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

[Scott Wood]

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.

-Scott