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

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

On Thu Oct 1, 2026 at 5:13 AM EDT, Paul Barker 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.

Alright. Do you want me to resubmit them as a smaller, separate series?

>
>> 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.

Yes, that is the idea (in addition to supporting more profiles for development).
I am fine with adding these to meta-riscv in the short-term.
>
>> 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.

Ack.

Trevor

>
>> 
>> # 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,