24.09.2019 20:54, Simon South пишет: > 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.
How do you take NetBSD image? > > 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 > > > _______________________________________________ > U-Boot mailing list > [email protected] > https://lists.denx.de/listinfo/u-boot > _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
