[U-Boot] Multiple binaries built through u-boot source

[Premi, Sanjeev]

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de 
> [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Kyungmin Park
> Sent: Tuesday, September 14, 2010 7:48 PM
> To: Stefan Roese
> Cc: u-boot at lists.denx.de; Shiraz HASHIM
> Subject: Re: [U-Boot] Multiple binaries built through u-boot source
> 
> On Tue, Sep 14, 2010 at 10:51 PM, Stefan Roese <sr at denx.de> wrote:
> > Hi Aneesh,
> >
> > On Tuesday 14 September 2010 15:33:53 V, Aneesh wrote:
> >> > >> I wanted to know if there is a generic way to create two
> >> > >> binaries from the u-boot source both compiled for different
> >> > >> address ranges. The first initializes the RAM (may be
> >> > >> something else as well) and the second is the u-boot binary
> >> > >> responsible for loading OS etc.
> >>
> >> It's sheer coincidence that I also wanted to post a very 
> similar query
> >> today. We have a similar requirement for OMAP platforms.
> >>
> >> Presently, we are maintaining a mini bootloader(called 
> x-loader, based
> >> on u-boot)separately. We want to integrate x-loader with u-boot and
> >> up-stream the source code.
> >
> > That's definitely a good idea.
> >
> >> > > Take a look at the NAND_SPL infrastructure (nand_spl/*). It was
> >> > > created for
> >> > > platforms booting from NAND with tight restrictions 
> (e.g. 4k image
> >> > > size for
> >> > > inital setup, mostly DDR). General idea here is that 2 
> images are
> >> > > created:
> >> > > a) Very small SPL (secondary program loader) image 
> with only basic
> >> > >    setup, like DDR and NAND
> >> > >
> >> > > b) RAM based U-Boot image
> >> > >
> >> > > Both images are combined in the build process creating a single
> >> > > image that can be flashed into NAND.
> >> > >
> >> > > doc/README.nand-boot-ppc440 might be interesting to 
> get some more
> >> > > infos about this, some of it PPC4xx specific though.
> >>
> >> This looks promising. However, our SPL has to load u-boot 
> from MMC. Is
> >> it OK to keep it under nand_spl directory or should we create
> >> something like 'mmc_spl'?
> 
> Good question, It created the mmc_ipl and use it for mmc booting e.g.,
> eMMC boot.
> 
> >
> > Not sure. Perhaps we should now really think about a more 
> generic approach and
> > merge all this IPL/SPL stuff into a single directory. 
> Perhaps something like
> > this:
> >
> > spl/
> > spl/nand
> > spl/onenand
> > spl/mmc
> > spl/board
> 
> Good, and use the CONFIG_PRELOADER as existing. but what's the SPL
> stand for? SPL (secondary program loader)?
> 

[sp] I was pointed to this thread through another discussion. I did
     see (almost) an agreement reached here.

     But, wanted to share my experience on the same topic. Posed with
     same problem, I had looked at minimizing the u-boot binary and
     had managed to reach 29-30KB 

     In short, shouldn't we make u-boot more "configurable" so that
     parts we consider "integral" in u-boot today can also be excluded
     e.g. support for unzip, tftp, ...

Best regards,
Sanjeev

> Thank you,
> Kyungmin Park
> > ...
> >
> > Comments welcome.
> >
> > Cheers,
> > Stefan
> >
> > --
> > DENX Software Engineering GmbH,      MD: Wolfgang Denk & 
> Detlev Zundel
> > HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 
> Groebenzell, Germany
> > Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: 
> office at denx.de
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> >
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>