This series adds big-endian (BE) RISC-V target support to QEMU,
covering both softmmu and linux-user emulation for riscv32be and
riscv64be.
 
The RISC-V ISA supports big-endian operation via the mstatus SBE/MBE/UBE
bits. While instructions are always little-endian, data accesses follow
the configured endianness. This series implements the necessary QEMU
infrastructure.

Furthermore, MIPS announced cores with BE configuration:
  https://mips.com/products/hardware/i8500/

Patches 01-03: Build system and config for new BE targets
Patches 04-07: Core emulation fixes (instruction fetch, boot ROM, ELF
               loading, fw_dynamic endianness)
Patches 08-11: Linux-user BE targets and vDSO handling
Patch  12:     Set SBE/MBE mstatus bits at CPU reset
Patch  13:     Fix PTE A/D atomic update endianness in page table walker
Patch  14:     Clean up instruction fetch to use MO_LE directly
Patch  15:     Fix virtio-mmio legacy device register endianness
Patch  16:     Add riscv32be and riscv64be to SysEmuTarget

Djordje Todorovic (9):
  meson: Add BE RISCV targets
  config/targets: Add BE RISCV softmmu targets
  config/devices: Add BE riscv configs
  target/riscv: Ensure LE instruction fetching
  hw/riscv: Ensure bootrom has correct endianess
  hw/riscv: Ensure proper ELF endian expectation
  hw/riscv: Check endianness for fw_dynamic fields
  config/targets: Add RISC-V userspace targets
  arch/riscv: Set UBE bit on BE target

djtodoro (7):
  config/targets: Add missing fields to BE linux-user targets
  linux-user/riscv: Disable vDSO for big-endian targets
  target/riscv: Set SBE and MBE bits at CPU reset for BE targets
  target/riscv: Fix PTE A/D atomic update endianness
  target/riscv: Use MO_LE for instruction fetch
  hw/virtio: Use DEVICE_LITTLE_ENDIAN for virtio-mmio legacy ops
  qapi: Add riscv32be and riscv64be to SysEmuTarget

 configs/devices/riscv32be-softmmu/default.mak | 15 +++++++
 configs/devices/riscv64be-softmmu/default.mak | 16 ++++++++
 configs/targets/riscv32be-linux-user.mak      | 11 +++++
 configs/targets/riscv32be-softmmu.mak         |  8 ++++
 configs/targets/riscv64be-linux-user.mak      | 11 +++++
 configs/targets/riscv64be-softmmu.mak         |  8 ++++
 hw/riscv/boot.c                               | 41 ++++++++++++++++---
 hw/virtio/virtio-mmio.c                       |  2 +-
 include/hw/riscv/boot.h                       |  5 +++
 linux-user/riscv/target_elf.h                 | 10 ++++-
 meson.build                                   |  7 +++-
 qapi/machine.json                             |  3 +-
 target/riscv/cpu.c                            |  3 ++
 target/riscv/cpu_bits.h                       |  2 +
 target/riscv/cpu_helper.c                     |  9 ++--
 target/riscv/translate.c                      | 16 ++++----
 16 files changed, 145 insertions(+), 22 deletions(-)
 create mode 100644 configs/devices/riscv32be-softmmu/default.mak
 create mode 100644 configs/devices/riscv64be-softmmu/default.mak
 create mode 100644 configs/targets/riscv32be-linux-user.mak
 create mode 100644 configs/targets/riscv32be-softmmu.mak
 create mode 100644 configs/targets/riscv64be-linux-user.mak
 create mode 100644 configs/targets/riscv64be-softmmu.mak

-- 
2.34.1

> On 25. Feb 2026, at 11:20, Djordje Todorovic <Djordje.Todorovic@htecgroup.com> wrote:
> 
> This series adds big-endian (BE) RISC-V target support to QEMU,
> covering both softmmu and linux-user emulation for riscv32be and
> riscv64be.
Hello,

There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
support it unless we’re sure that it can get to Linux upstream (for the linux-user mode)?

