U-Boot – Universal Bootloader for Embedded Linux System

Introduction to U-Boot

U-Boot (Universal Bootloader) is an open source, primary boot loader used in embedded devices. It is available for a number of different computer architectures, including 68k, ARM, AVR32, Blackfin, MicroBlaze, MIPS, Nios, PPC and x86.

Following are the key features of U-Boot:

  • Monolithic code image
  • Runs processor in physical or a single address space
  • Enables clocking, sets up some of the pin mux settings
  • Reads in Kernel image (uImage)
  • Jumps to load address pointed to in uImage header
  • Passes Kernel Command Line to Kernel
  • Debugging capabilities (just mentioning, not used during boot process)

Embedded U-Boot process

  • Power on
  • U-Boot gets control
  • U-Boot initializes minimum necessary hardware
  • U-Boot runs environment variable “bootcmd” on boot
  • bootcmd tells U-Boot to boot Linux from flash with initramfs and dtb
  • U-Boot loads Linux, initramfs, and dtb from flash into RAM
  • bootcmd boots Linux, passing initramfs and dtb
  • Kernel finds hardware via dtb
  • Kernel extracts initramfs into tmpfs
  • Kernel runs init
  • Init gets userspace up and running

Bootstrapping the U-Boot

The term bootstrapping usually refers to the process of loading the basic software into the memory of a computer after power-on or general reset, especially the operating system which will then take care of loading other software as needed. A bootloader is required to load an operating system. The bootloader starts before any other software starts and initializes the processor and makes CPU ready to execute a software like an operating system.

bootstrapping uboot-1
Bootstrapping U-Boot on ARM System – 1
bootstrapping uboot-2
Bootstrapping U-Boot on ARM System – 2

U-Boot Binary Relocation and Memory Remap

The Process of assigning load address to various parts of program and adjusting the code and data segment to reflect the assigned address is called relocation. In other words, copy the binary from a source address to a new destination address but the binary must be able to execute correctly.
Doing memory relocation usually need adjusting the linking address offsets and global offset table through all binary. If no address adjustment is required, copy binary to destination address with exactly the same as its original address, this requires memory remap.
uboot reloc & mem remap
Two relocation happens in u-boot.

  • One is relocation with remap, which doesn’t need to do address adjustment.
  • The other is general relocation, which need to do address adjustment based on dynamic calculated offsets relative to the top of the DRAM.

Why U-BOOT relocate itself into RAM?

  • Memory access is faster from RAM than from ROM, this matters for system without instruction cache.
  • Execution from RAM allows flash reprogramming, allows software breakpoints with “trap” instructions.
  • Variable cannot be modified when it is stored in ROM.
  • Boot loader must copy itself into RAM to update the variables correctly.
  • Function calls relies on stack operation, which is to be stored in RAM.
This entry was posted in Technical and tagged , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *