Unnamed repository; edit this file 'description' to name the repository. http://cgit.235523.xyz/u-boot.git/atom/tools/binman/elf.py?h=v2022.01-rc2 2021-11-13T15:16:39Z 2021-11-13T15:16:39Z Simon Glass sjg@chromium.org 2021-11-04T03:09:18Z urn:sha1:0427bed63bece3caeb8153548903146b73b56677 WIth EFI we must embed the devicetree in an ELF image so that it is loaded as part of the executable file. We want it to include the binman definition in there also, which in some cases cannot be created until the ELF (u-boot) is built. Add an option to binman to support writing the updated dtb to the ELF file u-boot.out This is useful with the EFI app, which is always packaged as an ELF file. Signed-off-by: Simon Glass <sjg@chromium.org> 2021-11-13T15:16:39Z Simon Glass sjg@chromium.org 2021-11-04T03:09:16Z urn:sha1:056f0efd8ba20f382f120262c632545e6f06b4a5 Binman needs to be able to update the contents of an ELF file after it has been build. To support this, add a function to locate the position of a symbol's contents within the file. Fix the comments on bss_data.c and Symbol while we are here. Signed-off-by: Simon Glass <sjg@chromium.org> 2021-01-30T21:25:41Z Simon Glass sjg@chromium.org 2021-01-07T04:35:15Z urn:sha1:870a9ead569ce8ee1f9fc03d178b56e012465582 At present binman only supports resolving symbols in the same section as the binary that uses it. This is quite limited because we often need to group entries into different sections. Enhance the algorithm to search the entire image for symbols. Signed-off-by: Simon Glass <sjg@chromium.org> 2020-12-13T14:58:17Z Simon Glass sjg@chromium.org 2020-11-09T03:36:19Z urn:sha1:6a4ccad8e0cb42d53ff7016c1d9cd53b87e4347a This is not needed in Python 3. Drop it. Signed-off-by: Simon Glass <sjg@chromium.org> 2020-09-22T18:54:13Z Alper Nebi Yasak alpernebiyasak@gmail.com 2020-09-06T11:46:05Z urn:sha1:1e4687aa47ed269bbc82497df872f614cfafb2e9 Currently, binman always runs the compile tools like cc, objcopy, strip, etc. using their literal name. Instead, this patch makes it use the target-specific versions by default, derived from the tool-specific environment variables (CC, OBJCOPY, STRIP, etc.) or from the CROSS_COMPILE environment variable. For example, the u-boot-elf etype directly uses 'strip'. Trying to run the tests with 'CROSS_COMPILE=i686-linux-gnu- binman test' on an arm64 host results in the '097_elf_strip.dts' test to fail as the arm64 version of 'strip' can't understand the format of the x86 ELF file. This also adjusts some command.Output() calls that caused test errors or failures to use the target versions of the tools they call. After this, patch, an arm64 host can run all tests with no errors or failures using a correct CROSS_COMPILE value. Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> 2020-04-26T20:25:21Z Simon Glass sjg@chromium.org 2020-04-18T00:09:04Z urn:sha1:bf776679a73f3b9eae37aabd2be5754483039cb2 At present patman sets the python path on startup so that it can access the libraries it needs. If we convert to use absolute imports this is not necessary. Move patman to use absolute imports. This requires changes in tools which use the patman libraries (which is most of them). Signed-off-by: Simon Glass <sjg@chromium.org> 2020-04-26T20:25:21Z Simon Glass sjg@chromium.org 2020-04-18T00:09:03Z urn:sha1:16287933a852bab2ac4985a770e08c9aa69d21b1 At present binman sets the python path on startup so that it can access the libraries it needs. If we convert to use absolute imports this is not necessary. Move binman to use absolute imports. This enables removable of the path adjusting in Entry also. Signed-off-by: Simon Glass <sjg@chromium.org> 2020-04-26T20:25:21Z Simon Glass sjg@chromium.org 2020-04-18T00:08:54Z urn:sha1:83a45187715e719bfe520b9ca0373bd8b5bee8aa We don't need these now that the tools using Python 3. Drop them. Signed-off-by: Simon Glass <sjg@chromium.org> 2019-11-11T19:20:35Z Simon Glass sjg@chromium.org 2019-11-07T00:22:44Z urn:sha1:7c150136398916ac546b5a902d09208cc793cabe 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> 2019-11-02T10:00:51Z Simon Glass sjg@chromium.org 2019-10-21T03:31:34Z urn:sha1:15c981cc8adc26501e3a19ca7fb35705870ef597 At present binman adds the image base address to the symbol value before it writes it to the binary. This is not correct since the symbol value itself (e.g. image position) has no relationship to the image base. Fix this and update the tests to cover this case. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>