Thank you,
-Mohamed 
> 
> The RISC-V ISA supports big-endian operation via the mstatus SBE/MBE/UBE
> bits. While instructions are always little-endian, data accesses follow
> the configured endianness. This series implements the necessary QEMU
> infrastructure.
> 
> Furthermore, MIPS announced cores with BE configuration:
>  https://mips.com/products/hardware/i8500/
> 
> Patches 01-03: Build system and config for new BE targets
> Patches 04-07: Core emulation fixes (instruction fetch, boot ROM, ELF
>               loading, fw_dynamic endianness)
> Patches 08-11: Linux-user BE targets and vDSO handling
> Patch  12:     Set SBE/MBE mstatus bits at CPU reset
> Patch  13:     Fix PTE A/D atomic update endianness in page table walker
> Patch  14:     Clean up instruction fetch to use MO_LE directly
> Patch  15:     Fix virtio-mmio legacy device register endianness
> Patch  16:     Add riscv32be and riscv64be to SysEmuTarget
> 
> Djordje Todorovic (9):
>  meson: Add BE RISCV targets
>  config/targets: Add BE RISCV softmmu targets
>  config/devices: Add BE riscv configs
>  target/riscv: Ensure LE instruction fetching
>  hw/riscv: Ensure bootrom has correct endianess
>  hw/riscv: Ensure proper ELF endian expectation
>  hw/riscv: Check endianness for fw_dynamic fields
>  config/targets: Add RISC-V userspace targets
>  arch/riscv: Set UBE bit on BE target
> 
> djtodoro (7):
>  config/targets: Add missing fields to BE linux-user targets
>  linux-user/riscv: Disable vDSO for big-endian targets
>  target/riscv: Set SBE and MBE bits at CPU reset for BE targets
>  target/riscv: Fix PTE A/D atomic update endianness
>  target/riscv: Use MO_LE for instruction fetch
>  hw/virtio: Use DEVICE_LITTLE_ENDIAN for virtio-mmio legacy ops
>  qapi: Add riscv32be and riscv64be to SysEmuTarget
> 
> configs/devices/riscv32be-softmmu/default.mak | 15 +++++++
> configs/devices/riscv64be-softmmu/default.mak | 16 ++++++++
> configs/targets/riscv32be-linux-user.mak      | 11 +++++
> configs/targets/riscv32be-softmmu.mak         |  8 ++++
> configs/targets/riscv64be-linux-user.mak      | 11 +++++
> configs/targets/riscv64be-softmmu.mak         |  8 ++++
> hw/riscv/boot.c                               | 41 ++++++++++++++++---
> hw/virtio/virtio-mmio.c                       |  2 +-
> include/hw/riscv/boot.h                       |  5 +++
> linux-user/riscv/target_elf.h                 | 10 ++++-
> meson.build                                   |  7 +++-
> qapi/machine.json                             |  3 +-
> target/riscv/cpu.c                            |  3 ++
> target/riscv/cpu_bits.h                       |  2 +
> target/riscv/cpu_helper.c                     |  9 ++--
> target/riscv/translate.c                      | 16 ++++----
> 16 files changed, 145 insertions(+), 22 deletions(-)
> create mode 100644 configs/devices/riscv32be-softmmu/default.mak
> create mode 100644 configs/devices/riscv64be-softmmu/default.mak
> create mode 100644 configs/targets/riscv32be-linux-user.mak
> create mode 100644 configs/targets/riscv32be-softmmu.mak
> create mode 100644 configs/targets/riscv64be-linux-user.mak
> create mode 100644 configs/targets/riscv64be-softmmu.mak
> 
> -- 
> 2.34.1
> 

On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
<mohamed@unpredictable.fr> wrote:
>
>
>
> > On 25. Feb 2026, at 11:20, Djordje Todorovic <Djordje.Todorovic@htecgroup.com> wrote:
> >
> > This series adds big-endian (BE) RISC-V target support to QEMU,
> > covering both softmmu and linux-user emulation for riscv32be and
> > riscv64be.
> Hello,
>
> There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
> support it unless we’re sure that it can get to Linux upstream (for the linux-user mode)?

Agreed. We really need upstream Linux support before user mode

>
> Thank you,
> -Mohamed
> >
> > The RISC-V ISA supports big-endian operation via the mstatus SBE/MBE/UBE
> > bits. While instructions are always little-endian, data accesses follow
> > the configured endianness. This series implements the necessary QEMU
> > infrastructure.

How are you testing this?

Alistair

