[U-Boot] board_f for x86

[Alexey Brodkin <Alexey.Brodkin@synopsys.com>]

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