0

I am learning about u-boot and how this works in the Raspberry Pi system. This is what I understood so far:

  • The first stage from the RPI cannot or should be modified. In this stage the BootROM simply loads the bootloader from the flash EEPROM.
  • In the second stage the EEPROM boot loader finds and loads start.elf, whose task is to load the kernel. It first reads "config.txt" which contains a kernel parameter. This is where u-boot is "injected". kernel=u-boot.bin

U-boot can then in turn load the actual kernel. For a CM4 this would be "kernel7l.img".

I would be super satisfied with this knowledge, but in practice I have (possibly) seen other ways of integrating u-boot. I am here referring, for example, to Yocto recipes for the CM4 (meta-raspberrypi / u-boot). The boot directory of such an image contains: boot.scr, uboot.env, and uImage.

The readable part of boot.scr specifies that uImage will be loaded:

value bootargs /chosen bootargs
fatload mmc 0:1 ${kernel_addr_r} uImage
if test ! -e mmc 0:1 uboot.env; then saveenv; fi;
bootm ${kernel_addr_r} - ${fdt_addr}

config.txt does not contain a kernel parameter.

So here my questions for this boot process:

  1. start.elf cannot be modified since it is proprietary. How can it load u-boot if there is no kernel parameter in config.txt pointing to a binary u-boot? boot.scr is supposed to run before u-boot.bin. Who reads and executes boot.scr?
  2. is uImage just another name for u-boot.bin?
  3. In this scheme how does u-boot know it must load "kernel7l.img"?
  4. Are there other ways of integrating u-boot in a RaspberryPi? Is there any documentation which describes these different integration schemes?

Thank you very much for your help!

Anthony Arrascue
  • 220
  • 1
  • 2
  • 13
  • *"This is what I understood so far:..."* -- You omit salient concepts such as what processor is executing code, where that code was stored, and to where the code is loaded and executed. The RPi boot sequence you try to describe is atypical for an ARM-based SBC because the RPi uses a co-processor (its GPU) for booting. Typically an ARM SoC simply uses the ARM processor to boot the board. – sawdust Jul 08 '21 at 21:35

2 Answers2

0

The boot.scr script is read by U-Boot.

fatload mmc 0:1 ${kernel_addr_r} uImage loads a kernel in deprecated U-Boot specific format which can be created with the mkimage command.

The bootm ${kernel_addr_r} - ${fdt_addr} command receives the addresses of uImage and the device tree. The address for the initrd is left out ('-'). bootm starts the kernel and passes the device tree address to it.

Adding kernel=u-boot.bin to config.txt is the correct way to invoke U-Boot on a Raspberry.

Distributions like Suse and Fedora prefer to boot Linux via GRUB on the Raspberry using U-Boot's bootefi command.

Xypron
  • 2,215
  • 1
  • 12
  • 24
0

So here my questions for this boot process:

  1. start.elf cannot be modified since it is proprietary. How can it load u-boot if there is no kernel parameter in config.txt pointing to a binary u-boot?

The kernel=... parameter in the config.txt is an optional parameter that specifies an alternate (kernel) filename to load by the EEPROM boot program.
The default filename to load from the boot partition depends on the RPI version.

According to RPi documentation, the default kernel filename on the Pi 1, Pi Zero, and Compute Module is kernel.img, on the Pi 2, Pi 3, and Compute Module 3 it is kernel7.img, and on the Pi4 it is kernel7l.img

If "there is no kernel parameter", then inspect the kernelx.img file; what are the contents?

boot.scr is supposed to run before u-boot.bin. Who reads and executes boot.scr?

Incorrect, boot.scr is not "run before u-boot.bin".
The file boot.scr contains script that can be interpreted by U-Boot.
(The executable image for U-Boot is the u-boot.bin file.)

  1. is uImage just another name for u-boot.bin?

No, those are two distinct filenames with completely different uses.
The u-boot.bin file is the executable image for U-Boot.
A uImage file is a kernel image with the U-Boot wrapper for identification and verification. The U-Boot wrapper/header can be used for a variety of objects such a U-Boot script or a standalone executable besides a kernel image.
See Image vs zImage vs uImage

  1. In this scheme how does u-boot know it must load "kernel7l.img"?

U-Boot does not have that directive (in this situation).
According to the boot.scr file that you posted, the booting sequence that U-Boot will perform is to load the uImage from the boot partition.

  1. Are there other ways of integrating u-boot in a RaspberryPi? Is there any documentation which describes these different integration schemes?

As mentioned in your post and the other answer, an explicit kernel=u-boot.bin in the config.txt would be the obvious/preferred method to invoke U-Boot.
Otherwise, IDK. Today's alternative could be tomorrow's deprecated method.

sawdust
  • 16,103
  • 3
  • 40
  • 50