Skip to contentSkip to conversation

powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS

PATCH Superseded Aneesh Bansal 3 participants 8 messages Feb 3, 2014 – Feb 7, 2014 PowerPC

v3 of 7 Superseded Latest is v7 →

lore
Share & tools
lore

Aneesh Bansal

author
#0 lore raw

PATCH v3 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.

Signed-off-by Ruchika Gupta <[email protected]>
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 v2:
Squashed with previous patch after removing the ISBC version as per discussion. Changed the Subject Line.

README +4 -0
index 176de61..3ca307f 100644
@@ -428,6 +428,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_SECURE_HKAREA_CPC
+		This CONFIG is defined for the SoC's in which the BootROM code uses
+		the platform cache configured as SRAM for house keeping.
+
 - Generic CPU options:
 		CONFIG_SYS_BIG_ENDIAN, CONFIG_SYS_LITTLE_ENDIAN
arch/powerpc/cpu/mpc85xx/cpu_init.c +22 -5
index b31efb7..2b2fd27 100644
@@ -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_SECURE_HKAREA_CPC)
+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_SECURE_HKAREA_CPC)
+	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
index dbbd8e5..4ef0985 100644
@@ -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
index 4c7f0b1..9973100 100644
@@ -15,5 +15,11 @@
 #endif
 #define CONFIG_SYS_PBI_FLASH_WINDOW		0xcff80000
 
+#if defined(CONFIG_B4860QDS)
+#define CONFIG_SYS_SECURE_HKAREA_CPC
+#undef CONFIG_SYS_INIT_L3_ADDR
+#define CONFIG_SYS_INIT_L3_ADDR			0xbff00000
+#endif
+
 #endif
 #endif
boards.cfg +1 -0
index 2dfd2b4..0312595 100644
@@ -781,6 +781,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
#1 lore raw

PATCH v3 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS

Dear Aneesh Bansal,

Quoted 10 lines · In message <[email protected]> you…

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.

...

arch/powerpc/cpu/mpc85xx/cpu_init.c skip_l2: · line 569

Quoted 3 lines
arch/powerpc/cpu/mpc85xx/cpu_init.c +3 -0
+#if defined(CONFIG_RAMBOOT_PBL)
+	disable_cpc_sram();
+#endif

What is the meaning of this undocumented CONFIG_RAMBOOT_PBL option?

As far as I understand, this is not a boot from RAM at all, but a totally normal step in a boot process form regular boot media?

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The perversity of nature is nowhere better demonstrated by  the  fact
that,  when  exposed to the same atmosphere, bread becomes hard while
crackers become soft.
#2 lore raw

PATCH v3 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS

Quoted 13 lines · Wolfgang Denk

Dear Aneesh Bansal,

Quoted 10 lines · In message <[email protected]> you…

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.

Quoted 6 lines

...

arch/powerpc/cpu/mpc85xx/cpu_init.c skip_l2: · line 569

Quoted 3 lines
arch/powerpc/cpu/mpc85xx/cpu_init.c +3 -0
+#if defined(CONFIG_RAMBOOT_PBL)
+	disable_cpc_sram();
+#endif

What is the meaning of this undocumented CONFIG_RAMBOOT_PBL option?

I agree it should be documented, but it's not new to this patch.

Quoted 2 lines

As far as I understand, this is not a boot from RAM at all, but a totally normal step in a boot process form regular boot media?

FWIW, the only documentation I can find for CONFIG_SYS_RAMBOOT is doc/README.mpc85xx and doc/README.ramboot-ppc85xx which specify its usage in "totally normal steps in a boot process from regular boot media".

Any instance of "booting from RAM" is going to need the image to get into RAM somehow. If the symbol is to mean anything at all, it seems reasonable that it means that U-Boot was executing from RAM when the current image was entered, regardless of how that came to be. There should be some way to distinguish running from SRAM versus running from DDR, though.

-Scott

#3 lore raw

PATCH v3 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS

Dear Scott,

Quoted 8 lines · In message <[email protected]> you wrote:
Quoted 6 lines

arch/powerpc/cpu/mpc85xx/cpu_init.c skip_l2: · line 569

Quoted 4 lines
arch/powerpc/cpu/mpc85xx/cpu_init.c +3 -0
+#if defined(CONFIG_RAMBOOT_PBL)
+	disable_cpc_sram();
+#endif

What is the meaning of this undocumented CONFIG_RAMBOOT_PBL option?

I agree it should be documented, but it's not new to this patch.

Of course you are right. But this patch clearly shows the need to document such things, or more and more code will be added based on incorrect interpretations.

Quoted 4 lines

FWIW, the only documentation I can find for CONFIG_SYS_RAMBOOT is doc/README.mpc85xx and doc/README.ramboot-ppc85xx which specify its usage in "totally normal steps in a boot process from regular boot media".

