From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Mon, 10 Mar 2014 18:24:05 -0500 Subject: [U-Boot] [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS In-Reply-To: <531A18E5.9090309@freescale.com> References: <1394198592-18967-1-git-send-email-aneesh.bansal@freescale.com> <531A105C.3070003@freescale.com> <1394218478.32664.34.camel@snotra.buserror.net> <531A16BE.6000605@freescale.com> <1394218805.32664.39.camel@snotra.buserror.net> <531A18E5.9090309@freescale.com> Message-ID: <1394493845.6150.1.camel@snotra.buserror.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > >>>>> --- > >>>>> 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