I failed to run Mips target test image on my amd64 machine and I now found the reason of the bug: the kernel loader code used in hw/mips_r4k.c and hw/mips_malta.c implicitelly assumes that the ram_addr_t is 32 bits long. Unfortunatelly, on 64 bits hosts, this won't be the case and the kernel load address then is over 4 GB. Then, when computing the initrd_offset, the code always concludes that there's not enough RAM available to load it at the top of the kernel. I found 2 ways of fixing the bug, but I don't know which one is correct in Mips execution environment. The first patch is to make the VIRT_TO_PHYS_ADDEND negative, thus translating the kernel virtual address from 0x8000nnnn to the physical one 0x0000nnnn (instead of 0x10000nnnn, when running on 64 bits hosts). The second solution would be to explicitelly always cast the kernel_high value to 32 bits. As I do not really know if some Mips target specific constraints would make one of the other solution prefered, I'd better let the specialist choose !
The good news is that, once this issue is fixed, the Mips test images run with the reverse-endian softmmu patch applied. -- J. Mayer <[EMAIL PROTECTED]> Never organized