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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
