Re: [U-Boot] [PATCH v3 0/3] dfu: ram support
Hi Heiko, On Fri, Sep 13, 2013 at 03:44:54PM +0200, Marek Vasut wrote: CCing Heiko, can you please ACK/NAK ? v4 has been posted fixing an issue in this series pointed out by Marek and Gerhard, please review v4 instead. Regards Afzal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] *** [u-boot] Error 139 when config NAND relative setting
Hello, nice to meet everyone. I am new to U-boot development world. i have a s5pv310 soc dk board, and i config. it as origen board. i want to use nand command in u-boot, so i add blow setting in origen.h /*enable nand command*/ #define CONFIG_CMD_NAND #define CONFIG_SYS_MAX_NAND_DEVICE 1 #define CONFIG_SYS_NAND_MAX_CHIPS 1 #define CONFIG_SYS_NAND_SELF_INIT #define CONFIG_SYS_NAND_BASE 0x0CE0 but i got error message about ***[U-boot] Error 139. After searched some solution, some said that Error 139 is the cross compile version is too low. but my cross compile is gcc-arm-none-eabi-4_6-2012q2, i think it is not the version problem. without the nand relative config before i could build u-boot without any problem. could somebody give me some points to fix this error. thanks. ps. i don't know if i could consult building problem here. If u-boot mail-list is not proper to receive building problem please let me know. thanks again. drivers/mtd/nand/libnand.o: In function `nand_init': /usr/v310/uboot_linaro/u-boot-linaro/drivers/mtd/nand/nand.c:104: undefined reference to `board_nand_init' /usr/v310/toolchain/gcc-arm-none-eabi-4_6-2012q2/bin/arm-none-eabi-ld.bfd: BFD (GNU Tools for ARM Embedded Processors) 2.21.1.20120613 assertion fail /home/build/work/jenkins-daily-build/src/binutils/bfd/elf32-arm.c:12274 /usr/v310/toolchain/gcc-arm-none-eabi-4_6-2012q2/bin/arm-none-eabi-ld.bfd: BFD (GNU Tools for ARM Embedded Processors) 2.21.1.20120613 assertion fail /home/build/work/jenkins-daily-build/src/binutils/bfd/elf32-arm.c:12511 /bin/bash: line 1: 3818 Segmentation fault /usr/v310/toolchain/gcc-arm-none-eabi-4_6-2012q2/bin/arm-none-eabi-ld.bfd -pie -T u-boot.lds -Bstatic -Ttext 0x43E0 $UNDEF_LST arch/arm/cpu/armv7/start.o --start-group api/libapi.o arch/arm/cpu/armv7/exynos/libexynos.o arch/arm/cpu/armv7/libarmv7.o arch/arm/cpu/armv7/s5p-common/libs5p-common.o arch/arm/lib/libarm.o board/samsung/common/libsamsung.o common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o drivers/dfu/libdfu.o drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o drivers/usb/ulpi/libusb_ulpi.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o fs/cbfs/libcbfs.o fs/cramfs/libcramfs.o fs/ext4/libext4fs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/libfs.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o fs/zfs/libzfs.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o test/libtest.o board/samsung/origen/liborigen.o --end-group /usr/v310/uboot_linaro/u-boot-linaro/arch/arm/lib/eabi_compat.o -L /usr/v310/toolchain/gcc-arm-none-eabi-4_6-2012q2/bin/../lib/gcc/arm-none-eabi/4.6.2 -lgcc -Map u-boot.map -o u-boot make[1]: *** [u-boot] Error 139 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] omap1510inn: arm925t: remove support
omap1510inn is orphan and has been for years now. Reove it and, as it was the only arm925t target, also remove arm925t support. Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net --- Changes for v2: - rebased after boards.cfg/MAINTAINERS reformating Changes for v1: - initial submission MAKEALL | 1 - README | 1 - arch/arm/cpu/arm925t/Makefile| 34 --- arch/arm/cpu/arm925t/config.mk | 17 -- arch/arm/cpu/arm925t/cpu.c | 50 arch/arm/cpu/arm925t/omap925.c | 23 -- arch/arm/cpu/arm925t/start.S | 382 --- arch/arm/cpu/arm925t/timer.c | 104 - board/ti/omap1510inn/Makefile| 29 --- board/ti/omap1510inn/config.mk | 25 -- board/ti/omap1510inn/lowlevel_init.S | 380 -- board/ti/omap1510inn/omap1510innovator.c | 125 -- boards.cfg | 1 - include/arm925t.h| 11 - include/configs/omap1510inn.h| 166 -- 15 files changed, 1349 deletions(-) delete mode 100644 arch/arm/cpu/arm925t/Makefile delete mode 100644 arch/arm/cpu/arm925t/config.mk delete mode 100644 arch/arm/cpu/arm925t/cpu.c delete mode 100644 arch/arm/cpu/arm925t/omap925.c delete mode 100644 arch/arm/cpu/arm925t/start.S delete mode 100644 arch/arm/cpu/arm925t/timer.c delete mode 100644 board/ti/omap1510inn/Makefile delete mode 100644 board/ti/omap1510inn/config.mk delete mode 100644 board/ti/omap1510inn/lowlevel_init.S delete mode 100644 board/ti/omap1510inn/omap1510innovator.c delete mode 100644 include/arm925t.h delete mode 100644 include/configs/omap1510inn.h diff --git a/MAKEALL b/MAKEALL index c0d04fb..956f3da 100755 --- a/MAKEALL +++ b/MAKEALL @@ -353,7 +353,6 @@ LIST_ARM7=$(boards_by_cpu arm720t) LIST_ARM9=$(boards_by_cpu arm920t)\ $(boards_by_cpu arm926ejs) \ - $(boards_by_cpu arm925t)\ $(boards_by_cpu arm946es) \ diff --git a/README b/README index ccd47fa..0c3da92 100644 --- a/README +++ b/README @@ -139,7 +139,6 @@ Directory Hierarchy: /at91 Files specific to Atmel AT91RM9200 CPU /imxFiles specific to Freescale MC9328 i.MX CPUs /s3c24x0Files specific to Samsung S3C24X0 CPUs - /arm925t Files specific to ARM 925 CPUs /arm926ejs Files specific to ARM 926 CPUs /arm1136 Files specific to ARM 1136 CPUs /ixp Files specific to Intel XScale IXP CPUs diff --git a/arch/arm/cpu/arm925t/Makefile b/arch/arm/cpu/arm925t/Makefile deleted file mode 100644 index 40d2156..000 --- a/arch/arm/cpu/arm925t/Makefile +++ /dev/null @@ -1,34 +0,0 @@ -# -# (C) Copyright 2000-2006 -# Wolfgang Denk, DENX Software Engineering, w...@denx.de. -# -# SPDX-License-Identifier: GPL-2.0+ -# - -include $(TOPDIR)/config.mk - -LIB= $(obj)lib$(CPU).o - -START = start.o - -COBJS += cpu.o -COBJS += omap925.o -COBJS += timer.o - -SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) -OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) -START := $(addprefix $(obj),$(START)) - -all: $(obj).depend $(START) $(LIB) - -$(LIB):$(OBJS) - $(call cmd_link_o_target, $(OBJS)) - -# - -# defines $(obj).depend target -include $(SRCTREE)/rules.mk - -sinclude $(obj).depend - -# diff --git a/arch/arm/cpu/arm925t/config.mk b/arch/arm/cpu/arm925t/config.mk deleted file mode 100644 index 58fd756..000 --- a/arch/arm/cpu/arm925t/config.mk +++ /dev/null @@ -1,17 +0,0 @@ -# -# (C) Copyright 2002 -# Gary Jennejohn, DENX Software Engineering, ga...@denx.de -# -# SPDX-License-Identifier: GPL-2.0+ -# - -PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float - -PLATFORM_CPPFLAGS += -march=armv4 -# = -# -# Supply options according to compiler version -# -# = -PF_RELFLAGS_SLB_AT := $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -PLATFORM_RELFLAGS += $(PF_RELFLAGS_SLB_AT) diff --git a/arch/arm/cpu/arm925t/cpu.c b/arch/arm/cpu/arm925t/cpu.c deleted file mode 100644 index d0f8e1e..000 --- a/arch/arm/cpu/arm925t/cpu.c +++ /dev/null @@ -1,50 +0,0 @@ -/* - * (C) Copyright 2002 - * Sysgo Real-Time Solutions, GmbH www.elinos.com - * Marius Groeger mgroe...@sysgo.de - * - * (C) Copyright 2002 - * Gary Jennejohn, DENX Software Engineering, ga...@denx.de - * - * SPDX-License-Identifier:GPL-2.0+ - */ - -/* - * CPU specific code - */ - -#include common.h -#include command.h -#include arm925t.h -#include asm/system.h - -static void cache_flush(void); - -int
[U-Boot] [PATCH v3 05/10] exynos5: dts: Add COMPAT string data for USB 3.0 PHY and XHCI
Adding required compatible string for xHCI host controller
as well as USB 3.0 PHY to enable dt support for usb 3.0 on
exynos5.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Julius Werner jwer...@chromium.org
Cc: Simon Glass s...@chromium.org
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Dan Murphy dmur...@ti.com
Cc: Marek Vasut ma...@denx.de
---
Changes since v2:
- Nothing.
include/fdtdec.h |2 ++
lib/fdtdec.c |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 6bf83bf..433d6a7 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -73,7 +73,9 @@ enum fdt_compat_id {
COMPAT_GOOGLE_CROS_EC, /* Google CROS_EC Protocol */
COMPAT_GOOGLE_CROS_EC_KEYB, /* Google CROS_EC Keyboard */
COMPAT_SAMSUNG_EXYNOS_EHCI, /* Exynos EHCI controller */
+ COMPAT_SAMSUNG_EXYNOS5_XHCI,/* Exynos5 XHCI controller */
COMPAT_SAMSUNG_EXYNOS_USB_PHY, /* Exynos phy controller for usb2.0 */
+ COMPAT_SAMSUNG_EXYNOS5_USB3_PHY,/* Exynos phy controller for usb3.0 */
COMPAT_SAMSUNG_EXYNOS_TMU, /* Exynos TMU */
COMPAT_SAMSUNG_EXYNOS_FIMD, /* Exynos Display controller */
COMPAT_SAMSUNG_EXYNOS5_DP, /* Exynos Display port controller */
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index dc35856..51fa868 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -46,7 +46,9 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(GOOGLE_CROS_EC, google,cros-ec),
COMPAT(GOOGLE_CROS_EC_KEYB, google,cros-ec-keyb),
COMPAT(SAMSUNG_EXYNOS_EHCI, samsung,exynos-ehci),
+ COMPAT(SAMSUNG_EXYNOS5_XHCI, samsung,exynos5250-xhci),
COMPAT(SAMSUNG_EXYNOS_USB_PHY, samsung,exynos-usb-phy),
+ COMPAT(SAMSUNG_EXYNOS5_USB3_PHY, samsung,exynos5250-usb3-phy),
COMPAT(SAMSUNG_EXYNOS_TMU, samsung,exynos-tmu),
COMPAT(SAMSUNG_EXYNOS_FIMD, samsung,exynos-fimd),
COMPAT(SAMSUNG_EXYNOS5_DP, samsung,exynos5-dp),
--
1.7.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 01/10] usb: Move 'bmRequestType' USB device request macros from EHCI header
Macros defining bmRequestType field of USB device request, given in table 9.2 USB 2.0 spec, are rather generic macros which can be further used by other Host controller stacks. So moving them to usb_defs header. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Julius Werner jwer...@chromium.org Cc: Simon Glass s...@chromium.org Cc: Minkyu Kang mk7.k...@samsung.com Cc: Dan Murphy dmur...@ti.com Cc: Marek Vasut ma...@denx.de --- Changes since v2: - This patch is newly added in this version of the series. drivers/usb/host/ehci.h | 16 include/usb_defs.h | 19 +++ 2 files changed, 19 insertions(+), 16 deletions(-) diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h index bd52afe..3e1c312 100644 --- a/drivers/usb/host/ehci.h +++ b/drivers/usb/host/ehci.h @@ -28,22 +28,6 @@ #define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 2 #endif -/* (shifted) direction/type/recipient from the USB 2.0 spec, table 9.2 */ -#define DeviceRequest \ - ((USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_DEVICE) 8) - -#define DeviceOutRequest \ - ((USB_DIR_OUT | USB_TYPE_STANDARD | USB_RECIP_DEVICE) 8) - -#define InterfaceRequest \ - ((USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_INTERFACE) 8) - -#define EndpointRequest \ - ((USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_INTERFACE) 8) - -#define EndpointOutRequest \ - ((USB_DIR_OUT | USB_TYPE_STANDARD | USB_RECIP_INTERFACE) 8) - /* * Register Space. */ diff --git a/include/usb_defs.h b/include/usb_defs.h index 0cf5f2d..236a5ec 100644 --- a/include/usb_defs.h +++ b/include/usb_defs.h @@ -63,6 +63,25 @@ #define USB_DIR_OUT 0 #define USB_DIR_IN0x80 +/* + * bmRequestType: USB Device Requests, table 9.2 USB 2.0 spec. + * (shifted) direction/type/recipient. + */ +#define DeviceRequest \ + ((USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_DEVICE) 8) + +#define DeviceOutRequest \ + ((USB_DIR_OUT | USB_TYPE_STANDARD | USB_RECIP_DEVICE) 8) + +#define InterfaceRequest \ + ((USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_INTERFACE) 8) + +#define EndpointRequest \ + ((USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_INTERFACE) 8) + +#define EndpointOutRequest \ + ((USB_DIR_OUT | USB_TYPE_STANDARD | USB_RECIP_INTERFACE) 8) + /* Descriptor types */ #define USB_DT_DEVICE0x01 #define USB_DT_CONFIG0x02 -- 1.7.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 00/10] USB: XHCI: Add xHCI host controller stack driver
Based on 'master' branch of u-boot-usb tree. The series also includes patches to support xHCI on exynos5250, including required driver, device tree changes. Changes since V2: - Added patch to move 'bmRequestType' (Table 9-2, Ch9) definitions from EHCI header file to usb_defs.h so that XHCI can also use it: usb: Move 'bmRequestType' USB device request macros from EHCI header - Added patches to rework the Vbus GPIO setup for ehci and xhci in exynos SoCs: exynos: usb: Switch USB VBUS GPIOs to be device tree configured exynos: dts: Add USB VBUS GPIOs to the device tree - Added the top commit history for drivers/usb/host/xhci* of Linux kernel version 3.4 from where the xHCI code was initially imported. - Replaced GPL license with new SPDX license GPL-2.0+. - Moved this asm/io.h file inclusion to xhci.h - Reworked 'return -1' globally to return meaningful error numbers. - Added required comment in common/usb.c for not calling first get_descriptor request for XHCI. Julius Werner (2): exynos: usb: Switch USB VBUS GPIOs to be device tree configured exynos: dts: Add USB VBUS GPIOs to the device tree Vivek Gautam (8): usb: Move 'bmRequestType' USB device request macros from EHCI header USB: xHCI: Add stack support for xHCI USB: XHCI: Add xHCI host controller support for Exynos5 arm: exynos: Add methods to control power to USB 3.0 PHY exynos5: dts: Add COMPAT string data for USB 3.0 PHY and XHCI exynos5: dts: Add device node for XHCI config: arm: exynos5250: Define CONFIG_SYS_CACHELINE_SIZE temp: config: exynos5250: Enable xHCI support for Exynos5 arch/arm/cpu/armv7/exynos/power.c | 22 + arch/arm/dts/exynos5250.dtsi | 12 + arch/arm/include/asm/arch-exynos/cpu.h |8 + arch/arm/include/asm/arch-exynos/power.h |5 + arch/arm/include/asm/arch-exynos/xhci-exynos.h | 88 ++ board/samsung/dts/exynos5250-smdk5250.dts |4 + board/samsung/dts/exynos5250-snow.dts |8 + board/samsung/smdk5250/exynos5-dt.c| 19 - common/usb.c | 33 +- drivers/usb/host/Makefile |4 + drivers/usb/host/ehci-exynos.c | 11 + drivers/usb/host/ehci.h| 16 - drivers/usb/host/xhci-exynos5.c| 327 ++ drivers/usb/host/xhci-mem.c| 720 ++ drivers/usb/host/xhci-ring.c | 939 ++ drivers/usb/host/xhci.c| 1030 +++ drivers/usb/host/xhci.h| 1255 include/configs/exynos5250-dt.h|7 +- include/fdtdec.h |2 + include/linux/usb/dwc3.h | 188 include/usb.h |9 +- include/usb_defs.h | 19 + lib/fdtdec.c |2 + 23 files changed, 4688 insertions(+), 40 deletions(-) create mode 100644 arch/arm/include/asm/arch-exynos/xhci-exynos.h create mode 100644 drivers/usb/host/xhci-exynos5.c create mode 100644 drivers/usb/host/xhci-mem.c create mode 100644 drivers/usb/host/xhci-ring.c create mode 100644 drivers/usb/host/xhci.c create mode 100644 drivers/usb/host/xhci.h create mode 100644 include/linux/usb/dwc3.h -- 1.7.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 06/10] exynos5: dts: Add device node for XHCI
Adding device node for xhci host controller to enable
usb 3.0 on exynos5250.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Julius Werner jwer...@chromium.org
Cc: Simon Glass s...@chromium.org
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Dan Murphy dmur...@ti.com
Cc: Marek Vasut ma...@denx.de
---
Changes since v2:
- Nothing.
arch/arm/dts/exynos5250.dtsi | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi
index 4fff5e3..57be6a7 100644
--- a/arch/arm/dts/exynos5250.dtsi
+++ b/arch/arm/dts/exynos5250.dtsi
@@ -139,6 +139,18 @@
interrupts = 0 130 0;
};
+ xhci@1200 {
+ compatible = samsung,exynos5250-xhci;
+ reg = 0x1200 0x1;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ phy {
+ compatible = samsung,exynos5250-usb3-phy;
+ reg = 0x1210 0x100;
+ };
+ };
+
ehci@1211 {
compatible = samsung,exynos-ehci;
reg = 0x1211 0x100;
--
1.7.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 03/10] USB: XHCI: Add xHCI host controller support for Exynos5
This adds driver layer for xHCI controller in Samsung's exynos5 soc. This interacts with xHCI host controller stack. Signed-off-by: Vikas C Sajjan vikas.saj...@samsung.com Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Julius Werner jwer...@chromium.org Cc: Simon Glass s...@chromium.org Cc: Minkyu Kang mk7.k...@samsung.com Cc: Dan Murphy dmur...@ti.com Cc: Marek Vasut ma...@denx.de --- Changes since v2: - Replaced GPL license with new SPDX license GPL-2.0+. arch/arm/include/asm/arch-exynos/cpu.h |8 + arch/arm/include/asm/arch-exynos/xhci-exynos.h | 88 +++ drivers/usb/host/Makefile |1 + drivers/usb/host/xhci-exynos5.c| 316 include/linux/usb/dwc3.h | 188 ++ 5 files changed, 601 insertions(+), 0 deletions(-) create mode 100644 arch/arm/include/asm/arch-exynos/xhci-exynos.h create mode 100644 drivers/usb/host/xhci-exynos5.c create mode 100644 include/linux/usb/dwc3.h diff --git a/arch/arm/include/asm/arch-exynos/cpu.h b/arch/arm/include/asm/arch-exynos/cpu.h index cb924fb..0d2b511 100644 --- a/arch/arm/include/asm/arch-exynos/cpu.h +++ b/arch/arm/include/asm/arch-exynos/cpu.h @@ -50,6 +50,8 @@ #define EXYNOS4_SPI_ISP_BASE DEVICE_NOT_AVAILABLE #define EXYNOS4_ACE_SFR_BASE DEVICE_NOT_AVAILABLE #define EXYNOS4_DMC_PHY_BASE DEVICE_NOT_AVAILABLE +#define EXYNOS4_USB_HOST_XHCI_BASE DEVICE_NOT_AVAILABLE +#define EXYNOS4_USB3PHY_BASE DEVICE_NOT_AVAILABLE /* EXYNOS4X12 */ #define EXYNOS4X12_GPIO_PART3_BASE 0x0386 @@ -85,6 +87,8 @@ #define EXYNOS4X12_SPI_ISP_BASEDEVICE_NOT_AVAILABLE #define EXYNOS4X12_ACE_SFR_BASEDEVICE_NOT_AVAILABLE #define EXYNOS4X12_DMC_PHY_BASEDEVICE_NOT_AVAILABLE +#define EXYNOS4X12_USB_HOST_XHCI_BASE DEVICE_NOT_AVAILABLE +#define EXYNOS4X12_USB3PHY_BASEDEVICE_NOT_AVAILABLE /* EXYNOS5 Common*/ #define EXYNOS5_I2C_SPACING0x1 @@ -103,6 +107,8 @@ #define EXYNOS5_DMC_CTRL_BASE 0x10DD #define EXYNOS5_GPIO_PART1_BASE0x1140 #define EXYNOS5_MIPI_DSIM_BASE 0x11D0 +#define EXYNOS5_USB_HOST_XHCI_BASE 0x1200 +#define EXYNOS5_USB3PHY_BASE 0x1210 #define EXYNOS5_USB_HOST_EHCI_BASE 0x1211 #define EXYNOS5_USBPHY_BASE0x1213 #define EXYNOS5_USBOTG_BASE0x1214 @@ -217,7 +223,9 @@ SAMSUNG_BASE(swreset, SWRESET) SAMSUNG_BASE(timer, PWMTIMER_BASE) SAMSUNG_BASE(uart, UART_BASE) SAMSUNG_BASE(usb_phy, USBPHY_BASE) +SAMSUNG_BASE(usb3_phy, USB3PHY_BASE) SAMSUNG_BASE(usb_ehci, USB_HOST_EHCI_BASE) +SAMSUNG_BASE(usb_xhci, USB_HOST_XHCI_BASE) SAMSUNG_BASE(usb_otg, USBOTG_BASE) SAMSUNG_BASE(watchdog, WATCHDOG_BASE) SAMSUNG_BASE(power, POWER_BASE) diff --git a/arch/arm/include/asm/arch-exynos/xhci-exynos.h b/arch/arm/include/asm/arch-exynos/xhci-exynos.h new file mode 100644 index 000..92b90a4 --- /dev/null +++ b/arch/arm/include/asm/arch-exynos/xhci-exynos.h @@ -0,0 +1,88 @@ +/* Copyright (c) 2012 Samsung Electronics Co. Ltd + * + * Exynos Phy register definitions + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#ifndef _ASM_ARCH_XHCI_EXYNOS_H_ +#define _ASM_ARCH_XHCI_EXYNOS_H_ + +/* Phy register MACRO definitions */ + +#define LINKSYSTEM_FLADJ_MASK (0x3f 1) +#define LINKSYSTEM_FLADJ(_x) ((_x) 1) +#define LINKSYSTEM_XHCI_VERSION_CONTROL(0x1 27) + +#define PHYUTMI_OTGDISABLE (1 6) +#define PHYUTMI_FORCESUSPEND (1 1) +#define PHYUTMI_FORCESLEEP (1 0) + +#define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff 23) +#define PHYCLKRST_SSC_REFCLKSEL(_x)((_x) 23) + +#define PHYCLKRST_SSC_RANGE_MASK (0x03 21) +#define PHYCLKRST_SSC_RANGE(_x)((_x) 21) + +#define PHYCLKRST_SSC_EN (0x1 20) +#define PHYCLKRST_REF_SSP_EN (0x1 19) +#define PHYCLKRST_REF_CLKDIV2 (0x1 18) + +#define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f 11) +#define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 11) +#define PHYCLKRST_MPLL_MULTIPLIER_50M_REF (0x02 11) +#define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF(0x68 11) +#define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF(0x7d 11) +#define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 11) + +#define PHYCLKRST_FSEL_MASK(0x3f 5) +#define PHYCLKRST_FSEL(_x) ((_x) 5) +#define PHYCLKRST_FSEL_PAD_100MHZ (0x27 5) +#define PHYCLKRST_FSEL_PAD_24MHZ (0x2a 5) +#define PHYCLKRST_FSEL_PAD_20MHZ (0x31 5) +#define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 5) + +#define PHYCLKRST_RETENABLEN (0x1 4) + +#define PHYCLKRST_REFCLKSEL_MASK (0x03 2) +#define
[U-Boot] [PATCH v3 04/10] arm: exynos: Add methods to control power to USB 3.0 PHY
Adding methods to turn on/off power to USB3.0 type PHY
as and when required by the controller.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Julius Werner jwer...@chromium.org
Cc: Simon Glass s...@chromium.org
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Dan Murphy dmur...@ti.com
Cc: Marek Vasut ma...@denx.de
---
Changes since v2:
- Nothing.
arch/arm/cpu/armv7/exynos/power.c| 22 ++
arch/arm/include/asm/arch-exynos/power.h |5 +
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/power.c
b/arch/arm/cpu/armv7/exynos/power.c
index 517e804..563abd7 100644
--- a/arch/arm/cpu/armv7/exynos/power.c
+++ b/arch/arm/cpu/armv7/exynos/power.c
@@ -59,6 +59,28 @@ void set_usbhost_phy_ctrl(unsigned int enable)
exynos5_set_usbhost_phy_ctrl(enable);
}
+static void exynos5_set_usbdrd_phy_ctrl(unsigned int enable)
+{
+ struct exynos5_power *power =
+ (struct exynos5_power *)samsung_get_base_power();
+
+ if (enable) {
+ /* Enabling USBDRD_PHY */
+ setbits_le32(power-usbdrd_phy_control,
+ POWER_USB_DRD_PHY_CTRL_EN);
+ } else {
+ /* Disabling USBDRD_PHY */
+ clrbits_le32(power-usbdrd_phy_control,
+ POWER_USB_DRD_PHY_CTRL_EN);
+ }
+}
+
+void set_usbdrd_phy_ctrl(unsigned int enable)
+{
+ if (cpu_is_exynos5())
+ exynos5_set_usbdrd_phy_ctrl(enable);
+}
+
static void exynos5_dp_phy_control(unsigned int enable)
{
unsigned int cfg;
diff --git a/arch/arm/include/asm/arch-exynos/power.h
b/arch/arm/include/asm/arch-exynos/power.h
index 3241327..8db18c5 100644
--- a/arch/arm/include/asm/arch-exynos/power.h
+++ b/arch/arm/include/asm/arch-exynos/power.h
@@ -847,6 +847,11 @@ void set_hw_thermal_trip(void);
#define POWER_USB_HOST_PHY_CTRL_EN (1 0)
#define POWER_USB_HOST_PHY_CTRL_DISABLE(0 0)
+void set_usbdrd_phy_ctrl(unsigned int enable);
+
+#define POWER_USB_DRD_PHY_CTRL_EN (1 0)
+#define POWER_USB_DRD_PHY_CTRL_DISABLE (0 0)
+
void set_dp_phy_ctrl(unsigned int enable);
#define EXYNOS_DP_PHY_ENABLE (1 0)
--
1.7.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 07/10] config: arm: exynos5250: Define CONFIG_SYS_CACHELINE_SIZE
XHCI stack driver needs this to align buffers to CacheLine boundary. So define the same to be '64' Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Julius Werner jwer...@chromium.org Cc: Simon Glass s...@chromium.org Cc: Minkyu Kang mk7.k...@samsung.com Cc: Dan Murphy dmur...@ti.com Cc: Marek Vasut ma...@denx.de --- Changes since v2: - Nothing include/configs/exynos5250-dt.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index 8f8f85f..86d57e3 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -37,6 +37,8 @@ /* Keep L2 Cache Disabled */ #define CONFIG_SYS_DCACHE_OFF +#define CONFIG_SYS_CACHELINE_SIZE 64 + /* Enable ACE acceleration for SHA1 and SHA256 */ #define CONFIG_EXYNOS_ACE_SHA #define CONFIG_SHA_HW_ACCEL -- 1.7.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 08/10] temp: config: exynos5250: Enable xHCI support for Exynos5
This enables support for xHCI host controller on Exynos5 and further disables EHCI support, to make sure only one host controller is enabled at a time, since right now using two controllers at a time is not possible with current usb core infrastructure. Anyone who wants to enable EHCI support again needs to enable CONFIG_USB_EHCI, CONFIG_USB_EHCI_EXYNOS once again in exynos5-dt config. Signed-off-by: Vikas C Sajjan vikas.saj...@samsung.com Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Julius Werner jwer...@chromium.org Cc: Simon Glass s...@chromium.org Cc: Minkyu Kang mk7.k...@samsung.com Cc: Dan Murphy dmur...@ti.com Cc: Marek Vasut ma...@denx.de --- Changes since v2: - Eliminating the EHCI configs rather than just commenting them. include/configs/exynos5250-dt.h |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index 86d57e3..e3fb519 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -134,8 +134,9 @@ /* USB */ #define CONFIG_CMD_USB -#define CONFIG_USB_EHCI -#define CONFIG_USB_EHCI_EXYNOS +#define CONFIG_USB_XHCI +#define CONFIG_USB_XHCI_EXYNOS +#define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS 2 #define CONFIG_USB_STORAGE /* USB boot mode */ -- 1.7.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 10/10] exynos: dts: Add USB VBUS GPIOs to the device tree
From: Julius Werner jwer...@chromium.org
This patch adds a new samsung,vbus-gpio parameter to the device tree, in
preparation of replacing the currently hardcoded VBUS GPIO mechanism in
exynos5-dt.c with a device tree controlled solution, just as it already
exists in the Linux kernel.
Signed-off-by: Julius Werner jwer...@chromium.org
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Simon Glass s...@chromium.org
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Marek Vasut ma...@denx.de
---
Changes since v2:
- This patch is newly added in this version of the series.
board/samsung/dts/exynos5250-smdk5250.dts |4
board/samsung/dts/exynos5250-snow.dts |8
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/board/samsung/dts/exynos5250-smdk5250.dts
b/board/samsung/dts/exynos5250-smdk5250.dts
index 1e94c7f..6d6b0ba 100644
--- a/board/samsung/dts/exynos5250-smdk5250.dts
+++ b/board/samsung/dts/exynos5250-smdk5250.dts
@@ -145,4 +145,8 @@
mmc@1223 {
status = disabled;
};
+
+ ehci@1211 {
+ samsung,vbus-gpio = gpio 0xbe 0; /* X26 */
+ };
};
diff --git a/board/samsung/dts/exynos5250-snow.dts
b/board/samsung/dts/exynos5250-snow.dts
index 7832e4e..e023661 100644
--- a/board/samsung/dts/exynos5250-snow.dts
+++ b/board/samsung/dts/exynos5250-snow.dts
@@ -109,6 +109,14 @@
status = disabled;
};
+ ehci@1211 {
+ samsung,vbus-gpio = gpio 0xb1 0; /* X11 */
+ };
+
+ xhci@1200 {
+ samsung,vbus-gpio = gpio 0xbf 0; /* X27 */
+ };
+
tmu@1006 {
samsung,min-temp= 25;
samsung,max-temp= 125;
--
1.7.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 09/10] exynos: usb: Switch USB VBUS GPIOs to be device tree configured
From: Julius Werner jwer...@chromium.org
Some Exynos boards, such as the SMDK5250, control USB port power through
a GPIO pin. For now this had been hardcoded in the exynos5-dt board
file, but not all boards use the same pin, requiring local changes to
support different boards.
This patch moves the GPIO initialization into the USB host controller
drivers which they belong to, and uses the samsung,vbus-gpio parameter
in the device tree to configure it.
Signed-off-by: Julius Werner jwer...@chromium.org
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Simon Glass s...@chromium.org
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Marek Vasut ma...@denx.de
---
Changes since v2:
- This patch is newly added in this version of the series.
board/samsung/smdk5250/exynos5-dt.c | 19 ---
drivers/usb/host/ehci-exynos.c | 11 +++
drivers/usb/host/xhci-exynos5.c | 11 +++
3 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/board/samsung/smdk5250/exynos5-dt.c
b/board/samsung/smdk5250/exynos5-dt.c
index bb4a82f..6bcc883 100644
--- a/board/samsung/smdk5250/exynos5-dt.c
+++ b/board/samsung/smdk5250/exynos5-dt.c
@@ -61,22 +61,6 @@ struct local_info {
static struct local_info local;
-#ifdef CONFIG_USB_EHCI_EXYNOS
-int board_usb_vbus_init(void)
-{
- struct exynos5_gpio_part1 *gpio1 = (struct exynos5_gpio_part1 *)
- samsung_get_base_gpio_part1();
-
- /* Enable VBUS power switch */
- s5p_gpio_direction_output(gpio1-x2, 6, 1);
-
- /* VBUS turn ON time */
- mdelay(3);
-
- return 0;
-}
-#endif
-
#ifdef CONFIG_SOUND_MAX98095
static void board_enable_audio_codec(void)
{
@@ -122,9 +106,6 @@ int board_init(void)
if (board_init_cros_ec_devices(gd-fdt_blob))
return -1;
-#ifdef CONFIG_USB_EHCI_EXYNOS
- board_usb_vbus_init();
-#endif
#ifdef CONFIG_SOUND_MAX98095
board_enable_audio_codec();
#endif
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 155677e..15926c4 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -16,6 +16,7 @@
#include asm/arch/ehci.h
#include asm/arch/system.h
#include asm/arch/power.h
+#include asm/gpio.h
#include asm-generic/errno.h
#include linux/compat.h
#include ehci.h
@@ -30,6 +31,7 @@ DECLARE_GLOBAL_DATA_PTR;
struct exynos_ehci {
struct exynos_usb_phy *usb;
struct ehci_hccr *hcd;
+ struct fdt_gpio_state vbus_gpio;
};
static struct exynos_ehci exynos;
@@ -58,6 +60,9 @@ static int exynos_usb_parse_dt(const void *blob, struct
exynos_ehci *exynos)
exynos-hcd = (struct ehci_hccr *)addr;
+ /* Vbus gpio */
+ fdtdec_decode_gpio(blob, node, samsung,vbus-gpio, exynos-vbus_gpio);
+
depth = 0;
node = fdtdec_next_compatible_subnode(blob, node,
COMPAT_SAMSUNG_EXYNOS_USB_PHY, depth);
@@ -150,6 +155,12 @@ int ehci_hcd_init(int index, struct ehci_hccr **hccr,
struct ehci_hcor **hcor)
ctx-hcd = (struct ehci_hccr *)samsung_get_base_usb_ehci();
#endif
+#ifdef CONFIG_OF_CONTROL
+ /* setup the Vbus gpio here */
+ if (!fdtdec_setup_gpio(ctx-vbus_gpio))
+ gpio_direction_output(ctx-vbus_gpio.gpio, 1);
+#endif
+
setup_usb_phy(ctx-usb);
*hccr = ctx-hcd;
diff --git a/drivers/usb/host/xhci-exynos5.c b/drivers/usb/host/xhci-exynos5.c
index eb0ef6c..1146d10 100644
--- a/drivers/usb/host/xhci-exynos5.c
+++ b/drivers/usb/host/xhci-exynos5.c
@@ -22,6 +22,7 @@
#include asm/arch/cpu.h
#include asm/arch/power.h
#include asm/arch/xhci-exynos.h
+#include asm/gpio.h
#include asm-generic/errno.h
#include linux/compat.h
#include linux/usb/dwc3.h
@@ -39,6 +40,7 @@ struct exynos_xhci {
struct exynos_usb3_phy *usb3_phy;
struct xhci_hccr *hcd;
struct dwc3 *dwc3_reg;
+ struct fdt_gpio_state vbus_gpio;
};
static struct exynos_xhci exynos;
@@ -66,6 +68,9 @@ static int exynos_usb3_parse_dt(const void *blob, struct
exynos_xhci *exynos)
}
exynos-hcd = (struct xhci_hccr *)addr;
+ /* Vbus gpio */
+ fdtdec_decode_gpio(blob, node, samsung,vbus-gpio, exynos-vbus_gpio);
+
depth = 0;
node = fdtdec_next_compatible_subnode(blob, node,
COMPAT_SAMSUNG_EXYNOS5_USB3_PHY, depth);
@@ -291,6 +296,12 @@ int xhci_hcd_init(int index, struct xhci_hccr **hccr,
struct xhci_hcor **hcor)
ctx-dwc3_reg = (struct dwc3 *)((char *)(ctx-hcd) + DWC3_REG_OFFSET);
+#ifdef CONFIG_OF_CONTROL
+ /* setup the Vbus gpio here */
+ if (!fdtdec_setup_gpio(ctx-vbus_gpio))
+ gpio_direction_output(ctx-vbus_gpio.gpio, 1);
+#endif
+
ret = exynos_xhci_core_init(ctx);
if (ret) {
puts(XHCI: failed to initialize controller\n);
--
1.7.6.5
___
U-Boot mailing
Re: [U-Boot] [PATCH v2] omap1510inn: arm925t: remove support
Dear Albert, In message 1379146985-21134-1-git-send-email-albert.u.b...@aribaud.net you wrote: omap1510inn is orphan and has been for years now. Reove it and, as it was the only arm925t target, also remove arm925t support. Thanks - but please also add an entry to doc/README.scrapyard (and please also insert the commit ID for the CANBT board while you are at it). Thanks! 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 Here is an Appalachian version of management's answer to those who are concerned with the fate of the project: Don't worry about the mule. Just load the wagon. - Mike Dennison's hillbilly uncle ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/10] USB: XHCI: Add xHCI host controller stack driver
+ Marek, Dan, Julius, Simon and Vikas for this cover patch ;-) On Sat, Sep 14, 2013 at 2:02 PM, Vivek Gautam gautam.vi...@samsung.com wrote: Based on 'master' branch of u-boot-usb tree. The series also includes patches to support xHCI on exynos5250, including required driver, device tree changes. Changes since V2: - Added patch to move 'bmRequestType' (Table 9-2, Ch9) definitions from EHCI header file to usb_defs.h so that XHCI can also use it: usb: Move 'bmRequestType' USB device request macros from EHCI header - Added patches to rework the Vbus GPIO setup for ehci and xhci in exynos SoCs: exynos: usb: Switch USB VBUS GPIOs to be device tree configured exynos: dts: Add USB VBUS GPIOs to the device tree - Added the top commit history for drivers/usb/host/xhci* of Linux kernel version 3.4 from where the xHCI code was initially imported. - Replaced GPL license with new SPDX license GPL-2.0+. - Moved this asm/io.h file inclusion to xhci.h - Reworked 'return -1' globally to return meaningful error numbers. - Added required comment in common/usb.c for not calling first get_descriptor request for XHCI. Julius Werner (2): exynos: usb: Switch USB VBUS GPIOs to be device tree configured exynos: dts: Add USB VBUS GPIOs to the device tree Vivek Gautam (8): usb: Move 'bmRequestType' USB device request macros from EHCI header USB: xHCI: Add stack support for xHCI USB: XHCI: Add xHCI host controller support for Exynos5 arm: exynos: Add methods to control power to USB 3.0 PHY exynos5: dts: Add COMPAT string data for USB 3.0 PHY and XHCI exynos5: dts: Add device node for XHCI config: arm: exynos5250: Define CONFIG_SYS_CACHELINE_SIZE temp: config: exynos5250: Enable xHCI support for Exynos5 arch/arm/cpu/armv7/exynos/power.c | 22 + arch/arm/dts/exynos5250.dtsi | 12 + arch/arm/include/asm/arch-exynos/cpu.h |8 + arch/arm/include/asm/arch-exynos/power.h |5 + arch/arm/include/asm/arch-exynos/xhci-exynos.h | 88 ++ board/samsung/dts/exynos5250-smdk5250.dts |4 + board/samsung/dts/exynos5250-snow.dts |8 + board/samsung/smdk5250/exynos5-dt.c| 19 - common/usb.c | 33 +- drivers/usb/host/Makefile |4 + drivers/usb/host/ehci-exynos.c | 11 + drivers/usb/host/ehci.h| 16 - drivers/usb/host/xhci-exynos5.c| 327 ++ drivers/usb/host/xhci-mem.c| 720 ++ drivers/usb/host/xhci-ring.c | 939 ++ drivers/usb/host/xhci.c| 1030 +++ drivers/usb/host/xhci.h| 1255 include/configs/exynos5250-dt.h|7 +- include/fdtdec.h |2 + include/linux/usb/dwc3.h | 188 include/usb.h |9 +- include/usb_defs.h | 19 + lib/fdtdec.c |2 + 23 files changed, 4688 insertions(+), 40 deletions(-) create mode 100644 arch/arm/include/asm/arch-exynos/xhci-exynos.h create mode 100644 drivers/usb/host/xhci-exynos5.c create mode 100644 drivers/usb/host/xhci-mem.c create mode 100644 drivers/usb/host/xhci-ring.c create mode 100644 drivers/usb/host/xhci.c create mode 100644 drivers/usb/host/xhci.h create mode 100644 include/linux/usb/dwc3.h -- 1.7.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Best Regards Vivek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND] gpio: spear_gpio: Fix gpio_set_value() implementation
Hi Axel,
On Fri, 06 Sep 2013 14:22:40 +0800, Axel Lin axel@ingics.com
wrote:
In current gpio_set_value() implementation, it always sets the gpio control
bit
no matter the value argument is 0 or 1. Thus the GPIOs never set to low.
This patch fixes this bug.
Signed-off-by: Axel Lin axel@ingics.com
Acked-by: Stefan Roese s...@denx.de
Reviewed-by: Vipin Kumar vipin.ku...@st.com
---
This patch was sent on
http://lists.denx.de/pipermail/u-boot/2013-June/156861.html
Has Stefan's Ack:
http://lists.denx.de/pipermail/u-boot/2013-June/156864.html
Vipin says the code is fine, so I add Vipin's review-by.
http://lists.denx.de/pipermail/u-boot/2013-June/156966.html
Michael confirms it works:
http://lists.denx.de/pipermail/u-boot/2013-August/160652.html
No body picks up this patch, so here is a resend.
Although I think this is a bug fix, but I'll let maintainers to determinate
if this is the material for v2013.10.
Anyway, can someone at least let me know if this patch is ok for apply at some
point? I have no idea who is maintaining this file.
Regards,
Axel
drivers/gpio/spear_gpio.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/spear_gpio.c b/drivers/gpio/spear_gpio.c
index 367b670..6fb4117 100644
--- a/drivers/gpio/spear_gpio.c
+++ b/drivers/gpio/spear_gpio.c
@@ -36,7 +36,10 @@ int gpio_set_value(unsigned gpio, int value)
{
struct gpio_regs *regs = (struct gpio_regs *)CONFIG_GPIO_BASE;
- writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
+ if (value)
+ writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
+ else
+ writel(0, regs-gpiodata[DATA_REG_ADDR(gpio)]);
return 0;
}
Despite discussions in the previous thread and the confirmations that
this code is functionally equivalent to the Linux code, I still believe
this code is incorrect for both writing and reading.
From the doc, writing to GPIODATA will obviously copy each of bits 7
to 0 of the written value into the actuals GPIO mapped to bits 7 to
0 of this register (assuming they are configured as outputs, of course).
Based on this, the code above:
- when setting a single GPIO, sets *but clears up to seven other GPIOs*;
- when clearing a single GPIO, clears it *and up to seven other GPIOs*.
This code may have been tested only for a single active GPIO at a time,
for which this code would behave correctly; but as soon as two GPIOs
from the same bank must be set at the same time, it fails.
Please fix this code so that setting or clearing a GPIO does not set or
clear any other GPIO, and perform an actual test to confirm this works
before submitting V2.
BTW: if (as the previous thread seemed to imply) no one around has the
hardware to test this change, then why exactly is it needed?
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND] gpio: spear_gpio: Fix gpio_set_value() implementation
Hi Albert
On Sat, Sep 14, 2013 at 11:10 AM, Albert ARIBAUD
albert.u.b...@aribaud.net wrote:
Hi Axel,
On Fri, 06 Sep 2013 14:22:40 +0800, Axel Lin axel@ingics.com
wrote:
In current gpio_set_value() implementation, it always sets the gpio control
bit
no matter the value argument is 0 or 1. Thus the GPIOs never set to low.
This patch fixes this bug.
Signed-off-by: Axel Lin axel@ingics.com
Acked-by: Stefan Roese s...@denx.de
Reviewed-by: Vipin Kumar vipin.ku...@st.com
---
This patch was sent on
http://lists.denx.de/pipermail/u-boot/2013-June/156861.html
Has Stefan's Ack:
http://lists.denx.de/pipermail/u-boot/2013-June/156864.html
Vipin says the code is fine, so I add Vipin's review-by.
http://lists.denx.de/pipermail/u-boot/2013-June/156966.html
Michael confirms it works:
http://lists.denx.de/pipermail/u-boot/2013-August/160652.html
No body picks up this patch, so here is a resend.
Although I think this is a bug fix, but I'll let maintainers to determinate
if this is the material for v2013.10.
Anyway, can someone at least let me know if this patch is ok for apply at
some
point? I have no idea who is maintaining this file.
Regards,
Axel
drivers/gpio/spear_gpio.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/spear_gpio.c b/drivers/gpio/spear_gpio.c
index 367b670..6fb4117 100644
--- a/drivers/gpio/spear_gpio.c
+++ b/drivers/gpio/spear_gpio.c
@@ -36,7 +36,10 @@ int gpio_set_value(unsigned gpio, int value)
{
struct gpio_regs *regs = (struct gpio_regs *)CONFIG_GPIO_BASE;
- writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
+ if (value)
+ writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
+ else
+ writel(0, regs-gpiodata[DATA_REG_ADDR(gpio)]);
return 0;
}
Despite discussions in the previous thread and the confirmations that
this code is functionally equivalent to the Linux code, I still believe
this code is incorrect for both writing and reading.
From the doc, writing to GPIODATA will obviously copy each of bits 7
to 0 of the written value into the actuals GPIO mapped to bits 7 to
0 of this register (assuming they are configured as outputs, of course).
Based on this, the code above:
As I understand from the documentation (read some weeks ago),
it uses the address in clear operation not only the value
Michael
- when setting a single GPIO, sets *but clears up to seven other GPIOs*;
- when clearing a single GPIO, clears it *and up to seven other GPIOs*.
This code may have been tested only for a single active GPIO at a time,
for which this code would behave correctly; but as soon as two GPIOs
from the same bank must be set at the same time, it fails.
Please fix this code so that setting or clearing a GPIO does not set or
clear any other GPIO, and perform an actual test to confirm this works
before submitting V2.
BTW: if (as the previous thread seemed to imply) no one around has the
hardware to test this change, then why exactly is it needed?
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND] gpio: spear_gpio: Fix gpio_set_value() implementation
2013/9/14 Albert ARIBAUD albert.u.b...@aribaud.net:
Hi Axel,
On Fri, 06 Sep 2013 14:22:40 +0800, Axel Lin axel@ingics.com
wrote:
In current gpio_set_value() implementation, it always sets the gpio control
bit
no matter the value argument is 0 or 1. Thus the GPIOs never set to low.
This patch fixes this bug.
Signed-off-by: Axel Lin axel@ingics.com
Acked-by: Stefan Roese s...@denx.de
Reviewed-by: Vipin Kumar vipin.ku...@st.com
---
This patch was sent on
http://lists.denx.de/pipermail/u-boot/2013-June/156861.html
Has Stefan's Ack:
http://lists.denx.de/pipermail/u-boot/2013-June/156864.html
Vipin says the code is fine, so I add Vipin's review-by.
http://lists.denx.de/pipermail/u-boot/2013-June/156966.html
Michael confirms it works:
http://lists.denx.de/pipermail/u-boot/2013-August/160652.html
No body picks up this patch, so here is a resend.
Although I think this is a bug fix, but I'll let maintainers to determinate
if this is the material for v2013.10.
Anyway, can someone at least let me know if this patch is ok for apply at
some
point? I have no idea who is maintaining this file.
Regards,
Axel
drivers/gpio/spear_gpio.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/spear_gpio.c b/drivers/gpio/spear_gpio.c
index 367b670..6fb4117 100644
--- a/drivers/gpio/spear_gpio.c
+++ b/drivers/gpio/spear_gpio.c
@@ -36,7 +36,10 @@ int gpio_set_value(unsigned gpio, int value)
{
struct gpio_regs *regs = (struct gpio_regs *)CONFIG_GPIO_BASE;
- writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
+ if (value)
+ writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
+ else
+ writel(0, regs-gpiodata[DATA_REG_ADDR(gpio)]);
return 0;
}
Despite discussions in the previous thread and the confirmations that
this code is functionally equivalent to the Linux code, I still believe
this code is incorrect for both writing and reading.
From the doc, writing to GPIODATA will obviously copy each of bits 7
to 0 of the written value into the actuals GPIO mapped to bits 7 to
0 of this register (assuming they are configured as outputs, of course).
Based on this, the code above:
- when setting a single GPIO, sets *but clears up to seven other GPIOs*;
- when clearing a single GPIO, clears it *and up to seven other GPIOs*.
This code may have been tested only for a single active GPIO at a time,
for which this code would behave correctly; but as soon as two GPIOs
from the same bank must be set at the same time, it fails.
Please fix this code so that setting or clearing a GPIO does not set or
clear any other GPIO, and perform an actual test to confirm this works
before submitting V2.
No.
Some people (Marek, and *Michael*) asked this question in original
discussion thread.
The datasheet says each GPIO is controlled by *different* register.
(Well, it's unusual.)
And that is why we don't need a read-write-update operation.
Simply write 0 to the register does work. ( *Michael* replied it works )
BTW: if (as the previous thread seemed to imply) no one around has the
hardware to test this change, then why exactly is it needed?
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND] gpio: spear_gpio: Fix gpio_set_value() implementation
Hi Axel
On Sat, Sep 14, 2013 at 11:34 AM, Axel Lin axel@ingics.com wrote:
2013/9/14 Albert ARIBAUD albert.u.b...@aribaud.net:
Hi Axel,
On Fri, 06 Sep 2013 14:22:40 +0800, Axel Lin axel@ingics.com
wrote:
In current gpio_set_value() implementation, it always sets the gpio control
bit
no matter the value argument is 0 or 1. Thus the GPIOs never set to low.
This patch fixes this bug.
Signed-off-by: Axel Lin axel@ingics.com
Acked-by: Stefan Roese s...@denx.de
Reviewed-by: Vipin Kumar vipin.ku...@st.com
---
This patch was sent on
http://lists.denx.de/pipermail/u-boot/2013-June/156861.html
Has Stefan's Ack:
http://lists.denx.de/pipermail/u-boot/2013-June/156864.html
Vipin says the code is fine, so I add Vipin's review-by.
http://lists.denx.de/pipermail/u-boot/2013-June/156966.html
Michael confirms it works:
http://lists.denx.de/pipermail/u-boot/2013-August/160652.html
No body picks up this patch, so here is a resend.
Although I think this is a bug fix, but I'll let maintainers to determinate
if this is the material for v2013.10.
Anyway, can someone at least let me know if this patch is ok for apply at
some
point? I have no idea who is maintaining this file.
Regards,
Axel
drivers/gpio/spear_gpio.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/spear_gpio.c b/drivers/gpio/spear_gpio.c
index 367b670..6fb4117 100644
--- a/drivers/gpio/spear_gpio.c
+++ b/drivers/gpio/spear_gpio.c
@@ -36,7 +36,10 @@ int gpio_set_value(unsigned gpio, int value)
{
struct gpio_regs *regs = (struct gpio_regs *)CONFIG_GPIO_BASE;
- writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
+ if (value)
+ writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
+ else
+ writel(0, regs-gpiodata[DATA_REG_ADDR(gpio)]);
return 0;
}
Despite discussions in the previous thread and the confirmations that
this code is functionally equivalent to the Linux code, I still believe
this code is incorrect for both writing and reading.
From the doc, writing to GPIODATA will obviously copy each of bits 7
to 0 of the written value into the actuals GPIO mapped to bits 7 to
0 of this register (assuming they are configured as outputs, of course).
Based on this, the code above:
- when setting a single GPIO, sets *but clears up to seven other GPIOs*;
- when clearing a single GPIO, clears it *and up to seven other GPIOs*.
This code may have been tested only for a single active GPIO at a time,
for which this code would behave correctly; but as soon as two GPIOs
from the same bank must be set at the same time, it fails.
Please fix this code so that setting or clearing a GPIO does not set or
clear any other GPIO, and perform an actual test to confirm this works
before submitting V2.
No.
Some people (Marek, and *Michael*) asked this question in original
discussion thread.
The datasheet says each GPIO is controlled by *different* register.
(Well, it's unusual.)
And that is why we don't need a read-write-update operation.
Simply write 0 to the register does work. ( *Michael* replied it works )
BTW: if (as the previous thread seemed to imply) no one around has the
hardware to test this change, then why exactly is it needed?
Yes it's a strange implementation but looking at the documentation seems correct
Michael
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: spl: Do not set the stack pointer twice
Hi Masahiro,
On Wed, 17 Jul 2013 20:35:55 +0900, Masahiro Yamada
yamad...@jp.panasonic.com wrote:
Because the stack pointer is already set in arch/arm/lib/crt0.S,
we do not need to set it in arch/arm/lib/spl.c.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
arch/arm/lib/spl.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/lib/spl.c b/arch/arm/lib/spl.c
index 301f082..b5a1324 100644
--- a/arch/arm/lib/spl.c
+++ b/arch/arm/lib/spl.c
@@ -41,9 +41,6 @@ gd_t gdata __attribute__ ((section(.data)));
*/
void __weak board_init_f(ulong dummy)
{
- /* Set the stack pointer. */
- asm volatile(mov sp, %0\n : : r(CONFIG_SPL_STACK));
-
/* Clear the BSS. */
memset(__bss_start, 0, __bss_end - __bss_start);
Applied to u-boot-arm/master, thanks!
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 01/11] arm: dma_alloc_coherent: malloc() - memalign()
Hi Kuo-Jung,
On Mon, 29 Jul 2013 13:51:43 +0800, Kuo-Jung Su dant...@gmail.com
wrote:
From: Kuo-Jung Su dant...@faraday-tech.com
Even though the MMU/D-cache is off, some DMA engines still
expect strict address alignment.
For example, the incoming Faraday FTMAC110 FTGMAC100 ethernet
controllers expect the tx/rx descriptors should always be aligned
to 16-bytes boundary.
Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
CC: Albert ARIBAUD albert.u.b...@aribaud.net
---
Changes for v6, v7:
- Nothing updates
Changes for v5:
- Initial commit, which is separated from
arm: add MMU/D-Cache support for Faraday cores
arch/arm/include/asm/dma-mapping.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index 009863b..55a4e26 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -16,7 +16,7 @@ enum dma_data_direction {
static void *dma_alloc_coherent(size_t len, unsigned long *handle)
{
- *handle = (unsigned long)malloc(len);
+ *handle = (unsigned long)memalign(ARCH_DMA_MINALIGN, len);
return (void *)*handle;
}
--
1.7.9.5
Applied to u-boot-arm/master, thanks!
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] most efficient way to submit patches that are typo/grammar fixes?
given my pedantic nature, i've run across the occasional spelling mistake or grammar glitch and want to know the best way to submit a patch (or patches) for that. naturally, this stuff is scattered across the u-boot tree, so is it better to try to submit a separate patch per subsystem, or just one big one? most of this stuff is in comments so it doesn't represent any functional change and therefore shouldn't hurt anything ... stuff like spellings of environent or volitle, stuff like that. best way to do this? thanks. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 09/11] arm: add customized boot command for Faraday Images
Hi Kuo-Jung, On Mon, 29 Jul 2013 13:51:51 +0800, Kuo-Jung Su dant...@gmail.com wrote: + * At the time of writting, none of Faraday NAND SPI controllers + * supports XIP (eXecute In Place). So the Faraday A360/A369 SoC has + * to implement a 1st level bootstrap code stored in the embedded ROM + * inside the SoC. + * + * After power-on, the ROM code (1st level bootstrap code) would load + * the 2nd bootstrap code into SRAM without any SDRAM initialization. + * + * The 2nd bootstrap code would then initialize SDRAM and load the + * generic firmware (u-boot/linux) into SDRAM, and finally make + * a long-jump to the firmware. + * + * Which means the SPL design of U-boot would never fit to A360/A369, + * since it's usually not possible to alter a embedded ROM code. Sorry, but I don't see why SPL could not run in SRAM as the 2nd bootloader in your description; SPL certainly does not try to alter a embedded ROM. So, please rewrite the paragraph with the correct reason why SPL cannot be the 2nd bootloader, e.g., is it - because the 2nd bootloader is actually in ROM? - because the SRAM is too small? - ... In any case: + * And because both the 1st 2nd level bootstrap code use the private + * Faraday Firmware Image Format, it would be better to drop U-boot + * image support to simplify the design. Drop? Certainly not. Introduce a new image format where U-Boot is prepended with a header defined as follow..., yes -- you can even make a case that, if SPL cannot be the 2nd bootloader, then SPL is actually dropped for this platform. Please rewrite. Also: could the whole description and rationale be moved to some README.* file either arch/arm/cpu/faraday or in doc/ so that readers oof the C file can see the start of the actual code without having to scroll through hundreds of comment lines? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/8] ARMv7: Add HYP mode switching support
Hi Andre, On Fri, 9 Aug 2013 17:03:04 +0200, Andre Przywara andre.przyw...@linaro.org wrote: (for GIT URL and Changelog see below) Re: the changelog, I really prefer it when changelogs are per-patch rather than per-series. Right now, if I want to know the history for, say, patches 4/8 and 7/8, there is no way I can find it except by painfully doing git diffs. I would thus suggest that in the future you use patman, at least for patch series; based on the history you keep in each individual commit on your branch, it generates both per-patch and per-series history. That said, I'll pick the patch series, but I would appreciate if you could submit a standalone patch to address Christoffer's comment re 4/8 and 7/8. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 8/8] ARM: VExpress: enable ARMv7 virt support for VExpress A15
Hi Andre,
On Fri, 9 Aug 2013 17:03:12 +0200, Andre Przywara
andre.przyw...@linaro.org wrote:
To enable hypervisors utilizing the ARMv7 virtualization extension
on the Versatile Express board with the A15 core tile, we add the
required configuration variable.
Also we define the board specific functions to do the SMP bringup:
smp_set_cpu_boot_addr() to set the start address for secondary cores
and smp_waitloop() to wait for IPIs and jump to the start address.
This also serves as an example for what to do when adding support for
new boards.
Signed-off-by: Andre Przywara andre.przyw...@linaro.org
---
board/armltd/vexpress/Makefile | 7 +--
board/armltd/vexpress/vexpress_common.c | 13
board/armltd/vexpress/vexpress_smp.S| 36
+
include/configs/vexpress_ca15_tc2.h | 4
4 files changed, 58 insertions(+), 2 deletions(-)
create mode 100644 board/armltd/vexpress/vexpress_smp.S
diff --git a/board/armltd/vexpress/Makefile b/board/armltd/vexpress/Makefile
index 6719f3d..282ef6d 100644
--- a/board/armltd/vexpress/Makefile
+++ b/board/armltd/vexpress/Makefile
@@ -26,9 +26,12 @@ include $(TOPDIR)/config.mk
LIB = $(obj)lib$(BOARD).o
COBJS:= vexpress_common.o
+ifneq ($(CONFIG_ARMV7_NONSEC)$(CONFIG_ARMV7_VIRT),)
+SOBJS:= vexpress_smp.o
+endif
-SRCS := $(COBJS:.o=.c)
-OBJS := $(addprefix $(obj),$(COBJS))
+SRCS := $(COBJS:.o=.c) $(SOBJS:.o=.S)
+OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
$(LIB): $(obj).depend $(OBJS)
$(call cmd_link_o_target, $(OBJS))
diff --git a/board/armltd/vexpress/vexpress_common.c
b/board/armltd/vexpress/vexpress_common.c
index 2c54869..66b810d 100644
--- a/board/armltd/vexpress/vexpress_common.c
+++ b/board/armltd/vexpress/vexpress_common.c
@@ -272,3 +272,16 @@ ulong get_tbclk(void)
{
return (ulong)CONFIG_SYS_HZ;
}
+
+/* Setting the address at which secondary cores start from.
+ * Versatile Express uses one address for all cores, so ignore corenr
+ */
+void smp_set_core_boot_addr(unsigned long addr, int corenr)
+{
+ /* The SYSFLAGS register on VExpress needs to be cleared first
+ * by writing to the next address, since any writes to the address
+ * at offset 0 will only be ORed in
+ */
+ writel(~0, CONFIG_SYSFLAGS_ADDR + 4);
+ writel(addr, CONFIG_SYSFLAGS_ADDR);
+}
diff --git a/board/armltd/vexpress/vexpress_smp.S
b/board/armltd/vexpress/vexpress_smp.S
new file mode 100644
index 000..41be2e7
--- /dev/null
+++ b/board/armltd/vexpress/vexpress_smp.S
@@ -0,0 +1,36 @@
+/*
+ * code for redirecting secondary cores to their start address
+ *
+ * Copyright (c) 2013Andre Przywara andre.przyw...@linaro.org
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include config.h
+#include linux/linkage.h
+
+/* void _smp_waitloop(unsigned previous_address); */
+ENTRY(smp_waitloop)
+ wfi
+ ldr r1, =CONFIG_SYSFLAGS_ADDR @ load start address
+ ldr r1, [r1]
+ cmp r0, r1 @ make sure we dont execute this code
+ beq smp_waitloop@ again (due to a spurious wakeup)
+ mov pc, r1
+ENDPROC(smp_waitloop)
diff --git a/include/configs/vexpress_ca15_tc2.h
b/include/configs/vexpress_ca15_tc2.h
index 4f425ac..14aa78e 100644
--- a/include/configs/vexpress_ca15_tc2.h
+++ b/include/configs/vexpress_ca15_tc2.h
@@ -31,4 +31,8 @@
#include vexpress_common.h
#define CONFIG_BOOTP_VCI_STRING U-boot.armv7.vexpress_ca15x2_tc2
+#define CONFIG_SYSFLAGS_ADDR 0x1c010030
+
+#define CONFIG_ARMV7_VIRT
+
#endif
This patch breaks vexpress_ca9x4 and vexpress_ca5x2:
vexpress_common.c: In function 'smp_set_core_boot_addr':
vexpress_common.c:269:2: error: 'CONFIG_SYSFLAGS_ADDR' undeclared
(first use in this function) vexpress_common.c:269:2: note: each
undeclared identifier is reported only once for each function it
appears in.
Please provide V5 series addressing this as well as Christoffer's and
Nikolay's comments.
Amicalement,
--
Albert.
___
U-Boot mailing list
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Hi Robert and Hector, On Fri, Sep 13, 2013 at 2:46 PM, Wolfgang Denk w...@denx.de wrote: That's ALLOC_CACHE_ALIGN_BUFFER. Thanks. Could you please let us know wthether the change below fix the problem? Thanks, Fabio Estevam --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -794,7 +794,7 @@ static int fec_recv(struct eth_device *dev) uint16_t bd_status; uint32_t addr, size, end; int i; - uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN); + ALLOC_CACHE_ALIGN_BUFFER(uchar, buff, FEC_MAX_PKT_SIZE); /* * Check if any critical events have happened ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] doc: README.mxs: Add instruction to install 'libssl-dev'
From: Fabio Estevam fabio.este...@freescale.com
Building the mx28evk target on a host PC without the 'libssl-dev' package,
results in the following build error:
mxsimage.c:18:25: fatal error: openssl/evp.h: No such file or directory
Add an entry about the need of installing this package.
Also, remove the 'elftosb' text, since now we have the new 'mxsimage' method.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
doc/README.mxs | 37 +++--
1 file changed, 3 insertions(+), 34 deletions(-)
diff --git a/doc/README.mxs b/doc/README.mxs
index 5d9e72f..265cebd 100644
--- a/doc/README.mxs
+++ b/doc/README.mxs
@@ -27,41 +27,10 @@ Contents
1) Prerequisites
-To make a MXS based board bootable, some tools are necessary. The first one is
-the elftosb tool distributed by Freescale Semiconductor. The other one is the
-mxsboot tool found in U-Boot source tree.
+To make a MXS based board bootable, it is necessary to install the following
+package on the host PC. On a Debian-based distribution it would be:
-Firstly, obtain the elftosb archive from the following location:
-
- ftp://ftp.denx.de/pub/tools/elftosb-10.12.01.tar.gz
-
-We use a $VER variable here to denote the current version. At the time of
-writing of this document, that is 10.12.01. To obtain the file from command
-line, use:
-
- $ VER=10.12.01
- $ wget ftp://ftp.denx.de/pub/tools/elftosb-${VER}.tar.gz
-
-Extract the file:
-
- $ tar xzf elftosb-${VER}.tar.gz
-
-Compile the file. We need to manually tell the linker to use also libm:
-
- $ cd elftosb-${VER}/
- $ make LIBS=-lstdc++ -lm elftosb
-
-Optionally, remove debugging symbols from elftosb:
-
- $ strip bld/linux/elftosb
-
-Finally, install the elftosb binary. The install target is missing, so just
-copy the binary by hand:
-
- $ sudo cp bld/linux/elftosb /usr/local/bin/
-
-Make sure the elftosb binary can be found in your $PATH, in this case this
-means /usr/local/bin/ has to be in your $PATH.
+sudo apt-get install libssl-dev
2) Compiling U-Boot for a MXS based board
---
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx28evk: Fix checkpatch warning
From: Fabio Estevam fabio.este...@freescale.com Fix the following checkpatch warning: $ ./tools/checkpatch.pl -F board/freescale/mx28evk/mx28evk.c CHECK: Alignment should match open parenthesis #109: FILE: freescale/mx28evk/mx28evk.c:109: + writel(CLKCTRL_ENET_TIME_SEL_RMII_CLK | CLKCTRL_ENET_CLK_OUT_EN, + clkctrl_regs-hw_clkctrl_enet); Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- board/freescale/mx28evk/mx28evk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/freescale/mx28evk/mx28evk.c b/board/freescale/mx28evk/mx28evk.c index a307f27..3abf1fd 100644 --- a/board/freescale/mx28evk/mx28evk.c +++ b/board/freescale/mx28evk/mx28evk.c @@ -106,7 +106,7 @@ int board_eth_init(bd_t *bis) /* MX28EVK uses ENET_CLK PAD to drive FEC clock */ writel(CLKCTRL_ENET_TIME_SEL_RMII_CLK | CLKCTRL_ENET_CLK_OUT_EN, - clkctrl_regs-hw_clkctrl_enet); + clkctrl_regs-hw_clkctrl_enet); /* Power-on FECs */ gpio_direction_output(MX28_PAD_SSP1_DATA3__GPIO_2_15, 0); -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] - Help with usb3503 hub enumeration
Hello All and especially Dan Murphy, Reading thru the mailing list Dan seems to have worked on usb3503a + LAN9730 enumeration wrt the OMAP5. Hence, I seek his help and anyone else! This is with regards to an odroid-u2. It is Exynos 4412 prime based. It has a usb3503a hub and also a LAN 9730 - I am guessing pretty much like the omap5. From the clock source and the PMIC perspective I do see that the usb3503a is powered up and gets a REF_CLK. (I can verify this as I can read and write via I2C to the usb3503a and get/set its configuration. Also, I do have the correct GPIO pins for the INT_N, RESET_N and HUB_CONNECT wrt the usb3503a. In the platform based ehci-exynos.c I do initialize the the USB_PHY, HSIC_1_PHY and HSIC2_PHY that is present in the Exynos 4412 SoC. These I have copied over from the Linux kernel (which has full usb support and works). Once this is done, I can see that the values for hccr and hcor appear correct as reported by Linux too. When it comes to starting up usb via usb start, I seem to hit the below sequence - with debug on ... The u-boot is quite an older u-boot, but I have ported most of the usb code over from the arndale port over at insignal - which seems to have usb working (they too have a usb3503a but with exynos5) My question is how do I debug this to get it working. Looks like the hcd does not see the usb3503a, am I correct? 8 (Re)start USB... USB: Exynos4412-ehci: init hccr 1258 and hcor 12580010 hc_length 10 Register 1313 NbrPorts 3 USB EHCI 1.00 samsung_gpiolib_4bit_output: base: 11000c60 offset: 5 value: 0 s3c_gpiolib_set: reg: 11000c64 offset: 5 value: 0 samsung_gpiolib_4bit_output: base: 11000c60 offset: 0 value: 0 s3c_gpiolib_set: reg: 11000c64 offset: 0 value: 0 samsung_gpiolib_4bit_output: base: 11000c60 offset: 4 value: 0 s3c_gpiolib_set: reg: 11000c64 offset: 4 value: 0 s3c_gpiolib_set: reg: 11000c64 offset: 5 value: 1 Read 32 from USB3503 SP_ILOCK s3c_gpiolib_set: reg: 11000c64 offset: 4 value: 1 Wrote 33 to USB3503_SP_ILOCK samsung_gpiolib_4bit_input: base: 11000c60 offset: 0 scanning bus for devices... New Device 0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 set address 1 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x12 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x9 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x19 get_conf_no 0 Result 25, wLength 25 if 0, ep 0 ##EP epmaxpacketin[1] = 8 set configuration 1 usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 new device strings: Mfr=1, Product=2, SerialNumber=0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF USB device number 1 default language ID 0x1 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x1 length 0xFF usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x1 length 0xFF Manufacturer u-boot Product EHCI Host Controller SerialNumber Vendor: 0x Product 0x Version 1.0 USB hub found usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x4 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x8 3 ports detected individual port power switching standalone hub global over-current protection power on to power good time: 20ms hub controller current requirement: 0mA port 1 is removable port 2 is removable port 3 is removable usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4 get_hub_status returned status 1, change 103 local power source is lost (inactive) no over-current condition exists enabling power on all ports usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x1 length 0x0 port 1 returns 0 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x2 length 0x0 port 2 returns 0 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x3 length 0x0 The request port(2) is not configured port 3 returns 8000 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x3 length 0x4 The request port(2) is not configured port 3: get_port_status failed usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 port 1 returns 0 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x2 length 0x0 port 2 returns 0 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x3 length 0x0 The request port(2) is not configured port 3 returns 8000 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 Port 1 Status 500 Change 0 usb_control_msg: request:
Re: [U-Boot] most efficient way to submit patches that are typo/grammar fixes?
Dear Robert P. J. Day, In message alpine.DEB.2.02.1309140615150.14699@oneiric you wrote: given my pedantic nature, i've run across the occasional spelling mistake or grammar glitch and want to know the best way to submit a patch (or patches) for that. naturally, this stuff is scattered across the u-boot tree, so is it better to try to submit a separate patch per subsystem, or just one big one? most of this stuff is in comments so it doesn't represent any functional change and therefore shouldn't hurt anything ... stuff like spellings of environent or volitle, stuff like that. best way to do this? thanks. It's usually a good idea not to combine too many unrelated changes into a huge single patch. But then, there is also no need to split spelling fixes across sub-systems. I recommend to use common sense. It's probably a good idea to add a flag like [COSMETIC] to the patch subject, so we know immediately that this does not contain any functional changes. 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 There are some good people in it, but the orchestra as a whole is equivalent to a gang bent on destruction. - John Cage, composer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] doc: README.mxs: Add instruction to install 'libssl-dev'
On Sat, Sep 14, 2013 at 7:21 PM, Fabio Estevam feste...@gmail.com wrote: From: Fabio Estevam fabio.este...@freescale.com Building the mx28evk target on a host PC without the 'libssl-dev' package, results in the following build error: mxsimage.c:18:25: fatal error: openssl/evp.h: No such file or directory Add an entry about the need of installing this package. Also, remove the 'elftosb' text, since now we have the new 'mxsimage' method. Ops, looks like we cannot remove elftosb yet. When I try make u-boot.sb: make[1]: Entering directory `/home/fabio/denx/u-boot/arch/arm/cpu/arm926ejs/mxs' sed s@OBJTREE@/home/fabio/denx/u-boot@g /home/fabio/denx/u-boot/arch/arm/cpu/arm926ejs/mxs/u-boot-imx28.bd /home/fabio/denx/u-boot/u-boot.bd elftosb -zf imx28 -c /home/fabio/denx/u-boot/u-boot.bd -o /home/fabio/denx/u-boot/u-boot.sb make[1]: elftosb: Command not found ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Merge and reformat boards.cfg and MAINTAINERS
Hi Roger,
On Thu, 12 Sep 2013 13:18:20 +, Meier, Roger
r.me...@siemens.com wrote:
Hi Albert
-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On
Behalf Of Albert ARIBAUD
Sent: Mittwoch, 11. September 2013 15:53
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2] Merge and reformat boards.cfg and MAINTAINERS
Put all informations about targets, including state (active or
orphan) and maintainers, in boards.cfg; remove MAINTAINERS;
adjust the build system accordingly.
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
V2:
- updated with latest boards.cfg/MAINTAINER info
- fixed wrong maintainer(s) for orphan boards
- fixed wrong maintainer(s) for base:options case
- fixed lingering misuses of boards.cfg and MAINTAINERS
V1:
- initial submission from squashed RFC patch series
MAINTAINERS | 1412
MAKEALL | 51 +-
Makefile|2 +-
README |6 +-
boards.cfg | 2345
--
-
mkconfig| 31 +-
tools/buildman/board.py |2 +-
tools/reformat.py | 132 +++
8 files changed, 1350 insertions(+), 2631 deletions(-)
delete mode 100644 MAINTAINERS
create mode 100755 tools/reformat.py
I really like that simplification!
tools/checkpatch.pl detected these errors:
---SNIP---
ERROR: trailing whitespace
#4055: FILE: tools/reformat.py:32:
+# ^I$
ERROR: trailing whitespace
#4125: FILE: tools/reformat.py:102:
+^I^I# any missing field is set to default if it exists $
---SNIP---
and I recognized that tools/checkpatch.pl needs the patch below.
Regards,
Roger
diff --git a/tools/checkpatch.pl b/tools/checkpatch.pl
index 896e2bc..88c5bc7 100755
--- a/tools/checkpatch.pl
+++ b/tools/checkpatch.pl
@@ -398,7 +398,7 @@ sub top_of_kernel_tree {
my ($root) = @_;
my @tree_check = (
- COPYING, CREDITS, Kbuild, MAINTAINERS, Makefile,
+ COPYING, CREDITS, Kbuild, Makefile,
README, Documentation, arch, include, drivers,
fs, init, ipc, kernel, lib, scripts,
);
@@ -3701,7 +3701,7 @@ sub process {
$vname has style problems, please review.
If any of these errors are false positives, please report
-them to the maintainer, see CHECKPATCH in MAINTAINERS.
+them to the maintainer, see boards.cfg.
EOM
}
Thanks! I thought I'd done a grep -i MAINTAINERS before posting,
obviously I hadn't.
Could you send thoses two fixes as as a proper, standalone git patch
rather than a reply to another patch, so that they can be properly
attributed to you?
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
