Usage:

 (1) tools/mkimage -n rk3308 -T rksd -d tpl/u-boot-tpl.bin idbloader.img
 (2) cat spl/u-boot-spl.bin >> idbloader.img
 (3) upgrade_tool wl 0x40 idbloader.img

Note:
  When use ddr binary from rkbin as tpl, use it replace u-boot-tpl.bin in(1)

Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Add the table entry for px30 socs.
The px30 has 10K of sram available.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Move this symbol to Kconfig.  As part of this we can drop a UBI-specific
symbol that was a stop-gap for not having this particular symbol in
Kconfig.

Signed-off-by: Tom Rini <trini@konsulko.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>

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>

some boards use ddr4, not lpddr4, so we need to check ddr4 firmware.

Signed-off-by: Peng Fan <peng.fan@nxp.com>

The IVT offset is changed on i.MX8MN. Use ROM_VERSION to pass the
v1 or v2 to mkimage.
v1 is for iMX8MQ and iMX8MM
v2 is for iMX8M Nano (iMX8MN)

Signed-off-by: Peng Fan <peng.fan@nxp.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>