On 03/01/11 21:59, Andreas Färber wrote:
According to Tarl, the virtual address is not supposed to respect #address-cells but to use as many (integer) cells as needed for - hardcoded - one (stack) cell. I would thus expect the virtual address to be 4 bytes on sparc32.
Maybe the physical address is wider than expected?
Reviewing this again now, the obvious thing to spot is that the virtual address should be 2 cells wide in /virtual-memory:
ok cd /virtual-memory ok .properties .properties ? ok .attributes available 00000000 fff00000 00100000
i.e. the virtual address does seem to respect #address-cells here. I did a quick hack on OFMEM here to see what happens if I do this, and now the Solaris kernel gets stuck in a panic loop rather than invoking the fatal trap in Qemu - which I guess is progress ;)
It does however mean that the translation information must be being passed via the romvec memlist arrays, rather than being read from the device tree properties unless there is another MMU device node somewhere that we haven't found?
ATB,
Mark.