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

[Fabien Chouteau <chouteau@adacore.com>]

On 03/06/2013 12:08 AM, Peter Maydell wrote:
> On 5 March 2013 23:07, Fabien Chouteau <chouteau@adacore.com> wrote:
>> On 03/05/2013 01:33 PM, Peter Maydell wrote:
>>> 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]

Alright I get it. It looks similar to legacy BE32 because both
instruction and data use the same byte order. From the code point of
view it's the same, but in fact the data in RAM are different.

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

It makes sense for me, as I have the same executable working on the real
board (TMS570L31, Cortex-R4F BE-8 + IE) and on qemu-system-armeb. In the
3 devices I implemented (Memory region in DEVICE_NATIVE_ENDIAN), I had
no byte ordering problems.

Regards,

-- 
Fabien Chouteau