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 <[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.
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
