March 2015 - U-Boot

[U-Boot] [PATCH V2 1/2] usb: dwc2: fix aligned buffer usage
by Stephen Warren 09 Mar '15

09 Mar '15

The original aligned_buffer usage: a) Uselessly copied data into the aligned buffer even for IN transactions. Fix this my making the copy conditional. b) Always programmed the HW to transfer to/from the start of the aligned buffer. This worked fine for OUT transactions since the memcpy copied the OUT data to this location too. However, for large IN transactions, since the copy from the aligned buffer to the "client" buffer was deferred until after all chunks were transferred. it resulted in each chunk's transfer over-writing the data for the first transfer. Fix this by copying IN data as soon as it's received. Signed-off-by: Stephen Warren <swarren(a)wwwdotorg.org> --- v2: Move all memcpy()s back into the per-chunk loop; we can't rely on maxpacket being a multiple of 8-bytes, so we need to copy each chunk to the aligned_buffer not aligned_buffer+done; the HW requires 8-byte alignment for the DMA buffer. drivers/usb/host/dwc2.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index 5a1c44a8fb75..05d21b7948f5 100644 --- a/drivers/usb/host/dwc2.c +++ b/drivers/usb/host/dwc2.c @@ -795,7 +795,9 @@ int chunk_msg(struct usb_device *dev, unsigned long pipe, int *pid, int in, (*pid << DWC2_HCTSIZ_PID_OFFSET), &hc_regs->hctsiz); - memcpy(aligned_buffer, (char *)buffer + done, len - done); + if (!in) + memcpy(aligned_buffer, (char *)buffer + done, len); + writel((uint32_t)aligned_buffer, &hc_regs->hcdma); /* Set host channel enable after all other setup is complete. */ @@ -810,16 +812,16 @@ int chunk_msg(struct usb_device *dev, unsigned long pipe, int *pid, int in, break; } - done += xfer_len; if (in) { - done -= sub; + xfer_len -= sub; + memcpy(buffer + done, aligned_buffer, xfer_len); if (sub) stop_transfer = 1; } - } while ((done < len) && !stop_transfer); - if (done && in) - memcpy(buffer, aligned_buffer, done); + done += xfer_len; + + } while ((done < len) && !stop_transfer); writel(0, &hc_regs->hcintmsk); writel(0xFFFFFFFF, &hc_regs->hcint); -- 1.9.1

2 3

[U-Boot] [PATCH 1/5] usb: dwc2: unify waiting for transfer completion
by Stephen Warren 09 Mar '15

09 Mar '15

