[U-Boot] [PATCH][v3] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS

[Wolfgang Denk]

Dear Scott,

In message <1391469528.6733.97.camel at snotra.buserror.net> you wrote:
>
> > > +#if defined(CONFIG_RAMBOOT_PBL)
> > > +	disable_cpc_sram();
> > > +#endif
> > 
> > What is the meaning of this undocumented CONFIG_RAMBOOT_PBL option?
> 
> I agree it should be documented, but it's not new to this patch.

Of course you are right.  But this patch clearly shows the need to
document such things, or more and more code will be added based on
incorrect interpretations.

> FWIW, the only documentation I can find for CONFIG_SYS_RAMBOOT is
> doc/README.mpc85xx and doc/README.ramboot-ppc85xx which specify its
> usage in "totally normal steps in a boot process from regular boot
> media".

Agreed.  The original purpose has never been documented, whichi s a
serious pity, as now we only have the misinterpreting documents you
refer to.

> Any instance of "booting from RAM" is going to need the image to get
> into RAM somehow.  If the symbol is to mean anything at all, it seems
> reasonable that it means that U-Boot was executing from RAM when the

Yes, "booting from RAM" has been indeed intended for confiurations
where the U-Boot image was brought to RAM by some magic means totally
outside of normal operations of the CPU.

The first board that would meet such a description (and that I can
remember of) was the PN62 board; this was a PCI card, where the U-Boot
code was loaded into memory from the host while the CPU was helt in
reset, and subsequently it directly started executing from RAM.

Unfortunately I cannot check currently if my memory is correct and
PN62 was also where we introduced that variable (at that time under
the name CFG_RAMBOOT), as this was before U-Boot (still in PPCBoot)
and I only have the old CVS repository for that archived somewhere.

The next example of "correct" use of CONFIG_SYS_RAMBOOT was when
Stefan Roese added support to the PPC440EPx based Sequoia board to run
an U-Boot image that had been loaded to RAM using a JTAG debugger.


In any case, RAMBOOT was supposed to be used for systems, where code
execution started in RAM right out of reset, i. e. without any other
boot device like NAND, SPI flash, SDcard or similar.


> current image was entered, regardless of how that came to be.  There
> should be some way to distinguish running from SRAM versus running from
> DDR, though.

I cannot see how this is related to the RAMBOOT discussion. Actually
I cannot even see why such distinguishing would be needed at all
(unless you have very specific ideas about the characteristics of
SRAM versus DDR on some systems): SRAM and DDR are just examples of
hardware implementations for the more generic term RAM, i. e.
writable system memory from wich code can be executed (in contrast to
some storage device from which no code can be executed without
previously loading it to RAM, like NAND, SPI flash, SDcard, USB
storage devices, hard disk drives, etc. etc.)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Hello! I'm from outer space,  and I've made myself look like a signa-
ture.  While  you  are reading this, I'm having sex with your eyes. I
know it feels good to you, because you're smiling. I'm very horny, so
send me to someone else when you've had enough. Thanks!
                              Sincerely, A Stranger in a Strange Land