Agreed. The original purpose has never been documented, whichi s a serious pity, as now we only have the misinterpreting documents you refer to.

Quoted 3 lines

Any instance of "booting from RAM" is going to need the image to get into RAM somehow. If the symbol is to mean anything at all, it seems reasonable that it means that U-Boot was executing from RAM when the

Yes, "booting from RAM" has been indeed intended for confiurations where the U-Boot image was brought to RAM by some magic means totally outside of normal operations of the CPU.

The first board that would meet such a description (and that I can remember of) was the PN62 board; this was a PCI card, where the U-Boot code was loaded into memory from the host while the CPU was helt in reset, and subsequently it directly started executing from RAM.

Unfortunately I cannot check currently if my memory is correct and PN62 was also where we introduced that variable (at that time under the name CFG_RAMBOOT), as this was before U-Boot (still in PPCBoot) and I only have the old CVS repository for that archived somewhere.

The next example of "correct" use of CONFIG_SYS_RAMBOOT was when Stefan Roese added support to the PPC440EPx based Sequoia board to run an U-Boot image that had been loaded to RAM using a JTAG debugger.

In any case, RAMBOOT was supposed to be used for systems, where code execution started in RAM right out of reset, i. e. without any other boot device like NAND, SPI flash, SDcard or similar.

Quoted 3 lines

current image was entered, regardless of how that came to be. There should be some way to distinguish running from SRAM versus running from DDR, though.

I cannot see how this is related to the RAMBOOT discussion. Actually I cannot even see why such distinguishing would be needed at all (unless you have very specific ideas about the characteristics of SRAM versus DDR on some systems): SRAM and DDR are just examples of hardware implementations for the more generic term RAM, i. e. writable system memory from wich code can be executed (in contrast to some storage device from which no code can be executed without previously loading it to RAM, like NAND, SPI flash, SDcard, USB storage devices, hard disk drives, etc. etc.)

Best regards,

Wolfgang Denk

Signature · 8 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Hello! I'm from outer space,  and I've made myself look like a signa-
ture.  While  you  are reading this, I'm having sex with your eyes. I
know it feels good to you, because you're smiling. I'm very horny, so
send me to someone else when you've had enough. Thanks!
                              Sincerely, A Stranger in a Strange Land
#4 lore raw

PATCH v3 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS

Quoted 25 lines · Wolfgang Denk

Dear Scott,

Quoted 8 lines · In message <[email protected]> you wrote:
Quoted 6 lines

arch/powerpc/cpu/mpc85xx/cpu_init.c skip_l2: · line 569

Quoted 4 lines
arch/powerpc/cpu/mpc85xx/cpu_init.c +3 -0
+#if defined(CONFIG_RAMBOOT_PBL)
+	disable_cpc_sram();
+#endif

What is the meaning of this undocumented CONFIG_RAMBOOT_PBL option?

I agree it should be documented, but it's not new to this patch.

Of course you are right. But this patch clearly shows the need to document such things, or more and more code will be added based on incorrect interpretations.

Quoted 4 lines

FWIW, the only documentation I can find for CONFIG_SYS_RAMBOOT is doc/README.mpc85xx and doc/README.ramboot-ppc85xx which specify its usage in "totally normal steps in a boot process from regular boot media".

Agreed. The original purpose has never been documented, whichi s a serious pity, as now we only have the misinterpreting documents you refer to.

Quoted 7 lines
Quoted 3 lines

Any instance of "booting from RAM" is going to need the image to get into RAM somehow. If the symbol is to mean anything at all, it seems reasonable that it means that U-Boot was executing from RAM when the

Yes, "booting from RAM" has been indeed intended for confiurations where the U-Boot image was brought to RAM by some magic means totally outside of normal operations of the CPU.

Why does U-Boot care, though, whether the means were totally outside the normal operations of the CPU, or something that was done by some other software component running on the CPU? What U-Boot needs to know is the present state of the system.

Quoted 5 lines
Quoted 3 lines

current image was entered, regardless of how that came to be. There should be some way to distinguish running from SRAM versus running from DDR, though.

I cannot see how this is related to the RAMBOOT discussion.

It's related because it's part of what CONFIG_RAMBOOT_PBL is being used to indicate.

Quoted 8 lines

Actually I cannot even see why such distinguishing would be needed at all (unless you have very specific ideas about the characteristics of SRAM versus DDR on some systems): SRAM and DDR are just examples of hardware implementations for the more generic term RAM, i. e. writable system memory from wich code can be executed (in contrast to some storage device from which no code can be executed without previously loading it to RAM, like NAND, SPI flash, SDcard, USB storage devices, hard disk drives, etc. etc.)

