summaryrefslogtreecommitdiff
path: root/tools/imagetool.h
AgeCommit message (Collapse)Author
2015-02-16tools/imagetool: remove linker scriptAndreas Bießmann
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>
2015-01-29dumpimage: replace the term "datafile" by "subimage"Guilherme Maciel Ferreira
Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
2015-01-29imagetool: replace image registration function by linker_lists featureGuilherme Maciel Ferreira
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>
2015-01-29imagetool: make the image_save_datafile() available to all image typesGuilherme Maciel Ferreira
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-29imagetool: move common code to imagetool moduleGuilherme Maciel Ferreira
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>
2014-10-06tools: socfpga: Add socfpga preloader signing to mkimageCharles Manning
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
2014-06-19includes: move openssl headers to include/u-bootJeroen Hofstee
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>
2014-05-27mkimage: add atmelimageAndreas Bießmann
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>
2014-04-17tools: mkimage: add support for gpimage formatKaricheri, Muralidharan
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>
2013-12-13Add dumpimage, a tool to extract data from U-Boot imagesGuilherme Maciel Ferreira
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-13tools: moved code common to all image tools to a separated module.Guilherme Maciel Ferreira
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>