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

[York Sun]

On 03/10/2014 04:24 PM, Scott Wood wrote:
> 
> On Fri, 2014-03-07 at 11:07 -0800, York Sun wrote:
>> On 03/07/2014 11:00 AM, Scott Wood wrote:
>>> On Fri, 2014-03-07 at 10:58 -0800, York Sun wrote:
>>>> On 03/07/2014 10:54 AM, Scott Wood wrote:
>>>>> On Fri, 2014-03-07 at 10:30 -0800, York Sun wrote:
>>>>>> On 03/07/2014 05:23 AM, Aneesh Bansal wrote:
>>>>>>> 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: Aneesh Bansal <aneesh.bansal at freescale.com>
>>>>>>> ---
>>>>>>>  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 v3:
>>>>>>> Renamed the macro to indicate CPC configured as SRAM at U-boot entry to
>>>>>>> CONFIG_SYS_CPC_SRAM 
>>>>>>
>>>>>> Aneesh,
>>>>>>
>>>>>> I understand you are trying to address the comment about when CPC needs to be
>>>>>> disabled before initializing as normal CPC. But introducing CONFIG_SYS_CPC_SRAM
>>>>>> seems even more confusing. Let's take one step back.
>>>>>>
>>>>>> CPC as SRAM can be used for many reasons. There is only one reason we should
>>>>>> keep it as SRAM, i.e. u-boot is indeed using SRAM as its final destination. For
>>>>>> all other usages, we can safely reconfigure it as normal CPC after u-boot
>>>>>> relocates itself into DDR. If u-boot's final destination is SRAM, it is a
>>>>>> RAMBOOT. Can we use this condition to deal with CPC?
>>>>>
>>>>> Even if CPC is the final destination, shouldn't RAMBOOT imply that DDR
>>>>> has been initialized?
>>>>
>>>> No. RAMBOOT implies u-boot shouldn't initialize RAM. There may be cases where
>>>> u-boot needs to run in SRAM without DDR. It doesn't matter if the RAM is SRAM or
>>>> DRAM.
>>>
>>> There are some situations where we run U-Boot out of SRAM without
>>> relocating to DDR, but I can't think of a situation where we wouldn't
>>> want to use DDR at all (e.g. for loading an OS to).
>>>
>>
>> I generally agree with you. Loading OS needs more RAM.
>>
>> I am trying to simplify the condition to reinitialize CPC. My point is only one
>> situation requires the CPC to act as SRAM. We can brainstorm how useful it is.
>> For example, as a recovery method if using JTAG tool to enable CPC as SRAM and
>> to load u-boot into it, one can skip the steps to initialize DDR to run an
>> full-feature u-boot and reflash the board.
> 
> What's relevant isn't whether there is a use case for not needing DDR,
> but whether there's a use case for having a special build of U-Boot that
> skips initializing DDR.
> 

There are cases, such as using JTAG tools before, using PBI commands recently.
There have been other cases when DDR is not or cannot be used, a RAMBOOT u-boot
will use SRAM. All these cases need u-boot skipping initializing DDR.

York