On Fri, 21 Mar 2014 04:27:19 -0700 (PDT)
[email protected] wrote:
> Am Freitag, 21. März 2014 11:16:04 UTC+1 schrieb Hans de Goede:
> > any objections to me merging this during one of the coming days ?
>
> There was a discussion with Huang Benn who is a member of Cubieboard.
> https://groups.google.com/forum/#!topic/linux-sunxi/rhOUJXJu0Jg
>
> 384 MHz seems to be quit conservative. Huang suggests 432 MHz.
When I originally submitted this Cubieboard2 dram clock reduction
patch for u-boot, I had a hope that it's only going to be a temporary
solution. And that the hardware manufacturers (CubieTech in this case)
will step in and help us to find the best settings for their hardware
which are also 100% reliable on non-defective units.
But appears that this is not going to fly. CubieTech is providing
their own SD card images with their own tweaks, which differ from
https://github.com/linux-sunxi/sunxi-boards
OLIMEX is also providing their own SD card images and compilation
instructions, relying on their own extra patches and custom
fex files. Moreover, there is also an active community providing a
variety of their own customized images at http://www.cubieforums.com/
(with different tweaks, and also overclocking in some cases). We
just can't stop the creativity of all these people :-)
Anyway, what we have now is that the default Cubieboard2 dram settings
at https://github.com/linux-sunxi/sunxi-boards do not work reliable
out of the box for some small fraction of users. I am *not* one of
them. My Cubietruck works fine with dram clocked at 432MHz and my
Cubieboard2 works fine with 480MHz dram, even with a bit of
overclocking headroom. And to move forward, we need ACKs from the
real users of the problematic hardware. Only they can tell us, which
dram clock speed is good for their devices. But finding a stable
hardware configuration is easier said than done.
And the only half-decent manageable solution is IMHO the introduction
of diagnostic tools, which could be useful for identifying defective
or misconfigured hardware. I hope that we can start with
https://github.com/ssvb/lima-memtester/
and evolve it into a more complete stress test suite for the sunxi
hardware (add cpuburn functionality, temperature monitoring and other
bells and whistles). Also trying to make it extremely simple and
intuitive to use. With the goal to eventually enforce something like
the following policy: if you have not run the diagnostic stress
test tool, then you have no right to complain about the supposedly
*software* problems that you think you have on your sunxi device.
As for the 480MHz dram clock on Cubieboard2, we are currently verifying
if it is just dcdc3 voltage that makes a certain small fraction of
Cubieboard2 devices unstable:
http://irclog.whitequark.org/linux-sunxi/2014-04-04#7013744;
Cubieboard1 and Cubieboard2 are both using exactly the same PCB.
And also Cubieboard1 is known to be 100% reliable with 480MHz dram
clock speed (at least there were no reports about any problems).
This means that the problem is likely in the A20 SoC or its
misconfiguration. And dcdc3 voltage looks like a very likely culprit,
taking into account the test results from my Cubietruck:
https://www.mail-archive.com/[email protected]/msg03510.html
--
Best regards,
Siarhei Siamashka
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
