Hi Simon, On Mon, Jan 5, 2015 at 9:44 AM, Simon Glass <s...@chromium.org> wrote: > 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
Thanks for the background information. I will take a look. Hope we can achieve generic board support as soon as we can. Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot