| Age | Commit message (Collapse) | Author |
|---|
|
Fixes: 3db711085752 ("crc32: Use the crc.h header for crc functions")
Signed-off-by: Ilya Lukin <4.shket@gmail.com>
|
|
This allows image type print_header() callback to access struct
image_tool_params *params.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
If image file is stored on flash partition then it contains padding, which
is not part of the image itself. Image data size is stored in the image
header. So use image size from the header instead of expecting that total
image file size is size of the header plus size of the image data. This
allows dumpimage to parse image files with padding (e.g. dumped from flash
partition).
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Before reading image header, verify that image size is at least size of
the image header.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
If the user select the image type "flat_dt" a FIT image will be build.
This breaks the legacy use case of putting a Flat Device Tree into a
legacy u-boot image.
Add a new image type "fdt_legacy" to build a legacy u-boot image
with a "flat_dt" type.
Link: https://lore.kernel.org/all/20221028155205.ojw6tcso2fofgnhm@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
|
|
This is not needed and we should avoid typedefs. Use the struct instead
and rename it to indicate that it really is a legacy struct.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Drop inclusion of crc.h in common.h and use the correct header directly
instead.
With this we can drop the conflicting definition in fw_env.h and rely on
the crc.h header, which is already included.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
The default CSF_SIZE defined in Kconfig is too high and SPL cannot
fit into the OCRAM in certain cases.
The CSF cannot achieve 0x2000 length when using RSA 4K key which is
the largest key size supported by HABv4.
According to AN12056 "Encrypted Boot on HABv4 and CAAM Enabled Devices"
it's recommended to pad CSF binary to 0x2000 and append DEK blob to
deploy encrypted boot images.
As the maximum DEK blob size is 0x58 we can reduce CSF_SIZE to 0x2060
which should cover both CSF and DEK blob length.
Update default_image.c and image.c to align with this change and avoid
a U-Boot proper authentication failure in HAB closed devices:
Authenticate image from DDR location 0x877fffc0...
bad magic magic=0x32 length=0x6131 version=0x38
bad length magic=0x32 length=0x6131 version=0x38
bad version magic=0x32 length=0x6131 version=0x38
spl: ERROR: image authentication fail
Fixes: 96d27fb218 (Revert "habv4: tools: Avoid hardcoded CSF size for SPL targets")
Reported-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Breno Lima <breno.lima@nxp.com>
|
|
This reverts commit 62a52f3f85bf33e286632e99f0d39b2c166af0c4.
|
|
Currently it's not possible to authenticate the U-Boot proper of
mx6ul_14x14_evk_defconfig target:
Authenticate image from DDR location 0x877fffc0...
bad magic magic=0x0 length=0x00 version=0x3
bad length magic=0x0 length=0x00 version=0x3
bad version magic=0x0 length=0x00 version=0x3
spl: ERROR: image authentication fail
Commit 0633e134784a ("imx: hab: Increase CSF_SIZE for i.MX6 and
i.MX7 devices") has increased CSF_SIZE to avoid a possible issue
when booting encrypted boot images.
Commit d21bd69b6e95 ("tools: mkimage: add firmware-ivt image type
for HAB verification") is hardcoding the CSF and IVT sizes, the
new CSF size is not being considered and u-boot-ivt.img fails to
boot.
Avoid hardcoded CSF and IVT size to fix this issue.
Signed-off-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
|
|
So we can use imagetool_get_source_date() from callers who do not have
the image tool params struct, just pass in the command name for the error
message.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Reviewed-by: Simon Glass <sjg@chromum.org>
|
|
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
This patch adds a new type IH_OS_TEE. This new OS type will be used for
chain-loading to Linux via a TEE.
With this patch in-place you can generate a bootable OPTEE image like this:
mkimage -A arm -T kernel -O tee -C none -d tee.bin uTee.optee
where "tee.bin" is the input binary prefixed with an OPTEE header and
uTee.optee is the output prefixed with a u-boot wrapper header.
This image type "-T kernel -O tee" is differentiated from the existing
IH_TYPE_TEE "-T tee" in that the IH_TYPE is installed by u-boot (flow
control returns to u-boot) whereas for the new IH_OS_TEE control passes to
the OPTEE firmware and the firmware chainloads onto Linux.
Andrew Davis gave the following ASCII diagram:
IH_OS_TEE: (mkimage -T kernel -O tee)
Non-Secure Secure
BootROM
|
-------------
|
v
SPL
|
v
U-Boot ------>
<----- OP-TEE
|
V
Linux
IH_TYPE_TEE: (mkimage -T tee)
Non-Secure Secure
BootROM
|
-------------
|
v
SPL ------->
<----- OP-TEE
|
v
U-Boot
|
V
Linux
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Suggested-by: Andrew F. Davis <afd@ti.com>
Cc: Harinarayan Bhatta <harinarayan@ti.com>
Cc: Andrew F. Davis <afd@ti.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Cc: Peng Fan <peng.fan@nxp.com>
Link: http://mrvan.github.io/optee-imx6ul
|
|
When we want to use Secure Boot with HAB from SPL over U-Boot.img,
we need to append the IVT to the image and leave space for the CSF.
Images generated as firmware_ivt can directly be signed using the
Freescale code signing tool. For creation of a CSF, mkimage outputs
the correct HAB Blocks for the image.
The changes to the usual firmware image class are quite small,
that is why I implemented that directly into the default_image.
Cc: sbabic@denx.de
v2-Changes: None
Signed-off-by: Sven Ebenfeld <sven.ebenfeld@gmail.com>
Reviewed-by: George McCollister <george.mccollister@gmail.com>
Tested-by: George McCollister <george.mccollister@gmail.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Wolfgang Denk <wd@denx.de>
[trini: Fixup common/cmd_io.c]
Signed-off-by: Tom Rini <trini@ti.com>
|
|
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>
|
|
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>
|
|
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>
|
