[U-Boot] Fixing IXP42x boards - some general questions

[Albert ARIBAUD <albert.aribaud@free.fr>]

Le 23/12/2010 11:39, Michael Schwingen a ?crit :
> Am 12/23/2010 11:20 AM, schrieb Albert ARIBAUD:
>> Hi Michael,
>>
>> Answering as the brand new ARM custodian :) :
>>
>> Le 23/12/2010 10:33, Michael Schwingen a ?crit :
>>
>>> Startup code. Is the following correct?
>>>    - code starts from flash, with TEXT_BASE = start of flash, ie. the code
>>> is linked to flash addresses.
>> Correct.  The goal of ELF relocation is to allow moving the code from
>> FLASH to any place in RAM (actually the highest possible location) by
>> correctly relocating it without developers having to fix or code
>> anything manually.
> Thanks. That means the code in the IXP startup code that copies flash to
> RAM (before calling board_init_f, and long before relocation code does a
> second copy) is really not needed, and can be removed if the branch to
> the reset code is replaced by an absolute jump to the real
> (not-aliased-to zero) flash location.

As for the additional copy, yes, it is uneeded -- look at some 
ARM-based archs or boards which support ELF relocation (such as arm926ejs).

As for the jump, 'b' instruction is relative, and there is no need to 
make an absolute jump -- unless you boot in a weird mode where FLASH 
mirrors all over the memory space (and over RAM) and you need to jump to 
the 'real', not 'mirrored', FLASH?

>>> What about interrupts? Use them or avoid them?
>> I say in any case don't use them before running from RAM; and if you can
>> avoid them in u-boot without incurring a huge performance penalty, I
>> would suggest avoiding them altogether.

> Fine with me. I got the non-interrupt code running, and will simply
> leave the (broken) interrupt code as is if that is OK.

Maybe it would be better to remove it. If someone really feels the need 
to revive it, they can copy back it from a previous commit where it 
still exists.

> cu
> Michael

Amicalement,
-- 
Albert.