FOSS Project Spotlight: LinuxBoot

David Hendricks — Thu, 15 Feb 2018 15:12:50 +0000

Linux as firmware.

The more things change, the more they stay the same. That may sound cliché, but it's still as true for the firmware that boots your operating system as it was in 2001 when Linux Journal first published Eric Biederman's "About LinuxBIOS". LinuxBoot is the latest incarnation of an idea that has persisted for around two decades now: use Linux as your bootstrap.

On most systems, firmware exists to put the hardware in a state where an operating system can take over. In some cases, the firmware and OS are closely intertwined and may even be the same binary; however, Linux-based systems generally have a firmware component that initializes hardware before loading the Linux kernel itself. This may include initialization of DRAM, storage and networking interfaces, as well as performing security-related functions prior to starting Linux. To provide some perspective, this pre-Linux setup could be done in 100 or so instructions in 1999; now it's more than a billion.

Oftentimes it's suggested that Linux itself should be placed at the boot vector. That was the first attempt at LinuxBIOS on x86, and it looked something like this:


#define LINUX_ADDR 0xfff00000; /* offset in memory-mapped NOR flash */
void linuxbios(void) {
       void(*linux)(void) = (void *)LINUX_ADDR;

       linux();  /* place this jump at reset vector (0xfffffff0) */
}

This didn't get very far though. Linux was not at the point where it could fully bootstrap itself—for example, it lacked functionality to initialize DRAM. So LinuxBIOS, later renamed coreboot, implemented the minimum hardware initialization functionality needed to start a kernel.

Today Linux is much more mature and can initialize much more—although not everything—on its own. A large part of this has to do with the need to integrate system and power management features, such as sleep states and CPU/device hotplug support, into the kernel for optimal performance and power-saving. Virtualization also has led to improvements in Linux's ability to boot itself.

Firmware Boot and Runtime Components

Modern firmware generally consists of two main parts: hardware initialization (early stages) and OS loading (late stages). These parts may be divided further depending on the implementation, but the overall flow is similar across boot firmware. The late stages have gained many capabilities over the years and often have an environment with drivers, utilities, a shell, a graphical menu (sometimes with 3D animations) and much more. Runtime components may remain resident and active after firmware exits. Firmware, which used to fit in an 8 KiB ROM, now contains an OS used to boot another OS and doesn't always stop running after the OS boots.

Go to Full Article

Updating the Firmware of Linux-Based Devices

Viktar Palstsiuk — Wed, 24 Apr 2013 14:29:16 +0000

by Viktar Palstsiuk

This tutorial provides a general description of updating Linux-based firmware and illustrates it with some specific implementations. First, consider the sections of the memory system (Figure 1) and parts of memory that should be updated while transferring software to a new version.

Typically, a Linux-based system has the following structure of volatile memory. The first section is filled with a Linux kernel loader, which in turn can be executed in several stages. For example, a small-size bootloader is copied to the CPU internal memory, performs initialization of external memory and copies the second-level loader to the external RAM. The second-level loader (for example, U-Boot) copies the Linux kernel to RAM and hands over control to it. Finally, the system launches custom applications stored in the last section of the Flash memory. So obviously, it's necessary to update the memory sections with user applications and the OS kernel.

Figure 1. Sections of the Flash Memory of a Linux-Based Device

Events for starting the update process include:

System launch (in this case, the update application is built in to the bootloader or runs at the OS initialization).
Connection of external media (USB or SD card) during the operation.
Detection of a newer version of the software on the update server.
User operations.

You can copy update files though plug media or receive them over the network (in case the system is fitted with an Ethernet port or a Wi-Fi module). Usually, this procedure uses the TFTP protocol widely supported by various loaders. If you perform the update process using a program in the OS, you can copy the necessary files from the server using the wget application or the libcurl library.

An important part of the update process is checking the version of the received files and their integrity. You can do this using such algorithms as MD5, CRC32 and so forth. I also advise checking the compatibility of the new firmware with the device (PCB revision).

Option 1: if you have ROM capacity sufficient for storing the old and new firmware (Figure 2), the system implements the option with the possibility of going back to the previous version of the software in case of upgrade process failure. Memory is overwritten using flash_eraseall (for erasing the memory) and nandwrite (for writing images to the NAND memory), which are included in the mtd-utils package.

When update files are received and checked, you can start the process of writing them to the system ROM. You can implement various software update options, depending on ROM capacity.

Go to Full Article