[U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT- define CONFIG_SYS_RAMBOOT for NAND boot

[aneesh.bansal at freescale.com]

> -----Original Message-----
> From: Sun York-R58495
> Sent: Tuesday, March 04, 2014 10:42 PM
> To: Wolfgang Denk; Bansal Aneesh-B39320
> Cc: Wood Scott-B07421; u-boot at lists.denx.de; Gupta Ruchika-R66431
> Subject: Re: [U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT-
> define CONFIG_SYS_RAMBOOT for NAND boot
> 
> On 01/27/2014 09:35 PM, Wolfgang Denk wrote:
> > Dear Aneesh,
> >
> > In message
> <7f771c64c5c44208b24e38c75e159f28 at DM2PR03MB415.namprd03.prod.outlook.c
> om> 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


Yes, in case of secure boot from NAND, the DRAM is initialized by the BootROM
and complete u-boot image is copied from NAND to DRAM by the BootROM.
So, it should be called RAMBOOT.

Aneesh