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