On Tue, Jun 7, 2022 at 11:47 AM Stafford Horne <sho...@gmail.com> wrote: > On Tue, Jun 07, 2022 at 10:42:08AM +0200, Arnd Bergmann wrote:
> > 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/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 That is much younger than Laurent made it appear, from his earlier explanations I expected this to have shipped a long time ago and been used in other OSs to the point where it cannot be fixed. > 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. Not really, the definition of DEVICE_NATIVE_ENDIAN in qemu is much less well-defined than that as I understand, it is just whatever the person adding support for that CPU thought would be the right one. A lot of CPUs can run either big-endian or little-endian code, and e.g. on ARM, qemu DEVICE_NATIVE_ENDIAN is just always little-endian, regardless of what the CPU runs, while I think on MIPS it would be whatever the CPU is actually executing. Arnd