One tiny fix...

... and suddenly everything goes better :-)

as you may remember, I have released a test pre-alpha iso with AROS for Efika recently. However, there were some issues with using it. Some people tried to boot it from DVD-USB devices, some tried USB Flash Keys. The former succeeded mostly (but not always) whereas the latter failed pathetically. I was scratching my head and found no sane solution. Once, being completely desperate, I have enabled full debug of OHCI driver, in order to see every single transfer description used by all USB devices in the system. There was it! In some cases, OHCI chip was instructed to read 512 bytes starting from physical address 0xffffffff. That cannot be and it couldn't work. At that point the reason of OHCI hanging was known. But why was it like this???

Well, the answer surprised me a bit. The issue was the sign extension during APTR to uint64_t cast. At some moment, AROS wanted to read from all bootable devices the first sector into it's local table in .bss section. Since that piece of code belongs to kernel, the virtual address of this portion of memory was somewhere around 0xff7f0000. Sign extended address, 0xffffffffff7f0000 was of course not found in the MMU hash table and the KrnVirtualToPhysical() call failed. Sign expansion fixed, et voilà! All the issues with mass storage are gone.

For those who do not own an Efika, a tiny screenshot:


here, you can see the PCI Tool (doesn't show much because the most of Efika devices are on MPC5200B SoC), the screenshot tool itself, About AROS window with the mysterious "chrp-ppc Build efika", and shell. I wanted to show you there, where the SYS: assign is pointing to. The volume labeled AROS: is a boot device named UH0. This is the USB flash key. The USB1: device is my DVD drive connected throughout USB bus.

The torrent file is here, if anyone of you is willing to test it. Keep in mind I have toyed with scheduler there. If it does not work smooth for you, let me know. If it works well, let me know too. If the iso fails on your machine, do not hesitate writing me about (in such case try to provide the debug log, if you can).

PS. If the boot starts before the USB key is enumerated, it will not be bootable for AROS. It sucks, but that's the way AROS boots (some people are considering few changes there). In such case, you may add a command line option, eg. bootdelay=5 will introduce additional delay of 5 seconds right before booting. The iso has a bootdelay of 3 seconds by default, because all my USB devices attached to efika (keyboard, mouse, flash key and DVD) are sitting on a hub.

Updates, updates

OMG, it was a busy weekend... :)

Last 48 hours were quite intensive. The source tree of Efika5k2 branch has been updated - the tree was almost 4 months old! I have added a complete contrib directory to the build - the iso is now 150 MB large and contains a complete gcc compiler toolchain for Efika as well as some other goodies.

The kernel.resource got new function, which may be used to change the WMID bits of certain pages of memory. One may use it, for example, to disable caching in some RAM areas. This feature is used by the PCI driver class for efika. Every region allocated for use by PCI bus master devices is excluded from caching. This manouver may simplify driver's code significantly. For example, the OHCI driver uses Endpoint Descriptors (ED) and Transfer Descriptors (TD) which may be used by both CPU and OHCI controller. With an incoherent cache enabled, the driver has to either flush or invalidate the cached copies of descriptors permanently. Here, uncached region for these descriptors permits a more simple and error-safer code.

I have changed the scheduler a bit. The old one was not so stable upon very small CPU loads. It's tendency was to lock interrupts and put CPU into sleep mode. Very unfortunate, I must say ;) The updated code introduces the Idle Task which enters the power saving mode in a safer way. The scheduler calculates the time which CPU spent during execution of very task. Have a look yourself at C:TaskList command to understand what I mean :)

Wait, Did I wrote "have a look yourself"? Yes! Download this torrent, and test the AROS for efika yourself. It is not complete yet. You will surely see it crashing. The both IDE and network drivers are missnig. The release is unstable. Just put the ISO on CD, put it into your USB-CD or USB-DVD drive and start efika. Then, type following commands in the OF prompt:

setenv boot-device cd
boot cd os_image

Once you see the Boot? > prompt, press 1 and be patient. The OF needs some time to read all aros' modules and will put enourmous amount of debug info. It will even report some missing file. Once AROS starts up, you will see the mouse pointer on the screen and CD drive working. Have fun. The serial port outputs debug information at 115200bps, 8N1.

PS. My upstream is limited. Please seed the file after download.

