February 27, 2008

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 :)


February 7, 2008

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-

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: ######
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.