Strange do_patch behaviour

Strange do_patch behaviour

[Dmitry Vinokurov]

[-- Attachment #1: Type: text/plain, Size: 5396 bytes --]

Hi,

I'm still working on building OE for Phytec LPC3250 (local.conf 
attached) and faced following thing:

I've created patch file from working 2.6.27.8 kernel sources (make 
distclean and diff -Nurd then), moved it to 
'recipes/linux/linux-2.6.27.8/phy3250/', copied working .config to 
'recipes/linux/linux-2.6.27.8/phy3250/defconfig', created 2.6.27.8 
recipe based on 2.6.27 (attached). When I try to run builded kernel 
('bitbake virtual/kernel') on target board I get kernel panic (not 
syncing: Attempted to kill init). Digged a little and found that 
standard sources with applied patch differs from fetched, unpacked and 
patched by bitbake sources, that lies at 
tmp/work/phy3250-oe-linux-gnueabi/linux-2.6.27.8-r1/linux-2.6.27.8. It's 
rather strange for me, because tail of 'bitbake virtual/kernel -v -DD -c 
patch' is following:
------------
NOTE: Running task 36 of 36 (ID: 3, 
/home/raydan/work/oe/openembedded/recipes/linux/linux_2.6.27.8.bb, do_patch)
DEBUG: Parsing 
/home/raydan/work/oe/openembedded/recipes/linux/linux_2.6.27.8.bb (full)
DEBUG: BB 
/home/raydan/work/oe/openembedded/recipes/linux/linux_2.6.27.8.bb: 
handle(data)
DEBUG: BB linux.inc: handle(data, include)
DEBUG: BB :0: inheriting classes/kernel.bbclass
DEBUG: BB classes/kernel.bbclass: handle(data, include)
DEBUG: BB :0: inheriting classes/linux-kernel-base.bbclass
DEBUG: BB classes/linux-kernel-base.bbclass: handle(data, include)
DEBUG: BB :0: inheriting classes/module_strip.bbclass
DEBUG: BB classes/module_strip.bbclass: handle(data, include)
DEBUG: BB :0: inheriting classes/kernel-arch.bbclass
DEBUG: BB classes/kernel-arch.bbclass: handle(data, include)
DEBUG: setVarFlag(kernel_do_compile, depends, ${INITRAMFS_TASK}, data)
DEBUG: setVarFlag(do_menuconfig, nostamp, 1, data)
DEBUG: BB :0: inheriting classes/cml1.bbclass
DEBUG: BB classes/cml1.bbclass: handle(data, include)
DEBUG: setVarFlag(do_deploy, dirs, ${S}, data)
DEBUG: update_data()
DEBUG: update_data()
DEBUG: Executing task do_patch
DEBUG: update_data()
DEBUG: 
mkdirhier(/home/raydan/work/oe/build/tmp/work/phy3250-oe-linux-gnueabi/linux-2.6.27.8-r1)
DEBUG: 
mkdirhier(/home/raydan/work/oe/build/tmp/work/phy3250-oe-linux-gnueabi/linux-2.6.27.8-r1)
NOTE: Applying patch 'phy3250.patch' 
(../openembedded/recipes/linux/linux-2.6.27.8/phy3250/phy3250.patch)
DEBUG: 
mkdirhier(/home/raydan/work/oe/build/tmp/stamps/phy3250-oe-linux-gnueabi)
NOTE: Tasks Summary: Attempted 36 tasks of which 35 didn't need to be 
rerun and 0 failed.
------------
And looks like bitbake did nothing except patching, but actually it does 
(diff between manually and bitbake patched dirs is ~30000 strings, and I 
decided not to attach it:)) and as a result builded kernel fails with 
kernel panic. Diff shows, that '.pc' dir is created (and some files in 
it are forbidden for any access (0000 rights)) and not only it -- some 
other files like in arch/arm or sound/soc/lpc3xxx/ differs too. Tried to 
remove tmp/ and rebuild -- same result.

Could anybody explain this strange behaviour? I thought that patch task 
should only execute 'patch' command.

P.S.: openembedded stable/2009, bitbake 1.8.12-1 from Debian rep.

-- 
Best Regards, 
Dmitry Vinokurov 
<d.vinokuroff@gmail.com>

#
# local.conf
#
# Author: Dmitry Vinokurov <raydan@permlug.org>
#


DL_DIR = "${HOME}/sources"
BBFILES := "${HOME}/work/oe/openembedded/recipes/*/*.bb"
BBMASK = ""

ASSUME_PROVIDED += " virtual/libc "
#ASSUME_PROVIDED += " linux-libc-headers "
ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc "
ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc-initial "
ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc-intermediate "
ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}binutils "
#ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}libc-for-gcc "

MACHINE = "phy3250"

DISTRO = "minimal"

#CCACHE = "ccache "
CCACHE = " "

TOOLCHAIN_BASE_PATH = "/opt/nxp/gcc-4.3.2-glibc-2.7"
TOOLCHAIN_PATH = "${TOOLCHAIN_BASE_PATH}/arm-vfp-linux-gnu"

