> -----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@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 > <7f771c64c5c44208b24e38c75e159...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
