Peter Maydell <peter.mayd...@linaro.org> writes: > On 8 August 2013 17:07, Anthony Liguori <anth...@codemonkey.ws> wrote: >> It's the same processor. It still starts executing big endian >> instructions. A magic register value is tweaked and loads/stores are >> swapped. > > I dunno about PPC, but for ARM generally the boot-up state is > controlled by config signals which a SoC or board can hardwire, > so you can have a SoC which is configured to start in big-endian > mode. > >> CPU data structures are still read as big endian though. > > Do you have an example of what you mean by "CPU data structure"?
MMU tlb hash table. If you grep ldl target-ppc/* you'll see that there are only a few cases where bswap occurs. >> The distinction is important in QEMU. ppc64 is still >> TARGET_WORDS_BIGENDIAN. > > Ideally TARGET_WORDS_BIGENDIAN would go away -- it is forcing > at compile time a setting which is actually a runtime one, > and a lot of the weirdness here flows from that. > >> We still want most stl_phys to treat integers >> as big endian. > > Any stl_phys() should [in an ideal design] be tied to a > "bus master" which has its own idea of which endianness > it is. That is, an stl_phys() for a DMA controller model > ought to use the endianness programmed for the DMA controller, > not whatever the CPU happens to be using. We have the DMA API that attempts to do this but maybe we need to generalize it a bit more... I think it's pretty true that we need a context and that the context for, say instruction fetch, is distinct from the context for load/store instructions. Regards, Anthony Liguori > > -- PMM
