powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
PATCH v4 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
Changes:
1. L2 cache is being invalidated by Boot ROM code for e6500 core. So removing the invalidation from start.S
2. Clear the LAW and corresponding configuration for CPC. Boot ROM code uses it as hosekeeping area.
3. For Secure boot, CPC is configured as SRAM and used as house keeping area. This configuration is to be disabled once in uboot. Earlier this disabling of CPC as SRAM was happening in cpu_init_r. As a result cache invalidation function was getting skipped in case CPC is configured as SRAM.This was causing random crashes.
--- README | 4 ++++ arch/powerpc/cpu/mpc85xx/cpu_init.c | 27 ++++++++++++++++++++++----- arch/powerpc/cpu/mpc85xx/start.S | 3 ++- arch/powerpc/include/asm/fsl_secure_boot.h | 6 ++++++ boards.cfg | 1 + 5 files changed, 35 insertions(+), 6 deletions(-)
Changes from v3:
Renamed the macro to indicate CPC configured as SRAM at U-boot entry to CONFIG_SYS_CPC_SRAM
README +4 -0
@@ -427,6 +427,10 @@ The following options need to be configured: In this mode, a single differential clock is used to supply clocks to the sysclock, ddrclock and usbclock. + CONFIG_SYS_CPC_SRAM + This CONFIG is defined when the SPC is configured as SRAM at the + time of U-boot entry. + - Generic CPU options: CONFIG_SYS_BIG_ENDIAN, CONFIG_SYS_LITTLE_ENDIAN
arch/powerpc/cpu/mpc85xx/cpu_init.c +22 -5
@@ -125,17 +125,14 @@ void config_8560_ioports (volatile ccsr_cpm_t * cpm)#endif #ifdef CONFIG_SYS_FSL_CPC -static void enable_cpc (void ) +#if defined(CONFIG_RAMBOOT_PBL) || defined(CONFIG_SYS_CPC_SRAM) +static void disable_cpc_sram(void) { int i; -u32 size =0 ; cpc_corenet_t *cpc = (cpc_corenet_t *)CONFIG_SYS_FSL_CPC_ADDR; for (i = 0; i < CONFIG_SYS_NUM_CPC; i++, cpc++) { -u32 cpccfg0 =in_be32 (&cpc->cpccfg0); - size +=CPC_CFG0_SZ_K (cpccfg0); -#ifdef CONFIG_RAMBOOT_PBL if (in_be32(&cpc->cpcsrcr0) & CPC_SRCR0_SRAMEN) { /* find and disable LAW of SRAM */ struct law_entry law = find_law(CONFIG_SYS_INIT_L3_ADDR);
@@ -150,8 +147,21 @@ static void enable_cpc(void)out_be32 (&cpc->cpccsr0,0 ); out_be32(&cpc->cpcsrcr0, 0); } + } +}#endif +static void enable_cpc (void ) +{ +int i; +u32 size =0 ; + +cpc_corenet_t *cpc = (cpc_corenet_t *)CONFIG_SYS_FSL_CPC_ADDR ; + +for (i =0 ; i <CONFIG_SYS_NUM_CPC ; i++, cpc++) { +u32 cpccfg0 =in_be32 (&cpc->cpccfg0); + size +=CPC_CFG0_SZ_K (cpccfg0); +#ifdef CONFIG_SYS_FSL_ERRATUM_CPC_A002 setbits_be32 (&cpc->cpchdbcr0,CPC_HDBCR0_TAG_ECC_SCRUB_DIS );#endif
@@ -250,6 +260,10 @@ void cpu_init_f (void) law =find_law (CONFIG_SYS_PBI_FLASH_BASE );if (law.index !=-1 )disable_law (law.index); + +#if defined(CONFIG_SYS_CPC_SRAM ) +disable_cpc_sram (); +#endif #endif #ifdef CONFIG_CPM2
@@ -550,6 +564,9 @@ skip_l2:puts ("disabled\n" );#endif +#if defined(CONFIG_RAMBOOT_PBL ) +disable_cpc_sram (); +#endif enable_cpc ();#ifndef CONFIG_SYS_FSL_NO_SERDES
arch/powerpc/cpu/mpc85xx/start.S +2 -1
@@ -115,7 +115,8 @@ _start_e500: #endif -#if defined(CONFIG_SECURE_BOOT) && defined(CONFIG_E500MC) +#if defined(CONFIG_SECURE_BOOT) && defined(CONFIG_E500MC) && \ + !defined(CONFIG_E6500) /* ISBC uses L2 as stack. * Disable L2 cache here so that u-boot can enable it later * as part of it's normal flow
arch/powerpc/include/asm/fsl_secure_boot.h +6 -0
@@ -15,5 +15,11 @@#endif #define CONFIG_SYS_PBI_FLASH_WINDOW 0xcff80000 +#if defined(CONFIG_B4860QDS ) +#define CONFIG_SYS_CPC_SRAM +#undef CONFIG_SYS_INIT_L3_ADDR +#define CONFIG_SYS_INIT_L3_ADDR 0xbff00000 +#endif +#endif #endif
boards.cfg +1 -0
@@ -782,6 +782,7 @@ Active powerpc mpc85xx - freescale b4860qds Active powerpc mpc85xx - freescale b4860qds B4420QDS_NAND B4860QDS:PPC_B4420,RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF40000 - Active powerpc mpc85xx - freescale b4860qds B4420QDS_SPIFLASH B4860QDS:PPC_B4420,RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF40000 - Active powerpc mpc85xx - freescale b4860qds B4860QDS B4860QDS:PPC_B4860 - +Active powerpc mpc85xx - freescale b4860qds B4860QDS_SECURE_BOOT B4860QDS:PPC_B4860,SECURE_BOOT Aneesh Bansal <[email protected]> Active powerpc mpc85xx - freescale b4860qds B4860QDS_NAND B4860QDS:PPC_B4860,RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF40000 - Active powerpc mpc85xx - freescale b4860qds B4860QDS_SPIFLASH B4860QDS:PPC_B4860,RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF40000 - Active powerpc mpc85xx - freescale b4860qds B4860QDS_SRIO_PCIE_BOOT B4860QDS:PPC_B4860,SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF40000 -
Signature · 1 line
1.8.1.4
PATCH v4 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
Quoted 20 lines · Aneesh Bansal
Changes:
1. L2 cache is being invalidated by Boot ROM code for e6500 core. So removing the invalidation fromstart.S
2. Clear the LAW and corresponding configuration for CPC. Boot ROM code uses it as hosekeeping area.
3. For Secure boot, CPC is configured as SRAM and used as house keeping area. This configuration is to be disabled once in uboot. Earlier this disabling of CPC as SRAM was happening incpu_init_r. As a result cache invalidation function was getting skipped in case CPC is configured as SRAM.This was causing random crashes.Signed-off-by Aneesh Bansal <[email protected]>--- README | 4 ++++ arch/powerpc/cpu/mpc85xx/cpu_init.c | 27 ++++++++++++++++++++++----- arch/powerpc/cpu/mpc85xx/start.S | 3 ++- arch/powerpc/include/asm/fsl_secure_boot.h | 6 ++++++ boards.cfg | 1 + 5 files changed, 35 insertions(+), 6 deletions(-)
Quoted 3 lines
Changes from v3:
Renamed the macro to indicate CPC configured as SRAM at U-boot entry toCONFIG_SYS_CPC_SRAM
Aneesh,
I understand you are trying to address the comment about when CPC needs to be disabled before initializing as normal CPC. But introducing CONFIG_SYS_CPC_SRAM seems even more confusing. Let's take one step back.
CPC as SRAM can be used for many reasons. There is only one reason we should keep it as SRAM, i.e. u-boot is indeed using SRAM as its final destination. For all other usages, we can safely reconfigure it as normal CPC after u-boot relocates itself into DDR. If u-boot's final destination is SRAM, it is a RAMBOOT. Can we use this condition to deal with CPC?
Do you see the need to disable CPC before relocation? You are doing so in this patch. Does the temporary LAW or address conflict with u-boot?
York
PATCH v4 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
Quoted 31 lines · York Sun
Quoted 20 lines · Aneesh Bansal
Changes:
1. L2 cache is being invalidated by Boot ROM code for e6500 core. So removing the invalidation fromstart.S
2. Clear the LAW and corresponding configuration for CPC. Boot ROM code uses it as hosekeeping area.
3. For Secure boot, CPC is configured as SRAM and used as house keeping area. This configuration is to be disabled once in uboot. Earlier this disabling of CPC as SRAM was happening incpu_init_r. As a result cache invalidation function was getting skipped in case CPC is configured as SRAM.This was causing random crashes.Signed-off-by Aneesh Bansal <[email protected]>--- README | 4 ++++ arch/powerpc/cpu/mpc85xx/cpu_init.c | 27 ++++++++++++++++++++++----- arch/powerpc/cpu/mpc85xx/start.S | 3 ++- arch/powerpc/include/asm/fsl_secure_boot.h | 6 ++++++ boards.cfg | 1 + 5 files changed, 35 insertions(+), 6 deletions(-)Quoted 3 lines
Changes from v3:
Renamed the macro to indicate CPC configured as SRAM at U-boot entry toCONFIG_SYS_CPC_SRAMAneesh,
I understand you are trying to address the comment about when CPC needs to be disabled before initializing as normal CPC. But introducing
CONFIG_SYS_CPC_SRAMseems even more confusing. Let's take one step back.
Quoted 5 lines
CPC as SRAM can be used for many reasons. There is only one reason we should keep it as SRAM, i.e. u-boot is indeed using SRAM as its final destination. For all other usages, we can safely reconfigure it as normal CPC after u-boot relocates itself into DDR. If u-boot's final destination is SRAM, it is a RAMBOOT. Can we use this condition to deal with CPC?
Even if CPC is the final destination, shouldn't RAMBOOT imply that DDR has been initialized?
-Scott
PATCH v4 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
Quoted 32 lines · Scott Wood
Quoted 31 lines · York Sun
Quoted 20 lines · Aneesh Bansal
Changes:
1. L2 cache is being invalidated by Boot ROM code for e6500 core. So removing the invalidation fromstart.S
2. Clear the LAW and corresponding configuration for CPC. Boot ROM code uses it as hosekeeping area.
3. For Secure boot, CPC is configured as SRAM and used as house keeping area. This configuration is to be disabled once in uboot. Earlier this disabling of CPC as SRAM was happening incpu_init_r. As a result cache invalidation function was getting skipped in case CPC is configured as SRAM.This was causing random crashes.Signed-off-by Aneesh Bansal <[email protected]>--- README | 4 ++++ arch/powerpc/cpu/mpc85xx/cpu_init.c | 27 ++++++++++++++++++++++----- arch/powerpc/cpu/mpc85xx/start.S | 3 ++- arch/powerpc/include/asm/fsl_secure_boot.h | 6 ++++++ boards.cfg | 1 + 5 files changed, 35 insertions(+), 6 deletions(-)Quoted 3 lines
Changes from v3:
Renamed the macro to indicate CPC configured as SRAM at U-boot entry toCONFIG_SYS_CPC_SRAMAneesh,
I understand you are trying to address the comment about when CPC needs to be disabled before initializing as normal CPC. But introducing
CONFIG_SYS_CPC_SRAMseems even more confusing. Let's take one step back.
Quoted 8 lines
Quoted 5 lines
CPC as SRAM can be used for many reasons. There is only one reason we should keep it as SRAM, i.e. u-boot is indeed using SRAM as its final destination. For all other usages, we can safely reconfigure it as normal CPC after u-boot relocates itself into DDR. If u-boot's final destination is SRAM, it is a RAMBOOT. Can we use this condition to deal with CPC?
Even if CPC is the final destination, shouldn't RAMBOOT imply that DDR has been initialized?
No. RAMBOOT implies u-boot shouldn't initialize RAM. There may be cases where u-boot needs to run in SRAM without DDR. It doesn't matter if the RAM is SRAM or DRAM.
York
PATCH v4 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
Quoted 39 lines · York Sun
Quoted 38 lines · Scott Wood
Quoted 36 lines · York Sun
Quoted 20 lines · Aneesh Bansal
Changes:
1. L2 cache is being invalidated by Boot ROM code for e6500 core. So removing the invalidation fromstart.S
2. Clear the LAW and corresponding configuration for CPC. Boot ROM code uses it as hosekeeping area.
3. For Secure boot, CPC is configured as SRAM and used as house keeping area. This configuration is to be disabled once in uboot. Earlier this disabling of CPC as SRAM was happening incpu_init_r. As a result cache invalidation function was getting skipped in case CPC is configured as SRAM.This was causing random crashes.Signed-off-by Aneesh Bansal <[email protected]>--- README | 4 ++++ arch/powerpc/cpu/mpc85xx/cpu_init.c | 27 ++++++++++++++++++++++----- arch/powerpc/cpu/mpc85xx/start.S | 3 ++- arch/powerpc/include/asm/fsl_secure_boot.h | 6 ++++++ boards.cfg | 1 + 5 files changed, 35 insertions(+), 6 deletions(-)Quoted 3 lines
Changes from v3:
Renamed the macro to indicate CPC configured as SRAM at U-boot entry toCONFIG_SYS_CPC_SRAMAneesh,
I understand you are trying to address the comment about when CPC needs to be disabled before initializing as normal CPC. But introducing
CONFIG_SYS_CPC_SRAMseems even more confusing. Let's take one step back.CPC as SRAM can be used for many reasons. There is only one reason we should keep it as SRAM, i.e. u-boot is indeed using SRAM as its final destination. For all other usages, we can safely reconfigure it as normal CPC after u-boot relocates itself into DDR. If u-boot's final destination is SRAM, it is a RAMBOOT. Can we use this condition to deal with CPC?
Quoted 6 lines
Quoted 2 lines
Even if CPC is the final destination, shouldn't RAMBOOT imply that DDR has been initialized?
No. RAMBOOT implies u-boot shouldn't initialize RAM. There may be cases where u-boot needs to run in SRAM without DDR. It doesn't matter if the RAM is SRAM or DRAM.
There are some situations where we run U-Boot out of SRAM without relocating to DDR, but I can't think of a situation where we wouldn't want to use DDR at all (e.g. for loading an OS to).
-Scott
PATCH v4 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
Quoted 43 lines · Scott Wood
Quoted 42 lines · York Sun
Quoted 40 lines · Scott Wood
Quoted 31 lines · York Sun
Quoted 20 lines · Aneesh Bansal
Changes:
1. L2 cache is being invalidated by Boot ROM code for e6500 core. So removing the invalidation fromstart.S
2. Clear the LAW and corresponding configuration for CPC. Boot ROM code uses it as hosekeeping area.
3. For Secure boot, CPC is configured as SRAM and used as house keeping area. This configuration is to be disabled once in uboot. Earlier this disabling of CPC as SRAM was happening incpu_init_r. As a result cache invalidation function was getting skipped in case CPC is configured as SRAM.This was causing random crashes.Signed-off-by Aneesh Bansal <[email protected]>--- README | 4 ++++ arch/powerpc/cpu/mpc85xx/cpu_init.c | 27 ++++++++++++++++++++++----- arch/powerpc/cpu/mpc85xx/start.S | 3 ++- arch/powerpc/include/asm/fsl_secure_boot.h | 6 ++++++ boards.cfg | 1 + 5 files changed, 35 insertions(+), 6 deletions(-)Quoted 3 lines
Changes from v3:
Renamed the macro to indicate CPC configured as SRAM at U-boot entry toCONFIG_SYS_CPC_SRAMAneesh,
I understand you are trying to address the comment about when CPC needs to be disabled before initializing as normal CPC. But introducing
CONFIG_SYS_CPC_SRAMseems even more confusing. Let's take one step back.Quoted 5 lines
CPC as SRAM can be used for many reasons. There is only one reason we should keep it as SRAM, i.e. u-boot is indeed using SRAM as its final destination. For all other usages, we can safely reconfigure it as normal CPC after u-boot relocates itself into DDR. If u-boot's final destination is SRAM, it is a RAMBOOT. Can we use this condition to deal with CPC?
Even if CPC is the final destination, shouldn't RAMBOOT imply that DDR has been initialized?
Quoted 8 lines
Quoted 3 lines
No. RAMBOOT implies u-boot shouldn't initialize RAM. There may be cases where u-boot needs to run in SRAM without DDR. It doesn't matter if the RAM is SRAM or DRAM.
There are some situations where we run U-Boot out of SRAM without relocating to DDR, but I can't think of a situation where we wouldn't want to use DDR at all (e.g. for loading an OS to).
I generally agree with you. Loading OS needs more RAM.
I am trying to simplify the condition to reinitialize CPC. My point is only one situation requires the CPC to act as SRAM. We can brainstorm how useful it is. For example, as a recovery method if using JTAG tool to enable CPC as SRAM and to load u-boot into it, one can skip the steps to initialize DDR to run an full-feature u-boot and reflash the board.
York
PATCH v4 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
Quoted 53 lines · York Sun
Quoted 43 lines · Scott Wood
Quoted 42 lines · York Sun
Quoted 40 lines · Scott Wood
Quoted 31 lines · York Sun
Quoted 20 lines · Aneesh Bansal
Changes:
1. L2 cache is being invalidated by Boot ROM code for e6500 core. So removing the invalidation fromstart.S
2. Clear the LAW and corresponding configuration for CPC. Boot ROM code uses it as hosekeeping area.
3. For Secure boot, CPC is configured as SRAM and used as house keeping area. This configuration is to be disabled once in uboot. Earlier this disabling of CPC as SRAM was happening incpu_init_r. As a result cache invalidation function was getting skipped in case CPC is configured as SRAM.This was causing random crashes.Signed-off-by Aneesh Bansal <[email protected]>--- README | 4 ++++ arch/powerpc/cpu/mpc85xx/cpu_init.c | 27 ++++++++++++++++++++++----- arch/powerpc/cpu/mpc85xx/start.S | 3 ++- arch/powerpc/include/asm/fsl_secure_boot.h | 6 ++++++ boards.cfg | 1 + 5 files changed, 35 insertions(+), 6 deletions(-)Quoted 3 lines
Changes from v3:
Renamed the macro to indicate CPC configured as SRAM at U-boot entry toCONFIG_SYS_CPC_SRAMAneesh,
I understand you are trying to address the comment about when CPC needs to be disabled before initializing as normal CPC. But introducing
CONFIG_SYS_CPC_SRAMseems even more confusing. Let's take one step back.Quoted 5 lines
CPC as SRAM can be used for many reasons. There is only one reason we should keep it as SRAM, i.e. u-boot is indeed using SRAM as its final destination. For all other usages, we can safely reconfigure it as normal CPC after u-boot relocates itself into DDR. If u-boot's final destination is SRAM, it is a RAMBOOT. Can we use this condition to deal with CPC?
Even if CPC is the final destination, shouldn't RAMBOOT imply that DDR has been initialized?
Quoted 8 lines
Quoted 3 lines
No. RAMBOOT implies u-boot shouldn't initialize RAM. There may be cases where u-boot needs to run in SRAM without DDR. It doesn't matter if the RAM is SRAM or DRAM.
There are some situations where we run U-Boot out of SRAM without relocating to DDR, but I can't think of a situation where we wouldn't want to use DDR at all (e.g. for loading an OS to).
Quoted 7 lines
I generally agree with you. Loading OS needs more RAM.
I am trying to simplify the condition to reinitialize CPC. My point is only one situation requires the CPC to act as SRAM. We can brainstorm how useful it is. For example, as a recovery method if using JTAG tool to enable CPC as SRAM and to load u-boot into it, one can skip the steps to initialize DDR to run an full-feature u-boot and reflash the board.
What's relevant isn't whether there is a use case for not needing DDR, but whether there's a use case for having a special build of U-Boot that skips initializing DDR.
-Scott
PATCH v4 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
Quoted 63 lines · Scott Wood
Quoted 53 lines · York Sun
Quoted 43 lines · Scott Wood
Quoted 42 lines · York Sun
Quoted 40 lines · Scott Wood
Quoted 31 lines · York Sun
Quoted 20 lines · Aneesh Bansal
Changes:
1. L2 cache is being invalidated by Boot ROM code for e6500 core. So removing the invalidation fromstart.S
2. Clear the LAW and corresponding configuration for CPC. Boot ROM code uses it as hosekeeping area.
3. For Secure boot, CPC is configured as SRAM and used as house keeping area. This configuration is to be disabled once in uboot. Earlier this disabling of CPC as SRAM was happening incpu_init_r. As a result cache invalidation function was getting skipped in case CPC is configured as SRAM.This was causing random crashes.Signed-off-by Aneesh Bansal <[email protected]>--- README | 4 ++++ arch/powerpc/cpu/mpc85xx/cpu_init.c | 27 ++++++++++++++++++++++----- arch/powerpc/cpu/mpc85xx/start.S | 3 ++- arch/powerpc/include/asm/fsl_secure_boot.h | 6 ++++++ boards.cfg | 1 + 5 files changed, 35 insertions(+), 6 deletions(-)Quoted 3 lines
Changes from v3:
Renamed the macro to indicate CPC configured as SRAM at U-boot entry toCONFIG_SYS_CPC_SRAMAneesh,
I understand you are trying to address the comment about when CPC needs to be disabled before initializing as normal CPC. But introducing
CONFIG_SYS_CPC_SRAMseems even more confusing. Let's take one step back.Quoted 5 lines
CPC as SRAM can be used for many reasons. There is only one reason we should keep it as SRAM, i.e. u-boot is indeed using SRAM as its final destination. For all other usages, we can safely reconfigure it as normal CPC after u-boot relocates itself into DDR. If u-boot's final destination is SRAM, it is a RAMBOOT. Can we use this condition to deal with CPC?
Even if CPC is the final destination, shouldn't RAMBOOT imply that DDR has been initialized?
Quoted 8 lines
Quoted 3 lines
No. RAMBOOT implies u-boot shouldn't initialize RAM. There may be cases where u-boot needs to run in SRAM without DDR. It doesn't matter if the RAM is SRAM or DRAM.
There are some situations where we run U-Boot out of SRAM without relocating to DDR, but I can't think of a situation where we wouldn't want to use DDR at all (e.g. for loading an OS to).
Quoted 7 lines
I generally agree with you. Loading OS needs more RAM.
I am trying to simplify the condition to reinitialize CPC. My point is only one situation requires the CPC to act as SRAM. We can brainstorm how useful it is. For example, as a recovery method if using JTAG tool to enable CPC as SRAM and to load u-boot into it, one can skip the steps to initialize DDR to run an full-feature u-boot and reflash the board.
Quoted 4 lines
What's relevant isn't whether there is a use case for not needing DDR, but whether there's a use case for having a special build of U-Boot that skips initializing DDR.
There are cases, such as using JTAG tools before, using PBI commands recently. There have been other cases when DDR is not or cannot be used, a RAMBOOT u-boot will use SRAM. All these cases need u-boot skipping initializing DDR.
York
PATCH v4 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
In reply to York SunQuoted 35 lines
-----Original Message-----
From: Sun York-R58495
Sent: Saturday, March 08, 2014 12:01 AM
To: Bansal Aneesh-B39320; u-boot at lists.denx.de
Cc: Wood Scott-B07421
Subject: Re: [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDSQuoted 8 lines · Aneesh Bansal
Changes:
1. L2 cache is being invalidated by Boot ROM code for e6500 core. So removing the invalidation fromstart.S2. Clear the LAW and
corresponding configuration for CPC. Boot ROM
code uses it as hosekeeping area.
3. For Secure boot, CPC is configured as SRAM and used as house keeping area. This configuration is to be disabled once in uboot. Earlier this disabling of CPC as SRAM was happening in
cpu_init_r.Quoted 7 lines
As a result cache invalidation function was getting skipped in case CPC is configured as SRAM.This was causing random crashes.
Signed-off-by Aneesh Bansal <[email protected]>--- README | 4 ++++ arch/powerpc/cpu/mpc85xx/cpu_init.c | 27++++++++++++++++++++++-----
Quoted 8 lines
arch/powerpc/cpu/mpc85xx/start.S | 3 ++- arch/powerpc/include/asm/fsl_secure_boot.h | 6 ++++++ boards.cfg | 1 + 5 files changed, 35 insertions(+), 6 deletions(-)Changes from v3:
Renamed the macro to indicate CPC configured as SRAM at U-boot entry toCONFIG_SYS_CPC_SRAM
Quoted 6 lines
Aneesh,
I understand you are trying to address the comment about when CPC needs to be disabled before initializing as normal CPC. But introducing
CONFIG_SYS_CPC_SRAMseems even more confusing. Let's take one step back.
In the previous patch we had defined it as CONFIG_SYS_SECURE_HKAREA_CPC. But as per the discussion on previous patch, we were advised to make it generic to have a macro stating that U-Boot is entered with the CPC configured as SRAM.
Quoted 7 lines
CPC as SRAM can be used for many reasons. There is only one reason we should keep it as SRAM, i.e. u-boot is indeed using SRAM as its final destination. For all other usages, we can safely reconfigure it as normal CPC after u-boot relocates itself into DDR. If u-boot's final destination is SRAM, it is a RAMBOOT. Can we use this condition to deal with CPC?
There is a separate condition for secure boot in which CPC is required as SRAM. For NOR secure boot, user needs to initialize a housekeeping area using PBI commands and provide pointer to this housekeeping area to boot ROM. Currently we are using CPC configured as SRAM for this area. Since, this area was initialized as SRAM by PBI commands, there is no cleanup of this area by Boot ROM. Since out of ROM, this are is no longer required, in case of NOR secure boot we need to disable this setting. NOR secure boot is not a RAMBOOT.
Quoted 3 lines
Do you see the need to disable CPC before relocation? You are doing so in this patch. Does the temporary LAW or address conflict with u-boot?
Earlier we were disabling cpc in cpu_init_r. However since cache invalidation function was getting skipped in the process, it was causing random crashes. Skipping invalidation works in RAMBOOT scenario, however since we don?t have valid data when CPC is configured as cache for the secure boot scenario which is not RAMBOOT, these crashes were occurring in few platforms. As a result we had to move this disable code early in the sequence, so that invalidation of cache doesn?t get skipped.
Quoted 3 lines
York
PATCH v4 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
Quoted 35 lines · On 03/10/2014 02:14 AM, Bansal Aneesh-B39320 wrote:
Quoted 35 lines
-----Original Message-----
From: Sun York-R58495
Sent: Saturday, March 08, 2014 12:01 AM
To: Bansal Aneesh-B39320; u-boot at lists.denx.de
Cc: Wood Scott-B07421
Subject: Re: [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDSQuoted 8 lines · Aneesh Bansal
Changes:
1. L2 cache is being invalidated by Boot ROM code for e6500 core. So removing the invalidation fromstart.S2. Clear the LAW and
corresponding configuration for CPC. Boot ROM
code uses it as hosekeeping area.
3. For Secure boot, CPC is configured as SRAM and used as house keeping area. This configuration is to be disabled once in uboot. Earlier this disabling of CPC as SRAM was happening in
cpu_init_r.Quoted 7 lines
As a result cache invalidation function was getting skipped in case CPC is configured as SRAM.This was causing random crashes.
Signed-off-by Aneesh Bansal <[email protected]>--- README | 4 ++++ arch/powerpc/cpu/mpc85xx/cpu_init.c | 27++++++++++++++++++++++-----
Quoted 8 lines
arch/powerpc/cpu/mpc85xx/start.S | 3 ++- arch/powerpc/include/asm/fsl_secure_boot.h | 6 ++++++ boards.cfg | 1 + 5 files changed, 35 insertions(+), 6 deletions(-)Changes from v3:
Renamed the macro to indicate CPC configured as SRAM at U-boot entry toCONFIG_SYS_CPC_SRAM
Quoted 7 lines
Quoted 6 lines
Aneesh,
I understand you are trying to address the comment about when CPC needs to be disabled before initializing as normal CPC. But introducing
CONFIG_SYS_CPC_SRAMseems even more confusing. Let's take one step back.In the previous patch we had defined it as
CONFIG_SYS_SECURE_HKAREA_CPC. But as per the discussion on previous patch, we were advised to make it generic to have a macro stating that U-Boot is entered with the CPC configured as SRAM.
In your patch, you are using this new macro to disable SRAM. It would be more clear if the macro is named CONFIG_SYS_CPC_REINIT_F.
Quoted 8 lines
Quoted 7 lines
CPC as SRAM can be used for many reasons. There is only one reason we should keep it as SRAM, i.e. u-boot is indeed using SRAM as its final destination. For all other usages, we can safely reconfigure it as normal CPC after u-boot relocates itself into DDR. If u-boot's final destination is SRAM, it is a RAMBOOT. Can we use this condition to deal with CPC?
There is a separate condition for secure boot in which CPC is required as SRAM. For NOR secure boot, user needs to initialize a housekeeping area using PBI commands and provide pointer to this housekeeping area to boot ROM. Currently we are using CPC configured as SRAM for this area. Since, this area was initialized as SRAM by PBI commands, there is no cleanup of this area by Boot ROM. Since out of ROM, this are is no longer required, in case of NOR secure boot we need to disable this setting. NOR secure boot is not a RAMBOOT.
That's not conflict with my suggestion. This is NOT a RAMBOOT, so CPC should be reinitialized.
Quoted 6 lines
Quoted 4 lines
Do you see the need to disable CPC before relocation? You are doing so in this patch. Does the temporary LAW or address conflict with u-boot?
Earlier we were disabling cpc in
cpu_init_r. However since cache invalidation function was getting skipped in the process, it was causing random crashes. Skipping invalidation works in RAMBOOT scenario, however since we don?t have valid data when CPC is configured as cache for the secure boot scenario which is not RAMBOOT, these crashes were occurring in few platforms. As a result we had to move this disable code early in the sequence, so that invalidation of cache doesn?t get skipped.Quoted 1 line
As I suggested, if you have to do this before relocation, a macro CONFIG_SYS_CPC_REINIT_F makes more sense.
York
PATCH v4 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
Quoted 9 lines · York Sun
Quoted 8 lines · On 03/10/2014 02:14 AM, Bansal Aneesh-B39320 wrote:
Quoted 8 lines
-----Original Message-----
From: Sun York-R58495
Sent: Saturday, March 08, 2014 12:01 AM
To: Bansal Aneesh-B39320; u-boot at lists.denx.de
Cc: Wood Scott-B07421
Subject: Re: [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
Do you see the need to disable CPC before relocation? You are doing so in this patch. Does the temporary LAW or address conflict with u-boot?
Earlier we were disabling cpc in
cpu_init_r. However since cache invalidation function was getting skipped in the process, it was causing random crashes. Skipping invalidation works in RAMBOOT scenario, however since we don?t have valid data when CPC is configured as cache for the secure boot scenario which is not RAMBOOT, these crashes were occurring in few platforms. As a result we had to move this disable code early in the sequence, so that invalidation of cache doesn?t get skipped.Quoted 1 line
As I suggested, if you have to do this before relocation, a macro
CONFIG_SYS_CPC_REINIT_Fmakes more sense.
How hard would it be to check the status of CPC at runtime, or just unconditionally reinit (for non-ramboot)?
I don't think I ever saw an answer to the question of what harm it does to leave CPC alone until the normal place where we init CPC.
-Scott
PATCH v4 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
Quoted 12 lines · Scott Wood
Quoted 11 lines · York Sun
Quoted 10 lines · On 03/10/2014 02:14 AM, Bansal Aneesh-B39320 wrote:
Quoted 10 lines
-----Original Message-----
From: Sun York-R58495
Sent: Saturday, March 08, 2014 12:01 AM
To: Bansal Aneesh-B39320; u-boot at lists.denx.de
Cc: Wood Scott-B07421
Subject: Re: [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDSDo you see the need to disable CPC before relocation? You are doing so in this patch. Does the temporary LAW or address conflict with u-boot?
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Earlier we were disabling cpc in
cpu_init_r. However since cache invalidation function was getting skipped in the process, it was causing random crashes. Skipping invalidation works in RAMBOOT scenario, however since we don?t have valid data when CPC is configured as cache for the secure boot scenario which is not RAMBOOT, these crashes were occurring in few platforms. As a result we had to move this disable code early in the sequence, so that invalidation of cache doesn?t get skipped.Quoted 1 line
As I suggested, if you have to do this before relocation, a macro
CONFIG_SYS_CPC_REINIT_Fmakes more sense.How hard would it be to check the status of CPC at runtime, or just unconditionally reinit (for non-ramboot)?
That's what I was suggesting.
Quoted 4 lines
I don't think I ever saw an answer to the question of what harm it does to leave CPC alone until the normal place where we init CPC.
Aneesh seems to believe disabling and re-initializing CPC in cpu_inti_r is too late for SECURE BOOT.
York
PATCH v4 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
Quoted 42 lines
-----Original Message-----
From: Sun York-R58495
Sent: Tuesday, March 11, 2014 5:31 AM
To: Wood Scott-B07421
Cc: Bansal Aneesh-B39320; u-boot at lists.denx.de; Gupta Ruchika-R66431
Subject: Re: [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDSQuoted 11 lines · Scott Wood
Quoted 10 lines · York Sun
Quoted 9 lines · On 03/10/2014 02:14 AM, Bansal Aneesh-B39320 wrote:
Quoted 9 lines
-----Original Message-----
From: Sun York-R58495
Sent: Saturday, March 08, 2014 12:01 AM
To: Bansal Aneesh-B39320; u-boot at lists.denx.de
Cc: Wood Scott-B07421
Subject: Re: [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDSDo you see the need to disable CPC before relocation? You are
doing
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
so in this patch. Does the temporary LAW or address conflict with
u-boot?
Quoted 1 line
Quoted 1 line
Quoted 1 line
Earlier we were disabling cpc in
cpu_init_r. However since cacheinvalidation function was getting skipped in the process, it was causing random crashes. Skipping invalidation works in RAMBOOT scenario, however since we don?t have valid data when CPC is configured as cache for the secure boot scenario which is not RAMBOOT, these crashes were occurring in few platforms. As a result we had to move this disable code early in the sequence, so that invalidation of cache doesn?t get skipped.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
As I suggested, if you have to do this before relocation, a macro
CONFIG_SYS_CPC_REINIT_Fmakes more sense.How hard would it be to check the status of CPC at runtime, or just unconditionally reinit (for non-ramboot)?
That's what I was suggesting.
Quoted 1 line
Quoted 9 lines
Quoted 3 lines
I don't think I ever saw an answer to the question of what harm it does to leave CPC alone until the normal place where we init CPC.
Aneesh seems to believe disabling and re-initializing CPC in
cpu_inti_ris too late for SECURE BOOT.York
Yes, we have seen random crashes occur during Secure Boot if CPC is not disabled before cache invalidation and re-initialization.
Aneesh
PATCH v4 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
In reply to Aneesh BansalQuoted 29 lines · Aneesh Bansal
Changes:
1. L2 cache is being invalidated by Boot ROM code for e6500 core. So removing the invalidation fromstart.S
2. Clear the LAW and corresponding configuration for CPC. Boot ROM code uses it as hosekeeping area.
3. For Secure boot, CPC is configured as SRAM and used as house keeping area. This configuration is to be disabled once in uboot. Earlier this disabling of CPC as SRAM was happening incpu_init_r. As a result cache invalidation function was getting skipped in case CPC is configured as SRAM.This was causing random crashes.Signed-off-by Aneesh Bansal <[email protected]>--- README | 4 ++++ arch/powerpc/cpu/mpc85xx/cpu_init.c | 27 ++++++++++++++++++++++----- arch/powerpc/cpu/mpc85xx/start.S | 3 ++- arch/powerpc/include/asm/fsl_secure_boot.h | 6 ++++++ boards.cfg | 1 + 5 files changed, 35 insertions(+), 6 deletions(-)Changes from v3:
Renamed the macro to indicate CPC configured as SRAM at U-boot entry toCONFIG_SYS_CPC_SRAMREADME +0
-0
README The following options need to be configured: · line 432
Quoted 6 lines
README +3
-0@@ -427,6 +427,10 @@ The following options need to be configured: In this mode, a single differential clock is used to supply clocks to the sysclock, ddrclock and usbclock. + CONFIG_SYS_CPC_SRAM + This CONFIG is defined when the SPC is configured as SRAM at the + time of U-boot entry.
SPC?
-Scott