u-boot.git/tools/binman/test, branch v2022.10-rc2

spl: binman: Check at runtime if binman symbols were filled in

2022-06-28T02:09:52Z

Binman lets us declare symbols in SPL/TPL that refer to other entries in the same binman image as them. These symbols are filled in with the correct values while binman assembles the images, but this is done in-memory only. Symbols marked as optional can be filled with BINMAN_SYM_MISSING as an error value if their referred entry is missing. However, the unmodified SPL/TPL binaries are still available on disk, and can be used by people. For these files, nothing ensures that the symbols are set to this error value, and they will be considered valid when they are not. Empirically, all symbols show up as zero in a sandbox_vpl build when we run e.g. tpl/u-boot-tpl directly. On the other hand, zero is a perfectly fine value for a binman-written symbol, so we cannot say the symbols have wrong values based on that. Declare a magic symbol that binman always fills in with a fixed value. Check this value as an indicator that symbols were filled in correctly. Return the error value for all symbols when this magic symbol has the wrong value. For binman tests, we need to make room for the new symbol in the mocked SPL/TPL data by extending them by four bytes. This messes up some test image layouts. Fix the affected values, and check the magic symbol wherever it makes sense. Signed-off-by: Alper Nebi Yasak

spl: binman: Split binman symbols support from enabling binman

2022-06-28T02:09:52Z

Enabling CONFIG_BINMAN makes binman run after a build to package any images specified in the device-tree. It also enables a mechanism for SPL/TPL to declare and use special linker symbols that refer to other entries in the same binman image. A similar feature that gets this info from the device-tree exists for U-Boot proper, but it is gated behind a CONFIG_BINMAN_FDT unlike the symbols. Confusingly, CONFIG_SPL/TPL_BINMAN_SYMBOLS also exist. These configs don't actually enable/disable the symbols mechanism as one would expect, but declare some symbols for U-Boot using this mechanism. Reuse the BINMAN_SYMBOLS configs to make them toggle the symbols mechanism, and declare symbols for the U-Boot phases in a dependent BINMAN_UBOOT_SYMBOLS config. Extend it to cover symbols of all phases. Update the config prompt and help message to make it clearer about this. Fix binman test binaries to work with CONFIG_IS_ENABLED(BINMAN_SYMBOLS). Co-developed-by: Peng Fan [Alper: New config for phase symbols, update Kconfigs, commit message] Signed-off-by: Alper Nebi Yasak

binman: Refuse to replace sections for now

2022-04-25T14:11:05Z

Binman interfaces allow attempts to replace any entry in the image with arbitrary data. When trying to replace sections, the changes in the section entry's data are not propagated to its child entries. This, combined with how sections rebuild their contents from its children, eventually causes the replaced contents to be silently overwritten by rebuilt contents equivalent to the original data. Add a simple test for replacing a section that is currently failing due to this behaviour, and mark it as an expected failure. Also, raise an error when replacing a section instead of silently pretending it was replaced. Signed-off-by: Alper Nebi Yasak Reviewed-by: Simon Glass

binman: Create FIT subentries in the FIT section, not its parent

2022-04-25T14:11:05Z

When reading images from a file, each entry's data is read from its parent section as specified in the Entry.Create() call that created it. The FIT entry type has been creating its subentries under its parent (their grandparent), as creating them under the FIT entry resulted in an error until FIT was converted into a proper section. FIT subentries have their offsets relative to the FIT section, and reading those offsets in the parent section results in wrong data. The subentries rightfully belong under the FIT entries, so create them there. Add tests checking that we can extract the correct data for a FIT entry and its subentries. Signed-off-by: Alper Nebi Yasak Reviewed-by: Simon Glass

binman: Collect bintools for images when replacing entries

2022-04-25T14:11:05Z

Binman entries can use other executables to compute their data, usually in their ObtainContents() methods. Subclasses of Entry_section would use bintools in their BuildSectionData() method instead, which is called from several places including their Pack(). These binary tools are resolved correctly while building an image from a device-tree description so that they can be used from these methods. However, this is not being done when replacing entries in an image, which can result in an error as the Pack() methods attempt to use them. Collect and resolve entries' bintools also when replacing entries to fix Pack() errors. Add a way to mock bintool usage in the testing entry type and tests that check bintools are being resolved for such an entry. Signed-off-by: Alper Nebi Yasak Reviewed-by: Simon Glass

binman: Fix unique names having '/.' for images read from files

2022-04-25T14:10:41Z

Binman can embed a copy of the image description into the images it builds as a fdtmap entry, but it omits the /binman/ prefix from the node paths while doing so. When reading an already-built image file, entries are reconstructed using this fdtmap and their associated nodes still lack that prefix. Some entries like fit and vblock create intermediate files whose names are based on an entry unique name. This name is constructed from their node's path by concatenating the parents with dots up to the binman node, e.g. /binman/image/foo/bar becomes 'image.foo.bar'. However, we don't have this /binman/image prefix when replacing entries in such an image. The /foo/bar entry we read when doing so erroneously has the unique name of '/.foo.bar', causing permission errors when the entry attempts to create files based on that. Fix the unique-name generation by stopping at the '/' node like how it stops at the binman node. As the unique names are used as filenames, add tests that check if they're safe to use as filenames. Signed-off-by: Alper Nebi Yasak Reviewed-by: Simon Glass

tools: binman: add support for pre-load header

2022-03-31T18:12:23Z

Adds the support of the pre-load header with the image signature to binman. Reviewed-by: Simon Glass Signed-off-by: Philippe Reynes

binman: Support splitting an ELF file into multiple nodes

2022-03-19T01:24:25Z

Some boards need to load an ELF file using the 'loadables' property, but the file has segments at different memory addresses. This means that it cannot be supplied as a flat binary. Allow generating a separate node in the FIT for each segment in the ELF, with a different load address for each. Also add checks that the fit,xxx directives are valid. Signed-off-by: Simon Glass Acked-by: Alper Nebi Yasak

binman: Allow mkimage to use a non-zero fake-blob size

2022-03-19T01:24:25Z

Unfortunately mkimage gets upset with zero-sized files. Update the ObtainContents() method to support specifying the size, if a fake blob is created. Signed-off-by: Simon Glass Reviewed-by: Alper Nebi Yasak

binman: Refactor fit to generate output at the end

2022-03-19T01:24:25Z

At present the fit implementation creates the output tree while scanning the FIT description. Then it updates the tree later when the data is known. This works, but is a bit confusing, since it requires mixing the scanning code with the generation code, with a fix-up step at the end. It is actually possible to do this in two phases, one to scan everything and the other to generate the FIT. Thus the FIT is generated in one pass, when everything is known. Update the code accordingly. The only functional change is that the 'data' property for each node are now last instead of first, which is really a more natural position. Update the affected test to deal with this. One wrinkle is that the calculated properties (image-pos, size and offset) are now added before the FIT is generated. so we must filter these out when copying properties from the binman description to the FIT. Most of the change here is splitting out some of the code from the ReadEntries() implementation into _BuildInput(). So despite the large diff, most of the code is the same. It is not feasible to split this patch up, so far as I can tell. Signed-off-by: Simon Glass Reviewed-by: Alper Nebi Yasak