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 <[email protected]
<mailto:[email protected]>> 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.
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.
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.
> 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 (#247435):
https://lists.openembedded.org/g/openembedded-core/message/247435
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]]
-=-=-=-=-=-=-=-=-=-=-=-
