| Age | Commit message (Collapse) | Author |
|---|
|
In order to sign images with the IMX code-signing-tool (CST) we need to
know the load address of a given image. The best way to derive this load
address is to make it into a define - so that u-boot.cfg contains the
address - which we can then parse when generating the IMX CST headers.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Ryan Harkin <ryan.harkin@linaro.org>
Tested-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
|
|
This patch enables CONFIG_BOOTM_TEE. Once enabled its possible to
chain-load Linux through OPTEE.
Loading kernel to 0x80800000
=> run loadimage
Load FDT to 0x83000000
=> run loadfdt
Load OPTEE to 0x84000000
=> fatload mmc 0:5 0x84000000 /lib/firmware/uTee.optee
Then chain-load to the kernel via OPTEE
=> bootm 0x84000000 - 0x83000000
Image Name:
Image Type: ARM Trusted Execution Environment Kernel Image (uncompressed)
Data Size: 249844 Bytes = 244 KiB
Load Address: 9dffffe4
Entry Point: 9e000000
Verifying Checksum ... OK
Loading Kernel Image ... OK
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Tested-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
|
|
Various function associated with booting the WaRP7 in High Assurance Boot
(HAB) mode are enabled by switching on CONFIG_SECURE_BOOT.
This patch enables CONFIG_SECURE_BOOT for the WaRP7 defconfig.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Tested-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
|
|
In order to sign images with the IMX code-signing-tool (CST) we need to
know the load address of a given image. The best way to derive this load
address is to make it into a define - so that u-boot.cfg contains the
address - which we can then parse when generating the IMX CST headers.
This patch makes the OPTEE_LOAD_ADDR available via u-boot.cfg for further
parsing by external tools.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Ryan Harkin <ryan.harkin@linaro.org>
Tested-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
|
|
Right now a region of 0x300000 bytes is allocated at the end of DRAM for
the purposes of loading an OPTEE firmware inside of it. This patch adds the
printout of the relevant address ranges.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Tested-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
|
|
Subtracts CONFIG_OPTEE_TZDRAM_SIZE from the available DRAM size.
On WaRP7 we simply define the OPTEE region as from the maximum DRAM address
minus CONFIG_OPTEE_TZDRAM_SIZE bytes.
Note the OPTEE boot process will itself subtract the DRAM region it lives
in from the memory map passed to Linux.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Tested-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
|
|
Requires setting CONFIG_OPTEE=y and setting an OPTEE TrustZone DRAM base in
include/configs/warp7.h.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Tested-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
|
|
This patch adds an environment variable called "hab_enabled" which gets set
to a boolean status indicating whether HAB is enabled or not.
Subsequent patches can use this environment variable to determine if its
necessary to run a given binary through the hab_auth_img console command.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Tested-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
|
|
In order to correctly produce an image with a IVT/DCD header we need to
define a CSF in imximage.cfg. We just use the mx7 default here.
All we have to do with this option switched on is "make u-boot.imx" and we
then will get
- u-boot.imx
- u-boot.imx.log
The log file is really important because it gives the addresses for the HAB
that we will require to sign the u-boot image using the CST. Since the
addresses can change this logfile is a critical output.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Tested-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
|
|
This patch adds BOOTROM_IVT_HDR_OFFSET at 0xC00. The BootROM expects to
find the IVT header at a particular offset in an i.MX image.
Defining the expected offset of the IVT header in the first-stage BootROM
image format is of use of later stage authentication routines where those
routines continue to follow the first-stage authentication layout.
This patch defines the first stage offset which later patch make use of.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc: Utkarsh Gupta <utkarsh.gupta@nxp.com>
Cc: Breno Lima <breno.lima@nxp.com>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Tested-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
|
|
commit 8519c9c98ad6 ("tools/imximage: use 0x prefix in HAB Blocks line")
adds an 0x prefix to each HAB Block number to make it easier for host tools
to process the HAB Block output, however it neglects to apply the same
prefix to the DCD Blocks directive. You need the DCD Blocks directive if
you are making a u-boot recovery image which the BootROM will accept via
the USB upload utility.
This disparity results in a fruity output like this with HAB Blocks
prefixed but DCD Blocks not prefixed - which is pretty inconsistent.
This patch fixes the difference assuming the original commit was a
legitimate change.
Old:
Image Type: Freescale IMX Boot Image
Image Ver: 2 (i.MX53/6/7 compatible)
Mode: DCD
Data Size: 430080 Bytes = 420.00 KiB = 0.41 MiB
Load Address: 877ff420
Entry Point: 87800000
HAB Blocks: 0x877ff400 0x00000000 0x00066c00
DCD Blocks: 00910000 0000002c 000001d4
New:
Image Type: Freescale IMX Boot Image
Image Ver: 2 (i.MX53/6/7 compatible)
Mode: DCD
Data Size: 430080 Bytes = 420.00 KiB = 0.41 MiB
Load Address: 877ff420
Entry Point: 87800000
HAB Blocks: 0x877ff400 0x00000000 0x00066c00
DCD Blocks: 0x00910000 0x0000002c 0x000001d4
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Breno Lima <breno.lima@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
|
|
This enable generic file system commands (load, ls).
Signed-off-by: Pierre-Jean TEXIER <texier.pj2@gmail.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Acked-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
|
|
use the generic filesystem command 'load' rather
than 'fatload' to avoid per-fs specific commands.
Signed-off-by: Pierre-Jean TEXIER <texier.pj2@gmail.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Acked-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
|
|
|
|
With clang-4.0 and later we see:
warning: logical not is only applied to the left hand side of this bitwise
operator [-Wlogical-not-parentheses]
if ((!gd->flags & GD_FLG_RELOC))
^ ~
And while the compiler suggests adding parenthesis around gd->flags, a
reading of the code says that we want to know when GD_FLG_RELOC is not
set and then return.
Cc: Simon Glass <sjg@chromium.org>
Cc: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Patch queue for efi - 2018-04-23
Some last minute fixes for 2018.05. Most of them are minor fixes. On
top we have some functional improvements for the device path logic
which should also help us be more compatible.
|
|
Staticize the function since it's only used in mmc.c .
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Tom Rini <trini@konsulko.com>
|
|
Provide unit tests for the EFI_DEVICE_PATH_UTILITIES_PROTOCOL.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
|
|
The missing services of the EFI_DEVICE_PATH_UTILITIES_PROTOCOL are
implemented.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
|
|
Device paths may consist of multiple instances. Up to now we have only
considered the size of the first instance. For the services of the
EFI_DEVICE_PATH_UTILITIES_PROTOCOL in most cases the total length of the
device path is relevant.
So let's rename efi_dp_size() to efi_dp_instance_size() and create a new
function efi_dp_size() that calculates the total device path length.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
|
|
efi_dp_size() is meant to return the device path length without the end
node.
The length of a device path containing only an end node was incorrectly
reported as 4.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
|
|
The logic of the AppendDevicePath service of the
EFI_DEVICE_PATH_UTILITIES_PROTOCOL is incorrectly implemented:
* if both paths are NULL an end node has to be returned
* if both paths are not NULL the end node of the second device path has to
be kept
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
|
|
Implement the CreateDeviceNode service of the device path utility protocol.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
|
|
%s/provice/provide/
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
|
|
Executing a test after failed setup may lead to unexpected behavior like
an illegal memory access. So after a setup failure we should skip to
teardown.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
|
|
We do not support bootefi booting ARMv7 in non-secure mode.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
|
|
According to the documentation the EFI log category is called LOGC_EFI.
All other categories start with LOGC_. So let's fix it.
Fixes: 1973b381a1b3 ("log: add category LOGC_EFI")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
|
|
|
|
Currently, the address region, 0xf8000 - 0x100000, is used for SPL
stack for the 32bit SoCs. Because the U-Boot proper image starts
from 0x70000, the maximum size of the U-Boot proper image is 544KB
(0x70000 - 0xf8000) for the NOR boot mode. Now uniphier_v7_defconfig
is almost hitting this size limit. Changing CONFIG_SPL_STACK can
raise the size limit with less impact. With this, the size limit
will increase to 576KB (0x70000 - 0x100000). If we need to increase
it even more, we would be able to change CONFIG_SYS_UBOOT_BASE at the
cost of the flashing command changes.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Some boards support an SD card and an eMMC device at the same time.
Since both belong to 'mmc', they are identified by a device number.
When the device number of the eMMC is 1 instead 0, "mmc dev" command
must be performed to switch the target device before flashing images.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
The last clock consumer in SPL, SD/eMMC driver, gave up using the
clock driver. The clock driver is only used in U-Boot proper.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Now that the SD/eMMC driver does not use the clock driver in SPL,
remove u-boot,dm-pre-reloc properties to let the fdtgrep tool drop
the unnecessary nodes.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
The size of SPL is hitting the limit (64KB) for uniphier_v7_defconfig.
When booting from SD/eMMC, obviously its clock has been properly set up
by the boot ROM. Acutually, no need to re-initialize the clock in SPL.
Using a clock driver would generalize the SoC specific code, but
solving the memory footprint problem would win.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
I need to differentiate the clock handling for uniphier-sd. Move it
to each driver's probe function from the tmio common code so that
renesas-sdhi will not be affected.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
With the recent changes, the size of the U-Boot proper image for
uniphier_v7_defconfig exceeded the current limit, 512KB, then SPL
fails to load the whole of the U-Boot proper. Increase the size.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Xilinx fixes for v2018.05-rc3
- Fix nand initialization
- Runtime ddr detection for static DDR setting
- Enable rewriting env locations
- Sync defconfig for zc770 xm011
- Remove useless ioremap in watchdog
- Check return value from soc_clk_dump()
|
|
The Odroid C2 fails to read from mmc with U-Boot v2018.03.
The change avoids a division by zero.
The fix was suggested by Jaehoon in
https://lists.denx.de/pipermail/u-boot/2018-January/318577.html
Reported-by: Vagrant Cascadian <vagrant@debian.org>
Suggested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Vagrant Cascadian <vagrant@debian.org>
|
|
In case of error in soc_clk_dump function are returned different values
then CMD return values (-1, 0, 1).
For example:
ZynqMP> clk dump
exit not allowed from main input shel
The patch is checking all negative return values and return
CMD_RET_FAILURE which is proper reaction for these cases.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
|
|
There is no need to call ioremap. Also reg pointer is completely unused
in the driver.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
|
|
x8 and x16 configurations should be in sync.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
|
|
Boards have an option to rewrite variable locations in their own board
files. This is necessary for qspi and nand configurations where boot
image can be bigger then 896k(current limit).
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
|
|
When static memory configuration is used U-Boot has capability to detect
memory size in setup range. Enable this feature for static
configuration.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
|
|
There is no need to use zynq name as SYS_BOARD for all boards.
The patch is adding an option to change it.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
|
|
CONFIG_NAND_ZYNQ selects CONFIG_SYS_NAND_SELF_INIT, so the
driver doesn't have to play any ifdef game.
Also, we can mark zynq_nand_init() as static and get rid
of the mach-specific nand.h header.
This is really a revert of:
"mtd: zynq: nand: Move board_nand_init() function to board.c"
(sha1: 310995d9f91ae56082b49be06fe8c3d01424f8f6)
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
|
|
This driver is currently broken, refusing to initialize properly.
The reason is that get_nand_dev_by_index() was being called before
nand_register(), thus returning a pointer into uninitialized memory.
In other words, the struct mtd_info used by the driver is total junk.
Fix it by getting the correct struct mtd_info, via nand_to_mtd()
on the driver's struct nand_chip.
Tested on a custom board, where the CPU is halted without this patch.
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
|
|
|
|
|
|
The disabled clk API returns -ENOSYS unlike the reset API returning -ENOTSUPP.
Fixes: ca7fdc8b1267 ("usb: host: Add simple of glue driver for DWC3 USB Controllers integration")
Reported-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
|
|
Add the compatibility with "ti,dwc3" and enable it by default if DM_USB
is enabled.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
|
|
This simple glue layer does not require CONFIG_MISC, but it does require
CONFIG_DM_USB.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
|
