This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Adjusting the uname in the kernel

One of the first steps I took with the code from the SDK was to put it into Git, such that changes I made were traceable. I recently tried to "reset" myself by removing the old board-support/linux-3.12.10-ti2013.12.01 and replacing it with my version from Git.

Once I did that, the build started changing. I found that the uname -r command now returned:

3.12.10-g8e4a6e5-dirty

So I started looking into how I could change that string. I found references to it in a few files:

include/generated/utsrelease.h:#define UTS_RELEASE "3.12.10-g8e4a6e5-dirty"<br>
include/config/kernel.release:3.12.10-g8e4a6e5-dirty

But it seems that utsrelease.h was created from kernel.release's content, and that is set in the kernel makefile via a call out to scripts/setlocalversion

I found the following lines in there:

	# Check for git and a git repo.
	if test -d .git && head=`git rev-parse --verify --short HEAD 2>/dev/null`; then

		# If we are at a tagged commit (like "v2.6.30-rc6"), we ignore
		# it, because this version is defined in the top level Makefile.
		if [ -z "`git describe --exact-match 2>/dev/null`" ]; then

			# If only the short version is requested, don't bother
			# running further git commands
			if $short; then
				echo "+"
				return
			fi
			# If we are past a tagged commit (like
			# "v2.6.30-rc5-302-g72357d5"), we pretty print it.
			if atag="`git describe 2>/dev/null`"; then
				echo "$atag" | awk -F- '{printf("-%05d-%s", $(NF-1),$(NF))}'

			# If we don't have a tag at all we print -g{commitish}.
			else
				printf '%s%s' -g $head
			fi
		fi

		# Is this git on svn?
		if git config --get svn-remote.svn.url >/dev/null; then
			printf -- '-svn%s' "`git svn find-rev $head`"
		fi

		# Check for uncommitted changes
		if git diff-index --name-only HEAD | grep -qv "^scripts/package"; then
			printf '%s' -dirty
		fi

		# All done with git
		return
	fi

This is clearly how it's being set. I removed everything internal to the "if" check for git and replaced it with a print of:

printf '%s' "3.12.10-ti2013.12.01"

That worked... but when the kernel booted it was looking for /lib/modules/3.12.103.12.10-ti2013.12.01 and when I tried to remove the initial 3.12.10 from my string then the kernel refused to boot getting stuck at about 3 seconds in.

So my question is: Can the string, which generates uname -r, be updated somehow manually? If so what changes would be required to do this?

  • I will forward this to the SW team.

  • Hi Mike,

    The messages 3.12.10-g8e4a6e5-dirty are from MLO and u-boot. You can see these definition on a <>/ti-sdk-am335x-evm-07.00.00.00/board-support/u-boot-2013.10-ti2013.12.01/Makefile. You will see two definition PLAIN_VERSION and U_BOOT_VERSION which generated on line 795. If you want to change whatever you can make here.
    From uname -r you see the part of second linux line: Linux version 3.12.10-ti2013.12.01 ... This information is generated in <>ti-sdk-am335x-evm-07.00.00.00/board-support/linux-3.12.10-ti2013.12.01/init/version.c file in linux_banner[] array. If you want to change whatever see well definition and changed them. With changing in <>/ti-sdk-am335x-evm-07.00.00.00/board-support/linux-3.12.10-ti2013.12.01/Makefile definition of VERSION, PATCHLEVEL, ... you can change version number.

    BR
    Ivan

  • Hi Ivan,

    I have a few follow up questions.

    Ivan Matrakov said:


    From uname -r you see the part of second linux line: Linux version 3.12.10-ti2013.12.01 ... This information is generated in <>ti-sdk-am335x-evm-07.00.00.00/board-support/linux-3.12.10-ti2013.12.01/init/version.c file in linux_banner[] array.

    I see the code you're talking about:

    /* FIXED STRINGS! Don't touch! */
    const char linux_banner[] =
    	"Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
    	LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n";
    

    I feel like chaning the value here isn't quite what I was looking for, I was hoping I'd be able to change these values at the source so any place they may be used could be propagated.

    Ivan Matrakov said:


    With changing in <>/ti-sdk-am335x-evm-07.00.00.00/board-support/linux-3.12.10-ti2013.12.01/Makefile definition of VERSION, PATCHLEVEL, ... you can change version number.



    Yes, this is what I was looking at initially, I like the thought of updating things in the Makefile. I see there VERSION, PATCHLEVEL, etc are used to build up the KERNELVERSION (the 3.12.10 part):

    KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
    KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)

    It seems the KERNELRELEASE is the part I'm a little confused on. I see this comes from the kernel.release file which is generated every build time. I found this file gets the "g8e4a6e5-dirty" part of the message due to scripts/setlocalversion script, but I wasn't sure how or where to resolve this to be whatever I'd like. Do you have information on that specific point, or is that where you linux_banner array should come up?

    Thanks.

    -Mike

  • In the top level Makefile, I just change the EXTRAVERSION define for customized kernels, with the format:

    -AA.BB

    where AA and BB is our own custom version tracking number.  So uname results in:

    3.x.x-AA.BB

    I leave the other fields alone to indicate the base kernel that it was derived from.  Of course, if you are the official kernel maintainer, you would modify Version, patch and sublevel as you see fit.

  • Mike Worster said:
    It seems the KERNELRELEASE is the part I'm a little confused on. I see this comes from the kernel.release file which is generated every build time. I found this file gets the "g8e4a6e5-dirty" part of the message due to scripts/setlocalversion script, but I wasn't sure how or where to resolve this to be whatever I'd like

    The "-dirty" is because you have uncommitted changes.  I suspect that if you've assigned a tag to a given commit that it uses the tag name instead of the commit id.  I know that ti2013.12.01 is the name of the tag in our development tree for that release, so that seems to fit.