> >
> > Furthermore, MIPS announced cores with BE configuration:
> >  https://mips.com/products/hardware/i8500/
> >
> > Patches 01-03: Build system and config for new BE targets
> > Patches 04-07: Core emulation fixes (instruction fetch, boot ROM, ELF
> >               loading, fw_dynamic endianness)
> > Patches 08-11: Linux-user BE targets and vDSO handling
> > Patch  12:     Set SBE/MBE mstatus bits at CPU reset
> > Patch  13:     Fix PTE A/D atomic update endianness in page table walker
> > Patch  14:     Clean up instruction fetch to use MO_LE directly
> > Patch  15:     Fix virtio-mmio legacy device register endianness
> > Patch  16:     Add riscv32be and riscv64be to SysEmuTarget
> >
> > Djordje Todorovic (9):
> >  meson: Add BE RISCV targets
> >  config/targets: Add BE RISCV softmmu targets
> >  config/devices: Add BE riscv configs
> >  target/riscv: Ensure LE instruction fetching
> >  hw/riscv: Ensure bootrom has correct endianess
> >  hw/riscv: Ensure proper ELF endian expectation
> >  hw/riscv: Check endianness for fw_dynamic fields
> >  config/targets: Add RISC-V userspace targets
> >  arch/riscv: Set UBE bit on BE target
> >
> > djtodoro (7):
> >  config/targets: Add missing fields to BE linux-user targets
> >  linux-user/riscv: Disable vDSO for big-endian targets
> >  target/riscv: Set SBE and MBE bits at CPU reset for BE targets
> >  target/riscv: Fix PTE A/D atomic update endianness
> >  target/riscv: Use MO_LE for instruction fetch
> >  hw/virtio: Use DEVICE_LITTLE_ENDIAN for virtio-mmio legacy ops
> >  qapi: Add riscv32be and riscv64be to SysEmuTarget
> >
> > configs/devices/riscv32be-softmmu/default.mak | 15 +++++++
> > configs/devices/riscv64be-softmmu/default.mak | 16 ++++++++
> > configs/targets/riscv32be-linux-user.mak      | 11 +++++
> > configs/targets/riscv32be-softmmu.mak         |  8 ++++
> > configs/targets/riscv64be-linux-user.mak      | 11 +++++
> > configs/targets/riscv64be-softmmu.mak         |  8 ++++
> > hw/riscv/boot.c                               | 41 ++++++++++++++++---
> > hw/virtio/virtio-mmio.c                       |  2 +-
> > include/hw/riscv/boot.h                       |  5 +++
> > linux-user/riscv/target_elf.h                 | 10 ++++-
> > meson.build                                   |  7 +++-
> > qapi/machine.json                             |  3 +-
> > target/riscv/cpu.c                            |  3 ++
> > target/riscv/cpu_bits.h                       |  2 +
> > target/riscv/cpu_helper.c                     |  9 ++--
> > target/riscv/translate.c                      | 16 ++++----
> > 16 files changed, 145 insertions(+), 22 deletions(-)
> > create mode 100644 configs/devices/riscv32be-softmmu/default.mak
> > create mode 100644 configs/devices/riscv64be-softmmu/default.mak
> > create mode 100644 configs/targets/riscv32be-linux-user.mak
> > create mode 100644 configs/targets/riscv32be-softmmu.mak
> > create mode 100644 configs/targets/riscv64be-linux-user.mak
> > create mode 100644 configs/targets/riscv64be-softmmu.mak
> >
> > --
> > 2.34.1
> >
>

On 2/27/26 00:30, Alistair Francis wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
> <mohamed@unpredictable.fr> wrote:
>>
>>
>>> On 25. Feb 2026, at 11:20, Djordje Todorovic <Djordje.Todorovic@htecgroup.com> wrote:
>>>
>>> This series adds big-endian (BE) RISC-V target support to QEMU,
>>> covering both softmmu and linux-user emulation for riscv32be and
>>> riscv64be.
>> Hello,
>>
>> There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
>> support it unless we’re sure that it can get to Linux upstream (for the linux-user mode)?
> Agreed. We really need upstream Linux support before user mode
>
>> Thank you,
>> -Mohamed
>>> The RISC-V ISA supports big-endian operation via the mstatus SBE/MBE/UBE
>>> bits. While instructions are always little-endian, data accesses follow
>>> the configured endianness. This series implements the necessary QEMU
>>> infrastructure.
> How are you testing this?

Hi Alistair,

Thanks for your comments!


Even though the SW ecosystem is not complete/mature, there is

pretty decent support in GNU toolchain for riscv big-endian already.

GNU GCC, binutils, etc. are pretty okay. I am now working on the

upstreaming process of riscv big-endian in LLVM project, and compiler

part is already merged -- almost done with LLD (LLVM based linker)

and LLDB (LLVM based debugger) as well.


