Date
1 - 8 of 8
SRCREV spec not working for kernel git recipes
|
Elvis Dowson
Hi,
I find that specifying a SRCREV doesn't work for kernel git recipes. The following recipe has SRCREV set to the commit id for xilinx_v2.6.37, but during the build process, it is always taking the latest commit id from the master branch, which is at 3.3.0. I checked the tmp/work/virtex5-poky-linux/linux-xilinx-2.6.37+git1+ed63a4d76efadcb68f5776e4244766ffea226cc4-r17/git/Makefile and it clearly is building linux kernel 3.3.0 instead of 2.6.37 contents of Makefile: VERSION = 3 PATCHLEVEL = 3 SUBLEVEL = 0 EXTRAVERSION = -14.2-build1 NAME = Saber-toothed Squirrel recipe linux-xilinx_git.bb inherit kernel xilinx-kernel xilinx-utils require recipes-kernel/linux/linux-dtb.inc DESCRIPTION = "Linux kernel for Xilinx platforms" COMPATIBLE_MACHINE = "(virtex4|virtex5|virtex5mb|spartan6-sp605|spartan6-lx9mb)" LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" KBRANCH = "master" SRCREV = "a5556fb251253ccb674bd22d9703c37f6f8807a8" LINUX_VERSION ?= "2.6.37" PR = "r17" PV = "${LINUX_VERSION}+git${SRCPV}" XILINX_BOARD ?= "${@find_board(bb.data.getVar('XILINX_BSP_PATH', d, 1), d)}" KERNEL_DEVICETREE = "${@device_tree(bb.data.getVar('TARGET_ARCH', d, 1), d)}" KERNEL_DEVICETREE_microblazeel = "${@device_tree(bb.data.getVar('TARGET_CPU', d, 1), d)}" S = "${WORKDIR}/git" Elvis Dowson |
|
|
|
Elvis Dowson
Hi,
I found out that if I specify SRCREV_pn-${PN}, it works and picks up the correct commit id, as follows: SRCREV_pn-${PN} = "a5556fb251253ccb674bd22d9703c37f6f8807a8" However, if you simply specifying SRCREV = "a5556fb251253ccb674bd22d9703c37f6f8807a8", it has no effect and it always picks up the latest commit from the git repository. It would be great if someone could please explain why this is so, because I search through the Yocto documentation and it isn't mentioned anywhere. The OE classic way of doing things, it used to pick up the correct commit by just specifying SRCREV. Now I find that you have to specify SRCREV_pn-${PN} to get it to work. Is this documented somewhere? Best regards, Elvis Dowson |
|
|
|
On Fri, Jun 22, 2012 at 11:16 PM, Elvis Dowson <elvis.dowson@...> wrote:
Hi,? can you port bitbake -e virtual/kernel output with and without change somewhere ?
|
|
|
|
Elvis Dowson
Hi Khem,
On Jun 23, 2012, at 11:29 AM, Khem Raj wrote: I found out that if I specify SRCREV_pn-${PN}, it works and picks up the correct commit id, as follows:? The output files are rather large. BTW, I do not have a PROVIDES += "virtual/kernel" entry in the linux-xilinx kernel recipes. Is that necessary to get SRCREV to work? Best regards, Elvis Dowson |
|
|
|
Elvis Dowson
Hi,
On Jun 23, 2012, at 11:57 AM, Elvis Dowson wrote: Hi Khem,Even adding a PROVIDES += "virtual/kernel" entry to the linux-xilinx recipe did not change the behavior. So for the moment, SRCREV doesn't seem to have any effect, but SRCREV_pn-${PN} works. Best regards, Elvis Dowson |
|
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 On 6/23/2012 12:57 AM, Elvis Dowson wrote: Hi Khem,hmm I see SRCREV = "AUTOINC" in faulty case which is your problem comes from meta-xilinx layer it sets SRCEREV in conf/distro/include/xilinx-default-revisions.inc SRCREV_pn-u-boot-xilinx ?= "${AUTOREV}" SRCREV_pn-linux-xilinx ?= "${AUTOREV}" that setting up SRCREV to be top of tree and its using pn-${PN} override so whatever you set without override will be overwritten by this the reson why SRCREV_pn-${PN} worked is because this is a weak assignment so when you defined yours that one took precedence. Best regards, -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/l3fIACgkQuwUzVZGdMxRyLQCeP7mdXN/95Nkm264x7ENSpfYe f/EAoIZsF0yE0HbOD90iz0jYAwrlPmjJ =GzN2 -----END PGP SIGNATURE----- |
|
|
|
Elvis Dowson
Hi Khem,
On Jun 23, 2012, at 7:17 PM, Khem Raj wrote:
What do you recommend I do? Best regards, Elvis Dowson |
|
|
|
On Sat, Jun 23, 2012 at 9:04 AM, Elvis Dowson <elvis.dowson@...> wrote:
well I think redefining overridden value is right if you dont want to modify the layer policy SRCREV_pn-${PN} is the way to go with this layer then |
|
|