Back to Efika

Good Day Everyone!

After my last fights with the USB Mass Storage bounty I have decided to take a break there and continue with AROS port for Efika. The Mass Storage is basically ready, at least in my eyes, since I do lack the hardware where the whole USB stack makes any issues at all. It works here with two PC's I own and with two virtual machines: QEMU and VmWare Player.

Anyway, I'm back with Efika right now. I took my freshly written mass storage class, fixed the OHCI driver again (it uses the physical address provided by the CachePreDMA() call) and copied the whole Efika CD onto my SFS partition of USB stick. And guess what! I have the wanderer desktop on Efika in front of my eyes now! Horray! Screenshot will follow as soon as I organise a USB hub (two USB slots are not enough for mouse, keyboard and USB stick, you know :)

One note: as you may know from the lecture of my previous posts, both FAT and FFS filesystems lack proper caching and thus are relatively slow, especially on Efika. Attempting to boot from FFS partition on USB stick may take more than 10 minutes. Booting from FAT will not work, because this filesystem is still incomplete. As for SFS, Efika needed one minute to boot from it, approximately.

PS. Since the SFS filesystem for linux is not working well on my machine (it crashes the linux kernel during mount already), I have started VMWare with AROS and Efika cd's attached. Then I have plugged my usb stick, attached it to vmware and copied all the Efika ISO contents to the stick. Just as a proof that all the things are working here as expected.

YASU - Yet Another Status Update

Hello there,

There is actually not much to tell you, except the small status update :)

The development of AROS for Efika is an interesting coding experience. Some parts come without any trouble, and are ready to use, stable and usable just out of the box. Others require a bit more patience and documentation reading.

I have put a whole bunch of modules into the Efika kernel and they do seem to work properly. As I wrote the last entry in my blog, efika kernel consisted of 23 modules. Now, there are 40! All of them seem to work :-D. The PCI driver for MPC5200B successfully scans the PCI bus full of interesting devices

[PCI] Adding driver PCINative (Efika5200 native direct access PCI driver) to the system  
[PCI] Scanning bus 0  
[PCIDevice] 00.10.0 = 1002:5960 (Video PC Compatible VGA)  
[PCIDevice] 00.10.1 = 1002:5940 (Video Other )  
[PCIDevice] 00.1c.0 = 1057:5809 (Bridge Other )  
[PCI_Efika] All OK 

The ATI hidd communicates with my TFT monitor using our I2C class.

calling InitResident("radeon.hidd", NULL)  
[ATI] Init  
[timer] OpenDevice(0)  
[ATI] Enumerator: checking productid 5960 vendorid 1002 00008904  
[ATI] Enumerator: found productid 5960 vendorid 1002 masked_check 0  
[KRN] KrnMapGlobal(80000000->80000000 08000000 0305)  
[ATI] Got framebuffer @ 80000000 (size=128MiB)  
[KRN] KrnMapGlobal(88000000->88000000 00010000 0305)  
[ATI] Got registers @ 88000000 (size=64KiB)  
[ATI] RomBase provided by ATI card: 88020000  
[KRN] KrnMapGlobal(88020000->88020000 00020000 0305)  
[ATI] Got BIOS @ 88020000 (size=128KiB)  
[ATIBMP] Bitmap at 0x6e640, size 16384 bytes (131072 bits)  
[ATI] Video BIOS not detected in PCI space!  
[ATI] Attempting to read Video BIOS using openfirmware  
[OF] OpenKey('/pci/display')  
[OF] looking for child 'pci'  
[OF] looking for child 'display'  
[ATI] OF reported BIOS at ff1039b8  
[ATI] Legacy BIOS detected  
[ATI] Connector0: DDCType-2, DACType-1, TMDSType-0, ConnectorType-3  
[ATI] Connector1: DDCType-3, DACType-0, TMDSType--1, ConnectorType-2

The timer.device is ready and working. It uses slice timer which, at 33MHz timebase clock, has a minimal resolution of 7 microseconds. If it will be insufficient then I will try to change the clock used. Beloved dos.library complains that no bootable volumes have been found:

[DOS] __dosboot_IntBoot: Could not open bootmenu.resource, something's wrong!  
[timer] OpenDevice(1)  
[DOS] __dosboot_IntBoot: Checking MountList for useable nodes:  
No bootable disk was found.  
Please insert a bootable disk in any drive.  
Retrying in 5 seconds...

