[U-Boot] [PATCH v2] mx6: Read silicon revision from register
Instead of hardcoding the mx6 silicon revision, read it from the proper register.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com --- 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; }
On 13.03.2012 15:18, Fabio Estevam wrote:
Instead of hardcoding the mx6 silicon revision, read it from the proper register.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
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;
Can we get a register overlay instead of the 'ANATOP_BASE_ADDR + 0x260'? Like in the rest of the file, e.g.
readl(&fuse->mac_addr_high); writel(0x00000000, &aips1->opacr0);
Best regards
Dirk
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 Estevamfabio.estevam@freescale.com
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().
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?
Please advise,
Eric
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 Estevamfabio.estevam@freescale.com
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 ?
Best regards, Stefano Babic
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 Estevamfabio.estevam@freescale.com
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...
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
On Tue, Mar 13, 2012 at 12:40 PM, Eric Nelson eric.nelson@boundarydevices.com wrote:
Fabio, do you have any guidance about how/whether the system_rev should be updated to include a board revision?
Yes, will point you offline on how this was implemented on the FSL U-boot.
Regards,
Fabio Estevam
participants (5)
-
Dirk Behme -
Eric Nelson -
Fabio Estevam -
Fabio Estevam -
Stefano Babic