Add a generic function which can be used to compute the CRC32 value of
a region of RAM.
Signed-off-by: Liam Beguin <liambeguin@gmail.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
As opposed to PATH, HOSTNAME is not appended to PYTHONPATH
automatically. Lets add it to the examples to make it more
obvious to new users.
Signed-off-by: Liam Beguin <liambeguin@gmail.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Fix a minor typo causing vim (and possibly other) to get confused with
coloring.
Signed-off-by: Liam Beguin <liambeguin@gmail.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Make sure 0x00 is a valid address to read to. If `addr` is 0x00 then
map_physmem() will return 0 which should be a valid address.
Signed-off-by: Liam Beguin <liambeguin@gmail.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Make sure the user is notified instead of silently returning an error.
Signed-off-by: Liam Beguin <liambeguin@gmail.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
The kwboot tool for Marvell devices isn't currently being built even if
HOST_TOOLS_ALL is set. It doesn't appear to depend on any CONFIG_
options, so it seems appropriate to enable building it here.
Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>
If we check an index against array bounds, we should do so before
accessing the array and not afterwards.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Fix NOR, SD and QSPI fallback option in case of secure boot failure.
Signed-off-by: Vinitha V Pillai <vinitha.pillai@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
IFC-NOR and QSPI-NOR pins are multiplexed on SoC, so they cannot be
accessed simultaneously. IFC-NOR can be accessed along with SD-BOOT.
Ls1088aqds_sdcard_ifc_defconfig is default config for SD boot and
IFC-NOR to be used as flash. This allows writing to IFC-NOR flash.
QSPI and DSPI cannot be accessed in this defconfig.
IFC-NOR image is generated using ls1088aqds_defconfig.
Signed-off-by: Ashish Kumar <Ashish.Kumar@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
This function is required for enabling access to early i2c function
for correct usage of QIXIS_READ and QIXIS_WRITE.
Signed-off-by: Ashish Kumar <Ashish.Kumar@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
get_board_ddr_clk(), get_board_sys_clk() and if_board_diff_clk() is
now available for SPL build.
Signed-off-by: Ashish Kumar <Ashish.Kumar@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.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
CONFIG_OPTEE_LOAD_ADDR is used to tell u-boot where to load the OPTEE
binary into memory prior to handing off control to OPTEE.
We need to pull this value out of u-boot in order to produce an IMX IVT/CSF
signed pair for the purposes of secure boot. The best way to do that is to
have CONFIG_OPTEE_LOAD_ADDR appear in u-boot.cfg.
Adding new CONFIG entires to u-boot should be kconfig driven so this patch
does just that.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Ryan Harkin <ryan.harkin@linaro.org>
OPTEE is currently linked to a specific area of memory called the TrustZone
DRAM. This patch adds a CONFIG entry for the default address of TrustZone
DRAM that a board-port can over-ride. The region that U-Boot sets aside for
the OPTEE run-time should be verified before attempting to hand off to the
OPTEE run-time. Each board-port should carefully ensure that the TZDRAM
address specified in the OPTEE build and the TZDRAM address specified in
U-Boot match-up.
Further patches will use TZDRAM address with other defines and variables to
carry out a degree of automated verification in U-Boot prior to trying to
boot an OPTEE image.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
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>
OPTEE is currently linked to a specific area of memory called the TrustZone
DRAM. This patch adds a CONFIG entry for the default size of TrustZone DRAM
that a board-port can over-ride. The region that U-Boot sets aside for the
OPTEE run-time should be verified before attempting to hand off to the
OPTEE run-time. Each board-port should carefully ensure that the TZDRAM
size specified in the OPTEE build and the TZDRAM size specified in U-Boot
match-up.
Further patches will use TZDRAM size with other defines and variables to
carry out a degree of automated verification in U-Boot prior to trying to
boot an OPTEE image.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
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>
Tested-by: Peng Fan <peng.fan@nxp.com>