Re: [RFC PATCH 3/3] hw/openrisc: Add the OpenRISC virtual machine

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

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.

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.