From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Andreas_Bie=DFmann?= Date: Tue, 09 Jul 2013 12:42:27 +0200 Subject: [U-Boot] [RFC] ARM: omap3: Add option to disable errata workarounds. In-Reply-To: <20130709111040.77d19940@lilith> References: <1373356832-28983-1-git-send-email-anaumann@ultratronik.de> <51DBC4EA.4090104@andin.de> <20130709111040.77d19940@lilith> Message-ID: <51DBE913.20202@gmail.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 Andreas, On 07/09/2013 11:10 AM, Albert ARIBAUD wrote: > Hi Andreas, > > On Tue, 09 Jul 2013 10:08:10 +0200, Andreas Naumann > wrote: > >> Hi, >> >> It seems that all three ARM errata workarounds done in omap3 board-init >> (#454179 #430973 #621766) are solved/not longer needed e.g. in the >> AM/DM37xx chips. Other people have noticed this: >> http://e2e.ti.com/support/arm/sitara_arm/f/791/t/254742.aspx >> >> When still applying them (especcially #430973), lots of segmentations >> faults and other strange stuff begin to appear. I read your link the other way round. If the #430973 errata fix is _not_ applied to r3p2 it gives a lot of segfaults. Unfortunately the thread has noc more information on that. >> So as a simple solution I propose adding a config option to remove these >> workarounds for boards/silicon that dont need them. Is this sensible or >> should there be more automatism? >> >> >> regards, >> Andreas >> >> >> PS. Does anybody have the "ARM Core Cortex-A8 (AT400/AT401) errata" >> document to make sure my assumption above holds true? I have rev 20.0 from 13-Apr-10. The three mentioned errata should be fixed in r2p1. > Two remarks: > > 1. I would prefer the option to be the other way around, i.e. forcing > the inclusion of the workaround when defined rather than when not > defined; e.g. CONFIG_SYS_CORTEXA8_WORK_AROUND_ERRATA > > 2. (if applicable) I would prefer erratum-specific options, e.g. > CONFIG_SYS_CORTEXA8_WORK_AROUND_ERRATUM_430973 -- ok, "ERRATA" will be > fine too; what I want is easing the search for errata by number. I join Albert's suggestion. Another solution could be to read the silicon revision and enable erratum workarounds on that information. It would be a step towards single binary. Best regards Andreas Bie?mann