[U-Boot] uboot to load uboot

[Mike Frysinger]

On Tuesday 29 November 2011 02:00:38 Wolfgang Denk wrote:
> Sridhar Addagada you wrote:
> > Here is a scenario, i have a working version of the u-boot on my
> > board, and am trying my changes.  Am not sure it is going to freeze
> > the board, so would like the present version to load the new version
> > for testing before it can be burned to flash.  Is it possible to do
> > this or is it already done?
> 
> In the strict sense, this usually cannot be done - one of the most
> critical parts (that most oftenly is incorrect and thus bricks your
> system) is the low-level initialization, like initializing the memory
> controller.  And you usually cannot re-do this while already running
> from RAM.
> 
> Note that this is covered in the FAQ:
> http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStarte
> dInRAM

i like this one:
	Answer: Well, yes. Of course this is possible. This is software, so 
*everything* is possible.

not to keep harping, but the Blackfin arch does support this.  and does so 
stable-ly/cleanly imo.  the cpu offers a few advantages though that most cores 
don't (afaik) which makes it possible: dedicated on-chip L1 SRAM that can be 
directly accessed (which is not cache).  and since the majority of the code we 
have to have anyways for normal booting, the additional "i'm being booted from 
external RAM" logic adds like ~6 insns of overhead.  so when we detect we're 
in RAM, we copy the initcode to on-chip memory, put external memory into self 
refresh, reprogram everything, take external memory out of self refresh, and 
then resume execution from RAM.

only caveat i know of is that you can't change some addressing modes (like # 
of cols used to program the SDRAM chips).  otherwise, this changes how bytes 
are laid out in RAM, so you end up having stride-ed data.  what was:
	0xab 0xcd 0xef 0x00 ...
is now something like:
	0xab <garbage> 0xcd <garbage> 0xef <garbage> 0x00 <garbage>
(the specifics here are probably wrong, but you get the general idea)

in this case, we aren't about to kick off a DMA to re-pack the data, so that is 
unsupported.  but we find that's significantly less of an issue compared to what 
people actual want: to play with memory/clock timings.

</braindump>
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111129/86071a18/attachment.pgp>