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

[Scott Wood]

On Tue, 2014-02-04 at 08:03 +0100, Wolfgang Denk wrote:
> 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.

Why does U-Boot care, though, whether the means were totally outside the
normal operations of the CPU, or something that was done by some other
software component running on the CPU?  What U-Boot needs to know is the
present state of the system.

> > 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.

It's related because it's part of what CONFIG_RAMBOOT_PBL is being used
to indicate.

> 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.)

The difference is relevant (at least on some platforms) because U-Boot
needs to know which TLB entries to have during early boot, whether it
needs to initialize the DDR controller, whether the cache is currently
configured as an SRAM, etc.

Perhaps it could detect this information at runtime, but currently it
does not for at least some of the above.  It also affects the
pre-relocation link address, which must be compile time (but doesn't
necessarily need a symbol that's visible outside the board config file).

-Scott