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

[Peter Maydell]

On 5 March 2013 18:56, Fabien Chouteau <address@hidden> 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