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: >>>>> +#ifdef TARGET_WORDS_BIGENDIAN >>>>> + if (arm_feature(env, ARM_FEATURE_V6) >>>>> + || arm_feature(env, ARM_FEATURE_V7)) { >>>>> + /* IE and EE bits stay set for big-endian */ >>>>> + env->cp15.c1_sys |= (1 << 31) | (1 << 25); >>>>> + } >>>>> +#endif >>>> >>>> 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. 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 * 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. >> The ARM architecture defines two big-endian modes. In BE8 mode only data >> accesses big-endian, code fetches are still little-endian. In BE32 mode both >> code and data are big-endian. In theory a fourth mode (big-endian code, >> little-endian data) exists, though I've never seen that used. > I'm a bit lost. You say that BE32 means data and instruction in > big-endian and BE8 only data in big-endian. And this is confirmed by > Peter's article : > (http://translatedcode.wordpress.com/2012/04/02/this-end-up/). > > For me there's two different things: > - big-endian kind: BE32 or BE8 > - endianness of data/instruction > > Is it possible to have both data and instruction in BE8? Yes; this is precisely what SCTLR.IE enables. > Now in the ARMv7 ARM chapter A3.3.2: > > "Instruction endianness static configuration, ARMv7-R only > > To provide support for legacy big-endian object code, the ARMv7-R > profile supports optional byte order reversal hardware as a static > option from reset. The ARMv7-R profile includes a read-only bit in the > CP15 Control Register, SCTLR.IE, bit [31]. For more information, see c1, > System Control Register (SCTLR) on page B4-45." > > 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. >> 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. -- PMM