On 7/6/22 16:08, Arnd Bergmann wrote:
On Tue, Jun 7, 2022 at 2:12 PM Stafford Horne <[email protected]> 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/[email protected]/
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.
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.