The USB stack is working. It has found my USB stick, yet it is unsupported :))

[USBDevice::New] Address=02, Interface=00, Bus=0x899e4, Hub=0x899e4 
[USBDevice::New] Device 1d00:13fe 00/00/00 at address 000899e4:02  
[USBDevice::New] Default LangID=0904  
[USBDevice::New] iProduct = "DataTraveler 2.0"  
[USBDevice::New] iManufacturer = "Kingston"  
[USBDevice::New] iSerial = "5B72059F82DF"  
[USB] USBDevice::New() = 0x94804  

The Efikas MPC5200B CPU has built in OHCI USB controller. Yay! That was fun! Allthough all usual OHCI controllers work in little-endian mode (even the one in PPC based Sam440/Pegasos/AmigaOne and others!!). MPC5200B is different. Here, the whole OHCI chip is a big endian beast. Respect! And wasted time for me ;)

In order to complete the Efika bounty, I need to do

• ata.device specific for MPC5200B. If I will do my best, DMA transfers will work.
• Network driver for Efika. The rest of TCP/IP stack is already there.

But hey! How will you install AROS on harddrive then? Tftpboot? Hard to do. Remove harddrive and use another machine? Almost impossible and stupid. Well?...

There is a way. Allthough the Poseidon bounty is open, I cannot wait for this bounty. Instead, I will apply for the bounty number 25. What do you think about? Am I cruel? Evil? Will my work on USB mass storage be pointless in spite of Poseidon? Tell me what you think about - I'm ready for all kinds of criticism ;)

During next few days I will consider what has a higher priority right now: USB Mass Storage or ATA. 

Cheers :)

AROS on Efika status update

I haven't been posting here for a very long time - sorry about that. I hope you still remember me :) The AROS port to Efika progresses nicely. There were some issues with handling of the MMU unit but now they are luckily ironed out.

The kernel.resource which happens to be the core of AROS, has been extended compared to the version which sam440 port uses, and even more extended compared to the x86_64 version. It uses MMU a bit more - protect all regions of memory which shouldn't be accessed, provides supervisor address space starting at 0xff000000 and provides access to a "virtual" SysBase, i.e. reading a 32-bit value (and only 32-bit one!) from address 0x00000004 will give you the pointer to the ExecBase structure.

Kernel resource exposes four new functions to the user space. KrnMapGlobal maps the physical address range of specified size into virtual one, using desired protection and caching settings. KrnUnmapGlobal removes the mapping created above. KrnCreateContext creates a cpu context stored in the area accessible by supervisor only. KrnDeleteContext removes the cpu context and eventually unbinds it from the FPU (kernel.resource in efika will use lazy FPU context switching).

There is also a new system call - SC_REBOOT. It performs a soft reboot of AROS on efika. Don't be afraid about non-intentional syscall which could reboot your efika, it may be done only in kernel.resource and exec.library. A system call which would occur from any other address range would cause no action.

Apart from the low-level stuff I tried to boot AROS with a bit more modules. The result looks like this:

Welcome to SmartFirmware(tm) for bplan EFIKA5K2
Version 1.3 (20070122084838)
SmartFirmware(tm) Copyright 1996-2001 by CodeGen, Inc.
All Rights Reserved.
Pegasos BIOS Extensions Copyright 2001-2007 by bplan GmbH.
All Rights Reserved.
ok boot

Second Level Bootloader for OpenFirmware
Build 242 from Sep 13 2008
Available memory 128MB


Available boot configurations:
1. AROS for Efika 5200
2. AROS for Efika Test 2
Boot? (4.8)>


