Patchwork [U-Boot,1/2] nitrogen6x: Pass the correct CPU revision to the kernel

login
register
mail settings
Submitter Fabio Estevam
Date March 15, 2013, 9:06 p.m.
Message ID <1363381594-17077-1-git-send-email-festevam@gmail.com>
Download mbox | patch
Permalink /patch/228184/
State Changes Requested
Delegated to: Stefano Babic
Headers show

Comments

Fabio Estevam - March 15, 2013, 9:06 p.m.
From: Fabio Estevam <fabio.estevam@freescale.com>

As nitrogen6x boards support different i.MX6 flavors (quad, dual-lite and solo)
the correct CPU revision needs to passed to the kernel, so call get_cpu_rev()
instead of hardcoding it.

Freescale 3.0.35 kernel assumes that the CPU revision is passed passed from the 
bootloader.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
 board/boundary/nitrogen6x/nitrogen6x.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Eric Nelson - March 16, 2013, 12:20 a.m.
On 03/15/2013 02:06 PM, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> As nitrogen6x boards support different i.MX6 flavors (quad, dual-lite and solo)
> the correct CPU revision needs to passed to the kernel, so call get_cpu_rev()
> instead of hardcoding it.
>
> Freescale 3.0.35 kernel assumes that the CPU revision is passed passed from the
> bootloader.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
>   board/boundary/nitrogen6x/nitrogen6x.c |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/boundary/nitrogen6x/nitrogen6x.c b/board/boundary/nitrogen6x/nitrogen6x.c
> index 229c237..fec0e3a 100644
> --- a/board/boundary/nitrogen6x/nitrogen6x.c
> +++ b/board/boundary/nitrogen6x/nitrogen6x.c
> @@ -330,7 +330,7 @@ int board_mmc_init(bd_t *bis)
>
>   u32 get_board_rev(void)
>   {
> -	return 0x63000;
> +	return get_cpu_rev();
>   }
>
>   #ifdef CONFIG_MXC_SPI
>

This is the **board** revision, right?

At first glance, the kernel seems to be getting the silicon revision
from the same place as get_cpu_rev():
	https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_3.0.35_1.1.1/arch/arm/mach-mx6/cpu.c#L51
	http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/mx6/soc.c;h=a8aad5dd0a6c8548277021ebe8f6e159dbf31b9b;hb=HEAD#l42

Is there a reference to the ATAG that I'm not seeing somewhere?

Please advise,


Eric
Fabio Estevam - March 16, 2013, 2:58 p.m.
Hi Eric,

On Fri, Mar 15, 2013 at 9:20 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:

> This is the **board** revision, right?
>
> At first glance, the kernel seems to be getting the silicon revision
> from the same place as get_cpu_rev():
>
> https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_3.0.35_1.1.1/arch/arm/mach-mx6/cpu.c#L51
>
> http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/mx6/soc.c;h=a8aad5dd0a6c8548277021ebe8f6e159dbf31b9b;hb=HEAD#l42
>
> Is there a reference to the ATAG that I'm not seeing somewhere?

Ok, so 3.0.35 treats cpu_rev correctly and do not assume this info to
be passed from the bootloader. I was confused with 2.6.35, where I had
issues with this on mx53.

So, it seems that nitrogen does not need to pass get_board_rev() at all then?

Regards,

Fabio Estevam
Eric Nelson - March 16, 2013, 4:13 p.m.
On 03/16/2013 07:58 AM, Fabio Estevam wrote:
> Hi Eric,
>
> On Fri, Mar 15, 2013 at 9:20 PM, Eric Nelson
> <eric.nelson@boundarydevices.com> wrote:
>
>> This is the **board** revision, right?
>>
>> At first glance, the kernel seems to be getting the silicon revision
>> from the same place as get_cpu_rev():
>>
>> https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_3.0.35_1.1.1/arch/arm/mach-mx6/cpu.c#L51
>>
>> http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/mx6/soc.c;h=a8aad5dd0a6c8548277021ebe8f6e159dbf31b9b;hb=HEAD#l42
>>
>> Is there a reference to the ATAG that I'm not seeing somewhere?
>
> Ok, so 3.0.35 treats cpu_rev correctly and do not assume this info to
> be passed from the bootloader. I was confused with 2.6.35, where I had
> issues with this on mx53.
>
> So, it seems that nitrogen does not need to pass get_board_rev() at all then?
>
At the moment, it doesn't.

