| Message ID | 1750040965-15015-1-git-send-email-mark.hatle@kernel.crashing.org |
|---|---|
| Headers | show |
| Series | ISA based RISC-V tune implementation | expand |
On 6/16/25 04:29, Mark Hatle via lists.openembedded.org wrote: > From: Mark Hatle <mark.hatle@amd.com> > > The following implements the risc-v processor tune based on the ISA approach > as documented in the oe-architecture post: > > https://lists.openembedded.org/g/openembedded-architecture/message/2155 > > This set also attempts to make u-boot and kernel configurations dynamic > based on the TUNE_FEATURES. > > For the linux-yocto, I suspect that the config fragments should be > sent to the kmeta (kernel-cache), but I'd like a review from Bruce and > others before I do this. > > Additionally, this enables a new (optional) features_check for TUNE_FEATURES. > > I've found numerous items in the system have certain RISC-V ISA expectations > that may need to be addressed over time, however the obvious one is the > Linux kernel requires ima_zicsr_zifencei. Since it has it's own -march= > setting this will ensure the processor defintion will be compatible. > > Also dynamically configure the QEMU cpu based on the tune_features. This > is nice to ensure that what we're actually building should be able to run > on real hardware. However, it does highlight some of the (extension) > limitations in the current design. (limitations as in extension not yet > enabled.) > > Note: OpenSBI _requires_ the 'c' extension or it will not execute. I > suspect this can be fixed, but it's beyond my capabilities at this time. > I'm not a particularly advanced risc-v user, but I use qemuriscv64 to run smoketests on Firefox, with a barely-extended core-image-sato. After applying your this patch series, librsvg fails to compile with lot of "undefined reference" errors[1]. I haven't looked into this at all yet, hoping that someone would know the solution from the top of the head. Does this need some magic Rust flag maybe? Beside applying this series, I didn't do any other modifications, and without these changes librsvg builds (did I miss some new config, or another patch?) . [1]: full log: https://gist.githubusercontent.com/OldManYellsAtCloud/e9968f3c63df943e8fd54dc217ab15e6/raw
On 6/16/25 5:11 AM, Gyorgy Sarvari wrote: > On 6/16/25 04:29, Mark Hatle via lists.openembedded.org wrote: >> From: Mark Hatle <mark.hatle@amd.com> >> >> The following implements the risc-v processor tune based on the ISA approach >> as documented in the oe-architecture post: >> >> https://lists.openembedded.org/g/openembedded-architecture/message/2155 >> >> This set also attempts to make u-boot and kernel configurations dynamic >> based on the TUNE_FEATURES. >> >> For the linux-yocto, I suspect that the config fragments should be >> sent to the kmeta (kernel-cache), but I'd like a review from Bruce and >> others before I do this. >> >> Additionally, this enables a new (optional) features_check for TUNE_FEATURES. >> >> I've found numerous items in the system have certain RISC-V ISA expectations >> that may need to be addressed over time, however the obvious one is the >> Linux kernel requires ima_zicsr_zifencei. Since it has it's own -march= >> setting this will ensure the processor defintion will be compatible. >> >> Also dynamically configure the QEMU cpu based on the tune_features. This >> is nice to ensure that what we're actually building should be able to run >> on real hardware. However, it does highlight some of the (extension) >> limitations in the current design. (limitations as in extension not yet >> enabled.) >> >> Note: OpenSBI _requires_ the 'c' extension or it will not execute. I >> suspect this can be fixed, but it's beyond my capabilities at this time. >> > > I'm not a particularly advanced risc-v user, but I use qemuriscv64 to > run smoketests on Firefox, with a barely-extended core-image-sato. > > After applying your this patch series, librsvg fails to compile with lot > of "undefined reference" errors[1]. I haven't looked into this at all > yet, hoping that someone would know the solution from the top of the > head. Does this need some magic Rust flag maybe? > > Beside applying this series, I didn't do any other modifications, and > without these changes librsvg builds (did I miss some new config, or > another patch?) . The ONLY patch required to test this is the first one, the rest are all additional functionality based on the first patch. Honestly I have no idea how to debug this. The configuration selected: -march=rv64imafdc_zicsr_zifencei -mabi=lp64d is perfectly reasonable and contains the 'a' (atomic) operations, so I don't know how or why these atomic_loads_4 and _8 would not be defined, yet used by the compiler. I do see a reference in the error message to: .text._ZN69_$LT$smallvec..SmallVec$LT$A$GT$$u20$as$u20$core This configuration has _vector_ (v) support _disabled_. Could there be something in the toolchain that is assuming vector support is always enabled, if so that could be a large part of the problem. @Khem any ideas? > > [1]: full log: > https://gist.githubusercontent.com/OldManYellsAtCloud/e9968f3c63df943e8fd54dc217ab15e6/raw
On 6/16/25 9:12 AM, Mark Hatle wrote: > > > On 6/16/25 5:11 AM, Gyorgy Sarvari wrote: >> On 6/16/25 04:29, Mark Hatle via lists.openembedded.org wrote: >>> From: Mark Hatle <mark.hatle@amd.com> >>> >>> The following implements the risc-v processor tune based on the ISA approach >>> as documented in the oe-architecture post: >>> >>> https://lists.openembedded.org/g/openembedded-architecture/message/2155 >>> >>> This set also attempts to make u-boot and kernel configurations dynamic >>> based on the TUNE_FEATURES. >>> >>> For the linux-yocto, I suspect that the config fragments should be >>> sent to the kmeta (kernel-cache), but I'd like a review from Bruce and >>> others before I do this. >>> >>> Additionally, this enables a new (optional) features_check for TUNE_FEATURES. >>> >>> I've found numerous items in the system have certain RISC-V ISA expectations >>> that may need to be addressed over time, however the obvious one is the >>> Linux kernel requires ima_zicsr_zifencei. Since it has it's own -march= >>> setting this will ensure the processor defintion will be compatible. >>> >>> Also dynamically configure the QEMU cpu based on the tune_features. This >>> is nice to ensure that what we're actually building should be able to run >>> on real hardware. However, it does highlight some of the (extension) >>> limitations in the current design. (limitations as in extension not yet >>> enabled.) >>> >>> Note: OpenSBI _requires_ the 'c' extension or it will not execute. I >>> suspect this can be fixed, but it's beyond my capabilities at this time. >>> >> >> I'm not a particularly advanced risc-v user, but I use qemuriscv64 to >> run smoketests on Firefox, with a barely-extended core-image-sato. >> >> After applying your this patch series, librsvg fails to compile with lot >> of "undefined reference" errors[1]. I haven't looked into this at all >> yet, hoping that someone would know the solution from the top of the >> head. Does this need some magic Rust flag maybe? >> >> Beside applying this series, I didn't do any other modifications, and >> without these changes librsvg builds (did I miss some new config, or >> another patch?) . > > The ONLY patch required to test this is the first one, the rest are all > additional functionality based on the first patch. > > Honestly I have no idea how to debug this. The configuration selected: > > -march=rv64imafdc_zicsr_zifencei -mabi=lp64d > > is perfectly reasonable and contains the 'a' (atomic) operations, so I don't > know how or why these atomic_loads_4 and _8 would not be defined, yet used by > the compiler. > > I do see a reference in the error message to: > > .text._ZN69_$LT$smallvec..SmallVec$LT$A$GT$$u20$as$u20$core > > This configuration has _vector_ (v) support _disabled_. > > Could there be something in the toolchain that is assuming vector support is > always enabled, if so that could be a large part of the problem. > > @Khem any ideas? I've reproduced the issue. This due to RUST. I'm also getting additional error messages about the ABI being incorrect (it's definitely not incorrect), so rust itself is configured in correctly after this change. Still investigating. --Mark >> >> [1]: full log: >> https://gist.githubusercontent.com/OldManYellsAtCloud/e9968f3c63df943e8fd54dc217ab15e6/raw >> >> >> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> View/Reply Online (#218827): https://lists.openembedded.org/g/openembedded-core/message/218827 >> Mute This Topic: https://lists.openembedded.org/mt/113664652/3616948 >> Group Owner: openembedded-core+owner@lists.openembedded.org >> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [mark.hatle@kernel.crashing.org] >> -=-=-=-=-=-=-=-=-=-=-=- >>
From: Mark Hatle <mark.hatle@amd.com> The following implements the risc-v processor tune based on the ISA approach as documented in the oe-architecture post: https://lists.openembedded.org/g/openembedded-architecture/message/2155 This set also attempts to make u-boot and kernel configurations dynamic based on the TUNE_FEATURES. For the linux-yocto, I suspect that the config fragments should be sent to the kmeta (kernel-cache), but I'd like a review from Bruce and others before I do this. Additionally, this enables a new (optional) features_check for TUNE_FEATURES. I've found numerous items in the system have certain RISC-V ISA expectations that may need to be addressed over time, however the obvious one is the Linux kernel requires ima_zicsr_zifencei. Since it has it's own -march= setting this will ensure the processor defintion will be compatible. Also dynamically configure the QEMU cpu based on the tune_features. This is nice to ensure that what we're actually building should be able to run on real hardware. However, it does highlight some of the (extension) limitations in the current design. (limitations as in extension not yet enabled.) Note: OpenSBI _requires_ the 'c' extension or it will not execute. I suspect this can be fixed, but it's beyond my capabilities at this time. Mark Hatle (6): riscv tunes: ISA Implementation of RISC-V tune features linux-yocto: Enable risc-v TUNE_FEATURES ISA selections u-boot: Dynamic RISC-V ISA configuration qemuriscv: Dynamically configure qemu CPU features_check.bbclass: Add support for required TUNE_FEATURES linux-yocto.inc: State riscv required tune_features meta/classes-recipe/features_check.bbclass | 2 +- meta/conf/machine/include/riscv/README | 122 ++++++++++++++++ .../conf/machine/include/riscv/arch-riscv.inc | 138 +++++++++++++++++- meta/conf/machine/include/riscv/qemuriscv.inc | 31 +++- .../conf/machine/include/riscv/tune-riscv.inc | 40 ++--- meta/conf/machine/qemuriscv32.conf | 4 +- meta/lib/oe/__init__.py | 2 +- meta/lib/oe/tune.py | 81 ++++++++++ .../u-boot/files/u-boot-riscv-isa_a.cfg | 1 + .../u-boot/files/u-boot-riscv-isa_c.cfg | 1 + .../u-boot/files/u-boot-riscv-isa_clear.cfg | 6 + .../u-boot/files/u-boot-riscv-isa_d.cfg | 1 + .../u-boot/files/u-boot-riscv-isa_f.cfg | 1 + .../u-boot/files/u-boot-riscv-isa_zbb.cfg | 1 + .../u-boot/files/u-boot-riscv-isa_zicbom.cfg | 1 + meta/recipes-bsp/u-boot/u-boot-common.inc | 12 ++ .../linux/files/risc-v-isa-c.cfg | 1 + .../linux/files/risc-v-isa-clear.cfg | 9 ++ .../linux/files/risc-v-isa-fpu.cfg | 1 + .../linux/files/risc-v-isa-rv32i.cfg | 2 + .../linux/files/risc-v-isa-rv64i.cfg | 2 + .../linux/files/risc-v-isa-v.cfg | 1 + .../linux/files/risc-v-isa-zbb.cfg | 1 + .../linux/files/risc-v-isa-zicbom.cfg | 1 + meta/recipes-kernel/linux/linux-yocto.inc | 19 +++ 25 files changed, 439 insertions(+), 42 deletions(-) create mode 100644 meta/conf/machine/include/riscv/README create mode 100644 meta/lib/oe/tune.py create mode 100644 meta/recipes-bsp/u-boot/files/u-boot-riscv-isa_a.cfg create mode 100644 meta/recipes-bsp/u-boot/files/u-boot-riscv-isa_c.cfg create mode 100644 meta/recipes-bsp/u-boot/files/u-boot-riscv-isa_clear.cfg create mode 100644 meta/recipes-bsp/u-boot/files/u-boot-riscv-isa_d.cfg create mode 100644 meta/recipes-bsp/u-boot/files/u-boot-riscv-isa_f.cfg create mode 100644 meta/recipes-bsp/u-boot/files/u-boot-riscv-isa_zbb.cfg create mode 100644 meta/recipes-bsp/u-boot/files/u-boot-riscv-isa_zicbom.cfg create mode 100644 meta/recipes-kernel/linux/files/risc-v-isa-c.cfg create mode 100644 meta/recipes-kernel/linux/files/risc-v-isa-clear.cfg create mode 100644 meta/recipes-kernel/linux/files/risc-v-isa-fpu.cfg create mode 100644 meta/recipes-kernel/linux/files/risc-v-isa-rv32i.cfg create mode 100644 meta/recipes-kernel/linux/files/risc-v-isa-rv64i.cfg create mode 100644 meta/recipes-kernel/linux/files/risc-v-isa-v.cfg create mode 100644 meta/recipes-kernel/linux/files/risc-v-isa-zbb.cfg create mode 100644 meta/recipes-kernel/linux/files/risc-v-isa-zicbom.cfg