mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Lucas Stach <l.stach@pengutronix.de>
To: Sascha Hauer <s.hauer@pengutronix.de>, Oleksij Rempel <fishor@gmx.net>
Cc: Barebox List <barebox@lists.infradead.org>
Subject: Re: [PATCH 5/6] ARM: i.MX: external NAND boot: Leave icache disabled
Date: Wed, 19 Feb 2020 12:53:56 +0100	[thread overview]
Message-ID: <ea522b8d2edc79a5354bc8234aea66519603cc55.camel@pengutronix.de> (raw)
In-Reply-To: <20200219082730.jwvsp3cdsoomdhwd@pengutronix.de>

On Mi, 2020-02-19 at 09:27 +0100, Sascha Hauer wrote:
> On Wed, Feb 19, 2020 at 07:23:09AM +0100, Oleksij Rempel wrote:
> > Am 18.02.20 um 16:37 schrieb Sascha Hauer:
> > > It seems running from the NFC SRAM doesn't work with the instruction
> > > cache enabled, it leads to corruptions on the i.MX27. We stumbled upon
> > > this earlier and the solution at that time was to disable the
> > > instruction cache in the NAND boot code. It is, however, more reliable
> > > to just not enable the instruction cache in the first place.
> > > This is not particularly nice as we have to ifdef this in generic code,
> > > duplicate arm_cpu_lowlevel_init(), or call arm_cpu_lowlevel_init() later
> > > when we are out of NFC SRAM. From the different bad solutions I chose
> > > to ifdef the instruction cache away. It will be enabled later in the
> > > common cache functions.
> > 
> > Hm... is it possible that we have similar speculation issues as on i.MX6UL? The CPU was speculating
> > in to IOMEM, caused cache poisoning/corruption and executed corrupted cache.
> 
> I don't know how much speculation an ARM9 processor does, but the end
> result looks very similar. via JTAG I can see that the memory matches
> my disassembly, just the CPU does something completely different.

Processors from this generation don't do much speculation at all. They
have a simple branch predictor, but wrong predictions are resolved via
a simple pipeline flush. I wouldn't expect a misspeculated instruction
to reach the load/store units on those simple cores.

It's much more likely that the I-cache simply issues AXI transactions
(most likely WRAP ones to implement critical word first) which the NAND
controller slave can't handle properly. In that case there is nothing
much we can do besides keeping the I$ disabled while we are running
from the NAND SRAM region.

Regards,
Lucas


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2020-02-19 11:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-18 15:37 [PATCH 0/6] i.MX: Fix external NAND boot Sascha Hauer
2020-02-18 15:37 ` [PATCH 1/6] ARM: i.MX Phytec phycard i.MX27: get fdt in common init function Sascha Hauer
2020-02-18 15:37 ` [PATCH 2/6] ARM: i.MX Phytec phycard i.MX27: replace __naked with noinline Sascha Hauer
2020-02-18 15:37 ` [PATCH 3/6] ARM: i.MX Phytec phycore " Sascha Hauer
2020-02-18 15:37 ` [PATCH 4/6] ARM: i.MX: external NAND boot: remove unnecessary arguments from imx*_nand_load_image Sascha Hauer
2020-02-18 15:37 ` [PATCH 5/6] ARM: i.MX: external NAND boot: Leave icache disabled Sascha Hauer
2020-02-19  6:23   ` Oleksij Rempel
2020-02-19  8:27     ` Sascha Hauer
2020-02-19 11:53       ` Lucas Stach [this message]
2020-02-18 15:37 ` [PATCH 6/6] ARM: i.MX: external NAND boot: Fix passing boarddata Sascha Hauer

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=ea522b8d2edc79a5354bc8234aea66519603cc55.camel@pengutronix.de \
    --to=l.stach@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=fishor@gmx.net \
    --cc=s.hauer@pengutronix.de \
    /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