- 26 Mar, 2021 1 commit
-
-
Simon Glass authored
A few tests declare a type when this can be inferred from the node name. Drop these lines, since it might cause confusion. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
- 11 Nov, 2019 1 commit
-
-
A recent change adjusted the symbol calculation to work on x86 but broke it for Tegra. In fact this is because they have different needs. On x86 devices the code is linked to a ROM address and the end-at-4gb property is used for the image. In this case there is no need to add the base address of the image, since the base address is already built into the offset and image-pos properties. On other devices we must add the base address since the offsets start at zero. In addition the base address is currently added to the 'offset' and 'size' values. It should in fact only be added to 'image-pos', since 'offset' is relative to its parent and 'size' is not actually an address. This code should have been adjusted when support for 'image-pos' and 'size' was added, but it was not. To correct these problems: - move the code that handles adding the base address to section.py, which can check the end-at-4gb property and which property (offset/size/image-pos) is being read - add the base address only when needed (only for image-pos and not if the image uses end-at-4gb) - add a note to the documentation - add a separate test to cover x86 behaviour Fixes: 15c981cc (binman: Correct symbol calculation with non-zero image base) Signed-off-by:
Simon Glass <sjg@chromium.org> Tested-by:
Stephen Warren <swarren@nvidia.com>
-
- 15 Oct, 2019 2 commits
-
-
Simon Glass authored
At present these are large enough to hold 20 bytes of symbol data. Add four more bytes so we can add another test. Unfortunately at present this involves changing a few test files to make room. We could adjust the test files to not specify sizes for entries. Then we could make the tests check the actual sizes. But for now, leave it as it is, since the effort is minor. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
At present we only support symbols inside binaries which are at the top level of an image. This restrictions seems unreasonable since more complex images may want to group binaries within different sections. Relax the restriction, adding a new _SetupTplElf() helper function. Also fix a typo in the comment for testTpl(). Signed-off-by:
Simon Glass <sjg@chromium.org>
-
- 09 Oct, 2018 1 commit
-
-
Simon Glass authored
We now have 99 tests. Before adding any more, rename everything to three digits. This helps to preserve the ordering of tests and makes it easier to find things. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
- 01 Aug, 2018 1 commit
-
-
Simon Glass authored
After some thought, I believe there is an unfortunate naming flaw in binman. Entries have a position and size, but now that we support hierarchical sections it is unclear whether a position should be an absolute position within the image, or a relative position within its parent section. At present 'position' actually means the relative position. This indicates a need for an 'image position' for code that wants to find the location of an entry without having to do calculations back through parents to discover this image position. A better name for the current 'position' or 'pos' is 'offset'. It is not always an absolute position, but it is always an offset from its parent offset. It is unfortunate to rename this concept now, 18 months after binman was introduced. However I believe it is the right thing to do. The impact is mostly limited to binman itself and a few changes to in-tree users to binman: tegra sunxi x86 The change makes old binman definitions (e.g. downstream or out-of-tree) incompatible if they use the 'pos = <...>' property. Later work will adjust binman to generate an error when it is used. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
- 13 Dec, 2017 2 commits
-
-
Simon Glass authored
Binman construct images consisting of multiple binary files. These files sometimes need to know (at run timme) where their peers are located. For example, SPL may want to know where U-Boot is located in the image, so that it can jump to U-Boot correctly on boot. In general the positions where the binaries end up after binman has finished packing them cannot be known at compile time. One reason for this is that binman does not know the size of the binaries until everything is compiled, linked and converted to binaries with objcopy. To make this work, we add a feature to binman which checks each binary for symbol names starting with '_binman'. These are then decoded to figure out which entry and property they refer to. Then binman writes the value of this symbol into the appropriate binary. With this, the symbol will have the correct value at run time. Macros are used to make this easier to use. As an example, this declares a symbol that will access the 'u-boot-spl' entry to find the 'pos' value (i.e. the position of SPL in the image): binman_sym_declare(unsigned long, u_boot_spl, pos); This converts to a symbol called '_binman_u_boot_spl_prop_pos' in any binary that includes it. Binman then updates the value in that binary, ensuring that it can be accessed at runtime with: ulong u_boot_pos = binman_sym(ulong, u_boot_spl, pos); This assigns the variable u_boot_pos to the position of SPL in the image. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
This is only 3 bytes long which is not enough to hold two symbol values, needed to test the binman symbols feature. Increase it to 15 bytes. Using very small regions is useful since we can easily compare them in tests and errors are fairly easy to diagnose. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
- 19 Dec, 2016 1 commit
-
-
Simon Glass authored
Add entries to support some standard U-Boot binaries, such as u-boot.bin, u-boot.dtb, etc. Also add some tests for these. Signed-off-by:
Simon Glass <sjg@chromium.org> Tested-by:
Bin Meng <bmeng.cn@gmail.com>
-