Hi Wolfgang,
Thanks for the response.
On Thu, Jul 28, 2011 at 7:45 AM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message CAPnjgZ0Y7Lnu6KiOsm8Q4qFqNeZh0wg3txFFiTqhzPZUW8Weig@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@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.