I would really like to see us (the i.MX6 community) standardize
the use of some fuses to specifically mean board revision.

We're contemplating some board changes such as switching the
ethernet PHY and having a convention for the use of a few
bits in OTP would allow us to implement get_board_rev() once in
a common place.

Over the lifetime of most boards, it's likely that at least
one board revision will have software implications and having
a common way to express/detect this could prevent some churn
in board-specific files.

Such a convention would need to have broad sign off though.

Let me know your thoughts on the subject.

Regards,


Eric
Dirk Behme - March 16, 2013, 4:55 p.m.
Am 16.03.2013 17:13, schrieb Eric Nelson:
> On 03/16/2013 07:58 AM, Fabio Estevam wrote:
>> Hi Eric,
>>
>> On Fri, Mar 15, 2013 at 9:20 PM, Eric Nelson
>> <eric.nelson@boundarydevices.com> wrote:
>>
>>> This is the **board** revision, right?
>>>
>>> At first glance, the kernel seems to be getting the silicon revision
>>> from the same place as get_cpu_rev():
>>>
>>> https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_3.0.35_1.1.1/arch/arm/mach-mx6/cpu.c#L51
>>>
>>>
>>> http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/mx6/soc.c;h=a8aad5dd0a6c8548277021ebe8f6e159dbf31b9b;hb=HEAD#l42
>>>
>>>
>>> Is there a reference to the ATAG that I'm not seeing somewhere?
>>
>> Ok, so 3.0.35 treats cpu_rev correctly and do not assume this info to
>> be passed from the bootloader. I was confused with 2.6.35, where I had
>> issues with this on mx53.
>>
>> So, it seems that nitrogen does not need to pass get_board_rev() at
>> all then?
>>
> At the moment, it doesn't.
>
> I would really like to see us (the i.MX6 community) standardize
> the use of some fuses to specifically mean board revision.
>
> We're contemplating some board changes such as switching the
> ethernet PHY and having a convention for the use of a few
> bits in OTP would allow us to implement get_board_rev() once in
> a common place.
>
> Over the lifetime of most boards, it's likely that at least
> one board revision will have software implications and having
> a common way to express/detect this could prevent some churn
> in board-specific files.
>
> Such a convention would need to have broad sign off though.
>
> Let me know your thoughts on the subject.

I think the OMAP/Beagle community introduced serial EEPROMs to 
identify their (add on) boards.

Best regards

Dirk
Fabio Estevam - March 16, 2013, 7:48 p.m.
Hi Eric,

On Sat, Mar 16, 2013 at 1:13 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:

> At the moment, it doesn't.
>
> I would really like to see us (the i.MX6 community) standardize
> the use of some fuses to specifically mean board revision.
>
> We're contemplating some board changes such as switching the
> ethernet PHY and having a convention for the use of a few
> bits in OTP would allow us to implement get_board_rev() once in
> a common place.
>
> Over the lifetime of most boards, it's likely that at least
> one board revision will have software implications and having
> a common way to express/detect this could prevent some churn
> in board-specific files.
>
> Such a convention would need to have broad sign off though.
>
> Let me know your thoughts on the subject.

Would this approach work?

http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/board/freescale/common/fsl_sys_rev.c?h=imx_v2009.08_3.0.0

Regards,

Fabio Estevam
Wolfgang Denk - March 16, 2013, 8:14 p.m.
Dear Eric Nelson,

In message <51449A34.7080902@boundarydevices.com> you wrote:
>
> At the moment, it doesn't.
> 
> I would really like to see us (the i.MX6 community) standardize
> the use of some fuses to specifically mean board revision.

No.  This is a very bad idea.  We've been working long enough with a
number of board manufacturers; many of these provides SOMs (Systems on
Module) that get then used by many different customers for many
different purposes - and the use of things like fuse settings should
be left to these end users.

> We're contemplating some board changes such as switching the
> ethernet PHY and having a convention for the use of a few
> bits in OTP would allow us to implement get_board_rev() once in
> a common place.
> 
> Over the lifetime of most boards, it's likely that at least
> one board revision will have software implications and having
> a common way to express/detect this could prevent some churn
> in board-specific files.
> 
> Such a convention would need to have broad sign off though.

You seem to forget that there is a standardized, well documented way
to pass all kind of hardware related information to the Linux kernel.
If you need any such information, add it to the device tree.

Best regards,

Wolfgang Denk
Wolfgang Denk - March 16, 2013, 8:17 p.m.
Dear Dirk Behme,

In message <5144A401.9020209@gmail.com> you wrote:
>
> I think the OMAP/Beagle community introduced serial EEPROMs to 
> identify their (add on) boards.

There are many such ad-hoc approaches, and most of them are just a
PITA.  If you are trying to optimize boot times, it is really a pain
if you have to wait for inherently slow devives like EEPROMs on a I2C
bus etc.

Also, this addresses only the first half of the problem - the source
of the information. The other half is how to pass the information to
the kernel (-> DT).

Best regards,

Wolfgang Denk
Eric Nelson - March 16, 2013, 8:27 p.m.
Hi Fabio,

On 03/16/2013 12:48 PM, Fabio Estevam wrote:
> Hi Eric,
>
> On Sat, Mar 16, 2013 at 1:13 PM, Eric Nelson
> <eric.nelson@boundarydevices.com> wrote:
>
>> At the moment, it doesn't.
>>
>> I would really like to see us (the i.MX6 community) standardize
>> the use of some fuses to specifically mean board revision.
>>
>> We're contemplating some board changes such as switching the
>> ethernet PHY and having a convention for the use of a few
>> bits in OTP would allow us to implement get_board_rev() once in
>> a common place.
>>
>> Over the lifetime of most boards, it's likely that at least
>> one board revision will have software implications and having
>> a common way to express/detect this could prevent some churn
>> in board-specific files.
>>
>> Such a convention would need to have broad sign off though.
>>
>> Let me know your thoughts on the subject.
>
> Would this approach work?
>
> http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/board/freescale/common/fsl_sys_rev.c?h=imx_v2009.08_3.0.0
>

I think this mixes apples and oranges a bit.

	/* Get Board ID information from OCOTP_GP1[15:8]
	 * bit 12-15: Board type
	 * 0x0 : Unknown
	 * 0x1 : Sabre-AI (ARD)
	 * 0x2 : Smart Device (SD)
	 * 0x3 : Quick-Start Board (QSB)
	 * 0x4 : SoloLite EVK (SL-EVK)
	 *
	 * bit 8-11: Board Revision ID
	 * 0x0 : Unknown or latest revision
	 * 0x1 : RevA board
	 * 0x2 : RevB
	 * 0x3 : RevC
	 *
	 * exp:
	 * i.MX6Q ARD RevA:     0x11
	 * i.MX6Q ARD RevB:     0x12
	 * i.MX6Solo ARD RevA:  0x11
	 * i.MX6Solo ARD RevB:  0x12
	 */

Bits 8-11 seem reasonable, though the comment for zero
is probably bad. It seems that as soon as a board needs
to make a decision based on board revision, it will add
a requirement for a non-zero (programmed) fuse, so the
"latest" will be non-zero by definition.

Four bits also seems like plenty for a revision of a
given board type.

The board type bits above are a bit parochial. You may be able
to list Freescale boards with only four bits, but I would expect the
number of down-stream board types to be in the hundreds, so
it seems this is better left in CONFIG_MACH_TYPE.

The CPU and silicon revision is already available in other
ways and programmed at the Freescale factory.

So for the purposes of get_board_rev(), I think we just
need to identify some bits in an OTP register, define them
as the standard and have get_board_rev() return their value.

That said, I don't think any of this can or should be done
without identifying the down-stream code that might break.

I've seen code that scrapes /proc/cpuinfo for the "Revision:"
line and uses that.

My memory is hazy, but I think it was in either or both the
gstreamer plugins or an "FSL Power Monitor" applet in Android.

I don't recall seeing it in any VPU-related code. Dirk, do you
have a reference there?

I'll try to do some tests of different userspaces with
get_board_rev() returning zero and see what breaks.

Regards,


Eric
Wolfgang Denk - March 16, 2013, 8:29 p.m.
Dear Fabio Estevam,

In message <CAOMZO5C0Wi8qf82KDspM0=ZyMn8DBh3b215e-PmWJjDu7=sMUQ@mail.gmail.com> you wrote:
> 
> Would this approach work?
> 
> http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/board/freescale/common/fsl_sys_rev.c?h=imx_v2009.08_3.0.0

I bet there is a to of existing ways to encode and pass such
information - in NOR flash, EEPROM, encoded in the serial number
and/or MAC addresses, whatever.  I would expect that each major board
vendor has his preferred style, and I don't see how this could be
changed.

Also, pleas ekeep inmind that there are two sides of the issue:

- storage device and format for the related information

- method and for mat of passing this on to the kernel

The Subject: addresses only the second part of this.  And as mentioned
before, there is a standardized method of passing such infoirmation to
the kernel - through the device tree.

Best regards,

Wolfgang Denk
Eric Nelson - March 25, 2013, 7:14 p.m.
Hi Fabio,

On 03/16/2013 01:27 PM, Eric Nelson wrote:
> Hi Fabio,
>
> <snip>
 >
> That said, I don't think any of this can or should be done
> without identifying the down-stream code that might break.
>
> I've seen code that scrapes /proc/cpuinfo for the "Revision:"
> line and uses that.
>
> My memory is hazy, but I think it was in either or both the
> gstreamer plugins or an "FSL Power Monitor" applet in Android.
>
> I don't recall seeing it in any VPU-related code. Dirk, do you
> have a reference there?
>
> I'll try to do some tests of different userspaces with
> get_board_rev() returning zero and see what breaks.
>

The Gstreamer VPU plugin breaks on Solo and Quad if get_board_rev()
doesn't return 0x61xxx or 0x63xxx. Oddly, the code in vpu_lib.c
loads firmware based on the 61 or 63 reference and yet still
nominally works on a Solo with a hard-coded value of 0x63000.

The VPU seems fine. It runs Vivante demos on Solo and Quad
with a board rev of zero.

Regards,


Eric
Fabio Estevam - March 26, 2013, 2:25 a.m.
Hi Eric,

On Mon, Mar 25, 2013 at 4:14 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:

> The Gstreamer VPU plugin breaks on Solo and Quad if get_board_rev()
> doesn't return 0x61xxx or 0x63xxx. Oddly, the code in vpu_lib.c
> loads firmware based on the 61 or 63 reference and yet still
> nominally works on a Solo with a hard-coded value of 0x63000.

Thanks for testing, I will fix get_cpu_rev() tomorrow.

Regards,

Fabio Estevam
Fabio Estevam - March 26, 2013, 3:27 a.m.
On Mon, Mar 25, 2013 at 11:25 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Eric,
>
> On Mon, Mar 25, 2013 at 4:14 PM, Eric Nelson
> <eric.nelson@boundarydevices.com> wrote:
>
>> The Gstreamer VPU plugin breaks on Solo and Quad if get_board_rev()
>> doesn't return 0x61xxx or 0x63xxx. Oddly, the code in vpu_lib.c
>> loads firmware based on the 61 or 63 reference and yet still
>> nominally works on a Solo with a hard-coded value of 0x63000.
>
> Thanks for testing, I will fix get_cpu_rev() tomorrow.

Eric, please try the attached patch if you have a chance.

I don't have my mx6dl or solo to test it, but the attached patch plus
the original one of this thread should make things work.

Thanks,

Fabio Estevam
Eric Nelson - March 26, 2013, 3:24 p.m.
Hi Fabio,

On 03/15/2013 02:06 PM, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> As nitrogen6x boards support different i.MX6 flavors (quad, dual-lite and solo)
> the correct CPU revision needs to passed to the kernel, so call get_cpu_rev()
> instead of hardcoding it.
>
> Freescale 3.0.35 kernel assumes that the CPU revision is passed passed from the
> bootloader.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
>   board/boundary/nitrogen6x/nitrogen6x.c |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/boundary/nitrogen6x/nitrogen6x.c b/board/boundary/nitrogen6x/nitrogen6x.c
> index 229c237..fec0e3a 100644
> --- a/board/boundary/nitrogen6x/nitrogen6x.c
> +++ b/board/boundary/nitrogen6x/nitrogen6x.c
> @@ -330,7 +330,7 @@ int board_mmc_init(bd_t *bis)
>
>   u32 get_board_rev(void)
>   {
> -	return 0x63000;
> +	return get_cpu_rev();
>   }
>
>   #ifdef CONFIG_MXC_SPI
>

Since this convention is shared among at least SABRE Lite, SABRE SD,
Nitrogen6x and Wandboard, wouldn't a weak function in imx-common/cpu.c
be a better choice?

+#ifdef CONFIG_REVISION_TAG
+u32 __weak get_board_rev(void)
+{
+       return get_cpu_rev();
+}
+#endif

Then boards could override things, but will do the reasonable thing
without the extra code.
Eric Nelson - March 26, 2013, 3:26 p.m.
On 03/26/2013 08:24 AM, Eric Nelson wrote:
> Hi Fabio,
>
 > <snip>
 >
>> --- a/board/boundary/nitrogen6x/nitrogen6x.c
>> +++ b/board/boundary/nitrogen6x/nitrogen6x.c
>> @@ -330,7 +330,7 @@ int board_mmc_init(bd_t *bis)
>>
>>   u32 get_board_rev(void)
>>   {
>> -    return 0x63000;
>> +    return get_cpu_rev();
>>   }
>>
>>   #ifdef CONFIG_MXC_SPI
>>
>
> Since this convention is shared among at least SABRE Lite, SABRE SD,
> Nitrogen6x and Wandboard, wouldn't a weak function in imx-common/cpu.c
> be a better choice?
>

Oops.

I meant to say arch/arm/cpu/armv7/mx6/soc.c, not imx-common/cpu.c.
Fabio Estevam - March 26, 2013, 6:06 p.m.
Hi Eric,

On Tue, Mar 26, 2013 at 12:24 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:

> Since this convention is shared among at least SABRE Lite, SABRE SD,
> Nitrogen6x and Wandboard, wouldn't a weak function in imx-common/cpu.c
> be a better choice?
>
> +#ifdef CONFIG_REVISION_TAG
> +u32 __weak get_board_rev(void)
> +{
> +       return get_cpu_rev();
> +}
> +#endif
>
> Then boards could override things, but will do the reasonable thing
> without the extra code.

I like this idea. Will submit this change with the get_cpu_rev()
tomorrow, after I get more comments on the proposed get_cpu_rev patch.

Thanks,

Fabio Estevam

Patch

diff --git a/board/boundary/nitrogen6x/nitrogen6x.c b/board/boundary/nitrogen6x/nitrogen6x.c
index 229c237..fec0e3a 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -330,7 +330,7 @@  int board_mmc_init(bd_t *bis)
 
 u32 get_board_rev(void)
 {
-	return 0x63000;
+	return get_cpu_rev();
 }
 
 #ifdef CONFIG_MXC_SPI