On Tue, 13 Dec 2022 at 18:11, BALATON Zoltan <bala...@eik.bme.hu> wrote: > I can't remember the details but I think I've had no tswap in sam460ex > first but that did not work and had to add it but I've probably looked at > other examples and did not really understand why this was needed. I tested > on x86_64 so not matching host. The board firmware has some reference to > this magic value in: > > qemu/roms/u-boot-sam460ex/arch/powerpc/lib/bootm.c::boot_jump_linux() > > I don't know what it does with it but I think kernel expects it in big > endian and what we put there should match what U-Boor does (if this is > actually used on sam460ex which I'm not sure about).
Thanks. That u-boot code uses the same value for EPAPR_MAGIC as we do (0x45504150), and it puts it in r6 (by doing a function call), and being native code the register will get that exact value, not a byte-swapped version. So to match that we should delete the tswap32() that we currently have in our hw/ppc/sam460ex.c code. My guess is that (as with the virtex kernel in our test suite) the Debian/Ubuntu kernel you tested with worked because it doesn't actually check the value of the magic number, it only cares that it gets the FDT address in r3. The giveaway that the tswap32() is wrong is that we're only swapping one of the 4 things we pass to the guest code in registers -- either we should need to swap all of them, or none (unless our magic number value was pre-byteswapped, which it isn't). -- PMM
