summaryrefslogtreecommitdiff
path: root/tools/default_image.c
Commit message (Collapse)AuthorAgeLines
* Respect SOURCE_DATE_EPOCH when building FIT images.Vagrant Cascadian2016-06-24-13/+1
| | | | | | | | | | | | | | | | | | | | | 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>
* Fix variation in timestamps caused by timezone differences.Vagrant Cascadian2015-10-11-5/+1
| | | | | | | | | | | 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>
* Reproducible U-Boot build support, using SOURCE_DATE_EPOCHPaul Kocialkowski2015-07-27-1/+20
| | | | | | | | | | | | | | 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>
* tools: do not print error messages in verify_header() functionsGuilherme Maciel Ferreira2015-01-29-9/+8
| | | | | | | | | | | 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>
* dumpimage: replace the term "datafile" by "subimage"Guilherme Maciel Ferreira2015-01-29-3/+3
| | | | Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
* imagetool: replace image registration function by linker_lists featureGuilherme Maciel Ferreira2015-01-29-16/+14
| | | | | | | | | The registration was introduced in commit f86ed6a8d52c99bb2d17d3cac1647edca0c4399c 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>
* imagetool: make the image_save_datafile() available to all image typesGuilherme Maciel Ferreira2015-01-29-27/+1
| | | | | | | | 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>
* Add dumpimage, a tool to extract data from U-Boot imagesGuilherme Maciel Ferreira2013-12-13-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* tools: moved code common to all image tools to a separated module.Guilherme Maciel Ferreira2013-12-13-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Add GPL-2.0+ SPDX-License-Identifier to source filesWolfgang Denk2013-07-24-14/+1
| | | | | | Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com>
* image: Implement IH_TYPE_KERNEL_NOLOADStephen Warren2011-12-01-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* checkpatch whitespace cleanupsStephen Warren2011-10-22-28/+28
| | | | | | | | | | | | | | | | | | | | | | 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>
* tools: mkimage: split code into core, default and FIT image specificPrafulla Wadaskar2009-09-10-0/+149
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>
generated by cgit v1.1 at 2024-11-02 00:03:52 +0000