Alexander on U-Boot+UEFI+GRUB on ARM

Here’s one interesting presentation for the upcoming OpenIoT and Embedded Linux Conference:

Marrying U-Boot, uEFI and grub2 – Alexander Graf, SUSE

Booting is hard. Booting in the ARM world is even harder. State of the art are a dozen different boot loaders that may or may not deserve that name. Each gets configured differently and each has its own pros and cons. As a distribution this is a nightmare. Configuring each and every one of them complicates code that really should be very simple. To solve the problem, we can just add another layer of abstraction (grub2) on top of another layer of abstraction (uEFI) on top of another layer of abstraction (u-boot). Follow me on a journey on how all those layers can make life easier for the distribution and how much fun uEFI really is. After this talk, you will know how ARM systems boot, what uEFI really means, how uEFI binaries interact with firmware and how this enables convergence of the Enterprise and Embedded markets.

Alexander Graf, KVM Wizard, SUSE
Alexander started working for SUSE about 8 years ago. Since then he worked on fancy things like SUSE Studio, QEMU, KVM and openSUSE on ARM. Whenever something really useful comes to his mind, he tends to implement it. Among others he did Mac OS X virtualization using KVM, nested SVM, KVM on PowerPC and a lot of work in QEMU for openSUSE on ARM. He is the upstream maintainer of KVM for PowerPC, QEMU for PowerPC and QEMU for S390x.





U-Boot gets improved testing

Tom Rini of Konsulko posted an 8-part patch to the U-Boot list, improving their CI infrastrucute. It is nice to see firmware projects with improved testing!

[PATCH 0/8] Various travis-ci improvements

The following series does a few things with our existing travis-ci infrastructure.  We update to the latest Ubuntu release that is supported (there are only 2 Linux host choices) and make use of toolchains that are available that way when possible and fix building of x86.  I added in microblaze and sh4 and xtensa to the build loop (I left out blackfin and openrisc as they have compile problems currently in general). The biggest change here is that I’ve added support for test.py running on qemu-x86, qemu-ppce500, qemu-mips*, vexpress_ca15_tc2, vexpress_ca9x4, and integratorcp_cm926ejs along with sandbox.

This final part is I think the most important.  With this change all it now takes to have some build coverage and some test.py coverage is a github account.  You can then login to travis-ci.org that, click a few things and get build and test coverage with minimal effort now.  It takes about 2 hours in its current configuration but could easily be cut down in ones personal repository for quicker test cycles.  And for the record, in addition to email notifications by default one will have https://api.travis-ci.org/repos/USERNAME/u-boot/builds.atom available as an atom feed, in addition to the numerous other notification methods available.



U-Boot ported to Intel64

Simon Glass of Chromium posted a *82-part* patch to the U-Boot list, with a port of U-Boot from 32-bit x86 to 64-bit x64 support. Quoting Simon’s initial message:

[PATCH 00/82] x86: Add initial support for 64-bit U-Boot

At present U-Boot runs entirely in 32-bit mode on x86, except for the initial switch from 16-bit mode. On 64-bit machines it is possible to run in 64-bit mode. This series starts the process of adding this support. The main benefit of 64-bit mode for a boot loader is direct access to all available memory. There are also more registers, but this makes very little difference. This feature is implemented by putting all of the 32-bit code in an SPL build. SPL then runs through all the init that has to be done in 32-bit mode, changes to 64-bit mode and then jumps to U-Boot proper. Typically the total code size increases slightly. For example, on link in 32-bit mode, U-Boot has around 480KB of code (admittedly with a large number of features enabled). In 64-bit mode, U-Boot falls to around 460KB, but SPL adds another 60KB, for a net increase of 40KB. Partly this is due to code duplication and partly it is due to the worse code density of 64-bit code on x86. Many major features are not implemented yet, for example:
  – SDRAM sizing
  – Booting linux
  – FSP support
  – EFI support
  – SCSI device init
  – Running video ROMs
Still, this is a big step forward towards full 64-bit support. To enable it, select CONFIG_X86_RUN_64BIT. This series is available at u-boot-x86/64-working.

91 files changed, 1796 insertions(+), 705 deletions(-)
See full description in the post:


U-Boot v2016.09 released

Tom Rini of Konsulko announced the latest release of U-Boot on the u-boot list @lists.denx.de.

