Das U-Boot supports a wide range of ARM, PPC and x86 options, with rich documentation and the capability of both reading and writing the media.

It is important to note that this software is licensed under the terms of GPLv2, which requires full source code for “derived works” to be available to recipients of a compiled version. “Derived work” is generally understood to mean a single statically-linked executable, which is what U-boot is. On Linux, U-Boot supports a number of file systems, including ext2, 3, and 4, FAT, Squashfs, ZFS, and btrfs. It also includes the flash file systems JFFS2 and UBIFS – more on that later.

U-Boot on embedded Linux

As useful as U-Boot is for embedded designs, there are a couple of challenges that need to be addressed. The supported file systems in U-Boot are also supported by the standard Linux kernel, which means kernel files can be read from those same file systems, giving some flexibility for runtime updates. Before U-Boot, kernel images were typically read from sequential blocks on the media and usually weren’t stored within a file system at all. To update an image during runtime the entire update had to be written at once, with no protection for power interruption, which left system vulnerable to being “bricked” during an update.

Many system designers looking for a power fail-safe way to manage data often turn to the our file system, Reliance Nitro. But isn’t this a proprietary solution that uses a license that is not compatible with GPL? Yes, that is true for the full version of Reliance Nitro, however Tuxera provides a Reliance Nitro reader under a GPLv2-compatible license which can be used in the U-Boot bootloader. This solution can read files from a Reliance Nitro-formatted partition, even though the file system kernel objects are not yet loaded. Using Reliance Nitro, these kernel files could then be updated at runtime with confidence that random power loss won’t cause corruption.

An additional challenge exists for designs using raw flash media storage: a driver is required to read the NAND or NOR flash. On Linux, that driver typically is the Memory Technology Device (MTD). Versions of two flash file systems (JFFS2 and UBIFS) are provided in U-Boot for this environment. Provided that these choices meet your needs, you could be all set. However, all of the features of modern flash devices may not be supported or optimized in these solutions.

Can a developer just use one of the basic flash file systems to boot and then hand off to a more robust solution for normal operation? Unfortunately, not. The media manager portion of those flash file systems cannot handoff control to another media manager. If MTD is utilized to read the NAND for the bootloader, its use will also be required to control the NAND during normal operation. Fortunately, our proprietary flash management software, FlashFX Tera, because we provide a compatible flash information module (FIM) for MTD.

For non-Linux environments

Das U-Boot has also been widely adopted outside of Linux, in environments such as Wind River’s VxWorks and smaller kernel solutions such as FreeRTOS. Of the file systems built into U-Boot, only the unreliable FAT is supported by these operating systems – however, there are simple ways to add power failsafe reliability and cross-platform support even to these operating systems.

Tuxera’s file system solution for small environments is Reliance Edge. As this software can be licensed GPL v2, we have ported it to the U-Boot environment, allowing a system to use U-Boot to bring up an operating system image or kernel image stored on a Reliance Edge file system volume. Like the Linux environment, this means that image can be updated during runtime with confidence that the transaction points of Reliance Edge provide protection against power loss or other interruption.

Reliance Edge will work with any media solution that U-Boot can use, including the commonly available SD and eMMC media. What is not provided in many of these environments is a raw NAND media driver – the equivalent of MTD.

Until a better solution is available, the best option is to boot from media that is readable by U-Boot in those environments – SPI NOR flash or SD media. After the system boot is complete, a NAND driver (such as FlashFX Tera) can be loaded to directly access the NAND media for storage.

Have more questions?

If you have more questions on this topic, I’ll be happy to answer them for you. Just drop us a line through our contact form→ and we’ll get back with you as soon as possible.