-----Original Message----- From: Sun York-R58495 Sent: Tuesday, March 11, 2014 5:31 AM To: Wood Scott-B07421 Cc: Bansal Aneesh-B39320; u-boot@lists.denx.de; Gupta Ruchika-R66431 Subject: Re: [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
On 03/10/2014 04:55 PM, Scott Wood wrote:
On Mon, 2014-03-10 at 08:38 -0700, York Sun wrote:
On 03/10/2014 02:14 AM, Bansal Aneesh-B39320 wrote:
-----Original Message----- From: Sun York-R58495 Sent: Saturday, March 08, 2014 12:01 AM To: Bansal Aneesh-B39320; u-boot@lists.denx.de Cc: Wood Scott-B07421 Subject: Re: [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
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.
As I suggested, if you have to do this before relocation, a macro CONFIG_SYS_CPC_REINIT_F makes 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.
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
Yes, we have seen random crashes occur during Secure Boot if CPC is not disabled before cache invalidation and re-initialization.
Aneesh