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

[Fabien Chouteau]

On 03/05/2013 01:33 PM, Peter Maydell wrote:
> 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:
>>>>>
>>>>> 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