From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeroen Hofstee Date: Wed, 10 Dec 2014 11:25:28 +0100 Subject: [U-Boot] ti, am3517: errata 430973 workaround In-Reply-To: References: <548623DE.10704@myspectrum.nl> Message-ID: <54881F98.7060908@myspectrum.nl> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Robert, Andreas, On 09-12-14 22:45, Robert Nelson wrote: > On Mon, Dec 8, 2014 at 4:19 PM, Jeroen Hofstee wrote: >> Hi, >> >> A while ago [1], a RFC was posted to disable workaround for >> besides others, errata 430973. It is a bit unclear to me which >> revision actually need this workaround, but as suggested in >> [2] also enabling this workaround in Linux seem to make some >> weird problems go away in linux (signal 4, bad instruction, >> 11 segfaults etc). >> >> As said, I am a bit in doubt why this works. The board in question >> is a tam3517 derived one: >> >> cat /proc/cpuinfo >> Processor : ARMv7 Processor rev 7 (v7l) >> BogoMIPS : 397.57 >> Features : swp half thumb fastmult vfp edsp neon vfpv3 tls >> CPU implementer : 0x41 >> CPU architecture: 7 >> CPU variant : 0x1 >> CPU part : 0xc08 >> CPU revision : 7 >> >> Which makes this a r1p7 I assume, and hence the workaround >> of linux, CONFIG_ARM_ERRATA_430973, "This option enables the >> workaround for the 430973 Cortex-A8 (r1p0..r1p2) erratum", >> should not be needed it seems. > Digging thru my old beagle notes 430973 is also needed for "r1p3" > (dm3730/bb-xm), so that config option was never updated since the > errata was first discovered in r1p2 devices.. > > Fixed in r2p1 sounds about right, as i know for sure it works fine in > 'r3p2' (am335x/bbb) Thanks for the clarification. I sent a patch to the linux folks to update the help text. Regards, Jeroen