From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
Date: Thu, 2 Feb 2012 14:49:42 +0000 [thread overview]
Message-ID: <20120202144942.GD1275@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CAHkRjk690R951NUDC_erNsBtbmtrM-nPjY2gR=Tf-sW4qXX7ww@mail.gmail.com>
On Thu, Feb 02, 2012 at 02:32:03PM +0000, 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 the caches and MMU.
The only answer which assures complete system stability is for the
earliest reasonable point in the booting sequence to handle the errata,
before any of the potential errata scenarios occur. For things like
working around L2 cache problems, that means before the L2 cache is
enabled for the first time.
If the boot loader enables the L2 cache, then _it_ has to take care of
the errata before it enables the L2 cache, and not some blob that it
loads.
If the boot loader enables the cache, and there are workarounds for buggy
cache behaviour, then the boot loader has to implement those errata
itself.
And so the list goes on.
I think the one issue which Santosh is justified about is: if that is
the case, why have the errata workarounds in the kernel in the first
place. I agree - it makes no sense when we have things like the
decompressor enabling the caches.
So, I propose that we rip out all those work-arounds that are just
'set this bit in some register' at boot time from the kernel itself
right now, and reconsider how these are handled.
If that means boot loader people need to update their code to deal with
errata, because they want to use CPU features which have errata associated
with them, they then get to deal with the errata updates themselves, and
also have to carry the pain of dealing with running in non-secure mode.
Or, they will have to chose to avoid using those features.
But, having errata for things like DMB being faulty in the kernel after
things like the boot loader will _already_ have had to issue DMB
instructions, or for failing I-cache invalidate after we've already done
some I-cache invalidates (eg, boot loader or the decompressor) is quite
absurd.
So, I think we need to rip out a fair number of these errata from the
kernel itself; it's quite clear they're already being done far too late
in the system boot sequence.
next prev parent reply other threads:[~2012-02-02 14:49 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
[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 [this message]
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=20120202144942.GD1275@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).