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:


U-Boot updates from ELC2017

As pointed out by the Phoronix article, Embedded Linux Conference had a few talks on U-Boot:





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: