On 2019-09-24 12:54 p.m., Matwey V. Kornilov wrote:
Simon, maybe you'll describe a way to obtain SD card image which you
use? For the case if anybody wants to reproduce the issue in situ?
Sure---I'd love for other people to test this, and it's pretty easy
since it doesn't require anything other than U-Boot itself.
Assuming the CROSS_COMPILE and BL31 environment variables are set up
appropriately (I'm using ATF 2.1 from the mainline repository):
1. Switch to U-Boot's master branch and/or configure the source tree
identically to my own with
git checkout a9fa70b7b7167487affc5d919e541872c99e814b
2. Apply the attached patch, which enables the "mtest" command, with
patch -p1 < rock64-enable-mtest.patch
3. Build U-Boot as usual:
make distclean; rm -f ./idbloader.img
make rock64-rk3328_defconfig all u-boot.itb
4. Write U-Boot to a microSD card as usual:
sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64
sudo dd if=u-boot.itb of=/dev/mmcblk0 seek=16384
5. Place the microSD card in the ROCK64 and start it. Once the SPL
loads, hit the spacebar to enter the shell and start the memory test with
mtest
On my ROCK64, this immediately begins throwing off errors like
FAILURE (read/write) @ 0x020014c0: expected 0x00000299, actual
0x00000219)
and if I continue the boot process with "boot", the NetBSD kernel will
load but panic almost immediately.
Note mine is a ROCK64 v2.0 with a 32Gb SpecTek LPDDR3 memory
module---there is also a ROCK64 v3.0 and some variance in the memory
chips used, so it could be this is limited to a specific model or
production run.
Now here's what I've discovered lately:
Everything works normally if I have U-Boot TPL's set a slightly lower
clock rate for the memory, by editing
arch/arm/dts/rk3328-sdram-lpddr3-1600.dtsi and changing the "800" on
line 27 to "766".
That suggests a hardware issue with my ROCK64, and in fact others have
reported similar problems with the 2.0 version [1]. I'd be willing to
leave it at that, except that if I also patch the (333MHz) Rockchip TPL
to set a _higher_ clock rate for the memory, it continues to work just
fine---all the way up to 933MHz!
So this is not just a hardware problem; there is some incompatibility
between the RK3328 SDRAM driver as it exists in U-Boot and at least one
group of ROCK64s in the world.
At the moment I'm still trying to identify what's different in the
closed-source loader that causes it not to have this issue. Anyone have
any thoughts?
[1] https://forum.pine64.org/showthread.php?tid=7387
--
Simon South
[email protected]
diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig
index 3ab0af1158..90061498c9 100644
--- a/configs/rock64-rk3328_defconfig
+++ b/configs/rock64-rk3328_defconfig
@@ -28,6 +28,8 @@ CONFIG_SPL_ATF=y
CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
CONFIG_CMD_BOOTZ=y
CONFIG_CMD_GPT=y
+CONFIG_CMD_MEMTEST=y
+CONFIG_SYS_ALT_MEMTEST=y
CONFIG_CMD_MMC=y
CONFIG_CMD_SF=y
CONFIG_CMD_USB=y
diff --git a/include/configs/rk3328_common.h b/include/configs/rk3328_common.h
index 3ff3331c80..3c09fd94b9 100644
--- a/include/configs/rk3328_common.h
+++ b/include/configs/rk3328_common.h
@@ -29,6 +29,9 @@
#define CONFIG_SYS_SDRAM_BASE 0
#define SDRAM_MAX_SIZE 0xff000000
+#define CONFIG_SYS_MEMTEST_START 0x02000000
+#define CONFIG_SYS_MEMTEST_END 0x03ffffff
+
#ifndef CONFIG_SPL_BUILD
#define ENV_MEM_LAYOUT_SETTINGS \
_______________________________________________
U-Boot mailing list
[email protected]
https://lists.denx.de/listinfo/u-boot
