Hi Bin,
On 3 January 2015 at 20:26, Bin Meng <bmeng...@gmail.com> wrote:
> Hi Simon,
>
> On Fri, Jan 2, 2015 at 6:23 AM, Simon Glass <s...@chromium.org> wrote:
>> Hi Bin,
>>
>> On 30 December 2014 at 22:51, Bin Meng <bmeng...@gmail.com> wrote:
>>>
>>> Hi Simon,
>>>
>>> On Sun, Dec 28, 2014 at 10:20 AM, Simon Glass <s...@chromium.org> wrote:
>>> > For bare platforms we turn off ROM-caching before calling board_init_f_r()
>>> > It is then very slow to copy U-Boot from ROM to RAM. So adjust the order
>>> > so
>>> > that the copying happens before we turn off ROM-caching.
>>> >
>>> > Signed-off-by: Simon Glass <s...@chromium.org>
>>> > ---
>>> >
>>> > common/board_f.c | 8 +++++---
>>> > 1 file changed, 5 insertions(+), 3 deletions(-)
>>> >
>>> > diff --git a/common/board_f.c b/common/board_f.c
>>> > index 98c9c72..1b65575 100644
>>> > --- a/common/board_f.c
>>> > +++ b/common/board_f.c
>>> > @@ -983,6 +983,11 @@ static init_fnc_t init_sequence_f[] = {
>>> > INIT_FUNC_WATCHDOG_RESET
>>> > reloc_fdt,
>>> > setup_reloc,
>>> > +#ifdef CONFIG_X86
>>> > + copy_uboot_to_ram,
>>> > + clear_bss,
>>> > + do_elf_reloc_fixups,
>>> > +#endif
>>> > #if !defined(CONFIG_ARM) && !defined(CONFIG_SANDBOX)
>>> > jump_to_copy,
>>> > #endif
>>> > @@ -1042,9 +1047,6 @@ void board_init_f(ulong boot_flags)
>>> > */
>>> > static init_fnc_t init_sequence_f_r[] = {
>>> > init_cache_f_r,
>>> > - copy_uboot_to_ram,
>>> > - clear_bss,
>>> > - do_elf_reloc_fixups,
>>> >
>>> > NULL,
>>> > };
>>> > --
>>>
>>> I don't understand. Isn't the init_cache_f_r() which turns on the cache?
>>>
>>
>> Yes it turns on the cache, but turns off the ROM cache (they are
>> different things). So this ordering is much faster. I think I might
>> have more tuning to do though.
>>
>
> Got it. Since we moved these 3 routines from init_sequence_f_r[] to
> init_sequence_f[], how about we remove the whole init_sequence_f_r[]
> completely? If not possible, the comment block above
> init_sequence_f_r[] needs to be fixed?
I'll remove the comment.
>
> *
> * 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)
> *
> * NOTE: At present only x86 uses this route, but it is intended that
> * all archs will move to this when generic relocation is implemented.
> */
>
> So looks that we should either drop this _f_r stage, or make other
> arch use this _f_r?
I think we should move to generic relocation, meaning that all archs
do relocation the same way with the same code. Then only arch-specific
stuff is the then ELF fixup function, which adjusts a relocation site,
and the code to actually change the stack pointer.
This board_init_f_r() code is part of one attempt to do this - the
premise was that turning the cache on before relocating U-Boot will
save time. That's true, but it would be even better to turn the cache
on much earlier. With pit (Chromebook 2) we turn on the cache in SPL.
So I think turning it on here is too late if we are trying to save
time. Still it is a good start and if we could make it happen
generally it would be nice.
See here for my original attempt, which was tied up with generic
board. In the end I untied them and we got one but not the other.
http://lists.denx.de/pipermail/u-boot/2012-February/118409.html
Since then Albert has tidied up ARM start.S a lot which makes this much easier.
So that's the background. One of these days I might take another look
at it if it doesn't get someone's attention.
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
