[OE-core] [PATCH] classes/kernel-yocto: Apply patches from BSP
Bruce Ashfield
bruce.ashfield at gmail.com
Fri Dec 20 15:09:29 UTC 2019
On Fri, Dec 20, 2019 at 10:07 AM Joshua Watt <jpewhacker at gmail.com> wrote:
>
> On Thu, Dec 19, 2019 at 4:14 PM Bruce Ashfield <bruce.ashfield at gmail.com> wrote:
> >
> > On Thu, Dec 19, 2019 at 4:53 PM Joshua Watt <jpewhacker at gmail.com> wrote:
> > >
> > >
> > > On 12/19/19 3:18 PM, Bruce Ashfield wrote:
> > > > On Thu, Dec 19, 2019 at 3:32 PM Joshua Watt <jpewhacker at gmail.com> wrote:
> > > >> On Thu, Dec 19, 2019 at 1:30 PM Bruce Ashfield <bruce.ashfield at gmail.com> wrote:
> > > >>> On Thu, Dec 19, 2019 at 1:53 PM Joshua Watt <jpewhacker at gmail.com> wrote:
> > > >>>>
> > > >>>> On 12/19/19 12:45 PM, Bruce Ashfield wrote:
> > > >>>>> On Thu, Dec 19, 2019 at 1:38 PM Joshua Watt <jpewhacker at gmail.com> wrote:
> > > >>>>>> 0f698dfd1c8 ("kernel-yocto: streamline patch, configuration and audit
> > > >>>>>> phases") appears to have inadvertently broken support for BSP .scc files
> > > >>>>>> to provide patches for the kernel. Restore this behavior by adding
> > > >>>>>> $bsp_definition to the list of files processed for patches.
> > > >>>>>> Additionally, the logic can be simplified now that the same elements are
> > > >>>>>> used for both configuration fragments and patches
> > > >>>>> Unfortunately no, we can't do this.
> > > >>>>>
> > > >>>>> It would reapply all the patches that are already integrated into the
> > > >>>>> tree, and that distinction is the key part of that change.
> > > >>>>>
> > > >>>>> What exactly are you trying to do ? Define a userspace BSP ? If so,
> > > >>>>> there are examples of this and I can dig them up and send them along.
> > > >>>> We have a lot of boards running different SoCs (each with a different
> > > >>>> vendor provided kernel) and we are trying to keep our sanity managing
> > > >>>> all of the by using a metadata repo. So for example, we have a recipe
> > > >>>> that pulls in vendor A's kernel directly from the upstream source, then
> > > >>>> our local metadata repo which provides the scc files we need to
> > > >>>> configure that repo. Inevitably, we end up needing to patch these
> > > >>>> kernels, so I was hoping that we could provide the patches in the
> > > >>>> metadata repo and add them to the BSP .scc file, but that wasn't working.
> > > >>>>
> > > >>> Right! It does make sense to keep the configs and patches together in
> > > >>> that meta data repo.
> > > >>>
> > > >>> So you have your own kmeta repo, and that's where the BSP definitions
> > > >>> that are being searched and found. Are those definitions completely
> > > >>> standalone, or are they including some of the common yocto ktype
> > > >>> definitions ? (It makes a difference to how they can be included).
> > > >> I think they are standalone (e.g. they don't include any of the ktype files).
> > > >>
> > > >>
> > > >>> I explained the details of the behaviour in an email on Oct 9th, with
> > > >>> the title: "[yocto] Kernel patches pulled from BSP definition file are
> > > >>> not applied.", so I won't repeat that long description here .. except
> > > >>> to say that it is working as intended (but that doesn't mean it is set
> > > >>> in stone .. see below ..). And yes, there are doc updates that need to
> > > >>> happen for this to more clearly explain the design and options.
> > > >>>
> > > >>> That being said, there are a couple of things that can be done, and
> > > >>> one that works right now:
> > > >>>
> > > >>> - The BSP definition SCC needs to be on the SRC_URI itself (as I
> > > >>> describe in that other email), if your kernel recipe's have different
> > > >>> names, that's doable. If they are under a common recipe, that of
> > > >>> course would be harder (but you could use a variable for the MACHINE
> > > >>> and have it work that way).
> > > >> Does that mean the BSP scc files need to be moved from our metadata
> > > >> repo to live alongside the recipe, or is there some special sauce that
> > > >> allows the scc to be specified in SRC_URI, but pulled from our kmeta
> > > >> repo?
> > > > At the moment, yes. Since you need to specify it in SRC_URI where the
> > > > fetcher can find it (obviously :D), which implies that it isn't in
> > > > that separate kernel meta repository.
> > > >
> > > > What, if anything, do you currently have on your SRC_URI ? Just the
> > > > kernel repo and your kernel meta data repo ?
> > >
> > > Yes, that is all we have.
> > >
> > > >
> > > > Let me see if I can come up with a simple way (probably patch) to avoid that.
> > >
> > > That would be great! Thanks.
> > >
> >
> > Attached is my proposed solution. Hopefully the commit log is detailed
> > enough to explain what I'm trying to do :D
> >
> > I've only tested that it doesn't break a standard BSP build, so let me
> > know if this solves your use case, and I'll run some additional tests
> > and send it to the list.
>
> I had to make one minor fix to your patch (the assignment of the sccs
> variable needs the spaces around the "=" removed to be valid shell
> code), but other than that your patch works great for me and does
> exactly what I want.
>
ahah. Right you are. I'll make that tweak and send it to the list.
Bruce
> Thanks!
>
> >
> > Bruce
> >
> > > >
> > > > Bruce
> > > >
> > > >>> That's the one that works now.
> > > >>>
> > > >>> A second option would be if I inject some logic to differentiate an
> > > >>> integrated BSP versus one that requires patching. That's a slippery
> > > >>> slope back into the complex logic that used to be in place, but I can
> > > >>> think of a few viable ways to do it.
> > > >>>
> > > >>> Definitely a use case we can support, it'll just take some tweaking.
> > > >>>
> > > >>> Cheers,
> > > >>>
> > > >>> Bruce
> > > >>>
> > > >>>
> > > >>> Bruce
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>> Bruce
> > > >>>>>
> > > >>>>>> Signed-off-by: Joshua Watt <JPEWhacker at gmail.com>
> > > >>>>>> ---
> > > >>>>>> meta/classes/kernel-yocto.bbclass | 7 ++-----
> > > >>>>>> 1 file changed, 2 insertions(+), 5 deletions(-)
> > > >>>>>>
> > > >>>>>> diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
> > > >>>>>> index ed9bcfa57c..08c02a8f50 100644
> > > >>>>>> --- a/meta/classes/kernel-yocto.bbclass
> > > >>>>>> +++ b/meta/classes/kernel-yocto.bbclass
> > > >>>>>> @@ -193,12 +193,9 @@ do_kernel_metadata() {
> > > >>>>>> if [ $? -ne 0 ]; then
> > > >>>>>> bbfatal_log "Could not generate configuration queue for ${KMACHINE}."
> > > >>>>>> fi
> > > >>>>>> - fi
> > > >>>>>>
> > > >>>>>> - # run2: only generate patches for elements that have been passed on the SRC_URI
> > > >>>>>> - elements="`echo -n ${sccs} ${patches} ${KERNEL_FEATURES}`"
> > > >>>>>> - if [ -n "${elements}" ]; then
> > > >>>>>> - scc --force -o ${S}/${meta_dir}:patch --cmds patch ${includes} ${sccs} ${patches} ${KERNEL_FEATURES}
> > > >>>>>> + # run2: generate patches
> > > >>>>>> + scc --force -o ${S}/${meta_dir}:patch --cmds patch ${includes} ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}
> > > >>>>>> if [ $? -ne 0 ]; then
> > > >>>>>> bbfatal_log "Could not generate configuration queue for ${KMACHINE}."
> > > >>>>>> fi
> > > >>>>>> --
> > > >>>>>> 2.23.0
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>> _______________________________________________
> > > >>>>>> Openembedded-core mailing list
> > > >>>>>> Openembedded-core at lists.openembedded.org
> > > >>>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> > > >>>>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> - Thou shalt not follow the NULL pointer, for chaos and madness await
> > > >>> thee at its end
> > > >>> - "Use the force Harry" - Gandalf, Star Trek II
> > > >
> > > >
> > > > --
> > > > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > > > thee at its end
> > > > - "Use the force Harry" - Gandalf, Star Trek II
> >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
More information about the Openembedded-core
mailing list