* Kernel patch is unpacked but not applied
@ 2013-06-27 3:08 Bryan Evenson
2013-06-27 3:42 ` Bruce Ashfield
0 siblings, 1 reply; 10+ messages in thread
From: Bryan Evenson @ 2013-06-27 3:08 UTC (permalink / raw)
To: yocto
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?
Thanks,
Bryan
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Kernel patch is unpacked but not applied
2013-06-27 3:08 Kernel patch is unpacked but not applied Bryan Evenson
@ 2013-06-27 3:42 ` Bruce Ashfield
2013-06-27 5:24 ` Bruce Ashfield
0 siblings, 1 reply; 10+ messages in thread
From: Bruce Ashfield @ 2013-06-27 3:42 UTC (permalink / raw)
To: Bryan Evenson; +Cc: yocto
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 ?
Cheers,
Bruce
>
> Thanks,
> Bryan
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Kernel patch is unpacked but not applied
2013-06-27 3:42 ` Bruce Ashfield
@ 2013-06-27 5:24 ` Bruce Ashfield
2013-06-27 12:50 ` Bryan Evenson
0 siblings, 1 reply; 10+ messages in thread
From: Bruce Ashfield @ 2013-06-27 5:24 UTC (permalink / raw)
To: Bryan Evenson; +Cc: yocto
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 ?
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.
Bruce
>
> Cheers,
>
> Bruce
>
>>
>> Thanks,
>> Bryan
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Kernel patch is unpacked but not applied
2013-06-27 5:24 ` Bruce Ashfield
@ 2013-06-27 12:50 ` Bryan Evenson
2013-06-27 13:24 ` Bruce Ashfield
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Bryan Evenson @ 2013-06-27 12:50 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: yocto
> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
> Sent: Thursday, June 27, 2013 1:24 AM
> To: Bryan Evenson
> Cc: yocto@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'll let you know if I discover anything new.
Thanks,
Bryan
> Bruce
>
> >
> > Cheers,
> >
> > Bruce
> >
> >>
> >> Thanks,
> >> Bryan
> >> _______________________________________________
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> >>
> >
> > _______________________________________________
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Kernel patch is unpacked but not applied
2013-06-27 12:50 ` Bryan Evenson
@ 2013-06-27 13:24 ` Bruce Ashfield
2013-06-27 15:19 ` Bruce Ashfield
2013-06-27 15:20 ` Bruce Ashfield
2 siblings, 0 replies; 10+ messages in thread
From: Bruce Ashfield @ 2013-06-27 13:24 UTC (permalink / raw)
To: Bryan Evenson; +Cc: yocto
On 13-06-27 08:50 AM, Bryan Evenson wrote:
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
>> Sent: Thursday, June 27, 2013 1:24 AM
>> To: Bryan Evenson
>> Cc: yocto@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
That wouldn't have made a difference, the flags to patches are .. a bit
arcane at times. If a patch is in a SRC_URI it should be applied, and
won't be ignored. So there's a bug lurking somewhere that is specific
to your config.
Out of curiosity, can you try creating a .scc file, containing the
patches and .cfg files within it, and only listing the .scc file on the
SRC_URI.
Your method should work, but I'm trying to keep you moving while I
poke around, and .scc files are specifically designed to help manage
patch lists like this.
To do it, just create "foo.scc" in the same directory as your patches
and configs, and list foo.scc on your SRC_URI .. and that's it.
In foo.scc:
patch rs485.patch
patch usart1.patch
patch mmc.patch
one-wire.patch
kconf hardware gpio.cfg
kconf hardware ad5446.cfg
What I have above is generated to wrap the patches and .cfgs, which allows
them to be audited, and handled the same as in-tree kernel features.
I suspect something is just happening with the wrapping.
> 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.
Great. If I can use your exact configuration and layers, that makes
it much easier. If I can reproduce the issue, I can fix it.
Bruce
>
> I'll let you know if I discover anything new.
>
> Thanks,
> Bryan
>
>> Bruce
>>
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>>
>>>> Thanks,
>>>> Bryan
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Kernel patch is unpacked but not applied
2013-06-27 12:50 ` Bryan Evenson
2013-06-27 13:24 ` Bruce Ashfield
@ 2013-06-27 15:19 ` Bruce Ashfield
2013-06-27 15:20 ` Bruce Ashfield
2 siblings, 0 replies; 10+ messages in thread
From: Bruce Ashfield @ 2013-06-27 15:19 UTC (permalink / raw)
To: Bryan Evenson; +Cc: yocto
On 13-06-27 08:50 AM, Bryan Evenson wrote:
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
>> Sent: Thursday, June 27, 2013 1:24 AM
>> To: Bryan Evenson
>> Cc: yocto@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
>
> I'll let you know if I discover anything new.
>
> Thanks,
> Bryan
>
>> Bruce
>>
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>>
>>>> Thanks,
>>>> Bryan
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Kernel patch is unpacked but not applied
2013-06-27 12:50 ` Bryan Evenson
2013-06-27 13:24 ` Bruce Ashfield
2013-06-27 15:19 ` Bruce Ashfield
@ 2013-06-27 15:20 ` Bruce Ashfield
2013-06-27 15:41 ` Bryan Evenson
2 siblings, 1 reply; 10+ messages in thread
From: Bruce Ashfield @ 2013-06-27 15:20 UTC (permalink / raw)
To: Bryan Evenson; +Cc: yocto
On 13-06-27 08:50 AM, Bryan Evenson wrote:
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
>> Sent: Thursday, June 27, 2013 1:24 AM
>> To: Bryan Evenson
>> Cc: yocto@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@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Kernel patch is unpacked but not applied
2013-06-27 15:20 ` Bruce Ashfield
@ 2013-06-27 15:41 ` Bryan Evenson
2013-06-27 16:39 ` Bruce Ashfield
2013-06-27 20:44 ` Bruce Ashfield
0 siblings, 2 replies; 10+ messages in thread
From: Bryan Evenson @ 2013-06-27 15:41 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: yocto
> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
> Sent: Thursday, June 27, 2013 11:20 AM
> To: Bryan Evenson
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Kernel patch is unpacked but not applied
>
> On 13-06-27 08:50 AM, Bryan Evenson wrote:
> >> -----Original Message-----
> >> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
> >> Sent: Thursday, June 27, 2013 1:24 AM
> >> To: Bryan Evenson
> >> Cc: yocto@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'm closer to a working solution. I switched both the meta-atmel layer
and the meta-melink layer to use a single .scc file, and I changed the
SRC_URI in each bbappend as follows:
In the meta-atmel layer's linux-yocto-custom-3.9.0.bbappend:
SRC_URI += "file://${MACHINE}/${KBRANCH}/meta-atmel-${KBRANCH}.scc \
"
In the meta-melink layer's linux-yocto-custom-3.9.0.bbappend:
SRC_URI += "file://${MACHINE}/${KBRANCH}/meta-melink-${KBRANCH}.scc \
"
However, no matter how I've tried setting layer priority or ordering
these layers in bblayers.conf, do_patch always tries to apply the patches
from the meta-melink layer first. This is incorrect for my setup, as my
patches build on the ones from the meta-atmel layer.
Just for fun, I tried changing the SRC_URI in the meta-melink layer to:
SRC_URI += " file://${MACHINE}/${KBRANCH}/meta-atmel-${KBRANCH}.scc \
file://${MACHINE}/${KBRANCH}/meta-melink-${KBRANCH}.scc \
"
With this change, I'm back where I started; all 9 patches show up in the
series, but only the first five are applied. And no errors are reported
for the patched not being applied.
In the short term, with things at this state I've found I can call
bitbake -c devshell linux-yocto-custom, then while in the devshell call
"guilt push -a", then it applies all the patches. Then I exit the devshell
and the rest of the build works without issues.
-Bryan
> >
> > I'll let you know if I discover anything new.
> >
> > Thanks,
> > Bryan
> >
> >> Bruce
> >>
> >>>
> >>> Cheers,
> >>>
> >>> Bruce
> >>>
> >>>>
> >>>> Thanks,
> >>>> Bryan
> >>>> _______________________________________________
> >>>> yocto mailing list
> >>>> yocto@yoctoproject.org
> >>>> https://lists.yoctoproject.org/listinfo/yocto
> >>>>
> >>>
> >>> _______________________________________________
> >>> yocto mailing list
> >>> yocto@yoctoproject.org
> >>> https://lists.yoctoproject.org/listinfo/yocto
> >
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Kernel patch is unpacked but not applied
2013-06-27 15:41 ` Bryan Evenson
@ 2013-06-27 16:39 ` Bruce Ashfield
2013-06-27 20:44 ` Bruce Ashfield
1 sibling, 0 replies; 10+ messages in thread
From: Bruce Ashfield @ 2013-06-27 16:39 UTC (permalink / raw)
To: Bryan Evenson; +Cc: yocto
On 13-06-27 11:41 AM, Bryan Evenson wrote:
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
>> Sent: Thursday, June 27, 2013 11:20 AM
>> To: Bryan Evenson
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Kernel patch is unpacked but not applied
>>
>> On 13-06-27 08:50 AM, Bryan Evenson wrote:
>>>> -----Original Message-----
>>>> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
>>>> Sent: Thursday, June 27, 2013 1:24 AM
>>>> To: Bryan Evenson
>>>> Cc: yocto@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'm closer to a working solution. I switched both the meta-atmel layer
> and the meta-melink layer to use a single .scc file, and I changed the
> SRC_URI in each bbappend as follows:
>
> In the meta-atmel layer's linux-yocto-custom-3.9.0.bbappend:
> SRC_URI += "file://${MACHINE}/${KBRANCH}/meta-atmel-${KBRANCH}.scc \
> "
>
> In the meta-melink layer's linux-yocto-custom-3.9.0.bbappend:
> SRC_URI += "file://${MACHINE}/${KBRANCH}/meta-melink-${KBRANCH}.scc \
> "
>
> However, no matter how I've tried setting layer priority or ordering
> these layers in bblayers.conf, do_patch always tries to apply the patches
> from the meta-melink layer first. This is incorrect for my setup, as my
> patches build on the ones from the meta-atmel layer.
Indeed. And strange. The ordering on the SRC_URI dictates the .scc
processing order. I'll try that one myself as well.
>
> Just for fun, I tried changing the SRC_URI in the meta-melink layer to:
>
> SRC_URI += " file://${MACHINE}/${KBRANCH}/meta-atmel-${KBRANCH}.scc \
> file://${MACHINE}/${KBRANCH}/meta-melink-${KBRANCH}.scc \
> "
>
> With this change, I'm back where I started; all 9 patches show up in the
> series, but only the first five are applied. And no errors are reported
> for the patched not being applied.
Argh. I'm starting another build. I need to see this myself!
>
> In the short term, with things at this state I've found I can call
> bitbake -c devshell linux-yocto-custom, then while in the devshell call
> "guilt push -a", then it applies all the patches. Then I exit the devshell
> and the rest of the build works without issues.
Good. I'm digging in deeper now. It'll be obvious, once I can reproduce
the problem.
Cheers,
Bruce
>
> -Bryan
>
>>>
>>> I'll let you know if I discover anything new.
>>>
>>> Thanks,
>>> Bryan
>>>
>>>> Bruce
>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Bruce
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Bryan
>>>>>> _______________________________________________
>>>>>> yocto mailing list
>>>>>> yocto@yoctoproject.org
>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> yocto mailing list
>>>>> yocto@yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Kernel patch is unpacked but not applied
2013-06-27 15:41 ` Bryan Evenson
2013-06-27 16:39 ` Bruce Ashfield
@ 2013-06-27 20:44 ` Bruce Ashfield
1 sibling, 0 replies; 10+ messages in thread
From: Bruce Ashfield @ 2013-06-27 20:44 UTC (permalink / raw)
To: Bryan Evenson; +Cc: yocto
On 13-06-27 11:41 AM, Bryan Evenson wrote:
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
>> Sent: Thursday, June 27, 2013 11:20 AM
>> To: Bryan Evenson
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Kernel patch is unpacked but not applied
>>
>> On 13-06-27 08:50 AM, Bryan Evenson wrote:
>>>> -----Original Message-----
>>>> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
>>>> Sent: Thursday, June 27, 2013 1:24 AM
>>>> To: Bryan Evenson
>>>> Cc: yocto@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'm closer to a working solution. I switched both the meta-atmel layer
> and the meta-melink layer to use a single .scc file, and I changed the
> SRC_URI in each bbappend as follows:
>
> In the meta-atmel layer's linux-yocto-custom-3.9.0.bbappend:
> SRC_URI += "file://${MACHINE}/${KBRANCH}/meta-atmel-${KBRANCH}.scc \
> "
>
> In the meta-melink layer's linux-yocto-custom-3.9.0.bbappend:
> SRC_URI += "file://${MACHINE}/${KBRANCH}/meta-melink-${KBRANCH}.scc \
> "
>
> However, no matter how I've tried setting layer priority or ordering
> these layers in bblayers.conf, do_patch always tries to apply the patches
> from the meta-melink layer first. This is incorrect for my setup, as my
> patches build on the ones from the meta-atmel layer.
>
> Just for fun, I tried changing the SRC_URI in the meta-melink layer to:
>
> SRC_URI += " file://${MACHINE}/${KBRANCH}/meta-atmel-${KBRANCH}.scc \
> file://${MACHINE}/${KBRANCH}/meta-melink-${KBRANCH}.scc \
> "
>
> With this change, I'm back where I started; all 9 patches show up in the
> series, but only the first five are applied. And no errors are reported
> for the patched not being applied.
>
> In the short term, with things at this state I've found I can call
> bitbake -c devshell linux-yocto-custom, then while in the devshell call
> "guilt push -a", then it applies all the patches. Then I exit the devshell
> and the rest of the build works without issues.
I have a patch to the kern tools that *may* help your test case. I was
able to use meta-atmel, plus a second layer that has your exact .cfg
and patch names (but with different content) to patch the kernel.
Everything was applied, and nothing ignored.
You'll need to point your kern-tools recipe at a temporary branch to
try it out, so if you are ok with that. Let me know and I'll send the
details.
Cheers,
Bruce
>
> -Bryan
>
>>>
>>> I'll let you know if I discover anything new.
>>>
>>> Thanks,
>>> Bryan
>>>
>>>> Bruce
>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Bruce
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Bryan
>>>>>> _______________________________________________
>>>>>> yocto mailing list
>>>>>> yocto@yoctoproject.org
>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> yocto mailing list
>>>>> yocto@yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-06-27 20:44 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-27 3:08 Kernel patch is unpacked but not applied Bryan Evenson
2013-06-27 3:42 ` Bruce Ashfield
2013-06-27 5:24 ` Bruce Ashfield
2013-06-27 12:50 ` Bryan Evenson
2013-06-27 13:24 ` Bruce Ashfield
2013-06-27 15:19 ` Bruce Ashfield
2013-06-27 15:20 ` Bruce Ashfield
2013-06-27 15:41 ` Bryan Evenson
2013-06-27 16:39 ` Bruce Ashfield
2013-06-27 20:44 ` Bruce Ashfield
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.