Hi

Am 12.10.22 um 15:12 schrieb Arnd Bergmann:

On Wed, Oct 12, 2022, at 2:00 PM, Thomas Zimmermann wrote:

quoted

Could well be. But ofdrm intents to replace offb and this test has
worked well in offb for almost 15 yrs. If there are bug reports, I'm
happy to take patches, but until then I see no reason to change it.

I wouldn't change the code in offb unless a user reports a bug,
but I don't see a point in adding the same mistake to ofdrm if we
know it can't work on real hardware.

As I said, this has worked with offb and apparently on real hardware. 
For all I know, ATI hardware (before it became AMD) was used in PPC 
Macintoshs and assumed big-endian access on those machines.

I tried to find out where this is configured in qemu, but it seems
to depend on the framebuffer backend there: most are always little-endian,
ati/bochs/vga-pci/virtio-vga are configurable from the guest through
some register setting, but vga.c picks a default from the
'TARGET_WORDS_BIGENDIAN' macro, which I think is set differently
between qemu-system-ppc64le and qemu-system-ppc64.

If you are using the framebuffer code from vga.c, I would guess that
that you can run a big-endian kernel with qemu-system-ppc64,
or a little-endian kernel with qemu-system-ppc64le and get the
correct colors, while running a little-endian kernel with
qemu-system-ppc64 and vga.c, or using a different framebuffer
emulation on a big-endian kernel would give you the wrong colors.

If qemu doesn't give us the necessary DT property, it's a qemu bug. In 
in the absence of the property, picking the kernel's endianess is a 
sensible choice.

Best regards
Thomas

Which combinations did you actually test?

      Arnd

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev