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.
> 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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#247019):
https://lists.openembedded.org/g/openembedded-core/message/247019
Mute This Topic: https://lists.openembedded.org/mt/121511748/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
