Commit 669dfc2e adds libfdt_env.h to HOSTCPPFLAGS. It causes stdio.h
to be included before _GNU_SOURCE is defined in C files. On some old hosts
some prototypes are protected by #ifdef __USE_GNU, which is set when
_GNU_SOURCE is defined.
Signed-off-by: York Sun <yorksun@freescale.com>
Acked-by: Simon Glass <sjg@chromium.org>
when generating the bmp_logo_bitmap, the index is casted
as an uint16_t. So bigger logos as 65535 bytes are converted wrong
Fix this.
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Anatolij Gustschin <agust@denx.de>
Subsequent patches assume that dtc supports various recent features.
These are available in dtc 1.4.0. Validate that dtc is at least that
version.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
adjust instructions for the invocation of Patman's self test: the -t
flag appears to have a different meaning now, refer to the --test option
for the builtin unit test; adjust a directory location and make sure to
run the file which resides in the source directory
Signed-off-by: Gerhard Sittig <gsi@denx.de>
Acked-by: Simon Glass <sjg@chromium.org>
Fix a trivial conflict in arch/arm/dts/exynos5250.dtsi about gpio and
serial.
Conflicts:
arch/arm/dts/exynos5250.dtsi
Signed-off-by: Tom Rini <trini@ti.com>
Remove non portable usage of REG_NOERROR.
BSD (like OS X) variants of regex.h do not declare REG_NOERROR, even GNU
regex(3) does not mention REG_NOERROR, just remove it.
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Acked-by: Jeroen Hofstee <jeroen@myspectrum.nl>
At present mkimage is set up to always build with image signing support.
This means that the SSL libraries (e.g. libssl-dev) are always required.
Adjust things so that mkimage can be built with and without image signing,
controlled by the presence of CONFIG_FIT_SIGNATURE in the board config file.
If CONFIG_FIT_SIGNATURE is not enabled, then mkimage will report a warning
that signing is not supported. If the option is enabled, but libraries are
not available, then a build error similar to this will be shown:
lib/rsa/rsa-sign.c:26:25: fatal error: openssl/rsa.h: No such file or directory
Signed-off-by: Simon Glass <sjg@chromium.org>
While signing images is useful, it does not provide complete protection
against several types of attack. For example, it it possible to create a
FIT with the same signed images, but with the configuration changed such
that a different one is selected (mix and match attack). It is also possible
to substitute a signed image from an older FIT version into a newer FIT
(roll-back attack).
Add support for signing of FIT configurations using the libfdt's region
support.
Please see doc/uImage.FIT/signature.txt for more information.
Signed-off-by: Simon Glass <sjg@chromium.org>
Normally, multiple public keys can be provided and U-Boot is not
required to use all of them for verification. This is because some
images may not be signed, or may be optionally signed.
But we still need a mechanism to determine when a key must be used.
This feature cannot be implemented in the FIT itself, since anyone
could change it to mark a key as optional. The requirement for
key verification must go in with the public keys, in a place that
is protected from modification.
Add a -r option which tells mkimage to mark all keys that it uses
for signing as 'required'.
If some keys are optional and some are required, run mkimage several
times (perhaps with different key directories if some keys are very
secret) using the -F flag to update an existing FIT.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
When signing an image, it is useful to add some details about which tool
or person is authorising the signing. Add a comment field which can take
care of miscellaneous requirements.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
When signing images it is sometimes necessary to sign with different keys
at different times, or make the signer entirely separate from the FIT
creation to avoid needing the private keys to be publicly available in
the system.
Add a -F option so that key signing can be a separate step, and possibly
done multiple times as different keys are avaiable.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
FIT image verification requires public keys. Add a convenient option to
mkimage to write the public keys to an FDT blob when it uses then for
signing an image. This allows us to use:
mkimage -f test.its -K dest.dtb -k keys test.fit
and have the signatures written to test.fit and the corresponding public
keys written to dest.dtb. Then dest.dtb can be used as the control FDT
for U-Boot (CONFIG_OF_CONTROL), thus providing U-Boot with access to the
public keys it needs.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Keys required for signing images will be in a specific directory. Add a
-k option to specify that directory.
Also update the mkimage man page with this information and a clearer list
of available commands.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de> (v1)
RSA provides a public key encryption facility which is ideal for image
signing and verification.
Images are signed using a private key by mkimage. Then at run-time, the
images are verified using a private key.
This implementation uses openssl for the host part (mkimage). To avoid
bringing large libraries into the U-Boot binary, the RSA public key
is encoded using a simple numeric representation in the device tree.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for signing images using a new signature node. The process
is handled by fdt_add_verification_data() which now takes parameters to
provide the keys and related information.
Signed-off-by: Simon Glass <sjg@chromium.org>
This tool provides the facility to decode U-Boot trace data and write out
a text file in Linux ftrace format for use with pytimechart.
Signed-off-by: Simon Glass <sjg@chromium.org>
This adds a userspace linux utility that writes the u-boot image to an mtd
partition on the docg4 nand flash.
A special utility is required to do this because u-boot is partially loaded by
an initial program loader (IPL) that is permanently programmed to the boot
region of the flash. This IPL expects the image to be written in a unique
format. The characteristics of this format can be summarized as follows:
- Flash blocks to be loaded must have a magic number in the oob bytes of the
first page of the block.
- Each page must be written redundantly in the subsequent page.
- The integrated flash controller's "reliable mode" is used, requiring that
alternate 2k regions (4 pages) are skipped when writing.
For these reasons, a u-boot image can not be written using nandwrite from
mtd-utils.
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
Instead of assuming that SYS_TEXT_BASE is 0xFFF80000 calculate the initial
pbl command offset by subtracting the image size from the top of the
24-bit address range. Also increase the size of the memory buffer to
accommodate a larger output image.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Andy Fleming <afleming@freescale.com>
Small conflict over DRA7XX updates and adding SRAM_SCRATCH_SPACE_ADDR
Conflicts:
arch/arm/include/asm/arch-omap5/omap.h
Signed-off-by: Tom Rini <trini@ti.com>
These are not actually used in mkimage itself, but the image code (which
is common with mkimage) does use them. To avoid #ifdefs in the image code
just for mkimage, define dummy version of these here. The compiler will
eliminate the dead code anyway.
A better way to handle this might be to split out more things from common.h
so that mkimage can include them. At present any file that mkimage uses
has to be very careful what headers it includes.
Signed-off-by: Simon Glass <sjg@chromium.org>
The boot logo matching is now done in following way:
- use LOGO_BMP if it is set, or
- use $(BOARD).bmp if it exists in tools/logos, or
- use $(VENDOR).bmp if it exists in tools/logos, or
- use denx.bmp otherwise.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Acked-by: Wolfgang Denk <wd@denx.de>
The fit_handle_file() function is quite long - split out the part that
loads and checks a FIT into its own function. We will use this
function for storing public keys into a destination FDT file.
The error handling is currently a bit repetitive - tidy it.
Signed-off-by: Simon Glass <sjg@chromium.org>
We intend to add signatures to FITs also, so rename this function so that
it is not specific to hashing. Also rename fit_image_set_hashes() and
make it static since it is not used outside this file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
This function doesn't need to be exported, and with verification
we want to use it for setting the 'value' property in any node,
so rename it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
This function has become quite long and much of the body is indented quite
a bit. Move it into a separate function to make it easier to work with.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Marek Vasut <marex@denx.de>
This code is never compiled into U-Boot, so move it into a separate
file in tools/ to avoid the large #ifdef.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
The FIT code is about half the size of the >3000-line image.c. Split this
code into its own file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Move this definition from aisimage.c to mkimage.h so that it is available
more widely.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Marek Vasut <marex@denx.de>
Patman requires python 2.7.4 to run but it doesn't
need to be placed in /usr/bin/python.
Use env to ensure that the interpreter used is
the first one on environment's $PATH on system
with several versions of Python installed.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Tom Rini <trini@ti.com>
Acked-by: Simon Glass <sjg@chromium.org>
Conflicting tags can prevent buildman from building two series which exist
one after the other in a branch. There is no reason not to allow this sort
of workflow with buildman, so ignore conflicting tags in buildman.
Change-Id: I2231d04d8684fe0f8fe77f8ea107e5899a3da5e8
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@ti.com>
The MX53 ROM loads the data from NAND in multiples of pages and
supports maximum page size of 4k. Thus, align the image and header
to 4k to be safe from ROM bugs.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Cc: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tom Rini <trini@ti.com>
Implement BOOT_OFFSET command for imximage. This command is parallel
to current BOOT_FROM command, but allows more flexibility in configuring
arbitrary image header offset. Also add an imximage.cfg with default
offset values into arm/arch/imx-common/ so the board-specific imximage.cfg
can include this file to avoid magic constants.
The syntax of BOOT_OFFSET command is "BOOT_OFFSET <u32 offset>".
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Cc: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tom Rini <trini@ti.com>
Acked-by: Stefano Babic <sbabic@denx.de>
Acked-by: Stefan Roese <sr@denx.de>
The MX23 Boot ROM does blindly load from 2048 offset while the MX28
does parse the BCB header to known where to load the image from. We
move the BCB header to 4 sectors offset so same code can be used by
both SoCs avoiding code duplication.
This idea was given by Marek Vasut <marex@denx.de>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Tested-by: Marek Vasut <marex@denx.de>
The git config parameter log.decorate is quite useful when working with git.
Patman, however can not handle the decorated output when parsing the commit.
To prevent this use the '--no-decorate' switch for git-log.
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Acked-by: Simon Glass <sjg@chromium.org>
When building host utilities, we include libfdt.h from the host, not from
U-Boot. This in turn brings in libfdt_env.h from the host, which can mess
up the types and cause a build failure, depending on the host environment.
To fix this, force inclusion of U-Boot's libfdt_env.h so that the types
are correct.
Another way to fix this is to use -nostdinc and -idirafter to ensure that
system includes are included after U-Boot ones. Unfortunately this means
that U-Boot's errno.h gets included instead of the system one. This in
turn requires a hack to errno.h to redirect things, so all in all the
solution in this patch is probably cleaner.
Signed-off-by: Simon Glass <sjg@chromium.org>
Give more flexibility to define configs that can be interpreted by make, e.g. to
define fallback values of configs like in the example below.
Before this change, the config lines:
#define CONFIG_SPL_MAX_SIZE 2048
#define CONFIG_SPL_PAD_TO CONFIG_SPL_MAX_SIZE
would have been changed in autoconfig.mk into:
CONFIG_SPL_MAX_SIZE=2048
CONFIG_SPL_PAD_TO="CONFIG_SPL_MAX_SIZE"
Hence, a make recipe using as an argument to $(OBJCOPY):
--pad-to=$(CONFIG_SPL_PAD_TO)
would have issued:
--pad-to="CONFIG_SPL_MAX_SIZE"
which means nothing for $(OBJCOPY) and makes it fail.
Thanks to this change, the config lines above are changed in autoconfig.mk into:
CONFIG_SPL_MAX_SIZE=2048
CONFIG_SPL_PAD_TO=$(CONFIG_SPL_MAX_SIZE)
Hence, the make recipe above now issues:
--pad-to=2048
as expected from the defined config.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Reviewed-by: Tom Rini <trini@ti.com>
UBI is a better place for the environment on NAND devices because it
handles wear-leveling and bad blocks.
Gluebi is needed in Linux to access the env as an MTD partition.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
