From: Siarhei Siamashka <siarhei.siamashka@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] configs: Lower Lamobo R1 DRAM clock rate to 384 MHz
Date: Mon, 18 Jun 2018 15:37:36 +0300 [thread overview]
Message-ID: <20180618153736.67df1e76@i7> (raw)
In-Reply-To: <20180615205239.11868-1-contact@paulk.fr>
On Fri, 15 Jun 2018 22:52:39 +0200
Paul Kocialkowski <contact@paulk.fr> wrote:
> When running at 432 MHz, the Lamobo R1 DRAM tends to get corrupted under
> stressing workloads.
Yes, it is well known that Allwinner devboards tend to have overclocked
settings out of the box and poor reliability track record because each
board vendor is trying to clock this low end hardware as high as
possible in order to look more "competitive". You can find more
information about this problem here:
https://linux-sunxi.org/Hardware_Reliability_Tests
> Reducing the clock rate to 384 MHz results in significantly-improved stability.
It would be great if we could get the reliability problems completely
resolved on this board rather than just improved.
> One reliable way to trigger a corruption at 432 MHz is to run
> I/O-intensive operations on an attached SATA disk. The same operations
> when operating the DRAM at 384 MHz typically go fine.
Yes, concurrent access to the DRAM controller from more than one
peripheral exposes reliability problems. That's why we have the
lima-memtester tool at least for A10/A20 hardware, which does a
stress test for DRAM reliability by using CPU+Mali simultaneously:
https://github.com/ssvb/lima-memtester/
I also did some experiments with CPU+Mali+G2D (simultaneous access from
3 sources) and CPU+G2D (use G2D instead of Mali) and the highest
reliable DRAM clock speeds under these workloads were pretty much the
same. So I suspect that CPU+SATA is about as stressful as any other
combination. And you can probably just run a regular memtester
tool together with some SATA activity in the background (I'm
assuming that you did just that when debugging this problem).
Still I would suggest you to try the lima-memtester tool too. It
requires a legacy 3.4 kernel. If you are really lazy, then you can
even try this kernel branch from my github repository:
https://github.com/ssvb/linux-sunxi/tree/20151206-embedded-lima-memtester
The embedded initramfs automatically starts lima-memtester, so you only
need to boot this kernel image and watch the serial console log. The
only other thing is a proper script.bin file for your board (created
from a fex file).
If you are interested in a more advanced stuff (finding better DRAM
settings rather than just downclocking DRAM until it stops failing),
then you may want to check this wiki page:
https://linux-sunxi.org/A10_DRAM_Controller_Calibration
For example, I had to downclock DRAM from 408MHz to 360MHz in the
Linksprite_pcDuino_defconfig in the past, you can find a detailed
analysis in the commit log:
https://lists.denx.de/pipermail/u-boot/2015-October/229567.html
> For some unexplained reason, running at 408 MHz worsens the situation.
>
> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> ---
> configs/Lamobo_R1_defconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configs/Lamobo_R1_defconfig b/configs/Lamobo_R1_defconfig
> index 92e682128c..cf60fdfaf4 100644
> --- a/configs/Lamobo_R1_defconfig
> +++ b/configs/Lamobo_R1_defconfig
> @@ -2,7 +2,7 @@ CONFIG_ARM=y
> CONFIG_ARCH_SUNXI=y
> CONFIG_SYS_TEXT_BASE=0x4a000000
> CONFIG_MACH_SUN7I=y
> -CONFIG_DRAM_CLK=432
> +CONFIG_DRAM_CLK=384
> CONFIG_MACPWR="PH23"
> CONFIG_MMC0_CD_PIN="PH10"
> CONFIG_SATAPWR="PB3"
--
Best regards,
Siarhei Siamashka
prev parent reply other threads:[~2018-06-18 12:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-15 20:52 [U-Boot] [PATCH] configs: Lower Lamobo R1 DRAM clock rate to 384 MHz Paul Kocialkowski
2018-06-18 7:59 ` Maxime Ripard
2018-06-18 9:26 ` Paul Kocialkowski
2018-06-18 12:37 ` Siarhei Siamashka [this message]
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=20180618153736.67df1e76@i7 \
--to=siarhei.siamashka@gmail.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