[U-Boot] Building two different "SPL" for the same board?
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
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.
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
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.
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
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,
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.
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/79272ff764ee392d616feb02f...
Will show up for review in next round of submitting the sunxi changes.
Regards Henrik
participants (3)
-
Albert ARIBAUD -
Henrik Nordström -
Tom Rini