This patch adds high assurance boot support (HABv4) image generation to
barebox, currently tested on i.MX6 only.
In order to build a signed barebox image, add a new image target to
images/Makefile.imx as illustrated in the diff below:
- - - a/images/Makefile.imx
+ + + b/images/Makefile.imx
@@ -163,10 +163,14 @@ image-$(CONFIG_MACH_SABRELITE) += barebox-freescale-imx6dl-sabrelite.img
pblx-$(CONFIG_MACH_SABRESD) += start_imx6q_sabresd
CFG_start_imx6q_sabresd.pblx.imximg = $(board)/freescale-mx6-sabresd/flash-header-mx6-sabresd.imxcfg
FILE_barebox-freescale-imx6q-sabresd.img = start_imx6q_sabresd.pblx.imximg
image-$(CONFIG_MACH_SABRESD) += barebox-freescale-imx6q-sabresd.img
+CSF_start_imx6q_sabresd.pblx.imximg = $(havb4_imx6csf)
+FILE_barebox-freescale-imx6q-sabresd-signed.img = start_imx6q_sabresd.pblx.imximg.signed
+image-$(CONFIG_MACH_SABRESD) += barebox-freescale-imx6q-sabresd-signed.img
+
Here the default i.MX6 CSF file $(havb4_imx6csf) is used, it's generated during
build on from the template "scripts/habv4/habv4-imx6.csf.in". You can configure
the paths to the SRK table and certificates via: System Type -> i.MX specific
settings -> HABv4 support.
The proprietary tool "cst" by Freescale tool is expected in the PATH.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The BCTs are build objects and as such are located in the objtree instead of
the srctree. Fix out-of-tree build by defining a variable which refers to the
board directories in the objtree and use it for Tegra.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
A lot of the image makefiles define an equal board variable, which
gives the impression that this variable is unique for this makefile.
As those files aren't freestanding makefiles but get included into a
parent makefile this is not actually true. Attempts to override this
variable will not work reliable as make is picking up a random instance.
Fix this confusion by moving this variable out of the individual makefiles.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
PIE is a form of dynamic linking and thus inherently incompatible
with -static. It worked ok as the current behavior of ld.bfd is
to not respect -static if -pie has been specified.
ld.gold and future versions of ld.bfd will fail to link if both
of those incompatible switches are specified at the same time.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The Freescale MXS SoCs have a multi staged boot process which needs
different images composed out of different binaries. The ROM executes
a so called bootstream which contains multiple executables. The first
one is executed in SRAM and the purpose of this binary is to setup
the internal PMIC and the SDRAM. The second image is usually the
bootloader itself. In case of barebox the bootstream is composed
out of the self extracting barebox image (pblx) and the prepare
stage for setting up the SDRAM.
The bootstream image itself is useful for USB boot, but for booting from
SD cards or NAND a BCB header has to be prepended to the image. In case
of SD boot the image has the .mxssd file extension in barebox.
Since the bootstream images are encrypted they are not suitable for
2nd stage execution. For this purpose the 2nd stage images are generated.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This adds xz decompression support from the kernel. Both compressing
the barebox binary with xz and decompressing xz files on the commandline
is supported.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Allows to build persistent images for the Tegra124
line of SoCs.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Allows to build persistent images for the Tegra30
line of SoCs.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Allows to build persistent images for the Tegra20
line of SoCs.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The pblx is a self extracting barebox binary. This doesn't have
the size of the image correctly set because the linker doesn't
generate it for relocatable binaries.
This currently only works on ARM, but this is the only architecture
supporting multi images anyway. TO make it work on other architectures
fix_size would have to be extended to recognize other images.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The multi image startup process used to have three binaries involved:
- The lowlevel board code to initialize SDRAM
- the uncompressor
- the regular (compressed) barebox binary
Drop the uncompressor and put the uncompress code into the lowlevel
board code binary. This makes the startup process easier.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
To keep things clean I removed all support for the old way to build
images. There is now a single tegra_v7 defconfig which builds both
supported Tegra boards as images.
The new image generation also paves the way for integration of the
tegra-cbootimage tool to produce directly flashable images.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
imximage-y is only needed to add its content to $targets so that
the build system does not rebuild the files because of the files
not being in $targets.
Automatically generate the files and add them to $targets and remove
imximage-y
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This adds the make infrastructure to build multiple SoC or
board specific images from a single barebox binary.
The basic idea is that we no longer have a single pbl, but instead
multiple pbls, one per image if necessary. Each pbl is defined
by its entry function so that each pbl can do exactly what a given
board needs. Additionally the pbls together with a self extracting
barebox binary can be encapsulated in specific image formats.
squashed in build fixes from Lucas Stach for make version >= 3.82:
Split Multimage Makefile rule in explicit and implicit parts
Fixes build with make version >=3.82
Frome the make 3.82 NEWS file:
* WARNING: Backward-incompatibility!
In previous versions of make it was acceptable to list one or more explicit
targets followed by one or more pattern targets in the same rule and it
worked "as expected". However, this was not documented as acceptable and if
you listed any explicit targets AFTER the pattern targets, the entire rule
would be mis-parsed. This release removes this ability completely: make
will generate an error message if you mix explicit and pattern targets in
the same rule.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Marc Kleine-Budde
Lucas Stach
Sascha Hauer
Jean-Christophe PLAGNIOL-VILLARD