On 01.10.2010, at 00:37, Andreas Färber wrote:
Am 01.10.2010 um 00:03 schrieb Alexander Graf:
On 30.09.2010, at 19:02, Andreas Färber wrote:
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...
Those are pure fixups to get back to 32 bit mode from the interrupt handlers, as they go into 64 bit mode by default.
I'd really hate to see code duplication between an arch/ppc and arch/ppc64, since we'll want ppc and ppc64 versions of New World Macs and CHRP systems.
I'm not fully convinced that this would be a bad thing, but ok.
The easiest would be if I would find out how to configure a multi-lib ppc/ppc64 gcc-4.4.x, so that we can compile a ppc64 version using `make EXTRACFLAGS=-m64`. Otherwise we'd need to provide a separate cross-ppc64 config file and hack switch-arch to drop the "64" at some point so that it builds in obj-ppc64 but uses code from ppc...
You don't need to compile 64 bit code to address 64 bit physical addresses. Just map them to 32 bit addresses and you're good from the existing code base. The only thing that needs to change is the physical address variable type of the alloc function. That has to become uint64_t.
Alex