From: Alexey.Brodkin@synopsys.com (Alexey Brodkin)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH] arc: Flush and invalidate caches on start
Date: Thu, 31 Aug 2017 16:34:29 +0000 [thread overview]
Message-ID: <1504197268.3799.8.camel@synopsys.com> (raw)
In-Reply-To: <7a5267e3-c012-7bfd-ced2-cfaa3f47524a@synopsys.com>
Hi Vineet,
On Thu, 2017-08-31@09:31 -0700, Vineet Gupta wrote:
> On 08/31/2017 07:22 AM, Alexey Brodkin wrote:
> >
> > This is useful to make sure no stale data exists in caches after bootloaders.
> > The worst thing could be some lines of cache were locked in a bootloader
> > for example during DDR recalibration and never unlocked. This may lead
> > to really unpredictable issues later down the line.
> >
> > Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
> > ---
> > ? arch/arc/kernel/head.S | 16 ++++++++++++++++
> > ? 1 file changed, 16 insertions(+)
> >
> > diff --git a/arch/arc/kernel/head.S b/arch/arc/kernel/head.S
> > index 8b90d25a15cc..04e28b664183 100644
> > --- a/arch/arc/kernel/head.S
> > +++ b/arch/arc/kernel/head.S
> > @@ -34,6 +34,10 @@
> > ? #endif
> > ?? sr r5, [ARC_REG_IC_CTRL]
> > ??
> > + ; Invalidate entire I$
> > + mov r5, 1
> > + sr r5, [ARC_REG_IC_IVIC]
> > +
> > ? 1:
> > ?? lr r5, [ARC_REG_DC_BCR]
> > ?? breq????r5, 0, 1f ; D$ doesn't exist
> > @@ -46,6 +50,18 @@
> > ? #endif
> > ?? sr r5, [ARC_REG_DC_CTRL]
> > ??
> > + ; Flush entire D$
> > + mov r5, 1
> > + sr r5, [ARC_REG_DC_FLSH]
> > + ; Wait for flush operation to complete
> > +1:
> > + lr r5, [ARC_REG_DC_CTRL]
> > + bbit1 r5, DC_CTRL_FLUSH_STATUS, 1b
> > +
> > + ; Invalidate entire D$
> > + mov r5, 1
> > + sr r5, [ARC_REG_DC_IVDC]
> > +
>
> AFAIK uboot already flushes the caches before handing control over to kernel - so?
> why do we need it here.
> If uboot is locking lines, it needs to fix that and not penalize the general case?
> with or w/o uboot !
U-Boot indeed flushes caches.. but doesn't invalidate them!
And only invalidation unlocks locked lines.
That indeed should be added in U-Boot but I'd say above stuff doesn't
influence a lot code size or execution time while makes system more fool-proof.
-Alexey
WARNING: multiple messages have this Message-ID (diff)
From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
To: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>
Subject: Re: [PATCH] arc: Flush and invalidate caches on start
Date: Thu, 31 Aug 2017 16:34:29 +0000 [thread overview]
Message-ID: <1504197268.3799.8.camel@synopsys.com> (raw)
In-Reply-To: <7a5267e3-c012-7bfd-ced2-cfaa3f47524a@synopsys.com>
Hi Vineet,
On Thu, 2017-08-31 at 09:31 -0700, Vineet Gupta wrote:
> On 08/31/2017 07:22 AM, Alexey Brodkin wrote:
> >
> > This is useful to make sure no stale data exists in caches after bootloaders.
> > The worst thing could be some lines of cache were locked in a bootloader
> > for example during DDR recalibration and never unlocked. This may lead
> > to really unpredictable issues later down the line.
> >
> > Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
> > ---
> > arch/arc/kernel/head.S | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/arch/arc/kernel/head.S b/arch/arc/kernel/head.S
> > index 8b90d25a15cc..04e28b664183 100644
> > --- a/arch/arc/kernel/head.S
> > +++ b/arch/arc/kernel/head.S
> > @@ -34,6 +34,10 @@
> > #endif
> > sr r5, [ARC_REG_IC_CTRL]
> >
> > + ; Invalidate entire I$
> > + mov r5, 1
> > + sr r5, [ARC_REG_IC_IVIC]
> > +
> > 1:
> > lr r5, [ARC_REG_DC_BCR]
> > breq r5, 0, 1f ; D$ doesn't exist
> > @@ -46,6 +50,18 @@
> > #endif
> > sr r5, [ARC_REG_DC_CTRL]
> >
> > + ; Flush entire D$
> > + mov r5, 1
> > + sr r5, [ARC_REG_DC_FLSH]
> > + ; Wait for flush operation to complete
> > +1:
> > + lr r5, [ARC_REG_DC_CTRL]
> > + bbit1 r5, DC_CTRL_FLUSH_STATUS, 1b
> > +
> > + ; Invalidate entire D$
> > + mov r5, 1
> > + sr r5, [ARC_REG_DC_IVDC]
> > +
>
> AFAIK uboot already flushes the caches before handing control over to kernel - so
> why do we need it here.
> If uboot is locking lines, it needs to fix that and not penalize the general case
> with or w/o uboot !
U-Boot indeed flushes caches.. but doesn't invalidate them!
And only invalidation unlocks locked lines.
That indeed should be added in U-Boot but I'd say above stuff doesn't
influence a lot code size or execution time while makes system more fool-proof.
-Alexey
next prev parent reply other threads:[~2017-08-31 16:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-31 14:21 [PATCH] arc: Flush and invalidate caches on start Alexey Brodkin
2017-08-31 14:21 ` Alexey Brodkin
2017-08-31 16:31 ` Vineet Gupta
2017-08-31 16:31 ` Vineet Gupta
2017-08-31 16:34 ` Alexey Brodkin [this message]
2017-08-31 16:34 ` Alexey Brodkin
2017-11-15 15:26 ` Alexey Brodkin
2017-11-15 15:26 ` Alexey Brodkin
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=1504197268.3799.8.camel@synopsys.com \
--to=alexey.brodkin@synopsys.com \
--cc=linux-snps-arc@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.