[U-Boot] board_f for x86

[U-Boot] board_f for x86

[Alexey Brodkin]

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] board_f for x86

[Simon Glass]

Hi Alexey,

On 25 February 2015 at 04:06, Alexey Brodkin
<Alexey.Brodkin@synopsys.com> wrote:
> 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.

Sounds good. I think ARM could move the same way.

>
> 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().

Yes that's right. This change was made quite recently, because on x86
we run from 'cache-as-ram' which means that when we switch over the
cache to be a normal cache, we lose our old RAM.

In jump_to_copy() on x86, the call to board_init_f_r_trampoline()
changes things over. The old temporary RAM (including global_data goes
away). The new stack and global data is in SDRAM. Then it calls
board_init_f_r().

The change to the code happened during the bare x86 support. It does
need another look as it is not optimal, although the cache is
generally on at least in bare mode.

>
> So probably we need to move cache_enable() before copy_uboot_to_ram in
> "init_sequence_f"?

Yes, but copy_uboot_to_ram() uses global_data so we can't do that on
x86. I think we should do something like change to the new SRAM-based
global_data earlier to avoid this problem.

>
>  [2] Why "board_init_f_mem" is placed in #else /* CONFIG_X86 */? I would
> say that this function is orthogonal to a particular architecture.

Yes I'd like this function to be generic, called from all archs.

Regards,
Simon