[U-Boot] board_f for x86
Alexey Brodkin
Alexey.Brodkin at synopsys.com
Wed Feb 25 12:06:56 CET 2015
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
More information about the U-Boot
mailing list