From: Stafford Horne <shorne@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Joel Stanley <joel@jms.id.au>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
Openrisc <openrisc@lists.librecores.org>,
QEMU Development <qemu-devel@nongnu.org>
Subject: Re: [RFC PATCH 3/3] hw/openrisc: Add the OpenRISC virtual machine
Date: Tue, 7 Jun 2022 18:47:17 +0900 [thread overview]
Message-ID: <Yp8epZsizfKMEVZV@antec> (raw)
In-Reply-To: <CAK8P3a3Vpn02uDe3rdXSNXANY=u4ZM+wjm-qqszTXzjOKkAeEg@mail.gmail.com>
On Tue, Jun 07, 2022 at 10:42:08AM +0200, Arnd Bergmann wrote:
> On Tue, Jun 7, 2022 at 10:11 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Sun, Jun 5, 2022 at 9:32 AM Stafford Horne <shorne@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=5n0gD6vQcXRjmq1Q@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
next prev parent reply other threads:[~2022-06-07 10:11 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-27 17:27 [RFC PATCH 0/3] OpenRISC Semihosting and Virt Stafford Horne
2022-05-27 17:27 ` [RFC PATCH 1/3] target/openrisc: Add basic support for semihosting Stafford Horne
2022-06-02 15:39 ` Richard Henderson
2022-06-05 0:57 ` Stafford Horne
2022-06-05 14:36 ` Richard Henderson
2022-05-27 17:27 ` [RFC PATCH 2/3] hw/openrisc: Split re-usable boot time apis out to boot.c Stafford Horne
2022-06-02 15:40 ` Richard Henderson
2022-05-27 17:27 ` [RFC PATCH 3/3] hw/openrisc: Add the OpenRISC virtual machine Stafford Horne
2022-06-02 11:42 ` Joel Stanley
2022-06-02 15:49 ` Richard Henderson
2022-06-02 19:08 ` Geert Uytterhoeven
2022-06-02 19:59 ` Stafford Horne
2022-06-03 7:05 ` Geert Uytterhoeven
2022-06-05 1:58 ` Stafford Horne
2022-06-05 7:32 ` Stafford Horne
2022-06-05 8:19 ` Jason A. Donenfeld
2022-06-07 9:48 ` Jason A. Donenfeld
2022-06-07 8:11 ` Geert Uytterhoeven
2022-06-07 8:42 ` Arnd Bergmann
2022-06-07 9:47 ` Stafford Horne [this message]
2022-06-07 10:04 ` Arnd Bergmann
2022-06-07 10:43 ` Peter Maydell
2022-06-07 12:12 ` Stafford Horne
2022-06-07 14:08 ` Arnd Bergmann
2022-06-05 2:36 ` Stafford Horne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yp8epZsizfKMEVZV@antec \
--to=shorne@gmail.com \
--cc=Jason@zx2c4.com \
--cc=arnd@arndb.de \
--cc=geert@linux-m68k.org \
--cc=joel@jms.id.au \
--cc=openrisc@lists.librecores.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).