On 03/01/2013 11:40 AM, Peter Maydell wrote: > On 1 March 2013 10:13, Fabien Chouteau <chout...@adacore.com> wrote: >> On 02/28/2013 07:42 PM, Peter Maydell wrote: >>> How are you handling the SCTLR IE and EE bits? >> >> I did nothing, as far as I know it's not possible to switch endianness >> in QEMU. > > Yes, that's why I'm wondering how you're handling them. > >> TMS570 are configured for big-endian only, so this is not a >> problem for me. > > Do you mean they are BE8 for load/stores always (ie SCTLR.EE is > 1, or that they are both BE8 for load/stores and also for > instruction fetches (ie that SCTLR.IE is also 1) ? > > Endianness in ARM is not as simple as a single flag saying > "big or little"... >
I'm new to this ARM architecture so I will just quote the doc. TMS570LS31x/21x Technical Reference Manual: "The TMS570 family is based on the ARM® CortexTM-R4F core. ARM has designed this core to be used in big-endian and little-endian systems. For the TI TMS570 family, the endianness has been configured to BE32." >>>>> Are you planning to do the v7 PMSA support? >>> >>>> I don't know what that is, but I'll take a look :) >>> >>> It's the Memory Protection Unit -- QEMU currently only has the >>> old v5 MPU, and register_cpu_regs_for_features() will assert >>> if your CPU is v6 or v7 and has the FEATURE_MPU bit set. >>> If you're putting in system emulation for an R4 then you must >>> implement this (and I'm surprised you've managed to get anything >>> significant to run without it). >> >> The programs I run don't need MPU, so for the moment I have no plan to >> implement PMSA. > > However from an upstream point of view something that claims > to be an R4 but doesn't actually implement the MPU is not > terribly useful... > Well it is useful for us. Our safety-critical small-foot-print run-time doesn't need MPU. Look for Ravenscar profile in Ada. Regards, -- Fabien Chouteau