> -----Original Message-----
> From: u-boot-boun...@lists.denx.de
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Kyungmin Park
> Sent: Tuesday, September 14, 2010 7:48 PM
> To: Stefan Roese
> Cc: u-boot@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 <s...@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:
> off...@denx.de
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> >
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
