[U-Boot] Building two different "SPL" for the same board?

[U-Boot] Building two different "SPL" for the same board?

[Henrik Nordström]

I am looking into reusing the SPL system initialization part for a very
minimalistic "SPL" which only initializes the board.

To give a bit of context, on the Allwinner CPUs there is a recovery boot
mode where data can be copied over USB and executed by the CPU. But most
of the board including DRAM controller is not initialized by default so
the very first thing you need to do is to upload & execute board
initialization code (but excluding CPU initialization).

Note: It is not really an SPL as all it does is initializing the board
and then returning control to the USB loader so additional code
(u-boot.bin) can be uploaded to DRAM and executed.

I have this implemented today partially out-of-tree leaching objects
from an u-boot build to build a binary with the initialization code. My
question is if it would make sense to try integrate this into the u-boot
tree somehow. Have something similar been done for any other board?

The current "code" is at
https://github.com/linux-sunxi/sunxi-tools/tree/master/felboot
mainly main.c (entry + stubs), the rest is only for a small printf and
is not needed.

Regards
Henrik

[U-Boot] Building two different "SPL" for the same board?

[Tom Rini]

On Fri, May 17, 2013 at 08:06:07PM +0200, Henrik Nordstr?m wrote:

> I am looking into reusing the SPL system initialization part for a very
> minimalistic "SPL" which only initializes the board.
> 
> To give a bit of context, on the Allwinner CPUs there is a recovery boot
> mode where data can be copied over USB and executed by the CPU. But most
> of the board including DRAM controller is not initialized by default so
> the very first thing you need to do is to upload & execute board
> initialization code (but excluding CPU initialization).
> 
> Note: It is not really an SPL as all it does is initializing the board
> and then returning control to the USB loader so additional code
> (u-boot.bin) can be uploaded to DRAM and executed.
> 
> I have this implemented today partially out-of-tree leaching objects
> from an u-boot build to build a binary with the initialization code. My
> question is if it would make sense to try integrate this into the u-boot
> tree somehow. Have something similar been done for any other board?
> 
> The current "code" is at
> https://github.com/linux-sunxi/sunxi-tools/tree/master/felboot
> mainly main.c (entry + stubs), the rest is only for a small printf and
> is not needed.

I would say you want to hypothetically add a _felboot build target for
the allwinner boards that instead of building out a regular
CONFIG_SPL_FRAMEWORK (I hope!) SPL spits out just a very tiny one that
does what you need for this use case.  Having different builds for
different SPL cases is a normal thing that we do on a few boards, but
none are quite so drastically different sounding as this.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130517/8fb02c24/attachment.pgp>

[U-Boot] Building two different "SPL" for the same board?

[Henrik Nordström]

fre 2013-05-17 klockan 14:17 -0400 skrev Tom Rini:

> I would say you want to hypothetically add a _felboot build target for
> the allwinner boards that instead of building out a regular
> CONFIG_SPL_FRAMEWORK (I hope!) SPL spits out just a very tiny one that
> does what you need for this use case.  Having different builds for
> different SPL cases is a normal thing that we do on a few boards, but
> none are quite so drastically different sounding as this.

Yes the main SPL is using CONFIG_SPL_FRAMEWORK. But the low level board
initialization is done in s_init (via lowlevel_init).

This other boot helper is basically only calling s_init() and then
returns to the caller with the board now configured in a reasonable
state allowing it to accept u-boot.bin to be uploaded into SDRAM.

Regards
Henrik

[U-Boot] Building two different "SPL" for the same board?

[Tom Rini]

On Fri, May 17, 2013 at 10:56:25PM +0200, Henrik Nordstr?m wrote:
> fre 2013-05-17 klockan 14:17 -0400 skrev Tom Rini:
> 
> > I would say you want to hypothetically add a _felboot build target for
> > the allwinner boards that instead of building out a regular
> > CONFIG_SPL_FRAMEWORK (I hope!) SPL spits out just a very tiny one that
> > does what you need for this use case.  Having different builds for
> > different SPL cases is a normal thing that we do on a few boards, but
> > none are quite so drastically different sounding as this.
> 
> Yes the main SPL is using CONFIG_SPL_FRAMEWORK. But the low level board
> initialization is done in s_init (via lowlevel_init).
> 
> This other boot helper is basically only calling s_init() and then
> returns to the caller with the board now configured in a reasonable
> state allowing it to accept u-boot.bin to be uploaded into SDRAM.

If we can implement it cleanly, this isn't (at the 1000 meter view) all
that much different than what we do on some PowerPC platforms today
where everything must fit within a few kilobytes.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130522/276cdbce/attachment.pgp>

[U-Boot] Building two different "SPL" for the same board?

[Henrik Nordström]

ons 2013-05-22 klockan 11:26 -0400 skrev Tom Rini:

> If we can implement it cleanly, this isn't (at the 1000 meter view) all
> that much different than what we do on some PowerPC platforms today
> where everything must fit within a few kilobytes.

Yes it is quite doable. The pieces I have done should be possible to fit
without too much effort.

The question is more if these kinds of board initialization only
programs is seen as suitable for having in the u-boot tree.  It's not
really an SPL as it does not load anything, but it's 99.9% the same code
as used in u-boot SPL.

Regards
Henrik

[U-Boot] Building two different "SPL" for the same board?

[Albert ARIBAUD]

Hi Henrik,

On Thu, 23 May 2013 10:53:39 +0200, Henrik Nordstr?m
<henrik@henriknordstrom.net> wrote:

> ons 2013-05-22 klockan 11:26 -0400 skrev Tom Rini:
> 
> > If we can implement it cleanly, this isn't (at the 1000 meter view) all
> > that much different than what we do on some PowerPC platforms today
> > where everything must fit within a few kilobytes.
> 
> Yes it is quite doable. The pieces I have done should be possible to fit
> without too much effort.
> 
> The question is more if these kinds of board initialization only
> programs is seen as suitable for having in the u-boot tree.  It's not
> really an SPL as it does not load anything, but it's 99.9% the same code
> as used in u-boot SPL.

My opinion is that such code fits in U-Boot quite well. After all, SPL
too was "that much shorter bit of code that was run before U-Boot
because U-Boot is too large to load and run directly on this platform".
Granted, SPL now tends to outgrow itself -- to the point that it becomes
more of a 'lightweight U-Boot', as Falcon mode shows -- but obviously,
there is a need for a very short code piece that can fit in e.g. a NAND
access device's read buffer.

> Regards
> Henrik

Amicalement,
-- 
Albert.

[U-Boot] Building two different "SPL" for the same board?

[Tom Rini]

On Thu, May 23, 2013 at 10:53:39AM +0200, Henrik Nordstr?m wrote:

> ons 2013-05-22 klockan 11:26 -0400 skrev Tom Rini:
> 
> > If we can implement it cleanly, this isn't (at the 1000 meter view) all
> > that much different than what we do on some PowerPC platforms today
> > where everything must fit within a few kilobytes.
> 
> Yes it is quite doable. The pieces I have done should be possible to fit
> without too much effort.
> 
> The question is more if these kinds of board initialization only
> programs is seen as suitable for having in the u-boot tree.  It's not
> really an SPL as it does not load anything, but it's 99.9% the same code
> as used in u-boot SPL.

My rather poor understanding of how some of the Freescale ARM parts do
SPL is a lot more like this (whack things about, let ROM load next
parts) than the "SPL takes over, loads U-Boot" method.  And this is OK,
in so far as it gets needed jobs done in the resources available.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130523/6d3d34bb/attachment.pgp>

[U-Boot] Building two different "SPL" for the same board?

[Henrik Nordström]

tor 2013-05-23 klockan 16:39 -0400 skrev Tom Rini:

> My rather poor understanding of how some of the Freescale ARM parts do
> SPL is a lot more like this (whack things about, let ROM load next
> parts) than the "SPL takes over, loads U-Boot" method.  And this is OK,
> in so far as it gets needed jobs done in the resources available.

Got it integrated into the tree now and after config changes it could be
reduced to only a dummy (empty) start.c + linker script. The binary grew
by a few KB compared to the separate version, but still well within the
margin.

https://github.com/linux-sunxi/u-boot-sunxi/commit/79272ff764ee392d616feb02fb91c2dcaad42f04

Will show up for review in next round of submitting the sunxi changes.

Regards
Henrik