| Message ID | 20220704030607.2292135-1-dfustini@baylibre.com |
|---|---|
| Headers | show |
| Series | fix ARAGO_BRAND=mainline builds | expand |
I was thinking that instead of keying off of ARAGO_BRAND=mainline, which is very specific to Arago distro, long term we should instead key off of PREFERRED_PROVIDER_virtual/kernel=linux-ti-mainline, that is specific to meta-ti... Thoughts? On Sun, Jul 03, 2022 at 08:06:06PM -0700, Drew Fustini wrote: > Builds for ARAGO_BRAND=mainline are failing for the following machines: > > - dra7xx-evm > - am57xx-evm > - am437x-evm > > This is beause the above machine configurations include files in their > KERNEL_DEVICETREE variable that do not exist upstream. Therefore the > image creation task fails when it tries to copy device tree files that > do not exist. > > This series of patches use '@oe.utils.conditional' to avoid adding those > device tree files to KERNEL_DEVICETREE when ARAGO_BRAND=mainline. Thus > the image create task is then able to complete successfully regardless > of which kernel recipe is being used. > > Drew Fustini (3): > conf: am57xx-evm: avoid missing dtb files when ARAGO_BRAND=mainline > conf: dra7xx-evm: avoid missing dtb files when ARAGO_BRAND=mainline > conf: am43: avoid missing dtb files when ARAGO_BRAND=mainline > > conf/machine/am57xx-evm.conf | 6 +++--- > conf/machine/dra7xx-evm.conf | 2 +- > conf/machine/include/ti43x.inc | 6 ++++-- > 3 files changed, 8 insertions(+), 6 deletions(-) > > -- > 2.32.0
On 23:18-20220718, Denys Dmytriyenko wrote: > I was thinking that instead of keying off of ARAGO_BRAND=mainline, which > is very specific to Arago distro, long term we should instead key off of > PREFERRED_PROVIDER_virtual/kernel=linux-ti-mainline, that is specific to > meta-ti... Thoughts? We'd want mainline kernel, u-boot, tf-a, optee ..... as many upstream components as possible. is there a way to create a virtual package group that points to all upstream base components? I am looking for ways we can enable this beyond just arago brand.
On Tue, Jul 19, 2022 at 08:22:01AM -0500, Nishanth Menon wrote: > On 23:18-20220718, Denys Dmytriyenko wrote: > > I was thinking that instead of keying off of ARAGO_BRAND=mainline, which > > is very specific to Arago distro, long term we should instead key off of > > PREFERRED_PROVIDER_virtual/kernel=linux-ti-mainline, that is specific to > > meta-ti... Thoughts? > > > We'd want mainline kernel, u-boot, tf-a, optee ..... as many upstream > components as possible. is there a way to create a virtual package group > that points to all upstream base components? > > I am looking for ways we can enable this beyond just arago brand. My understanding is that tf-a and optee were initially forked for K3 development, but these days are pretty much the same as upstream. And optee is already pulling code from upstream, just pinning down to a specific version and doing some extra TI-specific signing on top. As of tf-a, I'd recommend dropping git.ti.com fork completely and pulling from upstream, if possible. But kernel/U-boot is a bit more involved. Those are done as multiple providers and require switching corresponding PREFERRED_PROVIDER variables. Either way, for testing which kernel is being built (ti-staging or mainline) and which U-boot (ti-staging or mainline), checking PREFERRED_PROVIDER should be doable and Distro-agnostic. As of creating a virtual package group, it might be a bit challenging. Since if you try building linux-ti-mainline w/o switching preferred provider, you'd get an error saying there's a conflict between 2 kernels. It would be more involved to solve this w/o simply switching providers, maybe with multiconfig, or something like that...
On 7/19/22 2:51 PM, Denys Dmytriyenko wrote: > On Tue, Jul 19, 2022 at 08:22:01AM -0500, Nishanth Menon wrote: >> On 23:18-20220718, Denys Dmytriyenko wrote: >>> I was thinking that instead of keying off of ARAGO_BRAND=mainline, which >>> is very specific to Arago distro, long term we should instead key off of >>> PREFERRED_PROVIDER_virtual/kernel=linux-ti-mainline, that is specific to >>> meta-ti... Thoughts? >> >> >> We'd want mainline kernel, u-boot, tf-a, optee ..... as many upstream >> components as possible. is there a way to create a virtual package group >> that points to all upstream base components? >> >> I am looking for ways we can enable this beyond just arago brand. > > My understanding is that tf-a and optee were initially forked for K3 > development, but these days are pretty much the same as upstream. > > And optee is already pulling code from upstream, just pinning down to a > specific version and doing some extra TI-specific signing on top. > > As of tf-a, I'd recommend dropping git.ti.com fork completely and pulling > from upstream, if possible. > Great minds.., 26998f43 :) Andrew > But kernel/U-boot is a bit more involved. Those are done as multiple > providers and require switching corresponding PREFERRED_PROVIDER > variables. > > Either way, for testing which kernel is being built (ti-staging or mainline) > and which U-boot (ti-staging or mainline), checking PREFERRED_PROVIDER > should be doable and Distro-agnostic. > > As of creating a virtual package group, it might be a bit challenging. > Since if you try building linux-ti-mainline w/o switching preferred provider, > you'd get an error saying there's a conflict between 2 kernels. > > It would be more involved to solve this w/o simply switching providers, > maybe with multiconfig, or something like that... > > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#14883): https://lists.yoctoproject.org/g/meta-ti/message/14883 > Mute This Topic: https://lists.yoctoproject.org/mt/92158565/3619733 > Group Owner: meta-ti+owner@lists.yoctoproject.org > Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [afd@ti.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On Tue, Jul 19, 2022 at 03:15:10PM -0500, Andrew Davis wrote: > On 7/19/22 2:51 PM, Denys Dmytriyenko wrote: > >On Tue, Jul 19, 2022 at 08:22:01AM -0500, Nishanth Menon wrote: > >>On 23:18-20220718, Denys Dmytriyenko wrote: > >>>I was thinking that instead of keying off of ARAGO_BRAND=mainline, which > >>>is very specific to Arago distro, long term we should instead key off of > >>>PREFERRED_PROVIDER_virtual/kernel=linux-ti-mainline, that is specific to > >>>meta-ti... Thoughts? > >> > >> > >>We'd want mainline kernel, u-boot, tf-a, optee ..... as many upstream > >>components as possible. is there a way to create a virtual package group > >>that points to all upstream base components? > >> > >>I am looking for ways we can enable this beyond just arago brand. > > > >My understanding is that tf-a and optee were initially forked for K3 > >development, but these days are pretty much the same as upstream. > > > >And optee is already pulling code from upstream, just pinning down to a > >specific version and doing some extra TI-specific signing on top. > > > >As of tf-a, I'd recommend dropping git.ti.com fork completely and pulling > >from upstream, if possible. > > > Great minds.., 26998f43 :) Right, that got merged to dunfell and is in my queue for master/kirkstone sync-up to be posted shortly... > >But kernel/U-boot is a bit more involved. Those are done as multiple > >providers and require switching corresponding PREFERRED_PROVIDER > >variables. > > > >Either way, for testing which kernel is being built (ti-staging or mainline) > >and which U-boot (ti-staging or mainline), checking PREFERRED_PROVIDER > >should be doable and Distro-agnostic. > > > >As of creating a virtual package group, it might be a bit challenging. > >Since if you try building linux-ti-mainline w/o switching preferred provider, > >you'd get an error saying there's a conflict between 2 kernels. > > > >It would be more involved to solve this w/o simply switching providers, > >maybe with multiconfig, or something like that...
On Tue, Jul 19, 2022 at 03:51:02PM -0400, Denys Dmytriyenko wrote: > On Tue, Jul 19, 2022 at 08:22:01AM -0500, Nishanth Menon wrote: > > On 23:18-20220718, Denys Dmytriyenko wrote: > > > I was thinking that instead of keying off of ARAGO_BRAND=mainline, which > > > is very specific to Arago distro, long term we should instead key off of > > > PREFERRED_PROVIDER_virtual/kernel=linux-ti-mainline, that is specific to > > > meta-ti... Thoughts? > > > > > > We'd want mainline kernel, u-boot, tf-a, optee ..... as many upstream > > components as possible. is there a way to create a virtual package group > > that points to all upstream base components? > > > > I am looking for ways we can enable this beyond just arago brand. > > My understanding is that tf-a and optee were initially forked for K3 > development, but these days are pretty much the same as upstream. > > And optee is already pulling code from upstream, just pinning down to a > specific version and doing some extra TI-specific signing on top. > > As of tf-a, I'd recommend dropping git.ti.com fork completely and pulling > from upstream, if possible. > > But kernel/U-boot is a bit more involved. Those are done as multiple > providers and require switching corresponding PREFERRED_PROVIDER > variables. > > Either way, for testing which kernel is being built (ti-staging or mainline) > and which U-boot (ti-staging or mainline), checking PREFERRED_PROVIDER > should be doable and Distro-agnostic. Thank you for the suggestion. Would the conditional then being something like this? ${@oe.utils.conditional('PREFERRED_PROVIDER_virtual/kernel', 'linux-ti-mainline', '', 'dra71-evm-nand.dtb', d)} Drew
On Wed, Jul 20, 2022 at 01:45:24PM -0700, Drew Fustini wrote: > On Tue, Jul 19, 2022 at 03:51:02PM -0400, Denys Dmytriyenko wrote: > > On Tue, Jul 19, 2022 at 08:22:01AM -0500, Nishanth Menon wrote: > > > On 23:18-20220718, Denys Dmytriyenko wrote: > > > > I was thinking that instead of keying off of ARAGO_BRAND=mainline, which > > > > is very specific to Arago distro, long term we should instead key off of > > > > PREFERRED_PROVIDER_virtual/kernel=linux-ti-mainline, that is specific to > > > > meta-ti... Thoughts? > > > > > > > > > We'd want mainline kernel, u-boot, tf-a, optee ..... as many upstream > > > components as possible. is there a way to create a virtual package group > > > that points to all upstream base components? > > > > > > I am looking for ways we can enable this beyond just arago brand. > > > > My understanding is that tf-a and optee were initially forked for K3 > > development, but these days are pretty much the same as upstream. > > > > And optee is already pulling code from upstream, just pinning down to a > > specific version and doing some extra TI-specific signing on top. > > > > As of tf-a, I'd recommend dropping git.ti.com fork completely and pulling > > from upstream, if possible. > > > > But kernel/U-boot is a bit more involved. Those are done as multiple > > providers and require switching corresponding PREFERRED_PROVIDER > > variables. > > > > Either way, for testing which kernel is being built (ti-staging or mainline) > > and which U-boot (ti-staging or mainline), checking PREFERRED_PROVIDER > > should be doable and Distro-agnostic. > > Thank you for the suggestion. > > Would the conditional then being something like this? > > ${@oe.utils.conditional('PREFERRED_PROVIDER_virtual/kernel', 'linux-ti-mainline', '', 'dra71-evm-nand.dtb', d)} LGTM. Thanks