EFI variable support for U-Boot

Rob Clark has an RFC patch to U-Boot, with UEFI variable support:

[RFC] efi: variable support

Mapping from EFI variables to grub variables. Still almost as many TODOs as lines of code, but just figured I’d send out an early version for comments. I was thinking of it as a useful way for u-boot to pass values to grub (although grub is still missing a way for grub scripts to retrieve UEFI variables). The rough idea is to encode GUID + variable name plus “efi_” prefix (to avoid unintended u-boot variables leaking into the UEFI world). And then encode the type (and attributes?) in the string value of the variable. Ie. something like:

setenv efi_8be4df6193ca11d2aa0d00e098032b8c_OsIndicationsSupported (u64)0

Full patch/thread:



Hacking the Virgin Media Super Hub

By Jan Mitchell and Andy Monaghan, 12 June 2017
Context’s Research team have looked at a large number of off-the-shelf home routers in the past and found them to be almost universally dreadful in terms of security posture. However, flagship routers from large ISPs such as BT, Sky and Virgin Media are notably absent from the regular stream of router vulnerabilities in the press. We were curious to discover if these routers were significantly more secure than their off-the-shelf cousins, so we decided to dedicate some of our public research time into looking at one of these devices. […]
The output in Figure 1 suggested that U-Boot is executing a boot script, which was definitely something we wanted to investigate. The first step was to obtain a copy of the bootloader by reading the Flash memory. Given we didn’t have the ability to input characters this would be somewhat tricky via software, so we fired up the hot air gun and removed the Spansion (S25FL129P) NAND flash chip. There are a number of ways to read data from a flash chip, all of which we will be detailing in another blog shortly. In our case, as our preferred I2C/Serial Peripheral Interface (SPI) reader was in another office we used a BeagleBone Black and a bit of Python to manually drive the chip’s SPI bus[…]




Microsoft seeks U-Boot Linux firmware Engineer

Senior Software Engineer, Linux Firmware – CSI / Azure – Cloud Server Infrastructure
The Cloud Server Infrastructure Firmware Development (CSI-FW) team is responsible for server hardware definition, design and development of Server and Rack Infrastructure engineering for Microsoft’s online services. […] This role will be for a highly-motivated Firmware Engineer with a solid background in embedded system design using embedded Linux. […] Required Qualifications:
* Extensive knowledge of u-boot customization, Linux kernel internals and adding new hardware drivers




U-Boot gets NVMe support

Zhikang Zhang of NXP added NVMe driver support to U-Boot.

Add Support of devices that follow the NVM Express standard

 Basic functions:
    nvme init/scan
    nvme info – show the basic information of device
    nvme Read/Write

 Driver model:
    Use block device(CONFIG_BLK)’s structure to support nvme’s DM.
    Use UCLASS_PCI as a parent uclass.

The driver code heavily copy from the NVMe driver code in Linux Kernel.

Add nvme commands in U-Boot command line.

1. “nvme list” – show all available NVMe blk devices
2. “nvme info” – show current or a specific NVMe blk device
3. “nvme device” – show or set current device
4. “nvme part” – print partition table
5. “nvme read” – read data from NVMe blk device
6. “nvme write” – write data to NVMe blk device

More info: U-Boot mailing list.


Companies actively contributing to U-Boot

Here are some statistics on the U-Boot project, from a U-Boot list posting by Wolfgang Denk of DENX Software Engineering. The Full List is at the below URL. The subset list below are just the top contributing companies. The posting by Wolfgang also shows the top individuals.

Processed 664 csets from 126 developers
26 employers found
A total of 41330 lines added, 31385 removed (delta 9945)

Top changeset contributors by employer
(Unknown)                  170 (25.6%)
Socionext Inc.             105 (15.8%)
Google, Inc.                88 (13.3%)
NXP                         80 (12.0%)
Konsulko Group              42 (6.3%)
Texas Instruments           28 (4.2%)
Samsung                     26 (3.9%)
Xilinx                      26 (3.9%)
ARM                         20 (3.0%)
DENX Software Engineering   14 (2.1%)

Top lines changed by employer
Konsulko Group            21331 (35.5%)
(Unknown)                 8685 (14.4%)
Socionext Inc.            8227 (13.7%)
NXP                       8112 (13.5%)
Google, Inc.              5308 (8.8%)
DENX Software Engineering 1904 (3.2%)
ST Microelectronics       1801 (3.0%)
Openedev                  1105 (1.8%)
Samsung                    866 (1.4%)
CompuLab                   844 (1.4%)

Employers with the most signoffs (total 111)
NXP                         28 (25.2%)
Xilinx                      16 (14.4%)
DENX Software Engineering   15 (13.5%)
Samsung                     13 (11.7%)
(Unknown)                    9 (8.1%)
Google, Inc.                 9 (8.1%)
Collabora Ltd.               6 (5.4%)
ARM                          5 (4.5%)
Intel                        4 (3.6%)
Socionext Inc.               3 (2.7%)

Employers with the most hackers (total 128)
(Unknown)                   65 (50.8%)
NXP                         17 (13.3%)
Texas Instruments            7 (5.5%)
Xilinx                       4 (3.1%)
DENX Software Engineering    4 (3.1%)
Google, Inc.                 3 (2.3%)
Intel                        3 (2.3%)
Socionext Inc.               3 (2.3%)
Samsung                      2 (1.6%)
Collabora Ltd.               2 (1.6%)

More info:



proposed driver model for U-Boot init

Simon Glass of Chromium posted an 16-part patch to the U-Boot list, adding a driver model to the U-Boot init sequence.

[PATCH 00/16] RFC: Board init using driver model

At present we have a lot of ad-hoc init functions related to boards, for example board_early_init_f(), board_misc_init_f() and dram_init(). There are used in different ways by different boards as useful hooks to do the required init and sequence it correctly. Some functions are always enabled but have a __weak default. Some are controlled by the existence of a CONFIG. There are two main init sequences: board_init_f() (f for running from read-only flash) which runs before relocation and board_init_r() (r for relocated) which runs afterwards. One problem with the current sequence is that it has a lot of arch-specific #ifdefs around various functions. There are also #ifdefs for various features. There has been quite a bit of discussion about how to tidy this up and at least one RFC series[1].

Now that we have driver model we can use this to deal with the init sequences. This approach has several advantages:
– We have a path to remove the #ifdefs
– It is easy for multiple parts of the code to implement the same hook
– We can track what is called and what is not
– We don’t need weak functions
– We can eventually adjust the sequence to improve naming or to add new init phases
– It provides a model for how we might deal with ft_board_setup() and friends

This series starts the process of replacing the pre-relocation init sequence with a driver-model solution. It defines a uclass, adds tests and converts sandbox and a few x86 boards over to use this new setup. This series is not ready for use yet as the rest of the init sequence hooks need to be converted. But there is enough here to show the idea.

Comments welcome.

[1] https://lists.denx.de/pipermail/u-boot/2011-August/098718.html

37 files changed, 980 insertions(+), 45 deletions(-)
create mode 100644 doc/driver-model/board-info.txt

More information: