[U-Boot] [PATCH v2] mx6: Read silicon revision from register

[U-Boot] [PATCH v2] mx6: Read silicon revision from register

[Fabio Estevam]

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;
 }
-- 
1.7.1

[U-Boot] [PATCH v2] mx6: Read silicon revision from register

[Dirk Behme]

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

[U-Boot] [PATCH v2] mx6: Read silicon revision from register

[Eric Nelson]

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<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;
>   }

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

[U-Boot] [PATCH v2] mx6: Read silicon revision from register

[Stefano Babic]

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<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;
>>   }
> 
> 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

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH v2] mx6: Read silicon revision from register

[Fabio Estevam]

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

[U-Boot] [PATCH v2] mx6: Read silicon revision from register

[Eric Nelson]

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<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;
>>>    }
>>
>> 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