The Bootloader is a piece of software that is executed every time a hardware device is powered up. It is executable machine code and thus ARCH-specific. Because its main task is to initialize all the low-level hardware details, it's quite heavily device-specific. The bootloader can be contained on a separate EEPROM (very seldom) or directly on flash storage (most common).

Being a piece of software, the bootloader is considered part of the firmware, but the bootloader is not part of OpenWrt! Only on seldom occasions a change of the bootloader settings or the bootloader code is necessary to allow for booting/installing OpenWrt There are a number of bootloaders under diverse licenses

The bootloader's main function is to initialize the hardware, pass an abstraction of the initialized hardware, a hardware description, to and execute the Kernel. (A very nice technical example can be seen here.) After that the bootloader is done and not needed in memory any longer. Most bootloaders offer additional functions.

It's not. The use of one or several bootloaders in a row to chainload (or bootstrap) a Kernel is not a categorical necessity, it is merely a very crafty method to start an OS. There are various reasons for this, but the main advantage for OpenWrt is, that the existence of a bootloader makes it less likely for users (or developers) to end up with a bricked device when things go bad, since the bootloader usually stays untouched and remains unaltered and this offers us possibilities to debrick a device.

Some bootloader or implementation of universal bootloaders come with certain limitation implemented by the manufacturer, such as:

• a willfully designed kernel/firmware size limitation
• make the bootloader expect a certain exotic firmware format
• inability of the bootloader to execute the ELF binary format
• the need of some obscure "magic value" to be present and correct
• you name it

The reasons are variable, from simple ineptitude of the creators to the willful sabotage of the users' attempts to run free software on their own property

The bootloader can be more or less sophisticated, and offer none to many additional functions. In many situations additional functions would give the user a huge advantage, so most bootloaders offer them, such as:

• The bootloader can possibly validate data on the flash-storage, and e.g. should the firmware fail to pass a CRC, the bootloader would presume the firmware is corrupt and wait for a new firmware to be uploaded over the network. Of course, this also means, that every time you change something on the flash, you have to update this CRC-value…
• this could also be triggered by setting a boot_wait variable or by a command executed in the serial console
• a CLI (aka serial console), which usually can only be accessed over the serial port only. There are several ways to access the serial console port on your target system, such as using a terminal server, but the most common way is to attach it to a serial port on your host. Additionally, you will need a terminal emulation program on your host system, such as cu or kermit.
  • once the bootloader fulfilled it's main function, chainload the Kernel, it does not run any longer, so to play with it, you have to login to it, before it loads the Kernel and you may also have to prevent it from loading the Kernel, i.e. to stop the boot process.
• USB mass storage booting
  • Like the Kernel needs a module like kmod-fs-ext4 to read from and write to a EXT3 filesystem, so a bootloader would need such a module to do the same. A "grown up" bootloader like GRUB2 has this functionality implemented, so with it, you can very comfortably configure your boot options and also update and maintain your OS. The lightweight bootloaders we use with OpenWrt, usually do not have this functionality. But see Flash Layout for further reference. One exception is the U-Boot implementation of the dockstar. It can not only initialize the USB (like all the rest of the hardware) but additionally utilize the USB and also understand the EXT2 filesystem. Thus, the dockstar can be booted directly from an ext2-formated harddisc/usb-stick connected to any of it's USB-ports.
• net booting functionality via
  • BOOTP or PXE or DHCP or NFS or TFTP
  • a TFTP client ⇒ most implementations have merely an integrated TFTP client which is
    • activated by default and try to connect to an TFTP server on every bootup, if one is found, firmware is loaded and executed from it
    • deactivated by default; you can activate it through it's CLI or maybe also from a booted OpenWrt
    • semi-activated: the bootloader usually does some CRC-checking of the content of the flash, if this fails, the modem will NOT boot (chainload) the system, but activate the TFTP client (on every bootup the CRC-check fails)
  • a TFTP server ⇒ some implementations incorporate a TFTP server instead of a TFTP client
    • what to do with it?
  • a FTP server ⇒ some implementations incorporate a FTP server
    • what to do with it?

netboot is not the same as extroot over NFS, because when you netboot, everything but the bootloader is loaded from a different location than your flash storage chip on the PCB. As a developer/tester you definitely want to use this.

→ boot process should give a more detailed description of whole boot procedure. The bootloader is the beginning.

Comparison of boot loaders

An embedded bootloader fulfills the same functionality as the BIOS plus GNU GRUB together on a PC.

• BIOS proprietary the BIOS of your PC is nothing else but a bootloader!
• UEFI proprietary successor of the BIOS
• coreboot GPLv2 successor of the BIOS, alternative to UEFI based on the Linux Kernel
• GNU GRUB GPLv2

• Das U-Boot GPLv2 arguably the richest, most flexible, and most actively developed FOSS bootloader available

• RedBoot mod GPL
• CFE BSD like the orange color means, the OEM is not obliged to deliver the source code
• Adam2 proprietary for AR7/UR8
  • PSPBoot proprietary the only slightly compatible successor of Adam2.
• brnboot unknown sometimes called AMAZON Loader.
• yamon unknown Yamon. The Kernel can only be booted when it is in SREC format.
• Bootbase unknown used by the ZyXEL Prestige 660HW-xx and Prestige 660M-xx devices (and probably other ZyXEL products). http://www.ixo.de/info/zyxel_uclinux/
• MyLoader unknown
• PP_Boot unknown

• VxWorks' own bootloader - most Atheros devices (There is a description of the basic workings on the Netgear WGT624 page.)
• NetBoot - the standard loader in DWL7100AP allows to boot firmware image via network from TFTP server direct to RAM
• ThreadX - D-Link uses OS called ThreadX on lowend 1MiB Flash storage & 8MiB RAM models. They have custom boot loader that doesn't output anything sensible to serial port but does have recovery mode so you can upload firmware using browser.

• Adam2
• brnboot
• CFE
• kboot
• MyLoader
• PP Boot
• PSPBoot
• RedBoot
• Das U-Boot Environment
• Das U-Boot