On 28.05.2011, at 14:03, Andreas Färber wrote:
Am 28.05.2011 um 13:50 schrieb Alexander Graf:
On 28.05.2011, at 13:48, Andreas Färber wrote:
Am 28.05.2011 um 13:42 schrieb Alexander Graf:
On 28.05.2011, at 13:37, Andreas Färber wrote:
To avoid some of the cell size vs. pointer size issues, use 64-bit cells on ppc64. Suggested by Segher.
This involves handling lack of 128-bit type and compiling 64-bit libgcc parts, copied from sparc64.
Hopefully fixes compilation on 64-bit host, too.
I thought ppc64 OpenFirmware uses 32bit cells?
That's what I thought, too... but Segher said otherwise in January, and Tarl said the internal cell size (that I'm trying to change here) were different from the guest-visible 32-bit cell size. Through the use of prog_arg_t the CIF is supposed to remain 32-bit.
Oh, too quick in replying :). You're changing the "cell" type which is used all over the place with sizeof() to figure out the cell size of guest visible (device tree) fields. I don't see how it could not be guest exposed.
So you're saying...? Do you oppose Segher? Or do you see a better way of doing this? :) Blue and Kenneth were having compilation issues due to pointer size != cell size, and I hoped this might solve the iso9660 issue (which it doesn't, unless I have missed some change).
I'm saying that changing sizeof(cell) will change the device tree:
drivers/escc.c:escc_add_channel
[...] cell props[2]; [...] props[0] = IO_ESCC_OFFSET + offset * 0x20; props[1] = 0x00000020; set_property(dnode, "reg", (char *)&props, 2 * sizeof(cell));
So while the guest expects reg to be 2 32-bit numbers, it suddenly gets 4 32-bit numbers that don't make sense. IIUC to the guest, any DT property is nothing more than a stream of bytes.
Alex