On 2016-04-22 9:28 AM, Hugo Heutinck wrote:
2016-04-22 14:57 GMT+02:00 Bruce Ashfield <[email protected]
<mailto:[email protected]>>:
On 2016-04-22 3:21 AM, Hugo Heutinck wrote:
2016-04-21 15:22 GMT+02:00 Bruce Ashfield
<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>:
On 2016-04-21 7:42 AM, Hugo Heutinck wrote:
Hello,
I was wondering what the relation is between the
kernel-4.1.6-yocto-standard and the actual kernel
version being used
4.1.15 ?
Logging shows e.g. kernel-4.1.6-yocto-standard:armel
(4.1.15+git0+46bb64d605_efb6ffb2ca-r0) ...
I assume this is some kind of mapping to keep yocto
kernel changes /
updates separate from the kernel.org
<http://kernel.org> <http://kernel.org>
<http://kernel.org> versions. But
the issue is that "cat /proc/version" shows a 4.1.6
version while a
4.1.15 kernel is running, and this causes some
confusion between
various
people.
Is it a bad coincidence that both versions are in the
same range
(4.1.x)
or am I missing something here ?
What branch / release are you using ? That shouldn't
happen. The only
way there's a skew is if I forgot to update to the
LINUX_VERSION
variable when merging -stable updates to the tree.
I am using the jethro branch git://git.yoctoproject.org/poky.git
<http://git.yoctoproject.org/poky.git>
<http://git.yoctoproject.org/poky.git>, with last commit
a3a374a639b5d3c0be1e73d23615231dfc0798ce (so from feb 05, 2016)
Master shows: 4.1.18 for both LINUX_VERSION and what I've
merged to
the tree.
.. but the kicker is that the kernel tree is the per kernel
version,
not per-yocto release. So I'm betting you are on an older
branch and
no one has ported my version bump to that release.
If you can confirm the release you are using, I'll see if I
can figure
out a way to keep them in sync.
The meta layer seems to contain the right version:
meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb:LINUX_VERSION ?=
"4.1.15"
meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb:PV =
"${LINUX_VERSION}+git${SRCPV}"
*meta/recipes-kernel/linux/linux-yocto_4.1.bb:LINUX_VERSION ?=
"4.1.15"*
meta/recipes-kernel/linux/linux-yocto_4.1.bb:LINUX_VERSION_qemux86
?=
"4.1.17"
meta/recipes-kernel/linux/linux-yocto_4.1.bb:LINUX_VERSION_qemux86-64
?=
"4.1.17"
*meta/recipes-kernel/linux/linux-yocto_4.1.bb:PV =
"${LINUX_VERSION}+git${SRCPV}"*
meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb:LINUX_VERSION
?= "4.1.15"
meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb:PV =
"${LINUX_VERSION}+git${SRCPV}"
However, looking in the build/work directory, and grepping for
*4.1.6*
or *262406* references I see
beaglebone-poky-linux-gnueabi/linux-yocto/4.1.15+gitAUTOINC+46bb64d605_efb6ffb2ca-r0/
* |-
linux-beaglebone-standard-build/include/generated/utsrelease.h:#define
UTS_RELEASE "4.1.6-yocto-standard"*
|-
linux-beaglebone-standard-build/include/generated/autoconf.h: *
Linux/arm 4.1.6 Kernel Configuration
|-
linux-beaglebone-standard-build/include/config/tristate.conf:#
Linux/arm 4.1.6 Kernel Configuration
|-
linux-beaglebone-standard-build/include/config/auto.conf.cmd:ifneq
"$(KERNELVERSION)" "4.1.6"
|- linux-beaglebone-standard-build/include/config/auto.conf:#
Linux/arm 4.1.6 Kernel Configuration
* |-
linux-beaglebone-standard-build/include/config/kernel.release:4.1.6-yocto-standard*
|-
*linux-beaglebone-standard-build/include/generated/uapi/linux/version.h:#define
LINUX_VERSION_CODE 262406*
Aha.
Its the same thing that I was mentioning, just a different
manifestation.
The reference boards have their own SRCREVs set in meta-yocto-bsp, and
those SRCREVs haven't been bumped on the older releases. So there's
a skew between the main kernel recipe (which is setting the linux
version (and PV)) and the boards.
I have an open bugzilla to make sure that version is consistent in a
situation such as this, but it isnt complete yet.
Do you have a ticket id for this issue so I can track it ?
It's an old one:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6767
But really, there's no code to be written for it, just making sure
that the kernel version is set in the meta-yocto-bsp bbappends.
How does this SRCREV relation work ?
It's the git hash of the BSP branch that is to be built.
Its a SHA1 sum of which repo ?
git.yoctoproject.org/linux-yocto-4.1.git
(With this info I think I could create a local patch for the yocto
sources fixing this issue for our specific situation.)
See: meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.1.bbappend
SRCREV_machine_beaglebone ?= "efb6ffb2ca96a364f916c9890ad023fc595e0e6e"
If you look at that commit, it is 4.1.6 for that board. You can
update that in your local layers if you want (and have tested)
a newer commit (i.e. tip of standard/beaglebone in the linux-yocto-4.1
kernel tree).
Also see in that file where the generic BSP bumps its version since
it uses a new SRCREV.
LINUX_VERSION_genericx86 = "4.1.18"
LINUX_VERSION_genericx86-64 = "4.1.18"
So the BSPs on older revs, really should set their own version, but
it just hasn't happened yet .. since ideally whenever I update the
kernel tree, the references are tested, updated .. and are always
in sync. But of course, that doesn't always happen, since time is
limited :)
Bruce
Bruce
Hugo
Bruce
With kind regards,
H.Heutinck
--
_______________________________________________
linux-yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/linux-yocto
