Because the sizes of cells and pointers do not match on PPC64,
So fix that. Most OF implementations on 64-bit PowerPC use 64-bit cells; you pretty much need it for things like device access, esp. if running in real mode.
The Forth standard does not define pointers that do not fit in a cell; OF-specific words like rl@ take a cell-sized "address" as well.
I'm fairly sure that Andreas is aware of this (for example, one of the patches I posted earlier for SPARC32 fixes the generation of memory properties but will truncate the maximum address to 32-bits on PPC64 since the code assumes that a single cell can hold a virtual address).
Andreas - are you happy for these two patchsets to be applied? We'd like to hope they won't break PPC64 too badly until you can find some time to continue work on it.
My (our) requirement is that the guest-visible parts remain compatible with Apple OpenFirmware (the hardware we emulate today), and I'd prefer to share a common code base for ppc and ppc64.
You can do both with a 64-bit OF; you can provide a 32-bit client interface.
Apple's OF on the G5 machines is a 32-bit OF, and they do a lot of very much non-standard things (including a lot that are not correct).
It is possible that the Linux kernel will not work with certain 64-bit device tree things, because of bugs in the kernel. I recommend you fix such bugs, or avoid them. But you really want to have #address-cells = #size-cells = 2 in the root node; without it, for example, you cannot have 4GB or more of memory.
My understanding is that if we enlarge the internal cell size as suggested by Segher, encode-int and other Forth words will start widening their output, too, so that property values will start to differ, no?
No. encode-int will encode a 32-bit integer, always. All of the device tree data is completely independent of word size and endianness, etc.
"#address-cells" in the device tree actually means "number of 32-bit integers per address". It's historical...
Segher