From: aneesh@ti•com (Aneesh V)
To: linux-arm-kernel@lists•infradead.org
Subject: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
Date: Tue, 17 Jan 2012 17:31:28 +0530 [thread overview]
Message-ID: <4F156318.7030309@ti.com> (raw)
In-Reply-To: <CAMQu2gzPGrbBd4_SOM0TFfGH_Y+XYzoh2XjsoPgpzU10tFOpYQ@mail.gmail.com>
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
> <linux@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 code. And this API
>>> has to be anyway called before MMU is enabled.
>>
>> What about SMC on OMAP potentially corrupting most of the integer
>> registers? What if it corrupts an integer register which we depend
>> upon? You don't have a stack here to save those registers. We'd
>> need at least one additional register to save the old 'lr' value.
>>
> That's right.
>
>> What about other secure monitors? Some implementations require you to
>> give parameters via memory. How do you obtain that memory that early
>> on in the kernel boot (you haven't parsed anything here.)
>>
>> Not only that but you're asking to make the kernel boot a _lot_ more
>> fragile, when people start stuffing all kinds of utter shite into this
>> hook - and then we're burdened again with the old 'my kernel won't
>> boot and it remains silent, well your debug code is utter shite get rid
>> of it' crap that we used to have in the early 2000s.
>>
>> I really don't want to go anywhere near that situation.
>>
> 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 security architecture
>>> which can vary across SoCs.
>>
>> The latter. This is exactly the kind of pain I forsaw with this security
>> shite, and when I heard about it I was utterly dismayed at ARM Ltd for
>> coming up with such a brain-dead lack of design here.
>>
>> You're having to struggle with the results of that by having lots of
>> SoC specific hooks all around the place to fiddle with this that and the
>> other. Your need to have something called from the early assembly code
>> is just yet more of that disease caused by ARM Ltd's lack of forsight
>> on this matter.
>>
>> I have no solution for you on this
>
> I managed use some secure macro kind of code but as you said it
> will be really hard to maintain.
>
> So we are stuck with this issue then.
Can't we delay the L2 initialization a bit and do it when we have a
stack, like we do in OMAP4 (early_initcall)? Am I missing something?
br,
Aneesh
next prev parent reply other threads:[~2012-01-17 12:01 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <WC20120116100344.4204CC@terrafix.co.uk>
2012-01-16 10:18 ` OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)? Shilimkar, Santosh
2012-01-16 10:59 ` Russell King - ARM Linux
2012-01-16 12:43 ` Shilimkar, Santosh
2012-01-16 13:13 ` Russell King - ARM Linux
2012-01-16 13:22 ` Shilimkar, Santosh
2012-01-17 12:01 ` Aneesh V [this message]
[not found] ` <WC20120117085444.17057E@terrafix.co.uk>
2012-01-17 12:11 ` Catalin Marinas
2012-01-17 12:27 ` Aneesh V
2012-01-17 12:40 ` Shilimkar, Santosh
2012-01-17 13:39 ` Catalin Marinas
2012-01-17 13:58 ` Shilimkar, Santosh
2012-01-17 16:27 ` Catalin Marinas
2012-01-17 17:27 ` Shilimkar, Santosh
2012-01-17 19:39 ` Nicolas Pitre
2012-01-17 20:27 ` Shilimkar, Santosh
2012-01-17 20:45 ` Nicolas Pitre
2012-01-17 20:57 ` Nicolas Pitre
2012-01-17 20:58 ` Shilimkar, Santosh
2012-01-17 21:02 ` Nicolas Pitre
2012-01-18 8:43 ` Shilimkar, Santosh
2012-01-17 21:15 ` Russell King - ARM Linux
2012-01-17 19:47 ` Russell King - ARM Linux
2012-01-17 20:11 ` Shilimkar, Santosh
2012-01-17 20:48 ` Russell King - ARM Linux
2012-01-17 19:43 ` Russell King - ARM Linux
[not found] ` <WC20120120085711.330803@terrafix.co.uk>
2012-01-27 17:30 ` Catalin Marinas
2012-01-31 5:21 ` Aneesh V
2012-01-31 7:31 ` Catalin Marinas
2012-01-31 7:38 ` Shilimkar, Santosh
2012-01-31 8:54 ` Catalin Marinas
2012-01-31 9:05 ` Shilimkar, Santosh
2012-01-31 9:53 ` Catalin Marinas
2012-01-31 10:10 ` Russell King - ARM Linux
2012-01-31 12:10 ` Catalin Marinas
2012-01-31 18:09 ` Nicolas Pitre
2012-02-02 14:32 ` Catalin Marinas
2012-02-02 14:49 ` Russell King - ARM Linux
2012-02-02 15:10 ` Catalin Marinas
2012-01-31 9:56 ` Russell King - ARM Linux
2012-01-31 10:51 ` Shilimkar, Santosh
2012-01-31 18:27 ` Nicolas Pitre
2012-02-01 7:12 ` Shilimkar, Santosh
2012-01-17 14:18 ` Grazvydas Ignotas
2012-01-17 13:41 ` Catalin Marinas
2012-01-17 13:54 ` Aneesh V
2012-01-17 14:23 ` Måns Rullgård
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=4F156318.7030309@ti.com \
--to=aneesh@ti$(echo .)com \
--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