[yocto] Kernel patches pulled from BSP definition file are not applied
Diego Santa Cruz
Diego.SantaCruz at spinetix.com
Mon Oct 14 02:50:56 PDT 2019
> From: Bruce Ashfield <bruce.ashfield at gmail.com>
>
> On Fri, Oct 11, 2019 at 1:11 PM Diego Santa Cruz
> <Diego.SantaCruz at spinetix.com> wrote:
> >
> > Can anyone provide some advice as to what would be the recommended way
> to apply kernel patches listed in a mybsp-patches.scc file for a BSP?
> >
>
> The way to do this, is to put your BSP definition file on the SRC_URI, and if you
> are including the standard/ktype or any of the other common kernel meta data
> files, you need to inhibit any included meta data from adding patches to the
> patch queue (since they are already applied to the kernel).
>
> As an example, here's a 'myqemux86-64.scc' file that I use as a test:
>
> ---------------
> define KMACHINE myqemux86-64
> define KARCH x86
> define KTYPE standard
>
> include ktypes/standard.scc nopatch
>
> patch foo.patch
> -------------
>
> When that is on the SRC_URI, it will be found as the BSP definition, and you'll get
> "foo.patch" in the patch queue .. but importantly *not* all of the patches that
> make up the ktypes/standard.scc (and includes). If you aren't using linux-yocto,
> or you aren't building on top of a kernel repository with integrated patches, then
> don't add the 'nopatch', since you'd want any found patches to be applied at
> build time.
I'm using linux-intel.
>
> I thought we had documented the nopatch directive in the yocto mega manual,
> but I just checked the kernel meta data section and I don't see it. I'll follow up
> and try to figure out where that documentation went ... and get it added if it is
> missing.
>
BTW, the existing documentation about nocfg under https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#kernel-types is not very clear and from what I got from the spp tool's code the nocfg directive is always inherited and the "inherit" keyword seems to be ignored. There is also the "force" option to kconf which is not documented.
> Out of curiosity, how were you getting your BSP definition to be located by the
> do_metadata function (there are a few different ways) ?
> (since you need at least one .scc file or kernel-meta structure on the SRC_URI to
> get it added to the search path). If you were adding it to the SRC_URI directly
> and the patches weren't being applied, then that's a bug.
>
My explanation was probably a bit short. I'm using recipe-space metadata as explained at https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#recipe-space-metadata, although the explanation there is a bit short and I could not make it work until I saw the working example in the meta-xilinx layer if I remember well.
I am using linux-intel (from the meta-intel layer), I have set MACHINE="fukiran" (KMACHINE gets the same value) and I have this in my bbappend.
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI_append = " file://spx-intel-kmeta;type=kmeta;destsuffix=spx-intel-kmeta"
The recipe-space metadata tree is as follows
files/
`-- spx-intel-kmeta
|-- backports
| `-- drivers
| |-- 0001-tty-Add-NULL-TTY-driver.patch
| |-- null-tty.cfg
| `-- null-tty.scc
|-- bsp
| `-- spx-intel
| |-- 0001-platform-x86-spx-fukiran-info-new-driver-for-Spineti.patch
| |-- fukiran.cfg
| |-- fukiran-patches.scc
| |-- fukiran.scc
| `-- fukiran-standard.scc
|-- cfg
| `-- fs
| |-- squashfs.cfg
| `-- squashfs.scc
`-- features
|-- media
| |-- media-cec.cfg
| `-- media-cec.scc
`-- wifi
|-- atheros-10k-pci.cfg
`-- atheros-10k-pci.scc
The BSP definition file fukiran-standard.scc with the content below is thus located automatically (I followed the best I can the instructions in the Yocto docs to write the BSP definition file, although I did not quite get what is the "branch" directive for, I guess it is used when composing a kernel repo tree).
# fukiran-standard.scc
#
# Standard ktype for Fukiran (Apollo Lake SoC).
#
define KMACHINE fukiran
define KARCH x86_64
define KTYPE standard
include ktypes/standard/standard.scc
branch fukiran
include bsp/intel-common/intel-common-drivers.scc
include bsp/intel-common/intel-corei7-64.scc
include fukiran.scc
And fukiran.scc is
kconf hardware fukiran.cfg
patch 0001-platform-x86-spx-fukiran-info-new-driver-for-Spineti.patch
include features/media/media-cec.scc
> A short description of what is happening behind the scenes. The kernel meta-
> data is used in two ways: to construct a new kernel repo from scratch (i.e. when
> I start a new reference kernel version, or when building on top of a non
> integrated repository) and to construct a configuration for the kernel. Patches
> and config data are kept together, so everything you need for a feature is in one
> place. When you are building, the meta data gathering routine is running in that
> 2nd mode. Hence why the BSP definition is not used for patching, but is only
> used to generate the configuration queue. Only elements on the SRC_URI are
> always added to the patch queue .. since those patches are not already applied
> to the base repo (and if they are, you shouldn't have them on the SRC_URI and
> you'll get a patch error) .. There's even a longer winded explanation about how
> the original build processing attempted to detected which patches weren't
> already applied ... and was horribly complex and fragile, hence why the
> simpler/split processing I described is used.
>
I see, that was the key bit of information I was lacking: that the patches are already applied in the linux-yocto repo, so they need to be skipped when building.
As in my case the BSP specific patches are not applied to the kernel repo then I should add the BSP definition file to SRC_URI. I have thus changed my bbappend to have
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI_append = " file://spx-intel-kmeta;type=kmeta;destsuffix=spx-intel-kmeta"
SRC_URI_append_fukiran = " file://spx-intel-kmeta/bsp/spx-intel/fukiran-${LINUX_KERNEL_TYPE}.scc"
And also tweaked fukiran-standard.scc to have this line
include ktypes/standard/standard.scc nopatch
> Let me know if that tweak doesn't work (and if you can, supply your BSP
> definition / layer) .. since there may be a bug (see my comment on what you had
> on your SRC_URI above and how your bsp definition was being located).
>
With the above tweaks it does work as expected and I understand why :-) There's no bug I can see, just the documentation which is a bit lacking or hard to follow.
BTW, the linux-intel kernel repo does not have the patches from ktypes/standard/standard.scc applied and they are not being applied during build either (I do not see any scc file with patches being added to SRC_URI or KERNEL_FEATURES in the linux-intel recipe and in my test none are added to the patch queue), so it appears that the meta-intel layer has decided to build without those patches.
Many thanks for the long explanation which made things clear!
Best,
Diego
> Cheers,
>
> Bruce
>
> >
> >
> > Adding the “mybsp-patches.scc” file to KERNEL_FEATURES works for me, but
> seems a bit awkward given that there is a BSP definition scc file. It feels more
> natural to include the mybsp-patches.scc from the BSP definition scc file, but
> that does not work for me, the patches are ignored.
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Diego
> >
> > --
> > Diego Santa Cruz, PhD
> > Technology Architect
> > T +41 21 341 15 50
> > diego.santacruz at spinetix.com
> > spinetix.com
> >
> >
> >
> > From: yocto-bounces at yoctoproject.org <yocto-bounces at yoctoproject.org>
> > On Behalf Of Diego Santa Cruz
> > Sent: 09 October 2019 23:58
> > To: yocto at yoctoproject.org
> > Subject: [yocto] Kernel patches pulled from BSP definition file are
> > not applied
> >
> >
> >
> > Hello there,
> >
> >
> >
> > I am trying to add a few BSP specific kernel patches for my BSP and I wanted
> to pull them from the BSP definition scc file. However, I cannot get those
> patches applied (I am using thud). After looking around the kernel-yocto.bbclass
> it seems that patches which get pulled from the BSP definition file are ignored.
> What is the rationale behind that behavior? How should I go about it?
> >
> >
> >
> > To be more specific I have the following structure within my (recipe-space)
> kernel metadata.
> >
> >
> >
> > bsp
> >
> > `-- mybsp
> >
> > |-- mypatch.patch
> >
> > |-- mybsp.cfg
> >
> > |-- msbsp.scc
> >
> > `-- mybsp-standard.scc
> >
> >
> >
> > The mybsp-standard.scc is the BSP definition file, which includes
> > mybsp.scc (among other things). The mybsp.scc file looks as follows
> >
> >
> >
> > kconf hardware mybsp.cfg
> >
> > patch mypatch.patch
> >
> >
> >
> > The mypatch.patch file does not get applied when building the kernel,
> > I checked and it is not added to the patch.queue file. But if I add
> > the following to the recipe
> >
> >
> >
> > KERNEL_FEATURES += " bsp/mybsp/mybsp.scc"
> >
> >
> >
> > Then the patch is added to patch.queue and is applied.
> >
> >
> >
> > Looking into do_kernel_metadata in kernel-yocto.bbclass it parses the scc files
> in two steps, run1 and run2.
> >
> >
> >
> > The run1 step uses elements="`echo -n ${bsp_definition} ${sccs} ${patches}
> ${KERNEL_FEATURES}`" and generates cfg, merge and meta, so that picks up the
> mybsp.scc file contents, but this step does not generate the patch queue.
> >
> >
> >
> > The run2 step uses elements="`echo -n ${sccs} ${patches}
> ${KERNEL_FEATURES}`" and generates the patch queue, but this only includes
> the scc files in SRC_URI and KERNEL_FEATURES, but specifically leaves out the
> BSP definition file.
> >
> >
> >
> > Adding the mybsp.scc file to KERNEL_FEATURES to get this to work seems a bit
> odd. What is the recommended way of applying BSP specific kernel patches?
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Diego
> >
> > --
> > Diego Santa Cruz, PhD
> > Technology Architect
> > spinetix.com
> >
> >
> >
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee at
> its end
> - "Use the force Harry" - Gandalf, Star Trek II
--
Diego Santa Cruz, PhD
Technology Architect
spinetix.com
More information about the yocto
mailing list