[PATCH dunfell 0/3] fix ARAGO_BRAND=mainline builds

[PATCH dunfell 0/3] fix ARAGO_BRAND=mainline builds

[Drew Fustini]

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

[PATCH dunfell 1/3] conf: am57xx-evm: avoid missing dtb files when ARAGO_BRAND=mainline

[Drew Fustini]

For ARAGO_BRAND=mainline with the am57xx-evm MACHINE, avoid the
inclusion of device tree files that do not exist upstream.

Signed-off-by: Drew Fustini <dfustini@baylibre.com>
---
 conf/machine/am57xx-evm.conf | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/conf/machine/am57xx-evm.conf b/conf/machine/am57xx-evm.conf
index afcfbb4318ad..2fde75fe7603 100644
--- a/conf/machine/am57xx-evm.conf
+++ b/conf/machine/am57xx-evm.conf
@@ -13,9 +13,9 @@ KERNEL_DEVICETREE = " \
     am57xx-beagle-x15-revb1.dtb \
     am57xx-beagle-x15-revc.dtb \
     am5729-beagleboneai.dtb \
-    am57xx-evm.dtb \
+    ${@oe.utils.conditional('ARAGO_BRAND', 'mainline', '', 'am57xx-evm.dtb', d)} \
     ti/am57xx-evm-common.dtbo \
-    am57xx-evm-reva3.dtb \
+    ${@oe.utils.conditional('ARAGO_BRAND', 'mainline', '', 'am57xx-evm-reva3.dtb', d)} \
     ti/am57xx-evm-reva3.dtbo \
     am571x-idk.dtb \
     ti/am571x-idk-touchscreen.dtbo \
@@ -25,7 +25,7 @@ KERNEL_DEVICETREE = " \
     ti/am572x-idk-touchscreen.dtbo \
     ti/lcd-osd101t2587.dtbo \
     ti/lcd-osd101t2045.dtbo \
-    ti/ov10635.dtbo \
+    ${@oe.utils.conditional('ARAGO_BRAND', 'mainline', '', 'ti/ov10635.dtbo', d)} \
 "
 
 KERNEL_DEVICETREE += "${@oe.utils.conditional('ENABLE_TI_UIO_DEVICES', '1', 'am574x-idk-pru-excl-uio.dtb am572x-idk-pru-excl-uio.dtb am571x-idk-pru-excl-uio.dtb', '', d)}"
-- 
2.32.0

[PATCH dunfell 2/3] conf: dra7xx-evm: avoid missing dtb files when ARAGO_BRAND=mainline

[Drew Fustini]

For ARAGO_BRAND=mainline with the dra7xx-evm MACHINE, avoid the
inclusion of device tree files that do not exist upstream.

Signed-off-by: Drew Fustini <dfustini@baylibre.com>
---
 conf/machine/dra7xx-evm.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/machine/dra7xx-evm.conf b/conf/machine/dra7xx-evm.conf
index db4a5e1ca5fe..128205735c93 100644
--- a/conf/machine/dra7xx-evm.conf
+++ b/conf/machine/dra7xx-evm.conf
@@ -12,7 +12,7 @@ KERNEL_DEVICETREE = " \
     dra7-evm.dtb \
     ti/dra7x-evm-osd-lcd-common.dtbo \
     dra71-evm.dtb \
-    dra71-evm-nand.dtb \
+    ${@oe.utils.conditional('ARAGO_BRAND', 'mainline', '', 'dra71-evm-nand.dtb', d)} \
     ti/dra71-evm-lcd-auo-g101evn01.0.dtbo \
     dra72-evm.dtb \
     dra72-evm-revc.dtb \
-- 
2.32.0

[PATCH dunfell 3/3] conf: am43: avoid missing dtb files when ARAGO_BRAND=mainline

[Drew Fustini]

For ARAGO_BRAND=mainline with the am43xx machines, avoid the inclusion
of device tree files that do not exist upstream.

Signed-off-by: Drew Fustini <dfustini@baylibre.com>
---
 conf/machine/include/ti43x.inc | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/conf/machine/include/ti43x.inc b/conf/machine/include/ti43x.inc
index fc9af94921c4..729b42742303 100644
--- a/conf/machine/include/ti43x.inc
+++ b/conf/machine/include/ti43x.inc
@@ -27,9 +27,11 @@ PREFERRED_PROVIDER_u-boot = "u-boot-ti-staging"
 KERNEL_IMAGETYPE = "zImage"
 
 KERNEL_DEVICETREE = " \
-    am437x-gp-evm.dtb am437x-gp-evm-hdmi.dtb \
+    am437x-gp-evm.dtb \
+    ${@oe.utils.conditional('ARAGO_BRAND', 'mainline', '', 'am437x-gp-evm-hdmi.dtb', d)} \
     am437x-sk-evm.dtb am437x-idk-evm.dtb \
-    am43x-epos-evm.dtb am43x-epos-evm-hdmi.dtb \
+    am43x-epos-evm.dtb \
+    ${@oe.utils.conditional('ARAGO_BRAND', 'mainline', '', 'am43x-epos-evm-hdmi.dtb', d)} \
 "
 
 KERNEL_DEVICETREE += "${@oe.utils.conditional('ENABLE_TI_UIO_DEVICES', '1', 'am437x-idk-pru-excl-uio.dtb', '', d)}"
-- 
2.32.0

Re: [meta-ti] [PATCH dunfell 0/3] fix ARAGO_BRAND=mainline builds

[Denys Dmytriyenko]

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

Re: [meta-ti] [PATCH dunfell 0/3] fix ARAGO_BRAND=mainline builds

[Nishanth Menon]

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.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

Re: [meta-ti] [PATCH dunfell 0/3] fix ARAGO_BRAND=mainline builds

[Denys Dmytriyenko]

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...

-- 
Denys

Re: [meta-ti] [PATCH dunfell 0/3] fix ARAGO_BRAND=mainline builds

[Andrew Davis]

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]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

Re: [meta-ti] [PATCH dunfell 0/3] fix ARAGO_BRAND=mainline builds

[Denys Dmytriyenko]

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...

Re: [meta-ti] [PATCH dunfell 0/3] fix ARAGO_BRAND=mainline builds

[Drew Fustini]

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

Re: [meta-ti] [PATCH dunfell 0/3] fix ARAGO_BRAND=mainline builds

[Denys Dmytriyenko]

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

-- 
Denys