Hardware Reliability Tests

The importance of the hardware diagnostic tools
Because of the diversity of various Allwinner based devices we have to deal with different DRAM, CPU clock speed and voltage settings. They are primarily derived from the fex files found in the vendor provided firmware on NAND and also based on the information retrieved by the a10-meminfo tool. Some dishonest sellers also happily advertise way higher specs than the hardware can actually handle (for example, unrealistic 1.5GHz CPU clock speeds). Moreover, different chips have their own individual voltage and clock frequency tolerances within a certain range. So that the borderline stable settings may be good for one unit and bad for another.

In order to quickly identify obviously misconfigured hardware, we need some easy to use diagnostic tools. There is no magic involved. The general idea behind them is to find some real life or synthetic workloads, which are more likely to cause troubles. Then identify, which parts of these workloads are most problematic and convert them into (hopefully) user friendly test tools. Some of these tools are listed below.

Note: naturally, the majority of devices are expected to pass these tests and you are likely not to get any exciting results. Still this is not a good justification for the "nah, this may happen to anyone, but me" attitude. The experience shows that there are definitely faulty/misconfigured devices out there. If you are experiencing occasional crashes or freezes once in a while, then making sure that these tests pass is strongly recommended before trying anything else.

DRAM
The lima-memtester tool can be used to check if the dram settings are reasonable and dcdc3 voltage is sufficient. If you have a shell access to your device and development tools installed there, then you can download and compile the lima-memtester on the device itself using: git clone https://github.com/ssvb/lima-memtester.git cd lima-memtester ./build-lima-memtester-static-binary.sh

Now you should have the lima-memtester static binary. Running it only requires the sunxi-3.4 kernel with the mali kernel module and framebuffer enabled. This test does not depend on anything in the userland and should work with any Linux distribution (this also means that it does NOT require the userland Mali binary driver). Just run lima-memtester with root privileges as: ./lima-memtester 100M

If everything is working fine, you should see a spinning cube demo running indefinitely. If something is very wrong, then the test fails after just a few seconds! If something is mildly wrong, this usually gets detected in less than 15-20 minutes. In the case of troubles, you may observe the following symptoms:
 * the system freezes
 * the display background starts glowing red (normally it is gray)

For even more confidence, it is a good idea to keep it running overnight (8-10 hours) at least once.

CPU
If the CPU is overclocked or undervolted, then it may be unreliable. If the CPU is overclocked and overvolted, then it may overheat and also fail.

To check for the CPU overheating, it is possible to use the cpuburn tool. To run this test on the Allwinner A10 hardware: git clone https://github.com/ssvb/cpuburn-arm.git cd cpuburn-arm gcc -o cpuburn-a8 cpuburn-a8.S ./cpuburn-a8 Or on the Allwinner A20 hardware: git clone https://github.com/ssvb/cpuburn-arm.git cd cpuburn-arm gcc -o cpuburn-a7 cpuburn-a7.S ./cpuburn-a7

The cpuburn programs are only heating the CPU and are not providing any visible feedback. It may make sense to also run some other non CPU hungry program simultaneously to monitor whether it is still alive or not. Running some Mali400 graphical demo is the best for this purpose. And the GPU is also providing an extra source of heat.

WARNING: if the device is recklessly overclocked/overvolted too much, then some permanent hardware damage may theoretically happen.