[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


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


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


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


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


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


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


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