Loading "AROS for Efika 5200"
boot/aros-efika
boot/modules/expansion.library
boot/modules/utility.library
boot/modules/partition.library
boot/modules/battclock.resource
boot/modules/aros.library
boot/modules/bootloader.resource
boot/modules/mathieeesingbas.library
boot/modules/oop.library
boot/modules/hiddclass.hidd
boot/modules/misc.resource
boot/modules/graphics.hidd
boot/modules/gfx.library
boot/modules/keymap.library
boot/modules/intuition.library
boot/modules/layers.library
boot/modules/input.device
boot/modules/timer.device
boot/modules/gameport.device
boot/modules/keyboard.device
boot/modules/pci.hidd
[KRN] EFika5200B Kernel build on Oct 1 2008
[KRN] BootMsg @ 0x19111e4
[KRN] Copying TagList and data
[KRN] CmdLine: 'command_line_option_1 command line "line option"'
[KRN] Initializing exception handlers
[KRN] Initializing MMU
[KRN] Location of MMU tables: 07000000-070fffff
[KRN] SDR1 = 0700000f
[KRN] Flushing TLB
[KRN] MBAR at f0000000
[KRN] HID0=0000c000 HID1=40000000
[KRN] Entering ictl_init.
[KRN] Stopping all interrupt activities
[KRN] Mapping 00003000-06ffffff range for public use
[KRN] Mapping f0000000-f002fffc range for MBAR
[KRN] Mapping ff100000-ff123fff range for public read-only access
[KRN] Mapping ff124000-ff7f4fff range for supervisor
[KRN] Mapping ff7f5000-ff7fffff range for read-write
[KRN] Mapping ff800000-ff8b6fff range for read-only
[KRN] Mapping ff8b7000-ffffffff range for supervisor
[KRN] Supervisor mem: 6979KB free
[exec] AROS for Efika5200B - The AROS Research OS
[exec] Preparing the ExecBase...
[exec] ExecBase at 00003280
[exec] Clearing ExecBase
[exec] Initializing library...
[exec] Adding memory
[exec] Done. SysBase->ThisTask = 0x004180
[exec] Resident modules (addr: pri version name):
[exec] + 0xff80fd50: 127 2 "kernel.resource"
[exec] + 0xff811070: 126 41 "exec.library"
[exec] + 0xff8142ec: 110 41 "expansion.library"
[exec] + 0xff81b658: 104 1 "partition.library"
[exec] + 0xff816828: 103 41 "utility.library"
[exec] + 0xff81c92c: 102 41 "aros.library"
[exec] + 0xff81f9c0: 101 40 "mathieeesingbas.library"
[exec] + 0xff81d820: 100 41 "bootloader.resource"
[exec] + 0xff823d5c: 94 41 "oop.library"
[exec] + 0xff824fe4: 92 1 "hiddclass.hidd"
[exec] + 0xff8b56a4: 90 1 "pci.hidd"
[exec] + 0xff866a60: 65 41 "graphics.library"
[exec] + 0xff8aaa38: 60 41 "layers.library"
[exec] + 0xff8aded0: 50 41 "timer.device"
[exec] + 0xff81bdf0: 45 41 "battclock.resource"
[exec] + 0xff82582c: 45 41 "misc.resource"
[exec] + 0xff8af5b0: 44 41 "gameport.device"
[exec] + 0xff8b0d2c: 44 41 "keyboard.device"
[exec] + 0xff86b158: 40 41 "keymap.library"
[exec] + 0xff8acc8c: 30 41 "input.device"
[exec] + 0xff8a0afc: 10 50 "intuition.library"
[exec] + 0xff869d30: 8 41 "cybergraphics.library"
[exec] + 0xff83c4d8: 0 1 "graphics.hidd"
[exec] InitCode(RTF_SINGLETASK)
enter InitCode(0x2, 0)
calling InitResident("kernel.resource", NULL)
[KRN] Kernel resource post-exec init.
[KRN] Interrupts enabled
[KRN] Entered user mode
calling InitResident("expansion.library", NULL)
leave InitCode(0x2, 0)
[exec] InitCode(RTF_COLDSTART)
enter InitCode(0x1, 0)
calling InitResident("partition.library", NULL)
calling InitResident("utility.library", NULL)
calling InitResident("aros.library", NULL)
calling InitResident("mathieeesingbas.library", NULL)
calling InitResident("bootloader.resource", NULL)
[BootLdr] Init. msg=0xff7ffc30
[BootLdr] KRN_CmdLine=0xff123ad0
[BootLdr] CmdLine="command_line_option_1 command line "line option""
[BootLdr] Init: Argument command_line_option_1
[BootLdr] Init: Argument command
[BootLdr] Init: Argument line
[BootLdr] Init: Argument "line
[BootLdr] Init: Argument option"
calling InitResident("oop.library", NULL)
calling InitResident("hiddclass.hidd", NULL)
calling InitResident("pci.hidd", NULL)
[PCI] Initializing PCI system
[PCIDriver] Dummy Driver initialization
[PCI] base class initialization
[PCI] Everything OK
calling InitResident("graphics.library", NULL)
calling InitResident("layers.library", NULL)
calling InitResident("timer.device", NULL)
calling InitResident("battclock.resource", NULL)
calling InitResident("misc.resource", NULL)
calling InitResident("gameport.device", NULL)
calling InitResident("keyboard.device", NULL)
calling InitResident("keymap.library", NULL)
calling InitResident("input.device", NULL)
calling InitResident("intuition.library", NULL)
calling InitResident("cybergraphics.library", NULL)
calling InitResident("graphics.hidd", NULL)
leave InitCode(0x1, 0)
[exec] I should never get here...
[KRN] Uhm? Nothing to do?
[KRN] STOPPED

