On Sun, Dec 18, 2011 at 12:55 AM, Simon Glass <s...@chromium.org> wrote: > Hi Wolfgang, > > On Sat, Dec 17, 2011 at 12:08 PM, Wolfgang Denk <w...@denx.de> wrote: >> Dear Simon Glass, >> >> In message >> <CAPnjgZ0E4RfzzL2tfff=cn0xq5ov+v-qtqny3s3zb6hn7sv...@mail.gmail.com> you >> wrote: >>> >>> On Fri, Dec 16, 2011 at 9:20 AM, jonsm...@gmail.com <jonsm...@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: w...@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 jonsm...@gmail.com _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
