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

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

[Vipin Kumar]

Hello,

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.

Thanks in advance

Regards
Vipin

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

[Mike Frysinger]

On Tuesday, September 14, 2010 01:22:10 Vipin Kumar 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.

i dont think there is
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100914/7e7e57d4/attachment.pgp 

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

[Stefan Roese]

Hi Vipin,

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.

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.

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] Multiple binaries built through u-boot source

[Kyungmin Park]

On Tue, Sep 14, 2010 at 4:16 PM, Stefan Roese <sr@denx.de> wrote:
> Hi Vipin,
>
> 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.
>
> 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.

Same method.
OneNAND IPL (2KiB, 8KiB or 16KiB) combined with u-boot.bin and
generate u-boot-onenand.bin

OneNAND IPL (at SRAM) load the u-boot.bin to DRAM and jump to u-boot address.

Thank you,
Kyungmin Park

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

[Vipin Kumar]

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.
> 
> 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.
> 

Yes, got it. The only point is that this is meant to boot from NAND, ONENAND 
devices(As the name suggests). Can there be a generic interface independent 
of a particular device.

Offcourse I agree that execute in place would work for NOR devices and we wont 
need this kinda solution but still a generic solution for both types of devices 
is preferable

Regards
Vipin

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

[Stefan Roese]

Hi Vipin,

On Tuesday 14 September 2010 12:21:41 Vipin Kumar wrote:
> > 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.
> 
> Yes, got it. The only point is that this is meant to boot from NAND,
> ONENAND devices(As the name suggests). Can there be a generic interface
> independent of a particular device.
> 
> Offcourse I agree that execute in place would work for NOR devices and we
> wont need this kinda solution but still a generic solution for both types
> of devices is preferable

Sure, a more generic approach would be better. But I suspect that this is not 
so easy to do. Those tight image-size restrictions of the IPL/SPL loaders will 
make such generalisation efforts quite difficult.

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] Multiple binaries built through u-boot source

[Mike Frysinger]

On Tuesday, September 14, 2010 08:40:55 Stefan Roese wrote:
> On Tuesday 14 September 2010 12:21:41 Vipin Kumar wrote:
> > > 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.
> > 
> > Yes, got it. The only point is that this is meant to boot from NAND,
> > ONENAND devices(As the name suggests). Can there be a generic interface
> > independent of a particular device.
> > 
> > Offcourse I agree that execute in place would work for NOR devices and we
> > wont need this kinda solution but still a generic solution for both types
> > of devices is preferable
> 
> Sure, a more generic approach would be better. But I suspect that this is
> not so easy to do. Those tight image-size restrictions of the IPL/SPL
> loaders will make such generalisation efforts quite difficult.

there should at least be a build system unification if the general source code 
isnt possible.  all Blackfin builds now (LDRs) have a dedicated binary to 
initialize memory before any of u-boot is loaded.  this is the "initcode" 
stuff in the blackfin cpu dir.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100914/a769ee6c/attachment.pgp 

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

[V, Aneesh]

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] Multiple binaries built through u-boot source

[Stefan Roese]

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'?

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
...

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] Multiple binaries built through u-boot source

[Kyungmin Park]

On Tue, Sep 14, 2010 at 10:51 PM, Stefan Roese <sr@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)?

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] Multiple binaries built through u-boot source

[Vaibhav Bedia]

On Tue, Sep 14, 2010 at 7:03 PM, V, Aneesh <aneesh@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

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

[Stefan Roese]

Hi Kyungmin,

On Tuesday 14 September 2010 16:18:00 Kyungmin Park wrote:
> >> 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.

mmc_ipl? This is not in mainline yet.
 
> > 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)?

Correct. That's how IBM/AMCC called this code first loaded from NAND in their 
documentation. IPL (Initial Program Loader) was used for the ROM code inside 
the SoC, loading this SPL code from NAND.

Please note that I don't have a strong preference here. We could also call 
this first loader stage in the U-Boot source "IPL". But we should move to one 
name and stop mixing these names.

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] Multiple binaries built through u-boot source

[Kyungmin Park]

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

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

[Kyungmin Park]