Next module beeing working on is timer.device. Unfortunately, it will have worse resolution than the timer in sam440 - circa 7µs.

Status update - USB on Sam440

I have thought that fixing OHCI driver for endianess will be painful, since the OHCI chip works internally only in LittleEndian mode. Fixing it was like a fight with armor in form of preprocessor macros... But one day the war was over. The USB chip was, at least in theory, expected to work flawlessly.

It was not.

I have plugged the USB mouse and watched the debug. Wooha! OHCI root hub detected the change on one of it's ports. Great! The base USB class wanted to get on of mouse' descriptors, but it failed. It turned out that a local copy of transfer descriptor was in the data cache of CPU. Well, whatever. It may happen since AMCC440 does not maintain cache coherency. So, I did proper CacheClearE() and continued....


Two days later I was still fighting... Everything should work perfectly. The USB mouse got configured, my USB HID class knew what device it is. It was even able to parse the incoming reports. But there were none. Why oh why there are no reports from mouse???

Well, due to one mistake the OHCI chip was told that it should commit 0% (zero) for periodic transfers. Once fixed, USB mouse started to work. USB Stack is as usable as on a x86 architecture: USB - mice, keyboards, tablets and hubs are supposed to work. Additionally, I have fixed all cache issues in USB stack and enabled copy-back caching again.

You may see the PCITool app on sam440 - one of the very first programs I've started as soon as I could move the mouse pointer. Other Sam440 and AROS related screenshots may be found here.

I'm going to test AROS a bit this evening. As soon as everything will work as expected I will attempt to write the network driver for samantha.

UBoot Second Level Bootloader (UB2LB) update

I have been fiddling with my UBoot Second Level Bootloader (UB2LB) project. I ahve cleaned the code a little bit and added some nice features... Until now UB2LB assumed that user wants to perform network boot (through TFTP) only. Now it listens to the uboot and uses it's list of boot devices. It tries to boot of media selected through the environment variables boot1, boot2 and boot3. As soon as it supports booting from desired media and as soon as the media contains boot/menu.lst file (the file defining the layout of kernel modules and other boot options) it will start booting from it.

Currently the UB2LB supports booting through TFTP and CD (ISO9660 with optional RockRidge extensions). Since UBoot in Sam440 does support ElTorito, one can boot AROS (or at least parts of it, as Sam440 AROS is not yet ready ;)) directly from CD.

Besides ub2lb, I have been working on AROS for Sam440 too. There are already 30 modules loaded together with kernel into memory! Among them one may find dos.library and radeon driver. Both still need intensive testing though. At the very moment the filesystems and SATA driver are missing, therefore dos.library complains in it's usual way:

No bootable disk was found.
Please insert a bootable disk in any drive.
Retrying in 5 seconds...

Which is a lie of course, since it retries every 10 seconds :) The radeon driver is much more noisy and says

