On Wed, Oct 12, 2022, at 10:27 AM, Thomas Zimmermann wrote:

Am 12.10.22 um 09:44 schrieb Arnd Bergmann:

quoted

On Wed, Oct 12, 2022, at 9:40 AM, Thomas Zimmermann wrote:

quoted

Am 12.10.22 um 09:17 schrieb Arnd Bergmann:

quoted

On Wed, Oct 12, 2022, at 8:46 AM, Thomas Zimmermann wrote:

quoted

Does qemu mark the device has having a particular endianess then, or
does it switch the layout of the framebuffer to match what the CPU
does?

The latter. On neither architecture does qemu expose this flag. The
default endianess corresponds to the host.

"host" as in the machine that qemu runs on, or the machine that is
being emulated? I suppose it would be broken either way, but in the
latter case, we could get away with detecting that the machine is
running under qemu.

Sorry, my mistake. I meant "guest": the endianess of the framebuffer 
corresponds to the endianess of the emulated machine.  Given that many 
graphics cards support LE and BE modes, I assume that this behavior 
mimics real-hardware systems.

Not really: While the hardware may be able to switch between
the modes, something has to actively set some hardware registers up
that way, but the offb/ofdrm driver has no interface for interacting
with that register, and the bootloader or firmware code that knows
about the register has no information about what kernel it will
eventually run. This is a bit architecture dependent, as e.g. on
MIPS, a bi-endian hardware platform has to run a bootloader with the
same endianness as the kernel, but on arm and powerpc the bootloader
is usually fixed and the kernel switches to its configured endianness
in the first few instructions after it gets entered.

     Arnd