From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nishanth Menon Date: Tue, 5 Feb 2013 09:19:41 -0600 Subject: [U-Boot] [PATCH V2 1/5] ARM: OMAP5: Add silicon id support for ES2.0 revision. In-Reply-To: <5110FBCD.1020703@ti.com> References: <1359988164-24840-1-git-send-email-r.sricharan@ti.com> <1359988164-24840-2-git-send-email-r.sricharan@ti.com> <20130204194114.GA4740@kahuna> <5110FBCD.1020703@ti.com> Message-ID: <20130205151940.GA7517@kahuna> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > >>--- > >> 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