Lift common code out of submit_bulk_msg() and submit_control_msg(). Signed-off-by: Stephen Warren <swarren(a)wwwdotorg.org> --- drivers/usb/host/dwc2.c | 167 +++++++++++++++++------------------------------- 1 file changed, 60 insertions(+), 107 deletions(-) diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index e8142ac0922f..62111a754a1b 100644 --- a/drivers/usb/host/dwc2.c +++ b/drivers/usb/host/dwc2.c @@ -704,6 +704,36 @@ static int dwc_otg_submit_rh_msg(struct usb_device *dev, unsigned long pipe, return stat; } +int wait_for_chhltd(uint32_t *sub, int *toggle) +{ + const uint32_t hcint_comp_hlt_ack = DWC2_HCINT_XFERCOMP | + DWC2_HCINT_CHHLTD | DWC2_HCINT_ACK; + struct dwc2_hc_regs *hc_regs = &regs->hc_regs[DWC2_HC_CHANNEL]; + int ret; + uint32_t hcint, hctsiz; + + ret = wait_for_bit(&hc_regs->hcint, DWC2_HCINT_CHHLTD, true); + if (ret) + return ret; + + hcint = readl(&hc_regs->hcint); + if (hcint != hcint_comp_hlt_ack) { + debug("%s: Error (HCINT=%08x)\n", __func__, hcint); + return -EINVAL; + } + + hctsiz = readl(&hc_regs->hctsiz); + *sub = (hctsiz & DWC2_HCTSIZ_XFERSIZE_MASK) >> + DWC2_HCTSIZ_XFERSIZE_OFFSET; + if (toggle) + *toggle = (hctsiz & DWC2_HCTSIZ_PID_MASK) >> + DWC2_HCTSIZ_PID_OFFSET; + + debug("%s: sub=%u toggle=%d\n", __func__, *sub, toggle ? *toggle : -1); + + return 0; +} + /* U-Boot USB transmission interface */ int submit_bulk_msg(struct usb_device *dev, unsigned long pipe, void *buffer, int len) @@ -712,13 +742,12 @@ int submit_bulk_msg(struct usb_device *dev, unsigned long pipe, void *buffer, int ep = usb_pipeendpoint(pipe); int max = usb_maxpacket(dev, pipe); int done = 0; - uint32_t hctsiz, sub, tmp; + int ret; + uint32_t sub; struct dwc2_hc_regs *hc_regs = &regs->hc_regs[DWC2_HC_CHANNEL]; - uint32_t hcint; uint32_t xfer_len; uint32_t num_packets; int stop_transfer = 0; - unsigned int timeout = 1000000; if (devnum == root_hub_devnum) { dev->status = 0; @@ -771,50 +800,17 @@ int submit_bulk_msg(struct usb_device *dev, unsigned long pipe, void *buffer, (1 << DWC2_HCCHAR_MULTICNT_OFFSET) | DWC2_HCCHAR_CHEN); - while (1) { - hcint = readl(&hc_regs->hcint); - - if (!(hcint & DWC2_HCINT_CHHLTD)) - continue; - - if (hcint & DWC2_HCINT_XFERCOMP) { - hctsiz = readl(&hc_regs->hctsiz); - done += xfer_len; - - sub = hctsiz & DWC2_HCTSIZ_XFERSIZE_MASK; - sub >>= DWC2_HCTSIZ_XFERSIZE_OFFSET; - - if (usb_pipein(pipe)) { - done -= sub; - if (hctsiz & DWC2_HCTSIZ_XFERSIZE_MASK) - stop_transfer = 1; - } - - tmp = hctsiz & DWC2_HCTSIZ_PID_MASK; - tmp >>= DWC2_HCTSIZ_PID_OFFSET; - if (tmp == DWC2_HC_PID_DATA1) { - bulk_data_toggle[devnum][ep] = - DWC2_HC_PID_DATA1; - } else { - bulk_data_toggle[devnum][ep] = - DWC2_HC_PID_DATA0; - } - break; - } - - if (hcint & DWC2_HCINT_STALL) { - puts("DWC OTG: Channel halted\n"); - bulk_data_toggle[devnum][ep] = - DWC2_HC_PID_DATA0; + ret = wait_for_chhltd(&sub, &bulk_data_toggle[devnum][ep]); + if (ret) { + stop_transfer = 1; + break; + } + done += xfer_len; + if (usb_pipein(pipe)) { + done -= sub; + if (sub) stop_transfer = 1; - break; - } - - if (!--timeout) { - printf("%s: Timeout!\n", __func__); - break; - } } } @@ -838,11 +834,8 @@ int submit_control_msg(struct usb_device *dev, unsigned long pipe, void *buffer, int devnum = usb_pipedevice(pipe); int ep = usb_pipeendpoint(pipe); int max = usb_maxpacket(dev, pipe); - uint32_t hctsiz = 0, sub, tmp, ret; - uint32_t hcint; - const uint32_t hcint_comp_hlt_ack = DWC2_HCINT_XFERCOMP | - DWC2_HCINT_CHHLTD | DWC2_HCINT_ACK; - unsigned int timeout = 1000000; + int ret; + uint32_t sub; /* For CONTROL endpoint pid should start with DATA1 */ int status_direction; @@ -878,14 +871,8 @@ int submit_control_msg(struct usb_device *dev, unsigned long pipe, void *buffer, DWC2_HCCHAR_CHEN | DWC2_HCCHAR_CHDIS, (1 << DWC2_HCCHAR_MULTICNT_OFFSET) | DWC2_HCCHAR_CHEN); - ret = wait_for_bit(&hc_regs->hcint, DWC2_HCINT_CHHLTD, 1); - if (ret) - printf("%s: Timeout!\n", __func__); - - hcint = readl(&hc_regs->hcint); - - if (!(hcint & DWC2_HCINT_CHHLTD) || !(hcint & DWC2_HCINT_XFERCOMP)) { - printf("%s: Error (HCINT=%08x)\n", __func__, hcint); + ret = wait_for_chhltd(&sub, NULL); + if (ret) { dev->status = 0; dev->act_len = 0; return -EINVAL; @@ -917,47 +904,16 @@ int submit_control_msg(struct usb_device *dev, unsigned long pipe, void *buffer, (1 << DWC2_HCCHAR_MULTICNT_OFFSET) | DWC2_HCCHAR_CHEN); - while (1) { - hcint = readl(&hc_regs->hcint); - if (!(hcint & DWC2_HCINT_CHHLTD)) - continue; - - if (hcint & DWC2_HCINT_XFERCOMP) { - hctsiz = readl(&hc_regs->hctsiz); - done = len; - - sub = hctsiz & DWC2_HCTSIZ_XFERSIZE_MASK; - sub >>= DWC2_HCTSIZ_XFERSIZE_OFFSET; - - if (usb_pipein(pipe)) - done -= sub; - } - - if (hcint & DWC2_HCINT_ACK) { - tmp = hctsiz & DWC2_HCTSIZ_PID_MASK; - tmp >>= DWC2_HCTSIZ_PID_OFFSET; - if (tmp == DWC2_HC_PID_DATA0) { - control_data_toggle[devnum][ep] = - DWC2_HC_PID_DATA0; - } else { - control_data_toggle[devnum][ep] = - DWC2_HC_PID_DATA1; - } - } - - if (hcint != hcint_comp_hlt_ack) { - printf("%s: Error (HCINT=%08x)\n", - __func__, hcint); - goto out; - } - - if (!--timeout) { - printf("%s: Timeout!\n", __func__); - goto out; - } - - break; + ret = wait_for_chhltd(&sub, &control_data_toggle[devnum][ep]); + if (ret) { + dev->status = 0; + dev->act_len = 0; + return -EINVAL; } + + done = len; + if (usb_pipein(pipe)) + done -= sub; } /* End of DATA stage */ /* STATUS stage */ @@ -980,20 +936,17 @@ int submit_control_msg(struct usb_device *dev, unsigned long pipe, void *buffer, DWC2_HCCHAR_CHEN | DWC2_HCCHAR_CHDIS, (1 << DWC2_HCCHAR_MULTICNT_OFFSET) | DWC2_HCCHAR_CHEN); - while (1) { - hcint = readl(&hc_regs->hcint); - if (hcint & DWC2_HCINT_CHHLTD) - break; + ret = wait_for_chhltd(&sub, NULL); + if (ret) { + dev->status = 0; + dev->act_len = 0; + return -EINVAL; } - if (hcint != hcint_comp_hlt_ack) - printf("%s: Error (HCINT=%08x)\n", __func__, hcint); - -out: dev->act_len = done; dev->status = 0; - return done; + return 0; } int submit_int_msg(struct usb_device *dev, unsigned long pipe, void *buffer, -- 1.9.1

2 6

[U-Boot] [u-boot][PATCH] omap3_beagle: Fix device tree boot
by Roger Quadros 09 Mar '15

09 Mar '15

Don't redefine fdtaddr and other values that are already defined in ti_armv7_common.h. The value of fdtaddr in ti_armv7_common.h is more appropriate as it allows a larger kernel image to be loaded. With this change, I'm able to boot linux-4.0-rc1 with device tree blob. Signed-off-by: Roger Quadros <rogerq(a)ti.com> --- include/configs/omap3_beagle.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index f25a940..3ea9b08 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -129,10 +129,8 @@ /* devices */ #define CONFIG_EXTRA_ENV_SETTINGS \ - "loadaddr=0x80200000\0" \ - "rdaddr=0x81000000\0" \ + DEFAULT_LINUX_BOOT_ENV \ "fdt_high=0xffffffff\0" \ - "fdtaddr=0x80f80000\0" \ "usbtty=cdc_acm\0" \ "bootfile=uImage\0" \ "ramdisk=ramdisk.gz\0" \ -- 2.1.0

2 2

[U-Boot] [PATCH v4 00/14] Add PSCI support for Jetson TK1/Tegra124 + CNTFRQ fix
by Jan Kiszka 09 Mar '15

09 Mar '15

Changes in v4: - rebased over master - fixed a nasty bug in CTNFRQ setting that broke unrelated code - fixed a bug in Tegra's psci_cpu_off that prevented powergating - factored out armv7_get_cpu_id macro - removed duplicate call to psci_arch_init - addressed review comments regarding comments - wait on initial CPU power-down using Flow Controller instead of PMC Jan CC: Ian Campbell <ijc(a)hellion.org.uk> CC: Marc Zyngier <marc.zyngier(a)arm.com> Ian Campbell (3): tegra124: Add more registers to struct mc_ctlr jetson-tk1: Add PSCI configuration options and reserve secure code tegra124: Reserve secure RAM using MC_SECURITY_CFG{0, 1}_0 Jan Kiszka (11): sun7i: Remove duplicate call to psci_arch_init ARM: Factor out armv7_get_cpu_id macro ARM: Factor out reusable psci_cpu_off_common ARM: Factor out reusable psci_cpu_entry ARM: Factor out reusable psci_get_cpu_stack_top ARM: Put target PC for PSCI CPU_ON on per-CPU stack virt-dt: Allow reservation of secure region when in a RAM carveout tegra: Make tegra_powergate_power_on public tegra: Add ap_pm_init hook tegra124: Add PSCI support for Tegra124 tegra: Set CNTFRQ for secondary CPUs arch/arm/cpu/armv7/psci.S | 102 +++++++++++++++++++++++++ arch/arm/cpu/armv7/sunxi/psci.S | 112 +++++---------------------- arch/arm/cpu/armv7/virt-dt.c | 29 +++++++ arch/arm/cpu/armv7/virt-v7.c | 5 ++ arch/arm/include/asm/arch-tegra/ap.h | 5 ++ arch/arm/include/asm/arch-tegra/powergate.h | 1 + arch/arm/include/asm/arch-tegra124/flow.h | 6 ++ arch/arm/include/asm/arch-tegra124/mc.h | 35 ++++++++- arch/arm/include/asm/armv7.h | 1 + arch/arm/include/asm/macro.h | 7 ++ arch/arm/include/asm/system.h | 1 + arch/arm/lib/bootm-fdt.c | 5 ++ arch/arm/mach-tegra/Makefile | 4 + arch/arm/mach-tegra/ap.c | 15 ++++ arch/arm/mach-tegra/powergate.c | 2 +- arch/arm/mach-tegra/psci.S | 114 ++++++++++++++++++++++++++++ arch/arm/mach-tegra/tegra124/Kconfig | 2 + arch/arm/mach-tegra/tegra124/Makefile | 4 + arch/arm/mach-tegra/tegra124/ap.c | 55 ++++++++++++++ board/nvidia/common/board.c | 4 + include/configs/jetson-tk1.h | 5 ++ 21 files changed, 416 insertions(+), 98 deletions(-) create mode 100644 arch/arm/mach-tegra/psci.S create mode 100644 arch/arm/mach-tegra/tegra124/ap.c -- 2.1.4

3 23

[U-Boot] [RFC PATCH 0/7] RFC: dm: Add USB support
by Simon Glass 09 Mar '15

09 Mar '15

This series adds basic driver model support to USB. The intent is to permit the various subsystems (OHCI, EHCI, XHCI) to co-exist and allow any number of USB ports of different types. So far the absolute limit on the number of USB devices is only slightly relaxed. Only USB controllers have a real driver model device. USB devices (including the hub in the controller) are not modelled as driver model devices. This is for two reasons: - it is easier since we don't need to bind a whole lot of devices when scanning - the two main USB devices (block devices and Ethernet) don't have driver mode support yet anyway, so it would be pointless. However the recent network RFC has encouraged me to send this. The basic approach is to set up the driver model structures in parallel to what already exists rather than to replace them. This allows both driver model and legacy to be used for USB, although not with the same board. So far only XHCI is supported. As an example the Exynos XHCI driver is converted to driver model. I would appreciate comments before going further. Caveats: - sandbox code is incomplete and there are no tests - 'usb stop' does not remove existing devices (I have not yet settled on the best approach) - the usb.h changes need to be split correctly into the patches once they are final This series is available at u-boot-dm/usb-working. Simon Glass (7): dm: usb: Add a uclass for USB controllers dm: usb: Support driver model in exynos XHCI dm: usb: Adjust users of the USB stack to work with driver model dm: usb: WIP sandbox USB implementation dm: core: Add a function to get the uclass data for a device arm: Show relocated PC/LR in the register dump dm: exynos: Enable driver model for snow XHCI Makefile | 1 + arch/arm/lib/interrupts.c | 13 +- arch/sandbox/dts/sandbox.dts | 20 +++ arch/sandbox/include/asm/processor.h | 0 common/cmd_usb.c | 74 ++++++++--- common/usb.c | 28 +++-- common/usb_hub.c | 13 +- common/usb_storage.c | 148 +++++++++++++--------- drivers/core/device.c | 10 ++ drivers/usb/dev/Makefile | 10 ++ drivers/usb/dev/sandbox-flash.c | 95 +++++++++++++++ drivers/usb/dev/sandbox-hub.c | 116 ++++++++++++++++++ drivers/usb/dev/usb-emul-uclass.c | 16 +++ drivers/usb/eth/usb_ether.c | 46 +++++-- drivers/usb/host/Makefile | 5 + drivers/usb/host/usb-sandbox.c | 151 +++++++++++++++++++++++ drivers/usb/host/usb-uclass.c | 227 ++++++++++++++++++++++++++++++++++ drivers/usb/host/xhci-exynos5.c | 115 +++++++++++++++++- drivers/usb/host/xhci.c | 229 ++++++++++++++++++++++++++++------- drivers/usb/host/xhci.h | 24 ++++ include/configs/sandbox.h | 3 + include/configs/snow.h | 1 + include/dm/device.h | 10 ++ include/dm/uclass-id.h | 2 + include/usb.h | 76 +++++++++++- include/usb_defs.h | 14 ++- 26 files changed, 1294 insertions(+), 153 deletions(-) create mode 100644 arch/sandbox/include/asm/processor.h create mode 100644 drivers/usb/dev/Makefile create mode 100644 drivers/usb/dev/sandbox-flash.c create mode 100644 drivers/usb/dev/sandbox-hub.c create mode 100644 drivers/usb/dev/usb-emul-uclass.c create mode 100644 drivers/usb/host/usb-sandbox.c create mode 100644 drivers/usb/host/usb-uclass.c -- 2.2.0.rc0.207.ga3a616c

4 20

[U-Boot] [PATCH 0/4] samsung: dwc3: usb: Samsung specific code to handle dwc3
by Lukasz Majewski 09 Mar '15

09 Mar '15

Those patches depend on following commits: For the whole patch set please refer to -dfu u-boot repo, branch (devel/dwc3_gadget): http://git.denx.de/?p=u-boot/u-boot-dfu.git;a=shortlog;h=refs/heads/devel/d… And should be applied on top of them. Inha Song (1): ARM: exynos5420: Add dfu_alt_info board specific callbacks to support DFU download Joonyoung Shim (1): arm: exynos5420: Adding support for board_usb_{init|cleanup}() functions Lukasz Majewski (2): arm: exynos: USB3 PHY base definition for Exynos5 SoCs samsung: usb: phy: Support for DWC3 PHY arch/arm/include/asm/arch-exynos/cpu.h | 2 +- board/samsung/smdk5420/smdk5420.c | 67 +++++++++++++++++++++++++++++ drivers/usb/dwc3/Makefile | 1 + drivers/usb/dwc3/samsung_usb_phy.c | 78 ++++++++++++++++++++++++++++++++++ include/samsung-usb-phy-uboot.h | 16 +++++++ 5 files changed, 163 insertions(+), 1 deletion(-) create mode 100644 drivers/usb/dwc3/samsung_usb_phy.c create mode 100644 include/samsung-usb-phy-uboot.h -- 2.0.0.rc2

2 7

Re: [U-Boot] [PATCH 2/4] sun7i: Add support for the Wits Pro A20 DKT board
by Hans de Goede 08 Mar '15

08 Mar '15

Hi, On 07-03-15 15:05, Hans de Goede wrote: > The Wits Pro A20 DKT is an A20 Development KiT with 1G RAM, 4G NAND, sdio wifi, > 1Gbit ethernet, 1024x768 lcd screen with ft5x_ts touchscreen and a ton of > IO connectors. > > Note there seem to be multiple sdcard slots on the board (4 in total), but > other then mmc0 none of these are hooked up by default, there is a ton of > dip-switches which likely allow hooking some of these up, but the documentation > of the board only describes the use of a fraction of them, so for now we > only support mmc0. > > Also see: http://www.merrii.com/en/pla_d.asp?id=163 > > Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Ugh I forgot to update MAINTAINERS for this and the 2 other new boards (will I ever learn?). I will fix this in my personal tree. Regards, Hans > --- > configs/Wits_Pro_A20_DKT_defconfig | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > create mode 100644 configs/Wits_Pro_A20_DKT_defconfig > > diff --git a/configs/Wits_Pro_A20_DKT_defconfig b/configs/Wits_Pro_A20_DKT_defconfig > new file mode 100644 > index 0000000..de42b3c > --- /dev/null > +++ b/configs/Wits_Pro_A20_DKT_defconfig > @@ -0,0 +1,15 @@ > +CONFIG_SPL=y > +CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_GMAC,RGMII,AHCI,USB_EHCI" > +CONFIG_FDTFILE="sun7i-a20-wits-pro-a20-dkt.dtb" > +CONFIG_VIDEO_LCD_MODE="x:1024,y:768,depth:24,pclk_khz:65000,le:159,ri:160,up:22,lo:15,hs:1,vs:1,sync:3,vmode:0" > +CONFIG_VIDEO_LCD_POWER="PH8" > +CONFIG_VIDEO_LCD_BL_EN="PH7" > +CONFIG_VIDEO_LCD_BL_PWM="PB2" > +CONFIG_VIDEO_LCD_PANEL_LVDS=y > +CONFIG_VIDEO_VGA=y > ++S:CONFIG_ARM=y > ++S:CONFIG_ARCH_SUNXI=y > ++S:CONFIG_MACH_SUN7I=y > ++S:CONFIG_DRAM_CLK=384 > ++S:CONFIG_DRAM_ZQ=127 > ++S:CONFIG_DRAM_EMR1=4 >

2 1

[U-Boot] [PATCH] sun6i: Add support for the Mele I7 board
by codekipper＠gmail.com 08 Mar '15

08 Mar '15

From: Marcus Cooper <codekipper(a)gmail.com> The Mele I7 is a Allwinner based Android TV box. It features a A31 SOC, 1G RAM, 8GB NAND, HDMI out, A/V out, SPDIF, IrDA, 3 USB A, 1 USB micro OTG and Wireless LAN. Signed-off-by: Marcus Cooper <codekipper(a)gmail.com> --- board/sunxi/MAINTAINERS | 5 +++++ configs/Mele_I7_defconfig | 20 ++++++++++++++++++++ 2 files changed, 25 insertions(+) create mode 100644 configs/Mele_I7_defconfig diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index ead09c9..4c167f7 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -100,6 +100,11 @@ M: Aleksei Mamlin <mamlinav(a)gmail.com> S: Maintained F: configs/Marsboard_A10_defconfig +MELE I7 BOARD +M: Marcus Cooper <codekipper(a)gmail.com> +S: Maintained +F: configs/Mele_I7_defconfig + MELE M5 BOARD M: Ian Campbell <ijc(a)hellion.org.uk> S: Maintained diff --git a/configs/Mele_I7_defconfig b/configs/Mele_I7_defconfig new file mode 100644 index 0000000..1046694 --- /dev/null +++ b/configs/Mele_I7_defconfig @@ -0,0 +1,20 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS="USB_EHCI,SUNXI_GMAC" +CONFIG_FDTFILE="sun6i-a31-i7.dtb" ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN6I=y ++S:CONFIG_DRAM_CLK=312 ++S:CONFIG_DRAM_ZQ=120 +# The Mele I7 uses 3.3V for general IO ++S:CONFIG_AXP221_DCDC1_VOLT=3300 +# Ethernet phy power ++S:CONFIG_AXP221_DLDO1_VOLT=3300 +# USB hub power ++S:CONFIG_AXP221_DLDO4_VOLT=3300 +# Wifi power ++S:CONFIG_AXP221_ALDO1_VOLT=3300 +# Vbus gpio for usb1 ++S:CONFIG_USB1_VBUS_PIN="PC27" +# No Vbus gpio for usb2 ++S:CONFIG_USB2_VBUS_PIN="" -- 2.3.1

3 2

[U-Boot] [PATCH] usb: dwc2: fix aligned buffer usage
by Stephen Warren 08 Mar '15

08 Mar '15

The original aligned_buffer usage: a) Uselessly copied data into the aligned buffer even for IN transactions. b) Needlessly split the memcpy() into separate calls per chunk, rather than doing it all at once, as it did for the post-transfer copy for IN transactions. c) Always programmed the HW to transfer to/from the start of the aligned buffer, rather than the location of the start of the current chunk. This worked fine for OUT transactions since the memcpy copied the data to this location. However, for large IN transactions, it resulted in each transfer over-writing the data for the first transfer. This patch assumes that the USB maxpacket is at least 8, so that each chunk of the overall transfer is still aligned to the HW's 8-byte alignment requirement. Signed-off-by: Stephen Warren <swarren(a)wwwdotorg.org> --- drivers/usb/host/dwc2.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index 5a1c44a8fb75..5bb9df86735f 100644 --- a/drivers/usb/host/dwc2.c +++ b/drivers/usb/host/dwc2.c @@ -764,6 +764,9 @@ int chunk_msg(struct usb_device *dev, unsigned long pipe, int *pid, int in, return -EINVAL; } + if (!in) + memcpy(aligned_buffer, (char *)buffer, len); + do { /* Initialize channel */ dwc_otg_hc_init(regs, DWC2_HC_CHANNEL, devnum, ep, in, eptype, @@ -795,8 +798,7 @@ int chunk_msg(struct usb_device *dev, unsigned long pipe, int *pid, int in, (*pid << DWC2_HCTSIZ_PID_OFFSET), &hc_regs->hctsiz); - memcpy(aligned_buffer, (char *)buffer + done, len - done); - writel((uint32_t)aligned_buffer, &hc_regs->hcdma); + writel((uint32_t)&aligned_buffer[done], &hc_regs->hcdma); /* Set host channel enable after all other setup is complete. */ clrsetbits_le32(&hc_regs->hcchar, DWC2_HCCHAR_MULTICNT_MASK | -- 1.9.1

1 1

Re: [U-Boot] [linux-sunxi] [UBOOT] Both Linux-Sunxi and Mainline Uboot have issues
by Siarhei Siamashka 08 Mar '15

08 Mar '15

Hi Tsvetan, On Thu, 19 Feb 2015 14:38:58 +0200 Siarhei Siamashka <siarhei.siamashka(a)gmail.com> wrote: > On Wed, 18 Feb 2015 22:29:07 -0800 (PST) > TsvetanUsunov <tsvetanusunov(a)gmail.com> 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;… > > 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-upda… > > 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_defcon… > http://git.denx.de/?p=u-boot.git;a=blob;f=configs/A20-OLinuXino-Lime_defcon… > > 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? This is just a reminder to say that I'm still very much interested to get a reply. You seem to be assuming that nobody here (and in the upstream U-Boot) is interested in the DRAM settings used on Olimex boards, but this is not quite true. The wiki page at https://www.olimex.com/wiki/A13-OLinuXino now says: "Please note that you might need different Debian Linux images for different boards with different hardware - you would need to inspect the DDR3 RAM memory and use the image suitable for your board. Previously we used HYNIX H5TQ2G83CFR, now we use SAMSUNG K4B2G0846Q. Newest official Debian release (recommended): Torrent of Debian release 11.2 suitable for boards with SAMSUNG K4B2G0846Q DDR3 RAM memory: A13 Debian Linux with kernel 3.4.90+, suitable for boards with SAMSUNG DDR3 RAM Torrent of Debian release 10 suitable for boards with HYNIX H5TQ2G83CFR DDR3 RAM memory: A13 Debian Linux with kernel 3.4.90+, suitable for HYNIX DDR3 RAM". So Olimex is using different DRAM settings for the A13-OLinuXino board, depending on the DRAM chip type. And providing binary images to the end users. SAMSUNG K4B2G0846Q is quite interesting, because it is a family of DDR3 chips supporting speeds ranging from DDR3-1600 to DDR3-2133. And they are only officially backwards compatible with DDR3-1600, but not with anything lower. And we are mostly interested in DDR3-1066 timings. DDR3-1600 specifies 13.75 ns timings for tRCD/tRP, while DDR3-1066F speed bin specifies 13.125 ns. These newer SAMSUNG chips support higher clock frequencies, but have *worse* access latency. I would not be very surprised if this is exactly the source of the reliability problems. So it probably makes sense to use the DDR3-1066G speed bin timings (15 ns) for these chips. This can be done by adding the following line to the A13-OLinuXino defconfig file in U-Boot: +S:CONFIG_DRAM_TIMINGS_DDR3_800E_1066G_1333J=y Additionally, I did a bit of detective work earlier and "interrogated" a user named <TJvV> in the #olimex irc channel: https://www.olimex.com/irc?date=2015-02-24 Appears that these binary images, supplied by Olimex, are indeed using non-default DRAM settings. And an additional observation is that the DCDC3 voltage is set to only 1.2V on this board (down from the default 1.25V configured by U-Boot). The reduced DCDC3 voltage may be responsible for poor reliability at high MBUS and DRAM clock speeds too. To sum it up. It would be great if Olimex better cooperated with the upstream U-Boot and provided the DRAM settings for Olimex boards instead of diverging from the defaults in the custom binary images. IANAL, but some people may even treat the custom DRAM settings tweaks as a sort of GPL violation, unless Olimex provides U-Boot sources somewhere nearby. -- Best regards, Siarhei Siamashka

1 0