On 03/05/2013 01:33 PM, Peter Maydell wrote: > On 5 March 2013 18:56, Fabien Chouteau <chout...@adacore.com> wrote: >> On 03/04/2013 02:24 PM, Paul Brook wrote: >>>> On 03/01/2013 09:58 PM, Paul Brook wrote: >>>>> >>>>> This is wrong for all the CPUs QEMU crrently supports. SCTLR.IE is >>>>> defined to be zero. >>>> >>>> Again I'd like to have more information. Why is it wrong to set IE when >>>> we are in big-endian? > > It's wrong because you're setting IE for all v6 and v7 cores > in bigendian mode, when IE is only valid for R profile cores. >
Right, that's something I missed, SCTLR.IE is for R profiles only. > To correctly emulate a bigendian v6/v7 non-R profile core you would > need to arrange for the bswap_code flag to be set (which then causes > us to re-byte-swap code accesses to undo the endianness flip that > TARGET_WORDS_BIGENDIAN would otherwise give us). I suspect that what > you actually want is: > * sctlr bit IE is read-only, and set to 0 or 1 according to the > sctlr reset value defined for the CPU type It's actually more of a board setting. > * the bswap_code flag is set to 1 if TARGET_WORDS_BIGENDIAN && > SCTLR.IE == 0) > but that's just off the top of my head so might be wrong. > If it's that simple (i.e. set the bswap_code flag) I can try to do it, otherwise I'll just pass. My main interest here is cortex-R4. >> Is it possible to have both data and instruction in BE8? > > Yes; this is precisely what SCTLR.IE enables. OK good, that makes sense. >> Since it is a legacy support, I would imagine that SCTLR.IE means BE32 >> access for instructions. Is that right? > > No. It is supporting legacy code; it is not itself a legacy feature. > IE + BE8 (data) looks very very similar to BE32 from the point of view > of code on the CPU; it is code that expects a BE32 kind of view of > the world that is the legacy code being supported. > That's what I fail to understand, why IE + BE8 (data) gives a legacy BE32 view? >>> All the v7 cores QEMU currently supports[1] only implement BE8 mode. The IE >>> bit is reserved and most be zero. Usermode emulation implements both, but >>> the >>> privileged cp15 registers can safely be ignored there. >>> >> >> When I build my qemu-system-armeb, in what mode is it (BE8, BE32, data >> and/or instruction in big-endian)? > > It will effectively behave kind of like a BE32 (word invariant, swaps > both code and data) system; you won't be able to tell the difference > between that and the BE8+SCTLR.IE system you're trying to emulate, > except for accesses to word-width registers on device models. > That needs thought to make sure the changes are actually coherent. > So the current behavior of qemu-system-armeb is BE8+IE, therefore not compatible with any non R profile ARMv6/7. Thanks, -- Fabien Chouteau