[Qemu-devel] [PATCH 0/4] ARM: Misc ARM big-endian bug fixes

[Qemu-devel] [PATCH 0/4] ARM: Misc ARM big-endian bug fixes

[Fabien Chouteau]

Fabien Chouteau (4):
  QAPI: Add ARMEB target-type
  Add default config for armeb-softmmu
  target-arm: Fix VFP register byte order in GDB remote
  target-arm: always set endian bits in big-endian mode

 default-configs/armeb-softmmu.mak |    3 +++
 qapi-schema.json                  |    9 +++++----
 target-arm/cpu.c                  |   11 +++++++++++
 target-arm/helper.c               |   31 ++++++++++++++++++++++++-------
 4 files changed, 43 insertions(+), 11 deletions(-)
 create mode 100644 default-configs/armeb-softmmu.mak

-- 
1.7.9.5

[Qemu-devel] [PATCH 1/4] QAPI: Add ARMEB target-type

[Fabien Chouteau]

Signed-off-by: Fabien Chouteau <chouteau@adacore.com>
---
 qapi-schema.json |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index 28b070f..0615715 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2993,10 +2993,11 @@
 # Since: 1.2.0
 ##
 { 'enum': 'TargetType',
-  'data': [ 'alpha', 'arm', 'cris', 'i386', 'lm32', 'm68k', 'microblazeel',
-            'microblaze', 'mips64el', 'mips64', 'mipsel', 'mips', 'or32',
-            'ppc64', 'ppcemb', 'ppc', 's390x', 'sh4eb', 'sh4', 'sparc64',
-            'sparc', 'unicore32', 'x86_64', 'xtensaeb', 'xtensa' ] }
+  'data': [ 'alpha', 'arm', 'armeb','cris', 'i386', 'lm32', 'm68k',
+            'microblazeel', 'microblaze', 'mips64el', 'mips64', 'mipsel',
+            'mips', 'or32', 'ppc64', 'ppcemb', 'ppc', 's390x', 'sh4eb',
+            'sh4', 'sparc64', 'sparc', 'unicore32', 'x86_64', 'xtensaeb',
+            'xtensa' ] }
 
 ##
 # @TargetInfo:
-- 
1.7.9.5

[Qemu-devel] [PATCH 2/4] Add default config for armeb-softmmu

[Fabien Chouteau]

Just create one that includes arm-softmmu.mak.

Signed-off-by: Fabien Chouteau <chouteau@adacore.com>
---
 default-configs/armeb-softmmu.mak |    3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 default-configs/armeb-softmmu.mak

diff --git a/default-configs/armeb-softmmu.mak b/default-configs/armeb-softmmu.mak
new file mode 100644
index 0000000..17670c0
--- /dev/null
+++ b/default-configs/armeb-softmmu.mak
@@ -0,0 +1,3 @@
+# Default configuration for armeb-softmmu
+
+include arm-softmmu.mak
-- 
1.7.9.5

[Qemu-devel] [PATCH 3/4] target-arm: Fix VFP register byte order in GDB remote

[Fabien Chouteau]

>From GDB Remote Serial Protocol doc:

"The bytes with the register are transmitted in target byte order."

