Hi Graeme,
On Wed, Feb 8, 2012 at 7:38 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon,
On Wed, Feb 8, 2012 at 6:12 PM, Simon Glass sjg@chromium.org wrote:
Also make sure that the I-Cache is on as early as possible. Relocation is done with the d-cache off so is slow. Takes about 40ms for me from
Have a close look at the latest x86 patches (not yet pulled into mainline) as an example of how this does not need to be the case. The sequence I now use is:
1) Initialise 'Cache-As-RAM' (CAR) - Cache cannot be used to cache SDRAM, otherwise the Stack and Global Data get trashed 2) Create Stack and Global Data in CAR 3) Initialise SDRAM 4) Create a new stack in SDRAM 5) 'Pivot' U-Boot - Move stack from CAR to SDRAM (U-Boot still running in Flash) 6) Copy Global Data into SDRAM (adjust the global data pointer to point to the in-RAM copy) 7) CAR is no longer used - Enable caching of SDRAM 8) Copy U-Boot to RAM 9) Perform relocation adjustments to in-RAM copy 10) Jump to in-RAM copy 11) Continue initialisation
memory, but we do have things which can speed it up. But d-cache matters more than just about anything.
Yes I went through these carefully at the time - remember the discussion about board_init_f_r()? I hope we can do something similar on generic board, but of course in general there is a trade-off between the time to set up the MMU tables and the time to do the copy.
Now it may be the case (going by Wolfgang's comments) that some amount of high-memory needs to be reserved, and the amount to be reserved is not known until environment has been read. So there may be a need to put the initial in-RAM stack and global data somewhere 'safe' while high- memory space is calculated and U-Boot copied into RAM. Stack and global- data can then be moved again (stack probably doesn't need moving, just re-initialised at a new location) just below U-Boot. This would still be a lot cheaper than copying U-Boot with D-Cache off
Yes. With a chance of 'epsilon' of this patch getting in, I am dropping it. While I agree what you have done is much better than what was there, I have my eyes on the higher goal of unifying the board init code for all archs.
Will revisit when/if generic board goes into mainline. If you have time, please take a look at that series.
Regards, Simon
Regards,
Graeme