Testers wanted: Testing DRAM reliability on BPi M2+ and NanoPI M1

slinde · June 12, 2016

I did another test over night with 624MHz. It pretty much looks the same.

Eng-Shien Wu · June 12, 2016

Beelink X2 running "lima-memtester 100M" and the setting "dram_clk = 648". Grey background entire time, but only running 1 core at end--it is possible that I messed up the heatsink when I opened it up to solder serial out.

Tido · June 13, 2016

red LED on

Power Supply 5,16 Volt (measured on the PCB)

here are my results in the picture:

Finally I have received an answer:

it is right, its limit from 1.1V to 1.4V, we set it to 1.3V.

hojnikb · June 13, 2016

@tkaiser

Any word on the testing tool you mentioned in cnx ?

http://www.cnx-software.com/2016/06/09/orange-pi-pc-plus-quad-core-development-board-with-1gb-ram-8gb-emmc-flash-sells-for-20/#comment-527601

tkaiser · June 13, 2016

Any word on the testing tool you mentioned in cnx ?

http://www.cnx-software.com/2016/06/09/orange-pi-pc-plus-quad-core-development-board-with-1gb-ram-8gb-emmc-flash-sells-for-20/#comment-527601

I already wasted a bit too much time with it. The idea is to use the here referenced optimized Linpack version to reliably detect undervoltage situations. And then setup an automated test that runs through all reasonable dvfs operating points, exchanges settings in fex file, reboots, tests again.

The problem is that one needs a way to heat up the SoC before Linpack is running. I tried that with cpuburn-a7 (180 seconds are enough) but that's too heavy since then in undervoltage situation the board already locks up. There is some watchdog code that might be able to restart then but I want to avoid that. So I'm still experimenting (maybe relying on cpuminer to produce heat).

The tool itself will be rather primitive. The time consuming parts are to ensure that it

is able to run unattended without locking up the board
produces valid results

And now the most important part: This whole tuning isn't that important if it's about real world performance (depends more on settings than on clockspeeds). The only people able to benefit from are the ones who want to run heavy stuff on their boards (encoding video for example). They might be able to finish tasks in 20 percent less time with optimised dvfs operating points and fine grained throttling steps that match their thermal situation (that might be pretty different when comparing an SBC in a small enclosure without heatsink and one with a large heatsink attached with much airflow around)

tkaiser · August 25, 2016

Back to DRAM reliability testing. Jemk provided an u-boot patch that might help with reliability on boards failing at 672 MHz or above. In case you have such a device (any H3 device, it really doesn't matter which one) that failed at 648 MHz or above please try again with the patch applied.

Please read through

post #4 of this thread (there's a link to an OS image to test with and instructions how to install different u-boot versions)
https://groups.google.com/forum/#!topic/linux-sunxi/OZe9uFuT8Io%5B1-25%5D (there is description and a new archive)

You can simply re-use the image from back then for BPi M2+, connect your H3 device to display and keyboard/mouse, exchange then script.bin if you're not running on a Banana Pi M2+ and can then test through different DRAM clockspeeds set in u-boot. So in case you try this out on an Orange Pi PC all that's needed is starting the aforementioned Armbian 5.14 image and then as root

cd /boot && ln -sf bin/orangepipc.bin script.bin && reboot

Please be aware that lima-memtester currently does not work on H3 devices with more than 1 GB DRAM (so no testing possible on Plus 2/2E). In case you own such a board monitoring this issue might be an idea and if the problem is resolved replacing lima-memtester with the fixed version is the way to go.