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

Kyungmin Park kmpark at infradead.org
Tue Sep 14 16:26:36 CEST 2010


On Tue, Sep 14, 2010 at 11:22 PM, Vaibhav Bedia <vaibhav.bedia at gmail.com> wrote:
> 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.

Right, First OneNAND IPL based on x-loader and used for OMAP2 board.
and I integrate it into u-boot as onenand_ipl.
To reduce the code size, I introduced the CONFIG_ONENAND_IPL and
someone change it to CONFIG_PRELOADER for use both NAND and OneNAND.
>
> 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.

OneNAND IPL ues the symlink method and compile the code only when
CONFIG_PRELOADER is defined.
you can find it at arm/*/start.S. As I remover arm1176 and armv7 support it.

Thank you,
Kyungmin Park
>
> 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
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>


More information about the U-Boot mailing list