| Message ID | 1362158507-19310-5-git-send-email-chouteau@adacore.com |
|---|---|
| State | New |
| Headers | show |
> +#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
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,
> 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.
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,
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
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,
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
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,
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 */
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(+)