On 16 November 2012 18:39, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Nov 16, 2012 at 06:09:28PM +, Catalin Marinas wrote:
On Fri, Nov 16, 2012 at 09:59:21AM +, Russell King - ARM Linux wrote:
On Thu, Nov 15, 2012 at 08:31:33AM -0600, Rob Herring wrote:
So we
On Thu, Nov 15, 2012 at 08:31:33AM -0600, Rob Herring wrote:
So we should make all these work-arounds depend on !MULTI_PLATFORM then.
No, because some of the work-arounds don't require setting bits in magic
registers.
Also realise this: we test for the revision of the CPU to which they're
On Thu, Nov 15, 2012 at 09:37:08AM -0600, Rob Herring wrote:
Does that work for Versatile Express CA9? It needs ARM_ERRATA_751472.
On VE Linux runs in secure mode, so it's fine.
WTF? You are contradicting yourself.
No, it's already been explained; the problem is lack of understanding.
* Russell King - ARM Linux li...@arm.linux.org.uk [121116 02:07]:
So, we don't detect whether we're running in secure mode or not; as I've
already stated, we don't have a way to do that. We instead only apply
work-arounds which aren't already enabled prior to the kernel booting.
So, even on
On Fri, Nov 16, 2012 at 09:59:21AM +, Russell King - ARM Linux wrote:
On Thu, Nov 15, 2012 at 08:31:33AM -0600, Rob Herring wrote:
So we should make all these work-arounds depend on !MULTI_PLATFORM then.
No, because some of the work-arounds don't require setting bits in magic
registers.
On Fri, Nov 16, 2012 at 06:09:28PM +, Catalin Marinas wrote:
On Fri, Nov 16, 2012 at 09:59:21AM +, Russell King - ARM Linux wrote:
On Thu, Nov 15, 2012 at 08:31:33AM -0600, Rob Herring wrote:
So we should make all these work-arounds depend on !MULTI_PLATFORM then.
No, because
On Fri, Nov 16, 2012 at 09:13:33AM -0800, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [121116 02:07]:
So, we don't detect whether we're running in secure mode or not; as I've
already stated, we don't have a way to do that. We instead only apply
work-arounds
On Wed, Nov 14, 2012 at 02:21:59PM -0800, Tony Lindgren wrote:
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?
No, that's not safe. What if your pre-kernel code has asked the secure
monitor to set
On Thu, Nov 15, 2012 at 12:54:48AM +, Rob Herring wrote:
On 11/14/2012 04:21 PM, Tony Lindgren wrote:
* Rob Herring robherri...@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
On Thu, Nov 15, 2012 at 1:01 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
On Thu, Nov 15, 2012 at 12:54:48AM +, Rob Herring wrote:
On 11/14/2012 04:21 PM, Tony Lindgren wrote:
* Rob Herring robherri...@gmail.com [121114 13:59]:
On 11/14/2012 02:32 PM, Tony Lindgren wrote:
On Thu, Nov 15, 2012 at 02:41:43PM +0200, Siarhei Siamashka wrote:
BTW, I always wondered about what could be preventing TI and the other
silicon vendors from using something like an SMC API based on
asymmetric cryptography?
The answer is... nothing. But it didn't happen and we're stuck with
On Thu, Nov 15, 2012 at 12:41:43PM +, Siarhei Siamashka wrote:
On Thu, Nov 15, 2012 at 1:01 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
On Thu, Nov 15, 2012 at 12:54:48AM +, Rob Herring wrote:
On 11/14/2012 04:21 PM, Tony Lindgren wrote:
* Rob Herring robherri...@gmail.com
On 11/15/2012 05:01 AM, Catalin Marinas wrote:
On Thu, Nov 15, 2012 at 12:54:48AM +, Rob Herring wrote:
On 11/14/2012 04:21 PM, Tony Lindgren wrote:
* Rob Herring robherri...@gmail.com [121114 13:59]:
On 11/14/2012 02:32 PM, Tony Lindgren wrote:
Checking for the bit already set should
On Thu, Nov 15, 2012 at 02:31:33PM +, Rob Herring wrote:
On 11/15/2012 05:01 AM, Catalin Marinas wrote:
On Thu, Nov 15, 2012 at 12:54:48AM +, Rob Herring wrote:
On 11/14/2012 04:21 PM, Tony Lindgren wrote:
* Rob Herring robherri...@gmail.com [121114 13:59]:
On 11/14/2012 02:32 PM,
Catalin Marinas catalin.mari...@arm.com writes:
On Thu, Nov 15, 2012 at 12:41:43PM +, Siarhei Siamashka wrote:
BTW, I always wondered about what could be preventing TI and the other
silicon vendors from using something like an SMC API based on
asymmetric cryptography? My understanding is
On 11/15/2012 08:37 AM, Catalin Marinas wrote:
On Thu, Nov 15, 2012 at 02:31:33PM +, Rob Herring wrote:
On 11/15/2012 05:01 AM, Catalin Marinas wrote:
On Thu, Nov 15, 2012 at 12:54:48AM +, Rob Herring wrote:
On 11/14/2012 04:21 PM, Tony Lindgren wrote:
* Rob Herring
On Thu, Nov 15, 2012 at 03:37:08PM +, Rob Herring wrote:
On 11/15/2012 08:37 AM, Catalin Marinas wrote:
On Thu, Nov 15, 2012 at 02:31:33PM +, Rob Herring wrote:
Does that work for Versatile Express CA9? It needs ARM_ERRATA_751472.
On VE Linux runs in secure mode, so it's fine.
Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze
to not boot when enabled. The ARM core on it is an earlier r1p2:
CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d
Unfortunately I don't have the details of errata 751472, but I'm
guessing we need to disable it for
On Wed, Nov 14, 2012 at 10:53:35AM -0800, Tony Lindgren wrote:
Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze
to not boot when enabled. The ARM core on it is an earlier r1p2:
CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d
Unfortunately I don't have the
On 11/14/2012 12:53 PM, Tony Lindgren wrote:
Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze
to not boot when enabled. The ARM core on it is an earlier r1p2:
CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d
Unfortunately I don't have the details of errata
* Russell King - ARM Linux li...@arm.linux.org.uk [121114 11:03]:
On Wed, Nov 14, 2012 at 10:53:35AM -0800, Tony Lindgren wrote:
Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze
to not boot when enabled. The ARM core on it is an earlier r1p2:
CPU: ARMv7 Processor
* Jon Hunter jon-hun...@ti.com [121114 11:09]:
On 11/14/2012 12:53 PM, Tony Lindgren wrote:
Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze
to not boot when enabled. The ARM core on it is an earlier r1p2:
CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d
On Wed, Nov 14, 2012 at 01:06:53PM -0600, Jon Hunter wrote:
On 11/14/2012 12:53 PM, Tony Lindgren wrote:
Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze
to not boot when enabled. The ARM core on it is an earlier r1p2:
CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7),
* Russell King - ARM Linux li...@arm.linux.org.uk [121114 12:24]:
On Wed, Nov 14, 2012 at 01:06:53PM -0600, Jon Hunter wrote:
On 11/14/2012 12:53 PM, Tony Lindgren wrote:
Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze
to not boot when enabled. The ARM core on it is an
On 11/14/2012 02:32 PM, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [121114 12:24]:
On Wed, Nov 14, 2012 at 01:06:53PM -0600, Jon Hunter wrote:
On 11/14/2012 12:53 PM, Tony Lindgren wrote:
Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze
to not boot
* Rob Herring robherri...@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
On 11/14/2012 04:21 PM, Tony Lindgren wrote:
* Rob Herring robherri...@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
* Rob Herring robherri...@gmail.com [121114 16:56]:
On 11/14/2012 04:21 PM, Tony Lindgren wrote:
* Rob Herring robherri...@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
28 matches
Mail list logo
