| Das U-Boot | |
|---|---|
 | |
| Developer | DENX Software Engineering |
| Initial release | October 15, 1999; 26 years ago (1999-10-15) |
| Stable release | 2026.01[1]  / 5 January 2026 |
| Written in | C,Assembly |
| Available in | English |
| Type | Boot loader |
| License | GPL-2.0-or-later[2] |
| Website | u-boot |
| Repository | |
Das U-Boot (subtitled "the Universal Boot Loader" and often shortened toU-Boot; seeHistory for more about the name) is anopen-sourceboot loader used inembedded devices to perform various low-level hardware initialization tasks and boot the device's operating system kernel. It is available for a number ofcomputer architectures, includingM68000,ARM,Blackfin,MicroBlaze,AArch64,MIPS,Nios II,SuperH,PPC,Power ISA,RISC-V,LoongArch andx86.
U-Boot is both a first-stage and second-stage bootloader. It is loaded by the system's ROM (e.g. on-chip ROM of an ARM CPU) from a supported boot device, such as an SD card, SATA drive, NOR flash (e.g. usingSPI orI²C), or NAND flash. If there are size constraints, U-Boot may be split into two stages: the platform would load a small SPL (Secondary Program Loader), which is a stripped-down version of U-Boot, and the SPL would do some initial hardware configuration (e.g.DRAM initialization using CPU cache as RAM) and load the larger, fully featured version of U-Boot.[3][4][5] Regardless of whether the SPL is used, U-Boot performs both first-stage (e.g., configuringmemory controller,SDRAM,mainboard and other I/O devices) and second-stage booting (e.g., loadingOS kernel and other related files from storage device).
U-Boot implements a subset of theUEFI specification as defined in the Embedded Base Boot Requirements (EBBR) specification.[6] UEFI binaries likeGRUB or theLinux kernel can be booted via the boot manager or from the command-line interface.
U-Boot runs acommand-line interface on a console or a serial port. Using the CLI, users can load and boot a kernel, possibly changing parameters from the default. There are also commands to read device information, read and write flash memory, download files (kernels, boot images, etc.) from the serial port or network, manipulatedevice trees, and work with environment variables (which can be written to persistent storage, and are used to control U-Boot behavior such as the default boot command and timeout before auto-booting, as well as hardware data such as the Ethernet MAC address).
Unlike PC bootloaders which obscure or automatically choose the memory locations of the kernel and other boot data, U-Boot requires its boot commands to explicitly specify the physical memory addresses as destinations for copying data (kernel, ramdisk, device tree, etc.) and for jumping to the kernel and as arguments for the kernel. Because U-Boot's commands are fairly low-level, it takes several steps to boot a kernel, but this also makes U-Boot more flexible than other bootloaders, since the same commands can be used for more general tasks. It's even possible to upgrade U-Boot using U-Boot, simply by reading the new bootloader from somewhere (local storage, or from the serial port or network) into memory, and writing that data to persistent storage where the bootloader belongs.
U-Boot has support for USB, so it can use a USB keyboard to operate the console (in addition to input from the serial port), and it can access and boot from USB Mass Storage devices such as SD card readers.
U-Boot boots an operating system by reading the kernel and any other required data (e.g. device tree, ramdisk image or boot image) into memory, and then executing the kernel with the appropriate arguments.
U-Boot's commands are actually generalized commands which can be used to read or write any arbitrary data. Using these commands, data can be read from or written to any storage system that U-Boot supports, which include:
(Note: These are boot sources from which U-Boot is capable of loading data (e.g. a kernel or ramdisk image) into memory. U-Boot itself must be booted by the platform, and that must be done from a device that the platform's ROM is capable of booting from, which naturally depends on the platform.)
On some embedded device implementations, the CPU or SoC will locate and load the bootloader (such as Das U-Boot) from the boot partition (such asext4 orFAT filesystems) directly.
U-Boot does not need to be able to read a filesystem for the kernel to use it as a root filesystem or initial ramdisk; U-Boot simply provides an appropriate parameter to the kernel, and/or copies the data to memory without understanding its contents.
However, U-Boot can also read from (and in some cases, write to) filesystems. This way, rather than requiring the data that U-Boot will load to be stored at a fixed location on the storage device, U-Boot can read the filesystem to search for and load the kernel, device tree, etc., by pathname.
U-Boot includes support for these filesystems:
Device tree is a data structure for describing hardware layout. Using Device tree, a vendor might be able to use a less modifiedmainline U-Boot on otherwise special purpose hardware. As also adopted by the Linux kernel, Device tree is intended to ameliorate the situation in theembedded industry, where a vast number of product specificforks (of U-Boot and Linux) exist. The ability to run mainline software practically gives customers indemnity against lack of vendor updates.
The project started as a 8xx PowerPC bootloader called8xxROM written by Magnus Damm.[7] In October 1999 Wolfgang Denk moved the project to SourceForge.net and renamed it toPPCBoot, because SF.net did not allow project names starting with digits.[7] Version 0.4.1 of PPCBoot was first publicly released 19 July 2000.
In 2002 a previous version of thesource code was brieflyforked into a product calledARMBoot, but was merged back into the PPCBoot project shortly thereafter. On 31 October 2002PPCBoot−2.0.0 was released. This marked the last release under the PPCBoot name, as it was renamed to reflect its ability to work on other architectures besides the PPC ISA.[8][9]
PPCBoot−2.0.0 becameU−Boot−0.1.0 in November 2002, expanded to work on thex86 processor architecture. Additional architecture capabilities were added in the following months:MIPS32 in March 2003,MIPS64 in April,Nios II in October,ColdFire in December, andMicroBlaze in April 2004. The May 2004 release of U-Boot-1.1.2 worked on the products of 216 board manufacturers across the various architectures.[9]
The current nameDas U-Boot adds aGerman definite article, to create a bilingualpun on the classic 1981 German submarine filmDas Boot, which takes place on a World War II GermanU-boat[citation needed]. It isfree software released under the terms of theGNU General Public License. It can be built on an x86 PC for any of its intended architectures using a cross development GNUtoolchain, for example crosstool, the Embedded Linux Development Kit (ELDK) or OSELAS.Toolchain.
The importance of U-Boot in embedded Linux systems is quite succinctly stated in the bookBuilding Embedded Linux Systems, by Karim Yaghmour, whose text about U-Boot begins, "Though there are quite a few other bootloaders, 'Das U-Boot', the universal bootloader, is arguably the richest, most flexible, and most actively developed open source bootloader available."[10]
In 2025, multiplevulnerabilities discovered in 2024 have been disclosed in U-Boot.[11] Abusing the filesystem support feature (ext4,SquashFS) of U-Boot by manually modifying filesystem data structures, an attacker can cause aninteger overflow, astack overflow or aheap overflow. As a result, an attacker can perform anarbitrary code execution and bypass the bootchain of trust. These issues are mitigated by the version v2025.01-rc1.
| Processes |  | ||||||
|---|---|---|---|---|---|---|---|
| Bootingfirmware |
| ||||||
| Hybrid firmware bootloader | |||||||
| Bootloaders |
| ||||||
| Partition layouts | |||||||
| Partitions | |||||||
| Utilities |
| ||||||
| Network boot | |||||||
| ROM variants | |||||||
| Related | |||||||
