Commit graph

13 commits

Author SHA1 Message Date
Vagrant Cascadian
5847084f6b Respect SOURCE_DATE_EPOCH when building FIT images.
Embedding timestamps in FIT images results in unreproducible builds
for targets that generate a fit image, such as dra7xx_evm.

This patch uses the SOURCE_DATE_EPOCH environment variable, when set,
to use specified value for the date.

Thanks to HW42 for debugging the issue and providing the patch:

  https://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20160606/005722.html

For more information about reproducible builds and the
SOURCE_DATE_EPOCH specification:

  https://reproducible-builds.org/specs/source-date-epoch/
  https://reproducible-builds.org/

Signed-off-by: Vagrant Cascadian <vagrant@debian.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
2016-06-24 17:23:10 -04:00
Vagrant Cascadian
0219e4bfb4 Fix variation in timestamps caused by timezone differences.
When building with SOURCE_DATE_EPOCH set, avoid use of mktime in
default_image.c, which converts the timestamp into localtime. This
causes variation based on timezone when building u-boot.img and
u-boot-sunxi-with-spl.bin targets.

Signed-off-by: Vagrant Cascadian <vagrant@debian.org>
Tested-by: Paul Kocialkowski <contact@paulk.fr>
Acked-by: Paul Kocialkowski <contact@paulk.fr>
2015-10-11 17:12:12 -04:00
Paul Kocialkowski
f3f431a712 Reproducible U-Boot build support, using SOURCE_DATE_EPOCH
In order to achieve reproducible builds in U-Boot, timestamps that are defined
at build-time have to be somewhat eliminated. The SOURCE_DATE_EPOCH environment
variable allows setting a fixed value for those timestamps.

Simply by setting SOURCE_DATE_EPOCH to a fixed value, a number of targets can be
built reproducibly. This is the case for e.g. sunxi devices.

However, some other devices might need some more tweaks, especially regarding
the image generation tools.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
2015-07-27 15:03:14 -04:00
Guilherme Maciel Ferreira
2662179998 tools: do not print error messages in verify_header() functions
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>
2015-01-29 13:38:41 -05:00
Guilherme Maciel Ferreira
67f946cd18 dumpimage: replace the term "datafile" by "subimage"
Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
2015-01-29 13:38:41 -05:00
Guilherme Maciel Ferreira
a93648d197 imagetool: replace image registration function by linker_lists feature
The registration was introduced in commit f86ed6a8d5

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>
2015-01-29 13:38:41 -05:00
Guilherme Maciel Ferreira
067d156075 imagetool: make the image_save_datafile() available to all image types
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>
2015-01-29 13:38:41 -05:00
Guilherme Maciel Ferreira
a804b5ce2d Add dumpimage, a tool to extract data from U-Boot images
Given a multi-file image created through the mkimage's -d option:

  $ mkimage -A x86 -O linux -T multi -n x86 -d vmlinuz:initrd.img:System.map \
  multi.img

  Image Name:   x86
  Created:      Thu Jul 25 10:29:13 2013
  Image Type:   Intel x86 Linux Multi-File Image (gzip compressed)
  Data Size:    13722956 Bytes = 13401.32 kB = 13.09 MB
  Load Address: 00000000
  Entry Point:  00000000
  Contents:
     Image 0: 4040128 Bytes = 3945.44 kB = 3.85 MB
     Image 1: 7991719 Bytes = 7804.41 kB = 7.62 MB
     Image 2: 1691092 Bytes = 1651.46 kB = 1.61 MB

It is possible to perform the innverse operation -- extracting any file from
the image -- by using the dumpimage's -i option:

  $ dumpimage -i multi.img -p 2 System.map

Although it's feasible to retrieve "data files" from image through scripting,
the requirement to embed tools such 'dd', 'awk' and 'sed' for this sole purpose
is cumbersome and unreliable -- once you must keep track of file sizes inside
the image. Furthermore, extracting data files using "dumpimage" tool is faster
than through scripting.

Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
2013-12-13 09:15:32 -05:00
Guilherme Maciel Ferreira
f86ed6a8d5 tools: moved code common to all image tools to a separated module.
In order to avoid duplicating code and keep only one point of modification,
the functions, structs and defines useful for "dumpimage" were moved from
"mkimage" to a common module called "imagetool".

