[U-Boot] [PATCH 16/22] x86: board_f: Adjust x86 boot order for performance

[Bin Meng]

Hi Simon,

On Mon, Jan 5, 2015 at 9:44 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi Bin,
>
> On 3 January 2015 at 20:26, Bin Meng <bmeng.cn at gmail.com> wrote:
>> Hi Simon,
>>
>> On Fri, Jan 2, 2015 at 6:23 AM, Simon Glass <sjg at chromium.org> wrote:
>>> Hi Bin,
>>>
>>> On 30 December 2014 at 22:51, Bin Meng <bmeng.cn at gmail.com> wrote:
>>>>
>>>> Hi Simon,
>>>>
>>>> On Sun, Dec 28, 2014 at 10:20 AM, Simon Glass <sjg at 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 <sjg at 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

Thanks for the background information. I will take a look. Hope we can
achieve generic board support as soon as we can.

Regards,
Bin