[U-Boot] [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS

[York Sun <yorksun@freescale.com>]

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 at 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