On Wed, 18 Feb 2015 22:29:07 -0800 (PST)
TsvetanUsunov <[email protected]> wrote:
> Hi
>
> For A13-OLinuxino till now we conservatively used the Linux-Sunxi uboot,
> but we recently got new lot of Samsung memories and we decided to tweak
> some parameters for this DDR in Linux-Sunxi uboot and found problems.
> As this uboot is with status not maintained anymore I will not discuss the
> problems, as probably no one will spend time on it,
This is actually very much interesting. What kind of problems you
got after the change of DDR3 chips? My (probably somewhat limited)
understanding is that all DDR3 chips have to support standard timings
according to the JEDEC specs. There are several standard speed bins,
so the faster chips just are tested for compatibility with a faster
speed bin and labelled as such.
BUT
The "magic" Allwinner settings in u-boot make the DDR3 chips
configuration violate the spec:
http://lists.denx.de/pipermail/u-boot/2015-January/201787.html
So I would not be very surprised if some of the chips can tolerate
these settings and the others can't.
If you can confirm that this is indeed the problem, then we might try
to drop the problematic magic settings sooner. You can find a
collection of DDR3 timing parameters for different clock speeds
and JEDEC speed bins at:
http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/dram_timings_sun4i.h;h=29b934da639c86b1830d1e26b7a751b6b227a21a;hb=HEAD
The hardware documentation about the timing parameters is in the
linux-sunxi wiki (no official documentation exists, but we took some
efforts to collect the information about similar DRAM controllers
used in Rockchip/TI SoCs from the Internet and verify that they
actually apply to our hardware, mostly using the "trial and error"
method of black box testing):
http://linux-sunxi.org/A10_DRAM_Controller_Register_Guide#SDR_TPR0
http://linux-sunxi.org/A10_DRAM_Controller_Register_Guide#SDR_TPR1
http://linux-sunxi.org/A10_DRAM_Controller_Register_Guide#SDR_TPR2
Additionally, by tweaking the impedance matching configuration (using a
brute force search and some heuristics), we can reach much higher DRAM
clock speeds on various hardware. Some information about this is here:
http://linux-sunxi.org/A10_DRAM_Controller_Calibration
I know that Olimex has opted to just change the RZQ resistors nominal
away from the standard 240 Ohm in different board revisions instead of
tweaking the impedance via software. This introduces a practical problem
for us on Olimex boards, which employ these tricks.
It would be great if we could have a better cooperation with Olimex
and maybe improve the DRAM configuration on Olimex boards to get
better reliability and performance. Basically, we need to run certain
tests on a statistically significant number of boards, preferably from
different batches. I can help and answer questions. But most of the
information is already available in the linux-sunxi wiki.
> so we wisely decided to
> move to mainline uboot :) but it seems there are other issues to address.
That's a good choice :)
BTW, the blog post
https://olimex.wordpress.com/2014/10/27/a20-olinuxino-lime2-review-and-updates/
says that "Much better routing of DDR3 memory. We increased the number
of layers to 8 vs the 6 layers in LIME, we put the DDR3 memory closer
to the A20, we layout the tracks shorter, as result now LIME2 runs with
DDR3 on 532Mhz on LIME there were problems to run DDR3 at more than
400Mhz"
I'm very happy about the improved DRAM clock speed in LIME2. But if I
understand this correctly, the old LIME is not expected to be reliable
with the DRAM clocked higher than 400MHz? Are you now going to
contribute updates for
http://git.denx.de/?p=u-boot.git;a=blob;f=configs/A10-OLinuXino-Lime_defconfig;h=8fa1a330cd34e1a8202892595c549971b3275169;hb=HEAD
http://git.denx.de/?p=u-boot.git;a=blob;f=configs/A20-OLinuXino-Lime_defconfig;h=5442f645f87165c34bbed8ba3e6cde3d8a8b87e8;hb=HEAD
to pick a more reasonable DRAM clock speed? Or do you see no
problems having it configured as 480MHz in the mainline u-boot
for A10-OLinuXino-Lime and A20-OLinuXino-Lime?
> The PLL5 and PLL6 values are changed and this cause problems, this is what
> we found so far:
I'm sorry to hear about that. In fact, I'm partially to blame. However,
if the mainline u-boot compatibility with the sunxi-3.4 kernels was
implemented in a way that I wanted it to be implemented, then you
would not have needed to waste extra time debugging this problem.
> 1. mainline u-boot
> =================
> 1.1 pll5
> address 0x01c20020, value 0xb1049091 - P=1, N=16, K=2, M=2.
> The PLL5 output for DDR = (24MHz*N*K)/M. DDR=24*16*2/2 = 384MHz
> The PLL5 output for other module = (24MHz*N*K)/P. DDR=24*16*2/1 = 768MHz -
> This high frequency cause LCDs connected to the board to flicker
Yes, this was already known. And had been addressed a long time ago.
Hans has a more detailed reply, so I'm not going to duplicate it.
> 1.2 pll6
> address 0x01c20028, value 0xA1009900 - N=25, K=1, M=1
> The PLL6 output is (24MHz*N*K)/M/2 = 24*25*1/1/2 = 300MHz
> 1.3 MBUS clock
> address 0x01c2015c, value 0x81000001 - MBUS clock source is PLL6/2 = 300/2
> = 150MHz - This is connected to PLL6 setup, at this 150 Mhz the board cant
> play video smoothly and sometimes drop video packets when the video is
> playing
Right. Having a reasonably fast MBUS clock speed is very important for
performance.
> 2. sunxi u-boot
> =================
> 1.1 pll5
> address 0x01c20020, value 0xb1049091 - P=2, N=17, K=2, M=2.
> The PLL5 output for DDR = (24MHz*N*K)/M. DDR=24*17*2/2 = 408MHz
> The PLL5 output for other module = (24MHz*N*K)/P. DDR=24*16*2/2 = 408MHz -
> this frequency was OK, There is no problem with LCD flickering, why the
> frequency increase was necessary?
> 1.2 pll6
> address 0x01c20028, value 0xA1009900 - N=25, K=1, M=1
> The PLL6 output is (24MHz*N*K)/M/2 = 24*25*1/1/2 = 300MHz
Thanks a lot for finding and reporting this particular problem.
Based on a quick look, the most likely culprit seems to be the
'clock_get_pll6()' function in u-boot, which is providing wrong
information to the DRAM code. But Hans is already working on a
fix, so I'm not going to get involved yet.
Additionally, the sunxi-3.4 kernel is trying to re-configure PLL6 in
'arch/arm/mach-sun5i/clock/clock.c', which is a bit of a mess. As you
have the problem, most likely it also ends up being 300MHz there.
Probably the sunxi-3.4 kernel should not touch PLL6 at all and keep
the settings from u-boot.
> 1.3 about MBUS clock
> address 0x01c2015c, value 0x82000001 - MBUS clock source is PLL5/2 = 408/2
> = 204MHz - at this frequency No packet drop when the video is playing
>
>
> Can you tell me the reasons for the PLL5 and PLL6 frequency changes to
> mainline uboot?
Not doing the pre-division of PLL5P by two allows us to have the
MBUS/DRAM clock speed ratio 2/3 among other things. For example,
you can set DRAM to 408MHz and MBUS to 272MHz if you want. This in
some cases means better performance. Also the mainline u-boot is
expected to work with a wider range of DRAM clock frequencies
(up to and beyond 600MHz). You already get into a trouble with
the MBUS-clocked peripherals in the unpatched sunxi-3.4 kernel
when using DRAM/MBUS clock speeds of this magnitude.
As a workaround, you can just set '.mbus_clock' in the 'dram_para'
struct to 204 (exactly twice lower than the DRAM clock speed). And
u-boot will select PLL5P for clocking MBUS instead of PLL6.
--
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.
