On 13-06-27 08:50 AM, Bryan Evenson wrote:
-----Original Message-----
From: Bruce Ashfield [mailto:bruce.ashfi...@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
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
