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