Hi Simon,
I'm currently reworking start-up code for ARC with intention to leave as little of assembly code as possible. On that way I decided to use the same approach as x86 does.
In particular I mean:
* Use of sequence "copy_uboot_to_ram", "clear_bss" & "do_elf_reloc_fixups".
* Use of "board_init_f_r_trampoline" for final fix-ups after relocation (basically I do new stack-pointers setup and that's it)
* Use of "board_init_f_r" with "init_sequence_f_r"
I may post patches that implement those changes for ARC if of any interest.
During this development I faced a number of questions I'd like to discuss.
[1] Comment to "init_sequence_f_r" says: --->8--- The '_f_r' sequence must, as a minimum, copy U-Boot to RAM (if supported). It _should_, if possible, copy global data to RAM and initialise the CPU caches (to speed up the relocation process) --->8---
And indeed we have "init_cache_f_r" in that sequence, but what looks strange to me - isn't it too late for caches to be enabled (in terms of relocation speed-up)? Because relocation (both copying and fixups) happens in the end of "init_sequence_f" before jump_to_copy() where for x86 we call board_init_f_r_trampoline() -> board_init_f_r().
So probably we need to move cache_enable() before copy_uboot_to_ram in "init_sequence_f"?
[2] Why "board_init_f_mem" is placed in #else /* CONFIG_X86 */? I would say that this function is orthogonal to a particular architecture.
-Alexey