[ATI] Init
[ATI] Enumerator: checking productid 4c66 vendorid 1002 01004414
[ATI] Enumerator: found productid 4c66 vendorid 1002 masked_check 0
[ATI] Got framebuffer @ a8000000 (size=128MiB)
[ATI] Got registers @ b0000000 (size=64KiB)
[ATI] Got BIOS @ c0000 (size=128KiB)
[ATI] Restoring MEM_CNTL (00000000), setting to 2d002d01
[ATI] Radeon init
[ATI] flags: IsMobility
[ATI] R300CGWorkaroung = No
[ATI] Video memory = 64MiB (128 bit DDR SDRAM)
[ATI] Primary:
Monitor -- AUTO
Connector -- DVI-D
DAC Type -- TVDAC/ExtDAC
TMDS Type -- Internal
DDC Type -- DVI_DDC
[ATI] Secondary:
Monitor -- AUTO
Connector -- VGA
DAC Type -- Primary
TMDS Type -- External
DDC Type -- VGA_DDC
[ATI] Video BIOS not detected, using default clock settings!
[ATI] PLL parameters: rf=2700 rd=12 min=12500 max=35000; xclk=10300
[ATI] Usable size: 65536KB
[ATI] AllocBitmapArea(4096x16@4) = 0
[ATI] AllocBitmapArea(64x64@4) = 0x40000
[ATI] Enumerator found a card (ProductID=4c66)
[ATI] The card is supported

The AROS for Sam440 looks really promising. I am going to work on SATA driver right now and see how far will AROS boot.

No screenshot today... Again... Instead, if you are happy Sam440 owner, you may download test iso here. Do not expect much from it. If you assume that it will boot on any PPC hardware, then you are wrong. It will not work on any MacIntosh hardware. It will not work on any other OpenFirmware hardware. No, it will not work on Pegasos. Neither on Efika. This ISO does require UBoot firmware (with implementation of the boota command!) to work.

Ah, yes. Do not even try to boot this iso on AmigaOne, µA1 or any other. It will crash system before even exec.library will say "Hello, world!". AMCC440 CPU conforms the PowerPC E-Book specification and this version of AROS will not work any other type of PPC core :)

Anyway, have fun and stay tuned for more news :)

PS. Happy Easter to You all :))

Some news

Please forgive me, there will be no screenshot today! :) Instead, I may offer you bunch of log entries which I have found on the RS232 wires...

The kernel is still highly adjustable and thanks to the modules which are in PPC-form already it's a tiny bit bigger than previously

[KRN] Kernel size: 798KB code, 43KB data

It consists of the amcc440-aware kernel linked statically with exec.library (these two beasts have to cooperate somehow and depend on each other) and add-ons loaded by the UB2LB. They all are living in write-guarded address space far far away from any other allocatable memory. The kernel.resource does scheduling, handles interrupts, provides sane MMU mapping and handles exceptions properly. One of them is (and has to) issued everytime when the code tries to read a longword from absolute address 0x00000004. This area does not correspond any memory and assignment of the SysBase is done in exception handler. It is slower and inconvinient but accessing the SysBase pointer at 4UL is considered a bug anyway. Everything should be able to work without it. Later, the MMU handler will put some debug regarding such barbarian SysBase access.

Let's continue. The kernel pre-exec routine has been executed and did it's magic. Then, the exec's startup is called. It puts SysBase at the bottom of usable memory

[exec] AROS for Sam440 - The AROS Research OS
[exec] Preparing the ExecBase...
[exec] ExecBase at 008d0280

and scans for all modules loaded by the bootstrap code. There are lots of them currently, some of them even work :)

[exec] Resident modules (addr: pri version name):
[exec] + 0xff80bbd0:  127   1 "kernel.resource"
[exec] + 0xff80c5a0:  126  41 "exec.library"
[exec] + 0xff80f668:  110  41 "expansion.library"
[exec] + 0xff8166a8:  104   1 "partition.library"
[exec] + 0xff811b9c:  103  41 "utility.library"
[exec] + 0xff817454:  102  41 "aros.library"
[exec] + 0xff8186b8:  101  40 "mathieeesingbas.library"
[exec] + 0xff81cafc:   94  41 "oop.library"
[exec] + 0xff81ddb4:   92   1 "hiddclass.hidd"
[exec] + 0xff8a7cc0:   90   1 "pci.hidd"
[exec] + 0xff8aa588:   89   1 "pci-amcc440.hidd"
[exec] + 0xff85d904:   65  41 "graphics.library"
[exec] + 0xff8a10b0:   60  41 "layers.library"
[exec] + 0xff81e5ec:   45  41 "misc.resource"
[exec] + 0xff8abe0c:   44  41 "keyboard.device"
[exec] + 0xff8ad50c:   44  41 "gameport.device"
[exec] + 0xff861d64:   40  41 "keymap.library"
[exec] + 0xff8a3304:   30  41 "input.device"
[exec] + 0xff897338:   10  50 "intuition.library"
[exec] + 0xff860990:    8  41 "cybergraphics.library"
[exec] + 0xff8b1a88:    4  41 "console.device"
[exec] + 0xff834b38:    0   1 "graphics.hidd"
[exec] + 0xff8b6ce4: -120  44 "workbench.library"
[exec] + 0xff8bcb3c: -126  41 "con.handler"
[exec] + 0xff8c669c: -126   1 "packet.handler"
[exec] + 0xff8bece8: -127  41 "nil.handler"
[exec] + 0xff8c2e94: -127  41 "ram.handler"

