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