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,
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#247438):
https://lists.openembedded.org/g/openembedded-core/message/247438
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]]
-=-=-=-=-=-=-=-=-=-=-=-