On Tue, Sep 14, 2010 at 11:26 PM, Stefan Roese <sr@denx.de> wrote:
> Hi Kyungmin,
>
> On Tuesday 14 September 2010 16:18:00 Kyungmin Park wrote:
>> >> 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.
>
> mmc_ipl? This is not in mainline yet.
Right, I will tell the person to posting it.
>
>> > 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)?
>
> Correct. That's how IBM/AMCC called this code first loaded from NAND in their
> documentation. IPL (Initial Program Loader) was used for the ROM code inside
> the SoC, loading this SPL code from NAND.
>
> Please note that I don't have a strong preference here. We could also call
> this first loader stage in the U-Boot source "IPL". But we should move to one
> name and stop mixing these names.
Okay first explain our case.

BootROM code -> Initial Program Loader (runs on OneNAND 1KiB or
internal RAM) -> u-boot (secondary bootloader).
IPL configure the DRAM and loads the secondary bootloader, u-boot and jump it.

It's another story but I introduce the fastboot between IPL and
u-boot. So if normal boot, fastboot load the kernel and jump it. if
not, e.g., debug or usb download. then jump to u-boot and handle it.
In this case I call it Second BootLoader (SBL).

I also don't preference. just decide and use it.

Thank you,
Kyungmin Park

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

[Mike Frysinger]

On Tuesday, September 14, 2010 10:32:21 Kyungmin Park wrote:
> BootROM code -> Initial Program Loader (runs on OneNAND 1KiB or
> internal RAM) -> u-boot (secondary bootloader).
> IPL configure the DRAM and loads the secondary bootloader, u-boot and jump
> it.

the IPL may or may not handle loading of u-boot.  in the Blackfin case:
BootROM -> IPL (program memory/clocks) -> return to BootROM which handles 
loading of and then jumping to u-boot.

more in-depth documentation can be found here:
http://docs.blackfin.uclinux.org/doku.php?id=bootloaders
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100914/f0748b8b/attachment.pgp 

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

[Wolfgang Denk]

Dear "V, Aneesh",

In message <FF55437E1F14DA4BAEB721A458B6701706C58885A2@dbde02.ent.ti.com> you wrote:
> 
> 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 would be greatly appreciated.

> 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'?

Fr now we can stick with the nand_spl name (even if it's becoming a
bit misleading); if other use cases get added we can discuss to rename
it.  Please no not create yet another such directory.  I think we
should concentrate such code in one location.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A stone was placed at a ford in a river with the inscription:
"When this stone is covered it is dangerous to ford here."

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

[Scott Wood]

On Tue, 14 Sep 2010 18:17:47 +0200
Wolfgang Denk <wd@denx.de> wrote:

> Dear "V, Aneesh",
> 
> In message <FF55437E1F14DA4BAEB721A458B6701706C58885A2@dbde02.ent.ti.com> you wrote:
> > 
> > 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 would be greatly appreciated.
> 
> > 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'?
> 
> Fr now we can stick with the nand_spl name (even if it's becoming a
> bit misleading);

I'd rather just change the name now -- misleading is bad whether
there's one exception or several.

> if other use cases get added we can discuss to rename it.

Someone just internally posted a patch adding "i2c_spl", FWIW.

-Scott

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

[Stefan Roese]

On Wednesday 15 September 2010 18:36:02 Scott Wood wrote:
> > > 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'?
> > 
> > Fr now we can stick with the nand_spl name (even if it's becoming a
> > bit misleading);
> 
> I'd rather just change the name now -- misleading is bad whether
> there's one exception or several.

Yes, I would prefer this renaming right now as well.

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] Multiple binaries built through u-boot source

[Wolfgang Denk]

Dear Scott Wood,

In message <20100915113602.52666885@schlenkerla.am.freescale.net> you wrote:
>
> > Fr now we can stick with the nand_spl name (even if it's becoming a
> > bit misleading);
> 
> I'd rather just change the name now -- misleading is bad whether
> there's one exception or several.

OK - suggest a new name, please?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Microsoft Multitasking:
                     several applications can crash at the same time.

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

[Scott Wood]

On Wed, 15 Sep 2010 19:45:17 +0200
Wolfgang Denk <wd@denx.de> wrote:

