Andreas Färber wrote:
I've dug some more and noticed that the data parsed from /chosen/mmu/translations seems wrong:
0: map: 0x00000000, length 16384 -> physical: 0x00000000, mode 132972544 1: map: 0x00030000, length 0 -> physical: 0x07f00000, mode 1048576 2: map: 0x00000002, length -2147483648 -> physical: 0x000eb000, mode 106
Note the weird mode and subsequent values. It looks as if Haiku expects (and gets on real OpenFirmware): void *virtual_address int length void *physical_address int mode whereas OpenBIOS writes in libopenbios/ofmem_common.c:ofmem_update_mmu_translations: props[ncells++] = t->virt props[ncells++] = t->size props[ncells++] = t->mode
Should this be changed as follows, or is this platform-dependent?
Hmmm that's interesting. According to the OpenSolaris kernel source the translations property is mapped to the following struct:
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/sun4v/sys/...
struct translation { uint32_t virt_hi; /* upper 32 bits of vaddr */ uint32_t virt_lo; /* lower 32 bits of vaddr */ uint32_t size_hi; /* upper 32 bits of size in bytes */ uint32_t size_lo; /* lower 32 bits of size in bytes */ uint32_t tte_hi; /* higher 32 bites of tte */ uint32_t tte_lo; /* lower 32 bits of tte */ };
And in Haiku:
http://dev.haiku-os.org/browser/haiku/trunk/src/system/boot/platform/openfir... struct translation_map { void *virtual_address; int length; void *physical_address; int mode; } translations[64];
So in short, it does indeed look as if there are some platform differences here. I guess this extra field is based upon the Mac OF implementation so it would be good for someone to verify this on a real Mac before we go and hack the source for PPC-only hosts. Note that I can't see any references to the translations property in the OF spec so I guess it must be an extension.
ATB,
Mark.