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:
One step further. Keep the good work. Thinking about a sam now... :)
Hi Michal!
I was reading four comment about accesses to low addresses and I have remembered that some Mac emulators may take advantage of that, specially SheepShaver. That would allow running MacOS9 apps on top of AROS.
So here's my small request... could you please leave the first kilobytes free for MacOS use (that was between 8 and 64KB IIRC)? Maybe you want to remap them to another memory zone but I think that with that SheepShaver would work as well as Shapeshifter did on old miggies.
I did an AmigaOS4 port of BasiliskII and I wouldn't mind working on SheepShaver for AROS-PPC.
I have an Efika so I'll have to wait for Tigger to finish is work on that but I think that it would be quite possible to do it if both of you agreed that part.
Being able to run MacOS9 apps natively would rock. You could play Starcraft, run iCab, use old photoshop/Office versions...
The good point of this is that with the first KB free for the emulator no MMU functions will be required to get SheepShaver working :-)
@sleepless:
If you like I will add a command line option to kernel resource (called "macoshack" or something like this). if the option will be given, I will map some RWX memory in range 0x2000 - 0xffff. Would that be enough?
Hi Michal!
That option seems like a good idea :-)
I think the memory available should be from 0x0000 to 0x3000. Do you think that could be possible?
If that's not possible... do you think it could be possible to create some kind of MMU context for user apps so access to that memory zone is mapped by the kernel to other memory zone in a "transparent" way?
Thank you for your openness in this question :-)
@sleepless:
Aaaah. Access to address 0x0000 for all processes is a very bad idea. Excluding first few bytes of address space from any kind of access allows detection of programming mistakes (referencing NULL-pointers).
But I'm pretty sure we will find a way to both NULL-pointer protection and MacOS9 emulation.
PS. In worst case the SheepShaver will become it's own MMU map :) Everything is feasible :)
As you would activate sheepshaver support passing an argument to the kernel it would be optional, but having a different MMU context for some apps also sounds like a great idea.
How would this work? I guess Sheepshaver should call some function you provide to tell the scheduler that this app will remap the memory zone from 0x0000 to 0x3000 to other zone and the scheduler will switch MMU contexts.
PS: MMU functions could also help to develop Paula/CIA/Blitter emulators on PPC :-) It may be a good idea to leave unused the memory zone used by custom chips.
hi,
sorry for the inappropriate question, but will there ever be a ppc-boot-iso? i am willing to hack my open firmware (in progress) just to run aros natively..
Post a Comment
<< Home