On Tue, Jun 07, 2022 at 10:42:08AM +0200, Arnd Bergmann wrote: > On Tue, Jun 7, 2022 at 10:11 AM Geert Uytterhoeven <ge...@linux-m68k.org> > wrote: > > On Sun, Jun 5, 2022 at 9:32 AM Stafford Horne <sho...@gmail.com> wrote: > > > On Sun, Jun 05, 2022 at 10:58:14AM +0900, Stafford Horne wrote: > > > It might be a good idea to revisit the qemu implementation and make > > > sure that the extra byteswap is only inserted on m68k and not on > > > other targets, but hopefully there are no new targets based on > > > goldfish > > > anymore and we don't need to care. > > > > > > So, it seems that in addition to my patch we would need something in m68k > > > to > > > switch it back to 'native' (big) endian? > > > > > > Looking at the m68k kernel/qemu interface I see: > > > > > > Pre 5.19: > > > (data) <-- kernel(readl / little) <-- m68k qemu (native / big) - > > > RTC/PIC > > > (data) <-- kernel(__raw_readl / big) <-- m68k qemu (native / big) - TTY > > > > > > 5.19: > > > (data) <-- kernel(gf_ioread32 / big) <-- m68k qemu (native / big) - all > > > > > > The new fixes to add gf_ioread32/gf_iowrite32 fix this for goldfish and > > > m68k. > > > This wouldn't have been an issue for little-endian platforms where > > > readl/writel > > > were originally used. > > > > > > Why can't m68k switch to little-endian in qemu and the kernel? The m68k > > > virt > > > platform is not that old, 1 year? Are there a lot of users that this > > > would be a big > > > problem? > > > > > > [1] > > > https://lore.kernel.org/lkml/CAK8P3a1oN8NrUjkh2X8jHQbyz42Xo6GSa=5n0gd6vqcxrjm...@mail.gmail.com/ > > Goldfish is a very old platform, as far as I know only the kernel port is new. > I don't know when qemu started shipping goldfish, but changing it now would > surely break compatibility with whatever OS the port was originally made for.
Hi Arnd, As far as I can tell goldfish in qemu is not very old. There are 3 devices, 2 were added for the m68k virt machine, and 1 for riscv virt. $ git lo -- hw/rtc/goldfish_rtc.c 2022-01-28 2f93d8b04a Peter Maydell rtc: Move RTC function prototypes to their own header 2021-03-04 6b9409ba5f Laurent Vivier goldfish_rtc: re-arm the alarm after migration 2020-10-13 16b66c5626 Laurent Vivier goldfish_rtc: change MemoryRegionOps endianness to DEVICE_NATIVE_ENDIAN 2020-07-22 8380b3a453 Jessica Clarke goldfish_rtc: Fix non-atomic read behaviour of TIME_LOW/TIME_HIGH 2020-02-10 9a5b40b842 Anup Patel hw: rtc: Add Goldfish RTC device $ git lo -- hw/char/goldfish_tty.c 2021-11-09 65b4c8c759 Philippe Mathieu-Daudé hw/m68k: Fix typo in SPDX tag 2021-03-15 8c6df16ff6 Laurent Vivier hw/char: add goldfish-tty $ git lo -- hw/intc/goldfish_pic.c 2021-11-09 65b4c8c759 Philippe Mathieu-Daudé hw/m68k: Fix typo in SPDX tag 2021-03-15 8785559390 Laurent Vivier hw/intc: add goldfish-pic The mips/loongson3_virt machine now also uses the goldfish_rtc. The problem with the goldfish device models is that they were defined as DEVICE_NATIVE_ENDIAN. $ grep endianness hw/*/goldfish* hw/char/goldfish_tty.c: .endianness = DEVICE_NATIVE_ENDIAN, hw/intc/goldfish_pic.c: .endianness = DEVICE_NATIVE_ENDIAN, hw/rtc/goldfish_rtc.c: .endianness = DEVICE_NATIVE_ENDIAN, RISC-V is little-endian so when it was added there was no problem with running linux goldfish drivers. MIPS Longson3, added last year, seems to be running as little-endian well, I understand MIPS can support both big and little endian. However according to this all Loongson cores are little-endian. https://en.wikipedia.org/wiki/Loongson As I understand when endianness of the devices in qemu are defined as DEVICE_NATIVE_ENDIAN the device endian takes the endian of the target CPU. This means that MIPS Loongson3 and RISC-V are affectively running as little-endian which is what would be expected. So it appears to me that in qemu that m68k is the only architecture that is providing goldfish devices on a big-endian architecture. Also, as far as I know Linux is the only OS that was updated to cater for that. If there are other firmware/bootloaders that expect that maybe they could be updated too? -Stafford