Ten years ago…

… I was preparing my very first commit for AROS. It wasn’t much. A tiny bootsector loading few sectors from floppy. These sectors contained some startup code followed by empty function written in C. Everything else was written in assembler.

No, it wasn’t working yet. It was just proof of concept. A small check whether I will be able to perform this task. I was ten years younger and much more stupid of course. It was beginning of a great adventure.

And then, three days later, the cvs mailer generated an email containing these few lines:

* schulz 15.09.1998 22:31:13

  AROS/config/ibmpc/boot/: Makefile(A), README(A), bootsect.S(A), 
  head.S(A), init.c(A), setup.S(A), video.S(A):
   
  At least. The first pre-alpha version. Not to much for now, but it 
  is.

The mysterious story of native x86 AROS begun. It’s time to open some wine 🙂

SAM440 Bounty

Has been marked as completed. I have been working on AROS port for SAM440 for half a year. It was an extraordinary experience. I have never been working on such “young” hardware before. I have never been cooperating with board developers at this degree before. Thank you all for letting me do it! 🙂

The ISO of Sam440 AROS can be found here (MD5: 68b1010851d29de3aaf711af7fa9144e). It is compressed with 7zip again. Network starts automatically upon AROS startup. Due to some inconvenience in AROS (it lacks __ckhabort() function) I haven’t used DHCP protocol to set the IP of Sam440. Instead, the static address 192.168.2.211 is used.

I want to thank all of You who did helped me. My Wife for patience and acceptance, Randy Vice for leading TeamAROS for so long, and for very nice cooperation, Massimiliano Tretene and Nicola Morocutti for all the help, tons of good technical information and nice talks late evenings, all Bounty supporters and the whole AROS team and all you who whished me luck.

I will not leave the sam440 alone. There is still so much to do 🙂
… and never enough time.

Bye,
M.

Try it Yourself

Sam440 port of AROS is missing the EMAC driver at the moment. Nevertheless I have decided to give you a test version to try. Few comments on this iso:

  • Download it from this address,
  • Compressed size: 7492755 bytes, Uncompressed size: 37980160 bytes,
  • the MD5 sum equals 6f630f0bff9f5c5922d5ef76e1c748f5
  • The kernel of AROS assumes that your machine has 512MB of memory,
  • The default resolution is set to 1024x768x16. Due to a bug hiding in Zune, AROS might be unstable after the mode switch.
  • I have tested AROS connected to monitor through the DVI port – this one works for sure.

Have fun with it.

Small status update

Hello there.

If you were wondering where the hell am I, here’s the answer. My son, Oliver, was in a hospital recently. Twice within a month, once with nephritis, once with pneumonia. I have shared all my time between work, taking care of my daughters and visiting Oliver. There was very few time for AROS.

It does not mean that I did nothing, though. First of all I have been trying to make our ata.device work with Sam440’s SiL3114 SATA chip. With a significant help of Tomasz Wiszkowski I made it work on Sam! There were few issues which were not ever seen on x86 architecture. I have had to implement cache flushing in exec.library (finally! I should have done it before ;)), I have added some endian swapping code and had to flush data cache after the setup of PRD entries for DMA transfer.

The next step was radeon.hidd. It simply wasn’t working as expected. Initialization of any screen mode put my monitor into sleep mode. Not good. I had to add proper timing function to the driver (previously it used busy loops for all kinds of delays), then I have embedded a real BIOS into the sam440 variant of this driver – still no luck with displaying. I have added i2c support to the driver and now it even uses DDC bus and EDID information of the connected monitor. Still no luck. Finally, I have synced the video mode restore in my driver with xorg repository. That helped. It seems that the PLL setting on radeon is awfully fragile.

Having SATA and Radeon chips working, I have decided to give AROS a try. I have burned it on CD and booted on SAM. Ouch. Program exception. It turned out that I have had an outdated version of ELF LoadSeg, which was not flushing any caches. Another try brought me a bit further, but AROS hung on the following lines in startup-sequence:

If EXISTS ENV:SYS/Packages
    List ENV:SYS/Packages NOHEAD FILES TO T:P LFORMAT=”If EXISTS $SYS/Packages/%s*NCD $SYS/Packages/%s*NIf EXISTS S/Package-Startup*NExecute S/Package-Startup*NEndif*NEndif*N”
    Execute T:P
    Delete T:P QUIET
    CD SYS:
EndIf

Out of curiosity, I have deleted the SYS:Prefs/env-archive/SYS/Packages directory and tried once more. Moooo! Success. The wanderer screen showed up as you may see on the screenshot. BTW. Photographing display sucks. 🙂 I will investigate the issue with startup-sequence a bit later. Right now it’s a bit to early for it.

Now I gave the OHCI driver a look. The code assumed to some degree that it works on little endian machines. Moreover, it did assumed, that the processor uses very nice feature called cache snooping, which is the case on x86 family of CPU’s. Cache snooping means, that the CPU watches all transactions on the bus, and thus keeps it’s all caches up to date. Since it is not the case on sam440, the OHCI code needs to be reorganized a bit – it requires tons of CacheClearE() calls and few CachePreDMA/CachePostDMA pairs. At the moment all caches on Sam440 are working in write-through modus and will stay so until I fix all cache-irrelevant issues in the USB stack. I hope to have the whole stack working within few weeks.

In the mean time, I have helped Kalamatee with ACPI code a bit. Together we have made all CPU’s in x86_64 SMP system booting. At the very moment all Application Processors are switched into 64bit mode of operation and then put to sleep.

Find a bug…

in the following piece of code:

/* Allocate method table for this interface */
ifb->MethodTable = (struct IFMethod *)AllocVec(mtab_size, MEMF_ANY);
if (ifb->MethodTable)
{
  /* Get correct ID for the interface
     (string ID => interface ID mapping) */
  if (init_mi_methodbase(interface_id, &(ifb->InterfaceID), OOPBase))
  {
    ….

Found it? No? Too bad, you loose. Remember my words: “ULONG is BAD, IPTR is GOOD“. The init_mi_methodbase expects as a second argument a pointer to an ULONG and the ifb->InterfaceID was declared as an ULONG some days ago. It was supposed to work properly, since the ID is not a pointer in any form. Fine. The issue is, the struct IFMethod which did contained the InterfaceID ULONG field “inherits” from the Bucket used in hahstables of the oop.library. The Bucket structure expets this ID field to be an IPTR….

What a mess!

The 32-bit ULONG variable of struct IFBucket was initialized properly but the Bucket structure expected to find there a 64-bit IPTR one. Until now it was just reading some random values, name them trash. On some machines one had there zeroes instead of random values. That was the case on my machine, on qemu and on vmware. I have not seen this bug 🙂 Now I have modified memory alloc functions, so that they fill allocated region with some trash, unless the MEMF_CLEAR flag was set. Thanks to this small change I was able to see what many of you saw upon trying my last aros64 iso. After some fight with oop.library (adding debug points here and there) I have solved the issue.

You may download the new AROS64 iso from here. The md5 sum of the file is: 4852e85ab83f949e9ffe0019ea039e59.

I hope you will be able to boot into Wanderer now. And remember, AROS64 in VESA mode looks simply better 🙂

EDIT: I have uploaded newer iso. Here, the kernel limits address space to the 4GB. As soon as proper MMU handling is done, I will remove this limit.