I will review rest of series in detail later
On Thu, Oct 1, 2026, 11:13 AM Paul Barker <[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.
>
> > 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 (#247428):
https://lists.openembedded.org/g/openembedded-core/message/247428
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]]
-=-=-=-=-=-=-=-=-=-=-=-
