RFC: riscv64 big endian system attempt

Palmer Dabbelt palmer at dabbelt.com
Thu Jan 9 09:46:04 PST 2025


On Fri, 20 Dec 2024 11:53:47 PST (-0800), Olof Johansson wrote:
> On Fri, Dec 20, 2024 at 03:57:46PM +0000, Ben Dooks wrote:
>> With the latest spec adding configurable endianness, we thought we
>> should try putting together a proof of concept riscv64 big endian.
>>
>> The full information is documented on our gitlab[1] which includes
>> source repositories, build information and project documentation.
>>
>> We have a minimal buildroot, qemu and kernel working on QEMU.
>>
>> As this is a work in progress any review or help is appreciated.
>
> While this is neat, I wonder if there's any real point in picking this
> up broadly and enabling it, with the associated overhead to keep it
> maintained?
>
> While big endian ppc64 will always be close to my heart, little endian
> really has taken over the world by now, even on ppc64. It used to be
> that networking was the area that BE was a (soft) requirement, but with
> modern CPUs having advanced faster than memory latencies and speed, doing
> endian conversion in software doesn't seem to be a big deal any more.
>
> As far as I know, ARM platforms are in the same boat -- they did some
> early enablement, driven by a couple of specific use cases that didn't
> significantly grow and are used in very narrow environment and with very
> limited userspace.
>
> Is this a parallel situation to that, or are there reasons to support BE
> more broadly? It seems like it'd mostly split efforts and add overhead
> to make sure it's still supported, even if it's a fun project to prove
> that it works.

Ya, I think we'd need some real concrete use for this in order to want 
to support it.  Something like actual shipping hardware.

>
>
>
> -Olof
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



More information about the linux-riscv mailing list