Hi Bin,
On 25 November 2016 at 20:15, Simon Glass sjg@chromium.org wrote:
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, so sunxi and x86 boards are switched over to use it, as examples.
The series is available at u-boot-dm/binman-working
Future work and missing features are documented in the README.
Changes in v6:
- Deal with optional microcode in SPL
- Drop unwanted root-node properties from tegra20-u-boot.dtsi
- Use __import__() when importlib is not available
Does this work OK for you now?
[...]
Regards, Simon