[U-Boot] Some thoughts on SPL

[jonsmirl at gmail.com]

On Sun, Dec 18, 2011 at 12:55 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi Wolfgang,
>
> On Sat, Dec 17, 2011 at 12:08 PM, Wolfgang Denk <wd at denx.de> wrote:
>> Dear Simon Glass,
>>
>> In message <CAPnjgZ0E4RfzzL2tfff=CN0xQ5OV+v-QTQNy3s3zb6hn7svV2g at mail.gmail.com> you wrote:
>>>
>>> On Fri, Dec 16, 2011 at 9:20 AM, jonsmirl at gmail.com <jonsmirl at 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