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

[Nishanth Menon <nm@ti.com>]

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.
> 
>  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.
-- 
Regards,
Nishanth Menon