[U-Boot] Some thoughts on SPL
The CPU I'm working with, the LPC3130, is kind of an in-between CPU for SPL. Instead of a tightly constrained RAM of 16KB or so I have 96KB to work with. 96KB is enough room to support all of the various boot modes (uart, nand, spi, USB, etc) but not enough room for the full uboot command set. So I'm still stuck with the SPL model, but my constraints are much less.
One example of a conflict with SPL is NAND support. With SPL you hard code in the NAND type. In my case I have enough room to do NAND type detection. So this has me modifying the #ifdefs in the makefiles to include the NAND detection code in my SPL loader.
I'm wondering if SPL could be designed in a more generic manner. Another model would be to use SPL as the base layer for all u-boot builds. You would then start turning on features until full uboot capability was reached. An example of this would be NAND support, the default would be hard coded NAND for all u-boot builds, but turning on NAND detection would increase the size of the build and disable the hard coded support. Another default would be SPL chaining into the next image, turning on the u-boot UI would again make the code larger and disable auto-chaining.
The concept is to remove SPL as a special class and turn it into the base layer that everything builds on. Changing the model in this was should make the config files easier to understand. Instead of having a single file combining SPL and full u-boot you'd have two independent ones. In my case I'd build one u-boot config that fits into 96K and another full 250K one. Of course the two config files could each include a common base config.
Thoughts?
On 12/16/2011 11:20 AM, jonsmirl@gmail.com wrote:
The CPU I'm working with, the LPC3130, is kind of an in-between CPU for SPL. Instead of a tightly constrained RAM of 16KB or so I have
16K? Luxury! :-)
Many boards have only 4K, and IIRC some have only 2K.
96KB to work with. 96KB is enough room to support all of the various boot modes (uart, nand, spi, USB, etc) but not enough room for the full uboot command set. So I'm still stuck with the SPL model, but my constraints are much less.
All the SPL model is really supposed to be is makefile infrastructure for building the two stages. What code you pull in is configurable.
One example of a conflict with SPL is NAND support. With SPL you hard code in the NAND type.
This is only required with nand_spl_simple.c.
You could provide an alternate SPL driver, or even pull in the standard SPL stack if you want. No need to hack up nand_spl_simple.c.
I'm wondering if SPL could be designed in a more generic manner. Another model would be to use SPL as the base layer for all u-boot builds. You would then start turning on features until full uboot capability was reached.
A while back I suggested tracking a fully separate config for SPL, but Wolfgang didn't like it. Maybe a larger set of concrete use cases (and what it looks like to deal with each one manually as would currently be needed) would be convincing -- at the time it was just about having a separate CONFIG_SYS_TEXT_BASE_SPL.
-Scott
Hi,
On Fri, Dec 16, 2011 at 9:20 AM, jonsmirl@gmail.com jonsmirl@gmail.com wrote:
The CPU I'm working with, the LPC3130, is kind of an in-between CPU for SPL. Instead of a tightly constrained RAM of 16KB or so I have 96KB to work with. 96KB is enough room to support all of the various boot modes (uart, nand, spi, USB, etc) but not enough room for the full uboot command set. So I'm still stuck with the SPL model, but my constraints are much less.
One example of a conflict with SPL is NAND support. With SPL you hard code in the NAND type. In my case I have enough room to do NAND type detection. So this has me modifying the #ifdefs in the makefiles to include the NAND detection code in my SPL loader.
I'm wondering if SPL could be designed in a more generic manner. Another model would be to use SPL as the base layer for all u-boot builds. You would then start turning on features until full uboot capability was reached. An example of this would be NAND support, the default would be hard coded NAND for all u-boot builds, but turning on NAND detection would increase the size of the build and disable the hard coded support. Another default would be SPL chaining into the next image, turning on the u-boot UI would again make the code larger and disable auto-chaining.
The concept is to remove SPL as a special class and turn it into the base layer that everything builds on. Changing the model in this was should make the config files easier to understand. Instead of having a single file combining SPL and full u-boot you'd have two independent ones. In my case I'd build one u-boot config that fits into 96K and another full 250K one. Of course the two config files could each include a common base config.
Thoughts?
That's one way to do it, and makes more and more sense as the amount of available SRAM increases. Of course some SOCs can even set up their SDRAM and read entire programs in, so there are no restrictions. But for those with limitations, it makes sense to me to make SPL more a cut down build of U-Boot than a special program that pulls in #ifdefed code from various places.
Another approach is to just have one U-Boot, but keep everything you need to get started in the first 96KB.
I have the beginnings of a patch which allows you to split U-Boot into two parts: an initial part which is loaded first, and another part which can be loaded later if needed.
It works by telling the linker where to put the code and arranging that everything you need early is at the start of the image. During my recent forays into SPL I formed the view that it might be another way to implement the SPL functionality. It is controlled by a config file which specifies function symbols, object files or libraries to include in the initial region. It can also work from a run-time profile.
There are problems though. It is normally pretty easy to work out (or profile) which code is executed, but it is harder to know which data is needed. SPL solves this by linking and the resulting link errors when you get it wrong are easy to spot. But I don't have a tool that checks that all the code and data you need is within a certain region. Static inline functions can be a pain since they appear repeated all over the text area. Relocation data needs to stored with the loaded section.
In short this 'postload' feature is more complex, but more general. Might be useful one day.
Regards, Simon
-- Jon Smirl jonsmirl@gmail.com _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
The old lpc3130 port works the way you describe. The problem with it is that it is on a three year old u-boot. http://git.lpclinux.com/
It builds a single u-boot image and then slices the SPL piece off from the front of it.
On Sat, Dec 17, 2011 at 12:38 AM, Simon Glass sjg@chromium.org wrote:
Hi,
On Fri, Dec 16, 2011 at 9:20 AM, jonsmirl@gmail.com jonsmirl@gmail.com wrote:
The CPU I'm working with, the LPC3130, is kind of an in-between CPU for SPL. Instead of a tightly constrained RAM of 16KB or so I have 96KB to work with. 96KB is enough room to support all of the various boot modes (uart, nand, spi, USB, etc) but not enough room for the full uboot command set. So I'm still stuck with the SPL model, but my constraints are much less.
One example of a conflict with SPL is NAND support. With SPL you hard code in the NAND type. In my case I have enough room to do NAND type detection. So this has me modifying the #ifdefs in the makefiles to include the NAND detection code in my SPL loader.
I'm wondering if SPL could be designed in a more generic manner. Another model would be to use SPL as the base layer for all u-boot builds. You would then start turning on features until full uboot capability was reached. An example of this would be NAND support, the default would be hard coded NAND for all u-boot builds, but turning on NAND detection would increase the size of the build and disable the hard coded support. Another default would be SPL chaining into the next image, turning on the u-boot UI would again make the code larger and disable auto-chaining.
The concept is to remove SPL as a special class and turn it into the base layer that everything builds on. Changing the model in this was should make the config files easier to understand. Instead of having a single file combining SPL and full u-boot you'd have two independent ones. In my case I'd build one u-boot config that fits into 96K and another full 250K one. Of course the two config files could each include a common base config.
Thoughts?
That's one way to do it, and makes more and more sense as the amount of available SRAM increases. Of course some SOCs can even set up their SDRAM and read entire programs in, so there are no restrictions. But for those with limitations, it makes sense to me to make SPL more a cut down build of U-Boot than a special program that pulls in #ifdefed code from various places.
Another approach is to just have one U-Boot, but keep everything you need to get started in the first 96KB.
I have the beginnings of a patch which allows you to split U-Boot into two parts: an initial part which is loaded first, and another part which can be loaded later if needed.
It works by telling the linker where to put the code and arranging that everything you need early is at the start of the image. During my recent forays into SPL I formed the view that it might be another way to implement the SPL functionality. It is controlled by a config file which specifies function symbols, object files or libraries to include in the initial region. It can also work from a run-time profile.
There are problems though. It is normally pretty easy to work out (or profile) which code is executed, but it is harder to know which data is needed. SPL solves this by linking and the resulting link errors when you get it wrong are easy to spot. But I don't have a tool that checks that all the code and data you need is within a certain region. Static inline functions can be a pain since they appear repeated all over the text area. Relocation data needs to stored with the loaded section.
In short this 'postload' feature is more complex, but more general. Might be useful one day.
Regards, Simon
-- Jon Smirl jonsmirl@gmail.com _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Dear Simon Glass,
In message CAPnjgZ0E4RfzzL2tfff=CN0xQ5OV+v-QTQNy3s3zb6hn7svV2g@mail.gmail.com you wrote:
On Fri, Dec 16, 2011 at 9:20 AM, jonsmirl@gmail.com jonsmirl@gmail.com wr= ote:
...
The concept is to remove SPL as a special class and turn it into the base layer that everything builds on. Changing the model in this was should make the config files easier to understand. Instead of having a single file combining SPL and full u-boot you'd have two independent ones. In my case I'd build one u-boot config that fits into 96K and another full 250K one. Of course the two config files could each include a common base config.
...
That's one way to do it, and makes more and more sense as the amount of available SRAM increases. Of course some SOCs can even set up their SDRAM and read entire programs in, so there are no restrictions. But for those with limitations, it makes sense to me to make SPL more a cut down build of U-Boot than a special program that pulls in #ifdefed code from various places.
Another approach is to just have one U-Boot, but keep everything you need to get started in the first 96KB.
Please keep in mind that there is also a large number of boards that boot form some boot ROM (like NOR flash), i. e. that can directly execute _all_ U-Boot code, without need of any SPL at all.
Any changes to the design of the SPL must not have any adverse effects on such XIP booting systems.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Sat, Dec 17, 2011 at 12:08 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message CAPnjgZ0E4RfzzL2tfff=CN0xQ5OV+v-QTQNy3s3zb6hn7svV2g@mail.gmail.com you wrote:
On Fri, Dec 16, 2011 at 9:20 AM, jonsmirl@gmail.com jonsmirl@gmail.com wr= ote:
...
The concept is to remove SPL as a special class and turn it into the base layer that everything builds on. Changing the model in this was should make the config files easier to understand. Instead of having a single file combining SPL and full u-boot you'd have two independent ones. In my case I'd build one u-boot config that fits into 96K and another full 250K one. Of course the two config files could each include a common base config.
...
That's one way to do it, and makes more and more sense as the amount of available SRAM increases. Of course some SOCs can even set up their SDRAM and read entire programs in, so there are no restrictions. But for those with limitations, it makes sense to me to make SPL more a cut down build of U-Boot than a special program that pulls in #ifdefed code from various places.
Another approach is to just have one U-Boot, but keep everything you need to get started in the first 96KB.
Please keep in mind that there is also a large number of boards that boot form some boot ROM (like NOR flash), i. e. that can directly execute _all_ U-Boot code, without need of any SPL at all.
Any changes to the design of the SPL must not have any adverse effects on such XIP booting systems.
This is a degenerate case for the system I describe - where all the code is in the first part and the second part is empty. It adds nothing but for the extra build complexity already mentioned. I'm not involved enough in SPL yet to be able to say how useful all this is, perhaps later.
Regards, Simon
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@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_
On Sun, Dec 18, 2011 at 12:55 AM, Simon Glass sjg@chromium.org wrote:
Hi Wolfgang,
On Sat, Dec 17, 2011 at 12:08 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message CAPnjgZ0E4RfzzL2tfff=CN0xQ5OV+v-QTQNy3s3zb6hn7svV2g@mail.gmail.com you wrote:
On Fri, Dec 16, 2011 at 9:20 AM, jonsmirl@gmail.com jonsmirl@gmail.com wr= ote:
...
The concept is to remove SPL as a special class and turn it into the base layer that everything builds on. Changing the model in this was should make the config files easier to understand. Instead of having a single file combining SPL and full u-boot you'd have two independent ones. In my case I'd build one u-boot config that fits into 96K and another full 250K one. Of course the two config files could each include a common base config.
...
That's one way to do it, and makes more and more sense as the amount of available SRAM increases. Of course some SOCs can even set up their SDRAM and read entire programs in, so there are no restrictions. But for those with limitations, it makes sense to me to make SPL more a cut down build of U-Boot than a special program that pulls in #ifdefed code from various places.
Another approach is to just have one U-Boot, but keep everything you need to get started in the first 96KB.
Please keep in mind that there is also a large number of boards that boot form some boot ROM (like NOR flash), i. e. that can directly execute _all_ U-Boot code, without need of any SPL at all.
Any changes to the design of the SPL must not have any adverse effects on such XIP booting systems.
This is a degenerate case for the system I describe - where all the code is in the first part and the second part is empty. It adds nothing but for the extra build complexity already mentioned. I'm not involved enough in SPL yet to be able to say how useful all this is, perhaps later.
I agree, we are thinking about a change in the build process. The binaries produced would still function as they currently do.
Regards, Simon
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@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_
On Fri, Dec 16, 2011 at 10:20 AM, jonsmirl@gmail.com jonsmirl@gmail.com wrote:
The CPU I'm working with, the LPC3130, is kind of an in-between CPU for SPL. Instead of a tightly constrained RAM of 16KB or so I have 96KB to work with. 96KB is enough room to support all of the various boot modes (uart, nand, spi, USB, etc) but not enough room for the full uboot command set. So I'm still stuck with the SPL model, but my constraints are much less.
One example of a conflict with SPL is NAND support. With SPL you hard code in the NAND type. In my case I have enough room to do NAND type detection. So this has me modifying the #ifdefs in the makefiles to include the NAND detection code in my SPL loader.
I'm wondering if SPL could be designed in a more generic manner. Another model would be to use SPL as the base layer for all u-boot builds. You would then start turning on features until full uboot capability was reached. An example of this would be NAND support, the default would be hard coded NAND for all u-boot builds, but turning on NAND detection would increase the size of the build and disable the hard coded support. Another default would be SPL chaining into the next image, turning on the u-boot UI would again make the code larger and disable auto-chaining.
So, in chasing down another problem I was having (that turned out unrelated) I just made SPL use the full NAND stack. It wouldn't be difficult to add CONFIG_SPL_FULL_NAND_SUPPORT (and either keep the existing name for nand_spl_simple or rename to CONFIG_SPL_MIN_NAND_SUPPORT). I've even got the tree I did that hack in around on github if you want a reference.
On 12/20/2011 09:38 AM, Tom Rini wrote:
So, in chasing down another problem I was having (that turned out unrelated) I just made SPL use the full NAND stack. It wouldn't be difficult to add CONFIG_SPL_FULL_NAND_SUPPORT
How about CONFIG_SPL_NAND_FULL?
(and either keep the existing name for nand_spl_simple or rename to CONFIG_SPL_MIN_NAND_SUPPORT).
Please keep it as CONFIG_SPL_NAND_SIMPLE. There will be other NAND SPL implementations besides "simple" and "full" once we migrate over the existing nand_spl users.
-Scott
On Tue, Dec 20, 2011 at 1:48 PM, Scott Wood scottwood@freescale.com wrote:
On 12/20/2011 09:38 AM, Tom Rini wrote:
So, in chasing down another problem I was having (that turned out unrelated) I just made SPL use the full NAND stack. It wouldn't be difficult to add CONFIG_SPL_FULL_NAND_SUPPORT
How about CONFIG_SPL_NAND_FULL?
(and either keep the existing name for nand_spl_simple or rename to CONFIG_SPL_MIN_NAND_SUPPORT).
Please keep it as CONFIG_SPL_NAND_SIMPLE. There will be other NAND SPL implementations besides "simple" and "full" once we migrate over the existing nand_spl users.
OK, I only opened up README.SPL which says CONFIG_SPL_NAND_SUPPORT and not documenting that existing CONFIG_SPL_NAND_SIMPLE, so, agreed. And I'll add CONFIG_SPL_NAND_SIMPLE to the README.
participants (5)
-
jonsmirl＠gmail.com -
Scott Wood -
Simon Glass -
Tom Rini -
Wolfgang Denk