[OpenBIOS] [morphos] MorphOS on QEMU

[Mark Cave-Ayland]

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.