From: York Sun <yorksun@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
Date: Fri, 7 Mar 2014 10:58:06 -0800 [thread overview]
Message-ID: <531A16BE.6000605@freescale.com> (raw)
In-Reply-To: <1394218478.32664.34.camel@snotra.buserror.net>
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@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.
York
next prev parent reply other threads:[~2014-03-07 18:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-07 13:23 [U-Boot] [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS Aneesh Bansal
2014-03-07 18:30 ` York Sun
2014-03-07 18:54 ` Scott Wood
2014-03-07 18:58 ` York Sun [this message]
2014-03-07 19:00 ` Scott Wood
2014-03-07 19:07 ` York Sun
2014-03-10 23:24 ` Scott Wood
2014-03-11 2:46 ` York Sun
2014-03-10 9:14 ` aneesh.bansal at freescale.com
2014-03-10 15:38 ` York Sun
2014-03-10 23:55 ` Scott Wood
2014-03-11 0:00 ` York Sun
2014-03-11 8:43 ` aneesh.bansal at freescale.com
2014-03-07 18:43 ` Scott Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=531A16BE.6000605@freescale.com \
--to=yorksun@freescale.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox