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

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

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.

>   - 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.

FYI, the BSS location in FLASH is actually occupied by the relocation 
tables.

DATA (especially const data) are available, though, read-only.

Any RW data that you absolutely need to set before relocation and access 
after it, you need to put in the GD structure.

>   - code in flash sets up RAM, copies + relocates u-boot to RAM, and
> continues there

Correct. Rule of thumb is init_board_f() runs in Flash, and 
init_board_r() runs in RAM.

> 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.

Amicalement,
-- 
Albert.