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

Drop the now-unused Python 2 code to keep code coverage at 100%.

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>

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>

Build this swig module with Python 3.

Signed-off-by: Simon Glass <sjg@chromium.org>

Convert this tool to Python 3 and make it use that, to meet the 2020
deadline.

Signed-off-by: Simon Glass <sjg@chromium.org>

Convert this tool to Python 3 and make it use that, to meet the 2020
deadline.

Signed-off-by: Simon Glass <sjg@chromium.org>

Convert this tool to Python 3 and make it use that, to meet the 2020
deadline.

Signed-off-by: Simon 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: Simon Glass <sjg@chromium.org>

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

Signed-off-by: Simon Glass <sjg@chromium.org>

Convert buildman to Python 3 and make it use that, to meet the 2020
deadline.

Signed-off-by: Simon Glass <sjg@chromium.org>

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

Signed-off-by: Simon 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: 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>

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

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 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-S (Firmware Support Package
Silicon init) binary. Add support for this in binman.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin 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: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin 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: Michal 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: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon 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: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon 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: Bin Meng <bmeng.cn@gmail.com>

Some compilers may provide __packed define for us.

Signed-off-by: Bin 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: Bin Meng <bmeng.cn@gmail.com>

__leXX has Linux kernel specific __attribute__((bitwise)) which is
not portable. Use corresponding uintXX_t instead.

Signed-off-by: Bin 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: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

dpll_prog is available in some psu_init files that's why this function
should stay there.

Signed-off-by: Michal 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.html



Signed-off-by: Douglas Anderson <dianders@chromium.org>

This code is not needed so drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>

Sometimes binman takes multiple passes to complete packing an image. Add
logging to indicate this.

Signed-off-by: Simon 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: Simon 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: Simon 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: Simon 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: Simon Glass <sjg@chromium.org>

This comment references another entry type. Fix it.

Signed-off-by: Simon 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: Simon 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: Simon Glass <sjg@chromium.org>

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>