User Tools

Site Tools

This wiki is read only and for archival purposes only. >>>>>>>>>> Please use the new OpenWrt wiki at <<<<<<<<<<


This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
doc:techref:bootloader [2013/07/03 19:39]
doc:techref:bootloader [2017/10/28 05:47] (current)
RAThomas [Additional Functions]
Line 1: Line 1:
 +====== The Bootloader ======
 +The [[wp>​Bootloader]] is a piece of software that is executed every time the hardware device is powered up. It is executable machine code and thus [[doc/​hardware/​cpu#​the.isa.instruction.set.architecture|ARCH]]-specific. It's quite heavily device-specific because its main task is to initialize all the low-level hardware details. The bootloader can be contained on a separate [[wp>​EEPROM]] (very seldom) or directly on flash storage (most common).
 +<WRAP round tip>
 +Being a piece of software, the bootloader is considered part of the firmware, but <color red>​**the bootloader is not part of OpenWrt!**</​color>​\\ 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 [[wp>​software license]]s
 +===== Main Function =====
 +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 [[http://​​fritzbox/​index.php/​ADAM2#​Funktionen|here]].) After that the bootloader is done and not needed in memory any longer. Most bootloaders offer [[#​additional functions]].
 +==== Why this is necessary? ====
 +It's not. A bootloader is not required to boot Linux. The use of one (or several) bootloaders in a row to chainload (or [[wp>​Bootstrapping (computing)|bootstrap]]) a Kernel is not a categorical necessity, it is merely a very crafty method to start an operating system. The main advantage for OpenWrt is, that the existence of a bootloader offers users and developers additional possibilities to [[doc:​howto:​generic.debrick|debrick]] a device.
 +===== Features =====
 +==== Limitations ====
 +Some bootloader or implementation of universal bootloaders come with certain limitation implemented by the OEM, 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 [[wp>​Executable and Linkable Format|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 [[wp>​free software]] on their own property.
 +==== Additional Functions ====
 +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:
 +  * Flash new firmware, see [[doc:​howto:​generic.flashing]]
 +  * 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 [[wp>​Command-line interface|CLI]] (aka //serial console//), which usually can be accessed over the [[doc:​hardware:​port.serial|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 has fulfilled its 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.
 +  * boot from USB
 +    * Like the Kernel requires the module ''​kmod-fs-ext4''​ to read/write to a EXT3 filesystem, so a bootloader requires such a module to do the same. [[wp>​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 [[doc:​techref:​flash.layout]] for further reference. One exception is the U-Boot implementation of the [[toh:​seagate:​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.
 +  * [[inbox:​howto:​netboot|net booting]] functionality via [[wp>​Bootstrap Protocol|BOOTP]] or [[wp>​Preboot Execution Environment|PXE]] or DHCP or NFS or [[wp>​Trivial File Transfer Protocol|TFTP]]
 +===== Boot Procedure =====
 +-> **[[process.boot|boot process]]** should give a more detailed description of whole boot procedure. The bootloader is the beginning.
 +===== Individual Bootloaders =====
 +[[wp>​Comparison of boot loaders]]
 +| //Please use ''​[[meta:​templates]]''​ to create and maintain these articles. ATM they are quite unmaintained and without a structure and almost useless// |
 +==== PC ====
 +An embedded bootloader fulfills the same functionality as the [[wp>​BIOS]] plus [[wp>GNU GRUB]] together on a PC.
 +  * [[wp>​BIOS]] <color red>​proprietary</​color>​ the BIOS of your PC //is// nothing else but a bootloader!
 +  * [[wp>​Extensible Firmware Interface|UEFI]] <color red>​proprietary</​color>​ successor want-to-be of the BIOS
 +  * [[wp>​coreboot]] <color green>​GPLv2</​color>​ successor of the BIOS, alternative to UEFI based on the Linux kernel;\\ support for x86, x86-64 and ARM. There is no MIPS support.\\ Coreboot does only "a little bit of hardware initialization"​
 +  * [[wp>GNU GRUB]] <color green>​GPLv2</​color> ​
 +==== Embedded Devices ====
 +  * **[[doc:​techref:​bootloader:​uboot|Das U-Boot]]** <color green>​GPLv2</​color>​ arguably the richest, most flexible, and most actively developed FOSS bootloader available
 +  * [[doc:​techref:​bootloader:​redboot|RedBoot]] <color green>​mod GPL</​color>​
 +  * [[doc:​techref:​bootloader:​cfe|CFE]] <color orange>​BSD like</​color>​ by Broadcom; the orange color means, the OEM is not obliged to deliver the source code
 +  * [[doc:​techref:​bootloader:​adam2|Adam2]] <color red>​proprietary</​color>​ for AR7/UR8
 +    * [[doc:​techref:​bootloader:​PSPBoot]] <color red>​proprietary</​color>​ the only slightly compatible successor of Adam2.
 +  * [[doc:​techref:​bootloader:​brnboot]] <color red>​unknown</​color>​ sometimes called AMAZON Loader.
 +  * [[doc:​techref:​bootloader:​yamon]] <color red>​unknown</​color>​ by [[wp>​Imagination Technology]];​ the Linux kernel can only be booted when it is in SREC format.
 +  * [[doc:​techref:​bootloader:​Bootbase]] <color red>​unknown</​color>​ used by the ZyXEL Prestige 660HW-xx and Prestige 660M-xx devices (and probably other ZyXEL products). [[http://​​info/​zyxel_uclinux/​]]
 +  * [[doc:​techref:​bootloader:​JBOOT]] <color red>​unknown</​color> ​
 +  * [[doc:​techref:​bootloader:​MyLoader]] <color red>​unknown</​color> ​
 +  * [[doc:​techref:​bootloader:​PP_Boot]] <color red>​unknown</​color> ​
 +  * VxWorks'​ own bootloader - most Atheros devices (There is a description of the basic workings on the [[oldwiki:​OpenWrtDocs:​Hardware:​Netgear:​WGT624|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.
 +===== Bootloader Pages =====