2016-04-22 14:57 GMT+02:00 Bruce Ashfield <[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]>>: >> >> 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> 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>, 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 ? How does this SRCREV relation work ? Its a SHA1 sum of which repo ? (With this info I think I could create a local patch for the yocto sources fixing this issue for our specific situation.) > > Bruce > > > >> Hugo >> >> >> >> Bruce >> >> >> With kind regards, >> >> H.Heutinck >> >> >> >> >> >> >> >> >
-- _______________________________________________ linux-yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/linux-yocto
