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: NSimon Glass <sjg@chromium.org>
Tested-by: NStephen Warren <swarren@nvidia.com>

This script was only used on the MX1ADS board (and possibly other MX1
platforms) to program the flash.  As we no longer have any boards for
that SoC, remove this tool.

Fixes: e570aca9 ("mx1ads: remove board support")
Signed-off-by: NTom Rini <trini@konsulko.com>

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: NSimon Glass <sjg@chromium.org>

Drop the now-unused Python 2 code to keep code coverage at 100%.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Some tests have crept in with Python 2 strings and constructs. Convert
then.
Signed-off-by: NSimon 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: NSimon Glass <sjg@chromium.org>

Build this swig module with Python 3.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Convert this tool to Python 3 and make it use that, to meet the 2020
deadline.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Convert this tool to Python 3 and make it use that, to meet the 2020
deadline.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Convert this tool to Python 3 and make it use that, to meet the 2020
deadline.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Update this test to use Python 3 to meet the 2020 deadline.

Also make it executable while we are here.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Update this test to use Python 3 to meet the 2020 deadline.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Convert buildman to Python 3 and make it use that, to meet the 2020
deadline.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Update this tool to use Python 3 to meet the 2020 deadline.
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present patman test fail in some environments which don't use utf-8
as the default file encoding. Add this explicitly.
Signed-off-by: NSimon 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: NSimon Glass <sjg@chromium.org>

Bring over the fdt from this commit:

430419c (origin/master) tests: fix some python warnings

adding in the 'assumptions' series designed to reduce code size.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This comment references the wrong FSP component. Fix it.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin 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: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

This entry is used to hold an Intel FSP-S (Firmware Support Package
Silicon init) binary. Add support for this in binman.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

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: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

When running the following command

    mkimage -f auto -A arm -O linux -T kernel -C none -a 0x8000 -e 0x8000 \
            -d zImage -b zynq-microzed.dtb -i initramfs.cpio image.ub

the type of fdt subimage is the same as of the main kernel image and
the architecture of the initramfs image is not set. Such an image is
refused by U-Boot when booting. This commits sets the mentioned
attributes, allowing to use the "-f auto" mode in this case instead of
writing full .its file.

Following is the diff of mkimage output without and with this commit:

 FIT description: Kernel Image image with one or more FDT blobs
 Created:         Thu Sep 12 23:23:16 2019
  Image 0 (kernel-1)
   Description:
   Created:      Thu Sep 12 23:23:16 2019
   Type:         Kernel Image
   Compression:  uncompressed
   Data Size:    4192744 Bytes = 4094.48 KiB = 4.00 MiB
   Architecture: ARM
   OS:           Linux
   Load Address: 0x00008000
   Entry Point:  0x00008000
  Image 1 (fdt-1)
   Description:  zynq-microzed
   Created:      Thu Sep 12 23:23:16 2019
-  Type:         Kernel Image
+  Type:         Flat Device Tree
   Compression:  uncompressed
   Data Size:    9398 Bytes = 9.18 KiB = 0.01 MiB
   Architecture: ARM
-  OS:           Unknown OS
-  Load Address: unavailable
-  Entry Point:  unavailable
  Image 2 (ramdisk-1)
   Description:  unavailable
   Created:      Thu Sep 12 23:23:16 2019
   Type:         RAMDisk Image
   Compression:  Unknown Compression
   Data Size:    760672 Bytes = 742.84 KiB = 0.73 MiB
-  Architecture: Unknown Architecture
+  Architecture: ARM
   OS:           Linux
   Load Address: unavailable
   Entry Point:  unavailable
  Default Configuration: 'conf-1'
  Configuration 0 (conf-1)
   Description:  zynq-microzed
   Kernel:       kernel-1
   Init Ramdisk: ramdisk-1
   FDT:          fdt-1
   Loadables:    kernel-1
Signed-off-by: NMichal Sojka <michal.sojka@cvut.cz>

In the 'Make' function, the codes tries to create a directory
if current stage is 'build'. But the directory isn't used at
all anywhere.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

buildman always generates boards.cfg in the U-Boot source tree.
When '-o' is given, we should generate boards.cfg to the given
output directory.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

