Re: [Qemu-devel] [PATCH 4/4] target-arm: always set endian bits in big-endian mode

[Peter Maydell]

On 5 March 2013 23:07, Fabien Chouteau <address@hidden> wrote:
> On 03/05/2013 01:33 PM, Peter Maydell wrote:
>> 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.

True, but since we only support fixed endian cores we can just
have the CPU type set the reset value according to TARGET_WORDS_BIGENDIAN.
(Having boards fiddle with CPU config is not something we have
the qemu infrastructure for just yet.)

>> 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?

Because the only way to tell the difference between BE32 and BE8
is if you have two views of the data in memory, so you can tell
whether it's the byte accesses that are getting flipped or the
word accesses. Those two views could be:
 * via the Iside vs the Dside [but with IE enabled both get flipped]
 * by switching the core between BE and LE [you can't on R profile]
 * by using another core which is LE [there is none]
 * by looking at what peripheral devices see when you write words
   to them [the legacy code is assumed not to have direct dev access,
   or you could design your board so it looks like what the code
   expects]

>>> 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.

Well, the current behaviour is nothing at all since we don't
actually build it. In enabling it, you have to ensure that
the behaviour you enable makes sense.

-- PMM