[U-Boot] [PATCH V2 1/5] ARM: OMAP5: Add silicon id support for ES2.0 revision.
Nishanth Menon
nm at ti.com
Tue Feb 5 16:19:41 CET 2013
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 at 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
More information about the U-Boot
mailing list