include/plat/arm/common isn't needed by them, and is removed to avoid
dependency on Arm platform code.
Change-Id: Id9fccba33326fd075b3d1029bf1e4b012dfa0483
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Even though at this point plat_crash_console_flush is optional, it will
stop being optional in a following patch.
The console driver of warp7 doesn't support flush, so the implementation
is a placeholder.
TI had ``plat_crash_console_init`` and ``plat_crash_console_putc``, but
they weren't global so they weren't actually used. Also, they were
calling the wrong functions.
imx8_helpers.S only has placeholders for all of the functions.
Change-Id: I8d17bbf37c7dad74e134c61ceb92acb9af497718
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Previous changes in this series made the necessary driver additions and
updates. With those changes in-place we can add the platform.mk and
bl2_el3_setup.c to drive the boot process.
After this commit its possible to build a fully-functional TF-A for the
WaRP7 and boot from the BootROM to the Linux command prompt in secure or
non-secure mode.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
This patch adds a callback into the BootROM's provided High Assurance Boot
(HAB) failsafe function when panicking i.e. the call is done without making
use of stack.
The HAB failsafe function allows a piece of software to call into the
BootROM and place the processor into failsafe mode.
Failsafe mode is a special mode which presents a serial download protocol
interface over UART or USB at the time of writing.
If the board has been set into secure mode, then only a signed binary can
be used to recover the board.
Thus failsafe gives a putatively secure method of performing a secure
recovery over UART or USB.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Ryan Harkin <ryan.harkin@linaro.org>
This patch adds entries to the mem params array for
- BL32
- BL32_EXTRA1
- BL32_EXTRA2
- BL33
- HW_CONFIG_ID
BL32 is marked as bootable to indicate that OPTEE is the thing that should
be booted next.
In our model OPTEE chain-loads onto u-boot so only BL32 is bootable.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
This commit adds support for parsing a FIP pre-loaded by a previous
boot-phase such as u-boot or via ATF reading directly from eMMC.
[bod: squashing several patches from Rui, Jun and bod]
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Jun Nie <jun.nie@linaro.org>
Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
In order to link even a basic image we need to declare
REGISTER_BL_IMAGE_DESCS. This patch declares an empty structure which is
passed to REGISTER_BL_IMAGE_DESCS(). Later patches will add in some
meaningful data.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
In order to enable compile time differences in HAB interaction, we should
split out the definition of the base address of the HAB API.
Some version of the i.MX series have different offsets from the BootROM
base for the HAB callback table.
This patch defines the header into which we will define the i.MX7 specific
offset. The offset of the i.MX7 function-callback table is simultaneously
defined.
Once done, we can latch a set of common function pointer locations from the
offset given here and if necessary change the offset for different
processors without any other code-change.
For now all we support is i.MX7 so the only offset being defined is that
for the i.MX7.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Ryan Harkin <ryan.harkin@linaro.org>
In order to have some common code shared between similar SOCs its pretty
common to have IP blocks reused. In reusing those blocks we frequently need
to map compatible blocks to different addresses depending on the SOC.
This patch adds a basic memory map of the i.MX7 based on the "Cortex-A7
Memory Map" section 2.12 of "i.MX7Solo Applications Processor Reference
Manual, Rev 0.1 08/2016"
In memory map terms the i.MX7S and i.MX7D are identical with the D
variant containing two Cortex-A7 cores plus a Cortex-M core and the S
variant containing one Cortex-A7 and one Cortex-M.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>