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