[U-Boot] RFC: Move when we call cpu_init_r on PPC

Wolfgang Denk wd at denx.de
Sat Nov 13 19:22:37 CET 2010


Dear Kumar Gala,

In message <E20F32A5-0EF5-4CC3-AB70-0C1E2330EF27 at 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.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Imagination is more important than knowledge.      -- Albert Einstein


More information about the U-Boot mailing list