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

[Michael Schwingen]

Am 12/23/2010 12:28 PM, schrieb Albert ARIBAUD:
>> 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?
This is the case on IXP: the boot flash is located at 0x50000000 on the
expansion bus.
At reset, the flash is mirrored to 0x00000000, and the code starts
there. Later, the startup code removes that mirror so that the SDRAM is
at 0x00000000.

Currently, this works because the code copies u-boot from flash to
0x00000000 before disabling the mirror. However, a simple jump to
0x50000000 + offset works just as well (and is easier, because debug
symbols match execution).


>>>> 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.
Fine with me. I don't really see why interrupts should be needed inside
u-boot on IXP425.

cu
Michael