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 :)
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 :)
Labels: PPC
posted by Michal Schulz at 08:17
7 comments
