[U-Boot] (imp) uboot image size

[Albert ARIBAUD]

Le 14/07/2010 23:49, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> why not keeping the list on Cc:?

Wrong and unintended action on my part, sorry: I hit the wrong reply 
button (maybe there's a Thunderbird plugin that helps avoiding this?). 
As I don't know if you meant this reply of yours to be made public 
eventually, I'm replying in private. If you want to switch back to the 
list, no problem for me.

> In message<4C3E2808.5040509 at free.fr>  you wrote:
>>
>>> CONFIG_SKIP_LOWLEVEL_INIT is an ARM specific thing, and I am almost
>>> sure that Sagar is on a PowerPC systems.
>>
>> I think we both asked what system Sagar is talking about. But yes, I am
>> talking about ARM here -- the only architecture for which I can claim
>> knowledge of u-boot init sequence if I have any.
>
> I understand this. Sagar probably doesn't.
>
>>> Be careful again. Do you really mean "relocate" here? And
>>> "overloading" a running image is definitely NOT a safe operation.
>>
>> By "relocate" I mean the code that runs after low level init code once
>> RAM is available: if CONFIG_SKIP_RELOCATION is not defined (again, on
>> ARM, at least on arm926ejs) this relocation code moves u-boot from its
>> current location to TEXT_BASE, then jumps to it.
>
> But that is actyally only copying the code, not relocating it. We need
> to be very precise with these terms, as they mean different things.

I understand your point -- indeed, the code was intended to run at 
TEXT_BASE, and the actual relocation is when it is stored in Flash (or 
RAM when TFTP'ed) and starts running there; the code I mentionede which 
is under !CONFIG_SKIP_RELOCATION actually "de-relocates" it back to 
where it should have been.

>> As for "overloading", I should say "overwriting" actually, and it is
>> quite safe -- as safe as booting u-boot at least, as this "overwriting"
>> is the effect of the relocation I just described, which happens at every
>> (ARM) u-boot NOR FLASH startup.
>
> I disagree. You do not "overwrite" any running code.

If you mean "it is forbidden to overwrite any running code", you're 
right; but this never happens in the two scenarios I describe where 
(de)relocation happens: in the NOR Flash boot scenario, there is no code 
running at TEXT_BASE when U-boot gets copied there; in the "TFTP" 
scenario, granted the "chaining" u-boot is running at TEXT_BASE when it 
executes the 'go' to whereever in RAM the "chained" u-boot resides; but 
as soon as this "chained" u-boot starts executing, the "chaining" u-boot 
executes no more and never will again (there is caution of course to be 
taken regarding e.g. instruction cache, but this is taken care of in the 
u-boot startup code).

>> For instance, when I boot my edmini from NOR Flash, its flashed u-boot
>> starts, then relocates itself to TEXT_BASE in RAM and runs from there. I
>
> ...it gets copied to RAM...
>
>> can then do e.g. a tftp of a u-boot (which has low level init disabled
>> but relocation enabled) to some location in RAM other than TEXT_BASE,
>> and 'go' there. The RAM-loaded u-boot will relocate to TEXT_BASE and run
>> there, and will never return (it will destroy the former u-boot's stack
>> and establish its own).
>
> This may, or may not work. In general, it will NOT work unless you
> make sure that your new copy does not assume it is running on a a
> pre-initialized system.

Precisely. That is why I specified that in such a scenario, the 
"chained" u-boot needs to have CONFIG_SKIP_LOWLEVEL_INIT set 
(implicitely assuming that the chaining u-boot should have it unset, but 
that may or may not be necessary--for instance, a Flash-based orion5x 
u-boot should, and a Flash-based kirkwood should not, have 
CONFIG_SKIP_LOWLEVEL_INIT unset).

> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.