Furthermore, I have also implemented:

1) basic linux support

   https://github.com/djtodoro/linux/commits/riscv-be-proposal/

2) as well as some basic CI support for basic cases:

   https://github.com/djtodoro/riscv-be-test-suite

so qemu is tested against these two as well.


At the end, we do see that even on GNU GCC mailing list,

people are seeking for at least basic support in qemu for

riscv big-endian target, since the testing will become much

easier, since GNU Sym does support it, but it is not robust

enough (as qemu).


Thanks,
Djordje

> Alistair
>
>>> Furthermore, MIPS announced cores with BE configuration:
>>>   https://mips.com/products/hardware/i8500/
>>>
>>> Patches 01-03: Build system and config for new BE targets
>>> Patches 04-07: Core emulation fixes (instruction fetch, boot ROM, ELF
>>>                loading, fw_dynamic endianness)
>>> Patches 08-11: Linux-user BE targets and vDSO handling
>>> Patch  12:     Set SBE/MBE mstatus bits at CPU reset
>>> Patch  13:     Fix PTE A/D atomic update endianness in page table walker
>>> Patch  14:     Clean up instruction fetch to use MO_LE directly
>>> Patch  15:     Fix virtio-mmio legacy device register endianness
>>> Patch  16:     Add riscv32be and riscv64be to SysEmuTarget
>>>
>>> Djordje Todorovic (9):
>>>   meson: Add BE RISCV targets
>>>   config/targets: Add BE RISCV softmmu targets
>>>   config/devices: Add BE riscv configs
>>>   target/riscv: Ensure LE instruction fetching
>>>   hw/riscv: Ensure bootrom has correct endianess
>>>   hw/riscv: Ensure proper ELF endian expectation
>>>   hw/riscv: Check endianness for fw_dynamic fields
>>>   config/targets: Add RISC-V userspace targets
>>>   arch/riscv: Set UBE bit on BE target
>>>
>>> djtodoro (7):
>>>   config/targets: Add missing fields to BE linux-user targets
>>>   linux-user/riscv: Disable vDSO for big-endian targets
>>>   target/riscv: Set SBE and MBE bits at CPU reset for BE targets
>>>   target/riscv: Fix PTE A/D atomic update endianness
>>>   target/riscv: Use MO_LE for instruction fetch
>>>   hw/virtio: Use DEVICE_LITTLE_ENDIAN for virtio-mmio legacy ops
>>>   qapi: Add riscv32be and riscv64be to SysEmuTarget
>>>
>>> configs/devices/riscv32be-softmmu/default.mak | 15 +++++++
>>> configs/devices/riscv64be-softmmu/default.mak | 16 ++++++++
>>> configs/targets/riscv32be-linux-user.mak      | 11 +++++
>>> configs/targets/riscv32be-softmmu.mak         |  8 ++++
>>> configs/targets/riscv64be-linux-user.mak      | 11 +++++
>>> configs/targets/riscv64be-softmmu.mak         |  8 ++++
>>> hw/riscv/boot.c                               | 41 ++++++++++++++++---
>>> hw/virtio/virtio-mmio.c                       |  2 +-
>>> include/hw/riscv/boot.h                       |  5 +++
>>> linux-user/riscv/target_elf.h                 | 10 ++++-
>>> meson.build                                   |  7 +++-
>>> qapi/machine.json                             |  3 +-
>>> target/riscv/cpu.c                            |  3 ++
>>> target/riscv/cpu_bits.h                       |  2 +
>>> target/riscv/cpu_helper.c                     |  9 ++--
>>> target/riscv/translate.c                      | 16 ++++----
>>> 16 files changed, 145 insertions(+), 22 deletions(-)
>>> create mode 100644 configs/devices/riscv32be-softmmu/default.mak
>>> create mode 100644 configs/devices/riscv64be-softmmu/default.mak
>>> create mode 100644 configs/targets/riscv32be-linux-user.mak
>>> create mode 100644 configs/targets/riscv32be-softmmu.mak
>>> create mode 100644 configs/targets/riscv64be-linux-user.mak
>>> create mode 100644 configs/targets/riscv64be-softmmu.mak
>>>
>>> --
>>> 2.34.1
>>>

