From: jonathan@jonmasters•org (Jon Masters)
To: linux-arm-kernel@lists•infradead.org
Subject: Errata on multiplatform kernels
Date: Tue, 11 Dec 2012 23:56:42 -0500 [thread overview]
Message-ID: <50C80E8A.8080107@jonmasters.org> (raw)
In-Reply-To: <50C7F36E.3090308@gmail.com>
On 12/11/2012 10:01 PM, Rob Herring wrote:
> On 12/11/2012 06:51 PM, Russell King - ARM Linux wrote:
>> On Tue, Dec 11, 2012 at 07:41:18PM -0500, Jon Masters wrote:
>>> On 12/11/2012 01:01 PM, Tony Lindgren wrote:
>>>> * Olof Johansson <olof@lixom•net> [121210 21:38]:
>>>>> Hi,
>>>>>
>>>>> On Mon, Dec 10, 2012 at 9:20 PM, Tony Prisk <linux@prisktech•co.nz> wrote:
>>>>>> How are errata handled on multiplatform kernels?
>>>>>>
>>>>>> There don't appear to be any errata selected by default in any of the
>>>>>> current multiplatform options, but presumably it will happen eventually.
>>>>>>
>>>>>> Does that mean the errata will be applied to all machines that boot with
>>>>>> the errata selected, even if not required?
>>>>>
>>>>> Yes. To date I believe most errata we have are just performance hits
>>>>> on platforms that don't need it.
>>>>>
>>>>> Other architectures have in some cases added runtime patching (out) of
>>>>> workarounds that aren't needed on the current platform for the ones
>>>>> that have significant performance impact. I'm guessing we'll end up
>>>>> with something similar eventually but until then we'll try to just go
>>>>> with the superset of needed errata.
>>>>
>>>> We can't enable any of the errata if there's a chance that it will behave
>>>> in a different way for secure mode devices compared to non-secure devices.
>>>>
>>>> The discussion is in the thread "[PATCH] ARM: Fix errata 751472 handling
>>>> on Cortex-A9 r1p*".
>>>>
>>>> The conclusion was that we cannot enable any errata for multiplatform,
>>>> and must assume the errata is handled by the bootloader. Multiplatform
>>>> image is already broken for at least omap4 as 751472 is selected.
>>>
>>> On some platforms with a PL310 we have errata 588369 and 727915
>>> (especially enabled on OMAP4 targets) which will cause an external abort
>>> when enabled and then booted on highbank systems. This has taken the
>>> last couple of days on and off to track down. So I guess we need to
>>> basically disable these in our (Fedora) multiplatform kernel and then
>>> assume that e.g. PandaBoard will implement some U-Boot fix if it needs
>>> to have one? Not sure exactly what that fix is going to look like :)
>>
>> Neither 588369 nor 727915 are something a boot loader can do - they have
>> to be done in the kernel. If they're causing highbank systems to fail
>> that needs to be debugged.
>>
>> My guess is that highbank is another non-secure system, and the L2x0
>> code is trying to use pl310_set_debug() which will fail on non-secure
>> systems as the 'set_debug' hook is not being overriden.
>>
>> If there was a way to tell that we're running on a non-secure system,
>> we could automatically point set_debug() to a nop function, but it
>> would be far more preferable for highbank to provide the hook. (That
>> could be itself a no-op if it doesn't require the work-around.)
>
> Actually, we should check the pl310 revision and set .set_debug to NULL
> on r3p1 and later. This will fix highbank and any other platform that
> doesn't need the work-around. I'd assume platforms that are non-secure
> and need this work-around will override .set_debug. I'll work on a patch.
Ok. But Tony had a good idea too on the secure vs. non-secure thing. For
those cases where a fix can't be done in pre-boot platform code I think
that's a good idea for future errata.
Jon.
next prev parent reply other threads:[~2012-12-12 4:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-11 5:20 Errata on multiplatform kernels Tony Prisk
2012-12-11 5:32 ` Olof Johansson
2012-12-11 18:01 ` Tony Lindgren
2012-12-12 0:41 ` Jon Masters
2012-12-12 0:51 ` Russell King - ARM Linux
2012-12-12 0:54 ` Jon Masters
2012-12-12 3:01 ` Rob Herring
2012-12-12 4:56 ` Jon Masters [this message]
2012-12-12 0:52 ` Jon Masters
2012-12-12 1:28 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50C80E8A.8080107@jonmasters.org \
--to=jonathan@jonmasters$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox