[OpenBIOS] PATCH: Make creation of the MMU translation entries architecture-specific

[Andreas Färber]

Am 22.05.2010 um 15:37 schrieb Andreas Färber:

> Am 21.05.2010 um 12:03 schrieb Mark Cave-Ayland:
>
>> Andreas, if this works, how much further does the Haiku boot get?
>
> The stock nightly CD images (http://haiku-files.org/ppc/index.php?show=all 
> ) don't visibly get further.
>
> Locally, with the attached patch applied to Haiku's boot loader, I  
> avoid a memset on the memory returned by of_claim and thus get to  
> some debug output I've enabled in arch/ppc/ 
> mmu.cpp:find_allocated_ranges (the "0: map: ..." stuff).

Forgot to state the obvious: Numbers in the debug output do look  
better since r772! :)

> Comparison with Apple's OpenFirmware shows that:
> * Apple's of_claim returns memory at 0x00400000 (vs. 0x07f00000)
> * On the Mac I see an identity-mapped area at 0x00400000, length  
> 4194304, mode 16 (vs. mode 2 and size 1048576 for 0x07f00000 from  
> OpenBIOS)
>
> Haiku seems to actually claim 1048576 bytes for the new page table,  
> so I guess it uses up all available memory?

> Where can we bump that number? QEMU?

Let me rephrase the question:

If I read QEMU code correctly (hw/ppc_{new,old}world.c, hw/ppc_mac.h)  
then OpenBIOS should be loaded at PROM_ADDR (0xfff00000) of size  
BIOS_SIZE (1024 * 1024), i.e. the last 1 MiB of address space. Yet I  
don't see a translation for that.

Neither QEMU nor OpenBIOS have 0x07f00000 hardcoded anywhere. Where is  
it coming from?

Andreas