[U-Boot] [PATCH v3 09/14] tegra20: add u-boot.t2 target

[Allen Martin <amartin@nvidia.com>]

On Mon, Jun 11, 2012 at 01:21:13PM -0700, Simon Glass wrote:
> Hi Allen,
> 
> On Mon, Jun 11, 2012 at 12:22 PM, Allen Martin <amartin at nvidia.com<mailto:amartin@nvidia.com>> wrote:
> On Sat, Jun 09, 2012 at 12:12:09PM -0700, Simon Glass wrote:
> > Hi Allen,
> >
> > On Fri, Jun 8, 2012 at 2:16 PM, Allen Martin <amartin at nvidia.com<mailto:amartin@nvidia.com><mailto:amartin at nvidia.com<mailto:amartin@nvidia.com>>> wrote:
> > Add target for tegra20 u-boot image.  This is a concatenation of tegra
> > spl and normal u-boot binaries.
> >
> > Signed-off-by: Allen Martin <amartin at nvidia.com<mailto:amartin@nvidia.com><mailto:amartin at nvidia.com<mailto:amartin@nvidia.com>>>
> > ---
> >  .gitignore                      |    1 +
> >  Makefile                        |   11 +++++++++++
> >  board/nvidia/seaboard/config.mk<http://config.mk><http://config.mk> |    1 +
> >  3 files changed, 13 insertions(+)
> >  create mode 100644 board/nvidia/seaboard/config.mk<http://config.mk><http://config.mk>
> >
> > diff --git a/.gitignore b/.gitignore
> > index 0f32fd8..b9192bf 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -39,6 +39,7 @@
> >  /u-boot.ais
> >  /u-boot.dtb
> >  /u-boot.sb<http://u-boot.sb><http://u-boot.sb>
> > +/u-boot.t2
> >
> > What does t2 mean? If it is a binary file of some sort  perhaps
> u-boot-t2.bin would be better?
> 
> It's just means "tegra2".  I was following the convention that other
> SPL builds use.  I don't have a strong opinion on the name though.
> 
> OK, still would prefer a .bin on the end, but up to you.

I'm ok with that, it keeps in line with the u-boot-dtb.bin

> 
> 
> > +ifeq ($(CONFIG_OF_SEPARATE),y)
> > +T2_UBOOT=$(obj)u-boot-dtb.bin
> > +else
> > +T2_UBOOT=$(obj)u-boot.bin
> > +endif
> >
> > What is this logic for? The dtb file is separate but that doesn't
> > necessarily mean that it must be immediately after the U-Boot
> > image. We provide other options for packaging it, like
> > getenv(). Maybe if you want to create this composite binary you
> > should change its name (u-boot-dtb-t2.bin or u-boot-t2.bin) to
> > indicate what it contains?
> 
> This just picks up the name of the u-boot binary so it glues the SPL
> to the right thing depending if devicetree is in use or not.
> 
> OK, to avoid confusion I think you should change the name to include
> the -dtb or not, rather than having a filename without the -dtb part
> which does in fact include a dtb.

Ok.

> > I echo Stephen's comments. But also SPL is supposed to load U-Boot,
> > so shouldn't this t2 binary do that?
> 
> The t2 binary is the SPL and u-boot concatenated together into one
> binary.  The whole thing will get loaded into memory by the tegra
> BootROM.  The SPL knows the address of the real u-boot at compile time
> and uses that as the address for the Cortex A9 to jump to when it
> comes out of reset.
> 
> OK I see, makes sense. I am interested in your comments as to whether we might move to a 'true SPL' later, where U-Boot is actually loaded by SPL.

To keep this already complicated patch series under control I want to
just assume the SPL and regular u-boot are glued together for now, but
I'm definately thinking about the case where they are not.

In particular part of my motivation for this work is the ability to
have a version of the SPL that you can run in recovery mode when you
can't trust or don't have a BCT to initialize RAM.  In that case the
SPL would run out of IRAM and could take a BCT and u-boot from USB
DFU.  There's no reason it couldn't be extended to take those from
somewhere else the BootROM wouldn't normally be able to boot from like
SATA or network.  And it wouldn't have to be just in recovery mode
either I suppose.

-Allen
--
nvpublic