On 27 April 2014 16:28, Paolo Bonzini <pbonz...@redhat.com> wrote: > Il 22/04/2014 09:01, Peter Maydell ha scritto: >> Note that SCTLR.EE also sets the endianness for loads done >> for translation table walks and so on.
> I guess also v7m_push and v7m_pop. Well, not really. v7M handles endianness differently to A and R profiles. For v7M there is only one endianness setting, and it lives in AIRCR.ENDIANNESS (a memory mapped register which we implement in hw/intc/armv7m_nvic.c). This sets how all data accesses work; in that sense it corresponds most closely to the A and R profile CPSR.E. (There's no CPSR in M profile; the xPSR which is similar doesn't have an E bit.) The v7m_push and _pop and also the ldl_phys doing the vector table load in arm_v7m_cpu_do_interrupt() all honour AIRCR.ENDIANNESS. There is no equivalent of an SCTLR.EE. Since v7M always has an MPU, not an MMU, there's no translation table walking: we never do a memory access for virt-to-phys lookups. The slightly awkward bit about endianness for v7M is that it depends on which bit of the memory space you are accessing: the byteswapping happens only for memory transactions which are about to leave the CPU, so accesses to bits of the address space which are really implemented as part of the CPU itself (the "system control space", which is largely registers in our armv7m_nvic object) are always little endian. I think you could reasonably just leave the M-profile specific accesses in helper.c alone and we'll stick with the current "M profile cores don't support being big endian" until somebody comes along who cares... That means the only _phys accesses you need to change are the ones in get_phys_addr and the functions it calls. thanks -- PMM
