summaryrefslogtreecommitdiff
path: root/tools/imagetool.h
Commit message (Collapse)AuthorAgeLines
* mkimage: Add support for signing with pkcs11George McCollister2017-01-14-0/+1
| | | | | | | | | | | | Add support for signing with the pkcs11 engine. This allows FIT images to be signed with keys securely stored on a smartcard, hardware security module, etc without exposing the keys. Support for other engines can be added in the future by modifying rsa_engine_get_pub_key() and rsa_engine_get_priv_key() to construct correct key_id strings. Signed-off-by: George McCollister <george.mccollister@gmail.com>
* mkimage: Allow including a ramdisk in FIT auto modeTomeu Vizoso2016-11-06-0/+1
| | | | | | | | | | | | | | | Adds -i option that allows specifying a ramdisk file to be added to the FIT image when we are using the automatic FIT mode (no ITS file). This makes adding Depthcharge support to LAVA much more convenient, as no additional configuration files need to be kept around in the machine that dispatches jobs to the boards. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Simon Glass <sjg@chromium.org> Cc: Matt Hart <matthew.hart@linaro.org> Cc: Neil Williams <codehelp@debian.org> Reviewed-by: Simon Glass <sjg@chromium.org>
* Respect SOURCE_DATE_EPOCH when building FIT images.Vagrant Cascadian2016-06-24-0/+16
| | | | | | | | | | | | | | | | | | | | | 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>
* mkimage: fit: spl: Add an optional static offset for external dataTeddy Reed2016-06-24-0/+1
| | | | | | | | | | | | When building a FIT with external data (-E), U-Boot proper may require absolute positioning for executing the external firmware. To acheive this use the (-p) switch, which will replace the amended 'data-offset' with 'data-position' indicating the absolute position of external data. It is considered an error if the requested absolute position overlaps with the initial data required for the compact FIT. Signed-off-by: Teddy Reed <teddy.reed@gmail.com>
* mkimage: Add a quiet modeSimon Glass2016-05-23-0/+1
| | | | | | | | | Some build systems want to be quiet unless there is a problem. At present mkimage displays quite a bit of information when generating a FIT file. Add a '-q' flag to silence this. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
* mkimage: Support placing data outside the FITSimon Glass2016-03-14-0/+1
| | | | | | | | | | | | | | | | | | | One limitation of FIT is that all the data is 'inline' within it, using a 'data' property in each image node. This means that to find out what is in the FIT it is necessary to scan the entire file. Once loaded it can be scanned and then the images can be copied to the correct place in memory. In SPL it can take a significant amount of time to copy images around in memory. Also loading data that does not end up being used is wasteful. It would be useful if the FIT were small, acting as a directory, with the actual data stored elsewhere. This allows SPL to load the entire FIT, without the images, then load the images it wants later. Add a -E option to mkimage to request that it output an 'external' FIT. Signed-off-by: Simon Glass <sjg@chromium.org>
* mkimage: Support adding device tree files to a FITSimon Glass2016-03-14-0/+9
| | | | | | | | | | | To make the auto-FIT feature useful we need to be able to provide a list of device tree files on the command line for mkimage to add into the FIT. Add support for this feature. So far there is no support for hashing or verified boot using this method. For those cases, a .its file must still be provided. Signed-off-by: Simon Glass <sjg@chromium.org>
* mkimage: Support automatic creating of a FIT without a .itsSimon Glass2016-03-14-0/+1
| | | | | | | | | | | | | | | | | | At present, when generating a FIT, mkimage requires a .its file containing the structure of the FIT and referring to the images to be included. Creating the .its file is a separate step that makes it harder to use FIT. This is not required for creating legacy images. Often the FIT is pretty standard, consisting of an OS image, some device tree files and a single configuration. We can handle this case automatically and avoid needing a .its file at all. To start with, support automatically generate the FIT using a new '-f auto' option. Initially this only supports adding a single image (e.g. a linux kernel) and a single configuration. Signed-off-by: Simon Glass <sjg@chromium.org>
* tools: Add a function to obtain the size of a fileSimon Glass2016-03-14-0/+12
| | | | | | | This will be used in mkimage when working out the required size of the FIT based on the files to be placed into it. Signed-off-by: Simon Glass <sjg@chromium.org>
* mkimage: Allow a FIT to include an image of any typeSimon Glass2016-03-14-0/+1
| | | | | | | | | | At present FIT images are set up by providing a device tree source file which is a file with a .its extension. We want to support automatically creating this file based on the image supplied to mkimage. This means that even though the final file type is always IH_TYPE_FLATDT, the image inside may be something else. Signed-off-by: Simon Glass <sjg@chromium.org>
* mkimage: Allow the original file size to be recordedSimon Glass2015-09-02-0/+1
| | | | | | | | Allow the image handler to store the original input file size so that it can reference it later. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
* mkimage: Set up a file size parameter and keep it updatedSimon Glass2015-07-21-0/+1
| | | | | | | | | | | Some functions called by mkimage would like to know the output file size. Initially this is the same as the input file size, but it may be affected by adding headers, etc. Add this information to the image parameters. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
* Fix musl buildJörg Krause2015-05-08-0/+1
| | | | | | | | | | | This patch fixes cross-compiling U-Boot tools with the musl C library: * including <sys/types.h> is needed for ulong * defining _GNU_SOURCE is needed for loff_t Tested for target at91sam9261ek_dataflash_cs3. Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks> Cc: Tom Rini <trini@konsulko.com>
* tools/imagetool: remove linker scriptAndreas Bießmann2015-02-16-11/+45
| | | | | | | | | | | | | | | | | | Commit a93648d197df48fa46dd55f925ff70468bd81c71 introduced linker generated lists for imagetool which is the base for some host tools (mkimage, dumpimage, et al.). Unfortunately some host tool chains do not support the used type of linker scripts. Therefore this commit broke these host-tools for them, namely FreeBSD and Darwin (OS/X). This commit tries to fix this. In order to have a clean distinction between host and embedded code space we need to introduce our own linker generated list instead of re-using the available linker_lists.h provided functionality. So we copy the implementation used in linux kernel script/mod/file2alias.c which has the very same problem (cause it is a host tool). This code also comes with an abstraction for Mach-O binary format used in Darwin systems. Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com> Cc: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
* dumpimage: replace the term "datafile" by "subimage"Guilherme Maciel Ferreira2015-01-29-8/+9
| | | | Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
* imagetool: replace image registration function by linker_lists featureGuilherme Maciel Ferreira2015-01-29-40/+40
| | | | | | | | | 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-0/+17
| | | | | | | | 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>
* imagetool: move common code to imagetool moduleGuilherme Maciel Ferreira2015-01-29-0/+31
| | | | | | | 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>
* tools: socfpga: Add socfpga preloader signing to mkimageCharles Manning2014-10-06-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Like many platforms, the Altera socfpga platform requires that the preloader be "signed" in a certain way or the built-in boot ROM will not boot the code. This change automatically creates an appropriately signed preloader from an SPL image. The signed image includes a CRC which must, of course, be generated with a CRC generator that the SoCFPGA boot ROM agrees with otherwise the boot ROM will reject the image. Unfortunately the CRC used in this boot ROM is not the same as the Adler CRC in lib/crc32.c. Indeed the Adler code is not technically a CRC but is more correctly described as a checksum. Thus, the appropriate CRC generator is added to lib/ as crc32_alt.c. Signed-off-by: Charles Manning <cdhmanning@gmail.com> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Chin Liang See <clsee@altera.com> Cc: Dinh Nguyen <dinguyen@altera.com> Cc: Albert Aribaud <albert.u.boot@aribaud.net> Cc: Tom Rini <trini@ti.com> Cc: Wolfgang Denk <wd@denx.de> Cc: Pavel Machek <pavel@denx.de> Acked-by: Pavel Machek <pavel@denx.de> V2: - Zap unused constant - Explicitly print an error message in case of error - Rework the hdr_checksum() function to take the *header directly instead of a plan buffer pointer
* includes: move openssl headers to include/u-bootJeroen Hofstee2014-06-19-1/+1
| | | | | | | | | | | | commit 18b06652cd "tools: include u-boot version of sha256.h" unconditionally forced the sha256.h from u-boot to be used for tools instead of the host version. This is fragile though as it will also include the host version. Therefore move it to include/u-boot to join u-boot/md5.h etc which were renamed for the same reason. cc: Simon Glass <sjg@chromium.org> Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
* mkimage: add atmelimageAndreas Bießmann2014-05-27-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new atmelimage converts a machine code BLOB to bootable ROM image. Atmel ROM has no sophisticated image format, it only checks the first 7 ARM vectors. The vectors can contain valid B or LDR opcodes, the 6'th vector contains the image size to load. Additionally the PMECC header can be written by the atmelimage target. The parameters must be given via the -n switch as a coma separated list. For example: mkimage -T atmelimage \ -n usePmecc=1,sectorPerPage=4,sectorSize=512,spareSize=64,eccBits=4,eccOffset=36 \ -d spl/u-boot-spl.bin boot.bin A provided image can be checked for correct header setup. It prints out the PMECC header parameters if it has one and the 6'th interrupt vector content. ---8<--- Image Type: ATMEL ROM-Boot Image with PMECC Header PMECC header ==================== eccOffset: 36 sectorSize: 512 eccBitReq: 4 spareSize: 64 nbSectorPerPage: 4 usePmecc: 1 ==================== 6'th vector has 17044 set --->8--- A SPL binary modified with the atmelimage mkimage target was succesfully booted on a sama5d34ek via MMC and NAND. Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com> Cc: Bo Shen <voice.shen@atmel.com> Cc: Heiko Schocher <hs@denx.de> Tested-by: Bo Shen <voice.shen@atmel.com>
* tools: mkimage: add support for gpimage formatKaricheri, Muralidharan2014-04-17-0/+1
| | | | | | | | | | | This patch add support for gpimage format as a preparatory patch for porting u-boot for keystone2 devices and is based on omapimage format. It re-uses gph header to store the size and loadaddr as done in omapimage.c Signed-off-by: Vitaly Andrianov <vitalya@ti.com> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> Acked-by: Tom Rini <trini@ti.com>
* Add dumpimage, a tool to extract data from U-Boot imagesGuilherme Maciel Ferreira2013-12-13-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+161
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>
generated by cgit v1.1 at 2024-11-02 17:56:50 +0000