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.