Dear Wolfgang Denk, On Thu, Sep 16, 2010 at 01:06:01PM +0200, Wolfgang Denk wrote: > Dear Wolfgang Wegner, > > In message <20100916101810.gh25...@leila.ping.de> you wrote: [...] > > struggle with debugging tools that are either plain too stupid to > > program some flash devices or are much slower than U-Boot, you > > can simply run a specially built version from RAM and/or provide it > > with an environment in RAM to do all the actual flashing for the board > > production. > > Note the "specially built version". My understanding is that this > "special building" cannot be avoided in general.
I do not know if it can be avoided in general, but if it is architecture- dependent, maybe those architectures supporting such a boot procedure to allow doing this with a single image could be made to support it out-of-the-box. Then the other architectures could still benefit from more awareness of something like "CONFIG_MONITOR_IS_IN_RAM" or "CONFIG_SKIP_LOWLEVEL_INIT". > > For some targets, there may be fragments present in the code > > when searching for CONFIG_MONITOR_IS_IN_RAM, which statically > > disables all the low-level initialization to allow U-Boot being > > loaded from a first-stage loader or debugger. But beware, it is > > not always functional out-of-the-box. > > True. And the image configured that way is not the same binary image > that you normally load into flash. Currently it is not, and I do not know if it is possible at all for every architecture and worth the effort to make a single image for both cases, but as there seem to be already some architectures out there with (maybe somewhat limited) support, it looks like an interesting thought to me. Best regards, Wolfgang _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
