From: York Sun <yorksun@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT- define CONFIG_SYS_RAMBOOT for NAND boot
Date: Tue, 4 Mar 2014 09:11:41 -0800 [thread overview]
Message-ID: <5316094D.8060504@freescale.com> (raw)
In-Reply-To: <20140128053539.DE87A3801D7@gemini.denx.de>
On 01/27/2014 09:35 PM, Wolfgang Denk wrote:
> Dear Aneesh,
>
> In message <7f771c64c5c44208b24e38c75e159f28@DM2PR03MB415.namprd03.prod.outlook.com> you wrote:
>>
>> Sorry for the misleading statement. Yes, CONFIG_SYS_RAMBOOT is for
>> booting from RAM directly and we have used it for the same purpose in
>> the patch. Let me try and explain.
>
> Mind the "directly" in this sentence, and no, you have not used it in
> this way.
>
>> What I meant is that for P1010 like platforms for normal (non-secure)
>> boot in case of NAND, we don't use the CONFIG_SYS_RAMBOOT as we
>> don't boot from RAM directly in this case.
>
> You also do not boot directly from RAM in the secure case.
>
>> However in case of secure boot, even for NAND, we boot from RAM
>> directly with boot ROM (ISBC) code copying the image from NAND to
>> RAM. So in P1010RDB.h config file, for NAND Secure boot, we have
>
> This is NOT a RAM boot. This is a completely normal boot process from
> NAND. You must not declare this as RAM booting, as it is NOT.
>
>> defined CONFIG_RAMBOOT_NAND and then further are enabling
>> CONFIG_SYS_RAMBOOT for the same.
>
> This is wrong. You have the ROM boot loader booting from NAND and
> not from RAM.
>
> The name CONFIG_RAMBOOT_NAND is an oxymoron in itself (and it's
> undocumented as well). This should be fixed, as it makes no sense.
>
> You cannot "RAM-boot form NAND" - you can always boot from a single
> boot device only - either NOR or NAND or SDCard or ... or RAM.
>
Let me try to get the bottom of the CONFIG_SYS_RAMBOOT.
When a complete u-boot image boots from RAM (DDR, SRAM, etc), we can call it
RAMBOOT regardless how the image is loaded there. It can be JTAG, PBI, or other
bootloader. This line becomes blurred when we have SPL, TPL, secure boot. We
need to go back to see why we had CONFIG_SYS_RAMBOOT at the first place. If I
remember correctly, we had this RAMBOOT because we didn't want u-boot to
initialized DRAM for obvious reason. If we still have the same purpose of
RAMBOOT, then it is not difficult to draw the line for current situations.
Any booting method which initializes DRAM in its complete image is not a
RAMBOOT. So clearly NAND boot has its own DDR init code, even sometimes using
fixed register settings. So a normal NAND boot is not RAMBOOT. If a u-boot image
is wrapped by another bootloader, and the bootloader is responsible to
initialize DRAM, the u-boot image runs from DRAM doesn't init DRAM again, this
u-boot is a RAMBOOT.
Now we are back to secure NAND boot. Does the secure boot mechanism initialize
DRAM and load a complete u-boot image from NAND to DRAM? If true, then we can
call that image a RAMBOOT. But if the image has its own code to initialize DRAM,
it is not a RAMBOOT.
Do we all agree on this clarification?
York
next prev parent reply other threads:[~2014-03-04 17:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-20 9:25 [U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT- define CONFIG_SYS_RAMBOOT for NAND boot Aneesh Bansal
2014-01-20 22:04 ` Scott Wood
2014-01-27 7:20 ` aneesh.bansal at freescale.com
2014-01-27 14:22 ` Wolfgang Denk
2014-01-28 4:47 ` aneesh.bansal at freescale.com
2014-01-28 5:35 ` Wolfgang Denk
2014-03-04 17:11 ` York Sun [this message]
2014-03-05 5:30 ` aneesh.bansal at freescale.com
2014-03-05 18:00 ` Scott Wood
2014-03-06 9:24 ` aneesh.bansal at freescale.com
2014-03-07 0:35 ` York Sun
2014-03-07 18:57 ` Scott Wood
2014-03-07 19:01 ` York Sun
2014-03-10 9:14 ` aneesh.bansal at freescale.com
2014-03-10 15:26 ` York Sun
2014-03-10 23:58 ` Scott Wood
2014-03-11 15:53 ` York Sun
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=5316094D.8060504@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