| Message ID | 20250616184607.92039-2-alexander.sowarka@linaro.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Change genericarm64 machine to use the in-tree kernel config | expand |
On 16 Jun 2025, at 19:46, Alexander Sowarka via lists.yoctoproject.org <alexander.sowarka=linaro.org@lists.yoctoproject.org> wrote: > > The genericarm64 machine should run on most ARM SystemReady devices. > The arm64 configuration in the mainline kernel repository works stable > on a lot more devices then the poky internal one. > Switch to using the in-tree kernel config to run on more SystemReady > devices. This was almost by design: the initial target platform was the BeaglePlay, and then the Xilinx KV260. As the co-maintainer of this BSP I’d _much_ prefer to see the gaps fixed instead of upstream defconfig used blindly. It’s an unusual upstream release where the defconfig doesn’t result in configuration warnings, and we have a general ethos that modular configurations are better than a single monolithic defconfig. Ross
On Mon, Jun 16, 2025 at 3:05 PM Ross Burton via lists.yoctoproject.org <ross.burton=arm.com@lists.yoctoproject.org> wrote: > On 16 Jun 2025, at 19:46, Alexander Sowarka via lists.yoctoproject.org > <alexander.sowarka=linaro.org@lists.yoctoproject.org> wrote: > > > > The genericarm64 machine should run on most ARM SystemReady devices. > > The arm64 configuration in the mainline kernel repository works stable > > on a lot more devices then the poky internal one. > > Switch to using the in-tree kernel config to run on more SystemReady > > devices. > > This was almost by design: the initial target platform was the BeaglePlay, > and then the Xilinx KV260. > > As the co-maintainer of this BSP I’d _much_ prefer to see the gaps fixed > instead of upstream defconfig used blindly. It’s an unusual upstream > release where the defconfig doesn’t result in configuration warnings, and > we have a general ethos that modular configurations are better than a > single monolithic defconfig. > And as one of our reference platforms, that's a hard NO from me (the in tree defconfig). We do our references by the yocto policy, not the kitchen-sink in tree defconfig. If there's issues with the fragments, fix them. Not this. There's absolutely nothing by accident about the way we do it currently. Bruce > > Ross > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#13651): > https://lists.yoctoproject.org/g/poky/message/13651 > Mute This Topic: https://lists.yoctoproject.org/mt/113676396/1050810 > Group Owner: poky+owner@lists.yoctoproject.org > Unsubscribe: https://lists.yoctoproject.org/g/poky/unsub [ > bruce.ashfield@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
Understood. I will talk with ARM internally how they would wish to handle it. I sadly do not think that board manufactures care to enable the genericarm64 machine for their platform. ARM used the upstream kernel config in other places to create images that boot on most platforms. So I thought it would be useful. I will advise them to do something in their own layer if desired. Kind regards, Alexander Sowarka On Mon, 16 Jun 2025 at 20:49, Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > On Mon, Jun 16, 2025 at 3:05 PM Ross Burton via lists.yoctoproject.org > <ross.burton=arm.com@lists.yoctoproject.org> wrote: > >> On 16 Jun 2025, at 19:46, Alexander Sowarka via lists.yoctoproject.org >> <alexander.sowarka=linaro.org@lists.yoctoproject.org> wrote: >> > >> > The genericarm64 machine should run on most ARM SystemReady devices. >> > The arm64 configuration in the mainline kernel repository works stable >> > on a lot more devices then the poky internal one. >> > Switch to using the in-tree kernel config to run on more SystemReady >> > devices. >> >> This was almost by design: the initial target platform was the >> BeaglePlay, and then the Xilinx KV260. >> >> As the co-maintainer of this BSP I’d _much_ prefer to see the gaps fixed >> instead of upstream defconfig used blindly. It’s an unusual upstream >> release where the defconfig doesn’t result in configuration warnings, and >> we have a general ethos that modular configurations are better than a >> single monolithic defconfig. >> > > And as one of our reference platforms, that's a hard NO from me (the in > tree defconfig). > > We do our references by the yocto policy, not the kitchen-sink in tree > defconfig. > > If there's issues with the fragments, fix them. Not this. There's > absolutely nothing by > accident about the way we do it currently. > > Bruce > > > >> >> Ross >> >> >> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> View/Reply Online (#13651): >> https://lists.yoctoproject.org/g/poky/message/13651 >> Mute This Topic: https://lists.yoctoproject.org/mt/113676396/1050810 >> Group Owner: poky+owner@lists.yoctoproject.org >> Unsubscribe: https://lists.yoctoproject.org/g/poky/unsub [ >> bruce.ashfield@gmail.com] >> -=-=-=-=-=-=-=-=-=-=-=- >> >> > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await thee > at its end > - "Use the force Harry" - Gandalf, Star Trek II > >
On Mon, Jun 16, 2025 at 8:25 PM Alexander Sowarka < alexander.sowarka@linaro.org> wrote: > Understood. I will talk with ARM internally how they would wish to handle > it. > I sadly do not think that board manufactures care to enable the > genericarm64 > machine for their platform. ARM used the upstream kernel config in other > places > to create images that boot on most platforms. So I thought it would be > useful. > I will advise them to do something in their own layer if desired. > I get the push and pull on this! 14 years working at an OSV and working on the wrangling of configurations all that time (inside and outside of the project) and then continuing to have a different model (and view) from certain h/w companies about their reference/demo-ware configurations (I won't name names). In fact, I maintain multiple parallel configurations with fragments versus in-tree deconfigs. I can help with tooling on this front if needed. There's pros and cons to both. We just chose to have a predictable base, and one that isn't targeted to showing all features, all the time .. just in case. That's what a lot of the defconfigs do (and I'm not claiming one way or the other here). But what we do have in that base is the foundation for keeping the configuration small/tight (when possible) and one that we know enables what we need for the autobuilder testing and then to layer features from higher level layers (i.e. meta-virt) or opt-in / dynamic features. If all the references are using different defconfig bases, then we spend our time chasing a moving base and wondering why a runtime error is happening. Plus, there could be wildly different behaviour from the various platforms even on the same kernel version. BUT, we do spend our time on the fragments. So time is spent no matter what (refer to my pros and cons statement :) Anyway, you could definitely slap the defconfig on top, or replace in a layer and that's my suggestion if the fragments and enabling the h/w features that are required for a super wide / broad enablement just aren't working there. Bruce > > Kind regards, > Alexander Sowarka > > > On Mon, 16 Jun 2025 at 20:49, Bruce Ashfield <bruce.ashfield@gmail.com> > wrote: > >> >> >> On Mon, Jun 16, 2025 at 3:05 PM Ross Burton via lists.yoctoproject.org >> <ross.burton=arm.com@lists.yoctoproject.org> wrote: >> >>> On 16 Jun 2025, at 19:46, Alexander Sowarka via lists.yoctoproject.org >>> <alexander.sowarka=linaro.org@lists.yoctoproject.org> wrote: >>> > >>> > The genericarm64 machine should run on most ARM SystemReady devices. >>> > The arm64 configuration in the mainline kernel repository works stable >>> > on a lot more devices then the poky internal one. >>> > Switch to using the in-tree kernel config to run on more SystemReady >>> > devices. >>> >>> This was almost by design: the initial target platform was the >>> BeaglePlay, and then the Xilinx KV260. >>> >>> As the co-maintainer of this BSP I’d _much_ prefer to see the gaps fixed >>> instead of upstream defconfig used blindly. It’s an unusual upstream >>> release where the defconfig doesn’t result in configuration warnings, and >>> we have a general ethos that modular configurations are better than a >>> single monolithic defconfig. >>> >> >> And as one of our reference platforms, that's a hard NO from me (the in >> tree defconfig). >> >> We do our references by the yocto policy, not the kitchen-sink in tree >> defconfig. >> >> If there's issues with the fragments, fix them. Not this. There's >> absolutely nothing by >> accident about the way we do it currently. >> >> Bruce >> >> >> >>> >>> Ross >>> >>> >>> -=-=-=-=-=-=-=-=-=-=-=- >>> Links: You receive all messages sent to this group. >>> View/Reply Online (#13651): >>> https://lists.yoctoproject.org/g/poky/message/13651 >>> Mute This Topic: https://lists.yoctoproject.org/mt/113676396/1050810 >>> Group Owner: poky+owner@lists.yoctoproject.org >>> Unsubscribe: https://lists.yoctoproject.org/g/poky/unsub [ >>> bruce.ashfield@gmail.com] >>> -=-=-=-=-=-=-=-=-=-=-=- >>> >>> >> >> -- >> - Thou shalt not follow the NULL pointer, for chaos and madness await >> thee at its end >> - "Use the force Harry" - Gandalf, Star Trek II >> >>
diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto-dev.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto-dev.bbappend index 5b1b736b1c..5b3c31f530 100644 --- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto-dev.bbappend +++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto-dev.bbappend @@ -3,6 +3,8 @@ KBRANCH:genericx86-64 = "standard/base" KBRANCH:beaglebone-yocto = "standard/beaglebone" KMACHINE:genericarm64 ?= "genericarm64" +KBUILD_DEFCONFIG:genericarm64 ?= "defconfig" +KCONFIG_MODE:genericarm64 ?= "alldefconfig" KMACHINE:genericx86 ?= "common-pc" KMACHINE:genericx86-64 ?= "common-pc-64" KMACHINE:beaglebone-yocto ?= "beaglebone" diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_6.6.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_6.6.bbappend index 3f33ec991d..2159717cd0 100644 --- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_6.6.bbappend +++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_6.6.bbappend @@ -8,6 +8,8 @@ KBRANCH:genericx86-64 = "v6.6/standard/base" KBRANCH:beaglebone-yocto = "v6.6/standard/beaglebone" KMACHINE:genericarm64 ?= "genericarm64" +KBUILD_DEFCONFIG:genericarm64 ?= "defconfig" +KCONFIG_MODE:genericarm64 ?= "alldefconfig" KMACHINE:genericx86 ?= "common-pc" KMACHINE:genericx86-64 ?= "common-pc-64" KMACHINE:beaglebone-yocto ?= "beaglebone"
The genericarm64 machine should run on most ARM SystemReady devices. The arm64 configuration in the mainline kernel repository works stable on a lot more devices then the poky internal one. Switch to using the in-tree kernel config to run on more SystemReady devices. Signed-off-by: Alexander Sowarka <alexander.sowarka@linaro.org> --- meta-yocto-bsp/recipes-kernel/linux/linux-yocto-dev.bbappend | 2 ++ meta-yocto-bsp/recipes-kernel/linux/linux-yocto_6.6.bbappend | 2 ++ 2 files changed, 4 insertions(+)