Hello,
This is a reply to an old thread http://lists.denx.de/pipermail/u-boot/2015-February/205761.html
On Sat, 21 Feb 2015 10:41:48 +0100 Hans de Goede hdegoede@redhat.com wrote:
On 20-02-15 19:33, Siarhei Siamashka wrote:
On Fri, 20 Feb 2015 15:11:04 +0100
The sun4i/sun5i/sun7i DRAM controller code in u-boot is ready for much faster DRAM clock speeds since the v2014.10 release. We are only missing the appropriate 'dram_para' settings for the boards, which can be prepared/verified according to the instructions from the linux-sunxi wiki. But there does not seem to be much interest in the performance and reliability for the sunxi boards yet. And participation of the hardware vendors (for doing large scale tests on many boards) is missing too.
Maybe now after the introduction of the Raspberry Pi 2, the Allwinner based devboard manufacturers might become a bit more interested in tweaking the performance in order to remain competitive.
I believe that every Cubietruck user had more than enough time to try my 'highspeedtruck' branches posted at
http://lists.denx.de/pipermail/u-boot/2014-July/183981.htmlThat's "the proof of the pudding", which demonstrates what is possible with this hardware :-)
I still believe that the only way to get anywhere wrt getting better DRAM speeds is to just make the change. As said before if you submit patches to increase DRAM speed on some boards I'll put them in my personal sunxi-wip and the official u-boot-sunxi/next asap,
Just to make it clear. I'm still not in favour of pushing potentially reliability degrading changes to any repository, where they can be picked up by unsuspecting users. And I'm going to be strict about it, so no compromise is possible. Sorry about this.
The users must be well aware of what they are trying, which tests to run and what kind of feedback is expected from them. Otherwise very few will notice anything even if they get unreliable DRAM setup. A good example is the unstable "1008MHz, 1.4V" CPU voltage/frequency configuration on the A10-Lime board. Only a small fraction of boards was affected, and the symptoms were not very obvious (it is not like the board fails to boot). And the users had to unnecessarily play the "guinea pig" role for a very long time.
As I said, the best possible scenario would be a participation of the board manufacturers (OLIMEX, CubieTech, LeMaker, ...). So that we could collect sufficient statistics from multiple board samples (preferably from different batches) and check whether we can select the settings, which work fine on all of them. But if there is no interested board manufacturer, then the only option is to ask users for help. Unfortunately the users are not always cooperative and disciplined. So it becomes a real hassle in practice.
We already got some interesting results though. For example, Adam Sampson tried to follow the guide from the linux-sunxi wiki and run my DRAM settings bruteforcing scripts on two pcDuino3 Nano boards. He also managed to reach 648MHz DRAM clock speed (though increasing MBUS to anything higher than 300MHz resulted in stability problems). It's surely good that we can potentially get into the 600MHz DRAM clock speed range on one more board model in addition to Cubietruck and A13-OLinuXino-Micro. But the most interesting part is that he had the results updated in real time on a web server as the scripts were progressing (now this link contains the final report): http://stuff.offog.org/tpr3.html
The Adam's work also demonstrated that the current scripts do not support efficient handling of multiple boards at one. The html report is a bit messy when there is more than one board. I could try to introduce some improvements in this area. And inspired by Adam's web server usage for real-time progress tracking, in fact it may be beneficial to move from the current NFS based setup to a server in the Internet, which could show statistics in realtime, implement a simple communication protocol and coordinate the DRAM settings bruteforcing process by issuing commands to the connected "slave" devices. Anyone who is interested in participating, would only need to use a special bootable SD card and just let the device out in the Internet...
However now I'm really disappointed in the whole idea of relying on anyone else, because this proved to be really inefficient. So I have bought 5 pcDuino V2 boards myself from http://www.exp-tech.de/pcduino-v2-linux-android-arduino-dev-board They are currently available at a discounted price 22.5 euro, which seemed to be a reasonably good deal for me :-)
I'm just going to take care of tuning the DRAM settings for pcDuino V2. But I'm not setting any deadline and will do it as time permits. And then we can see what happens. After I'm done experimenting with the DRAM settings, I will probably donate extra boards to other people.
And we still do have preliminary DRAM settings for Cubietruck, which had been tested on my Cubietruck board: http://linux-sunxi.org/User:Ssvb/Cubietruck_DRAM_Calibration But Cubietruck is relatively expensive and I can't afford to buy many boards. I only initially selected Cubietruck because this was the first sunxi board added to the mainline U-Boot. Also both Hans de Goede and Ian Campbell own Cubietruck boards, so there was a hope that they could help by running some simple quick tests. But as we can see, no progress can be realistically made on the Cubietruck front, so the only choice is to focus on pcDuino V2 for now.
Again, I'm not suggesting to use ~600MHz DRAM clock speed settings by default. They are just good for exploring the limits of hardware capabilities and demonstrate that the ZQ calibration and carefully selected delay settings improve reliability if done right. What is a reasonable default DRAM clock speed is yet to be decided though.
PS. Raspberry Pi supports DRAM overclocking up to 600MHz as an option, so it is not something really extraordinary.
and then we can ask people to test that, and once the merge window for v2015.07 opens we can land those changes and see from there.
How is it really different from my announcement of the Cubietruck test branch and the request to try it?
What would also be welcome is a wiki page for reading DRAM chip markings, so that people can figure out what their board should be able to handle theoretically (assuming the pcb is not holding things back).
All the DRAM chips appear to be at least DDR3-1333 in practice. There are also DRAM chip compatibility lists from Allwinner available on the Internet. We have not seen any exception from this pattern so far. And newer devices tend to use DDR3-1600 chips.
Moreover, reading the markings would not help anyone. Not every person would want to open their device. And not every person would be able to read and correctly interpret the markings, no matter how good is the documentation. Also unlike robots, humans tend to make silly mistakes occasionally :-)
It is much better to just run a quick DRAM reliability test as a part of the Linux distribution installation procedure [1]. Finding good DRAM settings is a difficult and slow process. But verifying them is relatively simple and fast (while also ensuring some safety headroom). In a way, it's very similar to passwords bruteforcing. Bruteforcing a password is difficult, slow and needs special tools. However it is trivially simple to verify whether a password is good.
[1] http://lists.denx.de/pipermail/u-boot/2015-January/202306.html