qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stafford Horne <shorne@gmail.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	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 21:12:07 +0900	[thread overview]
Message-ID: <Yp9Al1UfqvIzStI7@antec> (raw)
In-Reply-To: <CAFEAcA97oraa5OSdqmubmJ2-ONTCTF4ZszwfTcZ9VhqKRFhogA@mail.gmail.com>

On Tue, Jun 07, 2022 at 11:43:08AM +0100, Peter Maydell wrote:
> So I don't have a strong view on whether these devices should
> be DEVICE_NATIVE_ENDIAN or DEVICE_LITTLE_ENDIAN (except that
> my impression is that a DEVICE_LITTLE_ENDIAN device on a
> big-endian system is a bit weird, because it means the guest
> has to byteswap everything. You see that with PCI devices because
> the PCI spec mandates LE, but not often elsewhere).
> 
> If there's an official-ish spec for how goldfish devices are
> supposed to behave (does anybody have a pointer to one?) and it says
> "always little-endian" then that would probably suggest that fixing
> m68k would be nice if we can.

I think there are some conflicting thoughts on this.

In Geert's he mentioned:

  Using Goldfish devices as little-endian devices should be fine.

In Arnd's mail he mentions:

  https://lore.kernel.org/lkml/CAK8P3a1oN8NrUjkh2X8jHQbyz42Xo6GSa=5n0gD6vQcXRjmq1Q@mail.gmail.com/#t

  ... the device was clearly defined as having little-endian
  registers,

Based on that I was thinking that switching to DEVICE_LITTLE_ENDIAN would make
sense.

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.

-Stafford


  reply	other threads:[~2022-06-07 12:44 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
2022-06-07 10:04                     ` Arnd Bergmann
2022-06-07 10:43                     ` Peter Maydell
2022-06-07 12:12                       ` Stafford Horne [this message]
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=Yp9Al1UfqvIzStI7@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=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).