RPI2 Kernel module compilation (kernel 3.18.11+ vs 3.18.11-v7+)

Question

I want to recompile a kernel module/driver on my RPI2 for my RPI2.

The command uname -a gives me:

Linux cpf 3.18.11-v7+ #781 SMP PREEMPT Tue Apr 21 18:07:59 BST 2015 armv7l GNU/Linux

Q1) What is the difference between kernel "3.18.11" and "3.18.11-v7+" ?

Q2) I'm planning to get this kernel source:

wget https://github.com/raspberrypi/linux/archive/rpi-3.18.y.tar.gz

Is this the correct source for my kernel ?

Q3) Why can't I install the kernel header like I usually do on my Ubuntu machine.

sudo apt-get install linux-headers-$(uname -r)

Answer 1

1. What is the difference between kernel "3.18.11" and "3.18.11-v7+"?

   The -v7+ is tacked on to indicate this isn't from a vanilla source tree, and that it was compiled specifically for the Pi 2.

2. I'm planning to get this kernel source: wget https://github.com/raspberrypi/linux/archive/rpi-3.18.y.tar.gz Is this the correct source for my kernel?

   No. If you look at the makefile you'll notice it's 3.18.16.

   However, if you are using a stock kernel from a Raspbian image, you can get the git commit hash this way on the pi (thanks to the OP and this):

   • zcat /usr/share/doc/raspberrypi-bootloader/changelog.Debian.gz | head

     This will spit out the first couple stanzas of a repeated sequence that includes something like firmware as of 960832a6c2590635216c296b6ee0bebf67b21d50. This hex string may be much shorter. You want the most recent one (i.e., the first one in that file).¹ Next:

     wget https://raw.github.com/raspberrypi/firmware/THAT_STRING/extra/git_hash -O -
     

     Where THAT_STRING is the commit hash from the changelog. This will dump another such string amidst the wget output.

   • If it works, you can now install the kernel source:

     git clone https://github.com/raspberrypi/linux
     git checkout THAT_OTHER_STRING
     

     For example, for the last Raspbian image (2015-09-24), THAT_OTHER_STRING fetched by wget is 0be82f722c097340632a59b879fbfee9c6148f53.

     Beware the initial clone here is more than a GB of stuff, and after the checkout you may end up with 2+ GB.

     Make sure this is really the right version by looking in the top level Makefile.

   If you are using some other Debian variant, the same methodology should work. If not, or you are using a kernel from rpi-update, or you would just rather browse around for what you want, you can always start with the commits link from the web view of the repo. Actual version commits are easy to find because they feature a head shot of Greg K.H. They seem to be at least a few pages or so apart.

3. Why can't I install the kernel header like I do on my Ubuntu machine.

   This is an unfortunate strategy of the people who maintain Raspbian.

---

With regard to building from source, from the toplevel of the tree you can use:

make bcm2709_defconfig

To create the same .config as used for the pre-compiled version of -v7+. You can also copy one in from a running kernel (copy /proc/config.gz in and gunzip -c config.gz > .config), then run make menuconfig and exit, saving. This may be less hassle than make oldconfig.

To build this on a Pi 2 will take an hour or so, I'd guess, but it is not that hard to cross compile if you have another linux box since most distros have a packaged ARMv7 cross compiler that is suitable. If you are uncertain about what "cross compiling" means, there are various instructions around (again, this is good), or just do it right on the pi.

---

^{1. Note that it does not match up with the VC_BUILD_ID_VERSION from start.elf, or vcgencmd version. But if all else fails you can try those and whatever else you want, e.g. /boot/.firmware_revision. In my tests none of these resolved to a commit from the public repo, but the chance of ending up with a hash that's coincidentally both an actual commit and not the one you want seems pretty slim. Or (see the last paragraph of #2 above), you can just browse commits via the web...}