export CC="${CCACHE}${TOOLCHAIN_BASE_PATH}/bin/arm-vfp-linux-gnu-gcc "
export CXX="${CCACHE}${TOOLCHAIN_BASE_PATH}/bin/arm-vfp-linux-gnu-g++ "
export CPP="${TOOLCHAIN_BASE_PATH}/bin/arm-vfp-linux-gnu-gcc -E "
export LD="${TOOLCHAIN_BASE_PATH}/bin/arm-vfp-linux-gnu-ld "
export AR="${TOOLCHAIN_BASE_PATH}/bin/arm-vfp-linux-gnu-ar "
export AS="${TOOLCHAIN_BASE_PATH}/bin/arm-vfp-linux-gnu-as "
export NM="${TOOLCHAIN_BASE_PATH}/bin/arm-vfp-linux-gnu-nm "
export RANLIB="${TOOLCHAIN_BASE_PATH}/bin/arm-vfp-linux-gnu-ranlib "
export STRIP="${TOOLCHAIN_BASE_PATH}/bin/arm-vfp-linux-gnu-strip "
export OBJCOPY="${TOOLCHAIN_BASE_PATH}/bin/arm-vfp-linux-gnu-objcopy "
export OBJDUMP="${TOOLCHAIN_BASE_PATH}/bin/arm-vfp-linux-gnu-objdump "

TARGET_CPPFLAGS_append = " -I${TOOLCHAIN_PATH}/include "
TARGET_LDFLAGS_prepend = " -L${TOOLCHAIN_PATH}/lib -Wl,-rpath-link,${TOOLCHAIN_PATH}/lib "

KERNEL_IMAGETYPE = "uImage"

HOST_PREFIX="${CCACHE}${TOOLCHAIN_BASE_PATH}/bin/arm-vfp-linux-gnu-"
UBOOT_ENTRYPOINT = "80008000"

require linux.inc

PR = "r1"

# Mark archs/machines that this kernel supports
DEFAULT_PREFERENCE = "-1"
DEFAULT_PREFERENCE_phy3250 = "1"

SRC_URI = "${KERNELORG_MIRROR}/pub/linux/kernel/v2.6/linux-${PV}.tar.bz2 \
           file://defconfig "

SRC_URI_append_phy3250 = "file://phy3250.patch;patch=1"

Re: Strange do_patch behaviour

[Chris Conroy]

On Wed, 2009-08-26 at 19:33 +0600, Dmitry Vinokurov wrote:
> ------------
> And looks like bitbake did nothing except patching, but actually it does 
> (diff between manually and bitbake patched dirs is ~30000 strings, and I 
> decided not to attach it:)) and as a result builded kernel fails with 
> kernel panic. Diff shows, that '.pc' dir is created (and some files in 
> it are forbidden for any access (0000 rights)) and not only it -- some 
> other files like in arch/arm or sound/soc/lpc3xxx/ differs too. Tried to 
> remove tmp/ and rebuild -- same result.
> 
> Could anybody explain this strange behaviour? I thought that patch task 
> should only execute 'patch' command.
> 

Bitbake uses a tool called 'quilt' in order to do the patching, and
quilt creates the .pc directory. Basically, quilt lets you deal with
patches as a stack. If you go into the linux work directory, you should
be able to run quilt commands to manually figure out what OE is patching
here.

'quilt applied' to see what patches are applied
'quilt pop' to pop a patch off the stack
'quilt push' to push a patch onto the stack.

Some Quilt Links:
Very helpful presentation: http://www.coffeebreaks.org/blogs/wp-content/archives/talks/2005/quilt/quiltintro-s5.html
Overview PDF: http://www.suse.de/~agruen/quilt.pdf
Savannah page: http://savannah.nongnu.org/projects/quilt

Re: Strange do_patch behaviour

[Dmitry Vinokurov]

Chris Conroy wrote:
> On Wed, 2009-08-26 at 19:33 +0600, Dmitry Vinokurov wrote:
>   
>> ------------
>> And looks like bitbake did nothing except patching, but actually it does 
>> (diff between manually and bitbake patched dirs is ~30000 strings, and I 
>> decided not to attach it:)) and as a result builded kernel fails with 
>> kernel panic. Diff shows, that '.pc' dir is created (and some files in 
>> it are forbidden for any access (0000 rights)) and not only it -- some 
>> other files like in arch/arm or sound/soc/lpc3xxx/ differs too. Tried to 
>> remove tmp/ and rebuild -- same result.
>>
>> Could anybody explain this strange behaviour? I thought that patch task 
>> should only execute 'patch' command.
>>
>>     
>
> Bitbake uses a tool called 'quilt' in order to do the patching, and
> quilt creates the .pc directory. Basically, quilt lets you deal with
> patches as a stack. If you go into the linux work directory, you should
> be able to run quilt commands to manually figure out what OE is patching
> here.
>
> 'quilt applied' to see what patches are applied
> 'quilt pop' to pop a patch off the stack
> 'quilt push' to push a patch onto the stack.
>
> Some Quilt Links:
> Very helpful presentation: http://www.coffeebreaks.org/blogs/wp-content/archives/talks/2005/quilt/quiltintro-s5.html
> Overview PDF: http://www.suse.de/~agruen/quilt.pdf
> Savannah page: http://savannah.nongnu.org/projects/quilt
>   
Thanks, refs and information was really helpful. Actually the only 
differences were in .pc and patches/, the only one applied patch was my 
phy3250. I just was inattentive and confused strings with differences in 
files and strings with file names.

--
Best Regards, 
Dmitry Vinokurov 
<d.vinokuroff@gmail.com>