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

[Albert ARIBAUD]

Hi Simon,

Le 28/10/2011 00:46, Simon Glass a écrit :
> Hi Albert,

>>>>>> Yes I'm tempted to go with this even if the ARM ARM is silent on the
>>>>>> matter. I will try it out today.
>>>>>
>>>>> Silly me of course it doesn't work - since if the CP15 doesn't have
>>>>> those features then you get undef instruction exception. Please see
>>>>> ^^^ above!
>>>>
>>>> Are you stating a reasoning here or the results of an actual test? What
>>>> causes an undefined instruction exception is the absence of a coprocessor
>>>> to
>>>> handle the instruction, not the presence of a coprocessor which
>>>> incidentally
>>>> cannot perform all of what"s being asked.
>>>
>>> Yes I did test it - it hangs. Would you like me to spend some time to
>>> debug exactly why? I suspect it is an undef instruction, since
>>> executing cache instructions on an ARM7TDMI is dodgy, but I could
>>> check if it would help. But let's assume for now we can't do that!
>>
>> What was the test exactly? Depending on which register of CP15 you try to
>> access, things could be different. Can you test MRC p15,0,<Rt>,c0,c0,0 ?
>> That's the MIDR and it should be always accessible, plus it should have a
>> unique value for each type of core, so it could be used to not write cp15
>> for caches etc from the AVP.
>
> I'm sure that is fine. So do you want me to add a check that the ID
> shows architecture ARMv7, and then skip the cache code if not?
> It should be safe enough since it is a clear signal that something is not
> right. It would also handle the case where an Cortex-A7 (with a cache)
> is attached.

That's the general idea of what I am asking for: test for actual 
conditions when needed rather than assume conditions at build time.

However I don't want to test for ARMv7 architecture, because there is no 
reason for *all* ARMv7 cores to fail handling current cp15 init.

What I want here is to test for NVidia Tegra2 AVP (using the 
Implementer, Variant, Primary part number and possibly even Revision 
fields of MIDR), since you have demonstrated it to not handle the 
current cp15 init.

Plus, run-time testing on MIDR could later on allow us to reduce ARM 
init code path to a single, common start.S for generic/common ARM init 
code, and specific code would be 'switched' into, based on MIDR -- that 
could allow for multiple board support in a single binary.

> Regards,
> Simon

Amicalement,
-- 
Albert.