Once the SysBase is up and operable, the exec.library calls InitCode. Twice. The first call is done with RTF_SINGLETASK and it wakes up the kernel.resource and expansion.library. The second, post-exec init of the kernel.resource prepares system to work without supervisor mode, eg. it enables userspace apps to flush caches. Then the interrupts are enabled and user mode is entered.

[exec] InitCode(RTF_SINGLETASK)
[KRN] Kernel resource post-exec init
[KRN] Allowing userspace to flush caches
[KRN] Interrupts enabled
[KRN] Entered user mode

Once expansion.library finishes it's setup, exec issues InitCode for the second time, with RTF_COLDSTART. There the real boot begins... Libraries are initialized, some of them fail at the very moment (eg. the input.device does a guru mediation since it cannot open timer.device yet) and the only visible (visible on serial debug of course!) effect of AROS booting is the PCI subsystem, which talks a lot (and works!)

[PCI] Initializing PCI system
[PCIDriver] Dummy Driver initialization
[PCI] base class initialization
[PCI] Everything OK
calling InitResident("pci-amcc440.hidd", NULL)
PCI440: Driver initialization
PCI440: Adding Driver to main the class OK
[PCI] Adding Driver class 0x01001d84
[PCI] Adding driver PCINative (AMCC440 native direct access PCI driver) to the system
[PCI] Scanning bus 0
[PCIDevice] 00.00.0 = 1014:027f (Bridge Other )
[PCIDevice] 00.0a.0 = 12d8:8150 (Bridge PCI-PCI Standard)
[PCIDevice] 00.0c.0 = 1002:4c66 (Video PC Compatible VGA)
[PCIDevice] 00.0e.0 = 1095:3114 (Mass storage Other )
[PCI] Scanning bus 1
[PCIDevice] 01.04.0 = 1013:6005 (Multimedia Audio )
[PCIDevice] 01.05.0 = 1131:1561 (Serial USB )
[PCIDevice] 01.05.1 = 1131:1561 (Serial USB )
[PCIDevice] 01.05.2 = 1131:1562 (Serial USB )
PCI440: All OK

Actually, the InitCode(RTF_ColdStart) should never return to exec.library. Due to missing dos it does return however

leave InitCode(0x1, 0)
[exec] I should never get here...

and this is the end of the story. At least today :)

Everything is virtual

Well, almost :)

The very first goal towards the SAM440 port of AROS is halfway done. The UBoot Second Level Bootloader is able to use TFTP protocol and load AROS menu.lst configuration file and binaries. It loads the AROS executables and relocates properly. It has reached the stage where I can live it as it is for a while and concentrate on the real goal - making AROS work on SAM440 board!

I have decided to separate the kernel (and libraries loaded together with it) from user space. The kernel is loaded somewhere within first 16MB of RAM and then relocated to the virtual address at the very top of the 32-bit address space. The bootstrap loader works in the same way as the x86_64 bootstrap did. It puts all read-only sections upwards from the kernel base, and all writable sections downwards from the kernel base. Since I'm evil by definition, my core of SAM440 AROS will greedily take all the memory *below* it's physical location for itself. This memory (few megabytes) will be used as a local pool for kernel and will be excluded from usermode access of any kind.

I must admit I was a bit surprised and shocked as I read the AMCC440 documentation. The PowerPC E-Book from IBM stands quite clearly:

