[yocto] Kernel patch is unpacked but not applied

Thu Jun 27 08:20:04 PDT 2013

On 13-06-27 08:50 AM, Bryan Evenson wrote:
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield at windriver.com]
>> Sent: Thursday, June 27, 2013 1:24 AM
>> To: Bryan Evenson
>> Cc: yocto at yoctoproject.org
>> Subject: Re: [yocto] Kernel patch is unpacked but not applied
>>
>> On 13-06-26 11:42 PM, Bruce Ashfield wrote:
>>> On 13-06-26 11:08 PM, Bryan Evenson wrote:
>>>> I am building a custom Linux kernel under poky-dylan and I am having
>>>> an issue with patches being unpacked but not applied.  I have two
>>>> layers that have a bbappend file for the kernel.  Generally, this is
>>>> what each bbappend file looks like:
>>>>
>>>> #First .bbappend
>>>>
>>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>> COMPATIBLE_MACHINE_mach1 = "mach1"
>>>> COMPATIBLE_MACHINE_mach2 = "mach2"
>>>> SRC_URI_append_mach2 = " file://${MACHINE}/${KBRANCH}/0001-
>> blah.patch \
>>>>       file://${MACHINE}/${KBRANCH}/0002-blah.patch \
>>>>       "
>>>>
>>>> # Increment the recipe revision
>>>> PRINC := "${@int(PRINC) + 1}"
>>>>
>>>> # Second .bbappend
>>>>
>>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>> COMPATIBLE_MACHINE_mach1 = "mach1"
>>>> COMPATIBLE_MACHINE_mach2 = "mach2"
>>>> SRC_URI_append_mach2 = " file://${MACHINE}/${KBRANCH}/0003-
>> blah.patch \
>>>>       file://${MACHINE}/${KBRANCH}/0004-blah.patch \
>>>>       "
>>>>
>>>> # Increment the recipe revision
>>>> PRINC := "${@int(PRINC) + 1}"
>>>>
>>>> All of the patch files are properly unpacked, but the last two
>>>> patches are not being applied.  If I open the devshell for the
>> kernel
>>>> (bitbake -c devshell linux-yocto-custom) I can see in the git log
>>>> that the first patch set was applied.  The second patch set exists
>>>> but is not applied.  If I call "guilt push" repeatedly from the
>>>> devshell, the patches from the second set are cleanly applied.  My
>>>> guess is that something doesn't like the second SRC_URI_append call.
>>>> Any ideas on how to fix it?
>>>
>>> It shouldn't matter. Let me try and set up something that reproduces
>>> the problem and get back to you.
>>>
>>> Strangely .. I'm actively debugging something similar here already,
>> so
>>> I may be able to re-use it.
>>>
>>> Stay tuned.
>>>
>>> Out of curiosity, have you tried this on master ?
>>
>
> I have not tried this on master.  Here is the relevant build information:
>
> Build Configuration:
> BB_VERSION        = "1.18.0"
> BUILD_SYS         = "i686-linux"
> NATIVELSBSTRING   = "Ubuntu-12.04"
> TARGET_SYS        = "arm-poky-linux-gnueabi"
> MACHINE           = "at91sam9x5ek"
> DISTRO            = "poky"
> DISTRO_VERSION    = "1.4.1"
> TUNE_FEATURES     = "armv5 thumb dsp arm926ejs"
> TARGET_FPU        = "soft"
> meta-melink       = "dylan:e4a0a4c5e419154a34710a1b6c28d4180c6304c3"
> meta-atmel        = "master:b2a9c072730b0f6b2a669a8de613e5e1d59453e6"
> meta
> meta-yocto
> meta-yocto-bsp    = "dylan:e4a0a4c5e419154a34710a1b6c28d4180c6304c3"
> meta-oe           = "dylan:13ae5105ee30410136beeae66ec41ee4a8a2e2b0"
>
> So I'm at the HEAD of the Dylan branch for both poky and meta-oe.
> The kernel patches are in both the meta-atmel layer and the meta-melink
> Layter.  Ignore that version string for meta-melink; it's not a git
> repository so it's just grabbing the info from poky.
>
>> So I tried to recreate this on master, and things worked for me. Which
>> I figured would happen, since this will make it harder to fix ... and
>> that's how it always works out.
>>
>> I created two layers, with four patches to the main linux Makefile.
>> They all add something to the description:
>>
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>
>> SRC_URI_append = " file://0001-makefile-one.patch \
>>                      file://0002-makefile-two.patch"
>>
>>
>>
>> PRINC := "${@int(PRINC) + 1}"
>>
>> and
>>
>>
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>> SRC_URI_append = " file://0003-makefile-three.patch \
>>                      file://0004-makefile-four.patch"
>>
>>
>>
>> PRINC := "${@int(PRINC) + 1}"
>>
>> .. and alas, the all were applied:
>>
>>   > grep NAME Makefile
>> NAME = Displaced Humerus Anterior one two three four
>>
>> ....
>>
>> Can you send me the exact names of your patches ? I'm wondering if an
>> already applied check is triggering and preventing the auto push.
>>
>
> Here are the patch names in the first layer (meta-atmel):
>
> " file://${MACHINE}/${KBRANCH}/UBI.cfg \
>      file://${MACHINE}/${KBRANCH}/dma.cfg \
>      file://${MACHINE}/${KBRANCH}/usb-c.patch \
>      file://${MACHINE}/${KBRANCH}/usart3.patch \
>      file://${MACHINE}/${KBRANCH}/rtc.patch \
>      file://${MACHINE}/${KBRANCH}/serial_dma.patch \
>      ${@base_contains("MACHINE_FEATURES", "watchdog", "file://${MACHINE}/${KBRANCH}/watchdog.patch", " ", d)} \
>      "
>
> If you're wondering about that last line, I added a watchdog
> feature to the meta-atmel layer to enable or disable the watchdog
> for the kernel, U-Boot and the AT91Bootstrap.
>
> And here are the patch names for the second layer (meta-melink):
>
> SRC_URI_append_at91sam9x5ek = " file://${MACHINE}/${KBRANCH}/mq.cfg \
>      file://${MACHINE}/${KBRANCH}/gpio.cfg \
>      file://${MACHINE}/${KBRANCH}/ad5446.cfg \
>      file://${MACHINE}/${KBRANCH}/rs485.patch;apply=yes \
>      file://${MACHINE}/${KBRANCH}/usart1.patch;apply=yes \
>      file://${MACHINE}/${KBRANCH}/mmc.patch;apply=yes \
>      file://${MACHINE}/${KBRANCH}/one-wire.patch;apply=yes \
>      "
>
> I tried adding the "apply=yes" to the second layer patches, and they still
> were not applied.  Incidentally, the configuration changes (.cfg files)
> *are* being applied.  So if I understand correctly, do_unpack is getting
> the correct files, do_patch is not applying all the patches, but
> do_configure is applying all the configuration changes.
>
> If it helps, the meta-atmel layer I am using is available here:
> https://github.com/evensonbryan/meta-atmel.  I just pushed an update a few
> minutes ago, so it has what I am using.

I've got a working baseline, using the meta-atmel layer, I see the
5 patches applied:

  f3864ee Add watchdog support.
  d8a2978dc Add DMA support for USARTs.
  c31d2cd Turn on RTC
  6d7277d Add USART3 to SAM9G25 device tree.
  9b38b15 Add USB-C to device tree.

But I of course don't have your meta-melink layer, so I'll have a go
at adding some similarly named, but different patches and see if the
problem can be reproduced.

Cheers,

Bruce

>
> I'll let you know if I discover anything new.
>
> Thanks,
> Bryan
>
>> Bruce
>>
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>>
>>>> Thanks,
>>>> Bryan
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto at yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto at yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>