On 2 February 2012 14:49, Russell King - ARM Linux
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 when you have thi
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
(sorry, I'm slow at replying, attending some internal ARM conference)
On 31 January 2012 18:09, Nicolas Pitre 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. We keep proc
On Tue, Jan 31, 2012 at 11:57 PM, Nicolas Pitre 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 1:1 mapp
On Tue, 31 Jan 2012, Shilimkar, Santosh wrote:
> On Tue, Jan 31, 2012 at 3:26 PM, Russell King - ARM Linux
> 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 this problem in di
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 li
On 31 January 2012 10:10, Russell King - ARM Linux
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 generic and the imple
On Tue, Jan 31, 2012 at 3:26 PM, Russell King - ARM Linux
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
>> wrote:
>> > Not if you write the code sequence in such a way that it also switches
>> > the C bit to 0 and
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 02:35:51PM +0530, Shilimkar, Santosh wrote:
> On Tue, Jan 31, 2012 at 2:24 PM, Catalin Marinas
> 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
> > platform code could go
On 31 January 2012 09:05, Shilimkar, Santosh wrote:
> On Tue, Jan 31, 2012 at 2:24 PM, Catalin Marinas
> wrote:
>> On 31 January 2012 07:38, Shilimkar, Santosh
>> wrote:
>>> On Tue, Jan 31, 2012 at 1:01 PM, Catalin Marinas
>>> wrote:
On 31 January 2012 05:21, Aneesh V wrote:
> On Fri
On Tue, Jan 31, 2012 at 2:24 PM, Catalin Marinas
wrote:
> On 31 January 2012 07:38, Shilimkar, Santosh wrote:
>> On Tue, Jan 31, 2012 at 1:01 PM, Catalin Marinas
>> wrote:
>>> On 31 January 2012 05:21, Aneesh V wrote:
On Friday 27 January 2012 11:00 PM, Catalin Marinas wrote:
> On Fri,
On 31 January 2012 07:38, Shilimkar, Santosh wrote:
> On Tue, Jan 31, 2012 at 1:01 PM, Catalin Marinas
> wrote:
>> On 31 January 2012 05:21, Aneesh V 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
On Tue, Jan 31, 2012 at 1:01 PM, Catalin Marinas
wrote:
> On 31 January 2012 05:21, Aneesh V 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.
On 31 January 2012 05:21, Aneesh V 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 that
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 conclus
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 bel
r.kernel.org, "linux-arm"
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 don't want to be a p
>
> 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 wrote:
> On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
>
>> On Tue, Jan 17, 2012 at 9:45 PM, Nicolas Pitre wrote:
>> > On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
>> >
>> >> On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre wrote:
>> >> > On Tue,
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 se
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
> On Tue, Jan 17, 2012 at 9:45 PM, Nicolas Pitre wrote:
> > On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
> >
> >> On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre wrote:
> >> > On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
> >> >
> >> >> How about
On Tue, Jan 17, 2012 at 9:45 PM, Nicolas Pitre wrote:
> On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
>
>> On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre wrote:
>> > On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
>> >
>> >> How about allowing platform hooks for single SOC builds. I mean having
>
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 wrote:
> > > On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
> > >
> > >> How about allowing platform hooks for single SOC builds. I mean having
> > >> t
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
> 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
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
> On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre 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 that. Tha
On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre wrote:
> On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
>
>> On Tue, Jan 17, 2012 at 5:27 PM, Catalin Marinas
>> wrote:
>> > BTW, does the firmware make any checks on what bits it allows to be set?
>> > Some of them may have security implications (an
On Tue, Jan 17, 2012 at 8:47 PM, Russell King - ARM Linux
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 would need to h
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 hoo
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, 17 Jan 2012, Shilimkar, Santosh wrote:
> On Tue, Jan 17, 2012 at 5:27 PM, Catalin Marinas
> 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, the first s
On Tue, Jan 17, 2012 at 5:27 PM, Catalin Marinas
wrote:
> On Tue, Jan 17, 2012 at 01:58:18PM +, Shilimkar, Santosh wrote:
>> On Tue, Jan 17, 2012 at 2:39 PM, Catalin Marinas
>> wrote:
>> > On Tue, Jan 17, 2012 at 12:40:54PM +, Shilimkar, Santosh wrote:
>> >> On A15 infact there are other
On Tue, Jan 17, 2012 at 01:58:18PM +, Shilimkar, Santosh wrote:
> On Tue, Jan 17, 2012 at 2:39 PM, Catalin Marinas
> 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 MMU is enabled
Catalin Marinas 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 cleared, and
u-boot messe
On Tue, Jan 17, 2012 at 3:39 PM, Catalin Marinas
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
>> and that's wha
On Tue, Jan 17, 2012 at 2:39 PM, Catalin Marinas
wrote:
> On Tue, Jan 17, 2012 at 12:40:54PM +, Shilimkar, Santosh wrote:
>> On Tue, Jan 17, 2012 at 1:27 PM, Aneesh V wrote:
>> > Hi Catalin,
>> >
>> >
>> > On Tuesday 17 January 2012 05:41 PM, Catalin Marinas wrote:
>> >>
>> >> On Tue, Jan 17,
On Tuesday 17 January 2012 07:11 PM, Catalin Marinas wrote:
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
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 th
On Tue, Jan 17, 2012 at 12:40:54PM +, Shilimkar, Santosh wrote:
> On Tue, Jan 17, 2012 at 1:27 PM, 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
On Tue, Jan 17, 2012 at 1:27 PM, 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 L
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 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 cou
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
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 stac
...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 tie
On Mon, Jan 16, 2012 at 2:13 PM, Russell King - ARM Linux
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 code. And this API
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 OMA
On Mon, Jan 16, 2012 at 11:59 AM, Russell King - ARM Linux
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 wrote:
>> > The latest uBoot release (2011.12) disables the L2/outer cac
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 wrote:
> > The latest uBoot release (2011.12) disables the L2/outer cache during boot
> > on OMAP boards.
> >
> > uBoot commit: "armv7: disabl
+ linux-arm, Russell and Catalin
On Mon, Jan 16, 2012 at 11:03 AM, Joe Woodward 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 adds the foll
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():
...
v7_out_cache_disa
50 matches
Mail list logo
