u-boot.git/tools/binman, branch v2020.04 Unnamed repository; edit this file 'description' to name the repository. binman: fix default filename of u-boot-with-ucode-ptr in documentation 2020-01-07T23:02:39+00:00 Masahiro Yamada masahiroy@kernel.org 2019-12-14T04:47:26+00:00 f6a8c0f4680f2364289c9fc45dabab5f63fd06a0 The suffix should be ".bin" instead of ".dtb" . Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
The suffix should be ".bin" instead of ".dtb" .

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
cosmetic: Fix spelling and whitespace errors 2019-12-03T13:43:23+00:00 Thomas Hebb tommyhebb@gmail.com 2019-11-14T02:18:03+00:00 32f2ca2a7e2ec3ecd0cfd56faebf4003001226fd Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> 
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
binman: tegra: Adjust symbol calculation depending on end-at-4gb 2019-11-11T19:20:35+00:00 Simon Glass sjg@chromium.org 2019-11-07T00:22:44+00:00 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> 
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>
binman: Move to use Python 3 2019-11-05T01:15:32+00:00 Simon Glass sjg@chromium.org 2019-10-31T13:43:05+00:00 388560134b99dc4cc752627d3a7e9f8c8c2a89a7 Update this tool to use Python 3 to meet the 2020 deadline. Unfortunately this introduces a test failure due to a problem in pylibfdt on Python 3. I will investigate. Signed-off-by: Simon Glass <sjg@chromium.org> 
Update this tool to use Python 3 to meet the 2020 deadline.

Unfortunately this introduces a test failure due to a problem in pylibfdt
on Python 3. I will investigate.

Signed-off-by: Simon Glass <sjg@chromium.org>
binman: Convert a few tests to Python 3 2019-11-05T01:15:32+00:00 Simon Glass sjg@chromium.org 2019-10-31T13:43:03+00:00 b6ee0cf89f9405094cbb6047076a13e14ebc030b Some tests have crept in with Python 2 strings and constructs. Convert then. Signed-off-by: Simon Glass <sjg@chromium.org> 
Some tests have crept in with Python 2 strings and constructs. Convert
then.

Signed-off-by: Simon Glass <sjg@chromium.org>
binman: Remember the pre-reset entry size 2019-11-05T01:15:32+00:00 Simon Glass sjg@chromium.org 2019-10-31T13:43:02+00:00 9a5d3dcff7894a24e493e6ae52d289d190d3ccdf When preparing to possible expand or contract an entry we reset the size to the original value from the binman device-tree definition, which is often None. This causes binman to forget the original size of the entry. Remember this so that it can be used when needed. Signed-off-by: Simon Glass <sjg@chromium.org> 
When preparing to possible expand or contract an entry we reset the size
to the original value from the binman device-tree definition, which is
often None.

This causes binman to forget the original size of the entry. Remember this
so that it can be used when needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
pylibfdt: Convert to Python 3 2019-11-05T01:15:32+00:00 Simon Glass sjg@chromium.org 2019-10-31T13:42:59+00:00 b4cf5f1df741e8781bed6149291823cd1a4b8baa Build this swig module with Python 3. Signed-off-by: Simon Glass <sjg@chromium.org> 
Build this swig module with Python 3.

Signed-off-by: Simon Glass <sjg@chromium.org>
patman: Adjust 'command' to return strings instead of bytes 2019-11-05T01:15:32+00:00 Simon Glass sjg@chromium.org 2019-10-31T13:42:50+00:00 3b3e3c0f6c261a8c9f989d437dc261ba84467d4f At present all the 'command' methods return bytes. Most of the time we actually want strings, so change this. We still need to keep the internal representation as bytes since otherwise unicode strings might break over a read() boundary (e.g. 4KB), causing errors. But we can convert the end result to strings. Add a 'binary' parameter to cover the few cases where bytes are needed. Signed-off-by: Simon Glass <sjg@chromium.org> 
At present all the 'command' methods return bytes. Most of the time we
actually want strings, so change this. We still need to keep the internal
representation as bytes since otherwise unicode strings might break over
a read() boundary (e.g. 4KB), causing errors. But we can convert the end
result to strings.

Add a 'binary' parameter to cover the few cases where bytes are needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
binman: Fix up comment in intel-fsp-m 2019-11-02T10:00:51+00:00 Simon Glass sjg@chromium.org 2019-10-21T03:31:37+00:00 211193dc5c732af1b88be0e6c23715f83afd1cb0 This comment references the wrong FSP component. Fix it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> 
This comment references the wrong FSP component. Fix it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
binman: Add support for Intel FSP-T 2019-11-02T10:00:51+00:00 Simon Glass sjg@chromium.org 2019-10-21T03:31:36+00:00 998d1482cdf980c083cdd95078fd86b53f963c41 This entry is used to hold an Intel FSP-T (Firmware Support Package Temp-RAM init) binary. Add support for this in binman. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> 
This entry is used to hold an Intel FSP-T (Firmware Support Package
Temp-RAM init) binary. Add support for this in binman.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>