[linux-sunxi] Re: [U-Boot] [PATCH 00/14] sunxi: Allwinner A10/A13/A20 DRAM controller fixes
Hi, On 07/18/2014 06:22 PM, Siarhei Siamashka wrote: Hello, First of all, it may be worth reminding that no accurate documentation for this particular DRAM controller exists in public access. However it is suspected that Allwinner uses one of the revisions of Synopsys DesignWare DDR2/3-Lite Memory Controller IP (MCTL) combined with DDR2/3-Lite PHY IP in A10/A13/A20. Also this DRAM controller apparently has siblings in Rockchip RK29XX, RK30XX and TI KeyStone2 hardware, which have some documentation and some bits of kernel and bootloader sources available in the Internet. Not to mention the original Allwinner boot0 bootloader sources and the suspend support code from the linux-sunxi kernel. This provides enough hints for finding out how the DRAM controller actually works by checking various bits of information via the trial and error method. In other words, a few people from the linux-sunxi community (me included) are essentially doing reverse engineering of the DRAM controller and using the linux-sunxi wiki to document all the findings: http://linux-sunxi.org/DRAM_Controller If Allwinner Technology, Synopsys DesignWare or anyone else can share real documentation or at least provide some hints or review the code, that would be really appreciated. Nevertheless, here is a patch set, which tries to improve the current u-boot sunxi dram code in the following way: * remove the convoluted dead code paths, which have no real use * fix obvious bugs and timing violations * add real ZQ calibration and ODT support for better reliability and higher clock speed potential * remove duplication and share code between sun4i/sun5i/sun7i * add more configuration knobs (such as MBUS clock frequency) * optional support for automatic detection of the bus width and chip density This patch set only modifies the dram.c and dram.h source files and applies cleanly to u-boot v2014.07 (but is intended for v2014.10). The patch set is organized in such a way, that we first fix bugs in the current sun7i implementation, and only after that add the missing sun4i/sun5i support bits. As such, it clashes with the dram parts of the sun4i/sun5i support patches, earlier submitted by Hans de Goede. First of all, many many thanks for working on this! Unfortunately the wheels of progress have been moving on though. Ian Campbell and I now maintain a u-boot custodian tree for allwinner related patches, and we (mostly Ian) have already prepared a set of patches to get merged for v2014.10 as soon as the window opens, and that includes sun4i and sun5i support. You can find this tree here: http://git.denx.de/?p=u-boot/u-boot-sunxi.git;a=summary I really don't want to go and roll-back changes already there so that we can add your patch-set. Therefor I've to ask you, can you please rebase your set on top of this tree? I understand this may be non trivial and thus may require some extra work from you side, and I'm sorry about that. Once you've posted a new rebased version I or Ian will review it and get it into the above tree for merging upstream. Regards, Hans -- 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] Re: [U-Boot] [PATCH 2/2] sunxi: Set the AUXCR L2EN bit for sun4i/sun5i in FEL boot mode
Hi, On 07/18/2014 07:09 PM, Siarhei Siamashka wrote: This is needed to have feature parity with the normal boot mode, where the L2EN bit in the CP15 Auxiliary Control Register is set by the BROM code right from the start. If this is not done, the Linux system ends up booted with the L2 cache disabled. Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com --- arch/arm/cpu/armv7/sunxi/board.c | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c index 49c9448..86cf4c9 100644 --- a/arch/arm/cpu/armv7/sunxi/board.c +++ b/arch/arm/cpu/armv7/sunxi/board.c @@ -69,6 +69,18 @@ void s_init(void) mcr p15, 0, r0, c1, c0, 1\n); #endif +#if defined(CONFIG_SPL_FEL) (defined(CONFIG_SUN4I) || defined(CONFIG_SUN5I)) + /* For ARM Cortex-A8 based hardware (sun4i and sun5i), the L2EN bit is +* set by the BROM code in the normal mode, but not in the FEL mode. +* Here we fix this inconsistency in the Auxiliary Ctl reg by also +* setting the missing L2EN bit. +*/ + asm volatile( + mrc p15, 0, r0, c1, c0, 1\n + orr r0, r0, #2\n + mcr p15, 0, r0, c1, c0, 1\n : : : r0); +#endif + Wouldn't it be better to do this in the start_fel.S file you've introduced in the first patch of this series ? Regards, Hans -- 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] Re: [U-Boot] [PATCH 1/3] AHCI: Increase link timeout to 200ms
Hi,
On 07/18/2014 09:38 PM, Ian Campbell wrote:
In 73545f75b66d ahci: wait longer for link I increased the
timeout to 40ms based on the observed behaviour of a WD disk on a
Cubietruck. Since then Karsten Merker and myself have both
observed timeouts with HGST disks (Karsten on Cubietruck, me on
Cubieboard2). Increasing the timeout to ~175ms fixes this, so go
to 200ms for a bit of headroom.
Signed-off-by: Ian Campbell i...@hellion.org.uk
Cc: Karsten Merker mer...@debian.org
Looks good to me:
Acked-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
---
drivers/block/ahci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index c8f6573..4df8046 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -41,7 +41,7 @@ u16 *ataid[AHCI_MAX_PORTS];
#define WAIT_MS_SPINUP2
#define WAIT_MS_DATAIO5000
#define WAIT_MS_FLUSH 5000
-#define WAIT_MS_LINKUP 40
+#define WAIT_MS_LINKUP 200
static inline u32 ahci_port_base(u32 base, u32 port)
{
--
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] Re: [U-Boot] [PATCH 3/3] ahci: provide sunxi SATA driver using AHCI platform framework
Hi,
On 07/18/2014 09:38 PM, Ian Campbell wrote:
This enables the necessary clocks, in AHB0 and in PLL6_CFG. This is done
for sun7i only since I don't have access to any other sunxi platforms
with sata included.
The PHY setup is derived from the Alwinner releases and Linux, but is mostly
undocumented.
The Allwinner AHCI controller also requires some magic (and, again,
undocumented) DMA initialisation when starting a port. This is added under a
suitable ifdef.
This option is enabled for Cubieboard, Cubieboard2 and Cubietruck based on
contents of Linux DTS files, including SATA power pin config taken from the
DTS. All build tested, but runtime tested on Cubieboard2 and Cubietruck only.
Signed-off-by: Ian Campbell i...@hellion.org.uk
Looks good to me:
Acked-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
---
arch/arm/cpu/armv7/sunxi/clock_sun4i.c| 4 ++
arch/arm/include/asm/arch-sunxi/clock_sun4i.h | 11 ++--
board/sunxi/Makefile | 1 +
board/sunxi/ahci.c| 84 +++
boards.cfg| 10 ++--
drivers/block/ahci.c | 16 +
include/ahci.h| 4 ++
include/configs/sunxi-common.h| 12
8 files changed, 133 insertions(+), 9 deletions(-)
create mode 100644 board/sunxi/ahci.c
diff --git a/arch/arm/cpu/armv7/sunxi/clock_sun4i.c
b/arch/arm/cpu/armv7/sunxi/clock_sun4i.c
index b8b16cf..ecbdb01 100644
--- a/arch/arm/cpu/armv7/sunxi/clock_sun4i.c
+++ b/arch/arm/cpu/armv7/sunxi/clock_sun4i.c
@@ -39,6 +39,10 @@ void clock_init_safe(void)
setbits_le32(ccm-ahb_gate0, 0x1 AHB_GATE_OFFSET_DMA);
#endif
writel(PLL6_CFG_DEFAULT, ccm-pll6_cfg);
+#ifdef CONFIG_SUNXI_AHCI
+ setbits_le32(ccm-ahb_gate0, 0x1 AHB_GATE_OFFSET_SATA);
+ setbits_le32(ccm-pll6_cfg, 0x1 CCM_PLL6_CTRL_SATA_EN_SHIFT);
+#endif
}
#endif
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
b/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
index 928f3f2..2531cbd 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
@@ -218,10 +218,13 @@ struct sunxi_ccm_reg {
#define CCM_PLL5_CTRL_BYPASS (0x1 30)
#define CCM_PLL5_CTRL_EN (0x1 31)
-#define CCM_PLL6_CTRL_N_SHIFT 8
-#define CCM_PLL6_CTRL_N_MASK (0x1f CCM_PLL6_CTRL_N_SHIFT)
-#define CCM_PLL6_CTRL_K_SHIFT 4
-#define CCM_PLL6_CTRL_K_MASK (0x3 CCM_PLL6_CTRL_K_SHIFT)
+#define CCM_PLL6_CTRL_EN 31
+#define CCM_PLL6_CTRL_BYPASS_EN30
+#define CCM_PLL6_CTRL_SATA_EN_SHIFT14
+#define CCM_PLL6_CTRL_N_SHIFT 8
+#define CCM_PLL6_CTRL_N_MASK (0x1f CCM_PLL6_CTRL_N_SHIFT)
+#define CCM_PLL6_CTRL_K_SHIFT 4
+#define CCM_PLL6_CTRL_K_MASK (0x3 CCM_PLL6_CTRL_K_SHIFT)
#define CCM_GPS_CTRL_RESET (0x1 0)
#define CCM_GPS_CTRL_GATE (0x1 1)
diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index 62acb8f..03f55cc 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -10,6 +10,7 @@
#
obj-y += board.o
obj-$(CONFIG_SUNXI_GMAC) += gmac.o
+obj-$(CONFIG_SUNXI_AHCI) += ahci.o
obj-$(CONFIG_A13_OLINUXINOM) += dram_a13_oli_micro.o
obj-$(CONFIG_CUBIEBOARD) += dram_cubieboard.o
obj-$(CONFIG_CUBIEBOARD2) += dram_cubieboard2.o
diff --git a/board/sunxi/ahci.c b/board/sunxi/ahci.c
new file mode 100644
index 000..0c262ea
--- /dev/null
+++ b/board/sunxi/ahci.c
@@ -0,0 +1,84 @@
+#include common.h
+#include ahci.h
+#include scsi.h
+#include errno.h
+#include asm/io.h
+#include asm/gpio.h
+
+#define AHCI_PHYCS0R 0x00c0
+#define AHCI_PHYCS1R 0x00c4
+#define AHCI_PHYCS2R 0x00c8
+#define AHCI_RWCR0x00fc
+
+/* This magic PHY initialisation was taken from the Allwinner releases
+ * and Linux driver, but is completely undocumented.
+ */
+static int sunxi_ahci_phy_init(u32 base)
+{
+ u8 *reg_base = (u8 *)base;
+ u32 reg_val;
+ int timeout;
+
+ writel(0, reg_base + AHCI_RWCR);
+ mdelay(5);
+
+ setbits_le32(reg_base + AHCI_PHYCS1R, 0x1 19);
+ clrsetbits_le32(reg_base + AHCI_PHYCS0R,
+ (0x7 24),
+ (0x5 24) | (0x1 23) | (0x1 18));
+ clrsetbits_le32(reg_base + AHCI_PHYCS1R,
+ (0x3 16) | (0x1f 8) | (0x3 6),
+ (0x2 16) | (0x6 8) | (0x2 6));
+ setbits_le32(reg_base + AHCI_PHYCS1R, (0x1 28) | (0x1 15));
+ clrbits_le32(reg_base + AHCI_PHYCS1R, (0x1 19));
+ clrsetbits_le32(reg_base + AHCI_PHYCS0R, (0x7 20), (0x3 20));
+ clrsetbits_le32(reg_base + AHCI_PHYCS2R, (0x1f 5), (0x19 5));
+ mdelay(5);
+
+ setbits_le32(reg_base + AHCI_PHYCS0R, (0x1 19));
+
+ timeout = 250; /* Power up takes approx 50 us */
+ for (;;) {
+ reg_val = readl(reg_base + AHCI_PHYCS0R) (0x7 28);
+ if (reg_val == (0x2
Re: [linux-sunxi] MicroSD Breakout board connectors
On Sat, Jul 19, 2014 at 9:06 PM, Jaakko Niemi liiwis...@gmail.com wrote: HI, Does anyone have spesific model name/number of the connectors on the MicroSD breakout board? To my untrained eye they seem to be 1.27mm 14 pin and 2.0mm 5-pin ones, but so far I haven't found any fitting connectors or cables.. Do you mean this one? http://linux-sunxi.org/MicroSD_Breakout It's just two sides of the same board. One side has 5 pins for UART, the other has a 2x7 connector for JTAG. You can only use either one. For the UART, just plug your USB-UART cable pins on it. They won't stick, but it works. ChenYu -- 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] A20 boot0/boot1 info
Hi all, I'm having trouble finding some infos regarding Boot0/Boot1 bootloaders - I need some GPIO control during boot and I also want to try to change the part of it which has magic number checking for NAND implemented. So far I have found only some general things about it on linux-sunxi.org and I'm currently going through the code to figure it out more (I've cloned hno/allwinner-boot), but some pointers or reading would be nice. My current GPIO Boot1 problem: I am booting off NAND with Olinuxino-A20 and I've changed the lcd_bl_en pin from PH07 to PB04 in my fex file, recompiled binary script.bin and copied it to /dev/nanda. I've also changed the actual physical connection on the pcb. After the kernel boots, it's the same as before - backlight working normally. However, during power-up, until the kernel LCD driver kicks in, the LCD is blank and I can no longer see the Boot1 logo (haven't changed it - still says Allwinner A20 Dual Core or something) - I just see the glimpse of it when kernel fires up the backlight. So for Boot1 (which inits the LCD also during LiPo charging), nothing's changed - BL_EN is still at PH07. This is why I've decided to change it in the source. However, the Boot1 source is quite messy for my taste and I also see references to script_parsers in the source like for regular linux kernel drivers, so it seems to also parse the script, but maybe not script.bin. So, if someone's got any info on this it'd be quite nice to share. Thanks in advance! -- 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] MicroSD Breakout board connectors
On Saturday, July 19, 2014 5:38:11 PM UTC+3, Chen-Yu Tsai wrote: On Sat, Jul 19, 2014 at 9:06 PM, Jaakko Niemi liiw...@gmail.com javascript: wrote: HI, Does anyone have spesific model name/number of the connectors on the MicroSD breakout board? To my untrained eye they seem to be 1.27mm 14 pin and 2.0mm 5-pin ones, but so far I haven't found any fitting connectors or cables.. Do you mean this one? http://linux-sunxi.org/MicroSD_Breakout Yup, there are not that many microsd breakoutboards :) It's just two sides of the same board. One side has 5 pins for UART, the other has a 2x7 connector for JTAG. You can only use either one. I'm looking for the pin spacing info or connectors models numbers. Any hints for those? For the UART, just plug your USB-UART cable pins on it. They won't stick, but it works. Yup, tried that, but need hot glue if I want them to stick. I'm just looking for info on the connectors and cables so that I don't have to .. umm.. glue-cycle every time I need to do something. Well, couple pieces of duct-tape does it now. --j -- 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] A20 device with AC97 codec chip
Are there any A20 based devices using an AC97 codec chip around? Emilio and I are working on audio drivers. We have hardware for everything except the AC97 case. -- Jon Smirl jonsm...@gmail.com -- 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] Re: gslx680 driver ported to sunxi
Hi, Sorry weekend away, only got phone and a few minutes. The separate files are separate firmwares from the Android driver. I have no way currently of know switch is right, so you will need to try each to find the right one. Joe On 19 Jul 2014 09:13, pebr...@gmail.com wrote: Hi Joe, i just received A20 tablet with manufactured code K711_OGS and this tab using gsl1688 for the touchscreen.. for a week i tried to make your driver works but always ended up with incomplete xfer 0xf8. Just yesterday i found out that 3.4.90 kernel has bugs with i2c devices since they changes i2c transfer speed from 200khz to standard 100khz. Changed back to 200 khz and the complaining about incomplete xfer dissapeared. The driver load successfully but i still can't get output. Maybe just firmware problem since fw extractor give me strange output.. it's split fw by 20 or more files. -- You received this message because you are subscribed to a topic in the Google Groups linux-sunxi group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/linux-sunxi/SZGxiTQcFyY/unsubscribe. To unsubscribe from this group and all its topics, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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] GSoC 2014 #1 status report - Improving Allwinner SoC support
Hi everyone, Here's this week's update on my GSoC project; if you missed the first issue or you want a refresher of what this is about, you can read it on the list archives[0] A couple of days after the last report, and with the help of Jon Smirl, I got the hardware working on mainline Linux, first on only 16 bit stereo mode, then mono as well, and later on, also on 24 bit mode. The first thing I had to do was rework the cyclic DMA code to make it perform decently and avoid underruns. The rest took a bit of playing with values and reading the Allwinner documentation. There is one unresolved issue with 24 bit audio still - for some reason, the volume is really low compared to the same track played on 16 bit. Unfortunately the SDK driver doesn't support 24 bit, so it's hard to compare with anything else. Aside from the audio stuff, I worked a bit on the DMA driver, after realizing memcpy could be optimized a fair bit. By using proper alignment and choosing the best bus width and as big a burst as possible, I was able to go from a totally unscientifically measured ~3MB/s to ~13MB/s on a single thread, single channel, 1000 iterations dmatest run with noverify=0. I will be sending a v3 with these new changes as well as addressing comments I received in the next few days. To round up on this week's developments, I also worked on the audio clock representation, involving PLL2, the codec clock gate and module 1 clocks (AC97, SPDIF, IIS) to enable Jon to work on IIS. Patches for these clocks will be out in the list soon as well. You can expect the next status report in about a week's time. Cheers! Emilio [0] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/271150.html -- 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] Re: [U-Boot] [PATCH 1/3] AHCI: Increase link timeout to 200ms
Dear Ian Campbell, In message 1405712321-12334-1-git-send-email-...@hellion.org.uk you wrote: In 73545f75b66d ahci: wait longer for link I increased the timeout to 40ms based on the observed behaviour of a WD disk on a Cubietruck. Since then Karsten Merker and myself have both observed timeouts with HGST disks (Karsten on Cubietruck, me on Cubieboard2). Increasing the timeout to ~175ms fixes this, so go to 200ms for a bit of headroom. Is there not some specification anywhere which defines a maximum time that is allowed for the link to come up? #define WAIT_MS_SPINUP 2 #define WAIT_MS_DATAIO 5000 #define WAIT_MS_FLUSH5000 -#define WAIT_MS_LINKUP 40 +#define WAIT_MS_LINKUP 200 BTW: All these names are just horrible from a name space point of view :-( Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Bus error -- please leave by the rear door. -- 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] GSoC 2014 #1 status report - Improving Allwinner SoC support
Hi Emilio, On Sun, Jul 20, 2014 at 3:41 AM, Emilio López emi...@elopez.com.ar wrote: Hi everyone, Here's this week's update on my GSoC project; if you missed the first issue or you want a refresher of what this is about, you can read it on the list archives[0] A couple of days after the last report, and with the help of Jon Smirl, I got the hardware working on mainline Linux, first on only 16 bit stereo mode, then mono as well, and later on, also on 24 bit mode. The first thing I had to do was rework the cyclic DMA code to make it perform decently and avoid underruns. The rest took a bit of playing with values and reading the Allwinner documentation. There is one unresolved issue with 24 bit audio still - for some reason, the volume is really low compared to the same track played on 16 bit. Unfortunately the SDK driver doesn't support 24 bit, so it's hard to compare with anything else. So I have not experimented on this, it's just a hunch: Could it be that the 24bit audio samples you're sending to the audio codec is aligned incorrectly? So the sample is actually seen as down-shifted by 8 bits, resulting in the low volume? I'll grab your tree and test 24bit tomorrow. (Good thing I have 24 bit music files.) :) Aside from the audio stuff, I worked a bit on the DMA driver, after realizing memcpy could be optimized a fair bit. By using proper alignment and choosing the best bus width and as big a burst as possible, I was able to go from a totally unscientifically measured ~3MB/s to ~13MB/s on a single thread, single channel, 1000 iterations dmatest run with noverify=0. I will be sending a v3 with these new changes as well as addressing comments I received in the next few days. This still seems quite slow? I think there was a discussion about this on IRC, you included? Any followups there? To round up on this week's developments, I also worked on the audio clock representation, involving PLL2, the codec clock gate and module 1 clocks (AC97, SPDIF, IIS) to enable Jon to work on IIS. Patches for these clocks will be out in the list soon as well. Thanks! I look forward to them. Cheers ChenYu You can expect the next status report in about a week's time. Cheers! Emilio [0] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/271150.html -- 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.
