[meta-xilinx] Yocto quilt/patch Issue

Nathan Rossi nathan at nathanrossi.com
Fri Jul 10 01:59:38 PDT 2015


On Thu, Jul 9, 2015 at 7:11 AM, Harold Lapprich
<hlapprich at pixel-velocity.com> wrote:
> To Whom It May Concern,
>
>
>
>
>
> Been an embedded Unix/Linux developers for years and started using Yocto
> about 5 months ago.
>
>
>
> Have gotten to the point where I need to make changes to the 'meta-xilinx'
> kernel layer.
>

It is unlikely that you need to make changes to the meta-xilinx layer.
This is because the major flexibility of Yocto/OE is that you can make
a layer that overrides or appends to the existing recipes.

I recommend you have a read of the wealth of documentation. Some of
the key sections linked below:
http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#developing-a-board-support-package-bsp
http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#patching-the-kernel

The following are the most important for your use case:
http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#create-a-layer-for-your-changes
http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#creating-the-patch
http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#set-up-your-layer-for-the-build

>
>
> Trying to use 'quilt' for development and 'git' for patching. Can make
> changes in the temporary development directory, build and test without a
> problem. But when I try to make a 'quilt' or 'git' patch for a permanant
> record I can't get it to work. Able to create the patch file using 'quilt'
> and 'git' but when integrated into the 'meta-xlinx/receipe-kernel/linux'
> directory nothing works.

For reference the kernel recipes are slightly different to the
majority of other recipes in yocto. This is because the kernel recipes
manage the source slightly different. I recommend using the git steps
documented in the "creating-the-patch" section linked above. But it
doesn't particularly matter how you obtain the patch file.

>
>
>
>
>
> Using 'Yocto Project Developent Manual' as my user guide:
>
>
>
>                Quilt
>
>
>
>                               4. Modifying Source Code
>
>                                              4.3.3 Using Quilt in Your
> Workflow
>
>                                                             cd temporary
> build directory
>
>                                                             mkdir patches
>
>                                                             quilt new
> my_changes.patch
>
>                                                             quilt add file
>
>                                                             build & test
> changes (i.e. bitbake virtual/kernel -c clean, bitbake virtual/kernel)
>
>                                                             quilt refresh
>
>
> IEEE1588PTP_Slave_Sync.patch (more the file to check the content)
>
>
>
>                                                             Quilt Patch
> (meta-xilinx/receipes-kernel/linux/)
>
>
>
>
> linux-xlnx_3.14.bb
>
>
>
>
> include linux-xlnx.inc
>
>
>
>                                         PR = "r1"
>
>
>
>                                         # Kernel version and SRCREV
> correspond to: xlnx_3.14 branch
>
>                                         KBRANCH = "xlnx_3.14"
>
>                                         LINUX_VERSION = "3.14"
>
>                                         SRCREV =
> "2b48a8aeea7367359f9eebe55c4a09a05227f32b"
>
>
>
>
> linux-yocto_3.14.bbappend
>
>
>
>
> require linux-machine-common.inc
>
>
>
>
>
>                                         FILESEXTRAPATHS_prepend :=
> "${THISDIR}/files:"
>
>                                         SRC_URI +=
> "file://IEEE1588PTP_Slave_Sync.patch;patch=1"
>
>
>
>
>
>
> cp patch file (meta-xilinx/receipes-kernel/linux/files
>
>
>
>
> IEEE1588PTP_Slave_Sync.patch

So the idea is to move these recipe changes into your layer with a
bbappend for the linux-xlnx kernel.

e.g.
meta-mylayer/recipes-kernel/linux/linux-xlnx_3.14.bbappend:
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI += "file://IEEE1588PTP_Slave_Sync.patch"

With the patch located:
meta-mylayer/recipes-kernel/linux/files/IEEE1588PTP_Slave_Sync.patch

>
>
>
>
> bitbake virtual/kernel -c clean (patch is now perserved so cleaning isn't a
> problem)
>
>
>
>
> bitbake virtual/kernel -c compile
>
>
>
>                                       No errors, check the time stamp on the
> file to be patched and it is updated
>
>
>
>                            more file and the patch has not been applied.
>
>
>
>
>
> Have searched the web and read a number of articles beside Yocto document
> and nothing works (this was a nice article:
> http://wp.angstrom-distribution.org/openembeddedangstrom-kernel-workflow/).
>
>
>
> Is there an issue with making a patch in the 'meta-xilinx' layer?
>

There are no issues with patches for the meta-xilinx layer however
there are many things that need to be considered. In this case the
patch would be for the kernel and as such likely not be accepted as
the meta-xilinx layer does not maintain the kernel linux-xlnx (the
only patches that get applied in the meta-xilinx layer are major bug
fixes), this is the role of Xilinx OSL, you would need to submit the
patch to git at xilinx.com or to the mainline linux kernel. And you
changes would then come through and be available in the meta-xilinx
layer with the newer kernels.

>
>
> Removed the patch from the files directory and 'bitbake' complains so it is
> being seen, is the patch applied to the file so one can 'more' it to verify
> the changes?
>
>
>
> Really have been working this issue and any input from the 'meta-xilinx' and
> 'yocto' community would be appreciated (shouldn't be this difficult or
> developers wouldn't be using the tool).
>

I think you have gotten 50% of the way based on your description, you
just need to make a separate layer for you modifications to the
kernel.

Regards,
Nathan

>
>
> Thanks,
>
> Harold
>
>
>
>
>
>
> --
> _______________________________________________
> meta-xilinx mailing list
> meta-xilinx at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
>



More information about the meta-xilinx mailing list