The difference is relevant (at least on some platforms) because U-Boot needs to know which TLB entries to have during early boot, whether it needs to initialize the DDR controller, whether the cache is currently configured as an SRAM, etc.

Perhaps it could detect this information at runtime, but currently it does not for at least some of the above. It also affects the pre-relocation link address, which must be compile time (but doesn't necessarily need a symbol that's visible outside the board config file).

-Scott

#5 lore raw

PATCH v3 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS

In reply to Aneesh Bansal
Quoted 30 lines · Aneesh Bansal

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.

Signed-off-by Ruchika Gupta <[email protected]>
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 v2:
Squashed with previous patch after removing the ISBC version as per discussion. Changed the Subject Line.

README +0 -0
index 176de61..3ca307f 100644

README The following options need to be configured: · line 433

Quoted 6 lines
README +3 -0
@@ -428,6 +428,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_SECURE_HKAREA_CPC
+		This CONFIG is defined for the SoC's in which the BootROM code uses
+		the platform cache configured as SRAM for house keeping.

What sort of house keeping? The bootrom is finished by the time U-Boot starts, right? What restrictions are there on U-Boot's use of the SRAM?

-Scott

author
#6 lore raw

PATCH v3 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS

Quoted 47 lines

-----Original Message-----
From: Wood Scott-B07421
Sent: Tuesday, February 04, 2014 4:32 AM
To: Bansal Aneesh-B39320
Cc: u-boot at lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431
Subject: Re: [PATCH][v3] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS

Quoted 11 lines · Aneesh Bansal

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.

Quoted 5 lines
Signed-off-by Ruchika Gupta <[email protected]>
Signed-off-by Aneesh Bansal <[email protected]>
---
 README                                     |  4 ++++
 arch/powerpc/cpu/mpc85xx/cpu_init.c        | 27

++++++++++++++++++++++-----

Quoted 7 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 v2:
Squashed with previous patch after removing the ISBC version as per

discussion.

README The following options need to be configured: · line 432

Quoted 12 lines

Changed the Subject Line.

README +2 -0
index 176de61..3ca307f 100644
@@ -428,6 +428,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_SECURE_HKAREA_CPC
+		This CONFIG is defined for the SoC's in which the BootROM

code uses

Quoted 7 lines

README The following options need to be configured: · line 433

Quoted 1 line
README +1 -0
+		the platform cache configured as SRAM for house keeping.

What sort of house keeping? The bootrom is finished by the time U-Boot starts, right? What restrictions are there on U-Boot's use of the SRAM?

-Scott

For Secure Boot, CPC is configured as SRAM by the PBI commands and BootROM uses it for sending commands to SEC block. In U-boot CPC is to be configured as platform cache and before doing so, the configuration of CPC as SRAM needs to be removed.

#7 lore raw

PATCH v3 1/1 powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS

Quoted 52 lines · On Tue, 2014-02-04 at 01:41 -0600, Bansal Aneesh-B39320 wrote:
Quoted 52 lines

-----Original Message-----
From: Wood Scott-B07421
Sent: Tuesday, February 04, 2014 4:32 AM
To: Bansal Aneesh-B39320
Cc: u-boot at lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431
Subject: Re: [PATCH][v3] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS

Quoted 11 lines · Aneesh Bansal

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.

Quoted 5 lines
Signed-off-by Ruchika Gupta <[email protected]>
Signed-off-by Aneesh Bansal <[email protected]>
---
 README                                     |  4 ++++
 arch/powerpc/cpu/mpc85xx/cpu_init.c        | 27

++++++++++++++++++++++-----

Quoted 7 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 v2:
Squashed with previous patch after removing the ISBC version as per

discussion.

README The following options need to be configured: · line 432

Quoted 12 lines

Changed the Subject Line.

README +2 -0
index 176de61..3ca307f 100644
@@ -428,6 +428,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_SECURE_HKAREA_CPC
+		This CONFIG is defined for the SoC's in which the BootROM

code uses

README The following options need to be configured: · line 433

Quoted 1 line
README +1 -0
+		the platform cache configured as SRAM for house keeping.

What sort of house keeping? The bootrom is finished by the time U-Boot starts, right? What restrictions are there on U-Boot's use of the SRAM?

Quoted 4 lines
Quoted 2 lines

-Scott

For Secure Boot, CPC is configured as SRAM by the PBI commands and BootROM uses it for sending commands to SEC block.

Why does U-Boot care?

Quoted 2 lines

In U-boot CPC is to be configured as platform
cache and before doing so, the configuration of CPC as SRAM needs to be removed.

So all you need is something saying that U-Boot is entered with the CPC configured as SRAM. We don't care whether it's for "secure hkarea". Right?

-Scott