On Thu, 6 Mar 2014, laire@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
On Fri, 7 Mar 2014, BALATON Zoltan wrote:
SYS_Start: Start first thread SYS_Start: MSR 0x3030
I think it's not working yet. It seems to crash during starting the first thread. I traced the calls to here:
0x0040d45c: SYS_StartNextThread? 0x0041f6e8: ?
IN: 0x0041f70c: lwz r5,200(r3) 0x0041f710: lwz r5,296(r5) 0x0041f714: lwz r10,428(r3) 0x0041f718: lwz r11,432(r3) 0x0041f71c: lwz r12,436(r3) 0x0041f720: lwz r13,440(r3) 0x0041f724: lwz r14,444(r3) 0x0041f728: lwz r15,448(r3) 0x0041f72c: lwz r16,452(r3) 0x0041f730: lwz r17,456(r3) 0x0041f734: lwz r18,460(r3) 0x0041f738: lwz r19,464(r3) 0x0041f73c: lwz r20,468(r3) 0x0041f740: lwz r21,472(r3) 0x0041f744: lwz r22,476(r3) 0x0041f748: lwz r23,480(r3) 0x0041f74c: lwz r24,484(r3) 0x0041f750: lwz r25,488(r3) 0x0041f754: lwz r26,492(r3) 0x0041f758: lwz r27,496(r3) 0x0041f75c: lwz r28,500(r3) 0x0041f760: lwz r29,504(r3) 0x0041f764: lwz r30,508(r3) 0x0041f768: lwz r31,512(r3) 0x0041f76c: mfmsr r0 0x0041f770: rlwinm r0,r0,0,17,15 0x0041f774: mtmsr r0
IN: 0x0041f778: bl 0x41cbcc
IN: 0x0041cbcc: lwzx r7,r2,r9 0x0041cbd0: lwz r8,24(r5) 0x0041cbd4: cmpw r7,r8 0x0041cbd8: beqlr
invalid bits: 00000001 for opcode: 1f - 17 - 04 (7d02492f) 0041cbdc IN: 0x0041cbdc: .long 0x7d02492f
Raise exception at 0041cbe0 => 00000006 (21)
This seems to be due to uninitialised/incorrect data but without knowing what the data structures are it is hard to tell.
Regards, BALATON Zoltan
On 07/03/14 00:03, BALATON Zoltan wrote:
On Thu, 6 Mar 2014, laire@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:
(cut)
Yes, this definitely looks better. In terms of the memory size, does MorphOS have a minimum memory requirement of 256MB? Otherwise, are you using the debug binary openbios-qemu.elf.nostrip rather than the stripped version? The reason for asking is that arch/ppc/qemu/ofmem.c declares OF_CODE_SIZE as 0x00100000 (1MB) whilst the debug file is ~1.4MB on my system here.
Does either increasing this to 2MB or swapping to use the stripped openbios-qemu.elf binary at 128MB help at all?
ATB,
Mark.
On Fri, 7 Mar 2014, Mark Cave-Ayland wrote:
Yes, this definitely looks better. In terms of the memory size, does MorphOS have a minimum memory requirement of 256MB? Otherwise, are you using the
I don't know if there's a minimum requirement. If so it at least appears to be not documented or this only happens on QEMU.
debug binary openbios-qemu.elf.nostrip rather than the stripped version? The reason for asking is that arch/ppc/qemu/ofmem.c declares OF_CODE_SIZE as 0x00100000 (1MB) whilst the debug file is ~1.4MB on my system here.
Does either increasing this to 2MB or swapping to use the stripped openbios-qemu.elf binary at 128MB help at all?
I'm using the stripped version which is 734040 bytes and it did not work with 128MB as I described but I think this is not related to openbios settings but to how MorphOS decides its memory layout. I hope someone can confirm this and explain why is it happening. Until then using at least 256MB memory is a good enough workaround for me.
I'm currently stuck at the place I've described yesterday which is very near the end of the initialisation of the Quark kernel but I don't know why is it failing. I hope to get some help with this because it is rather difficult to tell without source and knowledge about how Quark works.
Regards, BALATON Zoltan
On 07/03/14 20:11, BALATON Zoltan wrote:
debug binary openbios-qemu.elf.nostrip rather than the stripped version? The reason for asking is that arch/ppc/qemu/ofmem.c declares OF_CODE_SIZE as 0x00100000 (1MB) whilst the debug file is ~1.4MB on my system here.
Does either increasing this to 2MB or swapping to use the stripped openbios-qemu.elf binary at 128MB help at all?
I'm using the stripped version which is 734040 bytes and it did not work with 128MB as I described but I think this is not related to openbios settings but to how MorphOS decides its memory layout. I hope someone can confirm this and explain why is it happening. Until then using at least 256MB memory is a good enough workaround for me.
Okay. What should happen is that the kernel should parse the available properties (for both virtual and physical ranges) in order to calculate which areas of memory are free for use:
0 > cd /cpus/PowerPC,750 ok 0 > .properties name "PowerPC,750" device_type "cpu" cpu-version 80301 dcache-size 8000 icache-size 8000 dcache-sets 80 icache-sets 80 dcache-block-size 20 icache-block-size 20 timebase-frequency fd4bc0 clock-frequency fdad680 state "running" reg 00000000 available 00004000 07c54000 07e10000 f80f0000 00000000 ffffffff translations 00001000 00003000 00001000 00000000 07c58000 001b8000 07c58000 00000000 fff00000 00100000 07f00000 00000000 ok 0 > cd /memory ok 0 > .properties name "memory" device_type "memory" reg 00000000 08000000 available 00004000 07c54000 07e10000 000f0000
I've seen issues on SPARC before where some kernels try to allocate within the first free area of memory (starting top downwards) without checking the size and so end up writing over the PROM.
You can try experimenting with adding extra calls to ofmem_claim_phys() and ofmem_claim_virt() in arch/ppc/qemu/ofmem.c to mark extra areas of physical and virtual address space as in use at the top of RAM to see how MorphOS changes the address it calculates for the end of RAM based upon the updated values of the "available" properties.
I'm currently stuck at the place I've described yesterday which is very near the end of the initialisation of the Quark kernel but I don't know why is it failing. I hope to get some help with this because it is rather difficult to tell without source and knowledge about how Quark works.
FWIW you've got much further than I did, so keep up the good work :)
ATB,
Mark.
-
BALATON Zoltan -
Mark Cave-Ayland