Signed-off-by: Fabien Chouteau <chouteau@adacore.com>
---
 target-arm/helper.c |   13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index e97e1a5..75ee0dc 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -16,18 +16,17 @@ static int vfp_gdb_get_reg(CPUARMState *env, uint8_t *buf, int reg)
 {
     int nregs;
 
-    /* VFP data registers are always little-endian.  */
     nregs = arm_feature(env, ARM_FEATURE_VFP3) ? 32 : 16;
     if (reg < nregs) {
-        stfq_le_p(buf, env->vfp.regs[reg]);
+        stfq_p(buf, env->vfp.regs[reg]);
         return 8;
     }
     if (arm_feature(env, ARM_FEATURE_NEON)) {
         /* Aliases for Q regs.  */
         nregs += 16;
         if (reg < nregs) {
-            stfq_le_p(buf, env->vfp.regs[(reg - 32) * 2]);
-            stfq_le_p(buf + 8, env->vfp.regs[(reg - 32) * 2 + 1]);
+            stfq_p(buf, env->vfp.regs[(reg - 32) * 2]);
+            stfq_p(buf + 8, env->vfp.regs[(reg - 32) * 2 + 1]);
             return 16;
         }
     }
@@ -45,14 +44,14 @@ static int vfp_gdb_set_reg(CPUARMState *env, uint8_t *buf, int reg)
 
     nregs = arm_feature(env, ARM_FEATURE_VFP3) ? 32 : 16;
     if (reg < nregs) {
-        env->vfp.regs[reg] = ldfq_le_p(buf);
+        env->vfp.regs[reg] = ldfq_p(buf);
         return 8;
     }
     if (arm_feature(env, ARM_FEATURE_NEON)) {
         nregs += 16;
         if (reg < nregs) {
-            env->vfp.regs[(reg - 32) * 2] = ldfq_le_p(buf);
-            env->vfp.regs[(reg - 32) * 2 + 1] = ldfq_le_p(buf + 8);
+            env->vfp.regs[(reg - 32) * 2] = ldfq_p(buf);
+            env->vfp.regs[(reg - 32) * 2 + 1] = ldfq_p(buf + 8);
             return 16;
         }
     }
-- 
1.7.9.5

Re: [Qemu-devel] [PATCH 3/4] target-arm: Fix VFP register byte order in GDB remote

[Paul Brook]

> From GDB Remote Serial Protocol doc:
> 
> "The bytes with the register are transmitted in target byte order."

>          /* Aliases for Q regs.  */
>          nregs += 16;
>          if (reg < nregs) {
> 
> -            stfq_le_p(buf, env->vfp.regs[(reg - 32) * 2]);
> -            stfq_le_p(buf + 8, env->vfp.regs[(reg - 32) * 2 + 1]);
> +            stfq_p(buf, env->vfp.regs[(reg - 32) * 2]);
> +            stfq_p(buf + 8, env->vfp.regs[(reg - 32) * 2 + 1]);

This is wrong. You're still using little-endian ordering of words.

Paul

Re: [Qemu-devel] [PATCH 3/4] target-arm: Fix VFP register byte order in GDB remote

[Fabien Chouteau]

On 03/01/2013 09:51 PM, Paul Brook wrote:
>> From GDB Remote Serial Protocol doc:
>>
>> "The bytes with the register are transmitted in target byte order."
> 
>>          /* Aliases for Q regs.  */
>>          nregs += 16;
>>          if (reg < nregs) {
>>
>> -            stfq_le_p(buf, env->vfp.regs[(reg - 32) * 2]);
>> -            stfq_le_p(buf + 8, env->vfp.regs[(reg - 32) * 2 + 1]);
>> +            stfq_p(buf, env->vfp.regs[(reg - 32) * 2]);
>> +            stfq_p(buf + 8, env->vfp.regs[(reg - 32) * 2 + 1]);
> 
> This is wrong. You're still using little-endian ordering of words.
> 

Can you explain a little bit further? If I'm in big-endian mode, stfq_p() will be stfq_be_p(), right?

Thanks,

-- 
Fabien Chouteau

Re: [Qemu-devel] [PATCH 3/4] target-arm: Fix VFP register byte order in GDB remote

[Paul Brook]

> >> "The bytes with the register are transmitted in target byte order."
> >> 
> >>          /* Aliases for Q regs.  */
> >>          nregs += 16;
> >>          if (reg < nregs) {
> >> 
> >> -            stfq_le_p(buf, env->vfp.regs[(reg - 32) * 2]);
> >> -            stfq_le_p(buf + 8, env->vfp.regs[(reg - 32) * 2 + 1]);
> >> +            stfq_p(buf, env->vfp.regs[(reg - 32) * 2]);
> >> +            stfq_p(buf + 8, env->vfp.regs[(reg - 32) * 2 + 1]);
> > 
> > This is wrong. You're still using little-endian ordering of words.
> 
> Can you explain a little bit further? If I'm in big-endian mode, stfq_p()
> will be stfq_be_p(), right?

Because we're actually storing two halves of a 128-bit value.   You still 
store the least significant half first.

Paul

Re: [Qemu-devel] [PATCH 3/4] target-arm: Fix VFP register byte order in GDB remote

[Fabien Chouteau]

On 03/04/2013 02:30 PM, Paul Brook wrote:
>>>> "The bytes with the register are transmitted in target byte order."
>>>>
>>>>          /* Aliases for Q regs.  */
>>>>          nregs += 16;
>>>>          if (reg < nregs) {
>>>>
>>>> -            stfq_le_p(buf, env->vfp.regs[(reg - 32) * 2]);
>>>> -            stfq_le_p(buf + 8, env->vfp.regs[(reg - 32) * 2 + 1]);
>>>> +            stfq_p(buf, env->vfp.regs[(reg - 32) * 2]);
>>>> +            stfq_p(buf + 8, env->vfp.regs[(reg - 32) * 2 + 1]);
>>>
>>> This is wrong. You're still using little-endian ordering of words.
>>
>> Can you explain a little bit further? If I'm in big-endian mode, stfq_p()
>> will be stfq_be_p(), right?
> 
> Because we're actually storing two halves of a 128-bit value.   You still 
> store the least significant half first.
> 

Right, I'm sorry I didn't see you comment was only about the Q registers.
What would be the solution then?

#ifdef TARGET_WORDS_BIGENDIAN
            stfq_p(buf, env->vfp.regs[(reg - 32) * 2 + 1]);
            stfq_p(buf + 8, env->vfp.regs[(reg - 32) * 2]);
#else
            stfq_p(buf, env->vfp.regs[(reg - 32) * 2]);
            stfq_p(buf + 8, env->vfp.regs[(reg - 32) * 2 + 1]);
#endif  /* TARGET_WORDS_BIGENDIAN */

Regards,

-- 
Fabien Chouteau

Re: [Qemu-devel] [PATCH 3/4] target-arm: Fix VFP register byte order in GDB remote

[Fabien Chouteau]

On 03/05/2013 12:34 AM, Paul Brook wrote:
>>> Because we're actually storing two halves of a 128-bit value.   You still
>>> store the least significant half first.
>>
>> Right, I'm sorry I didn't see you comment was only about the Q registers.
>> What would be the solution then?
>>
>> #ifdef TARGET_WORDS_BIGENDIAN
>>             stfq_p(buf, env->vfp.regs[(reg - 32) * 2 + 1]);
>>             stfq_p(buf + 8, env->vfp.regs[(reg - 32) * 2]);
>> #else
>>             stfq_p(buf, env->vfp.regs[(reg - 32) * 2]);
>>             stfq_p(buf + 8, env->vfp.regs[(reg - 32) * 2 + 1]);
>> #endif  /* TARGET_WORDS_BIGENDIAN */
> 
> Yes, something like that.
> 

Alright, I'll do that for V2.

Thanks,

-- 
Fabien Chouteau

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

[Fabien Chouteau]

CPSR.E, SCTLR.EE and SCTLR.IE

Signed-off-by: Fabien Chouteau <chouteau@adacore.com>
---
 target-arm/cpu.c    |   11 +++++++++++
 target-arm/helper.c |   18 ++++++++++++++++++
 2 files changed, 29 insertions(+)

diff --git a/target-arm/cpu.c b/target-arm/cpu.c
index 5dfcb74..354843e 100644
--- a/target-arm/cpu.c
+++ b/target-arm/cpu.c
@@ -112,6 +112,17 @@ static void arm_cpu_reset(CPUState *s)
     }
     env->vfp.xregs[ARM_VFP_FPEXC] = 0;
 #endif
+
+#ifdef TARGET_WORDS_BIGENDIAN
+    if (arm_feature(env, ARM_FEATURE_V6) || arm_feature(env, ARM_FEATURE_V7)) {
+        /* Set IE and EE bits for big-endian */
+        env->cp15.c1_sys |= (1 << 31) | (1 << 25);
+
+        /* Set E bit for big-endian */
+        env->uncached_cpsr |= CPSR_E;
+    }
+#endif
+
     set_flush_to_zero(1, &env->vfp.standard_fp_status);
     set_flush_inputs_to_zero(1, &env->vfp.standard_fp_status);
     set_default_nan_mode(1, &env->vfp.standard_fp_status);
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 75ee0dc..e539186 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -1017,6 +1017,15 @@ static const ARMCPRegInfo lpae_cp_reginfo[] = {
 static int sctlr_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t value)
 {
     env->cp15.c1_sys = value;
+
+#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
+
     /* ??? Lots of these bits are not implemented.  */
     /* This may enable/disable the MMU, so do a TLB flush.  */
     tlb_flush(env, 1);
@@ -1509,6 +1518,15 @@ void cpsr_write(CPUARMState *env, uint32_t val, uint32_t mask)
     }
     mask &= ~CACHED_CPSR_BITS;
     env->uncached_cpsr = (env->uncached_cpsr & ~mask) | (val & mask);
+
+#ifdef TARGET_WORDS_BIGENDIAN
+    if (arm_feature(env, ARM_FEATURE_V6)
+        || arm_feature(env, ARM_FEATURE_V7)) {
+        /* E bit stays set for big-endian */
+        env->uncached_cpsr |= CPSR_E;
+    }
+#endif
+
 }
 
 /* Sign/zero extend */
-- 
1.7.9.5

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

[Paul Brook]

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

Paul

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

[Fabien Chouteau]

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?

Thanks,

-- 
Fabien Chouteau

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

[Paul Brook]

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

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.

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.

Paul

[1] Except maybe the M profile cores, but they use a different system model 
anyway.

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

[Fabien Chouteau]

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

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?

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

Thanks,

-- 
Fabien Chouteau

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 <chouteau@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

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 <chouteau@adacore.com> 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

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 <chouteau@adacore.com> 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

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

[Fabien Chouteau]

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