Re: Custom ARM Board: Setting BE32 endianness

[Peter Maydell]

On Mon, 16 Mar 2020 at 10:34, Tanay Gupta <address@hidden> wrote:
> I used the loader device to set the pc, and it works.
>
> I also set the breakpoint in gdb on arm_cpu_realizefn, and the function is 
> setting the SCTLR_B flag like it should.
>
> After that, I used "-d in_asm" to log target disassembly, as you suggested. 
> The output in that log still shows the little endian interpretation of the 
> code. Is there anything else that I need to change? What can I do to debug 
> this?

Hmm. Is the emulation also behaving as if it's reading the
instructions wrongly, or is it just the disassembler that's
getting it wrong? (All these loads are different code paths,
so you can't assume that because one of them is one way around
the others are all correct.)

> Also, I've tried to change the endianness from the inside, by running a 
> "correction" program, and then jumping to the actual start point. "setend be" 
> and setting the CP15 register, both don't work. Are these methods not 
> supported?

I think you're confused here. "SETEND BE" is for BE8 big-endian
(which is the byte-invariant endianness handling for ARMv6 and
later), not BE32 (which is the word-invariant endianness handling
for ARMv6 and earlier).

Anyway, I think you're now in "need to debug QEMU" territory.
Nobody really uses this BE32 support, so I'm not surprised that
it's broken. As I said, my guess is that the issue is in how
the code is loaded into memory -- because BE32 is word-invariant,
you can't just load a binary file in byte-by-byte, because the
order of bytes in the underlying RAM has to be 32107654...

thanks
-- PMM