This modification also weakens the coupling between image types (FIT, IMX, MXS,
and so on) and image tools (mkimage and dumpimage). Any tool may initialize the
"imagetool" through register_image_tool() function, while the image types
register themselves within an image tool using the register_image_type()
function:

                                                      +---------------+
                                               +------|   fit_image   |
 +--------------+          +-----------+       |      +---------------+
 |    mkimage   |--------> |           | <-----+
 +--------------+          |           |              +---------------+
                           | imagetool | <------------|    imximage   |
 +--------------+          |           |              +---------------+
 |  dumpimage   |--------> |           | <-----+
 +--------------+          +-----------+       |      +---------------+
                                               +------| default_image |
                                                      +---------------+

          register_image_tool()           register_image_type()

Also, the struct "mkimage_params" was renamed to "image_tool_params" to make
clear its general purpose.

Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
2013-12-13 09:15:32 -05:00
Wolfgang Denk
1a4596601f Add GPL-2.0+ SPDX-License-Identifier to source files
Signed-off-by: Wolfgang Denk <wd@denx.de>
[trini: Fixup common/cmd_io.c]
Signed-off-by: Tom Rini <trini@ti.com>
2013-07-24 09:44:38 -04:00
Stephen Warren
b9b50e89d3 image: Implement IH_TYPE_KERNEL_NOLOAD
The legacy uImage format includes an absolute load and entry-point
address. When bootm operates on a kernel uImage in memory that isn't
loaded at the address in the image's load address, U-Boot will copy
the image to its address in the header.

Some kernel images can actually be loaded and used at any arbitrary
address. An example is an ARM Linux kernel zImage file. To represent
this capability, IH_TYPE_KERNEL_NOLOAD is implemented, which operates
just like IH_TYPE_KERNEL, except that the load address header is
ignored, and U-Boot does not copy the image to its load address, but
rather uses it in-place.

This is useful when sharing a single (uImage-wrapped) zImage across
multiple boards with different memory layouts; in this case, a specific
load address need not be picked when creating the uImage, but instead
is selected by the board-specific U-Boot environment used to load and
boot that image.

v2: Rename from IH_TYPE_KERNEL_ANYLOAD to IH_TYPE_KERNEL_NOLOAD.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Stefan Roese <sr@denx.de>
2011-12-01 09:45:35 +01:00
Stephen Warren
712fbcf384 checkpatch whitespace cleanups
This avoids the following checkpatch warning in later patches:

ERROR: "(foo*)" should be "(foo *)"
ERROR: space required before the open brace '{'
ERROR: space prohibited before that close parenthesis ')'
ERROR: spaces required around that '||' (ctx:WxV)
WARNING: space prohibited between function name and open parenthesis '('
WARNING: line over 80 characters

This fixes all the white-space warnings/errors in my subsequent patch,
and within this current patch. A number of other checkpatch warnings
and errors are still present in this patch itself, but are beyond simple
whitespace fixes, so are not solved by this patch.

v2: New patch

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
2011-10-22 01:13:35 +02:00
Prafulla Wadaskar
89a4d6b12f tools: mkimage: split code into core, default and FIT image specific
This is a first step towards reorganizing the mkimage code to make it
easier to add support for additional images types. Current mkimage
code is specific to generating uImage and FIT image files, but the
same framework can be used to generate other image types like
Kirkwood boot images (kwbimage-TBD). For this, the mkimage code gets
reworked:

Here is the brief plan for the same:-
a) Split mkimage code into core and image specific support
b) Implement callback functions for image specific code
c) Move image type specific code to respective C files
       Currently there are two types of file generation/list
       supported (i.e uImage, FIT), the code is abstracted from
       mkimage.c/.h and put in default_image.c and fit_image.c;
       all code in these file is static except init function call
d) mkimage_register API is added to add new image type support
All above is addressed in this patch
e) Add kwbimage type support to this new framework (TBD)
This will be implemented in a following commit.

Signed-off-by: Prafulla Wadaskar <prafulla@marvell.com>
Edit commit message, fix coding style and typos.
Signed-off-by: Wolfgang Denk <wd@denx.de>
2009-09-10 22:58:48 +02:00