OpenBIOS March 2014

openbios@openbios.org

7 participants
30 discussions

[commit] r1277 - trunk/openbios-devel/libopenbios
by repository service 08 Mar '14

08 Mar '14

Author: mcayland Date: Sat Mar 8 14:03:01 2014 New Revision: 1277 URL: http://tracker.coreboot.org/trac/openbios/changeset/1277 Log: client.c: fixup display of nextprop return buffer when debugging is enabled Make sure that we display the entire 32-byte buffer result buffer when nextprop returns. Based upon a test patch sent to the mailing list by Olivier Danet. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/libopenbios/client.c Modified: trunk/openbios-devel/libopenbios/client.c ============================================================================== --- trunk/openbios-devel/libopenbios/client.c Sat Mar 8 02:00:11 2014 (r1276) +++ trunk/openbios-devel/libopenbios/client.c Sat Mar 8 14:03:01 2014 (r1277) @@ -189,7 +189,7 @@ memdump(arg2pointer(pb->args[2]), MIN(pb->args[3], pb->args[pb->nargs])); } else if (strcmp(service, "nextprop") == 0) { printk(FMT_prom_arg "\n", pb->args[pb->nargs]); - memdump(arg2pointer(pb->args[2]), pb->args[pb->nargs]); + memdump(arg2pointer(pb->args[2]), 32); } else if (strcmp(service, "setprop") == 0) { printk(FMT_prom_arg "\n", pb->args[pb->nargs]); } else if (strcmp(service, "canon") == 0) {

1 0

Re: [OpenBIOS] [patch] fix "partition-zero"/%BOOT booting for PowerPC targets.
by Mark Cave-Ayland 08 Mar '14

08 Mar '14

