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

[Eric Nelson <eric.nelson@boundarydevices.com>]

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