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

[Vaibhav Bedia]

On Tue, Sep 14, 2010 at 7:03 PM, V, Aneesh <aneesh at ti.com> wrote:

> Hi,
>
> > -----Original Message-----
> > From: u-boot-bounces at lists.denx.de [mailto:u-boot-
> > bounces at lists.denx.de] On Behalf Of Vipin Kumar
> > Sent: Tuesday, September 14, 2010 3:52 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 9/14/2010 12:46 PM, Stefan Roese wrote:
> > Hello Stefan,
> >
> > > On Tuesday 14 September 2010 07:22:10 Vipin Kumar wrote:
> > >> This is about a generic problem which may also be faced
> > >> by other developers. Our SoC has a masked bootrom area
> > >> which copies an image from NOR/NAND memories to an internal
> > >> embedded SRAM. The size of this SRAM is only 8K. This
> > >> binary initializes the DDR for larger binaries (u-boot/OS)
> > >> to be placed in RAM and executed from there.
> > >>
> > >> 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.
>
>
> > >
> > > 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'?
>
>
> Best regards,
> Aneesh
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

Hi,

On TI's OMAP based devices there is a minimal bootloader called as xloader
based on U-Boot. It which takes care of initializing the RAM and loads the
U-Boot binary built from the denx tree.

The directory structure,

ONENAND_spl does seem to based on xloader from the info by the author in the
source code.

Although it is possible to achieve significant size reduction by making
minimal changes to the U-Boot code, problems come in when we have to
selectively include some features and not make use of the whole framework
due to the size limitation of the initial program loader.

Since the directory structure, the build system and flow of xloader is
similar to U-Boot.. how about leveraging this for making the spl generic?

If linking against the various drivers directly instead of using the whole
framework is fine then we could have a common source for both the initial
loader and full fledged U-Boot.

-- 
Regards,
Vaibhav