On 05/03/14 08:50, Andrei E. Warkentin wrote: Hi Andrei, > Hi, > > This is a patch against r1272 which implements fully bootcode booting via > Apple boot partition descriptors. The current implementation in > libopenbios/bootcode_load.c hardcoded values for QUIK (the old > OldWorld bootloader), which is useless if you try to boot anything > else. > > In particular, I implemented this to simplify my development and test > cycle on iQUIK (https://github.com/andreiw/quik), but I also tested > this with the NetBSD floppy. The later now boots to stage 2 as well, > although it tries using some functionality unavailable in the OpenBIOS > implementation when compared to Apple's. > > I did this in the simplest way possible. Thanks for the patch! I've been aware for a while that the bootcode loader is slightly different from the others, although I've not been too keen to alter the existing behaviour in case it breaks anything. However it seems that you've got some test cases so... I've taken your patch as a starting point and reworked the bootcode loader to get rid of the global Forth variables and bring it in line with the others. Can you try the attached squashed patch and confirm that it still works in your tests? With these changes I can still boot my basic quik hard disk image which is all I have. One minor comment is that when you submit patches, please can you try and isolate different changes and be wary of whitespace? For example, I see that you've also added some code so that mac-parts.c will drop out early if want_bootcode is set which is a global behaviour change and so should be done as a separate patch. > Btw, I see that the optimization bugs are still present. I had to > compile with -O0, otherwise the resulting image doesn't boot (GCC 4.8 > here). That's interesting because I don't see that problem here? Then again I had problems with existing toolchains and so ended up rebuilding my cross-compiler by hand which eliminated all the problems I was seeing: build@kentang:~$ powerpc-elf-gcc -v Using built-in specs. COLLECT_GCC=powerpc-elf-gcc COLLECT_LTO_WRAPPER=/home/build/ppc-cross/libexec/gcc/powerpc-elf/4.8.2/lto-wrapper Target: powerpc-elf Configured with: ../gcc-4.8.2/configure --prefix=/home/build/ppc-cross --enable-languages=c --target=powerpc-elf --disable-libssp Thread model: single gcc version 4.8.2 (GCC) build@kentang:~$ ATB, Mark.

1 0

[commit] r1276 - trunk/openbios-devel/arch/ppc/qemu
by repository service 08 Mar '14

08 Mar '14

Author: mcayland Date: Sat Mar 8 02:00:11 2014 New Revision: 1276 URL: http://tracker.coreboot.org/trac/openbios/changeset/1276 Log: arch/ppc/qemu.c: Update Mac99 and PReP model to PowerMac3,1 Change model name to one which is similar but supported by MorphOS and better matches the emulated CPU. This should be safe to change as the two models are very close and unlikely to cause problems with other OSs but more testing is welcome. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/ppc/qemu/init.c Modified: trunk/openbios-devel/arch/ppc/qemu/init.c ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/init.c Sat Mar 8 02:00:07 2014 (r1275) +++ trunk/openbios-devel/arch/ppc/qemu/init.c Sat Mar 8 02:00:11 2014 (r1276) @@ -745,12 +745,12 @@ /* model */ - push_str("PowerMac2,1"); + push_str("PowerMac3,1"); fword("model"); /* compatible */ - push_str("PowerMac2,1"); + push_str("PowerMac3,1"); fword("encode-string"); push_str("MacRISC"); fword("encode-string");

1 0

[commit] r1275 - trunk/openbios-devel/arch/ppc/qemu
by repository service 08 Mar '14

08 Mar '14

Author: mcayland Date: Sat Mar 8 02:00:07 2014 New Revision: 1275 URL: http://tracker.coreboot.org/trac/openbios/changeset/1275 Log: arch/ppc/qemu/ofmem.c: Update comment to point to new IEEE1275 documentation URL Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/ppc/qemu/ofmem.c Modified: trunk/openbios-devel/arch/ppc/qemu/ofmem.c ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/ofmem.c Sat Mar 8 02:00:03 2014 (r1274) +++ trunk/openbios-devel/arch/ppc/qemu/ofmem.c Sat Mar 8 02:00:07 2014 (r1275) @@ -179,7 +179,7 @@ /* Generate translation property entry for PPC. * According to the platform bindings for PPC - * (http://playground.sun.com/1275/bindings/ppc/release/ppc-2_1.html#REF34579) + * (http://www.openfirmware.org/1275/bindings/ppc/release/ppc-2_1.html#REF34579) * a translation property entry has the following layout: * * virtual address

1 0

[commit] r1274 - trunk/openbios-devel/arch/ppc/qemu
by repository service 08 Mar '14

08 Mar '14

Author: mcayland Date: Sat Mar 8 02:00:03 2014 New Revision: 1274 URL: http://tracker.coreboot.org/trac/openbios/changeset/1274 Log: arch/ppc/qemu.c: Fix cache parameter property names to match the standard Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/ppc/qemu/init.c Modified: trunk/openbios-devel/arch/ppc/qemu/init.c ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/init.c Sat Mar 8 01:59:59 2014 (r1273) +++ trunk/openbios-devel/arch/ppc/qemu/init.c Sat Mar 8 02:00:03 2014 (r1274) @@ -241,32 +241,32 @@ PUSH(cpu->dcache_size); fword("encode-int"); - push_str("dcache-size"); + push_str("d-cache-size"); fword("property"); PUSH(cpu->icache_size); fword("encode-int"); - push_str("icache-size"); + push_str("i-cache-size"); fword("property"); PUSH(cpu->dcache_sets); fword("encode-int"); - push_str("dcache-sets"); + push_str("d-cache-sets"); fword("property"); PUSH(cpu->icache_sets); fword("encode-int"); - push_str("icache-sets"); + push_str("i-cache-sets"); fword("property"); PUSH(cpu->dcache_block_size); fword("encode-int"); - push_str("dcache-block-size"); + push_str("d-cache-block-size"); fword("property"); PUSH(cpu->icache_block_size); fword("encode-int"); - push_str("icache-block-size"); + push_str("i-cache-block-size"); fword("property"); PUSH(fw_cfg_read_i32(FW_CFG_PPC_TBFREQ));

1 0

[commit] r1273 - trunk/openbios-devel/libopenbios
by repository service 08 Mar '14

08 Mar '14

Author: mcayland Date: Sat Mar 8 01:59:59 2014 New Revision: 1273 URL: http://tracker.coreboot.org/trac/openbios/changeset/1273 Log: client.c: fix up return value from CIF call-method/interpret The handle_calls() function was accidentally using the client-call-iface return value instead of the catch wrapping the underlying call. Return the correct catch result, and while we're at it add some extra logging to indicate when we've detected an error condition. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/libopenbios/client.c Modified: trunk/openbios-devel/libopenbios/client.c ============================================================================== --- trunk/openbios-devel/libopenbios/client.c Wed Mar 5 01:04:32 2014 (r1272) +++ trunk/openbios-devel/libopenbios/client.c Sat Mar 8 01:59:59 2014 (r1273) @@ -261,15 +261,22 @@ push_str(get_service(pb)); fword("client-call-iface"); + /* Ignore client-call-iface return */ + POP(); + /* If the catch result is non-zero, restore stack and exit */ val = POP(); if (val) { + printk("%s %s failed with error " FMT_ucellx "\n", get_service(pb), arg2pointer(pb->args[0]), val); dstackcnt = dstacksave; return 0; } + /* Store catch result */ + pb->args[pb->nargs] = val; + j = dstackcnt; - for (i = 0; i < pb->nret; i++, j--) { + for (i = 1; i < pb->nret; i++, j--) { if (dstackcnt > dstacksave) { pb->args[pb->nargs + i] = POP(); }

1 0

Re: [OpenBIOS] [morphos] Re: [morphos] MorphOS on QEMU
by BALATON Zoltan 07 Mar '14

07 Mar '14

Hello, On Fri, 7 Mar 2014, Mark Olsen wrote: > Hi, > > On Fri, 7 Mar 2014 21:11:16 +0100 (CET) > BALATON Zoltan <balaton(a)eik.bme.hu> wrote: > >> [SPAM] > > Can you please stop cross posting to this mailing list? Thanks. I really don't understand why you call my messages spam. I was asking about MorphOS. Your website says: "Please use the MorphOS mailing list for bug reports and other inquiries regarding MorphOS." I've also started my first message with asking for alternative contact if this wasn't the right one. Can you please tell me what contact to use then for such questions? On the other hand, according to this forum thread: http://www.morphzone.info/modules/newbb_plus/viewtopic.php?topic_id=5774&fo… you are the one who at least once managed to do what I'm asking about so you're probably in a good position to help and share your experiences and knowledge. In the light of this your answer seems rather unfriendly. Can you explain why I should not use this list? Regards, BALATON Zoltan

1 0

Re: [OpenBIOS] [morphos] MorphOS on QEMU
by BALATON Zoltan 07 Mar '14

07 Mar '14

On Thu, 6 Mar 2014, laire(a)t-online.de wrote: > The new log is beyond the Openfirmware stage. Can't really say why it > fails now. Could be a side effect to unexpected data from OpenBIOS or > unusual powerpc usage. But without looking deeper into this I wouldn't > know what the root cause is. I've debugged it a bit further and here is the result: Breakpoint 3, 0x00441dec in ?? () (gdb) info reg r0 0x434f4d31 1129270577 r1 0x7de7d90 132021648 note the stack pointer and compare this with the log: > 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 if I'm reading this right it copies data to 0x7a70000-0x7e00000 which will overwrite the stack. I tried with larger memory (256M instead of the default 128M) to see if it helps and here's what I've got: Breakpoint 2, 0x00441dec in ?? () (gdb) info reg r0 0x434f4d31 1129270577 r1 0xfde7d90 266239376 and the log also looks much better now: 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 0x10000000 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 0x10000000 MMU_SetupPageTable: PhysicalSpaceSize 0x11288000 MMU_Init_GetTableSize: AddressPhySpace 0x11288000 must be covered MMU_Init_GetTableSize: 0x20000000 Bytes covers all MMU_Init_GetTableSize: 2^524288 mapped Pages MMU_Init_GetTableSize: Number of PTEGs 0x00010000 MMU_SetupPageTable: PageTableSize 0x00400000 MMU_SetupPageTable: PageTable1 0xfc00000 PageTable2 0xc00000 MMU_SetupPageTable: PageTable 0xfc00000 MMU_SetupPageTable: SDR1 0x0fc0003f MMU_SetupPageTable: HTABORG 0x0fc00000 MMU_SetupPageTable: HTABMASK 0x0000003f MMU_SetupPageTable: Result 0x1 SYS_Init: New MemoryPtr 0x00988000 MemoryEnd 0x0fc00000 SYS_CreateMemList: MemoryPtr 0x988000 MemoryEnd 0xfc00000 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 0xfde7e20 SYS_MoveRomModuleToMemoryEnd: MyBoardNode 0x688314 MemoryStart 0x988000 MemoryEnd 0xfc00000 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 0xf870000 SYS_MoveRomModuleToMemoryEnd: [] 9421fe80 7c0802a6 90010184 3ca01139 SYS_MoveRomModuleToMemoryEnd: New BoardNode Address 0xf870000 Size 0x390000 SYS_MoveRomModuleToMemoryEnd: MemoryEnd 0xf870000 SYS_CreateMemList: Check Entry 1 VendorID 0x30000 DeviceID 0x3 Flags 0x1 SYS_CreateMemList: MyBoardNode 0x6883a4 Type 0x0 Name 0x68841c <ABox Module Rom> SYS_CreateMemList: FunctionID 0x2 VendorID 0x30000 DeviceID 0x3 <> SYS_CreateMemList: Address 0x4c0000 Size 0x1bb000 MapList 0xfde7e20 SYS_MoveRomModuleToMemoryEnd: MyBoardNode 0x6883a4 MemoryStart 0x988000 MemoryEnd 0xf870000 SYS_MoveRomModuleToMemoryEnd: Module 0x4c0000 0x1bb000 SYS_MoveRomModuleToMemoryEnd: CompressType 0x1 [] 434f4d31 003d00e0 001ba40c 7f800000 SYS_MoveRomModuleToMemoryEnd: Uncompress Module 0x4c0000(CSize 0x1bb000) Size 0x3d1000 CType 0x1 SYS_MoveRomModuleToMemoryEnd: Map it to 0xf49f000 SYS_MoveRomModuleToMemoryEnd: [] ff000000 101003c0 9421ffe0 7c0802a6 SYS_MoveRomModuleToMemoryEnd: New BoardNode Address 0xf49f000 Size 0x3d1000 SYS_MoveRomModuleToMemoryEnd: MemoryEnd 0xf49f000 SYS_CreateMemList: Check Entry 2 VendorID 0x30000 DeviceID 0x7 Flags 0x1 SYS_CreateMemList: Board not found SYS_CreateMemList: Check Entry 3 VendorID 0x30000 DeviceID 0x4 Flags 0x1 SYS_CreateMemList: Board not found SYS_CreateMemList: Check Entry 4 VendorID 0x30000 DeviceID 0x2 Flags 0x0 SYS_CreateMemList: Board not found SYS_CreateMemList: Check Entry 5 VendorID 0x30000 DeviceID 0x6 Flags 0x0 SYS_CreateMemList: Board not found SYS_CreateMemList: Check Entry 6 VendorID 0x30000 DeviceID 0x8 Flags 0x0 SYS_CreateMemList: Board not found SYS_CreateMemList: VModuleTable 0xf870000 0xfc00000 Size 0x390000 SYS_CreateMemList: VModuleTable 0xf49f000 0xf870000 Size 0x3d1000 SYS_CreateMemList: VModuleTable 0x0 0x0 Size 0x0 SYS_CreateMemList: VModuleTable 0x0 0x0 Size 0x0 SYS_CreateMemList: VModuleTable 0x0 0x0 Size 0x0 SYS_CreateMemList: VModuleTable 0x0 0x0 Size 0x0 SYS_CreateMemList: VModuleTable 0x0 0x0 Size 0x0 SYS_CreateMemList: VModuleTable 0xfc00000 0x10000000 Size 0x400000 SYS_CreateMemList: Final MemoryPtr 0x988000 MemoryEnd 0xf49f000 SYS_CreateMemList: MemoryPtr 0x988000 SYS_FindFreeMemArea: MemoryPtr 0x988000 MemoryEnd 0xf49f000 SYS_FindFreeMemArea: PMemoryPtr 0x988000 PAreaEnd 0xf49f000 SYS_FindFreeMemArea: Current Module[0] 0xf870000 0xfc00000 SYS_FindFreeMemArea: Current Module[1] 0xf49f000 0xf870000 SYS_FindFreeMemArea: New CurrentEnd 0xf49f000 SYS_FindFreeMemArea: Current Module[2] 0x0 0x0 SYS_FindFreeMemArea: skip SYS_FindFreeMemArea: Current Module[3] 0x0 0x0 SYS_FindFreeMemArea: skip SYS_FindFreeMemArea: Current Module[4] 0x0 0x0 SYS_FindFreeMemArea: skip SYS_FindFreeMemArea: Current Module[5] 0x0 0x0 SYS_FindFreeMemArea: skip SYS_FindFreeMemArea: Current Module[6] 0x0 0x0 SYS_FindFreeMemArea: skip SYS_FindFreeMemArea: Current Module[7] 0xfc00000 0x10000000 SYS_FindFreeMemArea: FreeAreaSize 0xeb17000 SYS_CreateMemList: FreeAreaSize 0xeb17000 SYS_CreateMemList: EndArea MemoryPtr 0xf49f000 SYS_CreateMemList: SkipAreaSize 0x0 SYS_CreateMemList: MemoryPtr 0xf49f000 SYS_CreateMemList: MemoryPtr 0x0f49f000 MemoryEnd 0x0f49f000 SYS_Init: RamDebug Start 0x10000000 Size 0x400000 SYS_Init: Initializing RamDebug at 0xf09f000 Size 0x400000 SYS_Init: RamDebug log start SYS_Init: create MyBase->KernelMemPool SYS_Init: HalConfig 0x684348 SYS_Init: KernelMemPool 0x988000 SYS_Init: HalConfig 0x684348 SYS_Init: InitStack 0x9880a0 size 0x1000 SYS_Init: HalConfig 0x684348 SYS_Start: HalConfig 0x684348 SYS_Start: Alloc Interrupt Stacks for CPU 0 SYS_Start: CPU 0 IntStack 0x98a030 SYS_Start: Load CPU 0 stack 0x98b020 SYS_Start: MMU_CreateTable() ********************************* ********************************* ********************************* ********************************* ********************************* ********************************* Alert: 0x1005 Alert: SYS_MMUAddPage: Page 0x80000 EndPage 0x81000 already exists ********************************* ********************************* ********************************* ********************************* ********************************* ********************************* Alert: 0x1005 Alert: SYS_MMUAddPage: Page 0xf2000 EndPage 0xf2001 already exists SYS_Start: done SYS_Start: Create Initial Kernel Threads SYS_Start: Create System Chief Thread SYS_Start: done SYS_Start: Create Exception Server Thread SYS_Start: done SYS_Start: Create SystemInit Thread SYS_Start: done SYS_Start: done SYS_Start: MasterClanChiefTID 0x10000000 ExceptionTID 0x10000010 SystemInitTID 0x10000011 CPUTimerServerTID 0x0 KernelPID 0x10000000 SYS_Start: Enable Interrupts SYS_Start: Start first thread SYS_Start: MSR 0x3030 Can you tell if the above are good or something is obviously wrong here? Can you give any tips on how to continue from here? This is starting to look promising but without a working console I don't really know if it's working yet or not. For the graphics card I have these three ideas: 1. Find a supported card I can plug in my host and try to pci pass through it. QEMU people said this may be problematic as this was not tested very well. (And I don't have a suitable card yet either.) 2. Maybe MorphOS can use some generic graphics card (VESA frame buffer) or can have drivers to one of the virtual graphics cards supported by QEMU (QXL, VMWare). 3. There exists an open source Voodoo1-3 emulation that may be possible to be adapted to QEMU if this would work with MorphOS but I'm not sure how much work would this be. Any comments on this? Regards, BALATON Zoltan

2 4

Re: [OpenBIOS] [morphos] MorphOS on QEMU
by BALATON Zoltan 06 Mar '14

06 Mar '14

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

2 2

[PATCH 4/4] Changes for MorphOS
by BALATON Zoltan 06 Mar '14

06 Mar '14

arch/ppc/qemu: Move exception handling stubs to a place where it is less likely that they get overwritten. In particular this allows MorphOS to not crash at its first move which has previously overwritten the exception_return code at 0x80. According to the comments in ofmem.c it should still be safe to use space between 0x3000 and 0x3FFF Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> Index: openbios-devel/arch/ppc/qemu/start.S =================================================================== --- openbios-devel/arch/ppc/qemu/start.S (revision 1272) +++ openbios-devel/arch/ppc/qemu/start.S (working copy) @@ -280,21 +280,6 @@ 1: nop // b 1b -call_dsi_exception: - LOAD_REG_FUNC(r3, dsi_exception) - mtctr r3 - bctrl - b exception_return - -call_isi_exception: - LOAD_REG_FUNC(r3, isi_exception) - mtctr r3 - bctrl - b exception_return - -exception_return: - EXCEPTION_EPILOGUE - trap_error: lis r1, 0x8000 /* r1=0x80000000 */ add. r1,r1,r1 /* r1=r1+r1 (high 32bit !0) */ @@ -371,13 +356,19 @@ #endif +VECTOR( 0x3000, "DSI_ISI" ): real_dsi: EXCEPTION_PREAMBLE - b call_dsi_exception + LOAD_REG_FUNC(r3, dsi_exception) + b call_exception_handler real_isi: EXCEPTION_PREAMBLE - b call_isi_exception + LOAD_REG_FUNC(r3, isi_exception) +call_exception_handler: + mtctr r3 + bctrl + EXCEPTION_EPILOGUE GLOBL(__vectors_end):

1 0