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

[Denys Dmytriyenko <denis@denix.org>]

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