Unnamed repository; edit this file 'description' to name the repository. http://cgit.235523.xyz/u-boot.git/atom/tools/binman/elf.py?h=v2021.01 2020-09-22T18:54:13Z 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> 2019-10-15T14:40:02Z Simon Glass sjg@chromium.org 2019-08-24T13:22:52Z urn:sha1:180f556b090c2e3c84c904d3e6bc884acb423e1f At present this command silently fails if something goes wrong. Use the tools.Run() function instead, since it reports errors. Signed-off-by: Simon Glass <sjg@chromium.org> 2019-10-15T14:40:02Z Simon Glass sjg@chromium.org 2019-08-24T13:22:46Z urn:sha1:39c8e47d2ee38975b9377ee0049d2f88efc3edba Some versions of binutils generate hidden symbols which are currently not parsed by binman. Correct this. Signed-off-by: Simon Glass <sjg@chromium.org> 2019-10-15T14:40:02Z Simon Glass sjg@chromium.org 2019-08-24T13:22:45Z urn:sha1:9d44a7e6c67be9661e6d3dff3a2d5da31dd06cbc Recent versions of binutils add a '.note.gnu.property' into the ELF file. This is not required and interferes with the expected output. Drop it. Also fix testMakeElf() to use a different file for input and output. Signed-off-by: Simon Glass <sjg@chromium.org> 2019-07-29T15:38:05Z Simon Glass sjg@chromium.org 2019-07-20T18:23:36Z urn:sha1:9f297b09c06f2212cb59dac5950ae61de5fe3a9f Use the new logging feature to log information about progress with packing. This is useful to see how binman is figuring things out. Also update elf.py to use the same feature. Signed-off-by: Simon Glass <sjg@chromium.org>