| aa36c84e | 14-Jul-2016 |
Sumit Garg <sumit.garg@nxp.com> |
powerpc/mpc85xx: T104x: Add nand secure boot target
For mpc85xx SoCs, the core begins execution from address 0xFFFFFFFC.
In non-secure boot scenario from NAND, this address will map to CPC
configure
powerpc/mpc85xx: T104x: Add nand secure boot target
For mpc85xx SoCs, the core begins execution from address 0xFFFFFFFC.
In non-secure boot scenario from NAND, this address will map to CPC
configured as SRAM. But in case of secure boot, this default address
always maps to IBR (Internal Boot ROM).
The IBR code requires that the bootloader(U-boot) must lie in 0 to 3.5G
address space i.e. 0x0 - 0xDFFFFFFF.
For secure boot target from NAND, the text base for SPL is kept same as
non-secure boot target i.e. 0xFFFx_xxxx but the SPL U-boot binary will
be copied to CPC configured as SRAM with address in 0-3.5G(0xBFFC_0000)
As a the virtual and physical address of CPC would be different. The
virtual address 0xFFFx_xxxx needs to be mapped to physical address
0xBFFx_xxxx.
Create a new PBI file to configure CPC as SRAM with address 0xBFFC0000
and update DCFG SCRTACH1 register with location of Header required for
secure boot.
The changes are similar to
commit 467a40dfe35f48d830f01a72617207d03ca85b4d
powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041
While P3041 has a 1MB CPC and does not require SPL. On T104x, CPC
is only 256K and thus SPL framework is used.
The changes are only applicable for SPL U-Boot running out of CPC SRAM
and not the next level U-Boot loaded on DDR.
Reviewed-by: Ruchika Gupta <ruchika.gupta@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Signed-off-by: Sumit Garg <sumit.garg@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
show more ...
|
| d0a6d7ce | 22-Jan-2016 |
Aneesh Bansal <aneesh.bansal@nxp.com> |
secure_boot: enable chain of trust for PowerPC platforms
Chain of Trust is enabled for PowerPC platforms for Secure Boot.
CONFIG_BOARD_LATE_INIT is defined.
In board_late_init(), fsl_setenv_chain_of
secure_boot: enable chain of trust for PowerPC platforms
Chain of Trust is enabled for PowerPC platforms for Secure Boot.
CONFIG_BOARD_LATE_INIT is defined.
In board_late_init(), fsl_setenv_chain_of_trust() is called which
will perform the following:
- If boot mode is non-secure, return (No Change)
- If boot mode is secure, set the following environmet variables:
bootdelay = 0 (To disable Boot Prompt)
bootcmd = CONFIG_CHAIN_BOOT_CMD (Validate and execute Boot script)
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Acked-by: Ruchika Gupta <ruchika.gupta@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
show more ...
|
| bdc22074 | 22-Jan-2016 |
Aneesh Bansal <aneesh.bansal@nxp.com> |
secure_boot: split the secure boot functionality in two parts
There are two phases in Secure Boot
1. ISBC: In BootROM, validate the BootLoader (U-Boot).
2. ESBC: In U-Boot, continuing the Chain of T
secure_boot: split the secure boot functionality in two parts
There are two phases in Secure Boot
1. ISBC: In BootROM, validate the BootLoader (U-Boot).
2. ESBC: In U-Boot, continuing the Chain of Trust by
validating and booting LINUX.
For ESBC phase, there is no difference in SoC's based on ARM or
PowerPC cores.
But the exit conditions after ISBC phase i.e. entry conditions for
U-Boot are different for ARM and PowerPC.
PowerPC:
If Secure Boot is executed, a separate U-Boot target is required
which must be compiled with a diffrent Text Base as compared to
Non-Secure Boot. There are some LAW and TLB settings which are
required specifically for Secure Boot scenario.
ARM:
ARM based SoC's have a fixed memory map and exit conditions from
BootROM are same irrespective of boot mode (Secure or Non-Secure).
Thus the current Secure Boot functionlity has been split into
two parts:
CONFIG_CHAIN_OF_TRUST
This will have the following functionality as part of U-Boot:
1. Enable commands like esbc_validate, esbc_halt
2. Change the environment settings based on bootmode, determined
at run time:
- If bootmode is non-secure, no change
- If bootmode is secure, set the following:
- bootdelay = 0 (Don't give boot prompt)
- bootcmd = Validate and execute the bootscript.
CONFIG_SECURE_BOOT
This is defined only for creating a different compile time target
for secure boot.
Traditionally, both these functionalities were defined under
CONFIG_SECURE_BOOT. This patch is aimed at removing the requirement
for a separate Secure Boot target for ARM based SoC's.
CONFIG_CHAIN_OF_TRUST will be defined and boot mode will be
determine at run time.
Another Security Requirement for running CHAIN_OF_TRUST is that
U-Boot environemnt must not be picked from flash/external memory.
This cannot be done based on bootmode at run time in current U-Boot
architecture. Once this dependency is resolved, no separate
SECURE_BOOT target will be required for ARM based SoC's.
Currently, the only code under CONFIG_SECURE_BOOT for ARM SoC's is
defining CONFIG_ENV_IS_NOWHERE
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Acked-by: Ruchika Gupta <ruchika.gupta@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
show more ...
|