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

[Michael Schwingen]

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.


>>   - DATA/BSS are behind the text segment in flash, so the code may not
>> write RAM variables until relocation
> Actually in FLASH there is no BSS at all -- you cannot use BSS until 
> after relocation (this was already a constraint in u-boot, even though 
> before ELF relocation ARM architecture did not make it impossible.
I am asking because there *was* code in print_cpuinfo which writes
global variables, and which is called before relocation.
So that is definitely broken (and easy to fix).


> Correct. Rule of thumb is init_board_f() runs in Flash, and
> init_board_r() runs in RAM.
Fine. It seems some initialization order was changed - I had to
introduce a board_init_early_f function and move the localbus chip
select set-up there.

>> Timer system.
>>   - For IXP, there are two variants of the timer system - one using
>> interrupts, and one without interrupts. Both do not work currently.
>> I have patches that fix the non-interrupt version, changing
>> CONFIG_SYS_HZ from 66666666 to 1000, bringing it in line with what most
>> other ARM platforms do.
>> What is the preferred way of handling timers? Should CONFIG_SYS_HZ be
>> 1000 or rather the timer clock?
>> 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.

cu
Michael