ssvb

For the ZQ settings to have a meaningful effect, ODT needs to be enabled. This can be enabled by adding CONFIG_DRAM_ODT_EN=y to the U-Boot defconfig. Also at least for the boards with GT DRAM chips, these settings can result in a much improved reliability and higher DRAM clock speed ceiling: https://linux-sunxi.org/User:Ssvb/Cubietruck_DRAM_Calibration Basically, you could try the following: CONFIG_DRAM_TIMINGS_DDR3_1066F_1333H=y CONFIG_DRAM_EMR1=66 CONFIG_DRAM_ZQ=17643776 CONFIG_DRAM_ODT_EN=y CONFIG_DRAM_TPR3=528657 I'm not sure if these settings are also good for SKHynix but somebody could give them a try too. CONFIG_DRAM_DQS_GATING_DELAY option may be also added if necessary.

First, it looks like the calibrated ZQ value is the same in all tests (reported as 0x5294a00). We can try to force dqs_gating_delay to 0x06060606 instead of autodetection and check if this improves anything. This can be done via the CONFIG_DRAM_DQS_GATING_DELAY option in U-boot defconfig, see http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/Kconfig;h=e1d4ab148f0838d746889775cfbab5bed57838bf;hb=a705ebc81b7f91bbd0ef7c634284208342901149#l196 Also it may be a very good idea to add CONFIG_DRAM_TIMINGS_DDR3_800E_1066G_1333J=y or CONFIG_DRAM_TIMINGS_DDR3_1066F_1333H=y to the defconfig too.

Freezes are more connected to DCDC3 voltage because if it is high enough, then the freezes usually disappear and you only have to deal with just data corruption alone. There is one more trick. DRAM configuration is not deterministic because ZQ calibration is run at the initialization time. You can get the current results of ZQ calibration and a lot of other settings by running the a10-meminfo tool from https://github.com/ssvb/a10-dram-tools This may explain why sometimes you have a reliable board and sometimes it fails. ZQ calibration usually differs between cold start and warm reboot. It is also possible to bypass the ZQ calibration step and hardcode ZQ settings directly via the CONFIG_DRAM_ZQ parameter. This way the DRAM controller configuration will become deterministic. Some extra information can be found at https://linux-sunxi.org/User:Ssvb/pcDuino2_with_HYNIX_DDR3_reliability_test

Freezes and memory corruption errors are very likely two different types of problems (and both are bad). If DCDC3 voltage is insufficient, then we get freezes. If the clock speed is too high (or too low), then we get memory corruption errors. Yes, the clock speed also affects freezes to a smaller extent.

You can set CONFIG_AXP_DCDC3_VOLT=1300 in the configs/Cubietruck_defconfig file before compiling U-Boot.

Freezing is not a very good symptom. Normally one would see data corruption getting reported by lima-memtester (and a glowing red background with the cube spinning animation). You could also try to increase DCDC3 voltage (from 1.25V to 1.30V) and check if this helps to improve reliability.

Since we are testing the DRAM settings in U-Boot, the choice of kernel does not really matter. For the sake of convenience, the Orange Pi PC testing had been done via a special FEL boot package: https://github.com/ssvb/lima-memtester/releases/tag/20151207-orange-pi-pc-fel-test I can easily prepare something like this for the Cubietruck too.

@tpm8 - Yes, reducing the DRAM clock speed too much can also cause problems if the DRAM chips in question had been designed for very high clock speeds (DDR3-1600). Moreover, the default ZQ settings are very non-optimal for the Cubietruck board and it is possible to clock even to 600 MHz with DRAM chips from GT and tuned ZQ settings, while the defaults have relatively bad reliability - http://lists.denx.de/pipermail/u-boot/2014-July/183981.html @apollon77 - If I understand it correctly, you have never used the lima-memtester stress test, which is specifically designed to quickly identify DRAM problems/misconfigurations. You might want to give it a try, especially considering that you have a nice set of 4 boards.

