Re: [linux-sunxi] [RFC PATCH u-boot 2/2] sunxi: dram: Fix autorefresh timing setup
On 06/04/14 04:19, Siarhei Siamashka wrote:
On Wed, 26 Mar 2014 17:40:50 +0100
Jens Kuske jensku...@gmail.com wrote:
This patch unifies sun4i and sun[5,7]i autorefresh setup functions
and adds proper tRFC calculation.
tRFC (REF command to ACT time) depends on DDR type and chip density.
On sun4i there were two steps, 127.5ns for =1Gb density and 327.5ns
for the rest. This fits DDR2 specification for 1Gb and 4Gb chips
and shouldn't be a problems with DDR3 chips 8Gb either, but it will
waste some performance.
On sun[5,7]i however, tRFC was hardcoded to 131 clock cycles, which
seems to come from 4Gb DDR2 chips at 400MHz (327.5ns * 400MHz = 131).
For 4Gb DDR3 chips, like those on cubieboard2 and cubietruck, this
means the memory frequency was limited to ~435MHz if one doesn't want
to fall below the minimum specified tRFC for these chips.
Signed-off-by: Jens Kuske jensku...@gmail.com
---
arch/arm/cpu/armv7/sunxi/dram.c| 70
--
arch/arm/include/asm/arch-sunxi/dram.h | 4 ++
2 files changed, 28 insertions(+), 46 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/dram.c
b/arch/arm/cpu/armv7/sunxi/dram.c
index 957db59..921f683 100644
--- a/arch/arm/cpu/armv7/sunxi/dram.c
+++ b/arch/arm/cpu/armv7/sunxi/dram.c
@@ -412,53 +412,30 @@ static void dramc_clock_output_en(u32 on)
#endif
}
-#ifdef CONFIG_SUN4I
-static void dramc_set_autorefresh_cycle(u32 clk)
-{
-struct sunxi_dram_reg *dram = (struct sunxi_dram_reg *)SUNXI_DRAMC_BASE;
-u32 reg_val;
-u32 tmp_val;
-u32 reg_dcr;
-
-if (clk 600) {
-reg_dcr = readl(dram-dcr);
-if ((reg_dcr DRAM_DCR_CHIP_DENSITY_MASK) =
-DRAM_DCR_CHIP_DENSITY(DRAM_DCR_CHIP_DENSITY_1024M))
-reg_val = (131 * clk) 10;
-else
-reg_val = (336 * clk) 10;
-
-tmp_val = (7987 * clk) 10;
-tmp_val = tmp_val * 9 - 200;
-reg_val |= tmp_val 8;
-reg_val |= 0x8 24;
-writel(reg_val, dram-drr);
-} else {
-writel(0x0, dram-drr);
-}
-}
-#endif /* SUN4I */
+static const u16 tRFC_table[2][6] = {
+/* 256Mb512Mb1Gb 2Gb 4Gb 8Gb */
+/* DDR2 75ns 105ns127.5ns 195ns327.5ns invalid */
+{77, 108, 131, 200, 336, 336 },
+/* DDR3 invalid 90ns 110ns160ns300ns350ns*/
+{93, 93, 113, 164, 308, 359 }
+};
-#if defined(CONFIG_SUN5I) || defined(CONFIG_SUN7I)
-static void dramc_set_autorefresh_cycle(u32 clk)
+static void dramc_set_autorefresh_cycle(u32 clk, u32 type, u32 density)
{
struct sunxi_dram_reg *dram = (struct sunxi_dram_reg *)SUNXI_DRAMC_BASE;
-u32 reg_val;
-u32 tmp_val;
-reg_val = 0x83;
-
-tmp_val = (7987 * clk) 10;
-tmp_val = tmp_val * 9 - 200;
-reg_val |= tmp_val 8;
-reg_val |= 0x8 24;
-writel(reg_val, dram-drr);
+u32 tRFC, tREFI;
+
+tRFC = (tRFC_table[type][density] * clk + 1023) 10;
+tREFI = (7987 * clk) 10; /* = 7.8us */
Maybe I'm missing something, but what has happened to the tmp_val =
tmp_val * 9 - 200 part of the old code?
Also looks like there was an intention to replace reg_val |= 0x8
24 with the use of the new DRAM_DRR_BURST macro, but I can't see it
anywhere either.
I forgot to explain that, I removed the burst refresh. Don't know
whether this was a good idea, but there are some resources stating burst
refreshes reduce power consumption at the expense of increased latency.
Normally there is a tRFC-long refresh every tREFI, with burst there are
9*tRFC breaks every 9*tREFI. This leads to dram hangs of up to 3us
every ~70us.
reg_val |= 0x8 24 made the controller issue 9 refresh commands in
burst, and thus the period between refresh had to be multiplied by 9.
I don't know why they subtract 200, but it looks like some safety
margin. Maybe I shouldn't have removed that...
This patch was a RFC to discuss such things, so thanks for the comments.
Maybe it should be added again, but I don't think they originally wasted
any thoughts on this, they simply took the default values (reset-value
for burst is 0x8).
+
+writel(DRAM_DRR_TREFI(tREFI) | DRAM_DRR_TRFC(tRFC), dram-drr);
}
-#endif /* SUN5I */
unsigned long dramc_init(struct dram_para *para)
{
struct sunxi_dram_reg *dram = (struct sunxi_dram_reg *)SUNXI_DRAMC_BASE;
u32 reg_val;
+u32 density;
int ret_val;
/* check input dram parameter structure */
@@ -497,20 +474,21 @@ unsigned long dramc_init(struct dram_para *para)
reg_val |= DRAM_DCR_IO_WIDTH(para-io_width 3);
if (para-density == 256)
-reg_val |= DRAM_DCR_CHIP_DENSITY(DRAM_DCR_CHIP_DENSITY_256M);
+density = DRAM_DCR_CHIP_DENSITY_256M;
else if (para-density == 512)
-
Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code
On Sat, 05 Apr 2014 17:58:11 +0200 Jens Kuske jensku...@gmail.com wrote: On 03/04/14 07:49, Siarhei Siamashka wrote: I would guess that the .tpr settings, bundled with .cas=6, are likely assuming 400MHz memory clock speed. Which also agrees with the tRFC hardcoded values as you mentioned above. And also with the A10 and A20 user manuals, which specify 0~400MHz range for SDRAM_clk. The .cas=9 style sets of timings are likely very conservative and assuming memory clock speeds up to 667MHz if we take the cas value as a hint. If we are running dram at around 480MHz, these settings may unnecessarily sacrifice some performance. I found some documentation for TPR registers in the rk30xx manual from radxa. Their dram controller is pretty much different, but comparing the default values and settable bits of the TPR registers makes it likely that at least these registers have nearly the same bitfields. This makes the .cas=6 set look like: tMRD = 2, tRTP = 4, tWTR = 4, tRP = 6, tRCD = 6, tRAS = 18, tRRD = 4, tRC = 24, tCCD = 0 tAOND_tAOFD = 0, tRTW = 0, tFAW = 18, tMOD = 0, tRTODT = 0 tXS = 200, tXP = 8, tCKE = 3 Assuming this is valid, we can do some trail and error again and try to figure out the original timings. As it turns out, your guess was pretty good. The settings *exactly* match DDR2(!)-800E speed bin at 400MHz. Its DDR2 again, as with tRFC. Interesting part is, if we assume DDR3-1333H chips (as on cubieboard) many parameters are still in spec up to 480MHz (not all however, tFAW, tXS and what else I missed not). And for the .cas=9 set, most settings match DDR3-1333H speed bin at 667MHz. But some settings, like tFAW and tXP are too low, they only fit for ~420MHz. tMRD = 3, tRTP = 5, tWTR = 5, tRP = 9, tRCD = 9, tRAS = 24, tRRD = 6, tRC = 33, tCCD = 0 tAOND_tAOFD = 0, tRTW = 0, tFAW = 18, tMOD = 0, tRTODT = 0 tXS = 512, tXP = 10, tCKE = 4 That's a very nice catch. Thanks! Looks like this is a stepping stone in the memory controller reverse engineering. However things would have been surely much easier if all of this was properly documented by Allwinner. I tried to calculate the correct parameters for 480MHz on cubietruck, and currently lima-memtester is running without any errors till now. I first accidentally kept the clock at 432MHz and only changed the tprs, and even that gave a ~150MB/s boost at tinymembench compared to the original values. This is highly experimental, but if somebody wants to try (only cubietruck, other dram chips need different timings): .clock = 480 .cas = 7 .tpr0 = 0x30b27790 .tpr1 = 0xa078 .tpr2 = 0x0001b200 These timings are calculated by hand, but maybe this could lead to some program or even function in u-boot that calculates matching parameters for given dram chip type and speed. Well, not a big surprise, but my lucky Cubietruck fails lima-memtester tests with these settings too: Kernel driver is version 14 Detected 1 Mali-400 GP Cores. Detected 2 Mali-400 PP Cores. FB: 1280x720@32bpp at 0x51001000 (0x00A8C000) Using dual buffered direct rendering to FB. memtester version 4.3.0 (32-bit) Copyright (C) 2001-2012 Charles Cazabon. Licensed under the GNU General Public License version 2 (only). pagesize is 4096 pagesizemask is 0xf000 want 300MB (314572800 bytes) got 300MB (314572800 bytes), trying mlock ...locked. Loop 1: Stuck Address : ok Random Value: ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential: ok Checkerboard: ok Bit Spread : ok Bit Flip: testing 221FAILURE: 0xf7ff != 0xf700 at offset 0x03e041fc. FAILURE: 0x0800 != 0x080c at offset 0x03e04200. FAILURE: 0xf7ff != 0xf706 at offset 0x03e04204. Walking Ones: ok Walking Zeroes : ok Loop 2: Stuck Address : ok Random Value: ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential: ok Checkerboard: ok Bit Spread : ok Bit Flip: testing 213FAILURE: 0xfbff != 0xfb00 at offset 0x038051bc. FAILURE: 0x0400 != 0x04ff at offset 0x038051c0. FAILURE: 0xfbff != 0xfb00 at offset 0x038051c4. FAILURE: 0x0400 != 0x04ff at offset 0x038051c8. FAILURE: 0xfbff != 0xfb00 at offset 0x038051cc. FAILURE: 0x0400 != 0x04ff at offset 0x038051d0. FAILURE: 0xfbff != 0xfb00 at offset 0x038051d4. FAILURE: 0x0400 != 0x04ff at offset 0x038051d8. FAILURE: 0xfbff != 0xfb00 at offset
Re: [linux-sunxi] Re: [PATCH u-boot sunxi] sunxi: reduce Cubieboard2 dram clock from 480MHz to 384MHz
On Fri, 21 Mar 2014 04:27:19 -0700 (PDT) ditmar.r...@gmail.com 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/linux-sunxi@googlegroups.com/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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Audio support for up-to-date kernel
On Sat, 05 Apr 2014 12:57:52 -0400 Stefan Monnier monn...@iro.umontreal.ca wrote: I've been using the 3.4 kernel for a while now but have just switched to sunxi-devel because the 3.4 kept freezing (I partly worked around it by rebooting via cron once a day, which reduced the occurrence of the problem, but didn't eliminate it). This is most definitely not normal. The 3.4 kernel works fine for many people. For example, having weeks of uptime is not uncommon on my sunxi hardware. What kind of hardware do you have? Do you have anything unusual? Like a customized kernel config, overclocking of any sort, your own patches applied to the kernel or fex file customization? Have you also tried to disable the ondemand cpufreq governor (switch it to performance) and get rid of display blanking? -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Reading EDID blocks from LVDS LCD to configure LVDS output?
I found information on how to manually configure an LVDS display in the Wiki. However, at least in the case of the LVDS LCDs I can easily scrounge up out of otherwise dead HP DV6000/DV9000 laptops, the LG panels support E-EDID, and the factory cables have wires attached for it. The question is, where would I hook them up to on an AllWinner chip and then how would I use them to configure the LVDS display options? The first one I stripped I can't find a datasheet freely available for, so the only method I have to get the proper timings for it is to pull the E-EDID block and decode it. I'm also going to go out on a limb and guess that other LVDS LCDs support E-EDID as well. If it is possible to use EDID to configure them, it would make using an LVDS LCD much simpler :) Thanks! -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Livesuite image building tools
I'm trying to get build root to build an image that I can flash into my Cubieboard2 and boot. I think this means an image that Livesuit (which I have working) can read. It looks like sunxi-bsp is the preferred solution for building Livesuit images around here. I think I have buildroot building all of the u-boot files I need, and from looking at sunxi-bsp it looks like what I need mostly at this point is linux-sunxi/allwinner-tools from github (which is mostly proprietary binaries). I have also noted that there seems to be a newer toolset (from allwinner?) under the name Lichee? Is the linux-sunxi/allwinner-tools the way to go, or is there another way to build a Livesuit image from scratch? Also what do people think of the lichee toolset. Brian * https://github.com/linux-sunxi/allwinner-tools* -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Reading EDID blocks from LVDS LCD to configure LVDS output?
Dear John , what board are you using? The LVDS output needs to be tapped from the boards, its not possible to access the lvds pins of AW unless the boards offer them in a convenient connector. some relevant example links are below: http://linux-sunxi.org/Cubieboard/LVDS regds mallah. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
