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"

KBRANCH = "master"

SRCREV = "a5556fb251253ccb674bd22d9703c37f6f8807a8"

           file://defconfig"

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


Khem Raj
 

On Fri, Jun 22, 2012 at 11:16 PM, Elvis Dowson <elvis.dowson@...> wrote:
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?
?
can you port bitbake -e virtual/kernel output with and without change
somewhere ?

Best regards,

Elvis Dowson
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


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:

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?
?
can you port bitbake -e virtual/kernel output with and without change
somewhere ?

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,

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:

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?
?
can you port bitbake -e virtual/kernel output with and without change
somewhere ?

The output files are rather large.

<SRCREV_pn-.txt><SRCREV.txt>

BTW, I do not have a PROVIDES += "virtual/kernel" entry in the linux-xilinx kernel recipes. Is that necessary to get SRCREV to work?
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


Khem Raj
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 6/23/2012 12:57 AM, Elvis Dowson wrote:
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:

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?
? can you port bitbake -e virtual/kernel output with and without
change somewhere ?

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?
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,

Elvis Dowson

-----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:

BTW, I do not have a PROVIDES += "virtual/kernel" entry in the
linux-xilinx kernel recipes. Is that necessary to get SRCREV to
work?

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.

What do you recommend I do? 

Best regards,

Elvis Dowson


Khem Raj
 

On Sat, Jun 23, 2012 at 9:04 AM, Elvis Dowson <elvis.dowson@...> wrote:

What do you recommend I do?
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