OK, lower DRAM clock frequency can explain why stability problems disappeared. Why was it lowered in armbian in the first place? Was it there to address reliability problems? If yes, then why hasn't it been reported to mainline yet? In order to figure out what is going on, I think that we need to have some test results similar to https://linux-sunxi.org/Orange_Pi_PC#DRAM_clock_speed_limit Done separately for different brands of DRAM chips (GT vs. HYNIX). Edit: Various reports in this discussion thread are very confusing and contradict each other. For example, tpm8 mentioned that the mainline U-Boot was stable with the 432MHz DRAM clock speed, while armbian was not. Please get your act together.

Yes, these boards are designed to be unbrickable. They can either boot from the SD card (there is a special sd card bootable image in sunxi-tools, which activates FEL mode), or have a dedicated FEL button. The CPU is running at a really low clock speed in FEL mode (something like 384MHz?) and never uses more than one core. The current draw is much lower than 500mA. Idle FEL mode only shows ~80mA on my board. Unfortunately SPI NOR flash is not populated on my OpiZero board, but you can try to measure the current draw while flashing via sunxi-fel and report the results here. Yeah, but you first need to boot the board from the SD card to use flashrom, so pick your poison As for the Windows version of sunxi-tools, you can try http://linux-sunxi.org/FEL/USBBoot#Using_sunxi-fel_on_Windows and provide some feedback.

H5 is still not supported in U-Boot, that's why it is WIP. The required changes are trivial though. The sunxi-fel tool (from my branch) has full H5 support. It is not merged to the upstream sunxi-tools because some code cleanups are necessary (in fact they are already done). And also it would be best to have a high level firmware upgrade functionality implemented rather than just raw read/write support. If this is inconvenient for you, then just let me know. In fact, I have added the basic flashrom information to the wiki page in order to discourage everyone from using it. How did it end up having the opposite effect?

Of course it works. And was working fine since the very beginning. You can find the detailed step by step instructions here: https://linux-sunxi.org/Bootable_SPI_flash#Using_the_sunxi-fel_tool Please note that the flashrom method is not very foolproof. The sunxi-fel tool may provide some nice high level features in the future. Such as the installed bootloader identification, extra checks if the old and new u-boot configurations are compatible, SPI speed tuning for faster boot (right now it is working at 6MHz in U-Boot) and maybe even larger SPL sizes via an additional loader stub. Not to mention that U-Boot may enforce write-protection for itself before passing control to the linux kernel (write-protection is enforced until the next power-down/power-up cycle), and in this case the flashrom tool will become completely useless.

Keep in mind that different units may have slightly different tolerances and overclocking potential even if it's the same board model. For example, have a look at https://linux-sunxi.org/Orange_Pi_PC#DRAM_clock_speed_limit Some Orange Pi PC boards pass the lima-memtester test with DRAM clocked at 720 MHz, while the others fail it at 672 MHz. The same is very likely true for the Cubietruck. Also ""Works stable" means a minimum complete run of lima-memtester and cpufreq-ljt-stress-test (cpuburn-arm)" is not good enough. Ideally we want at least a bit of extra safety headroom. Which means that you should stress test the board at slightly higher settings than intended to be used in production. Still if you have some differences depending on the U-Boot version, then we need to investigate this too. Ideally we need to identify the exact problematic commit (via git bisecting).

Just try to find the exact commit which introduced the problem, and we will know more.

You can't get this information in a software way. Just check the markings on the four DRAM chips on the board. For example, the original https://linux-sunxi.org/Cubietruck used GT8UB512M8EN-BG chips and you can find them on the pictures. It is necessary to recompile U-Boot for this after changing the DRAM clock speed settings in the 'configs/Cubietruck_defconfig' file. You can find some instructions here: https://linux-sunxi.org/Mainline_U-Boot#Compile_U-Boot