When building U-Boot host tools for Windows from Microsoft Azure
Pipelines, the following errors were seen:

  HOSTCC  tools/mkenvimage.o
  In file included from tools/mkenvimage.c:25:
  ./tools/version.h:1:1: error: expected identifier or ‘(’ before ‘.’ token
     1 | ../include/version.h
       | ^
  tools/mkenvimage.c: In function ‘main’:
  tools/mkenvimage.c:117:4: warning: implicit declaration of function ‘usage’ [-Wimplicit-function-declaration]
   117 |    usage(prg);
       |    ^~~~~
  tools/mkenvimage.c:120:35: error: ‘PLAIN_VERSION’ undeclared (first use in this function)
   120 |    printf("%s version %s\n", prg, PLAIN_VERSION);
       |                                   ^~~~~~~~~~~~~
  tools/mkenvimage.c:120:35: note: each undeclared identifier is reported only once for each function it appears in
  make[2]: *** [scripts/Makefile.host:114: tools/mkenvimage.o] Error 1

It turns out tools/version.h is a symbolic link and with Windows
default settings it is unsupported hence the actual content of
tools/version.h is not what file include/version.h has, but the
the linked file path, which breaks the build.

To fix this, remove the symbolic links for tools/version.h. Instead
we perform a copy from include/version.h during the build.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>

Some compilers may provide __packed define for us.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>

__swab32() is a Linux specific macro defined in linux/swab.h. Let's
use the compiler equivalent builtin function __builtin_bswap32() for
better portability.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>

__leXX has Linux kernel specific __attribute__((bitwise)) which is
not portable. Use corresponding uintXX_t instead.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>

There is a contributor in Linux kernel with a comma in their name, which
confuses patman and results in invalid to- or cc- addresses on some
patches. To avoid this, let's use \0 as a separator when generating cc
file.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

dpll_prog is available in some psu_init files that's why this function
should stay there.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

As per the centithread on ksummit-discuss [1], there are folks who
feel that if a Change-Id is present in a developer's local commit that
said Change-Id could be interesting to include in upstream posts.
Specifically if two commits are posted with the same Change-Id there's
a reasonable chance that they are either the same commit or a newer
version of the same commit.  Specifically this is because that's how
gerrit has trained people to work.

There is much angst about Change-Id in upstream Linux, but one thing
that seems safe and non-controversial is to include the Change-Id as
part of the string of crud that makes up a Message-Id.

Let's give that a try.

In theory (if there is enough adoption) this could help a tool more
reliably find various versions of a commit.  This actually might work
pretty well for U-Boot where (I believe) quite a number of developers
use patman, so there could be critical mass (assuming that enough of
these people also use a git hook that adds Change-Id to their
commits).  I was able to find this git hook by searching for "gerrit
change id git hook" in my favorite search engine.

In theory one could imagine something like this could be integrated
into other tools, possibly even git-send-email.  Getting it into
patman seems like a sane first step, though.

NOTE: this patch is being posted using a patman containing this patch,
so you should be able to see the Message-Id of this patch and see that
it contains my local Change-Id, which ends in 2b9 if you want to
check.

[1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2019-August/006739.htmlSigned-off-by: NDouglas Anderson <dianders@chromium.org>

This code is not needed so drop it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Sometimes binman takes multiple passes to complete packing an image. Add
logging to indicate this.
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present the symbol information is written to binaries just before
binman exits. This is fine for entries within sections since the section
contents is calculated when it is needed, so the updated symbol values are
included in the image that is written.

However some binaries are inside entries which have already generated
their contents and do not notice that the entries have changed (e.g. Intel
IFWI).

Move the symbol writing earlier to cope with this.
Signed-off-by: NSimon Glass <sjg@chromium.org>

The Intel IFWI (Integrated Firmware Image) is effectively a section with
other entries inside it. Support writing symbol information into entries
within it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Add support for the ProcessContents() method in this entry so that it is
possible to support entries which change after initial creation.
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present this class reads its entries in the constructor. This is not
how things should be done now. Update it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This comment references another entry type. Fix it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

The Intel FSP supports initialising memory early during boot using a binary
blob called 'fspm'. Add support for this.
Signed-off-by: NSimon Glass <sjg@chromium.org>

It is useful to be able to access the size of an image in SPL, with
something like:

binman_sym_declare(unsigned long, u_boot_any, size);

...
   ulong u_boot_size = binman_sym(ulong, u_boot_any, size);

Add support for this and update the tests.
Signed-off-by: NSimon Glass <sjg@chromium.org>