Hello,
On Thu, 6 Mar 2014, laire@t-online.de wrote:
The standard behavior for the PPC OF boot process is disabled memory management when it starts the boot image. The system take over is always a sensitive thing but there is no reason for an OF to use the powerpc exception vectors in that early phase for what functions MorphOS is using.
Thanks for your reply. I could prevent the crash due to writing to memory address 0x80 by moving the exception handling code of openbios to somewhere else but unfortunately openbios is using the DSI and ISI exceptions and it seems it cannot work without them. I have found this document: http://www.openfirmware.org/1275/bindings/ppc/release/ppc-2_1.html that discusses memory management issues between OF and clients on PPC but I don't see what would be the correct behaviour.
I tried disabling these bits in openbios before staring the boot executable but that makes it freeze the first time it calls an openbios callback and I don't know how to change it to not rely on working memory management for client callbacks. However, if I leave these exceptions enabled and only disable them when the MorphOS boot tries to install its own handlers it seems to work all right and get past this point. So I think if MorphOS cleared the DSI and ISI bits before touching the vectors just in case, it would get further on QEMU while this should not matter on real hardware where these bits are supposedly not enabled anyway.
Currently I think I've managed to get through the boot phase and got to where the Quark kernel is started and tries to initialise itself. Here is the debug log I got:
macio_scan: macio_scan: found <mac-io> at 0x81080000 No more MacIO devices Done scanning MacIO openpic_init() Resetting PIC PIC reset 0xF80000E0 = 00000000 0xF80000E0 = 00000000 VendorID 0x0 I am CPU 0 IPVP0 Reg 0xa0000000 SYS_PreInit: Am I still alive? SYS_PreInit: Am I yet still alive?
Quark 0.93 (29.11.2013) Copyright 1998-2013 by Ralph Schmidt, Mark Olsen
SYS_Init: MemoryPtr 0x00988000 MemoryEnd 0x08000000 SYS_CopyCPUHalConfig: CPU Version 0xc Revision 0x209 SYS_CopyCPUHalConfig: CPUClock 0 BUSClock 0 BusTicks 0 SYS_CopyCPUHalConfig: Ticks50Hz 20000000 SYS_CopyCPUHalConfig: CacheL1Type 0x0 CacheL1Flags 0x1000f SYS_CopyCPUHalConfig: ICacheL1Size 32768 ICacheL1LineSize 32 ICacheL1Lines 1024 SYS_CopyCPUHalConfig: DCacheL1Size 32768 DCacheL1LineSize 32 DCacheL1Lines 1024 SYS_CopyCPUHalConfig: CacheL2Type 0x0 CacheL2Flags 0x0 SYS_CopyCPUHalConfig: ICacheL2Size 0 ICacheL2LineSize 0 ICacheL2Lines 0 SYS_CopyCPUHalConfig: DCacheL2Size 0 DCacheL2LineSize 0 DCacheL2Lines 0 SYS_CopyCPUHalConfig: CacheL3Type 0x0 CacheL3Flags 0x0 SYS_CopyCPUHalConfig: ICacheL3Size 0 ICacheL3LineSize 0 ICacheL3Lines 0 SYS_CopyCPUHalConfig: DCacheL3Size 0 DCacheL3LineSize 0 DCacheL3Lines 0 SYS_CopyCPUHalConfig: TLBEntries 0 TLBSets 0 MMU_SetupPageTable: MemoryPtr 0x00988000 MemoryEnd 0x08000000 MMU_SetupPageTable: PhysicalSpaceSize 0x09288000 MMU_Init_GetTableSize: AddressPhySpace 0x09288000 must be covered MMU_Init_GetTableSize: 0x10000000 Bytes covers all MMU_Init_GetTableSize: 2^262144 mapped Pages MMU_Init_GetTableSize: Number of PTEGs 0x00008000 MMU_SetupPageTable: PageTableSize 0x00200000 MMU_SetupPageTable: PageTable1 0x7e00000 PageTable2 0xa00000 MMU_SetupPageTable: PageTable 0x7e00000 MMU_SetupPageTable: SDR1 0x07e0001f MMU_SetupPageTable: HTABORG 0x07e00000 MMU_SetupPageTable: HTABMASK 0x0000001f MMU_SetupPageTable: Result 0x1 SYS_Init: New MemoryPtr 0x00988000 MemoryEnd 0x07e00000 SYS_CreateMemList: MemoryPtr 0x988000 MemoryEnd 0x7e00000 SYS_CreateMemList: Check Entry 0 VendorID 0x30000 DeviceID 0x1 Flags 0x1 SYS_CreateMemList: MyBoardNode 0x688314 Type 0x0 Name 0x68838c <ABox Rom> SYS_CreateMemList: FunctionID 0x1 VendorID 0x30000 DeviceID 0x1 <> SYS_CreateMemList: Address 0x445000 Size 0x7b000 MapList 0x7de7e20 SYS_MoveRomModuleToMemoryEnd: MyBoardNode 0x688314 MemoryStart 0x988000 MemoryEnd 0x7e00000 SYS_MoveRomModuleToMemoryEnd: Module 0x445000 0x7b000 SYS_MoveRomModuleToMemoryEnd: CompressType 0x1 [] 434f4d31 0038fd60 0007ae06 4a085fc8 SYS_MoveRomModuleToMemoryEnd: Uncompress Module 0x445000(CSize 0x7b000) Size 0x390000 CType 0x1 SYS_MoveRomModuleToMemoryEnd: Map it to 0x7a70000
Currently it fails when trying to return from a subroutine at the end here:
IN: 0x00441d74: li r3,1 0x00441d78: b 0x441d94
IN: 0x00441d94: lwz r0,20(r1) 0x00441d98: mtlr r0 0x00441d9c: addi r1,r1,16 0x00441da0: blr
Raise exception at 112ac440 => 00000003 (40000000)
which looks like a stack corruption somewhere. Do you have any idea what may cause this?
Regards, BALATON Zoltan
Regards
-----Original-Nachricht----- Betreff: [morphos] MorphOS on QEMU Datum: Wed, 05 Mar 2014 14:16:03 +0100 Von: BALATON Zoltan balaton@eik.bme.hu An: morphos@ml.morphos-team.net
Hello,
I'm trying to find out if it would be possible to run MorphOS on QEMU and have done some experiments with it. (Even if it is far from being usable and may never reach production quality it is still interesting to see how far I can get and if I can make it work as much as it is possible.) Here is what I have found so far.
QEMU can emulate a Mac99 machine that is similar to whay is supported by MorphOS so I try to use this for now. At first I've found that it crashes due to boot.img trying to write zero to 0x80 memory address at the very beginning, which overwrites the memory exception handlers of openbios and leads to a crash. If I remove this zeroing and fix some openbios bugs (for detailed discussion see the openbios mailing list at http://www.openfirmware.info/pipermail/openbios/2014-March/thread.html) it gets much further to the point where it is almost ready to start initializing the system. More exactly it crashes now while installing its own exception handlers. From this I think there is an implementation difference between openbios and Apple's openfirmware in that the latter seems to run the boot loader with memory management exceptions disabled while openbios uses these exceptions and this causes problems during the boot of MorphOS. Can someone who has knowledge about it please confirm this?
I've also found that MorphOS tries to get the name of the / node of the device tree to decide if it is running on a Mac. Maybe it would be better to use the "compatible" property instead as the root node name can differ between implementations.
I'd like to know if anyone from the developers can/is willing to help and if I can get hints or can turn to here/elsewhere with my questions during this effort?
To those who hope this can be a viable alternative to running MorphOS anytime in the near future I'd like to point out that a big obstacle I know about is the lack of emulation of any supported graphics cards in QEMU and possibly some other bugs to fix first so at this point it is more an experiment than something that can be interesting to a wider audience.
Regards, BALATON Zoltan