Book E provides binary compatibility for 32-bit PowerPC application programs.
Binary compatibility is not necessarily provided for privileged PowerPC instruc-
tions.

And you know what? They really mean that! Writing lowlevel code for AMCC440 cpu is very different from my previous experience with G3 CPU. :)

No screenshot today. Even worse, my bootlogs are very boring this days. Have a look if you're strong enough...

Filename 'boot/aros-amcc440'.
Load address: 0xe15a078
Loading: ######
done
Bytes transferred = 27062 (69b6 hex)
[BOOT] Loading ELF file from address 0e15a078
[BOOT] ELF: section loaded at 00800000 (Virtual addr: ff800000)
[BOOT] ELF: section loaded at 00802000 (Virtual addr: ff802000)
[BOOT] ELF: section loaded at 007feffc (Virtual addr: ff7feffc)
[BOOT] ELF: section loaded at 007feff0 (Virtual addr: ff7feff0)
[BOOT] ELF: section loaded at 007fef90 (Virtual addr: ff7fef90)
[BOOT] ELF: section loaded at 007f5f94 (Virtual addr: ff7f5f94)
[BOOT] Flushing all caches
[BOOT] Jumping into kernel
[BOOT] Bss: ff7fef90-ff7fefeb, 0000005c
[BOOT] Bss: ff7f5f94-ff7fef8b, 00008ff8
[KRN] Clearing BSS
[KRN]   0xff7fef90-0xff7fefeb
[KRN]   0xff7f5f94-0xff7fef8b
[KRN] Kernel resource pre-exec init
[KRN] MSR=00029000

Stay tuned for more news.

I've promised to show you some screenshot

That's how it looks like. The menu drawing and handling in bootstrap is for real. The menu.lst file is made for testing purposes, just to see whether it will be interpreted properly.

The default boot option is marked red and will be booted in 2 seconds (as seen on the screen) unless some other option gets selected. Of course one may change both the default option and the timeout.

The menu.lst config file which was parsed by bootstrap was like this:

# menu.lst config file for PPC AROS. Test version ;)

timeout 20
default 0

title AROS PowerPC test 1
   kernel boot/aros-ppc1 arg1 argument_2 "some arg 3" another_one
   module Libs/arosc.library
   module boot/modules.pkg
   module boot/test1.module

title AROS PPC test 2
   kernel boot/aros-ppc2
   module boot/modules.pkg
   module boot/test2.module

title AROS PPC third option
   kernel boot/blah

Power for your embedded ideas.

I like embedded systems. They are beautiful and simple, yet powerful enough to surprise you. They surround us :-) Beware, they are watching you ;). Recently I have applied for the AROS bounty number 60 - port of AROS to the SAM440. Yes, going back to PowerPC world for some time.

The board is already at home and working. I have made a PPC crosscompiler toolchain on my laptop and have a very nice dev environment. I make the PPC build on x86 machine, boot on sam440 through TFTP protocol and watch the debug output sent over serial line on x86 again. Recently, I have even added the rs232 terminal support to my beloved Eclipse IDE, and I don't need to switch between Eclipse and xterm anymore :)

The porting process may be divided into few logical parts:

1. Writing the second level boot loader
   
2. Making AMCC440EP aware Kernel (with kernel.resource as it's interface)
   
3. Porting the core system
4. Testing and debugging
5. Porting the contrib/necessary (including the USB stack and TCPIP stack)
6. Testing and debugging
7. Even more testing and debugging ;)

The U-Boot installed on sam440 provides a boota command which was initially supposed to boot AmigaOS4 operating system. This command looks for possible boot sources and launches the proprietary second level bootloader used in OS4. On my setup it loads the open-sourced second level bootloader which is responsible for loading AROS kernel and additional modules in the same fashion x86_64 does. This step should be halfway ready (initially with boot through TFTP only) within next week. Later, the read-only support for several filesystems (FFS, SFS, ISO9660 come to my mind) will be added. You may expect some nice screenshot of this bootloader this week :).

In the mean time I will still hunt for bugs in x86_64 AROS. They are really nerving but hopefully solvable. Recently, it became possible to start the InstallAROS tool on 64-bit machine, format AFFS partitions and install 64-bit AROS onto the drive. AROS can even boot from harddrive after successful installation process. Amazing :)