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
On 06/03/14 18:07, BALATON Zoltan wrote:
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.
Hi all,
My reading of the link above is that it shouldn't really matter if real-mode? is set to true or false, although it just so happens that that the default is true on Apple's PPC implementation. Does MorphOS boot if real-mode? is set to true on real hardware?
On startup OpenBIOS maps the entire RAM 1:1 physical to virtual, so I would have thought that this shouldn't be an issue. All other OSs I've seen under OpenBIOS reads the translations property from the CPU in order to build up any existing mappings before installing their own memory handlers, so it's fairly standard practice and I wouldn't expect MorphOS to be any different.
Additional mappings can be requested via CIF as the loader requires, but of course the loader would assume that anything it hasn't explicitly requested hasn't been mapped so would avoid these regions.
Can you obtain the fault address at all? My feeling is that this is a symptom of something else having already gone wrong a while back, and the stack corruption/exception is another symptom of this.
ATB,
Mark.
On Thu, 6 Mar 2014, Mark Cave-Ayland wrote:
On 06/03/14 18:07, BALATON Zoltan wrote:
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.
Hi all,
My reading of the link above is that it shouldn't really matter if real-mode? is set to true or false, although it just so happens that that the default is true on Apple's PPC implementation. Does MorphOS boot if real-mode? is set to true on real hardware?
I think you meant that the default is false as seen here in this dump: http://johannes.sipsolutions.net/PowerBook/openfirmware-device-tree According to the ppc binding document I've quoted before it means that the default is virtual mode in which OF will establish memory management during device initalisation and after that it's the client's responsibility to handle it and provide callbacks to OF for memory management. (This is discussed in section 4.2.6.) However it is not clear to me what is the supposed behaviour before the client takes over memory management. It says: "When a client executes set-callback, Open Firmware shall attempt to invoke the >>translate<< callback. If the translate callback is implemented, Open Firmware shall cease use of address translation hardware, instead using the client callbacks for changes to address translation." From this I think OF is allowed to use its own vectors before the client takes over. Then: "A client program shall not directly manipulate any address translation hardware before it either a) ceases to invoke OF client services or b) issues a set-callback to install the >>translate<< callback." See below on how this applies to MorphOS.
On startup OpenBIOS maps the entire RAM 1:1 physical to virtual, so I would have thought that this shouldn't be an issue. All other OSs I've seen under OpenBIOS reads the translations property from the CPU in order to build up any existing mappings before installing their own memory handlers, so it's fairly standard practice and I wouldn't expect MorphOS to be any different.
Additional mappings can be requested via CIF as the loader requires, but of course the loader would assume that anything it hasn't explicitly requested hasn't been mapped so would avoid these regions.
Can you obtain the fault address at all? My feeling is that this is a symptom of something else having already gone wrong a while back, and the stack corruption/exception is another symptom of this.
I think I have a fairly good understanding what is happening but I don't know how to fix it in openbios. The first exception is happening because MorphOS unconditionally writes 0 to 0x80 in its start routine. This seems to be the same start routine that is later copied to the reset vector and this write may be something that is needed during a reboot for MorphOS but it is also done at first boot when that address is not managed by MorphOS yet. Openbios had part of its exception handling routine there which was overwritten and hence this lead to an invalid opcode exception. This is probably in violation of the standard but happens to work on hardware with other OF implementations and I can change openbios to not use this address so it works there too. The move_stubs patch achieves this.
MorphOS does not set a callback but seems to call OF functions before starting to take over memory management and it probably only calls exit after that which may work according to the above document. During MMU take over what happens though is this: First MorphOS copies some code to 0x0000-0x1fff without first disabling the memory management interrupts. (Maybe it expects them to be off until enabled.) The code it copies is not correct yet as it has jumps pointing to somewhere near the end of ROM area. Then it fixes up these jumps with addresses pointing to its current location at its load address (it may change this back later again but I have not got there yet). Then it enables the MMU bits in the MSR. Surely enough on QEMU it hits a DSI exception just after it copied its vectors but before it fixed them up which leads to a jump to somewhere in ROM and eventually hits an invalid opcode again. This does not happen if I disable the MMU bits in MSR when the vectors are first copied and let MorphOS enable them later after it fixed the vectors up. I think this either again just works by chance on real hardware or the OF implementations there disable these bits when calling the boot loader and do not need working MMU for client functions. It could be verified by checking the value of MSR on real hardware but I have no access to any. In either case if MorphOS had not assumed that no MMU exception happens while the vectors are wrong but explicitely disabled MMU bits before touching the vectors it would work. The exception happening here during MMU take over is not caused by openbios but by accessing memory by the boot code but openbios needs working MMU for client functions earlier so it cannot disable these bits itself before calling the bootloader unless it could enable during callbacks. So I see no easy way to fix this within openbios.
The stack corruption is happening much later and I don't know yet what causes it but I think it is not diectly related to the above. I will need to dig deeper into this if noone has any hints or insight.
Regards, BALATON Zoltan
-
BALATON Zoltan -
Mark Cave-Ayland