On 01/10/2025 12:32, Daniel Henrique Barboza wrote:
(ccing qemu-devel ML - please send all patches to qemu-devel too)
On 9/30/25 6:46 AM, Heinrich Schuchardt wrote:
On 12/20/24 16:45, Roan Richmond wrote:
This is part of our project to investigate big endian on RISC-V.
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.
[1] https://gitlab.com/CodethinkLabs/riscv_bigendian
Ben Dooks (2):
target/riscv: Add big endian check for atomic ops
taregt/riscv: Add big endian checks for pagetable
Lawrence Hunter (3):
target/riscv: Add SSTATUS_UBE
target/riscv: Add sfence.vma for endian change
target/riscv: Add big endian CPU target
The RISC-V specification explicitly allows for bi-endian cpus.
Shouldn't we change the existing generic RISC-V cpus to allow starting
low-endian and switching the endianness at runtime instead of adding a
new CPU?
Mainline Linux stated that RISC-V BE support will be "discouraged" (feel
free to read
yet another Linus rant in linux-riscv - we're having multiple Linus
rants per month).
This means that this work investigation will require at very least a
custom kernel that
mainline won't support, which will in turn make it harder for QEMU to
properly support
it in boot tests via TuxBoot and so on.
This doesn't mean that we should reject this work, but we should keep BE
exclusive logic
separated from the generic LE code at least for now. Point being: the
split BE CPU
target, like this series is already doing, seems like the way to go.
Thanks,
Daniel
I think since there are other architectures already doing run-time
selectable endian I'm going to keep this in the series. I'll be replying
to the linux-kernel portion later when I'm less inclined to be rude to
Linus.
The linux-kernel changes are not huge so we could probably keep our own
out-of-tree for a bit, but I do not want to keep putting a lot of effort
into this without anyone else being interested.
Not sure if there would be any interested from any BSD for a kernel?
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html