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 <hdego...@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.html
> >
> > That'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
--
Best regards,
Siarhei Siamashka
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
