(sorry, I'm slow at replying, attending some internal ARM conference)
On 31 January 2012 18:09, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 31 Jan 2012, Catalin Marinas wrote:
Maybe we could factor out the CPU-specific settings from proc-v*.S
into a separate arch/arm/boot/preload directory.
On Thu, Feb 02, 2012 at 02:32:03PM +, Catalin Marinas wrote:
We could do the same and move the bit enabling to separate repository :).
We must certainly could do but that doesn't get around the errata
issues when you have things before the kernel (or before these blobs)
enabling things like
On 2 February 2012 14:49, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, Feb 02, 2012 at 02:32:03PM +, Catalin Marinas wrote:
We could do the same and move the bit enabling to separate repository :).
We must certainly could do but that doesn't get around the errata
issues
On 31 January 2012 07:38, Shilimkar, Santosh santosh.shilim...@ti.com wrote:
On Tue, Jan 31, 2012 at 1:01 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
On 31 January 2012 05:21, Aneesh V ane...@ti.com wrote:
On Friday 27 January 2012 11:00 PM, Catalin Marinas wrote:
On Fri, Jan 20, 2012
On Tue, Jan 31, 2012 at 2:24 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
On 31 January 2012 07:38, Shilimkar, Santosh santosh.shilim...@ti.com wrote:
On Tue, Jan 31, 2012 at 1:01 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
On 31 January 2012 05:21, Aneesh V ane...@ti.com wrote:
On 31 January 2012 09:05, Shilimkar, Santosh santosh.shilim...@ti.com wrote:
On Tue, Jan 31, 2012 at 2:24 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
On 31 January 2012 07:38, Shilimkar, Santosh santosh.shilim...@ti.com
wrote:
On Tue, Jan 31, 2012 at 1:01 PM, Catalin Marinas
On Tue, Jan 31, 2012 at 02:35:51PM +0530, Shilimkar, Santosh wrote:
On Tue, Jan 31, 2012 at 2:24 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
Not if you write the code sequence in such a way that it also switches
the C bit to 0 and back to 1. I think Nicolas suggested that the
On Tue, Jan 31, 2012 at 09:53:25AM +, Catalin Marinas wrote:
Maybe we could factor out the CPU-specific settings from proc-v*.S
into a separate arch/arm/boot/preload directory. We keep proc-v*.S
entirely generic and the implementation-defined bits setting in the
preload code. You could
On Tue, Jan 31, 2012 at 3:26 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Jan 31, 2012 at 02:35:51PM +0530, Shilimkar, Santosh wrote:
On Tue, Jan 31, 2012 at 2:24 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
Not if you write the code sequence in such a way that it
On 31 January 2012 10:10, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Jan 31, 2012 at 09:53:25AM +, Catalin Marinas wrote:
Maybe we could factor out the CPU-specific settings from proc-v*.S
into a separate arch/arm/boot/preload directory. We keep proc-v*.S
entirely
On Tue, 31 Jan 2012, Catalin Marinas wrote:
Maybe we could factor out the CPU-specific settings from proc-v*.S
into a separate arch/arm/boot/preload directory. We keep proc-v*.S
entirely generic and the implementation-defined bits setting in the
preload code. You could have an option to link
On Tue, 31 Jan 2012, Shilimkar, Santosh wrote:
On Tue, Jan 31, 2012 at 3:26 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
So, as many people have said, we're not going to go down the route of
allowing platforms to hook into this code. There's plenty of other
solutions to
On Tue, Jan 31, 2012 at 11:57 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 31 Jan 2012, Shilimkar, Santosh wrote:
[...]
I also understand that patching early common code is going to be tricky
and of-course against the single zImage.
So the option mentioned by Nicolas and Catalin about
Hi Catalin,
On Friday 27 January 2012 11:00 PM, Catalin Marinas wrote:
On Fri, Jan 20, 2012 at 08:57:11AM +, Joe Woodward wrote:
So I re-iterate that we need to have solution to this problem.
... I don't want to be a pain, but it seems to me that this dicussion
didn't reach a full
On 31 January 2012 05:21, Aneesh V ane...@ti.com wrote:
On Friday 27 January 2012 11:00 PM, Catalin Marinas wrote:
On Fri, Jan 20, 2012 at 08:57:11AM +, Joe Woodward wrote:
So I re-iterate that we need to have solution to this problem.
... I don't want to be a pain, but it seems to me
On Tue, Jan 31, 2012 at 1:01 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
On 31 January 2012 05:21, Aneesh V ane...@ti.com wrote:
On Friday 27 January 2012 11:00 PM, Catalin Marinas wrote:
On Fri, Jan 20, 2012 at 08:57:11AM +, Joe Woodward wrote:
So I re-iterate that we need to have
...@arm.linux.org.uk, linux-omap@vger.kernel.org, linux-arm linux-arm-
ker...@lists.infradead.org
Date: Fri, 20 Jan 2012 08:57:11 +
Subject: Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by
uBoot)?
So I re-iterate that we need to have solution to this problem.
... I
On Fri, Jan 20, 2012 at 08:57:11AM +, Joe Woodward wrote:
So I re-iterate that we need to have solution to this problem.
... I don't want to be a pain, but it seems to me that this dicussion
didn't reach a full conclussion?
Probably not, because it depends on many variables. See below
So I re-iterate that we need to have solution to this problem.
... I don't want to be a pain, but it seems to me that this dicussion didn't
reach a full conclussion?
I think it was left with the open options being:
1) Leave the L2/outer cache enabled in the bootloader (not ideal and may
On Tue, Jan 17, 2012 at 10:02 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
On Tue, Jan 17, 2012 at 9:45 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre
...snip...
Fair point. It will be harder to maintain and won't be consistent.
Am not sure what you mean because secure API
as such isn't a problem. If you mean one standard interface
for all the ARM SOC's then that's something won't be
easy to handled because it is tied up the
Santosh, Russel,
On Monday 16 January 2012 06:52 PM, Shilimkar, Santosh wrote:
On Mon, Jan 16, 2012 at 2:13 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Jan 16, 2012 at 01:43:03PM +0100, Shilimkar, Santosh wrote:
This code will be in assembly and that's what I have
been
On Tue, Jan 17, 2012 at 08:54:44AM +, Joe Woodward wrote:
So, is the upshot of this that the kernel isn't going to be in a
position to enable the L2/outer cache on OMAP3 (due to the need for
hacky/unmaintainable code)?
Hence the bootloader/uBoot had better leave it enabled...
It could
Hi Catalin,
On Tuesday 17 January 2012 05:41 PM, Catalin Marinas wrote:
On Tue, Jan 17, 2012 at 08:54:44AM +, Joe Woodward wrote:
So, is the upshot of this that the kernel isn't going to be in a
position to enable the L2/outer cache on OMAP3 (due to the need for
hacky/unmaintainable code)?
On Tue, Jan 17, 2012 at 1:27 PM, Aneesh V ane...@ti.com wrote:
Hi Catalin,
On Tuesday 17 January 2012 05:41 PM, Catalin Marinas wrote:
On Tue, Jan 17, 2012 at 08:54:44AM +, Joe Woodward wrote:
So, is the upshot of this that the kernel isn't going to be in a
position to enable the
On Tue, Jan 17, 2012 at 12:40:54PM +, Shilimkar, Santosh wrote:
On Tue, Jan 17, 2012 at 1:27 PM, Aneesh V ane...@ti.com wrote:
Hi Catalin,
On Tuesday 17 January 2012 05:41 PM, Catalin Marinas wrote:
On Tue, Jan 17, 2012 at 08:54:44AM +, Joe Woodward wrote:
So, is the
On Tue, Jan 17, 2012 at 12:27:25PM +, Aneesh V wrote:
Hi Catalin,
On Tuesday 17 January 2012 05:41 PM, Catalin Marinas wrote:
On Tue, Jan 17, 2012 at 08:54:44AM +, Joe Woodward wrote:
So, is the upshot of this that the kernel isn't going to be in a
position to enable the L2/outer
On Tue, Jan 17, 2012 at 2:39 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
On Tue, Jan 17, 2012 at 12:40:54PM +, Shilimkar, Santosh wrote:
On Tue, Jan 17, 2012 at 1:27 PM, Aneesh V ane...@ti.com wrote:
Hi Catalin,
On Tuesday 17 January 2012 05:41 PM, Catalin Marinas wrote:
On Tue, Jan 17, 2012 at 3:39 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
On Tue, Jan 17, 2012 at 12:40:54PM +, Shilimkar, Santosh wrote:
Well the L2 can be configured as inner or outer, so above
alone won't work.
Boot-loader disabling L2 cache ( all caches) is still right thing
Catalin Marinas catalin.mari...@arm.com writes:
On Tue, Jan 17, 2012 at 12:27:25PM +, Aneesh V wrote:
But I thought enabling L2$ again in kernel is the cleaner solution.
Why? It gets enabled via SCTLR.M together with L1.
Not if the L2EN bit of the auxiliary control register was
On Tue, Jan 17, 2012 at 01:58:18PM +, Shilimkar, Santosh wrote:
On Tue, Jan 17, 2012 at 2:39 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
On Tue, Jan 17, 2012 at 12:40:54PM +, Shilimkar, Santosh wrote:
On A15 infact there are other CP15 registers which needs to be set
before
On Tue, Jan 17, 2012 at 5:27 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
On Tue, Jan 17, 2012 at 01:58:18PM +, Shilimkar, Santosh wrote:
On Tue, Jan 17, 2012 at 2:39 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
On Tue, Jan 17, 2012 at 12:40:54PM +, Shilimkar, Santosh
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
On Tue, Jan 17, 2012 at 5:27 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
BTW, does the firmware make any checks on what bits it allows to be set?
Some of them may have security implications (and may not even be
documented).
Anyway,
On Tue, Jan 17, 2012 at 02:58:18PM +0100, Shilimkar, Santosh wrote:
Patching in boot-loaders isn't an option either since every customers
prefers to use there own boot-loader and then controlling
this vital bits is impossible.
So I re-iterate that we need to have solution to this problem.
On Tue, Jan 17, 2012 at 04:27:21PM +, Catalin Marinas wrote:
Anyway, the first step is this API provided by the secure firmware.
Since such API may need to be called before the MMU is initialised,
Linux would need to have knowledge of the platform type early on. Having
some platform hook
On Tue, Jan 17, 2012 at 8:47 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Jan 17, 2012 at 04:27:21PM +, Catalin Marinas wrote:
Anyway, the first step is this API provided by the secure firmware.
Since such API may need to be called before the MMU is initialised,
Linux
On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
On Tue, Jan 17, 2012 at 5:27 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
BTW, does the firmware make any checks on what bits it allows to be set?
Some of them may
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
How about allowing platform hooks for single SOC builds. I mean having
this code under !single_zImage or something like
On Tue, Jan 17, 2012 at 09:11:37PM +0100, Shilimkar, Santosh wrote:
On Tue, Jan 17, 2012 at 8:47 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Jan 17, 2012 at 04:27:21PM +, Catalin Marinas wrote:
Anyway, the first step is this API provided by the secure firmware.
On Tue, 17 Jan 2012, Nicolas Pitre wrote:
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
How about allowing platform hooks for single SOC builds. I mean having
On Tue, Jan 17, 2012 at 9:45 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
How about allowing platform hooks for single SOC
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
On Tue, Jan 17, 2012 at 9:45 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
On Tue, Jan 17, 2012 at 09:27:02PM +0100, Shilimkar, Santosh wrote:
There is nothing fancy here. It's an ARM security architecture feature
which OMAP implements. Have given enough reason about boot-loaders
issues.
There is nothing fancy about not being permitted to access registers
due to
The latest uBoot release (2011.12) disables the L2/outer cache during boot on
OMAP boards.
uBoot commit: armv7: disable L2 cache in cleanup_before_linux() on 6th Dec
2011 by Aneesh V adds the following to
uBootSources/arch/arm/cpu/armv7/cpu.c:cleanup_before_linux():
...
+ linux-arm, Russell and Catalin
On Mon, Jan 16, 2012 at 11:03 AM, Joe Woodward j...@terrafix.co.uk wrote:
The latest uBoot release (2011.12) disables the L2/outer cache during boot on
OMAP boards.
uBoot commit: armv7: disable L2 cache in cleanup_before_linux() on 6th Dec
2011 by Aneesh V
On Mon, Jan 16, 2012 at 11:18:21AM +0100, Shilimkar, Santosh wrote:
+ linux-arm, Russell and Catalin
On Mon, Jan 16, 2012 at 11:03 AM, Joe Woodward j...@terrafix.co.uk wrote:
The latest uBoot release (2011.12) disables the L2/outer cache during boot
on OMAP boards.
uBoot commit:
On Mon, Jan 16, 2012 at 11:59 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Jan 16, 2012 at 11:18:21AM +0100, Shilimkar, Santosh wrote:
+ linux-arm, Russell and Catalin
On Mon, Jan 16, 2012 at 11:03 AM, Joe Woodward j...@terrafix.co.uk wrote:
The latest uBoot release
On Mon, Jan 16, 2012 at 01:43:03PM +0100, Shilimkar, Santosh wrote:
This code will be in assembly and that's what I have
been using. Not having stack shoudn't be a blocker
and can be work-around in this code. And this API
has to be anyway called before MMU is enabled.
What about SMC on OMAP
On Mon, Jan 16, 2012 at 2:13 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Jan 16, 2012 at 01:43:03PM +0100, Shilimkar, Santosh wrote:
This code will be in assembly and that's what I have
been using. Not having stack shoudn't be a blocker
and can be work-around in this
49 matches
Mail list logo
