* [U-Boot] Some thoughts on SPL
@ 2011-12-16 17:20 jonsmirl at gmail.com
2011-12-16 21:49 ` Scott Wood
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: jonsmirl at gmail.com @ 2011-12-16 17:20 UTC (permalink / raw)
To: u-boot
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?
--
Jon Smirl
jonsmirl at gmail.com
^ permalink raw reply [flat|nested] 10+ messages in thread* [U-Boot] Some thoughts on SPL 2011-12-16 17:20 [U-Boot] Some thoughts on SPL jonsmirl at gmail.com @ 2011-12-16 21:49 ` Scott Wood 2011-12-17 5:38 ` Simon Glass 2011-12-20 15:38 ` Tom Rini 2 siblings, 0 replies; 10+ messages in thread From: Scott Wood @ 2011-12-16 21:49 UTC (permalink / raw) To: u-boot On 12/16/2011 11:20 AM, jonsmirl at 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] Some thoughts on SPL 2011-12-16 17:20 [U-Boot] Some thoughts on SPL jonsmirl at gmail.com 2011-12-16 21:49 ` Scott Wood @ 2011-12-17 5:38 ` Simon Glass 2011-12-17 5:56 ` jonsmirl at gmail.com 2011-12-17 20:08 ` Wolfgang Denk 2011-12-20 15:38 ` Tom Rini 2 siblings, 2 replies; 10+ messages in thread From: Simon Glass @ 2011-12-17 5:38 UTC (permalink / raw) To: u-boot Hi, On Fri, Dec 16, 2011 at 9:20 AM, jonsmirl at 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 at gmail.com > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] Some thoughts on SPL 2011-12-17 5:38 ` Simon Glass @ 2011-12-17 5:56 ` jonsmirl at gmail.com 2011-12-17 20:08 ` Wolfgang Denk 1 sibling, 0 replies; 10+ messages in thread From: jonsmirl at gmail.com @ 2011-12-17 5:56 UTC (permalink / raw) To: 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 at 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 at gmail.com >> _______________________________________________ >> U-Boot mailing list >> U-Boot at lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot -- Jon Smirl jonsmirl at gmail.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] Some thoughts on SPL 2011-12-17 5:38 ` Simon Glass 2011-12-17 5:56 ` jonsmirl at gmail.com @ 2011-12-17 20:08 ` Wolfgang Denk 2011-12-18 5:55 ` Simon Glass 1 sibling, 1 reply; 10+ messages in thread From: Wolfgang Denk @ 2011-12-17 20:08 UTC (permalink / raw) To: 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 at 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 -- 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_ ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] Some thoughts on SPL 2011-12-17 20:08 ` Wolfgang Denk @ 2011-12-18 5:55 ` Simon Glass 2011-12-18 15:38 ` jonsmirl at gmail.com 0 siblings, 1 reply; 10+ messages in thread From: Simon Glass @ 2011-12-18 5:55 UTC (permalink / raw) To: u-boot 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 at 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 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_ ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] Some thoughts on SPL 2011-12-18 5:55 ` Simon Glass @ 2011-12-18 15:38 ` jonsmirl at gmail.com 0 siblings, 0 replies; 10+ messages in thread From: jonsmirl at gmail.com @ 2011-12-18 15:38 UTC (permalink / raw) To: u-boot 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 at 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 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_ -- Jon Smirl jonsmirl at gmail.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] Some thoughts on SPL 2011-12-16 17:20 [U-Boot] Some thoughts on SPL jonsmirl at gmail.com 2011-12-16 21:49 ` Scott Wood 2011-12-17 5:38 ` Simon Glass @ 2011-12-20 15:38 ` Tom Rini 2011-12-20 20:48 ` Scott Wood 2 siblings, 1 reply; 10+ messages in thread From: Tom Rini @ 2011-12-20 15:38 UTC (permalink / raw) To: u-boot On Fri, Dec 16, 2011 at 10:20 AM, jonsmirl at 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. -- Tom ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] Some thoughts on SPL 2011-12-20 15:38 ` Tom Rini @ 2011-12-20 20:48 ` Scott Wood 2011-12-20 20:56 ` Tom Rini 0 siblings, 1 reply; 10+ messages in thread From: Scott Wood @ 2011-12-20 20:48 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] Some thoughts on SPL 2011-12-20 20:48 ` Scott Wood @ 2011-12-20 20:56 ` Tom Rini 0 siblings, 0 replies; 10+ messages in thread From: Tom Rini @ 2011-12-20 20:56 UTC (permalink / raw) To: u-boot 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. -- Tom ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-12-20 20:56 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-12-16 17:20 [U-Boot] Some thoughts on SPL jonsmirl at gmail.com 2011-12-16 21:49 ` Scott Wood 2011-12-17 5:38 ` Simon Glass 2011-12-17 5:56 ` jonsmirl at gmail.com 2011-12-17 20:08 ` Wolfgang Denk 2011-12-18 5:55 ` Simon Glass 2011-12-18 15:38 ` jonsmirl at gmail.com 2011-12-20 15:38 ` Tom Rini 2011-12-20 20:48 ` Scott Wood 2011-12-20 20:56 ` Tom Rini
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox