Hi Simon,

On 06/01/15 04:33, Simon Glass wrote:


Nice to hear from you again!


Thanks - Good to be back in the game

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.

Better would be to have init_cache_f_r after all this I think.

Why so? After copying the U-Boot code from ROM to RAM, we would want RAM based operations to be as fast as possible. By this point, we have passed most of the XIP code, so XIP performance _should_ be a non-issue.

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?)

Yes this can be unified. There is still something in there though for
board_init_f_r(), at least as things are now. It just so happens on
x86 that we are running from ROM and CAR so as I understand it we
sort-of have the cache on before relocation. That doesn't apply for
coreboot though, so there is probably an optimisation to be made
somewhere.

U-Boot runs from RAM right from the start in coreboot correct? In which case, coreboot builds can probably do away with all the relocation code I assume coreboot can relocate U-Boot to any place in memory. Last time I looked, coreboot had some ELF processing code.

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

Yes, it's hard to see, I'm not sure either.

Anyway I'm going to apply this patch while we figure out what further
work can be done.

Sounds good to me.

The pity is that I don't have ANY hardware to test any of this any more, and it looks like any development I do in the foreseeable future will be on ARM. So hacking and testing x86 might be a bit of a problem

Regards,

Graeme
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to