[U-Boot] [PATCH V2 1/5] ARM: OMAP5: Add silicon id support for ES2.0 revision.

[R Sricharan <r.sricharan@ti.com>]

Hi,
On Tuesday 05 February 2013 08:49 PM, Nishanth Menon wrote:
> On 18:02-20130205, R Sricharan wrote:
>> On Tuesday 05 February 2013 01:11 AM, Nishanth Menon wrote:
>>> On 19:59-20130204, R Sricharan wrote:
>>>> Adding the CPU detection suport for OMAP5430 and
>>>> OMAP5432 ES2.0 SOCs.
>>>>
>>>> Signed-off-by: R Sricharan <r.sricharan@ti.com>
>>>> ---
>>>>   arch/arm/cpu/armv7/omap5/hwinit.c      |   13 +++++++++++--
>>>>   arch/arm/include/asm/arch-omap5/omap.h |    2 ++
>>>>   arch/arm/include/asm/armv7.h           |    1 +
>>>>   arch/arm/include/asm/omap_common.h     |    2 ++
>>>>   4 files changed, 16 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c b/arch/arm/cpu/armv7/omap5/hwinit.c
>>>> index dfc0e44..0d8c95d 100644
>>>> --- a/arch/arm/cpu/armv7/omap5/hwinit.c
>>>> +++ b/arch/arm/cpu/armv7/omap5/hwinit.c
>>>> @@ -216,8 +216,17 @@ void init_omap_revision(void)
>>>>   			break;
>>>>   		}
>>>>   		break;
>>>> -	default:
>>>> -		*omap_si_rev = OMAP5430_SILICON_ID_INVALID;
>>>> +	case MIDR_CORTEX_A15_R2P2:
>>>> +		switch (readl(CONTROL_ID_CODE)) {
>>>> +		case OMAP5430_CONTROL_ID_CODE_ES2_0:
>>>> +			*omap_si_rev = OMAP5430_ES2_0;
>>>> +			break;
>>>> +		case OMAP5432_CONTROL_ID_CODE_ES2_0:
>>>> +			*omap_si_rev = OMAP5432_ES2_0;
>>>> +			break;
>>>> +		default:
>>>> +			*omap_si_rev = OMAP5430_SILICON_ID_INVALID;
>>>> +		}
>>>
>>> A first few samples of both ES1.0 and ES2.0 (in the few 10s of samples) came with wrong efuse
>>> ID fused in, why would we want to make it a standard to check ARMsilicon
>>> revision *and then* cross verify against control fuse verification, *and
>>> then* give up saying we dont support it?
>>>
>>> Looks like an over check for me -> IMHO, we should drop the MIDR checks
>>> entirely.
>>   In the same context, for some boards in past even in the actual samples
>>   the CONTROL ID code was reading the older revision. So in those
>>   cases ARM revision will help to differentiate them.
> which boards? Almost as a rule the first few samples on almost all
> revisions on production floor had messed up control ID, however, beyond
> that, all runs are properly updated.
>>
  I have seen this issue on some OMAP4 revisions as well. It was only 
after that we introduced this logic of double checking using ARM 
revision ID.
>>   But then it should have been in the opposite way, like reading the
>> CONTROL_CODE first and then reading the ARM revision if required in
>> those cases where is it broken. I will change this logic here.
> Having cortex check is just redundant - IMHO, switching it over might be
> better, but dropping it is more inline with expectation of the silicon
> spec.
>
  According to me the best way to do it is, use CONTROL_ID first and
  then use ARM revision for those which has wrong IDs. This will always
  be a fool proof even for those non-working boards.

Regards,
  Sricharan