From: Stafford Horne <shorne@gmail.com>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
Peter Maydell <peter.maydell@linaro.org>,
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>,
qemu-riscv <qemu-riscv@nongnu.org>
Subject: Re: [RFC PATCH 3/3] hw/openrisc: Add the OpenRISC virtual machine
Date: Thu, 11 Dec 2025 08:08:14 +0000 [thread overview]
Message-ID: <aTp77oJFaTFL4B70@antec> (raw)
In-Reply-To: <59727ca7-9f17-4688-8212-9c37271af41b@linaro.org>
On Wed, Dec 10, 2025 at 06:22:11AM +0100, Philippe Mathieu-Daudé wrote:
> On 7/6/22 16:08, Arnd Bergmann wrote:
> > On Tue, Jun 7, 2022 at 2:12 PM Stafford Horne <shorne@gmail.com> wrote:
> > > On Tue, Jun 07, 2022 at 11:43:08AM +0100, Peter Maydell wrote:
> > >
> > > However, in a followup mail from Laurent we see:
> > >
> > > https://lore.kernel.org/lkml/cb884368-0226-e913-80d2-62d2b7b2e761@vivier.eu/
> > >
> > > The reference document[1] doesn't define the endianness of goldfish.
> > >
> > > [1] https://android.googlesource.com/platform/external/qemu/+/master/docs/GOLDFISH-VIRTUAL-HARDWARE.TXT
> > >
> > >
> > > The documentation does not clearly specify it. So maybe maybe or1k should just
> > > be updated on the linux side and add gf_ioread32/gf_iowrite32 big-endian
> > > accessors.
> >
> > I don't think it makes any sense to use big-endian for a new
> > architecture, just use
> > the default little-endian implementation on the linux side, and change
> > the qemu code
> > to have the backward-compatibility hack for m68k while using big-endian for
> > the rest.
>
> Hitting this thread 3 years latter, suffering with endiannes. Sigh.
What is the issue this is causing?
> Back to OpenRISC virt machine, it is unfortunate it picked the
> TYPE_SIFIVE_TEST virtual device (expected to be little-endian)
> instead of the TYPE_VIRT_CTRL one (expected to be big-endian,
> like OpenRISC).
>
> Fortunately (to me) OpenRISC virt machine exposes the TYPE_SIFIVE_TEST
> virtual device via device tree, and make its endianness explicitly to
> little order.
>
> Stafford, is it too late to use the TYPE_VIRT_CTRL? We could map it
> as a secondary reset device at another address, deprecate the use of
> the mapped SIFIVE_TEST then remove it.
I think its ok to add a second device if that will help you. But, it will take
time to deco the old device as people may be running old kernels, with old
device trees that expect the SIFIVE device for some time.
-Stafford
next prev parent reply other threads:[~2025-12-11 8:08 UTC|newest]
Thread overview: 54+ 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 ` Stafford Horne
2022-05-27 17:27 ` [RFC PATCH 1/3] target/openrisc: Add basic support for semihosting Stafford Horne
2022-05-27 17:27 ` Stafford Horne
2022-06-02 15:39 ` Richard Henderson
2022-06-02 15:39 ` Richard Henderson
2022-06-05 0:57 ` Stafford Horne
2022-06-05 0:57 ` Stafford Horne
2022-06-05 14:36 ` Richard Henderson
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-05-27 17:27 ` Stafford Horne
2022-06-02 15:40 ` Richard Henderson
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-05-27 17:27 ` Stafford Horne
2022-06-02 11:42 ` Joel Stanley
2022-06-02 11:42 ` Joel Stanley
2022-06-02 15:49 ` Richard Henderson
2022-06-02 15:49 ` Richard Henderson
2025-12-10 5:22 ` Philippe Mathieu-Daudé
2025-12-11 8:05 ` Stafford Horne
2022-06-02 19:08 ` Geert Uytterhoeven
2022-06-02 19:08 ` Geert Uytterhoeven
2022-06-02 19:59 ` Stafford Horne
2022-06-02 19:59 ` Stafford Horne
2022-06-03 7:05 ` Geert Uytterhoeven
2022-06-03 7:05 ` Geert Uytterhoeven
2022-06-05 1:58 ` Stafford Horne
2022-06-05 1:58 ` Stafford Horne
2022-06-05 7:32 ` Stafford Horne
2022-06-05 7:32 ` Stafford Horne
2022-06-05 8:19 ` Jason A. Donenfeld
2022-06-05 8:19 ` Jason A. Donenfeld
2022-06-07 9:48 ` Jason A. Donenfeld
2022-06-07 9:48 ` Jason A. Donenfeld
2022-06-07 8:11 ` Geert Uytterhoeven
2022-06-07 8:11 ` Geert Uytterhoeven
2022-06-07 8:42 ` Arnd Bergmann
2022-06-07 8:42 ` Arnd Bergmann
2022-06-07 9:47 ` Stafford Horne
2022-06-07 9:47 ` Stafford Horne
2022-06-07 10:04 ` Arnd Bergmann
2022-06-07 10:04 ` Arnd Bergmann
2022-06-07 10:43 ` Peter Maydell
2022-06-07 10:43 ` Peter Maydell
2022-06-07 12:12 ` Stafford Horne
2022-06-07 12:12 ` Stafford Horne
2022-06-07 14:08 ` Arnd Bergmann
2022-06-07 14:08 ` Arnd Bergmann
2025-12-10 5:22 ` Philippe Mathieu-Daudé
2025-12-11 8:08 ` Stafford Horne [this message]
2022-06-05 2:36 ` Stafford Horne
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=aTp77oJFaTFL4B70@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=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.