– More DM work (MMC, of-platdata for size constrained instances, etc)
– Lots and lots of architecture / SoC / Platform updates: x86, rockchip,
  sunxi, TI, NXP/FSL, Tegra, Zynq, uniphier
– mkimage cleanups
– More test.py updates, vboot now a testcase
– Secure boot work on both ARM and PowerPC.
– PSCI updates
– MAKEALL is gone, buildman is for use by all
– We now have xtensa support
– DT overlays
– More Kconfig migration
– Some NFS fixes

Read the full announcement if you’re able to help U-Boot with testing, they’re looking for some help with their new automated test framework.


U-Boot v2016.09-rc2 released

Tom Rini of Konsulko announced the v2016.09-rc2 release of U-Boot. Excerpting most of his announcement:

It’s release day and v2016.09-rc2 is out now.  […]

A short list of changes to come in now are:
– More and various SoC and architecture updates
– Various DM updates and conversions
– PSCI updates
– MAKEALL is gone, buildman is for use by all
– We now have xtensa support
– DT overlays

A non-code change is that now I have Jenkins setup to automatically poll my WIP branches and run test/py/test.py on a few real boards along with sandbox.  I still have some more configuring and cabling to do, and a few more boards I can get setup.

For more info, see the announcement on the u-boot mailing list.


U-Boot v2016.09-rc1 released

Tom Rini of Konsulko announced the v2016.09-rc1 release of U-Boot, his announcement to the U-Boot list is excerpted below:

It’s release day and v2016.09-rc1 is out and the merge window is closed. I’ve updated git and the tarballs are also up now.  I’ve made an attempt at keeping track of what updated as things went along this time:
– DM / MMC block device clean up, patman improvements
– DM now supports of-platdata for cases where we are very much size constrained.
– Various SPI fixes / improvements
– Arch / SoC / Platform updates: x86, rockchip, sunxi, TI, NXP/FSL, Tegra, Zynq, uniphier
– First round of updates to the PSCI code to make it easier to use.
– mkimage cleanups
– More test.py updates, vboot now a testcase
– Secure boot on MPC85xx.

And of course, other things as well.  Please feel free to chime in if there’s something important I forgot to call out. If you notice any problems with the release, please speak out and thanks all!


binman: new U-Boot firmware image creation tool

Simon Glass of Chromium submitted “binman”, a new firmware image creation tool, to the U-Boot project. Below is the intro from Simon’s patch 0/30:

binman: A tool for creating firmware images

This series introduces binman, a tool designed to create firmware images. It provides a way to bring together various binaries and place them in an image, at particular positions and with configurable alignment.

Packaging of firmware is quite a different task from building the various parts. In many cases the various binaries which go into the image come from separate build systems. For example, ARM Trusted Firmware is used on ARMv8 devices but is not built in the U-Boot tree. If a Linux kernel is included in the firmware image, it is built elsewhere.

It is of course possible to add more and more build rules to the U-Boot build system to cover these cases. It can shell out to other Makefiles and build scripts. But it seems better to create a clear divide between building software and packaging it.

U-Boot supports a very large number of boards. Many of these have their own specific rules for how an image should be put together so that it boots correctly. At present these rules are described by manual instructions, different for each board. By turning these instructions into a standard format, we can support making valid images for any board without manual effort, lots of READMEs, etc.

Images consist of a number of entries which are combined to make up the final image. The image is described in the device tree for the board, meaning that it can be accessed at run-time if desired.

Binman is an extensible tool. A set of standard entries is provides, but new entries can be created fairly easily. Entries can be as simple as providing the name of a file to include. They can also handle more complex requirements, such as adjusting the input file or reading header information from one entry to control the position of another.

U-Boot’s mkimage builds FIT images and various other binaries. Binman augments this by allowing these binaries to be packed together. While FIT should be used where possible, it cannot be used everywhere. For example, many devices require executable code at a particular offset in the image. X86 machines require lots of binary blobs at particular places, and a microcode collection easily accessible at boot.

So far binman has enough functionality to be useful, but apart from a few RFC patches, no attempt is made to switch boards over to use it. There should be enough material to permit review and comments.

The series is available at u-boot-dm/binman-working

Future work and missing features are documented in the README.

For more info, see the patch on the U-Boot list: