On 03/13/2012 08:49 AM, Stefano Babic wrote:
Hi Stefano,
On 13/03/2012 16:40, Eric Nelson wrote:
On 03/13/2012 07:18 AM, Fabio Estevam wrote:
Instead of hardcoding the mx6 silicon revision, read it from the
proper register.
Signed-off-by: Fabio Estevam<[email protected]>
---
Changes since v1:
- Fix typo on Subject
arch/arm/cpu/armv7/mx6/soc.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index 2ac74b5..639bf30 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -32,7 +32,8 @@
u32 get_cpu_rev(void)
{
- int system_rev = 0x61000 | CHIP_REV_1_0;
+ int reg = readl(ANATOP_BASE_ADDR + 0x260)& 0xFF;
+ int system_rev = 0x61000 | 0x10 + reg;
return system_rev;
}
Nice!
MX6Q SABRELITE U-Boot> md 0x20C8260 1
020c8260: 00630000 ..c.
This beats the heck out of my hack:
http://lists.denx.de/pipermail/u-boot/2012-March/120102.html
Now the question is how get_cpu_rev() relates to get_board_rev().
Really they should be unrelated.....I know, we have several cases where
the board revision contains the cpu, but in u-boot they are unrelated.
get_board_rev() should only have the revision of the board, if any.
We had a discussion a while back about reserving some space in OTP
to allow per-board revision information.
Fabio, do you have any guidance about how/whether the system_rev
should be updated to include a board revision?
Do you mean which is the version to be put to make the imxlib happy ?
That's part of the question. imxlib seems to expect bits 12..31 to
contain the CPU:
#define mxc_cpu() (system_rev >> 12)
and bits 0-7 to represent the tapeout of the CPU:
#define mxc_cpu_rev() (system_rev & 0xFF)
That's a lot of bits for each, but tells me where the userspace
wants an **actual** board revision (bits 8-11).
That's confirmed here.
http://opensource.freescale.com/git?p=imx/uboot-imx.git;a=blob;f=include/asm-arm/arch-mx6/mx6.h;h=ae52fa2fed12d468ef4f920afece7478fcb5c479;hb=imx_v2009.08_11.11.01#l617
The other part of the question is where a board revision should be
stored in OTP, and Fabio answered that under separate cover.
The board id and revision should be read from OTP longword #0x26,
bits 8-12, and the mapping won't be 1:1 with system_rev.
I suppose it's time for us to get some more structure in place
for OTP.
Regards,
Eric
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
