Hi Simon & Bin,
On Tue, Jan 6, 2015 at 12:40 AM, Bin Meng <bmeng...@gmail.com> wrote:
> 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,
> >>>> > };
> >>>> > --
>
Wow, doesn't this bring back some memories. I've had a look over this code
as it is now and it took a while to sink in. Things have moved on in the
past 2 years :)
> >>>>
> >>>> 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.
>
I think init_sequence_f_r can go... but I need to have a better look at the
code
If turning off the ROM cache by init_cache_f_r is the problem, then perhaps
the following order would be better:
copy_uboot_to_ram,
init_cache_f_r,
clear_bss,
do_elf_reloc_fixups,
Without enabling the CPU's cache, clear_bss and do_elf_reloc_fixups will
suffer.
>
> >>
> >> *
> >> * 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 was always my plan - have arch specific do_reloc_fixups and the rest
would be generic
> >
> > 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.
>
And now you have me thinking board_init_f_r is not needed at all...
If we can setup the stack, clear BSS, copy U-Boot to RAM and perform
relocation fixups while running from ROM, what is left for board_init_f_r
to do?
The only thing I can think of is the caveats mentioned in the comment
('static' variables are read-only / Global Data (gd->xxx) is read/write).
But aren't these true when running from ROM?
Looking at non-x86 arches, relocate_code() looks to do what
copy_uboot_to_ram and clear_bss does in x86 land (not sure about
do_elf_reloc_fixups - seems to be arch specific as to whether
relocate_code() does this or it is done later (hence
the CONFIG_NEEDS_MANUAL_RELOC #define?)
>
> > 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
> >
>
Ah, generic relocation... I really wish my life hadn't taken a hard-left
turn when it did. We got so close.
>From where I'm looking (fresh eyes - I might be missing something big) we
should be able to do the ROM->RAM copy, BSS clearing, and relocation fixups
in board_init_f.
When we return from board_init_f it should be a fairly simple matter of:
- Copying the contents of the Global Data structure from CAR to RAM (or
from RAM to RAM if your on a platform which initialises RAM before U-Boot)
- Set the gd pointer (reserved register) to point to the new copy
- Figure out where board_init_r is and jump to it
board_init_r should be able to do any remaining cache tweaks. If cache
tweaks cannot be done while executing from RAM then they need to be done in
board_init_f
I just cannot see the point of board_init_f_r any more
> > 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.
>
Oh dear - it looks like I just put my hand up :)
> >
> > 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
>
>
Regards,
Graeme
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
