[U-Boot] [PATCH 1/2] nitrogen6x: Pass the correct CPU revision to the kernel
Eric Nelson
eric.nelson at boundarydevices.com
Sat Mar 16 21:27:13 CET 2013
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 at 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
More information about the U-Boot
mailing list