On Fri, Feb 27, 2026 at 09:30:00AM +1000, Alistair Francis wrote:
> On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
> <mohamed@unpredictable.fr> wrote:
> >
> >
> >
> > > On 25. Feb 2026, at 11:20, Djordje Todorovic <Djordje.Todorovic@htecgroup.com> wrote:
> > >
> > > This series adds big-endian (BE) RISC-V target support to QEMU,
> > > covering both softmmu and linux-user emulation for riscv32be and
> > > riscv64be.
> > Hello,
> >
> > There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
> > support it unless we’re sure that it can get to Linux upstream (for the linux-user mode)?
> 
> Agreed. We really need upstream Linux support before user mode

On that front, Ben posted patches for it and Linus was really really not
enthused when he became aware of it:
https://lore.kernel.org/linux-riscv/066d70c7-b0a7-45e5-9337-17901bc95664@codethink.co.uk
Even without Linus' take, I feel like there's absolutely no chance of
upstream support without meaningful shipping hardware that requires
big endian support, because basically everyone else was also opposed to
adding it...

On Fri, Feb 27, 2026 at 9:47 AM Conor Dooley <conor@kernel.org> wrote:
>
> On Fri, Feb 27, 2026 at 09:30:00AM +1000, Alistair Francis wrote:
> > On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
> > <mohamed@unpredictable.fr> wrote:
> > >
> > >
> > >
> > > > On 25. Feb 2026, at 11:20, Djordje Todorovic <Djordje.Todorovic@htecgroup.com> wrote:
> > > >
> > > > This series adds big-endian (BE) RISC-V target support to QEMU,
> > > > covering both softmmu and linux-user emulation for riscv32be and
> > > > riscv64be.
> > > Hello,
> > >
> > > There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
> > > support it unless we’re sure that it can get to Linux upstream (for the linux-user mode)?
> >
> > Agreed. We really need upstream Linux support before user mode
>
> On that front, Ben posted patches for it and Linus was really really not
> enthused when he became aware of it:
> https://lore.kernel.org/linux-riscv/066d70c7-b0a7-45e5-9337-17901bc95664@codethink.co.uk
> Even without Linus' take, I feel like there's absolutely no chance of
> upstream support without meaningful shipping hardware that requires
> big endian support, because basically everyone else was also opposed to
> adding it...

Yeah... I saw that.

A few thoughts, just because Linus doesn't like it doesn't mean QEMU
can't support it. But I am hesitant to support BE considering the lack
of ecosystem support everywhere else.

There are a bunch of changes in this series that could easily go into
QEMU. They aren't intrusive and just involve changing or using helper
functions to handle endianness. I think those could be split out and
go upstream, reducing the size of this series and reducing the
maintenance burden of out of tree patches.

The core BE support is a different problem. But if softmmu works in
the existing binaries then maybe it's worth accepting. linux user mode
is a whole other problem that we probably won't be able to accept.

Alistair

On 2/27/26 01:56, Alistair Francis wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> On Fri, Feb 27, 2026 at 9:47 AM Conor Dooley <conor@kernel.org> wrote:
>> On Fri, Feb 27, 2026 at 09:30:00AM +1000, Alistair Francis wrote:
>>> On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
>>> <mohamed@unpredictable.fr> wrote:
>>>>
>>>>
>>>>> On 25. Feb 2026, at 11:20, Djordje Todorovic <Djordje.Todorovic@htecgroup.com> wrote:
>>>>>
>>>>> This series adds big-endian (BE) RISC-V target support to QEMU,
>>>>> covering both softmmu and linux-user emulation for riscv32be and
>>>>> riscv64be.
>>>> Hello,
>>>>
>>>> There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
>>>> support it unless we’re sure that it can get to Linux upstream (for the linux-user mode)?
>>> Agreed. We really need upstream Linux support before user mode
>> On that front, Ben posted patches for it and Linus was really really not
>> enthused when he became aware of it:
>> https://lore.kernel.org/linux-riscv/066d70c7-b0a7-45e5-9337-17901bc95664@codethink.co.uk
>> Even without Linus' take, I feel like there's absolutely no chance of
>> upstream support without meaningful shipping hardware that requires
>> big endian support, because basically everyone else was also opposed to
>> adding it...
> Yeah... I saw that.
>
> A few thoughts, just because Linus doesn't like it doesn't mean QEMU
> can't support it. But I am hesitant to support BE considering the lack
> of ecosystem support everywhere else.


Please be aware that MIPS will ship hardware based on riscv BE

soon: https://mips.com/products/hardware/i8500/


Thanks,
Djordje


