On Nov 13, 2010, at 12:22 PM, Wolfgang Denk wrote:
> Dear Kumar Gala,
>
> In message <e20f32a5-0ef5-4cc3-ab70-0c1e2330e...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
