u-boot.git/tools, branch v2020.01-rc1

tools: buildman: Remove useless mkdir() in Make() in test.py

2019-10-29T20:17:39+00:00

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 
Reviewed-by: Simon Glass

tools: buildman: Honor output directory when generating boards.cfg

2019-10-29T20:17:36+00:00

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 
Reviewed-by: Simon Glass

tools: Avoid creating symbolic links for tools/version.h

2019-10-28T17:32:51+00:00

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

tools: ifwitool: Define __packed when it is not defined

2019-10-28T17:32:51+00:00

Some compilers may provide __packed define for us.

Signed-off-by: Bin Meng

tools: zynqmpbif: Use compiler builtin instead of linux-specific __swab32

2019-10-28T17:32:51+00:00

__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

tools: mtk_image.h: Use portable uintXX_t instead of linux-specific __leXX

2019-10-28T17:32:51+00:00

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

Signed-off-by: Bin Meng

arm64: zynqmp: Do not remove dpll_prog from psu_init

2019-10-24T11:37:02+00:00

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

Signed-off-by: Michal Simek

patman: Use the Change-Id, version, and prefix in the Message-Id

2019-10-15T14:40:03+00:00

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

binman: Drop comment-out code in testUpdateFdtOutput()

2019-10-15T14:40:02+00:00

This code is not needed so drop it.

Signed-off-by: Simon Glass

binman: Add logging for the number of pack passes

2019-10-15T14:40:02+00:00

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

Signed-off-by: Simon Glass