> Dear Scott Wood,
> 
> In message <20100915113602.52666885@schlenkerla.am.freescale.net> you wrote:
> >
> > > Fr now we can stick with the nand_spl name (even if it's becoming a
> > > bit misleading);
> > 
> > I'd rather just change the name now -- misleading is bad whether
> > there's one exception or several.
> 
> OK - suggest a new name, please?

Plain "spl" is fine with me, or perhaps something like "bootstrap" or 
"preboot" would be clearer.

-Scott

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

[Wolfgang Denk]

Dear Scott Wood,

In message <20100915130155.7e7b2039@schlenkerla.am.freescale.net> you wrote:
>
> > OK - suggest a new name, please?
> 
> Plain "spl" is fine with me, or perhaps something like "bootstrap" or 
> "preboot" would be clearer.

"spl" is OK with me. The other two might cause discussions (all
U-Boot is about how to "bootstrap" an OS, and what exactly is the
"boot" that is preceeded by preboot?).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"More software projects have gone awry for lack of calendar time than
for all other causes combined."
                         - Fred Brooks, Jr., _The Mythical Man Month_

[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@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
> 

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

[Scott Wood]

On Thu, 16 Sep 2010 21:14:57 +0530
"Premi, Sanjeev" <premi@ti.com> wrote:

> [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 

NAND SPL typically needs to fit in just 4 KiB (sometimes even less).

>      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, ...

Those things are configurable.  That doesn't mean we don't need
makefile infrastructure to build the two (or sometimes three) separate
images, or some special code for an extremely minimal image.

-Scott

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

[Mike Frysinger]

On Thursday, September 16, 2010 11:44:57 Premi, Sanjeev wrote:
>      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

the Blackfin one is in the range of 200-600 bytes.  i dont care how 
configurable you make u-boot, it isnt getting to that.

>      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, ...

yes, we should do this anyways.  i have another use of u-boot where i wanted 
it down to the 30KiB range, and that required posting patches to make things 
more configurable.  most have been merged already.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100916/ae727bfa/attachment.pgp 

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

[Premi, Sanjeev]

> -----Original Message-----
> From: Scott Wood [mailto:scottwood at freescale.com] 
> Sent: Thursday, September 16, 2010 11:30 PM
> To: Premi, Sanjeev
> Cc: Kyungmin Park; Stefan Roese; u-boot at lists.denx.de; Shiraz HASHIM
> Subject: Re: [U-Boot] Multiple binaries built through u-boot source
> 
> On Thu, 16 Sep 2010 21:14:57 +0530
> "Premi, Sanjeev" <premi@ti.com> wrote:
> 
> > [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 
> 
> NAND SPL typically needs to fit in just 4 KiB (sometimes even less).
> 
> >      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, ...
> 
> Those things are configurable.  That doesn't mean we don't need
> makefile infrastructure to build the two (or sometimes three) separate
> images, or some special code for an extremely minimal image.

[sp] Yes. When we need to be "extremely" small separate infra may be
     needed. But for rest, I feel we could/ should continue using the
     generic makefile infra - with more configuration options - that
     keeps maintenance low.

     I also feel that needs/requirements for the extremely small images
     will differ between the users. Maintaining compatibility will be
     a challenge for a common codebase.

~sanjeev

> 
> -Scott
> 
> 

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

[Premi, Sanjeev]

> -----Original Message-----
> From: Mike Frysinger [mailto:vapier at gentoo.org] 
> Sent: Friday, September 17, 2010 12:02 AM
> To: u-boot at lists.denx.de
> Cc: Premi, Sanjeev; Kyungmin Park; Stefan Roese; Shiraz HASHIM
> Subject: Re: [U-Boot] Multiple binaries built through u-boot source
> 
> On Thursday, September 16, 2010 11:44:57 Premi, Sanjeev wrote:
> >      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
> 
> the Blackfin one is in the range of 200-600 bytes.  i dont care how 
> configurable you make u-boot, it isnt getting to that.
> 
> >      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, ...
> 
> yes, we should do this anyways.  i have another use of u-boot 
> where i wanted 
> it down to the 30KiB range, and that required posting patches 
> to make things 
> more configurable.  most have been merged already.

[sp] I will rebase my work on latest and submit patches.

~sanjeev

> -mike
>