> There are a bunch of changes in this series that could easily go into
> QEMU. They aren't intrusive and just involve changing or using helper
> functions to handle endianness. I think those could be split out and
> go upstream, reducing the size of this series and reducing the
> maintenance burden of out of tree patches.
>
> The core BE support is a different problem. But if softmmu works in
> the existing binaries then maybe it's worth accepting. linux user mode
> is a whole other problem that we probably won't be able to accept.
>
> Alistair

On Fri, Feb 27, 2026 at 12:42:21PM +0000, Djordje Todorovic wrote:
> 
> On 2/27/26 01:56, Alistair Francis wrote:
> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> >
> >
> > On Fri, Feb 27, 2026 at 9:47 AM Conor Dooley <conor@kernel.org> wrote:
> >> On Fri, Feb 27, 2026 at 09:30:00AM +1000, Alistair Francis wrote:
> >>> On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
> >>> <mohamed@unpredictable.fr> wrote:
> >>>>
> >>>>
> >>>>> On 25. Feb 2026, at 11:20, Djordje Todorovic <Djordje.Todorovic@htecgroup.com> wrote:
> >>>>>
> >>>>> This series adds big-endian (BE) RISC-V target support to QEMU,
> >>>>> covering both softmmu and linux-user emulation for riscv32be and
> >>>>> riscv64be.
> >>>> Hello,
> >>>>
> >>>> There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
> >>>> support it unless we’re sure that it can get to Linux upstream (for the linux-user mode)?
> >>> Agreed. We really need upstream Linux support before user mode
> >> On that front, Ben posted patches for it and Linus was really really not
> >> enthused when he became aware of it:
> >> https://lore.kernel.org/linux-riscv/066d70c7-b0a7-45e5-9337-17901bc95664@codethink.co.uk
> >> Even without Linus' take, I feel like there's absolutely no chance of
> >> upstream support without meaningful shipping hardware that requires
> >> big endian support, because basically everyone else was also opposed to
> >> adding it...
> > Yeah... I saw that.
> >
> > A few thoughts, just because Linus doesn't like it doesn't mean QEMU
> > can't support it. But I am hesitant to support BE considering the lack
> > of ecosystem support everywhere else.
> 
> 
> Please be aware that MIPS will ship hardware based on riscv BE
> 
> soon: https://mips.com/products/hardware/i8500/

Not the meaning of "hardware" I was using, as this appears to be a core
complex IP rather than physical hardware? Do you know of any devices,
outside of a MIPS test chip or w/e, that are going to use this IP?

On the linux support front, the devils advocate take would be that
people should just run this core in LE mode, but that's a bridge to be
crossed when someone produces an SoC using that core complex and on
another mailing list!

On 2/27/26 13:56, Conor Dooley wrote:
> On Fri, Feb 27, 2026 at 12:42:21PM +0000, Djordje Todorovic wrote:
>> On 2/27/26 01:56, Alistair Francis wrote:
>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>>>
>>>
>>> On Fri, Feb 27, 2026 at 9:47 AM Conor Dooley<conor@kernel.org> wrote:
>>>> On Fri, Feb 27, 2026 at 09:30:00AM +1000, Alistair Francis wrote:
>>>>> On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
>>>>> <mohamed@unpredictable.fr> wrote:
>>>>>>> On 25. Feb 2026, at 11:20, Djordje Todorovic<Djordje.Todorovic@htecgroup.com> wrote:
>>>>>>>
>>>>>>> This series adds big-endian (BE) RISC-V target support to QEMU,
>>>>>>> covering both softmmu and linux-user emulation for riscv32be and
>>>>>>> riscv64be.
>>>>>> Hello,
>>>>>>
>>>>>> There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
>>>>>> support it unless we’re sure that it can get to Linux upstream (for the linux-user mode)?
>>>>> Agreed. We really need upstream Linux support before user mode
>>>> On that front, Ben posted patches for it and Linus was really really not
>>>> enthused when he became aware of it:
>>>> https://lore.kernel.org/linux-riscv/066d70c7-b0a7-45e5-9337-17901bc95664@codethink.co.uk
>>>> Even without Linus' take, I feel like there's absolutely no chance of
>>>> upstream support without meaningful shipping hardware that requires
>>>> big endian support, because basically everyone else was also opposed to
>>>> adding it...
>>> Yeah... I saw that.
>>>
>>> A few thoughts, just because Linus doesn't like it doesn't mean QEMU
>>> can't support it. But I am hesitant to support BE considering the lack
>>> of ecosystem support everywhere else.
>> Please be aware that MIPS will ship hardware based on riscv BE
>>
>> soon:https://mips.com/products/hardware/i8500/
> Not the meaning of "hardware" I was using, as this appears to be a core
> complex IP rather than physical hardware? Do you know of any devices,
> outside of a MIPS test chip or w/e, that are going to use this IP?
>
> On the linux support front, the devils advocate take would be that
> people should just run this core in LE mode, but that's a bridge to be
> crossed when someone produces an SoC using that core complex and on
> another mailing list!

Yes, you are right, the i8500 is an IP. And I can share for now that 
QEMU and FPGA

board with the i8500 bitfile are the targets for testing of RISC-V BE 
software.


Best regards,
Djordje

Hi Djordje,

On 27/2/26 15:24, Djordje Todorovic wrote:
> On 2/27/26 13:56, Conor Dooley wrote:
>> On Fri, Feb 27, 2026 at 12:42:21PM +0000, Djordje Todorovic wrote:
>>> On 2/27/26 01:56, Alistair Francis wrote:
>>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>>>>
>>>>
>>>> On Fri, Feb 27, 2026 at 9:47 AM Conor Dooley<conor@kernel.org> wrote:
>>>>> On Fri, Feb 27, 2026 at 09:30:00AM +1000, Alistair Francis wrote:
>>>>>> On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
>>>>>> <mohamed@unpredictable.fr> wrote:
>>>>>>>> On 25. Feb 2026, at 11:20, Djordje Todorovic<Djordje.Todorovic@htecgroup.com> wrote:
>>>>>>>>
>>>>>>>> This series adds big-endian (BE) RISC-V target support to QEMU,
>>>>>>>> covering both softmmu and linux-user emulation for riscv32be and
>>>>>>>> riscv64be.
>>>>>>> Hello,
>>>>>>>
>>>>>>> There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
>>>>>>> support it unless we’re sure that it can get to Linux upstream (for the linux-user mode)?
>>>>>> Agreed. We really need upstream Linux support before user mode
>>>>> On that front, Ben posted patches for it and Linus was really really not
>>>>> enthused when he became aware of it:
>>>>> https://lore.kernel.org/linux-riscv/066d70c7-b0a7-45e5-9337-17901bc95664@codethink.co.uk
>>>>> Even without Linus' take, I feel like there's absolutely no chance of
>>>>> upstream support without meaningful shipping hardware that requires
>>>>> big endian support, because basically everyone else was also opposed to
>>>>> adding it...
>>>> Yeah... I saw that.
>>>>
>>>> A few thoughts, just because Linus doesn't like it doesn't mean QEMU
>>>> can't support it. But I am hesitant to support BE considering the lack
>>>> of ecosystem support everywhere else.
>>> Please be aware that MIPS will ship hardware based on riscv BE
>>>
>>> soon:https://mips.com/products/hardware/i8500/
>> Not the meaning of "hardware" I was using, as this appears to be a core
>> complex IP rather than physical hardware? Do you know of any devices,
>> outside of a MIPS test chip or w/e, that are going to use this IP?
>>
>> On the linux support front, the devils advocate take would be that
>> people should just run this core in LE mode, but that's a bridge to be
>> crossed when someone produces an SoC using that core complex and on
>> another mailing list!
> 
> Yes, you are right, the i8500 is an IP. And I can share for now that
> QEMU and FPGA
> 
> board with the i8500 bitfile are the targets for testing of RISC-V BE
> software.

Just to clarify, as explained by Thomas elsewhere in this thread, we
are not opposed to have QEMU runs big-endian RISCV cores, and indeed
what guest runs shouldn't be a blocker (Linux support is convenient
for testing, but as long as you provide any other guest firmware code
we can run, we are happy). What we do not want is to add a new binary.
Endianness is a runtime variant. If implemented correctly, the current
binaries should be able to have the HARTs running any endianness. See
the recent changes in qemu-system-microblaze for example. Other targets
are going to get their endianness unified (but it will take time).

Regards,

Phil.

