> -----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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
