[U-Boot] [PATCH 3/9] arm: Move CP15 init out of cpu_init_crit()

[Simon Glass]

Hi Albert,

On Sat, Nov 5, 2011 at 1:09 AM, Albert ARIBAUD
<albert.u.boot at aribaud.net> wrote:
> Hi Simon et al.,
>
> Thanks to you and others for their patience. Let me summarize the thread:
>
> - ARM7TDMI definitely lacks a cp15, as AN99 explicitely states;
>
> - ARM provides no other, reliable, way to identify an ARM7TDMI reliably;
>
> - Identification through a manufacturer-specific method just defeats the
> goal.
>
> This makes it impossible to support ARM7TDMI (as well as others listed in
> AM99)  with a start.S code that contains cp15 instructions.
>
> OTOH, I've gone through a number of ARM TRMs for cores that have caches/MMU
> and they all state that these are disabled on reset. I will also assume that
> when U-Boot starts indirectly through SPL or any other mechanism, and if
> this mechanism uses caches/MMU, then it will disable them properly before
> passing control to U-Boot, just like U-Boot disables caches etc before
> passing control to e.g. Linux.
>
> I understand that this initialization is done so that the the cache/MMU is
> in a correct state, and this must still be ensured, but I now think that
> ensuring this is the burden of whatever passed control to the start label
> (this includes true resets, branching from SPL or any other IPL, and --ugh--
> branching to start from inside U-Boot).
>
> Based on this, I revise my opinion that the caches and MMU cleaning code in
> start.S should be kept there, and actually I now consider that they should
> be removed entirely.
>
> However, removing cp15 inits would mean a *third* revision of your patchset,
> plus it could cause unexpected issues which I don't want to happen at this
> point of the release cycle.

Yes - I did something similar at v2 where I moved it into a library.
Best left alone for now. I would prefer to continue this discussion if
needed later when we have got this series committed.

>
> Therefore, I'll go back to your patch as posted on oct 13th.
>
> Apologies for the long discussion.
>
> Amicalement,
> --
> Albert.
>

OK, it will at least need a rebase - I will take another look.

Also please note that my series is based on Stephen Warren's MMC
series (1/4 went in via the MMC tree, the other three are ready for
your to pick up) and also Stephen's GPIO patch which is still pending.
Please pick up Stephen's patches first.

Regards,
Simon