Ye.Li authored 10 years ago and Stefano Babic committed 10 years ago

Add QuadSPI boot support to imximage tool.

Note: The QuadSPI configuration parameters at offset 0x400 are not
included in this patch. Need other tools to generate the parameters
part.

Signed-off-by: Ye.Li <B37916@freescale.com>

We can't use config.h directly as some platforms include headers that
aren't safe to use in normal Linux userland.

Signed-off-by: Tom Rini <trini@ti.com>

This is used on the AXP boards, to pad u-boot.img to the desired offset in
SPI flash (only this boot target supported right now). This offset is
used by the SPL then to load u-boot.img into SDRAM and execute it there.

Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Luka Perkov <luka.perkov@sartura.hr>

Sometimes microcode is delivered as a header file. Allow the tool to
support this as well as collecting multiple microcode blocks into a
single update.

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

Add an explanation for how to set up git so that patman can find the alias
file. Fix up the get_maintainers message too.

Reported-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

True commit lines start at column zero.  Anything that is indented
is part of the commit message instead.  I noticed this by trying to
run buildman with commit e3a4facd
as master, which contained a reference to a Linux commit inside
the commit message.  ProcessLine saw that as a genuite commit
line, and thus buildman tried to build it, and died with an
exception because that SHA is not present in the U-Boot tree.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: Simon Glass <sjg@chromium.org>

When run with the --dry-run argument patman prints out information
showing what it would do.  This information currently doesn't line up
with what patman/git send-email really do.  Some basic examples:
- If an email address is addressed via "Series-cc" and "Patch-cc" patman
  shows that email address would be CC-ed two times.
- If an email address is addressed via "Series-to" and "Patch-cc" patman
  shows that email address would be sent TO and CC-ed.
- If an email address is addressed from a combination of tag aliases,
  get_maintainer.pl output, "Series-cc", "Patch-cc", etc patman shows
  that the email address would be CC-ed multiple times.

Patman currently does try to send duplicate emails like the --dry-run
output shows, but "git send-email" intelligently removes duplicate
addresses so this patch shouldn't change the non-dry-run functionality.

Change patman's output and email addressing to line up with the
"git send-email" logic.  This trims down patman's dry-run output and
prevents confusion about what patman will do when emails are actually
sent.

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
CC: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>

Public exponentiation which is required in rsa verify functionality is
tightly integrated with verification code in rsa_verify.c. The patch
splits the file into twp separating the modular exponentiation.

1. rsa-verify.c
- The file parses device tree keys node to fill a keyprop structure.
The keyprop structure can then be converted to implementation specific
format.
(struct rsa_pub_key for sw implementation)
- The parsed device tree node is then passed to a generic rsa_mod_exp
function.

2. rsa-mod-exp.c
Move the software specific functions related to modular exponentiation
from rsa-verify.c to this file.

Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
CC: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>

default_image.c and socfpgaimage.c are the only image modules that print error
messages during header verification. The verify_header() is used to query if a
given image file is processed by the image format. Thus, if the image format
can't handle the file, it must simply return an error. Otherwise we pollute the
screen with errors messages until we find the image format that handle a given
image file.

Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>

The dumpimage is able to extract components contained in a FIT image:

  $ ./dumpimage -T flat_dt -i CONTAINER.ITB -p INDEX FILE

The CONTAINER.ITB is a regular FIT container file. The INDEX is the poisition
of the sub-image to be retrieved, and FILE is the file (path+name) to save the
extracted sub-image.

For example, given the following kernel.its to build a kernel.itb:

  /dts-v1/;
  / {
      ...
      images {
        kernel@1 {
          description = "Kernel 2.6.32-34";
          data = /incbin/("/boot/vmlinuz-2.6.32-34-generic");
          type = "kernel";
          arch = "ppc";
          os = "linux";
          compression = "gzip";
          load = <00000000>;
          entry = <00000000>;
          hash@1 {
            algo = "md5";
          };
        };
        ...
      };
      ...
    };

The dumpimage can extract the 'kernel@1' node through the following command:

  $ ./dumpimage -T flat_dt -i kernel.itb -p 0 kernel
  Extracted:
   Image 0 (kernel@1)
    Description:  Kernel 2.6.32-34
    Created:      Wed Oct 22 15:50:26 2014
    Type:         Kernel Image
    Compression:  gzip compressed
    Data Size:    4040128 Bytes = 3945.44 kB = 3.85 MB
    Architecture: PowerPC
    OS:           Linux
    Load Address: 0x00000000
    Entry Point:  0x00000000
    Hash algo:    md5
    Hash value:   22352ad39bdc03e2e50f9cc28c1c3652

Which results in the file 'kernel' being exactly the same as '/boot/vmlinuz-2.6.32-34-generic'.

Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>

Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>

Some image types, like "KeyStone GP", do not have magic numbers to
distinguish them from other image types. Thus, the automatic image
type discovery does not work correctly.

This patch also fix some integer type mismatches.

Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>

The registration was introduced in commit f86ed6a8

This commit also removes all registration functions, and the member "next"
from image_type_params struct

Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>

Move the image_save_datafile() function from an U-Multi specific file
(default_image.c) to a file common to all image types (image.c). And rename it
to genimg_save_datafile(), to make clear it is useful for any image type.

Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>

