Hi, On 25 July 2016 at 18:58, Simon Glass <s...@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, 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.
I'm going to apply the clean-up parts of this series to u-boot-dm/next and then resend just the tool as a shorter series with some updates. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
