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...
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