[U-Boot] RFC: postload: Loading some U-Boot code later

[Simon Glass]

Hi Wolfgang,

Thanks for the response.

On Thu, Jul 28, 2011 at 7:45 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Simon Glass,
>
> In message <CAPnjgZ0Y7Lnu6KiOsm8Q4qFqNeZh0wg3txFFiTqhzPZUW8Weig at mail.gmail.com> you wrote:
>>
>> I am looking to implement a feature where a cut-down U-Boot is
>> initially loaded, which is enough for a normal boot. But then when an
>> abnormal boot is required (e.g. from a USB stick or network), we can
>> load more code to cope with it.
> ...
>> - has this been done before, or something similar?
>
> This has been done before, since the very earliest versions of U-Boot
> (or PPCboot, as it was called at that times).  The feature is called
> standalone applications.  There are _many_ systems around where you
> can load (and run) manufacturing test code, hardware diagnosis code,
> burn in test stuff, proprietary code to perform top secret actions
> nobody ever may know, etc.

In my case I am just wanting to run U-Boot code. It seems to me that
the standalone code is for being able to jump to a binary which can
still find and call U-Boot functions.

>
>> - any hints, tips, dragon warnings?
>> - does the above approach sound reasonable?
>
> I understand what you want, and why you want it.  But I disagree with
> the suggested implementation.
>
> If you just need a simple environment, you can probably do well with
> the existing standalone approach.

Hmmm so I think I would need to build some of the U-Boot code into a
separate binary.

>
> If you are looking for a more powerful solution, that is more tightly
> integrated with the rest of the U-Boot code (**) then we should make
> the jump and implement loadable modules.  This has been done before,
> too - see Linux for a big example, or barebox for a smaller, more
> U-Boot-like one.

OK I can certainly see how this could work. My idea is more along the
lines that there is a single 'virtual' U-Boot code image, but we just
don't have access to it all at the start. With modules we would
presumably enhance the y/n CONFIG items to support an 'm' option. We
would likely end up with one module per CONFIG item. Then the question
arises as to how to detect when a module is needed and load it. Also
there is the issue of load overhead - since some modules may only be
<1KB each. That suggests the idea of grouping functions into modules,
like a NET module.

It sounds like a lot of work! Is there a general use for it?

>
> (**) The separation and restriction of the standalone code is an
>     intentional one, made not for technical but for political
>     reasons - standalone applications are provided as a means to run
>     closed-source, proprietary code.  This is something that has to
>     hurt a bit.

OK I understand that. Everything we are doing is open source here.

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
> How many QA engineers does it take to screw in a lightbulb? 3:  1  to
> screw it in and 2 to say "I told you so" when it doesn't work.
>