3

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)
Greenonline
  • 2,448
  • 4
  • 18
  • 33
ssinfod
  • 586
  • 2
  • 10
  • 19

1 Answers1

6
  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).1 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...

goldilocks
  • 56,430
  • 17
  • 109
  • 217
  • Can I update my kernel to a specific version ? (Ex: 3.18.16). – ssinfod Oct 05 '15 at 19:21
  • Does the 3.18.16 vs 3.18.11 have the same kernel API ? I mean.. is it close enough the compile a driver ? When does the kernel API changes ? (Is it with a minor or major number change?) – ssinfod Oct 05 '15 at 19:22
  • It will be almost exactly the same and within major numbers I believe there's an effort to keep the API backward compatible. But that's not the problem. By default the kernel is configured to reject modules that do not have an identical version signature. As for updating to a specific version from the firmware, I'm not handy enough w/ git to tell you if that's even possible... – goldilocks Oct 05 '15 at 19:35
  • ...However, I think I'm wrong about what you'll get from `rpi-update`, since it actually pulls [from here](https://github.com/Hexxeh/rpi-firmware) which is at 4.1.10+. Then you could use the current 4.1.y source branch. Worth trying -- but back up your current kernel first or you might not be able to get one back again, lol! – goldilocks Oct 05 '15 at 19:35
  • OK, so I got it working but following the instructions from here: http://lostindetails.com/blog/post/Compiling-a-kernel-module-for-the-raspberry-pi-2 – ssinfod Oct 06 '15 at 03:43
  • That's a good one, thanks -- I've edited in some of the details. Won't work for everyone, but it should work so long as you aren't using a kernel from `rpi-update` (but for that I figured out how to browse the commits online, doh!). Of course, once you have the source and can cross-compile, you can just build and use a kernel from that rather than looking for an exact version match of the one you already have. – goldilocks Oct 06 '15 at 09:54