u-boot/arch/powerpc/include/asm/fsl_secure_boot.h

142 lines
4.2 KiB
C
Raw Normal View History

/* SPDX-License-Identifier: GPL-2.0+ */
/*
* Copyright 2010-2011 Freescale Semiconductor, Inc.
*/
#ifndef __FSL_SECURE_BOOT_H
#define __FSL_SECURE_BOOT_H
#include <asm/config_mpc85xx.h>
#ifdef CONFIG_SECURE_BOOT
#if defined(CONFIG_FSL_CORENET)
#define CONFIG_SYS_PBI_FLASH_BASE 0xc0000000
#elif defined(CONFIG_TARGET_BSC9132QDS)
#define CONFIG_SYS_PBI_FLASH_BASE 0xc8000000
#elif defined(CONFIG_TARGET_C29XPCIE)
#define CONFIG_SYS_PBI_FLASH_BASE 0xcc000000
#else
#define CONFIG_SYS_PBI_FLASH_BASE 0xce000000
#endif
#define CONFIG_SYS_PBI_FLASH_WINDOW 0xcff80000
#if defined(CONFIG_TARGET_B4860QDS) || \
defined(CONFIG_TARGET_B4420QDS) || \
defined(CONFIG_TARGET_T4160QDS) || \
defined(CONFIG_TARGET_T4240QDS) || \
defined(CONFIG_TARGET_T2080QDS) || \
defined(CONFIG_TARGET_T2080RDB) || \
defined(CONFIG_TARGET_T1040QDS) || \
defined(CONFIG_TARGET_T1040RDB) || \
defined(CONFIG_TARGET_T1040D4RDB) || \
defined(CONFIG_TARGET_T1042RDB) || \
defined(CONFIG_TARGET_T1042D4RDB) || \
defined(CONFIG_TARGET_T1042RDB_PI) || \
defined(CONFIG_ARCH_T1023) || \
defined(CONFIG_ARCH_T1024)
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>
2016-07-14 16:27:52 +00:00
#ifndef CONFIG_SYS_RAMBOOT
#define CONFIG_SYS_CPC_REINIT_F
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>
2016-07-14 16:27:52 +00:00
#endif
#define CONFIG_KEY_REVOCATION
#undef CONFIG_SYS_INIT_L3_ADDR
#define CONFIG_SYS_INIT_L3_ADDR 0xbff00000
#endif
#if defined(CONFIG_RAMBOOT_PBL)
#undef CONFIG_SYS_INIT_L3_ADDR
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>
2016-07-14 16:27:52 +00:00
#ifdef CONFIG_SYS_INIT_L3_VADDR
#define CONFIG_SYS_INIT_L3_ADDR \
(CONFIG_SYS_INIT_L3_VADDR & ~0xFFF00000) | \
0xbff00000
#else
#define CONFIG_SYS_INIT_L3_ADDR 0xbff00000
#endif
#endif
#if defined(CONFIG_TARGET_C29XPCIE)
#define CONFIG_KEY_REVOCATION
#endif
#if defined(CONFIG_ARCH_P3041) || \
defined(CONFIG_ARCH_P4080) || \
defined(CONFIG_ARCH_P5020) || \
defined(CONFIG_ARCH_P5040) || \
defined(CONFIG_ARCH_P2041)
#define CONFIG_FSL_TRUST_ARCH_v1
#endif
#if defined(CONFIG_FSL_CORENET) && !defined(CONFIG_SYS_RAMBOOT)
/* The key used for verification of next level images
* is picked up from an Extension Table which has
* been verified by the ISBC (Internal Secure boot Code)
* in boot ROM of the SoC.
* The feature is only applicable in case of NOR boot and is
* not applicable in case of RAMBOOT (NAND, SD, SPI).
*/
#define CONFIG_FSL_ISBC_KEY_EXT
#endif
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>
2016-01-22 11:07:24 +00:00
#endif /* #ifdef CONFIG_SECURE_BOOT */
#ifdef CONFIG_CHAIN_OF_TRUST
#ifdef CONFIG_SPL_BUILD
/*
* PPAACT and SPAACT table for PAMU must be placed on DDR after DDR init
* due to space crunch on CPC and thus malloc will not work.
*/
#define CONFIG_SPL_PPAACT_ADDR 0x2e000000
#define CONFIG_SPL_SPAACT_ADDR 0x2f000000
#define CONFIG_SPL_JR0_LIODN_S 454
#define CONFIG_SPL_JR0_LIODN_NS 458
/*
* Define the key hash for U-Boot here if public/private key pair used to
* sign U-boot are different from the SRK hash put in the fuse
* Example of defining KEY_HASH is
* #define CONFIG_SPL_UBOOT_KEY_HASH \
* "41066b564c6ffcef40ccbc1e0a5d0d519604000c785d97bbefd25e4d288d1c8b"
* else leave it defined as NULL
*/
#define CONFIG_SPL_UBOOT_KEY_HASH NULL
#endif /* ifdef CONFIG_SPL_BUILD */
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>
2016-01-22 11:07:24 +00:00
#define CONFIG_FSL_SEC_MON
#ifndef CONFIG_SPL_BUILD
/*
* fsl_setenv_chain_of_trust() must be called from
* board_late_init()
*/
/* If Boot Script is not on NOR and is required to be copied on RAM */
#ifdef CONFIG_BOOTSCRIPT_COPY_RAM
#define CONFIG_BS_HDR_ADDR_RAM 0x00010000
#define CONFIG_BS_HDR_ADDR_DEVICE 0x00800000
#define CONFIG_BS_HDR_SIZE 0x00002000
#define CONFIG_BS_ADDR_RAM 0x00012000
#define CONFIG_BS_ADDR_DEVICE 0x00802000
#define CONFIG_BS_SIZE 0x00001000
#define CONFIG_BOOTSCRIPT_HDR_ADDR CONFIG_BS_HDR_ADDR_RAM
#else
/* The bootscript header address is different for B4860 because the NOR
* mapping is different on B4 due to reduced NOR size.
*/
#if defined(CONFIG_TARGET_B4860QDS) || defined(CONFIG_TARGET_B4420QDS)
#define CONFIG_BOOTSCRIPT_HDR_ADDR 0xecc00000
#elif defined(CONFIG_FSL_CORENET)
#define CONFIG_BOOTSCRIPT_HDR_ADDR 0xe8e00000
#elif defined(CONFIG_TARGET_BSC9132QDS)
#define CONFIG_BOOTSCRIPT_HDR_ADDR 0x88020000
#elif defined(CONFIG_TARGET_C29XPCIE)
#define CONFIG_BOOTSCRIPT_HDR_ADDR 0xec020000
#else
#define CONFIG_BOOTSCRIPT_HDR_ADDR 0xee020000
#endif
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>
2016-01-22 11:07:24 +00:00
#endif /* #ifdef CONFIG_BOOTSCRIPT_COPY_RAM */
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>
2016-01-22 11:07:24 +00:00
#include <config_fsl_chain_trust.h>
#endif /* #ifndef CONFIG_SPL_BUILD */
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>
2016-01-22 11:07:24 +00:00
#endif /* #ifdef CONFIG_CHAIN_OF_TRUST */
#endif