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