From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Nelson Date: Sat, 16 Mar 2013 13:27:13 -0700 Subject: [U-Boot] [PATCH 1/2] nitrogen6x: Pass the correct CPU revision to the kernel In-Reply-To: References: <1363381594-17077-1-git-send-email-festevam@gmail.com> <5143BAE6.3030902@boundarydevices.com> <51449A34.7080902@boundarydevices.com> Message-ID: <5144D5A1.2020302@boundarydevices.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > 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