[OpenBIOS] [morphos] MorphOS on QEMU

Thu Mar 6 19:07:59 CET 2014

Hello,

On Thu, 6 Mar 2014, laire at 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 at eik.bme.hu>
> An: morphos at 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
>
>
>