.

.

Unter dieser Überschrift werden der geräte-neutrale Boot-Prozess eines embedded Systems mit einem ARM basierten "SoC" verständlich skizziert.

Bootloader is called a program, that initializes the system to basic-level and loads the kernel. Basic initialization is a part prior of kernel loading i.e. it initializes the parts of system which are needed to load the kernel. In short, bootloader performs all activities to create execution environment for kernel.

In controller, bootloaders job is to load and execute main application, receive and program application code to flash memory i.e. firmware upgrade.
.

After power-on or reset (POR) only one single cpu core and static memory can be used. Other resources such as DRAM, NAND flash, mmc controllers and discs need to be configured and initialized separately and these interfaces are not accessible.

Static memory available on SOC is very limited and it is not possible to load kernel code into it. How much "on chip" boot-rom and SRAM is available ?
.

The boot process begins at Power On Reset (POR) where the hardware reset logic forces the (first) ARM core to begin execution starting from the "on-chip" Boot ROM. Processor/controller starts the execution of instructions from the address which is called reset vector. Jump instruction is there at the reset vector, which points to the start of the Boot ROM.
.

Boot ROM program is provided by SoC manufacturer. The Boot ROM program called PPL is copied into SRAM and executes from SRAM - as DRAM configurations are not known at the time of manufacturing. Boot ROM code cannot initialize the DRAM.

As part of start-up Boot ROM code (PPL) configures the "PLL" (phase locked loop) and sets clock and watchdog timer. So that it can escape from dead-loops while booting.

As seen in the above figure, PPL ROM code is capable of initializing some drivers and protocols such as UART, SPI, USB, FAT etc. so that external devices / protocols can be interfaced with SoC and "Secondary Program Loader" can be loaded into the SRAM.

The initial PPL ROM Code can perform following booting procedures:

Memory Booting:
Booting the device by starting code stored on permanent memories like flash-memory or memory cards. This process is usually performed after either device cold or warm reset. Memory booting is performed when the memory is of type NOR-flash, NAND-flash, MMC or spi-flash.

Peripheral Booting:
Booting the device by downloading the executable code over a communication interface like UART, USB or Ethernet (TFTP). This process is intended for flashing a device. Peripheral booting is performed when device is of type – USB, Ethernet or UART.
.

ROM code generates the device list based on "SYS BOOT (configuration pins) read value. Once, the booting procedure is finalized i.e. depending on memory or peripheral device, ROM code loads the "SPL" program (from spi-flash) into SRAM. If it fails to find the device or to validate and run the SPL program then system will get into the dead loop and watchdog timer gets triggered and resets the SoC.
.

After successful execution of phase 1, the "SPL" gets loaded into the SRAM. Within Zyxel NAS-Systems it is in the partition-1 (uloader) of the spi-flash.
.

SRAM size on a SoC is very limited (in KiloBytes), and DRAM which is external peripheral of SoC is not operational - as it requires its configuration to be known to the program to be initialized. So we need a program which can take the DRAM configurations provided by board manufacturer and initialize the DRAM and load the TPL = "tertiary program loader" into DRAM.

Functionality of SPL is limited by SRAM size. Primary responsibility of SRAM is to initialize the DRAM and load TPL into DRAM and pass the control to TPL.

Difference between "call" and "passing control" :

1. When a program (das kann auch ein Script sein) passes (übergibt) control to next program, then the calling programs role ends at that point and that program is not expected to run until the reset after passing control.
2. Whereas, when one program calls (aufruft) another program, the called program (das aufgerufene Programm) is expected to return the control to calling program.

.

The TPL (bei uns das Mini-Operating-System barebox) loads the kernel (den Zyxel Kernel) into DRAM. Depending on the configuration it can load the initramfs (das virtuelle Dateisystem) and FDT into DRAM.

Other responsibilities of TPL includes, loading new boot and kernel images into flash storage. U-boot, barebox are the well known and most used TPL.
.

First, bootloader has to pass a pointer to a structure containing information about the hardware configuration, and second it has to pass a pointer to the kernel command line.

The kernel command line is a text string (eine etwas längere Zeile) that controls the behavior of Linux. Once the kernel has begun executing, the bootloader is no longer needed and all the memory it was using can be reclaimed by other programs. Der belegte Speicherbreich im RAM wird wieder freigegeben.
.

.

Der PPL kann ja nichts weiter, als aus seinem kleinen SRAM heraus den Ur-Loader "SPL" aus dem spi-flash-Speicher laden. Dieses Programm (SPL) beginnt an Adresse 0000 des flash-Speichers. Bei Zyxel ist diese Adresse sogar doppelt belegt. Das fällt nicht auf, weil der "PPL" nur seriell auf das spi-flash zugreifen kann. Das NAND-flash muß später über einen nachzuladenden Treiber angesprochen werden. Weiterhin wird der Zugriff auf das NAND-flash mit einem Offset in höhere Adress-Regionen verlegt.

Der SPL-Loader kann über einen Block-Treiber die drei Zyxel-Partitionen des spi-flashs adressieren und so aus der partition-2 den eigentlichen barbox Loader (TPL) ins RAM kopieren (sowie bereits Scripte ausführen ?).

Das barebox Modul, der "TPL", ist bereits recht intelligent und kann viel. Dieser Loader kann aus dem spi-flash gezielt einen (bei uns 8MB großen) Ubuntu/Debian Kernel ins RAM koiperen sowie eine 150 MB große RAM-Disk anlegen und die Verzeichnis- Srukturen darin aufbauen.
.

Die Entwicklung von "barebox" aus dem vorhanden "U-Boot" Loader war gezielt auf eine flexiblere Hardwareunabhängigkeit ausgelegt. Die verschiedenen Stages des Bootvorganges holen ihre Konfig-Infos aus Shell-Sripten und derer gibt es viele.

Es git da einen "init"-(1) Script und einen "env" Script in der partition-3 des spi-flash Speichers, der weitere Shell-Scripte teilweise verschachtelt aufruft.
.
Auch eine sogenannte ATAG Liste gibt es, die ebenfalls im spi-flash abgelegt ist.
.