On 27/02/2026 01.56, Alistair Francis wrote:
> On Fri, Feb 27, 2026 at 9:47 AM Conor Dooley <conor@kernel.org> wrote:
>>
>> On Fri, Feb 27, 2026 at 09:30:00AM +1000, Alistair Francis wrote:
>>> On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
>>> <mohamed@unpredictable.fr> wrote:
>>>>
>>>>
>>>>
>>>>> On 25. Feb 2026, at 11:20, Djordje Todorovic <Djordje.Todorovic@htecgroup.com> wrote:
>>>>>
>>>>> This series adds big-endian (BE) RISC-V target support to QEMU,
>>>>> covering both softmmu and linux-user emulation for riscv32be and
>>>>> riscv64be.
>>>> Hello,
>>>>
>>>> There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
>>>> support it unless we’re sure that it can get to Linux upstream (for the linux-user mode)?
>>>
>>> Agreed. We really need upstream Linux support before user mode
>>
>> On that front, Ben posted patches for it and Linus was really really not
>> enthused when he became aware of it:
>> https://lore.kernel.org/linux-riscv/066d70c7-b0a7-45e5-9337-17901bc95664@codethink.co.uk
>> Even without Linus' take, I feel like there's absolutely no chance of
>> upstream support without meaningful shipping hardware that requires
>> big endian support, because basically everyone else was also opposed to
>> adding it...
> 
> Yeah... I saw that.
> 
> A few thoughts, just because Linus doesn't like it doesn't mean QEMU
> can't support it. But I am hesitant to support BE considering the lack
> of ecosystem support everywhere else.
> 
> There are a bunch of changes in this series that could easily go into
> QEMU. They aren't intrusive and just involve changing or using helper
> functions to handle endianness. I think those could be split out and
> go upstream, reducing the size of this series and reducing the
> maintenance burden of out of tree patches.
> 
> The core BE support is a different problem. But if softmmu works in
> the existing binaries then maybe it's worth accepting.

FWIW, have a look at the changes that Philippe did in target/microblaze/ in 
the past two years, he merged the both endianness flavours there so it can 
now be handled in one binary! If you do something similar with riscv, it 
hopefully should not be too intrusive.

  Thomas

On 2/27/26 10:27, Thomas Huth wrote:
> CAUTION: This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender 
> and know the content is safe.
>
>
> On 27/02/2026 01.56, Alistair Francis wrote:
>> On Fri, Feb 27, 2026 at 9:47 AM Conor Dooley <conor@kernel.org> wrote:
>>>
>>> On Fri, Feb 27, 2026 at 09:30:00AM +1000, Alistair Francis wrote:
>>>> On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
>>>> <mohamed@unpredictable.fr> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On 25. Feb 2026, at 11:20, Djordje Todorovic 
>>>>>> <Djordje.Todorovic@htecgroup.com> wrote:
>>>>>>
>>>>>> This series adds big-endian (BE) RISC-V target support to QEMU,
>>>>>> covering both softmmu and linux-user emulation for riscv32be and
>>>>>> riscv64be.
>>>>> Hello,
>>>>>
>>>>> There’s no Linux RISC-V big endian. Maybe the right thing to do is 
>>>>> to not
>>>>> support it unless we’re sure that it can get to Linux upstream 
>>>>> (for the linux-user mode)?
>>>>
>>>> Agreed. We really need upstream Linux support before user mode
>>>
>>> On that front, Ben posted patches for it and Linus was really really 
>>> not
>>> enthused when he became aware of it:
>>> https://lore.kernel.org/linux-riscv/066d70c7-b0a7-45e5-9337-17901bc95664@codethink.co.uk 
>>>
>>> Even without Linus' take, I feel like there's absolutely no chance of
>>> upstream support without meaningful shipping hardware that requires
>>> big endian support, because basically everyone else was also opposed to
>>> adding it...
>>
>> Yeah... I saw that.
>>
>> A few thoughts, just because Linus doesn't like it doesn't mean QEMU
>> can't support it. But I am hesitant to support BE considering the lack
>> of ecosystem support everywhere else.
>>
>> There are a bunch of changes in this series that could easily go into
>> QEMU. They aren't intrusive and just involve changing or using helper
>> functions to handle endianness. I think those could be split out and
>> go upstream, reducing the size of this series and reducing the
>> maintenance burden of out of tree patches.
>>
>> The core BE support is a different problem. But if softmmu works in
>> the existing binaries then maybe it's worth accepting.
>
> FWIW, have a look at the changes that Philippe did in 
> target/microblaze/ in
> the past two years, he merged the both endianness flavours there so it 
> can
> now be handled in one binary! If you do something similar with riscv, it
> hopefully should not be too intrusive.
>
>  Thomas
>
Hi Thomas,

Yes, sure, thanks for the advice, I will try to follow that part for 
riscv as well!

Thanks a lot!
Djordje