From: Tony Lindgren <tony@atomide.com>
To: Rob Herring <robherring2@gmail.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
Dave Martin <dave.martin@linaro.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Santosh Shilimkar <santosh.shilimkar@ti.com>,
Jon Hunter <jon-hunter@ti.com>,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
Date: Wed, 14 Nov 2012 14:21:59 -0800 [thread overview]
Message-ID: <20121114222159.GB6801@atomide.com> (raw)
In-Reply-To: <50A413D4.7000405@gmail.com>
* Rob Herring <robherring2@gmail.com> [121114 13:59]:
> On 11/14/2012 02:32 PM, Tony Lindgren wrote:
> >
> > Checking for the bit already set should work in this case, I'll post
> > a patch for that shortly.
>
> Can you actually read the state of the diagnostic register in non-secure
> mode? If you can on the A9, is the same true on A8 or others?
Looks like it can be read on at least TI omap 4430 which is A9.
But it reads as zero, so the below patch is what I came up with.
No idea if assuming that zero value for the diagnostic register
is safe.. What's the default value of the diagnostic register supposed
to be?
> Multi-platform kernels present a new problem in that we basically need
> to enable all errata work-arounds. I've been meaning to look thru the
> errata work-arounds to figure out which ones can be selected for
> multi-platform kernels without side effects on unaffected parts (i.e.
> set a chicken bit based on core revision). For any in runtime paths, we
> may need to do runtime patching if they have performance impact.
Yeah that's how I ran into it as multiplatform enabled omap booted
on other omaps but not on omap4.
Regards,
Tony
From: Tony Lindgren <tony@atomide.com>
Date: Tue, 13 Nov 2012 16:57:42 -0800
Subject: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 for secure mode
Looks like enabling CONFIG_ARM_ERRATA_751472 causes TI omap4 blaze
to not boot when enabled. The ARM core on it is an earlier r1p2.
This seems to be caused by the write to the diagnostic register
that shortly after causes an exception as writing to the diagnostic
register on systems with secure mode is not allowed.
Also it seems that reading the diagnostic register results zero
so we may not be able to check if bit #11 is already set.
Let's assume that if the diagnostic register is zero, we don't
want to touch it as it seems to hint secure mode at least on
TI omaps. If it's non-zero, check if bit #11 is set and only
attempt to set it if not set.
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -238,9 +238,13 @@ __v7_setup:
#if defined(CONFIG_ARM_ERRATA_751472) && defined(CONFIG_SMP)
ALT_SMP(cmp r6, #0x30) @ present prior to r3p0
ALT_UP_B(1f)
- mrclt p15, 0, r10, c15, c0, 1 @ read diagnostic register
- orrlt r10, r10, #1 << 11 @ set bit #11
- mcrlt p15, 0, r10, c15, c0, 1 @ write diagnostic register
+ bge 1f @ not needed for r3p0 and later
+ mrc p15, 0, r10, c15, c0, 1 @ read diagnostic register
+ teq r10, #0 @ zero for secure mode?
+ beq 1f @ bail out for secure mode
+ tst r10, #1 << 11 @ bit #11 already set?
+ orreq r10, r10, #1 << 11 @ set bit #11 if not set
+ mcreq p15, 0, r10, c15, c0, 1 @ write diagnostic register
1:
#endif
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
Date: Wed, 14 Nov 2012 14:21:59 -0800 [thread overview]
Message-ID: <20121114222159.GB6801@atomide.com> (raw)
In-Reply-To: <50A413D4.7000405@gmail.com>
* Rob Herring <robherring2@gmail.com> [121114 13:59]:
> On 11/14/2012 02:32 PM, Tony Lindgren wrote:
> >
> > Checking for the bit already set should work in this case, I'll post
> > a patch for that shortly.
>
> Can you actually read the state of the diagnostic register in non-secure
> mode? If you can on the A9, is the same true on A8 or others?
Looks like it can be read on at least TI omap 4430 which is A9.
But it reads as zero, so the below patch is what I came up with.
No idea if assuming that zero value for the diagnostic register
is safe.. What's the default value of the diagnostic register supposed
to be?
> Multi-platform kernels present a new problem in that we basically need
> to enable all errata work-arounds. I've been meaning to look thru the
> errata work-arounds to figure out which ones can be selected for
> multi-platform kernels without side effects on unaffected parts (i.e.
> set a chicken bit based on core revision). For any in runtime paths, we
> may need to do runtime patching if they have performance impact.
Yeah that's how I ran into it as multiplatform enabled omap booted
on other omaps but not on omap4.
Regards,
Tony
From: Tony Lindgren <tony@atomide.com>
Date: Tue, 13 Nov 2012 16:57:42 -0800
Subject: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 for secure mode
Looks like enabling CONFIG_ARM_ERRATA_751472 causes TI omap4 blaze
to not boot when enabled. The ARM core on it is an earlier r1p2.
This seems to be caused by the write to the diagnostic register
that shortly after causes an exception as writing to the diagnostic
register on systems with secure mode is not allowed.
Also it seems that reading the diagnostic register results zero
so we may not be able to check if bit #11 is already set.
Let's assume that if the diagnostic register is zero, we don't
want to touch it as it seems to hint secure mode at least on
TI omaps. If it's non-zero, check if bit #11 is set and only
attempt to set it if not set.
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -238,9 +238,13 @@ __v7_setup:
#if defined(CONFIG_ARM_ERRATA_751472) && defined(CONFIG_SMP)
ALT_SMP(cmp r6, #0x30) @ present prior to r3p0
ALT_UP_B(1f)
- mrclt p15, 0, r10, c15, c0, 1 @ read diagnostic register
- orrlt r10, r10, #1 << 11 @ set bit #11
- mcrlt p15, 0, r10, c15, c0, 1 @ write diagnostic register
+ bge 1f @ not needed for r3p0 and later
+ mrc p15, 0, r10, c15, c0, 1 @ read diagnostic register
+ teq r10, #0 @ zero for secure mode?
+ beq 1f @ bail out for secure mode
+ tst r10, #1 << 11 @ bit #11 already set?
+ orreq r10, r10, #1 << 11 @ set bit #11 if not set
+ mcreq p15, 0, r10, c15, c0, 1 @ write diagnostic register
1:
#endif
next prev parent reply other threads:[~2012-11-14 22:22 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-14 18:53 [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p* Tony Lindgren
2012-11-14 18:53 ` Tony Lindgren
2012-11-14 19:01 ` Russell King - ARM Linux
2012-11-14 19:01 ` Russell King - ARM Linux
2012-11-14 19:19 ` Tony Lindgren
2012-11-14 19:19 ` Tony Lindgren
2012-11-14 19:06 ` Jon Hunter
2012-11-14 19:06 ` Jon Hunter
2012-11-14 19:21 ` Tony Lindgren
2012-11-14 19:21 ` Tony Lindgren
2012-11-14 20:22 ` Russell King - ARM Linux
2012-11-14 20:22 ` Russell King - ARM Linux
2012-11-14 20:32 ` Tony Lindgren
2012-11-14 20:32 ` Tony Lindgren
2012-11-14 21:57 ` Rob Herring
2012-11-14 21:57 ` Rob Herring
2012-11-14 22:21 ` Tony Lindgren [this message]
2012-11-14 22:21 ` Tony Lindgren
2012-11-15 0:54 ` Rob Herring
2012-11-15 0:54 ` Rob Herring
2012-11-15 2:08 ` Tony Lindgren
2012-11-15 2:08 ` Tony Lindgren
2012-11-15 11:01 ` Catalin Marinas
2012-11-15 11:01 ` Catalin Marinas
2012-11-15 12:41 ` Siarhei Siamashka
2012-11-15 12:41 ` Siarhei Siamashka
2012-11-15 13:36 ` Russell King - ARM Linux
2012-11-15 13:36 ` Russell King - ARM Linux
2012-11-15 13:52 ` Catalin Marinas
2012-11-15 13:52 ` Catalin Marinas
2012-11-15 15:14 ` Måns Rullgård
2012-11-15 15:14 ` Måns Rullgård
2012-11-15 14:31 ` Rob Herring
2012-11-15 14:31 ` Rob Herring
2012-11-15 14:37 ` Catalin Marinas
2012-11-15 14:37 ` Catalin Marinas
2012-11-15 15:37 ` Rob Herring
2012-11-15 15:37 ` Rob Herring
2012-11-15 16:06 ` Catalin Marinas
2012-11-15 16:06 ` Catalin Marinas
2012-11-16 10:05 ` Russell King - ARM Linux
2012-11-16 10:05 ` Russell King - ARM Linux
2012-11-16 17:13 ` Tony Lindgren
2012-11-16 17:13 ` Tony Lindgren
2012-11-16 18:41 ` Russell King - ARM Linux
2012-11-16 18:41 ` Russell King - ARM Linux
2012-11-16 9:59 ` Russell King - ARM Linux
2012-11-16 9:59 ` Russell King - ARM Linux
2012-11-16 18:09 ` Catalin Marinas
2012-11-16 18:09 ` Catalin Marinas
2012-11-16 18:39 ` Russell King - ARM Linux
2012-11-16 18:39 ` Russell King - ARM Linux
2012-11-17 10:46 ` Catalin Marinas
2012-11-17 10:46 ` Catalin Marinas
2012-11-15 9:22 ` Russell King - ARM Linux
2012-11-15 9:22 ` Russell King - ARM Linux
2012-12-12 0:46 ` Jon Masters
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=20121114222159.GB6801@atomide.com \
--to=tony@atomide.com \
--cc=Catalin.Marinas@arm.com \
--cc=dave.martin@linaro.org \
--cc=jon-hunter@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=robherring2@gmail.com \
--cc=santosh.shilimkar@ti.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.