7

In the boot partition there are two kernels, kernel.img and kernel7.img (for the pi 1 vs 2/3). How does the system know which to load?

plastic chris
  • 213
  • 1
  • 2
  • 7

2 Answers2

10

All the boot magic is in /boot/config.txt.

kernel: The alternative filename on the boot partition to use when loading the kernel; the default value is kernel.img.

from official documentation

Update: to clear up some confusion and to satisfy my curiosity, I tried the following small experiment.

I DO NOT RECOMMEND YOU TRY THIS!

  1. On my RPi3 I do not have the kernel entry in config.txt, and the system boots up fine.
  2. I deleted kernel.img.
  3. I renamed kernel7.img to foo.bar.
  4. After rebooting the RPi, the system failed to load. I got the multi-colour screen of death, as expected.
  5. I added kernel=foo.bar to my config.txt.
  6. Rebooted the system, and it worked.

This proves two things:

  1. The system can intelligently select the correct kernel per architecture, within some limits.
  2. The kernel entry in config.txt works if used.
SiKing
  • 347
  • 2
  • 12
  • This is NOT used by normal images. – Milliways Jan 23 '17 at 23:59
  • @Milliways What do you consider "normal" in this context? There are several sources, for example this http://raspberrypi.stackexchange.com/q/10489/53481 and several things linked from there, that agree with me. – SiKing Jan 24 '17 at 00:07
  • By "normal" I mean any of the prebuilt images downloadable from the Foundation site. The post you linked is an earlier version of the link in my answer (before loader.bin was removed). – Milliways Jan 24 '17 at 00:20
  • From the linked docs it seems /boot/config.txt is passed as an argument to the closed source GPU firmware start.elf which then launches the kernel specified - the confusing bit is that it seems all the boards use the pi 1 kernel image out of the box, but still contain a kernel7.img in /boot I guess that's what's necessary for one SD card image to work across all the boards. – plastic chris Jan 24 '17 at 05:44
  • @plasticchris: Indeed. Pi 1 doesn't use the kernel7.img at all (and vice versa, Pi 3 doesn't user kernel.img) , but they're both included (with their dependencies). I suspect that it allows for using the same card in various RPi models automagically. – Piskvor left the building Feb 26 '19 at 12:56
2

See http://elinux.org/RPi_Software#Overview which describes the Pi boot process.

Basically bootcode.bin analyses the hardware and (presumably) decides which kernel to load. (The source is not publicly available).

It is (or was) possible to specify a different kernel, but this is NOT used by normal images.

NOTE With the new USB/Network boot options for the Pi3 the process has changed but the principle remains similar.

For those interested in reading more about the new boot options Raspberry Pi boot modes

Milliways
  • 59,890
  • 31
  • 101
  • 209
  • From your link, I read that completely differently. "Second stage bootloader (bootcode.bin) - This is used to retrieve the GPU firmware from the SD card, program the firmware, then start the GPU." Reading further: "User code - This can be one of any number of binaries. By default, it is the Linux kernel (usually named kernel.img), but it can also be another bootloader (e.g. U-Boot), or a bare-bones application." – SiKing Jan 24 '17 at 00:09
  • 1
    FYI: I tried a small experiment to verify my answer. See my update. – SiKing Jan 30 '17 at 05:49
  • @SiKing I don't understand why you are deliberately misinterpreting my answer. I said the kernel option "is NOT used by normal images" NOT that it couldn't be done. This is easily verified by looking at config.txt in any standard image. – Milliways Jan 30 '17 at 06:40
  • @SiKing You are also NOT answering the actual question "How does the system know which to load" NOT what other methods can be used to load kernels. – Milliways Jan 30 '17 at 06:42
  • 1
    I think we are both saying the same thing. I was just trying to clarify my answer. Maybe I failed. Sorry. – SiKing Jan 30 '17 at 16:54
  • these threads have been very constructive and right on point, IMO. Understanding how these devices work is difficult and general discussion on options and limitations is super helpful. – Marc Compere Feb 21 '22 at 19:52