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