Hi Wolfgang, Thanks for the response.
On Thu, Jul 28, 2011 at 7:45 AM, Wolfgang Denk <w...@denx.de> wrote: > Dear Simon Glass, > > In message > <capnjgz0y7lnu6kiosm8q4qfqnezh0wg3txffitqhzpzuw8w...@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: w...@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. > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
