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

It would be best if you could compile U-Boot yourself and bisect this problem. You can check http://www.metaltoad.com/blog/beginners-guide-git-bisect-process-elimination or any other tutorial about using git bisect. Just using an older U-Boot release is only a workaround. This is unhealthy in the long run.

It is very old and all the development has moved to the mainline U-Boot since at least 2 years ago. The mainline U-Boot should work fine and I believe that this is what is used by Armbian already. MBUS should work at 400MHz too, I believe that this information is from Allwinner - https://irclog.whitequark.org/linux-sunxi/2013-11-06#5472690; Moreover, the A20 datasheet specifies some voltage limits and for VDD-DLL it is 1.4V Mainline is the only true U-Boot from http://git.denx.de/?p=u-boot.git;a=summary All the other U-Boot variants are forked versions with local patches. Did you have time to test anything?

Well, it was Allwinner who introduced their reference design, which relies on having a FEL button and doing firmware upgrade/recovery over the Micro-USB cable using their LiveSuit software. Many tablets and other devices are compatible with this reference design. And it looks like you and Zador are implementing your own open source alternative to LiveSuit. And of course, a few ugly ducklings or very specialized devices exist. They may need some special treatment.

The user interaction part is optional. We can easily tweak the code not to require any confirmation when there is only a single suitable choice available. For example, if the installer is only targeting Cubieboard1 / Cubieboard2 / Cubietruck, then there is just a single choice for the user (approve the installation or don't do it). As for the users doing a wrong choice, this is a universal problem and no better solution exists anyway. If you have multiple SD card images on the download page instead of a unified one, then the user still can download a wrong image and use it. The unified installer is in fact reducing the chance of a user error, because it does not allow the user to select Cubieboard2 when his/her SoC is detected as Allwinner A10 at runtime Moreover, the unified installer tries to provide instructions to the user at each step and explains how to make a correct choice. But this all is an ancient history Fast forward to the present days. Now I think that a proper solution is to have the exact board identification information available in the SPI flash or eMMC. There was some discussion about this in the Olimex blog: https://olimex.wordpress.com/2016/09/01/a64-olinuxino-emmc-rev-b-oshw-64-bit-arm-development-board-prototypes-are-testing/ And I suggested a patch for U-Boot to make the device model identification easy: https://patchwork.ozlabs.org/patch/629172/ It depends on the intended use of the device. If the user wants to run a desktop Linux system on the device, then we can expect a USB keyboard and a HDMI monitor to be normally available. You seem to be talking about the headless use case here. And it may (or even should?) have a different installer, or just the plain and boring board-specific SD card images. This seems to be a very specialized device. The users of such device are expected to know what they are doing.

It's not quite related to ARMbian build tools, but it is technically possible to have a generic bootable image / installer for all Allwinner devices. I had implemented a prototype a long time ago:http://linux-sunxi.org/SD_card_based_installer The sunxi-bootsetup demo only supports a set of A10/A10s/A20 boards, but in principle all the Allwinner chip generations can be covered (including H3). For example, you can try a simple helloworld binary, which can be written to the SD card instead of a bootloader (the source code is also available in github): wget https://github.com/linux-sunxi/sunxi-tools/raw/master/bin/uart0-helloworld-sdboot.sunxi dd if=uart0-helloworld-sdboot.sunxi of=/dev/sdX bs=1024 seek=8 Unfortunately none of the Linux distribution maintainers was interested in this feature back in 2014, probably it was way too unorthodox for them to accept. And of course, later the Raspberry Pi people have introduced an universal SD card image of their own, which can boot on all Raspberry Pi generations. Just because they probably do care about their users a little bit more

You can find some information about cpufreq governors here: https://linux-sunxi.org/Cpufreq Basically, the "ondemand" governor is way too slow to increase CPU clock speed. If you want to run a graphics desktop, then it feels rather laggy and unresponsive. Obviously, it was not fit for Android, and that's why Android people have implemented the "interactive" governor, which is admittedly also far from perfect, but at least it is nowhere as bad as "ondemand". The shortcomings of the "ondemand" governor have been known since a long time ago, but only now the "schedutil" governor is trying to implement it in a proper way.

But yes, the DCDC3 voltage seems to be correctly set to 1.30V, so the high MBUS clock speed should be OK. The culprit is probably the SK Hynix DRAM chips. I think that Cubieboard2 was initially developed and tested with the DRAM chips from GT. But the change to a different DRAM chips vendor now may require some different and more conservative settings. Please try to run lima-memtester with 432, 456 and 480 clock speeds for DRAM and find the last clock speed where the test passes and the first clock speed where it starts failing.

Are you sure about this? Which U-Boot repository are you using? If I build the mainline U-Boot for Cubieboard2 via git clone git://git.denx.de/u-boot.git cd u-boot make CROSS_COMPILE=arm-linux-gnueabihf- Cubieboard2_defconfig make CROSS_COMPILE=arm-linux-gnueabihf- -j8 Then the ".config" file contains CONFIG_DRAM_MBUS_CLK=300. And everyone else seems to have 300MHz MBUS clock speed, based on the logs posted here.

The mainline kernel with simplefb just uses the framebuffer passed over from the bootloader, but can't change its configuration. For the kernel is is just a memory buffer where one can write pixel data. The framebuffer setup is done in the U-boot bootloader. I believe that the framebuffer is initialized by U-Boot only when something is detected to be connected to HDMI and queried via EDID, but may be wrong.

I see that the MBUS clock speed is set to 400MHz instead of 300MHz. This should work fine, as long as the DCDC3 voltage is set to 1.30V instead of 1.25V You can check the DCDC3 voltage information in the dmesg log. And there was a patch for the 3.4 kernel to ensure that the kernel does not try to change the DCDC3 voltage, previously configured by the bootloader - https://github.com/linux-sunxi/linux-sunxi/commit/5052b83aa44dc16d6662d8d9d936166c139ad8c5 Please note that the mainline U-Boot currently uses 300MHz MBUS clock speed for Cubieboard2 / Cubietruck. There were so many broken 3.4 kernel forks that it was better be safe than sorry Regarding the DRAM performance with different DRAM / MBUS clock speeds, some information can be found here: https://linux-sunxi.org/A10_DRAM_Controller_Performance