Re: [OE-core][PATCH RFC v2 00/19] riscv: add new ISA extensions and profile support

["Trevor Gamblin" <tgamblin@baylibre.com>]

On Thu Oct 8, 2026 at 11:42 AM EDT, Mark Hatle wrote:
>
>
> On 10/8/26 5:56 AM, Khem Raj wrote:
>> I will review rest of series in detail later
>> 
>> On Thu, Oct 1, 2026, 11:13 AM Paul Barker <paul@pbarker.dev 
>> <mailto:paul@pbarker.dev>> wrote:
>> 
>>     Hi Trevor,
>> 
>>     Snipping a lot of the cover letter to give some initial thoughts...
>> 
>>     On Wed, 2026-09-30 at 12:38 -0400, Trevor Gamblin wrote:
>>      > A list of changes, by group:
>>      >
>>      > 1. Basic clarification changes and extra tunings:
>>      >     a. tune-riscv: be explicit about riscv32gc, riscv64gc defaults
>>      >     b. tune-riscv.inc: add 'riscv64gcv' tune
>> 
>>     I think these changes make sense, and now master has diverged from
>>     blacksail it may be a good time to take them.
>> 
>>      > 2. Adding official RVA20 profile extensions, and supporting the explicit
>>     choice
>>      > of 'rva20u64' as a tuning option for builds:
>>      >     a. arch-riscv.inc: add missing RVA20 extensions
>>      >     b. meta/lib/oe/tune.py: support profile strings, add rva20u64
>>      >     c. tune-riscv.inc: add rva20u64 to AVAILTUNES
>>      > 3. Adding RVA22 profile support:
>>      >     a. arch-riscv.inc: add rva22u64 extensions
>>      >     b. meta/lib/oe/tune.py: add rva22u64 profile
>>      >     c. tune-riscv.inc: add rva22u64 to AVAILTUNES
>>      > 4. Adding RVA23 profile support:
>>      >     a. arch-riscv.inc: add rva23u64 extensions
>>      >     b. meta/lib/oe/tune.py: add rva23u64 profile
>>      >     c. tune-riscv.inc: add rva23u64 to AVAILTUNES
>>      > 5. Quality-of-life fixups after 1-4:
>>      >     a. meta/lib/oe/tune.py: add riscv_pkgarch()
>>      >     b. arch-riscv.inc: rename TUNE_RISCV_PKGARCH -> TUNE_RISCV_PKGARCH_EXACT
>>      >        in assignments
>>      >     c. tune.py: add implied tuning logic
>>      >     d. tune.py: add vector extensions to RISCV_IMPLIED
>>      >     e. tune-riscv.inc: add RISCV_PKGARCH vars, set PACKAGE_EXTRA_ARCHS
>>      >     f. tune-riscv.inc: clarify zifencei comment
>>      > 6. Selftests:
>>      >     a. selftest: oelib: add tune.py
>>      >     b. selftest: cases: add riscvtune.py
>> 
>>     There are no users of the RVA20, RVA22 or RVA23 profiles in OE-core, so
>>     it's hard to be confident that the approach is right here. I assume the
>>     goal is to convert some of the machines in meta-riscv to use the
>>     appropriate TUNE once these changes are merged? If so, it may be better
>>     to first add support for the new profiles in meta-riscv and update
>>     relevant machine configurations to use them. Once they've had some time
>>     to stabilise in meta-riscv we could then move them into OE-core.
>> 
>> 
>> Its better to handle it in one place in oe-core. We do similar for arm. Where we 
>> have all kind of tunes in core its simpler to get the logic working that way. 
>> Older editions of architectures aren't going away anytime soon.
>
> I'm not attempting to speak for RP here, but when I did the initial code.  RP 
> wanted to be sure that we did not introduce additional maintenance by just 
> adding a boat load of new ISA options without someone willing to maintain them, 
> a way to test them (i.e. gcc/llvm/etc), and more to the point some sort of 
> target system(s) that were actively using them.

I've started by adding some selftests, but I think that was just the beginning.
This definitely does mean *some* more maintenance, but I think it's important
for us to be explicit about which extensions are to be selected for an available
tuning, rather than letting the compiler alone figure that out. That being said,
I'm not expecting ratified specifications to change significantly, so being more
explicit about extensions in this way might help us with detecting when
something has gone wrong with the underlying toolchain - this is something I was
thinking about before, but it's on my mind more now that I've had feedback from
you all.

>
> The initial implementation was formed based on existing OE, plus the AMD FPGA 
> based Risc-V components, so everything had an active "user" and test path.
>
> I think RP's request from the initial work is still valid.  We should be adding 
> ISA items because they are useful to actual embedded users, and not just because 
> someone defined them.  If they don't exist (yet) in gcc, llvm, etc, we should 
> not be including them.  If there is no hardware (qemu counts as hardware) to 
> exercise an ISA, I would be reluctant to include it as it just increases 
> maintenance without a path for testing.

gcc definitely includes them, although there is a distinction between
riscv64gc/rv64gc and rva20u64, which I believe has been made confusing by some
vendors and/or marketing materials suggesting RV64GC hardware was RVA20
compatible (technically true, in that rva20 is a superset), or the opposite,
which recent gcc versions at least show to be different:

|tgamblin@alchemist ~/workspace/git/boardgarden (main)$ gcc --version
|gcc (GCC) 16.2.1 20260819 (Red Hat 16.2.1-2)
|Copyright (C) 2026 Free Software Foundation, Inc.
|This is free software; see the source for copying conditions.  There is NO
|warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
|tgamblin@alchemist ~/workspace/git/boardgarden (main)$ riscv64-linux-gnu-gcc -march=rv64gc -mabi=lp64d -Q --help=target | grep march
|  --print-supported-extensions 		-march=help
|  -march=                     		rv64imafdc_zicsr_zifencei_zmmul_zaamo_zalrsc_zca_zcd
|  -march=help                 		[disabled]
|  -print-supported-extensions 		-march=help
|tgamblin@alchemist ~/workspace/git/boardgarden (main)$ riscv64-linux-gnu-gcc -march=rva20u64 -mabi=lp64d -Q --help=target | grep march
|  --print-supported-extensions 		-march=help
|  -march=                     		rv64imafdc_ziccamoa_ziccif_zicclsm_ziccrse_zicntr_zicsr_zmmul_za128rs_zaamo_zalrsc_zca_zcd
|  -march=help                 		[disabled]
|  -print-supported-extensions 		-march=help

As for target systems using them, the "new" standard is the SpacemiT K3 platform
for now, which is RVA23 compliant and thus mandates all of the extensions which
haven't been superseded from earlier profiles, plus all of the RVA23-specific
ones. Right now we're still building with 'riscv64gc' as the package tuning when
that BSP is enabled with meta-riscv, along with all other platforms (QEMU
included, which boots RVA23S64 by default in oe-core). The goal is definitely to
allow building with package tunings which match the underlying hardware in
meta-riscv, although the hardware landscape means that most people will be
building against one of the following three cases in the short-term:

1. riscv64gc
2. rva22u64 + RVV (SpacemiT K1)
3. rva23u64

>
> With the above said, I don't have a good view of the risc-v world outside of my 
> specific workflows and use-cases, so I can't recommend any particular ISA 
> extensions (in this patch set) that should or should not be included, but I 
> think the general design above is a good one to keep things reasonable and bound 
> the problem.  (We could try to implement ALL risc-v ISA extensions, but it's 
> pretty clear to me from reading the docs a lot of them are theoretical or not 
> used within the scope of what OE is current used for.

That could be true. I won't pretend that I have a thorough grasp of where most
of them come into play, but I have seen enough cases of certain extensions being
necessary for some packages (e.g. FFmpeg) that providing support for them seems
more practical than not. 

A related topic that came up repeatedly at LPC/OSS Prague last week was the more
general future of RISC-V software support. I got the impression from some
conversations that moving to RVA23 as the baseline and deprecating older
profiles from distro and toolchain perspectives was desired by some maintainers.
However, there are already some platforms in production using older profiles
that will need support for a long time. I don't want to speak for others either,
but I think Yocto is uniquely positioned to provide that kind of support as
other distros move on, and in my mind Yocto and RISC-V align very well in the
flexibility/customization sense (especially where we don't necessarily know
who's using which parts and in what capacity).

Anyway, I think I'll submit the first two patches in this series again as
standalone changes, and look at sending the rest to meta-riscv for now.

Trevor
>
>> 
>>      > One significant change to the way profile strings are processed with
>>      > these patches shows up in sstate/build path naming, and is part of the
>>      > reason for patch 5a-5d above. Before, a build directory
>>      > might have a path in it like:
>>      >
>>      > > build/tmp/work/riscv64imafdc_zicsr_zifencei-poky-linux/
>>      >
>>      > This was fine when the extension list was short (for riscv64gc), but with the
>>      > full RVA profiles, the paths started to get so long that bitbake would
>>     produce
>>      > this error:
>>      >
>>      > > ERROR: Unable to reduce sstate name to less than 255 chararacters
>>      >
>>      > To solve this problem, meta/lib/oe/tune.py now supports a very short
>>      > list of profile names, and includes new functions (riscv_pkgarch() and
>>      > riscv_implied()) designed to compare selected extensions against
>>      > dependencies (profile and otherwise), and shorten path names
>>      > appropriately. As an example, if you set the following in local.conf:
>>      >
>>      > > AVAILTUNES += "my-rva20-tune"
>>      > > TUNE_FEATURES:tune-my-rva20-tune =
>>     "${@oe.tune.riscv_isa_to_tune('rv64gc')} ziccamoa ziccif zicclsm ziccrse
>>     zicntr za128rs"
>>      > > PACKAGE_EXTRA_ARCHS:tune-my-rva20-tune = "${TUNE_RISCV_PKGARCH}"
>>      > > DEFAULTTUNE = "my-rva20-tune"
>>      >
>>      > then 'bitbake-getvar --value TUNE_PKGARCH' shows that it is recognized
>>      > as the RVA20 profile:
>>      >
>>      > > rva20u64_zifencei
>>      >
>>      > Extensions implied by others (e.g. 'zmmul', implied by 'm') don't need
>>      > to be listed, but if they are the same result is obtained.
>>      >
>>      > With all of this combined, subdirectories in tmp/work/ look like:
>>      >
>>      > > tgamblin@megalith ~/workspace/ypbuilds/poky-qemuriscv64 $ ls
>>     build/tmp/work/
>>      > > all-poky-linux          qemuriscv64-poky-linux                 
>>       rva20u64_zcmop_zifencei_zihintpause_zimop_zvbb-poky-linux 
>>     rva23u64_zifencei-poky-linux
>>      > > qemuriscv32-poky-linux  riscv32imafdc_zicsr_zifencei-poky-linux 
>>     rva20u64_zifencei-poky-linux                               x86_64-linux
>>      >
>>      > Note that 'rva20u64_zcmop_zifencei_zihintpause_zimop_zvbb-poky-linux' is
>>      > a custom configuration that I set in local.conf only for testing
>>      > purposes. Custom tunings still run the ris(c|k) of exceeding the naming
>>      > length, which we may need some extra hashing logic (maybe a bitmask?) to
>>      > handle if we want to enable freely customizing build tunings.
>> 
>>     I think this approach makes a lot of sense, given the way RISC-V
>>     extensions work it's probably the only way to make things readable.
>> 
>>      >
>>      > # Testing
>>      >
>>      > Testing different profiles' validity against the compiler involved
>>      > setting (for example) DEFAULTTUNE = "rva23u64" and then running 'bitbake
>>      > opensbi' (which also results in a kernel rebuild) as a quick smoke test.
>>      > I've also opted to do full image builds to make sure that the new
>>      > profiles fully boot and run without any obvious errors. I've also run a
>>      > series of boot tests (including ptests for packages like coreutils).
>>      > Note that when the vector extension is enabled (riscv64gcv, rva23u64),
>>      > test durations will generally be higher.
>>      >
>>      > As of v2, I've added some selftests to help:
>>      >
>>      > 1. The 'oelib.tune' suite at meta/lib/oeqa/selftest/cases/oelib/tune.py,
>>      >    for testing the riscv_pkgarch(), riscv_isa_to_tune(), and
>>      >    riscv_implied() functions
>>      > 2. The 'riscvtune' suite at meta/lib/oeqa/selftest/cases/riscvtune.py,
>>      >    for parsing and building against defined and unusual custom tunes to
>>      >    ensure they each yield a usable package arch
>> 
>>     Looking at qemuriscv.inc we set QB_CPU to rva23s64 for qemuriscv64. I
>>     think we should do some boot testing with different QB_CPU values (e.g.
>>     build for rva20 and test with rva20 virtual CPU).
>> 
>>     Long term we may want to set the default TUNE for qemuriscv64 to align
>>     with RVA23.
>> 
>>     Best regards,
>> 
>>     -- 
>>     Paul Barker
>>