The get_type() and verify_print_header() functions have the
same code on both dumpimage.c and mkimage.c modules.

Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>

Nikita Kiryanov authored 10 years ago and Stefano Babic committed 10 years ago

Add compulab logo and display it on boot.

Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>

Alexandre Coffignal authored 10 years ago and Stefano Babic committed 10 years ago

Add support for the NAND Flash chip with page size of 4096+224-bytes OOB area length

For example Micron MT29F4G08 NAND flash device defines a OOB area which is
224 bytes long (oobsize).

Signed-off-by: Alexandre Coffignal <acoffignal@geral.com>

Normally buildman runs with 'make -s' meaning that only errors and warnings
appear in the log file. Add a -V option to run make in verbose mode, and
with V=1, causing a full build log to be created.

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

The site at https://www.kernel.org/pub/tools/crosstool/

 is a convenient
repository of toolchains which can be used for U-Boot. Add a feature to
download and install a toolchain for a selected architecture automatically.

It isn't clear how long this site will stay in the current place and
format, but we should be able to rely on bug reports if it changes.

Suggested-by: Marek Vašut <marex@denx.de>
Suggested-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

Some archs have need than one alias, so support a list of alises in the
..buildman file.

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

We should create a test setting file when running testes, not use whatever
happens to be on the local machine.

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

Silently ignore this since it is valid to have missing sections.

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

This file is only partially documented. Add some more details.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Wolfgang Denk <wd@denx.de>

Since we need a few modules which might not be available in a bare-bones
distribution, add a note about that to the README.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Wolfgang Denk <wd@denx.de>

In some cases there may be multiple toolchains with the same name in the
path. Provide an option to use the full path in the CROSS_COMPILE
environment variable.

Note: Wolfgang mentioned that this is dangerous since in some cases there
may be other tools on the path that are needed. So this is set up as an
option, not the default. I will need test confirmation (i.e. that this
commit fixes a real problem) before merging it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Steve Rae <srae@broadcom.com>

If:

1. Toolchains A and B have the same filename
2. Toolchain A is in the PATH
3. Toolchain B is given in ~/.buildman and buildman uses it to build

then buildman will add toolchain B to the end of its path but will not
necessarily use it since U-Boot will find toolchain A first in the PATH.

Try to fix this by putting the toolchain first in the path instead of
last.

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

The assumption that the compiler name will always end in gcc is incorrect
for clang and apparently on BSD.

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

Adjust the -b flag to permit a range expression as well as a branch.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Tested-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>

When running tests the output directory is often wiped. This is only safe if
a branch is being built. The output directory may contain other things
besides the buildman test output.

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

When building current source for a single board, buildman puts the output
in <output_dir>/current/current/<board>. Add an option to make it use
<output_dir>/<board> instead. This removes the unnecessary directories
in that case, controlled by the --no-subdirs/-N option.

Suggested-by: Tom Rini <trini@ti.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

Buildman normally obtains the upstream commit by asking git. Provided that
the branch was created with 'git checkout -b <branch> <some_upstream>' then
this normally works.

When there is no upstream, we can try to guess one, by looking up through
the commits until we find a branch. Add a function to try this and print
a warning if buildman ends up relying on it.

Also update the documentation to match.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Wolfgang Denk <wd@denx.de>

This is not needed since we always do a full (non-incremental) build. Also
it might be dangerous since it will try to delete everything below the
base directory.

Fix this potentially nasty bug.

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

Buildman currently puts current-source builds in a current/current
subdirectory, but there is no need for the extra depth.

Suggested-by: Albert Aribaud <albert.u.boot@aribaud.net>
Signed-off-by: Simon Glass <sjg@chromium.org>

Add a few tests of the output directory logic.

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

This currently assumes that U-Boot resides at the start of ROM. Update
it to remove this assumption.

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

The two error checks for image_boot_mode_id and image_nand_ecc_mode_id where
wrong and would never fail, fix that!

This was detected by Apple's clang compiler:
---8<---
  HOSTCC  tools/kwbimage.o
tools/kwbimage.c:553:20: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
                if (el->bootfrom < 0) {
                    ~~~~~~~~~~~~ ^ ~
tools/kwbimage.c:571:23: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
                if (el->nandeccmode < 0) {
                    ~~~~~~~~~~~~~~~ ^ ~
2 warnings generated.
--->8---

Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Acked-By: Jeroen Hofstee <jeroen@myspectrum.nl>

When building with my toolchain (4.8.2):
CROSS_COMPILE=/home/lukma/work/ptxdist/toolchains/arm/OSELAS.Toolchain-2013.12.0/arm-v7a-linux-gnueabi/gcc-4.8.2-glibc-2.18-binutils-2.24-kernel-3.12-sanitized/bin/arm-v7a-linux-gnueabi-

I see following WARNING:
tools/kwbimage.c: In function "kwbimage_set_header":
tools/kwbimage.c:803:8: warning: "headersz" may be used uninitialized in this function [-Wmaybe-uninitialized]
  memcpy(ptr, image, headersz);
        ^
This fix aims to suppress it.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Acked-by: Stefan Roese <sr@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>

Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

Intel delivers microcode updates in a microcode.dat file which must be
split up into individual files for each CPU. Add a tool which performs
this task. It can list available microcode updates for each model and
produce a new microcode update in U-Boot's .dtsi format.

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