On 1 March 2013 12:07, Fabien Chouteau <chout...@adacore.com> wrote: > On 03/01/2013 12:32 PM, Peter Maydell wrote: >> I think you're going to have to run some tests on the actual >> hardware to find out what it really does. Specifically, what >> are the values of SCTLR.IE, SCTLR.EE and CPSR.E when you think >> you're in big-endian mode?
> SCTLR.IE and SCTLR.EE are both set to 1 at reset and the values > cannot be changed. OK, that makes sense. I think it's also a reasonable thing for qemu's qemu-system-armeb model to present to the guest. Have you changed QEMU to report IE and EE (and CPSR.E) as always-1, or does your guest code just not look at them? > BTW, our run-time works both on QEMU and a real-board, that's also why > I'm confident that there are no endianness issue. The trouble is that you can have two separate bits of QEMU which both model the endianness incorrectly but in such a way that the two errors cancel each other out and the guest-visible behaviour looks correct... -- PMM
