public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] sunxi: mctl_mem_matches: Add missing memory barrier
Date: Fri, 22 Apr 2016 12:48:31 +0200	[thread overview]
Message-ID: <571A017F.5080002@redhat.com> (raw)
In-Reply-To: <1461317533.24107.22.camel@hellion.org.uk>

Hi,

On 22-04-16 11:32, Ian Campbell wrote:
> On Fri, 2016-04-15 at 09:34 +0200, Hans de Goede wrote:
>>> I wonder if what you are observing could be possibly explained by just
>>> a usual data corruption problem? Which may be happening when the DRAM
>>> clock speed is set higher than this particular device is able to handle
>>> in a reliable way. Inserting just one or more NOP instructions instead
>>> of the barrier could possibly change some timings too.
>>>
>>> If this patch helps, then it's fine. But I wonder if it is not merely
>>> making the problem latent instead of fixing the root cause?
>> I do believe that this patch addresses a real problem and is not hiding
>> some dram timing issues, I might be wrong about the write-buffer being
>> the cause, it could simply be that the compiler is doing something bad
>> (despite the accesses being marked as volatile)  and that the DSB stops
>> the compiler from optimizing things too much.
>
> I have a _very_ vague memory of seeing something not disimilar to this
> (apparent write buffer interactions with MMU disabled) in the early
> days of Xen development, but that was probably on models and so may not
> have been representative of the intended behaviour of eventual silicon.
>
> It might be interesting to have a look at the generated assembly and
> see if it differs in more or less than the addition of the single
> instruction and perhaps experiment with just a compiler barrier.
>
> Andre, do you have any insights on this?

Andre here is the original mail/patch for reference:

     sunxi: mctl_mem_matches: Add missing memory barrier

     We are running with the caches disabled when mctl_mem_matches gets called,
     but the cpu's write buffer is still there and can still get in the way,
     add a memory barrier to fix this.

     This avoids mctl_mem_matches always returning false in some cases, which
     was resulting in:

<snip>

@@ -31,6 +32,7 @@ bool mctl_mem_matches(u32 offset)
  	/* Try to write different values to RAM at two addresses */
  	writel(0, CONFIG_SYS_SDRAM_BASE);
  	writel(0xaa55aa55, (ulong)CONFIG_SYS_SDRAM_BASE + offset);
+	DSB;
  	/* Check if the same value is actually observed when reading back */
  	return readl(CONFIG_SYS_SDRAM_BASE) ==
  	       readl((ulong)CONFIG_SYS_SDRAM_BASE + offset);


What this code is trying to do is determine RAM (chip) size by seeing when
writing to RAM wrapsaround.

This works with the DSB but not without (without it always returns false)
this is on a Cortex A7 with the mmu (and data caches) disabled.

Ian, I can try using just a compiler barrier, but I've never done so
before, how do I insert one ?

Regards,

Hans

  reply	other threads:[~2016-04-22 10:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-14 16:58 [U-Boot] [PATCH] sunxi: mctl_mem_matches: Add missing memory barrier Hans de Goede
2016-04-15  0:46 ` Siarhei Siamashka
2016-04-15  7:34   ` Hans de Goede
2016-04-22  9:32     ` Ian Campbell
2016-04-22 10:48       ` Hans de Goede [this message]
2016-04-22 11:46         ` Andre Przywara
2016-04-22 12:09           ` Hans de Goede
2016-04-22 13:12             ` Andre Przywara
2016-04-22 13:20               ` Ian Campbell

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=571A017F.5080002@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=u-boot@lists.denx.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