On Nov 13, 2010, at 12:22 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message E20F32A5-0EF5-4CC3-AB70-0C1E2330EF27@kernel.crashing.org you wrote:
I'd like to move cpu_init_r to after env_relocate(). This is desirable on 85xx based systems to deal with an issue when we boot from NAND (and probably SPI or SDHC/MMC) in which we use the L2 cache in SRAM mode to load the u-boot image from the storage device (NAND, SPI, SDHC/MMC, etc.). In these cases we have an ordering issue between freeing up the L2 cache and when the environment is relocated.
I don't think that's a good idea. cpu_init_r() starts a number of pretty basic servies and must run as early as possible after relocation. For example, it may initialize caches, load microcode needed for some drivers soon, initialize interrupts and timers and such...
Moving these things around requires extreme care and really intensive testing on a lots of boards.
If we move cpu_init_r() after env_relocate() that addresses the issue. I did an audit of all the other PPC chips and I dont believe it impacts any of them if we move cpu_init_r after spi_init_{f,r}, nand_init, mmc_initialize, & env_relocate.
Um.. I doubt that. My fingers still carry the fire scars from my last attempt to do something like that.
Please let me know if this is acceptable solution to my problem. I've provided both the 'audit' details and example diff.
Thanks for that. It only shows that there is alot of pretty basic stuff done, which might be needed. You will need to retest a ton of boards.
Well I'm still stuck for a solution to my problem :)
So is a post_env_relocate_cleanup() the way to go? I can than differ L2 init to that point in the case we use the L2 SRAM for boot memory?
- k