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.nel...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
