[OpenBIOS] OpenBIOS and ppc64?

[Blue Swirl]

On Thu, Sep 30, 2010 at 5:02 PM, Andreas Färber <andreas.faerber at web.de> wrote:
> Hello,
>
> I'm investigating the idea of a new QEMU chrp machine derived from mac99.
> The background is that there are ofmem issues when running Haiku on the
> g3beige machine, whereas running AIX on mac99 fails with the fix in place
> that makes Haiku go further. I assume this is due to differences in memory
> layout so that I need to move OpenBIOS to another location in RAM and
> anything else that clobbers the memory locations AIX assumes to be able to
> claim for itself.
>
> Not having (low-level) access to an IBM Power System / System p / pSeries,
> the best source I could find was a JS20 device tree [1]. (Some older RS/6000
> ones for comparison are available at [2].)
>
> Interestingly the nvram is at 0x00000100ff800000 and pci at
> 0x08000000f8000000, i.e. above 32-bit address space. With sizeof(void*) ==
> 4, drivers/macio.c:nvram is unable to save and access such an address.
>
> ofmem cannot deal with 64-bit virtual/physical addresses either, since it
> uses 32-bit ucell in translation_t and range_t. The MMU translations on
> mac99 don't match Apple's OpenFirmware on my G5 size-wise.

It looks like the cell size is 32 bits, but both #address-cells and
#size-cells is 2.

> What's the plan for fixing this? Will we need an openbios-ppc64 after all,
> or is there a way to fix these issues in openbios-ppc using uint64_t and
> some assembler magic? The 970 init
> (arch/ppc/qemu/init.c:ppc64_patch_handlers) apparently does something clever
> for the interrupt handlers and seems able to use 64-bit ld/std instructions
> in start.S. That still wouldn't help with ucell based structs and C
> functions of course...

If you don't have to implement JS20, are there any other machines
where all devices are located inside the first 4G?

There are more trees here:
http://penguinppc.org/historical/dev-trees-html/trees-index.html