Re: [U-Boot] [Patch v3 0/4] imx: mx6: use OTP for teperature grade info
Hi Peng, Tim, On 19/05/2015 02:21, Peng Fan wrote: U-Boot 2015.07-rc1-00260-g44bf513 (May 19 2015 - 09:14:52) CPU: Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 33C Reset cause: POR Board: MX6SX SABRE SDB I2C: ready DRAM: 1 GiB PMIC: PFUZE100 ID=0x11 MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 In:serial Out: serial Err: serial Net: FEC [PRIME] Hit any key to stop autoboot: 0 = Tested-by: Peng Fan peng@freescale.com Thanks. It looks like the last issue was solved - if nobody else complains, these patches are ready for merging. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm/imx-common: Fix warning 'get_reset_cause' defined but not used
Hi Prabhakar, Eric,
On 18/05/2015 16:44, Eric Nelson wrote:
Hi Prabhakar,
On 05/18/2015 04:43 AM, Prabhakar Kushwaha wrote:
Fix below warning
arch/arm/imx-common/cpu.c:29:14: warning: ‘get_reset_cause’ defined but
not used
static char *get_reset_cause(void)
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
arch/arm/imx-common/cpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
index 067d08f..0cd08cb 100644
--- a/arch/arm/imx-common/cpu.c
+++ b/arch/arm/imx-common/cpu.c
@@ -24,6 +24,7 @@
#include fsl_esdhc.h
#endif
+#if defined(CONFIG_DISPLAY_CPUINFO)
static u32 reset_cause = -1;
static char *get_reset_cause(void)
@@ -60,6 +61,7 @@ u32 get_imx_reset_cause(void)
{
return reset_cause;
}
+#endif
#if defined(CONFIG_MX53) || defined(CONFIG_MX6)
#if defined(CONFIG_MX53)
This makes the dependency clear, even if it's odd.
Reviewed-by: Eric Nelson eric.nel...@boundarydevices.com
Yes, anyway this is what we already use for other SOCs (iMX31, iMX35,..
they have a local get_reset_cause() protected by this switch).
Acked-by: Stefano Babic sba...@denx.de
Best regards,
Stefano babic
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: atmel: switch to usb ehci for sama5d3 boards
Hi, On 19-05-15 12:54, Josh Wu wrote: From: Bo Shen voice.s...@atmel.com As the cache coherence issue in OHCI HCD, when enable I/D cache for sama5d3 SoC, the OHCI can not work properly. So, switch to EHCI, then the USB can work well. Signed-off-by: Bo Shen voice.s...@atmel.com [rebase to mainline] Signed-off-by: Josh Wu josh...@atmel.com I'm confused now, with the patch you just send the ohci code should work, right? And this way usb-1 devices like keyboards will not work, otoh you will get faster usb storage support. What you should really do is convert the atmel usb glue to support the u-boot driver model and move to that, then you can build in both the ohci and ehci drivers and get the best of both worlds. I've already done so for sunxi, ironing out all the handover bugs in the usb core and ehci code, paving the way for you :) Regards, Hans --- include/configs/sama5d3_xplained.h | 21 +++-- include/configs/sama5d3xek.h | 21 +++-- 2 files changed, 6 insertions(+), 36 deletions(-) diff --git a/include/configs/sama5d3_xplained.h b/include/configs/sama5d3_xplained.h index bfd8aa7..0dab15d 100644 --- a/include/configs/sama5d3_xplained.h +++ b/include/configs/sama5d3_xplained.h @@ -20,17 +20,6 @@ #define CONFIG_USART_BASE ATMEL_BASE_DBGU #define CONFIG_USART_ID ATMEL_ID_DBGU -/* - * This needs to be defined for the OHCI code to work but it is defined as - * ATMEL_ID_UHPHS in the CPU specific header files. - */ -#define ATMEL_ID_UHP ATMEL_ID_UHPHS - -/* - * Specify the clock enable bit in the PMC_SCER register. - */ -#define ATMEL_PMC_UHP AT91SAM926x_PMC_UHP - /* SDRAM */ #define CONFIG_NR_DRAM_BANKS 1 #define CONFIG_SYS_SDRAM_BASE ATMEL_BASE_DDRCS @@ -95,13 +84,9 @@ #define CONFIG_CMD_USB #ifdef CONFIG_CMD_USB -#define CONFIG_USB_ATMEL -#define CONFIG_USB_ATMEL_CLK_SEL_UPLL -#define CONFIG_USB_OHCI_NEW -#define CONFIG_SYS_USB_OHCI_CPU_INIT -#define CONFIG_SYS_USB_OHCI_REGS_BASE ATMEL_BASE_OHCI -#define CONFIG_SYS_USB_OHCI_SLOT_NAME SAMA5D3 Xplained -#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 2 +#define CONFIG_USB_EHCI +#define CONFIG_USB_EHCI_ATMEL +#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 #define CONFIG_DOS_PARTITION #define CONFIG_USB_STORAGE #endif diff --git a/include/configs/sama5d3xek.h b/include/configs/sama5d3xek.h index d933a9e..d3ab6e4 100644 --- a/include/configs/sama5d3xek.h +++ b/include/configs/sama5d3xek.h @@ -24,17 +24,6 @@ #define CONFIG_USART_BASE ATMEL_BASE_DBGU #define CONFIG_USART_ID ATMEL_ID_DBGU -/* - * This needs to be defined for the OHCI code to work but it is defined as - * ATMEL_ID_UHPHS in the CPU specific header files. - */ -#define ATMEL_ID_UHP ATMEL_ID_UHPHS - -/* - * Specify the clock enable bit in the PMC_SCER register. - */ -#define ATMEL_PMC_UHP AT91SAM926x_PMC_UHP - /* LCD */ #define CONFIG_LCD #define LCD_BPP LCD_COLOR16 @@ -128,13 +117,9 @@ #define CONFIG_CMD_USB #ifdef CONFIG_CMD_USB -#define CONFIG_USB_ATMEL -#define CONFIG_USB_ATMEL_CLK_SEL_UPLL -#define CONFIG_USB_OHCI_NEW -#define CONFIG_SYS_USB_OHCI_CPU_INIT -#define CONFIG_SYS_USB_OHCI_REGS_BASE ATMEL_BASE_OHCI -#define CONFIG_SYS_USB_OHCI_SLOT_NAME sama5d3 -#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 3 +#define CONFIG_USB_EHCI +#define CONFIG_USB_EHCI_ATMEL +#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 #define CONFIG_DOS_PARTITION #define CONFIG_USB_STORAGE #endif ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: atmel: switch to usb ehci for sama5d3 boards
Hi, Hans On 5/19/2015 6:57 PM, Hans de Goede wrote: Hi, On 19-05-15 12:54, Josh Wu wrote: From: Bo Shen voice.s...@atmel.com As the cache coherence issue in OHCI HCD, when enable I/D cache for sama5d3 SoC, the OHCI can not work properly. So, switch to EHCI, then the USB can work well. Signed-off-by: Bo Shen voice.s...@atmel.com [rebase to mainline] Signed-off-by: Josh Wu josh...@atmel.com I'm confused now, with the patch you just send the ohci code should work, right? Right. I forget to amend the commit message. Sorry. And this way usb-1 devices like keyboards will not work, otoh you will get faster usb storage support. I didn't test the keyboard yet. Good to know this. thanks. What you should really do is convert the atmel usb glue to support the u-boot driver model and move to that, then you can build in both the ohci and ehci drivers and get the best of both worlds. Ok, that sounds nice. I've already done so for sunxi, ironing out all the handover bugs in the usb core and ehci code, paving the way for you :) Indeed, it seems convert to DM is the right way. Ok, I will do it. Thanks again. Best Regards, Josh Wu Regards, Hans --- include/configs/sama5d3_xplained.h | 21 +++-- include/configs/sama5d3xek.h | 21 +++-- 2 files changed, 6 insertions(+), 36 deletions(-) diff --git a/include/configs/sama5d3_xplained.h b/include/configs/sama5d3_xplained.h index bfd8aa7..0dab15d 100644 --- a/include/configs/sama5d3_xplained.h +++ b/include/configs/sama5d3_xplained.h @@ -20,17 +20,6 @@ #define CONFIG_USART_BASEATMEL_BASE_DBGU #define CONFIG_USART_IDATMEL_ID_DBGU -/* - * This needs to be defined for the OHCI code to work but it is defined as - * ATMEL_ID_UHPHS in the CPU specific header files. - */ -#define ATMEL_ID_UHPATMEL_ID_UHPHS - -/* - * Specify the clock enable bit in the PMC_SCER register. - */ -#define ATMEL_PMC_UHPAT91SAM926x_PMC_UHP - /* SDRAM */ #define CONFIG_NR_DRAM_BANKS1 #define CONFIG_SYS_SDRAM_BASE ATMEL_BASE_DDRCS @@ -95,13 +84,9 @@ #define CONFIG_CMD_USB #ifdef CONFIG_CMD_USB -#define CONFIG_USB_ATMEL -#define CONFIG_USB_ATMEL_CLK_SEL_UPLL -#define CONFIG_USB_OHCI_NEW -#define CONFIG_SYS_USB_OHCI_CPU_INIT -#define CONFIG_SYS_USB_OHCI_REGS_BASEATMEL_BASE_OHCI -#define CONFIG_SYS_USB_OHCI_SLOT_NAMESAMA5D3 Xplained -#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS2 +#define CONFIG_USB_EHCI +#define CONFIG_USB_EHCI_ATMEL +#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS3 #define CONFIG_DOS_PARTITION #define CONFIG_USB_STORAGE #endif diff --git a/include/configs/sama5d3xek.h b/include/configs/sama5d3xek.h index d933a9e..d3ab6e4 100644 --- a/include/configs/sama5d3xek.h +++ b/include/configs/sama5d3xek.h @@ -24,17 +24,6 @@ #define CONFIG_USART_BASEATMEL_BASE_DBGU #defineCONFIG_USART_IDATMEL_ID_DBGU -/* - * This needs to be defined for the OHCI code to work but it is defined as - * ATMEL_ID_UHPHS in the CPU specific header files. - */ -#define ATMEL_ID_UHPATMEL_ID_UHPHS - -/* - * Specify the clock enable bit in the PMC_SCER register. - */ -#define ATMEL_PMC_UHPAT91SAM926x_PMC_UHP - /* LCD */ #define CONFIG_LCD #define LCD_BPPLCD_COLOR16 @@ -128,13 +117,9 @@ #define CONFIG_CMD_USB #ifdef CONFIG_CMD_USB -#define CONFIG_USB_ATMEL -#define CONFIG_USB_ATMEL_CLK_SEL_UPLL -#define CONFIG_USB_OHCI_NEW -#define CONFIG_SYS_USB_OHCI_CPU_INIT -#define CONFIG_SYS_USB_OHCI_REGS_BASEATMEL_BASE_OHCI -#define CONFIG_SYS_USB_OHCI_SLOT_NAMEsama5d3 -#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS3 +#define CONFIG_USB_EHCI +#define CONFIG_USB_EHCI_ATMEL +#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS3 #define CONFIG_DOS_PARTITION #define CONFIG_USB_STORAGE #endif ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ohci: enable cache support
Hi,
On 19-05-15 12:44, Josh Wu wrote:
Remove the CONFIG_DM_USB limitation to enable cache support functions.
Tested on SAMA5D3x-EK board.
Signed-off-by: Josh Wu josh...@atmel.com
Looks good to me:
Acked-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
---
drivers/usb/host/ohci-hcd.c | 10 +-
drivers/usb/host/ohci.h | 2 +-
2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 494b760..8920b0f 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -103,21 +103,13 @@ static struct pci_device_id ehci_pci_ids[] = {
# define m32_swap(x) cpu_to_le32(x)
#endif /* CONFIG_SYS_OHCI_BE_CONTROLLER */
-#ifdef CONFIG_DM_USB
-/*
- * We really should do proper cache flushing everywhere, but for now we only
- * do it for new (driver-model) usb code to avoid regressions.
- */
+/* We really should do proper cache flushing everywhere */
#define flush_dcache_buffer(addr, size) \
flush_dcache_range((unsigned long)(addr), \
ALIGN((unsigned long)(addr) + size, ARCH_DMA_MINALIGN))
#define invalidate_dcache_buffer(addr, size) \
invalidate_dcache_range((unsigned long)(addr), \
ALIGN((unsigned long)(addr) + size, ARCH_DMA_MINALIGN))
-#else
-#define flush_dcache_buffer(addr, size)
-#define invalidate_dcache_buffer(addr, size)
-#endif
/* Do not use sizeof(ed / td) as our ed / td structs contain extra members */
#define flush_dcache_ed(addr) flush_dcache_buffer(addr, 16)
diff --git a/drivers/usb/host/ohci.h b/drivers/usb/host/ohci.h
index f52b4c1..47bd85b 100644
--- a/drivers/usb/host/ohci.h
+++ b/drivers/usb/host/ohci.h
@@ -18,7 +18,7 @@
# define ohci_writel(a, b) (*((volatile u32 *)(b)) = ((volatile u32)a))
#endif /* CONFIG_SYS_OHCI_SWAP_REG_ACCESS */
-#if defined CONFIG_DM_USB ARCH_DMA_MINALIGN 16
+#if ARCH_DMA_MINALIGN 16
#define ED_ALIGNMENT ARCH_DMA_MINALIGN
#else
#define ED_ALIGNMENT 16
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: ohci: enable cache support
Remove the CONFIG_DM_USB limitation to enable cache support functions.
Tested on SAMA5D3x-EK board.
Signed-off-by: Josh Wu josh...@atmel.com
---
drivers/usb/host/ohci-hcd.c | 10 +-
drivers/usb/host/ohci.h | 2 +-
2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 494b760..8920b0f 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -103,21 +103,13 @@ static struct pci_device_id ehci_pci_ids[] = {
# define m32_swap(x) cpu_to_le32(x)
#endif /* CONFIG_SYS_OHCI_BE_CONTROLLER */
-#ifdef CONFIG_DM_USB
-/*
- * We really should do proper cache flushing everywhere, but for now we only
- * do it for new (driver-model) usb code to avoid regressions.
- */
+/* We really should do proper cache flushing everywhere */
#define flush_dcache_buffer(addr, size) \
flush_dcache_range((unsigned long)(addr), \
ALIGN((unsigned long)(addr) + size, ARCH_DMA_MINALIGN))
#define invalidate_dcache_buffer(addr, size) \
invalidate_dcache_range((unsigned long)(addr), \
ALIGN((unsigned long)(addr) + size, ARCH_DMA_MINALIGN))
-#else
-#define flush_dcache_buffer(addr, size)
-#define invalidate_dcache_buffer(addr, size)
-#endif
/* Do not use sizeof(ed / td) as our ed / td structs contain extra members */
#define flush_dcache_ed(addr) flush_dcache_buffer(addr, 16)
diff --git a/drivers/usb/host/ohci.h b/drivers/usb/host/ohci.h
index f52b4c1..47bd85b 100644
--- a/drivers/usb/host/ohci.h
+++ b/drivers/usb/host/ohci.h
@@ -18,7 +18,7 @@
# define ohci_writel(a, b) (*((volatile u32 *)(b)) = ((volatile u32)a))
#endif /* CONFIG_SYS_OHCI_SWAP_REG_ACCESS */
-#if defined CONFIG_DM_USB ARCH_DMA_MINALIGN 16
+#if ARCH_DMA_MINALIGN 16
#define ED_ALIGNMENT ARCH_DMA_MINALIGN
#else
#define ED_ALIGNMENT 16
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-usb/master
The following changes since commit 0e6b7a28243175ae0874d53b6e6e4eff8548d71f: Merge git://git.denx.de/u-boot-samsung (2015-05-18 09:15:15 -0400) are available in the git repository at: git://git.denx.de/u-boot-usb.git HEAD for you to fetch changes up to 9cf3c384ad96c3e00c12e1d151d7f32c5b760a03: include:configs:ls1021aqds: Enable USB IP support (2015-05-19 12:42:16 +0200) Hans de Goede (2): usb: Remove unused variable in usb_setup_descriptor() usb: kbd: Fix key repeat not always using Peter Griffin (1): usb: dwc2: Add support for v3 snpsid value Ramneek Mehresh (5): drivers:usb:dwc3: Add DWC3 controller driver support drivers:usb:fsl: Add XHCI driver support arch:arm:fsl: Add XHCI support for LS1021A include:configs:ls1021atwr: Enable USB IP support include:configs:ls1021aqds: Enable USB IP support Siva Durga Prasad Paladugu (1): ci_udc: Update the ci_udc driver to support bulk transfers arch/arm/include/asm/arch-ls102xa/config.h| 1 + arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 10 +++ common/usb.c | 2 -- common/usb_kbd.c | 22 +++ drivers/usb/gadget/ci_udc.c | 135 +++- drivers/usb/gadget/ci_udc.h | 1 + drivers/usb/host/Makefile | 2 ++ drivers/usb/host/dwc2.c | 3 +- drivers/usb/host/dwc2.h | 1 + drivers/usb/host/xhci-dwc3.c | 74 drivers/usb/host/xhci-fsl.c | 109 +++ include/configs/ls1021aqds.h | 22 +++ include/configs/ls1021atwr.h | 38 + include/linux/usb/dwc3.h | 4 +++ include/linux/usb/xhci-fsl.h | 54 +++ 15 files changed, 446 insertions(+), 32 deletions(-) create mode 100644 drivers/usb/host/xhci-dwc3.c create mode 100644 drivers/usb/host/xhci-fsl.c create mode 100644 include/linux/usb/xhci-fsl.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: atmel: switch to usb ehci for sama5d3 boards
From: Bo Shen voice.s...@atmel.com As the cache coherence issue in OHCI HCD, when enable I/D cache for sama5d3 SoC, the OHCI can not work properly. So, switch to EHCI, then the USB can work well. Signed-off-by: Bo Shen voice.s...@atmel.com [rebase to mainline] Signed-off-by: Josh Wu josh...@atmel.com --- include/configs/sama5d3_xplained.h | 21 +++-- include/configs/sama5d3xek.h | 21 +++-- 2 files changed, 6 insertions(+), 36 deletions(-) diff --git a/include/configs/sama5d3_xplained.h b/include/configs/sama5d3_xplained.h index bfd8aa7..0dab15d 100644 --- a/include/configs/sama5d3_xplained.h +++ b/include/configs/sama5d3_xplained.h @@ -20,17 +20,6 @@ #define CONFIG_USART_BASE ATMEL_BASE_DBGU #define CONFIG_USART_IDATMEL_ID_DBGU -/* - * This needs to be defined for the OHCI code to work but it is defined as - * ATMEL_ID_UHPHS in the CPU specific header files. - */ -#define ATMEL_ID_UHP ATMEL_ID_UHPHS - -/* - * Specify the clock enable bit in the PMC_SCER register. - */ -#define ATMEL_PMC_UHP AT91SAM926x_PMC_UHP - /* SDRAM */ #define CONFIG_NR_DRAM_BANKS 1 #define CONFIG_SYS_SDRAM_BASE ATMEL_BASE_DDRCS @@ -95,13 +84,9 @@ #define CONFIG_CMD_USB #ifdef CONFIG_CMD_USB -#define CONFIG_USB_ATMEL -#define CONFIG_USB_ATMEL_CLK_SEL_UPLL -#define CONFIG_USB_OHCI_NEW -#define CONFIG_SYS_USB_OHCI_CPU_INIT -#define CONFIG_SYS_USB_OHCI_REGS_BASE ATMEL_BASE_OHCI -#define CONFIG_SYS_USB_OHCI_SLOT_NAME SAMA5D3 Xplained -#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 2 +#define CONFIG_USB_EHCI +#define CONFIG_USB_EHCI_ATMEL +#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 #define CONFIG_DOS_PARTITION #define CONFIG_USB_STORAGE #endif diff --git a/include/configs/sama5d3xek.h b/include/configs/sama5d3xek.h index d933a9e..d3ab6e4 100644 --- a/include/configs/sama5d3xek.h +++ b/include/configs/sama5d3xek.h @@ -24,17 +24,6 @@ #define CONFIG_USART_BASE ATMEL_BASE_DBGU #defineCONFIG_USART_ID ATMEL_ID_DBGU -/* - * This needs to be defined for the OHCI code to work but it is defined as - * ATMEL_ID_UHPHS in the CPU specific header files. - */ -#define ATMEL_ID_UHP ATMEL_ID_UHPHS - -/* - * Specify the clock enable bit in the PMC_SCER register. - */ -#define ATMEL_PMC_UHP AT91SAM926x_PMC_UHP - /* LCD */ #define CONFIG_LCD #define LCD_BPPLCD_COLOR16 @@ -128,13 +117,9 @@ #define CONFIG_CMD_USB #ifdef CONFIG_CMD_USB -#define CONFIG_USB_ATMEL -#define CONFIG_USB_ATMEL_CLK_SEL_UPLL -#define CONFIG_USB_OHCI_NEW -#define CONFIG_SYS_USB_OHCI_CPU_INIT -#define CONFIG_SYS_USB_OHCI_REGS_BASE ATMEL_BASE_OHCI -#define CONFIG_SYS_USB_OHCI_SLOT_NAME sama5d3 -#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 3 +#define CONFIG_USB_EHCI +#define CONFIG_USB_EHCI_ATMEL +#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 #define CONFIG_DOS_PARTITION #define CONFIG_USB_STORAGE #endif -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot compilation error for altera socfpga cyclon 5 if gpio included
Hi, On 12 May 2015 at 07:53, Altunbas Sabri (DC-IA/EAH2) sabri.altun...@boschrexroth.de wrote: Hi All, I use u-boot for altera socfpga cyclone 5 and want to include gpio-functionality with #define CONFIG_CMD_GPIO in file uboot-socfpga/include/configs/ socfpga_cyclone5.h and get the following compilation error .. . In file included from cmd_gpio.c:12:0: /media/tux/work/0/uboot/software/spl_bsp/uboot-socfpga/include/asm/gpio.h:1:27: fatal error: asm/arch/gpio.h: No such file or directory #include asm/arch/gpio.h ^ compilation terminated. make[2]: *** Keine Regel vorhanden, um das Target ».depend«, benötigt von »libcommon.o«, zu erstellen. Schluss. make[2]: Verzeichnis »uboot-socfpga/common« wird verlassen make[1]: *** [common/libcommon.o] Fehler 2 I think you need to add that file (even if empty) to: arch/arm/mach-socfpga/include/mach Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/9] moveconfig: Always run savedefconfig on the moved config
Hi Joe, 2015-05-20 3:21 GMT+09:00 Joe Hershberger joe.hershber...@ni.com: This will ensure that the order of the defconfig entries will always match that of the Kconfig files. After one slightly painful (but still early in the process) pass over all boards, this should keep the defconfigs clean from here on. Users must edit the Kconfig first to add the menu entries and then run moveconfig.py to update the defconfig files and the include configs. As such, moveconfig.py cannot compare against the '.config' contents. Signed-off-by: Joe Hershberger joe.hershber...@ni.com --- This is based on https://patchwork.ozlabs.org/patch/472591/ Changes in v5: -Removed warning that may never be reached The whole series of v5 looks good to me. Tom, looks like this series is delegated to me. Shall I apply my base patch and Joe's great improvements and then send a pull-req? Or would you do it? -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] tools: get-toolchais: a tool to get cross-tools for all architectures
2015-05-20 3:17 GMT+09:00 Simon Glass s...@chromium.org: In my case I do some work on an old distro and on that machine I have wget, but not python 3. 8 snip 8 One option there might be Python 2 and urllib2 like buildman? In general it is nice to support older platforms if we can as it reduces friction. Looks the sole choice to me. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc: gitignore: ignore PowerPC DTBs
Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- arch/powerpc/dts/.gitignore | 1 + 1 file changed, 1 insertion(+) create mode 100644 arch/powerpc/dts/.gitignore diff --git a/arch/powerpc/dts/.gitignore b/arch/powerpc/dts/.gitignore new file mode 100644 index 000..b60ed20 --- /dev/null +++ b/arch/powerpc/dts/.gitignore @@ -0,0 +1 @@ +*.dtb -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] i.MX53 USB Client not working
Hi Matthew, On Thu, May 14, 2015 at 7:39 PM, Matthew Starr mst...@hedonline.com wrote: It appears that setting CONFIG_MXC_USB_PORT to 0 then loads the OTG port on the i.MX53. The code appears to be in drivers/usb/host/ehci-mx5.c.The problem then is that the USB host port is then not usable since my i.MX53 board dedicates the OTG port to USB client functionality only. Now I am trying to get both USB Host port 1 and USB OTG port 0 working at the same time. Does u-boot allow using multiple USB controller ports at the same time? Yes, you can use both ports. In order to do so, you need to pass #define CONFIG_USB_MAX_CONTROLLER_COUNT 2 in your config file. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 20/20] tegra: config: nyan-big: Add options required by Chrome OS boot
Hi Stephen, On 19 May 2015 at 19:44, Stephen Warren swar...@wwwdotorg.org wrote: On 05/19/2015 05:27 PM, Simon Glass wrote: +Tom Rini in case he is interested... Hi Stephen, On 19 May 2015 at 15:36, Stephen Warren swar...@wwwdotorg.org wrote: On 05/19/2015 12:01 PM, Simon Glass wrote: Hi Stephen, On 19 May 2015 at 09:41, Stephen Warren swar...@wwwdotorg.org wrote: On 05/18/2015 03:33 PM, Simon Glass wrote: Hi Stephen, On 15 May 2015 at 09:34, Stephen Warren swar...@wwwdotorg.org wrote: On 05/13/2015 07:56 AM, Simon Glass wrote: Hi Stephen, On 25 February 2015 at 16:31, Stephen Warren swar...@wwwdotorg.org wrote: On 02/17/2015 03:29 PM, Simon Glass wrote: We need to match the device tree in the FIT with the U-Boot model so we can automatically select the right device tree. Also adjust the load address so that the device tree is not in the way when a zImage kernel tries to extract itself. We don't tend to use LOADADDR in any of the default boot scripts any more. Rather, we explicitly load files to a semantic location indicated by one of the following variables in tegra124-common.h: #define MEM_LAYOUT_ENV_SETTINGS \ scriptaddr=0x9000\0 \ pxefile_addr_r=0x9010\0 \ kernel_addr_r=0x8100\0 \ fdt_addr_r=0x8200\0 \ ramdisk_addr_r=0x8210\0 Perhaps the ChromeOS boot scripts could be adjusted to use one/some of those variables? If the value of CONFIG_LOADADDR isn't appropriate, perhaps we should fix it for all Tegra SoCs/boards? I forgot about this comment sorry. I had problems with the image overwriting itself. It is a bzImage inside a FIT so doesn't use the proper FIT decompression. Anyway I'd like to clarify what is meant by kernel_addr_r. Is that where the FIT is loaded or where the kernel will decompress to, or something else? kernel_addr_r is the address in RAM at which a kernel zImage is loaded by config_distro_bootcmd.h scripts (and likely other scripts too). It's usually deliberately chosen to be a fair way into RAM, so that when the zImage decompresses (to approx the start of RAM), the decompressed image doesn't overlap the compressed image at kernel_addr_r. This avoids the kernel decompressor having to move/copy the zImage somewhere else before copying to avoid any overlap during decompression. config_distro_bootcmd.h doesn't support FIT, so I haven't tried out loading FIT images. That said, if U-Boot simply jumps to the location of the kernel in the FIT image itself without any copying, I would expect everything to work fine if you loaded a FIT image to kernel_addr_r. However, if the processing of the FIT image requires the kernel to be copied out of the FIT image to some other location, you'd have to carefully choose that location so it didn't overlap anything. I'd strongly recommend avoiding any unnecessary copies like that though, if at all possible, from the perspective of both pointlessly wasted execution time and simplicity of the boot process. Perhaps storing a a kernel_noload image type inside the FIT rather than a kernel image type might help there? Perhaps you want to introduce a new standard variable that defines where FIT images are loaded. I wonder what would be involved in adjusting config_distro_bootcmd to support FIT? Well, it goes against the very idea of config_distro_bootcmd, which is to provide a single standard mechanism that doesn't rely on any bootloader-specific file formats etc. That mechanism is a raw zImage, a raw initrd, and a plain text extlinux.cfg file to specify things like file paths/names, command-line, etc. The boot.scr support there is legacy, and not something that should be built upon going forward. So, that's not an argument for adding support for a third mechanism! Do we need to adjust the mechanism? The only difference I see is that FIT brings the files together. No, it's just fine as it is. The benefit of the existing mechanism is precisely that nobody has to package the zImage/initrd/... together, whereas that appears to be precisely the purpose of FIT. The two schemes are by definition opposites of each-other. Really? Well zImage is a packaged kernel isn't it? That part of it is definitely opposite. But other than that I don't see why a group of separate files is so different from packaging them together. The zImage packaging is a kernel-internal function implemented (both compression and decompression) fully as part of the kernel build process. Code/... that consumes the kernel doesn't even know that such packaging happens; you can just run make in the kernel tree, and you get a zImage. However, if you want a FIT or uImage, you need to run additional tools beyond a plain make in the kernel tree. Yes I understand that, but what are you getting at? FIT would work the same way if implemented there. Would it make it simpler or
Re: [U-Boot] [PATCH 20/20] tegra: config: nyan-big: Add options required by Chrome OS boot
On 05/19/2015 05:27 PM, Simon Glass wrote: +Tom Rini in case he is interested... Hi Stephen, On 19 May 2015 at 15:36, Stephen Warren swar...@wwwdotorg.org wrote: On 05/19/2015 12:01 PM, Simon Glass wrote: Hi Stephen, On 19 May 2015 at 09:41, Stephen Warren swar...@wwwdotorg.org wrote: On 05/18/2015 03:33 PM, Simon Glass wrote: Hi Stephen, On 15 May 2015 at 09:34, Stephen Warren swar...@wwwdotorg.org wrote: On 05/13/2015 07:56 AM, Simon Glass wrote: Hi Stephen, On 25 February 2015 at 16:31, Stephen Warren swar...@wwwdotorg.org wrote: On 02/17/2015 03:29 PM, Simon Glass wrote: We need to match the device tree in the FIT with the U-Boot model so we can automatically select the right device tree. Also adjust the load address so that the device tree is not in the way when a zImage kernel tries to extract itself. We don't tend to use LOADADDR in any of the default boot scripts any more. Rather, we explicitly load files to a semantic location indicated by one of the following variables in tegra124-common.h: #define MEM_LAYOUT_ENV_SETTINGS \ scriptaddr=0x9000\0 \ pxefile_addr_r=0x9010\0 \ kernel_addr_r=0x8100\0 \ fdt_addr_r=0x8200\0 \ ramdisk_addr_r=0x8210\0 Perhaps the ChromeOS boot scripts could be adjusted to use one/some of those variables? If the value of CONFIG_LOADADDR isn't appropriate, perhaps we should fix it for all Tegra SoCs/boards? I forgot about this comment sorry. I had problems with the image overwriting itself. It is a bzImage inside a FIT so doesn't use the proper FIT decompression. Anyway I'd like to clarify what is meant by kernel_addr_r. Is that where the FIT is loaded or where the kernel will decompress to, or something else? kernel_addr_r is the address in RAM at which a kernel zImage is loaded by config_distro_bootcmd.h scripts (and likely other scripts too). It's usually deliberately chosen to be a fair way into RAM, so that when the zImage decompresses (to approx the start of RAM), the decompressed image doesn't overlap the compressed image at kernel_addr_r. This avoids the kernel decompressor having to move/copy the zImage somewhere else before copying to avoid any overlap during decompression. config_distro_bootcmd.h doesn't support FIT, so I haven't tried out loading FIT images. That said, if U-Boot simply jumps to the location of the kernel in the FIT image itself without any copying, I would expect everything to work fine if you loaded a FIT image to kernel_addr_r. However, if the processing of the FIT image requires the kernel to be copied out of the FIT image to some other location, you'd have to carefully choose that location so it didn't overlap anything. I'd strongly recommend avoiding any unnecessary copies like that though, if at all possible, from the perspective of both pointlessly wasted execution time and simplicity of the boot process. Perhaps storing a a kernel_noload image type inside the FIT rather than a kernel image type might help there? Perhaps you want to introduce a new standard variable that defines where FIT images are loaded. I wonder what would be involved in adjusting config_distro_bootcmd to support FIT? Well, it goes against the very idea of config_distro_bootcmd, which is to provide a single standard mechanism that doesn't rely on any bootloader-specific file formats etc. That mechanism is a raw zImage, a raw initrd, and a plain text extlinux.cfg file to specify things like file paths/names, command-line, etc. The boot.scr support there is legacy, and not something that should be built upon going forward. So, that's not an argument for adding support for a third mechanism! Do we need to adjust the mechanism? The only difference I see is that FIT brings the files together. No, it's just fine as it is. The benefit of the existing mechanism is precisely that nobody has to package the zImage/initrd/... together, whereas that appears to be precisely the purpose of FIT. The two schemes are by definition opposites of each-other. Really? Well zImage is a packaged kernel isn't it? That part of it is definitely opposite. But other than that I don't see why a group of separate files is so different from packaging them together. The zImage packaging is a kernel-internal function implemented (both compression and decompression) fully as part of the kernel build process. Code/... that consumes the kernel doesn't even know that such packaging happens; you can just run make in the kernel tree, and you get a zImage. However, if you want a FIT or uImage, you need to run additional tools beyond a plain make in the kernel tree. Would it make it simpler or harder? To me, we should be moving to using FIT with U-Boot as it is much more flexible and better designed from the ground up to provide the required features. I disagree that FIT is
[U-Boot] [PATCH] imx: dma: correct MXS_DMA_ALIGNMENT
We should not hardcode MXS_DMA_ALIGNMENT to 32, since we can not guarantee that socs' cache line size is 32 bytes. If on chips whose cache line size is 64 bytes, error occurs: NAND: ERROR: v7_dcache_inval_range - start address is not aligned - 0xbdf1d1a0 ERROR: v7_dcache_inval_range - stop address is not aligned - 0xbdf1f4a0 ERROR: v7_dcache_inval_range - start address is not aligned - 0xbdf1d1a0 Align MXS_DMA_ALIGNMENT with ARCH_DMA_MINALIGN whose value is same to CONFIG_SYS_CACHELINE_SIZE if CONFIG_SYS_CACHELINE_SIZE defined. Signed-off-by: Peng Fan peng@freescale.com --- arch/arm/include/asm/imx-common/dma.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/include/asm/imx-common/dma.h b/arch/arm/include/asm/imx-common/dma.h index d5c1f7f..7d421b3 100644 --- a/arch/arm/include/asm/imx-common/dma.h +++ b/arch/arm/include/asm/imx-common/dma.h @@ -22,7 +22,7 @@ #defineDMA_PIO_WORDS CONFIG_ARCH_DMA_PIO_WORDS #endif -#define MXS_DMA_ALIGNMENT 32 +#define MXS_DMA_ALIGNMENT ARCH_DMA_MINALIGN /* * MXS DMA channels -- 1.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 08/10] moveconfig: Print a message for missing compiler
2015-05-20 2:51 GMT+09:00 Joe Hershberger joe.hershber...@gmail.com:
Hi Masahiro-san,
On Mon, May 18, 2015 at 10:23 PM, Masahiro Yamada
yamada.masah...@socionext.com wrote:
2015-05-16 6:40 GMT+09:00 Joe Hershberger joe.hershber...@ni.com:
A common case for failed builds is a missing compiler. Print a message
for that case to tell the user concisely which compiler was expected
that was not found.
This patch also has the effect of not printing build errors any longer.
The next patch will add a switch to optionally bring that back.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
tools/moveconfig.py | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index 9e923da..f986f55 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -166,6 +166,7 @@ import os
import re
import shutil
import subprocess
+from subprocess import PIPE
Personally I do not prefer from ... import
because it disturbs the naming space.
Could you use subprocess.PIPE instead?
OK.
import sys
import tempfile
import time
@@ -606,11 +607,14 @@ class Slot:
return False
if self.ps.poll() != 0:
-
+errmsg = 'Failed to process.'
+errout = self.ps.stderr.read()
This throws exception if make *_defconfig or make savedefconfig fail.
Traceback (most recent call last):
File tools/moveconfig.py, line 924, in module
main()
File tools/moveconfig.py, line 919, in main
move_config(config_attrs, options)
File tools/moveconfig.py, line 794, in move_config
while not slots.available():
File tools/moveconfig.py, line 717, in available
if slot.poll():
File tools/moveconfig.py, line 616, in poll
errout = self.ps.stderr.read()
AttributeError: 'NoneType' object has no attribute 'read'
Seems better to add PIPE for all the call of subprocess.Popen()
OK
+if errout.find('gcc: command not found') != -1:
+errmsg = 'Compiler not found (%s)' % self.cross_compile
If you do this, should the locale be changed?
Without LANG=C, command not found is displayed in Japanese on my computer.
If --verbose is given, we will be able to know the cause of erorr.
missing compiler is a special case error?
That's true, but at least for my use-case before I spent several days
getting all tool-chains working, it was nice to know what the build
was trying to use for a cross tool-chain in a concise one-liner
instead of parsing a bunch of error prints. That's part of why I added
the -v flag. It's also helpful (naturally) in getting the compilers
all working.
OK.
You pass LANG=C in v5, so it works fine for me.
--
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 20/20] tegra: config: nyan-big: Add options required by Chrome OS boot
+Tom Rini in case he is interested... Hi Stephen, On 19 May 2015 at 15:36, Stephen Warren swar...@wwwdotorg.org wrote: On 05/19/2015 12:01 PM, Simon Glass wrote: Hi Stephen, On 19 May 2015 at 09:41, Stephen Warren swar...@wwwdotorg.org wrote: On 05/18/2015 03:33 PM, Simon Glass wrote: Hi Stephen, On 15 May 2015 at 09:34, Stephen Warren swar...@wwwdotorg.org wrote: On 05/13/2015 07:56 AM, Simon Glass wrote: Hi Stephen, On 25 February 2015 at 16:31, Stephen Warren swar...@wwwdotorg.org wrote: On 02/17/2015 03:29 PM, Simon Glass wrote: We need to match the device tree in the FIT with the U-Boot model so we can automatically select the right device tree. Also adjust the load address so that the device tree is not in the way when a zImage kernel tries to extract itself. We don't tend to use LOADADDR in any of the default boot scripts any more. Rather, we explicitly load files to a semantic location indicated by one of the following variables in tegra124-common.h: #define MEM_LAYOUT_ENV_SETTINGS \ scriptaddr=0x9000\0 \ pxefile_addr_r=0x9010\0 \ kernel_addr_r=0x8100\0 \ fdt_addr_r=0x8200\0 \ ramdisk_addr_r=0x8210\0 Perhaps the ChromeOS boot scripts could be adjusted to use one/some of those variables? If the value of CONFIG_LOADADDR isn't appropriate, perhaps we should fix it for all Tegra SoCs/boards? I forgot about this comment sorry. I had problems with the image overwriting itself. It is a bzImage inside a FIT so doesn't use the proper FIT decompression. Anyway I'd like to clarify what is meant by kernel_addr_r. Is that where the FIT is loaded or where the kernel will decompress to, or something else? kernel_addr_r is the address in RAM at which a kernel zImage is loaded by config_distro_bootcmd.h scripts (and likely other scripts too). It's usually deliberately chosen to be a fair way into RAM, so that when the zImage decompresses (to approx the start of RAM), the decompressed image doesn't overlap the compressed image at kernel_addr_r. This avoids the kernel decompressor having to move/copy the zImage somewhere else before copying to avoid any overlap during decompression. config_distro_bootcmd.h doesn't support FIT, so I haven't tried out loading FIT images. That said, if U-Boot simply jumps to the location of the kernel in the FIT image itself without any copying, I would expect everything to work fine if you loaded a FIT image to kernel_addr_r. However, if the processing of the FIT image requires the kernel to be copied out of the FIT image to some other location, you'd have to carefully choose that location so it didn't overlap anything. I'd strongly recommend avoiding any unnecessary copies like that though, if at all possible, from the perspective of both pointlessly wasted execution time and simplicity of the boot process. Perhaps storing a a kernel_noload image type inside the FIT rather than a kernel image type might help there? Perhaps you want to introduce a new standard variable that defines where FIT images are loaded. I wonder what would be involved in adjusting config_distro_bootcmd to support FIT? Well, it goes against the very idea of config_distro_bootcmd, which is to provide a single standard mechanism that doesn't rely on any bootloader-specific file formats etc. That mechanism is a raw zImage, a raw initrd, and a plain text extlinux.cfg file to specify things like file paths/names, command-line, etc. The boot.scr support there is legacy, and not something that should be built upon going forward. So, that's not an argument for adding support for a third mechanism! Do we need to adjust the mechanism? The only difference I see is that FIT brings the files together. No, it's just fine as it is. The benefit of the existing mechanism is precisely that nobody has to package the zImage/initrd/... together, whereas that appears to be precisely the purpose of FIT. The two schemes are by definition opposites of each-other. Really? Well zImage is a packaged kernel isn't it? That part of it is definitely opposite. But other than that I don't see why a group of separate files is so different from packaging them together. Would it make it simpler or harder? To me, we should be moving to using FIT with U-Boot as it is much more flexible and better designed from the ground up to provide the required features. I disagree that FIT is a good idea, but that's a separate topic. Anyway, normally FIT has a compressed kernel (e.g. with LZO), not a bzImage. Do you mean FIT normally contains an originally uncompressed kernel (i.e. an Image file in ARM land at least), but then compresses it itself as part of FIT image generation? A bzImage is also a compressed kernel. That's right, that's what I mean. So it seems like we need an additional decompression address. I
Re: [U-Boot] [PATCH v2] tools: moveconfig: a tool to move CONFIGs from headers to defconfigs
2015-05-20 0:33 GMT+09:00 Joe Hershberger joe.hershber...@gmail.com: +if len(failed_boards) 0: +msg = [ The following boards were not processed due to error: ] +msg += failed_boards +print msg This is an extra print. Fixed. Thanks! -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Fix fsl_elbc_nand driver
On Tue, 2015-05-19 at 17:38 -0500, Scott Wood wrote:
On Tue, 2015-05-19 at 15:29 -0700, Andrei Yakimov wrote:
I did not compiling latest, I still in 2011.9 and 2.6.38.
I have go over latest kernel and can see they using
NAND_CMD_PARAM with sub command 0x40 - to get JEDEC
information, it is 3 mandatory copy by 512 bytes.
3x512 or 3x256?
ONFI - 3x256 sub command 0x0
JEDEC - 3x512 sub command 0x40
Going over kernel divers, figure out some read whole
page some 256 bytes.
Reading whole page (set fcbr = 0) have some sense - you do not need
to know anything about flash, but what to put in to read_bytes ?
You don't want fbcr = 0 here because that will enable ECC which isn't
there.
Is it correcting or just generating syndrome? It is working on
my board, I would say it only generate or ignored for this command
(8313). It should corrupt data if it correcting but it does not.
It looks like for universal patch 2K should be read.
Again, if we're going to do anything beyond s/256/768/ it should be a
higher level function where the caller says how much it wants.
It is not normal nand flow: READ_ID and PARAM assuming it know the
size.
I have also check other vendor controllers like tegra,
there continuous data read trigger additional data transfer from
chip.
Can we do (NOP CWO UA RWB RS RS RS RS)
wait ltesr (cc) and after that
next read_buffer ( RB or RS)
all command have to start with NOP,
this will effectively terminate previous command.
And we do not care about locks in u-boot. kernel will be different
store, but again this code executed only during start up - so who care
holding CS to long.
there is only 4 places for PARAM:
drivers/mtd/nand/mxs_nand_spl.c chip-cmdfunc(mtd, NAND_CMD_PARAM, 0,
-1);
drivers/mtd/nand/nand_base.c: chip-cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
drivers/mtd/nand/nand_base.c: chip-cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
drivers/mtd/nand/nand_base.c: chip-cmdfunc(mtd, NAND_CMD_PARAM, 0x40,
-1);
latest kernel read it like this:
chip-cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
for (i = 0; i 3; i++) {
for (j = 0; j sizeof(*p); j++)
((uint8_t *)p)[j] = chip-read_byte(mtd);
if (onfi_crc16(ONFI_CRC_BASE, (uint8_t *)p, 254) ==
le16_to_cpu(p-crc)) {
break;
}
}
Yes, that's how the hardware works, but controllers like eLBC don't
directly expose that interface. We need to get all of the command's
output at once.
This kind of implementation better, but I did not see how it could
be done for this controller.
I wouldn't say it's better so much as a closer fit to what the Linux
NAND code is expecting.
I am not sure how is small page (512 byte) flash should operate
also.
Is there any small-page ONFI flash?
I do not know.
ONFI parameter page will tell you page size:
80-83 M Number of data bytes per page
84-85 M Number of spare bytes per page
if we drop it, lets set to 2k and forget.
Why did you take this e-mail off-list?
Sorry just forgot.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] tools: moveconfig: a tool to move CONFIGs from headers to defconfigs
This tool was originally written for my local use to ease the task of tons of CONFIG moves, but there have been some requests for mainlining it. So, I have tidied up the code with nicer comments, and here it is. See the comment block of the script for usage. The first draft was http://patchwork.ozlabs.org/patch/430422/ Main updates are: - Adapted to the single .config configuration - Support colored log - Support moving multiple options at once (and take configs via input file only) - Continue even if some boards fail (Idea provided by Joe Hershberger) - Add more options - More comments and code cleanups Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com Signed-off-by: Joe Hershberger joe.hershber...@ni.com --- Changes in v3: - Drop the debug code print msg - Change the CROSS_COMPILE mapping for sh - Update comments about toolchains URLs Changes in v2: - Fix comments - Map arc toolchain - Add dry-run option tools/moveconfig.py | 853 1 file changed, 853 insertions(+) create mode 100755 tools/moveconfig.py diff --git a/tools/moveconfig.py b/tools/moveconfig.py new file mode 100755 index 000..7b788f1 --- /dev/null +++ b/tools/moveconfig.py @@ -0,0 +1,853 @@ +#!/usr/bin/env python2 +# +# Author: Masahiro Yamada yamada.masah...@socionext.com +# +# SPDX-License-Identifier: GPL-2.0+ +# + + +Move config options from headers to defconfig files. + +Since Kconfig was introduced to U-Boot, we have worked on moving +config options from headers to Kconfig (defconfig). + +This tool intends to help this tremendous work. + + +Usage +- + +This tool takes one input file. (let's say 'recipe' file here.) +The recipe describes the list of config options you want to move. +Each line takes the form: +config_name type default +(the fields must be separated with whitespaces.) + +config_name is the name of config option. + +type is the type of the option. It must be one of bool, tristate, +string, int, and hex. + +default is the default value of the option. It must be appropriate +value corresponding to the option type. It must be either y or n for +the bool type. Tristate options can also take m (although U-Boot has +not supported the module feature). + +You can add two or more lines in the recipe file, so you can move +multiple options at once. + +Let's say, for example, you want to move CONFIG_CMD_USB and +CONFIG_SYS_TEXT_BASE. + +The type should be bool, hex, respectively. So, the recipe file +should look like this: + + $ cat recipe + CONFIG_CMD_USB bool n + CONFIG_SYS_TEXT_BASE hex 0x + +And then run this tool giving the file name of the recipe + + $ tools/moveconfig.py recipe + +The tool walks through all the defconfig files to move the config +options specified by the recipe file. + +The log is also displayed on the terminal. + +Each line is printed in the format +defconfig_name : action + +defconfig_name is the name of the defconfig +(without the suffix _defconfig). + +action shows what the tool did for that defconfig. +It looks like one of the followings: + + - Move 'CONFIG_... ' + This config option was moved to the defconfig + + - Default value 'CONFIG_...'. Do nothing. + The value of this option is the same as default. + We do not have to add it to the defconfig. + + - 'CONFIG_...' already exists in Kconfig. Do nothing. + This config option is already defined in Kconfig. + We do not need/want to touch it. + + - Undefined. Do nothing. + This config option was not found in the config header. + Nothing to do. + + - Failed to process. Skip. + An error occurred during processing this defconfig. Skipped. + (If -e option is passed, the tool exits immediately on error.) + +Finally, you will be asked, Clean up headers? [y/n]: + +If you say 'y' here, the unnecessary config defines are removed +from the config headers (include/configs/*.h). +It just uses the regex method, so you should not rely on it. +Just in case, please do 'git diff' to see what happened. + + +How does it works? +-- + +This tool runs configuration and builds include/autoconf.mk for every +defconfig. The config options defined in Kconfig appear in the .config +file (unless they are hidden because of unmet dependency.) +On the other hand, the config options defined by board headers are seen +in include/autoconf.mk. The tool looks for the specified options in both +of them to decide the appropriate action for the options. If the option +is found in the .config or the value is the same as the specified default, +the option does not need to be touched. If the option is found in +include/autoconf.mk, but not in the .config, and the value is different +from the default, the tools adds the option to the defconfig. + +For faster processing, this tool handles multi-threading. It creates +separate build directories where the out-of-tree build is run. The +temporary build directories are
[U-Boot] [PATCH v4] tools: moveconfig: a tool to move CONFIGs from headers to defconfigs
This tool was originally written for my local use to ease the task of tons of CONFIG moves, but there have been some requests for mainlining it. So, I have tidied up the code with nicer comments, and here it is. See the comment block of the script for usage. The first draft was http://patchwork.ozlabs.org/patch/430422/ Main updates are: - Adapted to the single .config configuration - Support colored log - Support moving multiple options at once (and take configs via input file only) - Continue even if some boards fail (Idea provided by Joe Hershberger) - Add more options - More comments and code cleanups Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com Signed-off-by: Joe Hershberger joe.hershber...@ni.com --- Changes in v4: - Fix arm cross_compile mapping that was degraded by v3 Changes in v3: - Drop the debug code print msg - Change the CROSS_COMPILE mapping for sh - Update comments about toolchains URLs Changes in v2: - Fix comments - Map arc toolchain - Add dry-run option tools/moveconfig.py | 853 1 file changed, 853 insertions(+) create mode 100755 tools/moveconfig.py diff --git a/tools/moveconfig.py b/tools/moveconfig.py new file mode 100755 index 000..b5abf56 --- /dev/null +++ b/tools/moveconfig.py @@ -0,0 +1,853 @@ +#!/usr/bin/env python2 +# +# Author: Masahiro Yamada yamada.masah...@socionext.com +# +# SPDX-License-Identifier: GPL-2.0+ +# + + +Move config options from headers to defconfig files. + +Since Kconfig was introduced to U-Boot, we have worked on moving +config options from headers to Kconfig (defconfig). + +This tool intends to help this tremendous work. + + +Usage +- + +This tool takes one input file. (let's say 'recipe' file here.) +The recipe describes the list of config options you want to move. +Each line takes the form: +config_name type default +(the fields must be separated with whitespaces.) + +config_name is the name of config option. + +type is the type of the option. It must be one of bool, tristate, +string, int, and hex. + +default is the default value of the option. It must be appropriate +value corresponding to the option type. It must be either y or n for +the bool type. Tristate options can also take m (although U-Boot has +not supported the module feature). + +You can add two or more lines in the recipe file, so you can move +multiple options at once. + +Let's say, for example, you want to move CONFIG_CMD_USB and +CONFIG_SYS_TEXT_BASE. + +The type should be bool, hex, respectively. So, the recipe file +should look like this: + + $ cat recipe + CONFIG_CMD_USB bool n + CONFIG_SYS_TEXT_BASE hex 0x + +And then run this tool giving the file name of the recipe + + $ tools/moveconfig.py recipe + +The tool walks through all the defconfig files to move the config +options specified by the recipe file. + +The log is also displayed on the terminal. + +Each line is printed in the format +defconfig_name : action + +defconfig_name is the name of the defconfig +(without the suffix _defconfig). + +action shows what the tool did for that defconfig. +It looks like one of the followings: + + - Move 'CONFIG_... ' + This config option was moved to the defconfig + + - Default value 'CONFIG_...'. Do nothing. + The value of this option is the same as default. + We do not have to add it to the defconfig. + + - 'CONFIG_...' already exists in Kconfig. Do nothing. + This config option is already defined in Kconfig. + We do not need/want to touch it. + + - Undefined. Do nothing. + This config option was not found in the config header. + Nothing to do. + + - Failed to process. Skip. + An error occurred during processing this defconfig. Skipped. + (If -e option is passed, the tool exits immediately on error.) + +Finally, you will be asked, Clean up headers? [y/n]: + +If you say 'y' here, the unnecessary config defines are removed +from the config headers (include/configs/*.h). +It just uses the regex method, so you should not rely on it. +Just in case, please do 'git diff' to see what happened. + + +How does it works? +-- + +This tool runs configuration and builds include/autoconf.mk for every +defconfig. The config options defined in Kconfig appear in the .config +file (unless they are hidden because of unmet dependency.) +On the other hand, the config options defined by board headers are seen +in include/autoconf.mk. The tool looks for the specified options in both +of them to decide the appropriate action for the options. If the option +is found in the .config or the value is the same as the specified default, +the option does not need to be touched. If the option is found in +include/autoconf.mk, but not in the .config, and the value is different +from the default, the tools adds the option to the defconfig. + +For faster processing, this tool handles multi-threading. It creates +separate build directories
Re: [U-Boot] [PATCH v4 03/10] moveconfig: Add a parameter to accept a list to build
2015-05-20 2:58 GMT+09:00 Joe Hershberger joe.hershber...@gmail.com:
Hi Masahiro-san,
On Mon, May 18, 2015 at 11:33 PM, Masahiro Yamada
yamada.masah...@socionext.com wrote:
2015-05-16 6:40 GMT+09:00 Joe Hershberger joe.hershber...@ni.com:
This is helpful to re-attempt to move failed boards from a previous run
without starting over.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v4: None
Changes in v3:
-Fixed command line options order (alphabetize)
Changes in v2:
-New for version 2
tools/moveconfig.py | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index d3009de..3f31e81 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -135,6 +135,9 @@ Available options
Surround each portion of the log with escape sequences to display it
in color on the terminal.
+ -d, --defconfigs
+ Specify a file containing a list of defconfigs to move
+
-n, --dry-run
Peform a trial run that does not make any changes. It is useful to
see what is going to happen before one actually runs it.
@@ -734,12 +737,21 @@ def move_config(config_attrs, options):
config_attr['type'],
config_attr['default'])
-# All the defconfig files to be processed
-defconfigs = []
-for (dirpath, dirnames, filenames) in os.walk('configs'):
-dirpath = dirpath[len('configs') + 1:]
-for filename in fnmatch.filter(filenames, '*_defconfig'):
-defconfigs.append(os.path.join(dirpath, filename))
+if options.defconfigs:
+defconfigs = [line.strip() for line in open(options.defconfigs,
'r')]
+for i, defconfig in enumerate(defconfigs):
+if not defconfig.endswith('_defconfig'):
+defconfigs[i] = defconfig + '_defconfig'
+if not os.path.exists(os.path.join('configs', defconfigs[i])):
+sys.exit('%s - defconfig does not exist. Stopping.' %
+ defconfigs[i])
'r' is redundant for open() because read-mode is default.
OK.
moveconfig.failed always prefixes _defconfig,
so we need not to do so again, I think. (or will we make this file by hand?)
I have done both moveconfig.failed as well as a hand-written file for
testing certain boards. That's why I added both the append
'_defconfig' as well as the check for it actually existing.
Then, we can drop enumarate and write the error message within 80 columns.
if options.defconfigs:
defconfigs = [line.strip() for line in open(options.defconfigs)]
for defconfig in defconfigs:
if not os.path.exists(os.path.join('configs', defconfig)):
sys.exit('%s: defconfig does not exist. Stopping.' %
defconfig)
I think we should keep the check for endswith('_defconfig').
OK, then. Let's keep it.
--
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env_nand: use nand_spl_load_image for readenv if SPL
Hi Tim, On 15/05/2015 20:59, Scott Wood wrote: On Thu, 2015-05-14 at 11:48 -0700, Tim Harvey wrote: The readenv() implementation of env_nand uses the mtd layer which is unnecessary overhead in SPL when we already have a nand_spl_load_image() function that doesn't need it. Using this instead eliminates the need to provide a mtd_read for SPL env as well as reduces code (4KB savings in IMX6 SPL). Signed-off-by: Tim Harvey thar...@gateworks.com --- common/env_nand.c | 7 +++ 1 file changed, 7 insertions(+) Acked-by: Scott Wood scottw...@freescale.com Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] imx: riotboard: Enable thermal DM support
On 18/05/2015 01:10, Nikolay Dimitrov wrote: Signed-off-by: Nikolay Dimitrov picmas...@mail.bg --- configs/riotboard_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/riotboard_defconfig b/configs/riotboard_defconfig index c0b689b..ae0036a 100644 --- a/configs/riotboard_defconfig +++ b/configs/riotboard_defconfig @@ -1,3 +1,5 @@ CONFIG_ARM=y CONFIG_TARGET_EMBESTMX6BOARDS=y CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6s1g.cfg,MX6S,DDR_MB=1024,ENV_IS_IN_MMC +CONFIG_DM=y +CONFIG_DM_THERMAL=y Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] imx: marsboard: Enable thermal DM support
On 18/05/2015 01:10, Nikolay Dimitrov wrote: Signed-off-by: Nikolay Dimitrov picmas...@mail.bg --- configs/marsboard_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/marsboard_defconfig b/configs/marsboard_defconfig index f54fdd0..460e2d0 100644 --- a/configs/marsboard_defconfig +++ b/configs/marsboard_defconfig @@ -1,3 +1,5 @@ CONFIG_ARM=y CONFIG_TARGET_EMBESTMX6BOARDS=y CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q.cfg,MX6Q,DDR_MB=1024,ENV_IS_IN_SPI_FLASH +CONFIG_DM=y +CONFIG_DM_THERMAL=y Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 19/19] imx: ventana: config: enable Falcon mode
On Mon, May 18, 2015 at 4:25 PM, Fabio Estevam feste...@gmail.com wrote: Hi Tim, On Fri, May 8, 2015 at 10:28 PM, Tim Harvey thar...@gateworks.com wrote: Falcon mode entails the SPL booting the OS directly instead of U-Boot. I would like to give this a try, but I am not sure where the dtb should be placed in the SD card. Or are you combining the dtb and zImage into a single binary? Do you have a small README that shows how the user should use Falcon mode? Thanks! Fabio, I will be posting a README in the next day or so to document Falcon mode usage on the Gateworks Ventana boards. In general the documentation will be the same for any board using it but I'll provide some detail about where things are stored in flash/mmc and what #defines control that. As a general rule though, when using Falcon mode for a device-tree kernel the dtb must get loaded and processed via the 'spl export fdt' command which you provide the kernel and dtb address in RAM you've loaded them to because U-Boot will tweak the dtb then allow you to store it back. This is documented pretty well currently in doc/README.falcon. You have to understand that the steps normally taken by U-Boot will be skipped in Falcon mode as you go straight from SPL to OS. In the general case this means your SPL must do anything that U-Boot typically does for fixups including GPIO configuration (pinmux, padctl, output/direction) for things the kernel may not be supporting (hence my recent patches that move or replicate some of Ventana U-Boot capability in the SPL). For the Linux OS case the SPL must do what the bootm U-Boot command would have done which is to load the dtb, make adjustments (enet macs, mtdparts, memsize, console args, anything in ft_board_setup(), etc) and it does this by using the spl export command which goes through all the steps that bootm does 'except' for jumping to the kernel. Then you take the mem area that spl export left the 'args' typically passed to the kernel and store that to your non-volatile storage so that when the SPL boots in 'OS mode' it loads the kernel, loads the pre-prepared args and jumps. Note that Falcon mode also requires you have a function in the SPL that decides to boot U-Boot or to skip it and boot the OS directly. In the Gateworks Ventana case I didn't want to make this completely dependent on a GPIO/Button because this bootloader supports about 8 different PCB designs in the Ventana family - some of which do not have buttons or may not have buttons loaded on the board. Instead, I pulled env support into the SPL and use 'boot_os' env var to decide as other boards do (see spl_start_uboot()). I also have the Ventana config build in support for both NAND and MMC so that in general the same SPL/U-Boot can be used on Ventana boards with or without NAND. U-Boot however currently does not support multiple environment backing stores, so only NAND env is defined meaning Falcon mode for Ventana on a nand-less board won't really work right as it will try to read env from NAND. I have a downstream patch that adds multiple env support which reads env from whatever the boot device was, however I have not posted this patch yet and I don't expect it will be accepted because it was desired for me to re-write env support instead which was a large undertaking I don't have time for. Until then, mainline U-Boot only supports Falcon mode on NAND for Ventana (which is the vast majority of the Ventana boards). Regards, Tim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] sunxi: Make dram odt-en configurable through Kconfig for A33 based boards
Hi, On 17-05-15 12:25, Ian Campbell wrote: On Fri, 2015-05-15 at 20:43 +0200, Hans de Goede wrote: Some A33 based boards use odt, while others do not, so make odt_en configurable for sun8i too by moving the existing Kconfig option for it out of the #if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I block it was in. I'm still not mad-keen on overloading an int Kconfig with boolean semantics. _Especially_ if it has different semantics on different generations of DRAM controller, that's even worse than before IMHO. I think we should either: Have two Kconfig options an int on SUN[457]I and a bool on SUN8I. Whether or not they have the same name I don't know, consider adding GENx to it perhaps? -or- Have a single option which is an int which has similar semantics on both. This could be ODT_EN[0] == enable, and: ODT_EN[31:1]==reserved on SUN8I but ODT_EN[7:1]==reserved,[15:8]==correction,[31:16]==reserved on the others. The main upshot here, apart from improved help text for the option, would be adding 0x1 to the usage in SUN8I. Is there any reason not to push odt_en through dram_para like on other subarches? Or conversely any reason for those others not to use the Kconfig directly? The second option sounds like a simpler change from where the code is today, but perhaps we prefer not to invent semantics in this way. FWIW if you were to prefer the first option above then going via dram_param would make the use of IS_ENABLED (to assign to a boolean field in the param struct) much less ugly than with the existing structure of the code. + Set the dram controller odt_en parameter. This can be used to + enable/disable the ODT feature. This isn't strictly correct/true on SUN8I since we don't set odt_en in the params. Ok, I think I've a good solution for this now, which actually makes it a bool, v3 of this patch is coming up. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] sunxi: Make DRAM_ODT_EN Kconfig setting a bool
Make DRAM_ODT_EN Kconfig setting a bool, add a separate DRAM_ODT_CORRECTION
setting for A23 SoCs and use DRAM_ODT_EN Kconfig everywhere instead of
only in dram_sun4i.c and hardcoding odt_en elsewhere.
Note this commit makes no functional changes for existing boards,
its purpose is to allow changing the odt_en value on future A33 boards.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v2:
-Use existing DRAM_ODT_EN Kconfig block moving it out of the
#if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I block it was in
Changes in v3:
-Complete rewrite of the patch
---
arch/arm/cpu/armv7/sunxi/dram_sun4i.c| 4 ++--
arch/arm/cpu/armv7/sunxi/dram_sun8i_a23.c| 19 +--
arch/arm/cpu/armv7/sunxi/dram_sun8i_a33.c| 4 ++--
arch/arm/include/asm/arch-sunxi/dram_sun4i.h | 3 +--
arch/arm/include/asm/arch-sunxi/dram_sun8i_a23.h | 1 +
board/sunxi/Kconfig | 22 +++---
board/sunxi/dram_sun4i_auto.c| 3 ++-
board/sunxi/dram_sun5i_auto.c| 3 ++-
8 files changed, 34 insertions(+), 25 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
b/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
index c736fa3..f7b4915 100644
--- a/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
+++ b/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
@@ -508,7 +508,7 @@ static void mctl_ddr3_initialize(void)
/*
* Perform impedance calibration on the DRAM controller side of the wire.
*/
-static void mctl_set_impedance(u32 zq, u32 odt_en)
+static void mctl_set_impedance(u32 zq, bool odt_en)
{
struct sunxi_dram_reg *dram = (struct sunxi_dram_reg *)SUNXI_DRAMC_BASE;
u32 reg_val;
@@ -556,7 +556,7 @@ static void mctl_set_impedance(u32 zq, u32 odt_en)
clrbits_le32(dram-zqcr0, DRAM_ZQCR0_ZCAL);
/* Set I/O configure register */
- writel(DRAM_IOCR_ODT_EN(odt_en), dram-iocr);
+ writel(DRAM_IOCR_ODT_EN, dram-iocr);
}
static unsigned long dramc_init_helper(struct dram_para *para)
diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun8i_a23.c
b/arch/arm/cpu/armv7/sunxi/dram_sun8i_a23.c
index 3d7964d..165c052 100644
--- a/arch/arm/cpu/armv7/sunxi/dram_sun8i_a23.c
+++ b/arch/arm/cpu/armv7/sunxi/dram_sun8i_a23.c
@@ -26,12 +26,14 @@
#include asm/arch/clock.h
#include asm/arch/dram.h
#include asm/arch/prcm.h
+#include linux/kconfig.h
static const struct dram_para dram_para = {
.clock = CONFIG_DRAM_CLK,
.type = 3,
.zq = CONFIG_DRAM_ZQ,
- .odt_en = 1,
+ .odt_en = IS_ENABLED(CONFIG_DRAM_ODT_EN),
+ .odt_correction = CONFIG_DRAM_ODT_CORRECTION,
.para1 = 0, /* not used (only used when tpr13 bit 31 is set */
.para2 = 0, /* not used (only used when tpr13 bit 31 is set */
.mr0 = 6736,
@@ -97,7 +99,6 @@ static void mctl_init(u32 *bus_width)
(struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
struct sunxi_mctl_phy_reg * const mctl_phy =
(struct sunxi_mctl_phy_reg *)SUNXI_DRAM_PHY0_BASE;
- int correction;
if (dram_para.tpr13 0x20)
writel(0x40b, mctl_phy-dcr);
@@ -138,7 +139,7 @@ static void mctl_init(u32 *bus_width)
writel(0x0181, mctl_phy-dtcr);
- if (dram_para.clock = 240 || !(dram_para.odt_en 0x01)) {
+ if (dram_para.clock = 240 || !dram_para.odt_en) {
clrbits_le32(mctl_phy-dx0gcr, 0x600);
clrbits_le32(mctl_phy-dx1gcr, 0x600);
}
@@ -251,13 +252,11 @@ static void mctl_init(u32 *bus_width)
} else
*bus_width = 16;
- correction = (dram_para.odt_en 8) 0xff;
- if (correction) {
- if (dram_para.odt_en 0x8000)
- correction = -correction;
-
- mctl_apply_odt_correction(mctl_phy-dx0lcdlr1, correction);
- mctl_apply_odt_correction(mctl_phy-dx1lcdlr1, correction);
+ if (dram_para.odt_correction) {
+ mctl_apply_odt_correction(mctl_phy-dx0lcdlr1,
+ dram_para.odt_correction);
+ mctl_apply_odt_correction(mctl_phy-dx1lcdlr1,
+ dram_para.odt_correction);
}
mctl_await_completion(mctl_ctl-statr, 0x01, 0x01);
diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun8i_a33.c
b/arch/arm/cpu/armv7/sunxi/dram_sun8i_a33.c
index 979bb3c..ebba438 100644
--- a/arch/arm/cpu/armv7/sunxi/dram_sun8i_a33.c
+++ b/arch/arm/cpu/armv7/sunxi/dram_sun8i_a33.c
@@ -14,12 +14,12 @@
#include asm/arch/clock.h
#include asm/arch/dram.h
#include asm/arch/prcm.h
+#include linux/kconfig.h
/* PLL runs at 2x dram-clk, controller runs at PLL / 4 (dram-clk / 2) */
#define DRAM_CLK_MUL 2
#define DRAM_CLK_DIV 4
#define DRAM_SIGMA_DELTA_ENABLE 1
-#define DRAM_ODT_EN 0
struct dram_para {
u8 cs1;
@@ -215,7 +215,7 @@ static int mctl_channel_init(struct dram_para *para)
clrbits_le32(mctl_ctl-pgcr0, 0x3f
Re: [U-Boot] [PATCH] hummingboard: Remove unused directory
On 15/05/2015 21:10, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com The 'mx6-microsom' directory was only used for the previous mx6solo hummingboard support, which has been removed in favour of the SPL version. Remove the remaining piece of the old mx6solo hummingboard support. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- board/solidrun/mx6-microsom/800mhz_2x128mx16.cfg | 74 - board/solidrun/mx6-microsom/clocks.cfg | 33 -- .../mx6-microsom/ddr-800mhz-32bit-setup.cfg| 76 -- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm/imx-common: Fix warning 'get_reset_cause' defined but not used
On 18/05/2015 13:43, Prabhakar Kushwaha wrote: Fix below warning arch/arm/imx-common/cpu.c:29:14: warning: ‘get_reset_cause’ defined but not used static char *get_reset_cause(void) Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/10 v2] i.MX6: move duplicated options to mx6_common to standardise mx6 config
Hi Peter, On 11/05/2015 18:22, Peter Robinson wrote: There's a lot of common options in the i.MX6 boards that are repeated across a lot of the devices. There's a mx6_common.h which is little used but makes sense to be the central location for all the options we want across all mx6 boards to ensure a consistent set of features. This is a first pass at moving those options and unifying the common options to a standard default. Changes since v1: * Move CONFIG_SYS_NO_FLASH changes from patch 7 to patch 2 and reorder includes so we don't need to undef CONFIG_CMD_FLASH / CONFIG_CMD_IMLS * Add CONFIG_CMD_GPIO to mx6_common.f (patch 5) * Use the default for all CONFIG_SYS_PROMPT_HUSH_PS2 (patch 7) * Drop LZO change (patch 8) I think I got all the review points :) Peter Robinson (10): novena: standardise mx6_common.h include imx6: move all standard includes to mx6_common.h imx6: move generic imx6 options to mx6_common.h imx6: move standard ATAG configs to mx6_common.h imx6: move MXC_GPIO define to mx6_common.h imx6: centralise common boot options in mx6_common.h imx6: move generic miscellaneous and overwrite options imx6: standardise filesystem and boot options imx6: generic MMC config options to mx6_common mx6: standardise CONFIG_CMD_CACHE Reviewed-by: Eric Nelson eric.nel...@boundarydevices.com Applying your patchset (I had to merge something due to changes in tree), I get several warnings due to duplicated #define. For example, tqma6 defines CONFIG_SYS_TEXT_BASE. I agree to have it in mx6_common, we need a #undef CONFIG_SYS_TEXT_BASE in the board configuration file for boards (like tqma6) that redefines it. CONFIG_BOOTDELAY is also set in config_distro_defaults, and it generates also a warning - maybe we have to remove it from mx6_common.h Can you check these issues and repost a V3 on current u-boot-imx tree ? Thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] imx: riotboard, marsboard: Enable thermal support
On 18/05/2015 01:10, Nikolay Dimitrov wrote: Signed-off-by: Nikolay Dimitrov picmas...@mail.bg --- include/configs/embestmx6boards.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/embestmx6boards.h b/include/configs/embestmx6boards.h index e9f5bed..16b5826 100644 --- a/include/configs/embestmx6boards.h +++ b/include/configs/embestmx6boards.h @@ -36,6 +36,7 @@ #define CONFIG_SETUP_MEMORY_TAGS #define CONFIG_INITRD_TAG #define CONFIG_REVISION_TAG +#define CONFIG_IMX6_THERMAL /* Size of malloc() pool */ #define CONFIG_SYS_MALLOC_LEN(10 * SZ_1M) Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx6sx enable SION for i2c pin mux
Hi Peng, On 18/05/2015 07:37, Peng Fan wrote: Enable IOMUX_CONFIG_SION for all I2C pin mux settings, otherwise we will get erros when doing i2c operations. error log like the following: wait_for_sr_state: failed sr=81 cr=a0 state=2020 i2c_init_transfer: failed for chip 0xb retry=1 Signed-off-by: Peng Fan peng@freescale.com --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: mx6: ddr: set fast-exit on DDR3 if pd_fast_exit specified
On 18/05/2015 16:07, Tim Harvey wrote: Commit fa8b7d66f49f0c7bd41467fe78f6488d8af6976a introduced fast-exit support to the MMDC however enabling it on the DDR3 got missed. Make sure we enable it on the DDR3 as well. Gateworks uses Micron memory as well as Winbond in MX6. We have found in testing that we need to enable fast-exit for Winbond stability. Gateworks boards are currently the only boards using the MX6 SPL and enabling fast-exit mode. Signed-off-by: Tim Harvey thar...@gateworks.com --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 19/19] imx: ventana: config: enable Falcon mode
Hi Tim, On Tue, May 19, 2015 at 10:26 AM, Tim Harvey thar...@gateworks.com wrote: Fabio, I will be posting a README in the next day or so to document Falcon mode usage on the Gateworks Ventana boards. In general the documentation will be the same for any board using it but I'll provide some detail about where things are stored in flash/mmc and what #defines control that. As a general rule though, when using Falcon mode for a device-tree kernel the dtb must get loaded and processed via the 'spl export fdt' command which you provide the kernel and dtb address in RAM you've loaded them to because U-Boot will tweak the dtb then allow you to store it back. This is documented pretty well currently in doc/README.falcon. You have to understand that the steps normally taken by U-Boot will be skipped in Falcon mode as you go straight from SPL to OS. In the general case this means your SPL must do anything that U-Boot typically does for fixups including GPIO configuration (pinmux, padctl, output/direction) for things the kernel may not be supporting (hence my recent patches that move or replicate some of Ventana U-Boot capability in the SPL). For the Linux OS case the SPL must do what the bootm U-Boot command would have done which is to load the dtb, make adjustments (enet macs, mtdparts, memsize, console args, anything in ft_board_setup(), etc) and it does this by using the spl export command which goes through all the steps that bootm does 'except' for jumping to the kernel. Then you take the mem area that spl export left the 'args' typically passed to the kernel and store that to your non-volatile storage so that when the SPL boots in 'OS mode' it loads the kernel, loads the pre-prepared args and jumps. Note that Falcon mode also requires you have a function in the SPL that decides to boot U-Boot or to skip it and boot the OS directly. In the Gateworks Ventana case I didn't want to make this completely dependent on a GPIO/Button because this bootloader supports about 8 different PCB designs in the Ventana family - some of which do not have buttons or may not have buttons loaded on the board. Instead, I pulled env support into the SPL and use 'boot_os' env var to decide as other boards do (see spl_start_uboot()). I also have the Ventana config build in support for both NAND and MMC so that in general the same SPL/U-Boot can be used on Ventana boards with or without NAND. U-Boot however currently does not support multiple environment backing stores, so only NAND env is defined meaning Falcon mode for Ventana on a nand-less board won't really work right as it will try to read env from NAND. I have a downstream patch that adds multiple env support which reads env from whatever the boot device was, however I have not posted this patch yet and I don't expect it will be accepted because it was desired for me to re-write env support instead which was a large undertaking I don't have time for. Until then, mainline U-Boot only supports Falcon mode on NAND for Ventana (which is the vast majority of the Ventana boards). Thanks for your work on this and for your detailed reply! I will give Falcon mode a try. Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] sunxi: Make DRAM_ODT_EN Kconfig setting a bool
On Tue, 2015-05-19 at 14:56 +0200, Hans de Goede wrote:
diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
b/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
index c736fa3..f7b4915 100644
--- a/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
+++ b/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
@@ -508,7 +508,7 @@ static void mctl_ddr3_initialize(void)
/*
* Perform impedance calibration on the DRAM controller side of the wire.
*/
-static void mctl_set_impedance(u32 zq, u32 odt_en)
+static void mctl_set_impedance(u32 zq, bool odt_en)
{
struct sunxi_dram_reg *dram = (struct sunxi_dram_reg *)SUNXI_DRAMC_BASE;
u32 reg_val;
@@ -556,7 +556,7 @@ static void mctl_set_impedance(u32 zq, u32 odt_en)
clrbits_le32(dram-zqcr0, DRAM_ZQCR0_ZCAL);
/* Set I/O configure register */
- writel(DRAM_IOCR_ODT_EN(odt_en), dram-iocr);
+ writel(DRAM_IOCR_ODT_EN, dram-iocr);
I think at this point previously odt_en would always be 0x1 here (0x0
having been short circuited earlier).
Whereas this...
-#define DRAM_IOCR_ODT_EN(n) n) 0x3) 30) | ((n) 0x3) 0)
-#define DRAM_IOCR_ODT_EN_MASK DRAM_IOCR_ODT_EN(0x3)
+#define DRAM_IOCR_ODT_EN ((3 30) | (3 0))
... now behaves as if it were always 0x3.
AFAICT up until now, at least with the in-tree defconfigs, odt_en was
always 0 for sun4i anyway, but this is a surprising change I think.
DRAM_IOCR_ODT_EN_MASK (which did use 0x3) seems to have been unused. in
tree.
diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun8i_a23.h
b/arch/arm/include/asm/arch-sunxi/dram_sun8i_a23.h
index 06adee2..316a333 100644
--- a/arch/arm/include/asm/arch-sunxi/dram_sun8i_a23.h
+++ b/arch/arm/include/asm/arch-sunxi/dram_sun8i_a23.h
@@ -19,6 +19,7 @@ struct dram_para {
u32 type;
u32 zq;
u32 odt_en;
Make this (and maybe others) an actual bool?
Keeping it a u32 might make hex editing easier though?
Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 17/19] imx: ventana: add pmic_setup to SPL
On 15/05/2015 18:18, Tim Harvey wrote: We need to do any PMIC setup in the SPL if we are to bypass U-Boot for falcon mode. Signed-off-by: Tim Harvey thar...@gateworks.com --- v2: rebased --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/19] imx: ventana: (cosmetic) clean up size defines for improved readability
On 15/05/2015 18:17, Tim Harvey wrote: Use the SZ_1M and SZ_1K macros from linuz/sizes.h for improved readability Signed-off-by: Tim Harvey thar...@gateworks.com --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/19] imx: ventana: config: use MMC SPL RAW support
On 15/05/2015 18:14, Tim Harvey wrote: Switch to MMC RAW support for SPL. We will place the uboot.img at 69KB. Signed-off-by: Tim Harvey thar...@gateworks.com --- v2: remove unnecessary CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR define Signed-off-by: Tim Harvey thar...@gateworks.com --- include/configs/gw_ventana.h | 4 1 file changed, 4 deletions(-) diff --git a/include/configs/gw_ventana.h b/include/configs/gw_ventana.h index b20b338..dd7188b 100644 --- a/include/configs/gw_ventana.h +++ b/include/configs/gw_ventana.h @@ -11,10 +11,6 @@ #define CONFIG_SPL_BOARD_INIT #define CONFIG_SPL_NAND_SUPPORT #define CONFIG_SPL_MMC_SUPPORT -#define CONFIG_SPL_FAT_SUPPORT -/* -#define CONFIG_SPL_SATA_SUPPORT -*/ /* Location in NAND to read U-Boot from */ #define CONFIG_SYS_NAND_U_BOOT_OFFS (14 * 1024 * 1024) Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pmic: pfuze100 fix typo
On 18/05/2015 07:37, Peng Fan wrote: Change PUZE_100_SW1ABCONF to PFUZE100_SW1ABCONF Signed-off-by: Peng Fan peng@freescale.com --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] sunxi: Make DRAM_ODT_EN Kconfig setting a bool
On Tue, 19 May 2015 14:56:39 +0200 Hans de Goede hdego...@redhat.com wrote: Make DRAM_ODT_EN Kconfig setting a bool, add a separate DRAM_ODT_CORRECTION setting for A23 SoCs and use DRAM_ODT_EN Kconfig everywhere instead of only in dram_sun4i.c and hardcoding odt_en elsewhere. Note this commit makes no functional changes for existing boards, its purpose is to allow changing the odt_en value on future A33 boards. Signed-off-by: Hans de Goede hdego...@redhat.com The sun4i part is fine. Regarding the A23 part, the only nitpick from me is the newly added CONFIG_DRAM_ODT_CORRECTION option. The description does not seem to be very informative in Kconfig: +if MACH_SUN8I_A23 +config DRAM_ODT_CORRECTION + int sunxi dram odt correction value + default 0 + ---help--- + Set the dram odt correction value (range -255 - 255). +endif Since the right correction value is extracted from the FEX file (or where are we expected to get it from?), a short instruction about converting the 'dram_odt_en' parameter from FEX into the DRAM_ODT_CORRECTION option for U-Boot would be quite useful here. Other than this, looks good and Acked-by: Siarhei Siamashka siarhei.siamas...@gmail.com -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] tools: get-toolchais: a tool to get cross-tools for all architectures
On Fri, May 15, 2015 at 6:01 AM, Masahiro Yamada yamada.masah...@socionext.com wrote: When we send patches, we are supposed to test them by build utilities such as MAKEALL, buildman. When we want to test global changes, the first hurdle is, I think, to collect toolchains for all the architectures. We have some documents about build utilities, but I have not seen any official information about how to get the suitable cross-tools. Of course, it is possible to build them from sources, but it is not necessarily feasible. Fortunately, the kernel.org site provides us pre-built toolchains, but some architectures are missing. Also, some boards fail to build with the kernel.org tools. We sometimes see, where can I get the compiler for this architecture? things on the ML. We should be able to prepare cross-compilers more easily. It is true that buildman provides --fetch-arch option for downloading kernel.org toolchains, but it does not have access to others. And what we really want to know is most likely how to get compilers for such minor architectures as kernel.org does not provide. This tool intends to be more generic design without hard-coding such kernel.org things. To achieve that, this tool consists of two files: Python script (this file) and the database file containing URLs of tarballs. We just need to update the latter when new version compilers are released (or better compilers are found.) The file is in the form of RFC 822 for easier editing. The script only uses Python libraries, not relies on external programs although it displays wget-like log when downloading tarballs. :-) This is RFC because I am thinking it can be more brushed up. If the basis idea is OK, I will improve code, add more comments. Note this script is written in Python 3 and only works on Python 3.3 or later. I do not think it is too much limitation, but some popular distributions under support might include older version. For example, looks like Ubuntu 12.04 LTS is shipped with Python 3.2. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- Also, in case you didn't notice, you have a typo in the subject of the patch. toolchais. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] sunxi: Make DRAM_ODT_EN Kconfig setting a bool
On Tue, 19 May 2015 15:13:18 +0100
Ian Campbell ijc+ub...@hellion.org.uk wrote:
On Tue, 2015-05-19 at 14:56 +0200, Hans de Goede wrote:
diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
b/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
index c736fa3..f7b4915 100644
--- a/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
+++ b/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
@@ -508,7 +508,7 @@ static void mctl_ddr3_initialize(void)
/*
* Perform impedance calibration on the DRAM controller side of the wire.
*/
-static void mctl_set_impedance(u32 zq, u32 odt_en)
+static void mctl_set_impedance(u32 zq, bool odt_en)
{
struct sunxi_dram_reg *dram = (struct sunxi_dram_reg *)SUNXI_DRAMC_BASE;
u32 reg_val;
@@ -556,7 +556,7 @@ static void mctl_set_impedance(u32 zq, u32 odt_en)
clrbits_le32(dram-zqcr0, DRAM_ZQCR0_ZCAL);
/* Set I/O configure register */
- writel(DRAM_IOCR_ODT_EN(odt_en), dram-iocr);
+ writel(DRAM_IOCR_ODT_EN, dram-iocr);
I think at this point previously odt_en would always be 0x1 here (0x0
having been short circuited earlier).
In fact, only 0 and 3 were the realistic practical choices. The commit
message says that no functional changes are introduced for the
existing boards. And this is true because these boards all use 0
by default.
But setting this option to 3 (which enables ODT for both DQ and DQS
lines), combined with picking good ZQ settings, can do wonders and
significantly improve reliability at high DRAM clock speeds. And
this is not just an armchair expert opinion :-) The 'highspeedtruck'
branch specifically took advantage of this configuration knob:
http://lists.denx.de/pipermail/u-boot/2014-July/183981.html
If I understand it correctly, you do have a Cubietruck board, right?
So if you are really interested, then you should be able to easily
verify this yourself.
With a bit of ZQ tuning, I also had DRAM successfully running at
648 MHz on my A13-OLinuXino-MICRO. And Adam Sampson could reach 648 MHz
DRAM clock speeds on his two LinkSprite pcDuino3 Nano boards
too.
Whereas this...
-#define DRAM_IOCR_ODT_EN(n) n) 0x3) 30) | ((n) 0x3) 0)
-#define DRAM_IOCR_ODT_EN_MASK DRAM_IOCR_ODT_EN(0x3)
+#define DRAM_IOCR_ODT_EN ((3 30) | (3 0))
... now behaves as if it were always 0x3.
AFAICT up until now, at least with the in-tree defconfigs, odt_en was
always 0 for sun4i anyway, but this is a surprising change I think.
Do you mean that you want a better description of this change in the
commit message?
I myself can only welcome the change of this option to the boolean type,
because this way we avoid any need to answer quite a predictable
question why 3 and not 1 or 2? at:
http://linux-sunxi.org/A10_DRAM_Controller_Calibration#Finding_good_impedance_settings
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] tools: moveconfig: a tool to move CONFIGs from headers to defconfigs
Hi Masahiro-san On Thu, May 14, 2015 at 11:44 PM, Masahiro Yamada yamada.masah...@socionext.com wrote: This tool was originally written for my local use to ease the task of tons of CONFIG moves, but there have been some requests for mainlining it. So, I have tidied up the code with nicer comments, and here it is. See the comment block of the script for usage. The first draft was http://patchwork.ozlabs.org/patch/430422/ Main updates are: - Adapted to the single .config configuration - Support colored log - Support moving multiple options at once (and take configs via input file only) - Continue even if some boards fail (Idea provided by Joe Hershberger) - Add more options - More comments and code cleanups Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com Signed-off-by: Joe Hershberger joe.hershber...@ni.com --- Changes in v2: - Fix comments - Map arc toolchain - Add dry-run option tools/moveconfig.py | 853 1 file changed, 853 insertions(+) create mode 100755 tools/moveconfig.py diff --git a/tools/moveconfig.py b/tools/moveconfig.py new file mode 100755 index 000..c39ea95 --- /dev/null +++ b/tools/moveconfig.py @@ -0,0 +1,853 @@ +#!/usr/bin/env python2 +# +# Author: Masahiro Yamada yamada.masah...@socionext.com +# +# SPDX-License-Identifier: GPL-2.0+ +# + + +Move config options from headers to defconfig files. + +Since Kconfig was introduced to U-Boot, we have worked on moving +config options from headers to Kconfig (defconfig). + +This tool intends to help this tremendous work. + + +Usage +- + +This tool takes one input file. (let's say 'recipe' file here.) +The recipe describes the list of config options you want to move. +Each line takes the form: +config_name type default +(the fields must be separated with whitespaces.) + +config_name is the name of config option. + +type is the type of the option. It must be one of bool, tristate, +string, int, and hex. + +default is the default value of the option. It must be appropriate +value corresponding to the option type. It must be either y or n for +the bool type. Tristate options can also take m (although U-Boot has +not supported the module feature). + +You can add two or more lines in the recipe file, so you can move +multiple options at once. + +Let's say, for example, you want to move CONFIG_CMD_USB and +CONFIG_SYS_TEXT_BASE. + +The type should be bool, hex, respectively. So, the recipe file +should look like this: + + $ cat recipe + CONFIG_CMD_USB bool n + CONFIG_SYS_TEXT_BASE hex 0x + +And then run this tool giving the file name of the recipe + + $ tools/moveconfig.py recipe + +The tool walks through all the defconfig files to move the config +options specified by the recipe file. + +The log is also displayed on the terminal. + +Each line is printed in the format +defconfig_name : action + +defconfig_name is the name of the defconfig +(without the suffix _defconfig). + +action shows what the tool did for that defconfig. +It looks like one of the followings: + + - Move 'CONFIG_... ' + This config option was moved to the defconfig + + - Default value 'CONFIG_...'. Do nothing. + The value of this option is the same as default. + We do not have to add it to the defconfig. + + - 'CONFIG_...' already exists in Kconfig. Do nothing. + This config option is already defined in Kconfig. + We do not need/want to touch it. + + - Undefined. Do nothing. + This config option was not found in the config header. + Nothing to do. + + - Failed to process. Skip. + An error occurred during processing this defconfig. Skipped. + (If -e option is passed, the tool exits immediately on error.) + +Finally, you will be asked, Clean up headers? [y/n]: + +If you say 'y' here, the unnecessary config defines are removed +from the config headers (include/configs/*.h). +It just uses the regex method, so you should not rely on it. +Just in case, please do 'git diff' to see what happened. + + +How does it works? +-- + +This tool runs configuration and builds include/autoconf.mk for every +defconfig. The config options defined in Kconfig appear in the .config +file (unless they are hidden because of unmet dependency.) +On the other hand, the config options defined by board headers are seen +in include/autoconf.mk. The tool looks for the specified options in both +of them to decide the appropriate action for the options. If the option +is found in the .config or the value is the same as the specified default, +the option does not need to be touched. If the option is found in +include/autoconf.mk, but not in the .config, and the value is different +from the default, the tools adds the option to the defconfig. + +For faster processing, this tool handles multi-threading. It
Re: [U-Boot] [PATCH v4 05/10] moveconfig: Cleanup headers in arch and board
On Mon, May 18, 2015 at 8:41 PM, Masahiro Yamada
yamada.masah...@socionext.com wrote:
Hi Joe,
2015-05-16 6:40 GMT+09:00 Joe Hershberger joe.hershber...@ni.com:
Some config.h files live in arch and board directories. They will need
to be cleaned up as well, so run the same filters there.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v4:
-New for version 4
Changes in v3: None
Changes in v2: None
tools/moveconfig.py | 10 ++
1 file changed, 10 insertions(+)
diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index b6db058..25cee21 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -352,6 +352,16 @@ def cleanup_headers(config_attrs, dry_run):
if not fnmatch.fnmatch(filename, '*~'):
cleanup_one_header(os.path.join(dirpath, filename),
patterns,
dry_run)
+for (dirpath, dirnames, filenames) in os.walk('arch'):
+for filename in filenames:
+if not fnmatch.fnmatch(filename, '*~'):
+cleanup_one_header(os.path.join(dirpath, filename),
patterns,
+ dry_run)
+for (dirpath, dirnames, filenames) in os.walk('board'):
+for filename in filenames:
+if not fnmatch.fnmatch(filename, '*~'):
+cleanup_one_header(os.path.join(dirpath, filename),
patterns,
+ dry_run)
To reduce code duplication, can we write like this or something?
for dir in 'include', 'arch', 'board':
for (dirpath, dirnames, filenames) in os.walk(dir):
for filename in filenames:
if not fnmatch.fnmatch(filename, '*~'):
cleanup_one_header(os.path.join(dirpath, filename),
patterns, dry_run)
OK.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 06/10] moveconfig: Remove probable debug print
Hi Masahiro-san, On Mon, May 18, 2015 at 9:10 PM, Masahiro Yamada yamada.masah...@socionext.com wrote: Hi Joe 2015-05-16 6:40 GMT+09:00 Joe Hershberger joe.hershber...@ni.com: This print seems to be redundant and unformatted compared to the next few lines, so remove it. Signed-off-by: Joe Hershberger joe.hershber...@ni.com --- Changes in v4: None Changes in v3: None Changes in v2: None tools/moveconfig.py | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/moveconfig.py b/tools/moveconfig.py index 25cee21..15b0f2b 100755 --- a/tools/moveconfig.py +++ b/tools/moveconfig.py @@ -725,7 +725,6 @@ class Slots: if len(failed_boards) 0: msg = [ The following boards were not processed due to error: ] msg += failed_boards -print msg for line in msg: print sys.stderr, color_text(self.options.color, COLOR_LIGHT_RED, line) -- Oops, my mistake. Acked-by: Masahiro Yamada yamada.masah...@socionext.com (Or, because it is a simply bug fix, you can comment on my base patch.) I'm dropping this patch and sent a reply to your original patch (not applied to master yet). -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 04/10] moveconfig: Add a switch to only cleanup headers
Hi Masahiro-san,
On Mon, May 18, 2015 at 9:03 PM, Masahiro Yamada
yamada.masah...@socionext.com wrote:
Hi Joe,
2015-05-16 6:40 GMT+09:00 Joe Hershberger joe.hershber...@ni.com:
In some case you may want to only cleanup the headers. Make it possible
without waiting for all boards to compile.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v4: None
Changes in v3:
-New for version 3
Changes in v2: None
tools/moveconfig.py | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index 3f31e81..b6db058 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -146,6 +146,9 @@ Available options
Exit immediately if Make exits with a non-zero status while processing
a defconfig file.
+ -H, --headers-only
+ Only cleanup the headers; skip the defconfig processing
+
-j, --jobs
Specify the number of threads to run simultaneously. If not specified,
the number of threads is the same as the number of CPU cores.
@@ -770,8 +773,6 @@ def move_config(config_attrs, options):
slots.show_failed_boards()
-cleanup_headers(config_attrs, options.dry_run)
-
def bad_recipe(filename, linenum, msg):
Print error message with the file name and the line number and
exit.
sys.exit(%s: line %d: error : % (filename, linenum) + msg)
@@ -859,6 +860,9 @@ def main():
parser.add_option('-e', '--exit-on-error', action='store_true',
default=False,
help='exit immediately on any error')
+parser.add_option('-H', '--headers-only', dest='cleanup_headers_only',
+ action='store_true', default=False,
+ help='only cleanup the headers')
parser.add_option('-j', '--jobs', type='int', default=cpu_count,
help='the number of jobs to run simultaneously')
parser.usage += ' recipe_file\n\n' + \
@@ -879,7 +883,10 @@ def main():
update_cross_compile()
-move_config(config_attrs, options)
+if not options.cleanup_headers_only:
+move_config(config_attrs, options)
+
+cleanup_headers(config_attrs, options.dry_run)
if __name__ == '__main__':
main()
Could you also move the check_top_directory() call
to main() function, above the move_config call.
We should make sure we are at the top directory
also for cleaning headers.
Yes... moving it.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 01/10] moveconfig: Always run savedefconfig on the moved config
Hi Masahiro-san,
On Mon, May 18, 2015 at 8:58 PM, Masahiro Yamada
yamada.masah...@socionext.com wrote:
Hi Joe,
2015-05-16 6:40 GMT+09:00 Joe Hershberger joe.hershber...@ni.com:
This will ensure that the order of the defconfig entries will always
match that of the Kconfig files. After one slightly painful (but
still early in the process) pass over all boards, this should keep
the defconfigs clean from here on.
Users must edit the Kconfig first to add the menu entries and then run
moveconfig.py to update the defconfig files and the include configs.
As such, moveconfig.py cannot compare against the '.config' contents.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
This feature expects the defconfigs are all clean.
Otherwise, savedefconfig would make git diff noisier.
It is safer to use make menuconfig make savedefconfig
for adding new options, but some people still try to
edit the defconfig directly...
Perhaps, should do the global cleanup periodically?
---
This is based on https://patchwork.ozlabs.org/patch/472591/
Changes in v4:
-Rebased series on Masahiro's v2
Changes in v3: None
Changes in v2: None
tools/moveconfig.py | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index c39ea95..544f6af 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -46,6 +46,9 @@ should look like this:
CONFIG_CMD_USB bool n
CONFIG_SYS_TEXT_BASE hex 0x
+Next you must edit the Kconfig to add the menu entries for the configs
+you are moving.
+
And then run this tool giving the file name of the recipe
Uh, I was doing in a different work-flow.
(I edit the Kconfig after I move CONFIGs to defconfigs).
But, the Kconfig must be edited beforehand
to do savedefconfig.
So, I am OK with this change.
$ tools/moveconfig.py recipe
@@ -192,6 +195,7 @@ CROSS_COMPILE = {
STATE_IDLE = 0
STATE_DEFCONFIG = 1
STATE_AUTOCONF = 2
+STATE_SAVEDEFCONFIG = 3
ACTION_MOVE = 0
ACTION_DEFAULT_VALUE = 1
@@ -390,8 +394,7 @@ class KconfigParser:
return CROSS_COMPILE.get(arch, '')
-def parse_one_config(self, config_attr, defconfig_lines,
- dotconfig_lines, autoconf_lines):
+def parse_one_config(self, config_attr, defconfig_lines,
autoconf_lines):
Parse .config, defconfig, include/autoconf.mk for one config.
This function looks for the config options in the lines from
@@ -402,7 +405,6 @@ class KconfigParser:
config_attr: A dictionary including the name, the type,
and the default value of the target config.
defconfig_lines: lines from the original defconfig file.
- dotconfig_lines: lines from the .config file.
autoconf_lines: lines from the include/autoconf.mk file.
Returns:
@@ -418,7 +420,7 @@ class KconfigParser:
else:
default = config + '=' + config_attr['default']
-for line in defconfig_lines + dotconfig_lines:
+for line in defconfig_lines:
line = line.rstrip()
if line.startswith(config + '=') or line == not_set:
return (ACTION_ALREADY_EXIST, line)
@@ -463,15 +465,12 @@ class KconfigParser:
with open(defconfig_path) as f:
defconfig_lines = f.readlines()
-with open(dotconfig_path) as f:
-dotconfig_lines = f.readlines()
-
with open(autoconf_path) as f:
autoconf_lines = f.readlines()
for config_attr in self.config_attrs:
result = self.parse_one_config(config_attr, defconfig_lines,
- dotconfig_lines, autoconf_lines)
+ autoconf_lines)
results.append(result)
log = ''
With the change of the work-flow above,
we need not parse the .config, so this seems OK.
@@ -499,7 +498,7 @@ class KconfigParser:
print log,
if not self.options.dry_run:
-with open(defconfig_path, 'a') as f:
+with open(dotconfig_path, 'a') as f:
for (action, value) in results:
if action == ACTION_MOVE:
f.write(value + '\n')
@@ -608,6 +607,24 @@ class Slot:
if self.state == STATE_AUTOCONF:
self.parser.update_defconfig(self.defconfig)
+
+Save off the defconfig in a consistent way
+cmd = list(self.make_cmd)
+cmd.append('savedefconfig')
+self.ps = subprocess.Popen(cmd, stdout=self.devnull,
+ stderr=self.devnull)
+self.state = STATE_SAVEDEFCONFIG
+return False
+
+if self.state == STATE_SAVEDEFCONFIG:
+defconfig_path = os.path.join(self.build_dir, 'defconfig')
+if not
Re: [U-Boot] fdt: Pass the board serial number through devicetree
Hi Simon, About: https://patchwork.ozlabs.org/patch/455720/ AFAIK on the kernel side all the relevant patches (including devicetree binding documentation binding) have been queued up for 4.2, so this ready to be merged now. Paul, can you confirm this ? Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: imx: Switch Wandboard to use config_distro_bootcmd.h.
Any new of this ? it can be merged ? I have tested and successfully boot a fedora on a Wandboard Quad with this. The improvement of the console variable management can be done with an other patch ? Thank you for working on this. -- XoD 2015-03-29 15:05 GMT+02:00 Tom Rini tr...@konsulko.com: On Sat, Mar 28, 2015 at 02:15:38PM +0100, Karsten Merker wrote: On Fri, Mar 27, 2015 at 06:24:43PM -0700, Vagrant Cascadian wrote: This allows for more flexible and standardized boot across multiple platforms. Remove most redundant legacy boot environment. Cc: Otavio Salvador ota...@ossystems.com.br Signed-off-by: Vagrant Cascadian vagr...@debian.org --- include/configs/wandboard.h | 139 ++-- 1 file changed, 17 insertions(+), 122 deletions(-) diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h [...] #define CONFIG_EXTRA_ENV_SETTINGS \ - script=boot.scr\0 \ - image=zImage\0 \ console=ttymxc0\0 \ Hello, regarding the boot environment standardization there is still the open topic of standardizing the console variable format for serial consoles - most platforms include the console baudrate in the console variable (e.g. console=ttyS0,115200) while some others, in particular the i.MX6 platforms, do not. This means that distributions like Debian currently need to add special-case handling for i.MX6-based platforms in their boot scripts which goes against the idea of having one generic boot script for all platforms that use config_distro_bootcmd.h. It would be nice if the i.MX6 platforms could - while adopting config_distro_bootcmd.h and thereby changing their default environment to a large extend - also change their console variable from console=ttymxc0 to console=ttymxc0,115200. Yes please. And Karsten can you do a patch that updates the README to note that as an expectation? Thanks! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] sunxi: VBUS detection function fixup in g_dnl_board_usb_cable_connected
Hi,
Thanks for these 2 fixes, I've added both to my personal tree. I'll send
a pull-req to get these into u-boot/master soon.
Regards,
Hans
On 05/16/2015 07:52 PM, Paul Kocialkowski wrote:
sunxi_usbc_vbus_detect was renamed to sunxi_usb_phy_vbus_detect but
g_dnl_board_usb_cable_connected was still using the old name, breaking the build
when USB gadget is enabled.
Signed-off-by: Paul Kocialkowski cont...@paulk.fr
---
board/sunxi/board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 4c51468..5f79cc1 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -476,7 +476,7 @@ static struct musb_hdrc_platform_data musb_plat = {
#ifdef CONFIG_USB_GADGET
int g_dnl_board_usb_cable_connected(void)
{
- return sunxi_usbc_vbus_detect(0);
+ return sunxi_usb_phy_vbus_detect(0);
}
#endif
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch 3/3] e1000: remove unnecessary clearing of SWSM.SWSM_SMBI
remove unnecessary clearing of SWSM.SWSM_SMBI when obtaining the SW semaphore. This was introduced in 951860634fdb557bbb58e0f99215391bc0c29779 while adding i210 support and should be now resolved by releasing the semaphore when no longer needed. Cc: Marcel Ziswiler mar...@ziswiler.com Cc: Marek Vasut ma...@denx.de Cc: Aneesh Bansal aneesh.ban...@freescale.com Cc: Naveen Burmi naveenbu...@freescale.com Cc: Po Liu po@freescale.com Cc: Bin Meng bmeng...@gmail.com Cc: Alison Wang alison.w...@freescale.com Cc: Reinhard Arlt reinhard.a...@esd-electronics.com Cc: Shengzhou Liu shengzhou@freescale.com Cc: York Sun york...@freescale.com Signed-off-by: Tim Harvey thar...@gateworks.com --- drivers/net/e1000.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c index f960024..a78ffc4 100644 --- a/drivers/net/e1000.c +++ b/drivers/net/e1000.c @@ -996,10 +996,6 @@ e1000_get_software_semaphore(struct e1000_hw *hw) DEBUGFUNC(); - swsm = E1000_READ_REG(hw, SWSM); - swsm = ~E1000_SWSM_SMBI; - E1000_WRITE_REG(hw, SWSM, swsm); - if (hw-mac_type != e1000_80003es2lan) return E1000_SUCCESS; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] sunxi: Make DRAM_ODT_EN Kconfig setting a bool
Hi,
On 05/19/2015 04:13 PM, Ian Campbell wrote:
On Tue, 2015-05-19 at 14:56 +0200, Hans de Goede wrote:
diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
b/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
index c736fa3..f7b4915 100644
--- a/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
+++ b/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
@@ -508,7 +508,7 @@ static void mctl_ddr3_initialize(void)
/*
* Perform impedance calibration on the DRAM controller side of the wire.
*/
-static void mctl_set_impedance(u32 zq, u32 odt_en)
+static void mctl_set_impedance(u32 zq, bool odt_en)
{
struct sunxi_dram_reg *dram = (struct sunxi_dram_reg *)SUNXI_DRAMC_BASE;
u32 reg_val;
@@ -556,7 +556,7 @@ static void mctl_set_impedance(u32 zq, u32 odt_en)
clrbits_le32(dram-zqcr0, DRAM_ZQCR0_ZCAL);
/* Set I/O configure register */
- writel(DRAM_IOCR_ODT_EN(odt_en), dram-iocr);
+ writel(DRAM_IOCR_ODT_EN, dram-iocr);
I think at this point previously odt_en would always be 0x1 here (0x0
having been short circuited earlier).
Whereas this...
-#define DRAM_IOCR_ODT_EN(n) n) 0x3) 30) | ((n) 0x3) 0)
-#define DRAM_IOCR_ODT_EN_MASK DRAM_IOCR_ODT_EN(0x3)
+#define DRAM_IOCR_ODT_EN ((3 30) | (3 0))
... now behaves as if it were always 0x3.
AFAICT up until now, at least with the in-tree defconfigs, odt_en was
always 0 for sun4i anyway, but this is a surprising change I think.
This is deliberate, as Siarhei explained in his reply to v2 the 2 bits
we are setting here enable odt for the DQ resp. DQS lines, having them
enabled for one but not the other does not really make sense.
I'll amend the commit message to explicitly mention this.
Regards,
Hans
DRAM_IOCR_ODT_EN_MASK (which did use 0x3) seems to have been unused. in
tree.
diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun8i_a23.h
b/arch/arm/include/asm/arch-sunxi/dram_sun8i_a23.h
index 06adee2..316a333 100644
--- a/arch/arm/include/asm/arch-sunxi/dram_sun8i_a23.h
+++ b/arch/arm/include/asm/arch-sunxi/dram_sun8i_a23.h
@@ -19,6 +19,7 @@ struct dram_para {
u32 type;
u32 zq;
u32 odt_en;
Make this (and maybe others) an actual bool?
Keeping it a u32 might make hex editing easier though?
Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] sunxi: Make DRAM_ODT_EN Kconfig setting a bool
Hi, On 05/19/2015 04:54 PM, Siarhei Siamashka wrote: On Tue, 19 May 2015 14:56:39 +0200 Hans de Goede hdego...@redhat.com wrote: Make DRAM_ODT_EN Kconfig setting a bool, add a separate DRAM_ODT_CORRECTION setting for A23 SoCs and use DRAM_ODT_EN Kconfig everywhere instead of only in dram_sun4i.c and hardcoding odt_en elsewhere. Note this commit makes no functional changes for existing boards, its purpose is to allow changing the odt_en value on future A33 boards. Signed-off-by: Hans de Goede hdego...@redhat.com The sun4i part is fine. Regarding the A23 part, the only nitpick from me is the newly added CONFIG_DRAM_ODT_CORRECTION option. The description does not seem to be very informative in Kconfig: +if MACH_SUN8I_A23 +config DRAM_ODT_CORRECTION + int sunxi dram odt correction value + default 0 + ---help--- + Set the dram odt correction value (range -255 - 255). +endif Since the right correction value is extracted from the FEX file (or where are we expected to get it from?), a short instruction about converting the 'dram_odt_en' parameter from FEX into the DRAM_ODT_CORRECTION option for U-Boot would be quite useful here. Thanks for the review, adding a blurb to the Kconfig help on how to get the correction value from a fex file is a good idea, I've added such a blurb to the version in my personal tree. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fdt: Pass the board serial number through devicetree
Le mardi 19 mai 2015 à 18:37 +0200, Hans de Goede a écrit : Hi Simon, About: https://patchwork.ozlabs.org/patch/455720/ AFAIK on the kernel side all the relevant patches (including devicetree binding documentation binding) have been queued up for 4.2, so this ready to be merged now. Paul, can you confirm this ? Correct, the two patches adding support for this in Linux have been accepted by Russell King: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8354/1 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8355/1 I didn't resend the patch in U-Boot yet (along with the use of ATAGs for sunxi) but if you're willing to accept it while the change has not yet landed in Linus' tree, I could wrap a new version soon. Should I also document the dt property in the U-Boot documentation? -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/ signature.asc Description: This is a digitally signed message part ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch 1/3] e1000: releasing semaphore once no longer needed
Once the hwsw semaphore is acquired, it must be released when access to the
hw is completed. Without this subsequent calls to acquire will timeout
obtaining the semaphore.
Cc: Marcel Ziswiler mar...@ziswiler.com
Cc: Marek Vasut ma...@denx.de
Cc: Aneesh Bansal aneesh.ban...@freescale.com
Cc: Naveen Burmi naveenbu...@freescale.com
Cc: Po Liu po@freescale.com
Cc: Bin Meng bmeng...@gmail.com
Cc: Alison Wang alison.w...@freescale.com
Cc: Reinhard Arlt reinhard.a...@esd-electronics.com
Cc: Shengzhou Liu shengzhou@freescale.com
Cc: York Sun york...@freescale.com
Signed-off-by: Tim Harvey thar...@gateworks.com
---
drivers/net/e1000.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index cd44222..a64bc7b 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -126,6 +126,7 @@ static int e1000_detect_gig_phy(struct e1000_hw *hw);
static void e1000_set_media_type(struct e1000_hw *hw);
static int32_t e1000_swfw_sync_acquire(struct e1000_hw *hw, uint16_t mask);
+static void e1000_swfw_sync_release(struct e1000_hw *hw, uint16_t mask);
static int32_t e1000_check_phy_reset_block(struct e1000_hw *hw);
#ifndef CONFIG_E1000_NO_NVM
@@ -729,7 +730,10 @@ void e1000_release_eeprom(struct e1000_hw *hw)
eecd = ~E1000_EECD_REQ;
E1000_WRITE_REG(hw, EECD, eecd);
}
+
+ e1000_swfw_sync_release(hw, E1000_SWFW_EEP_SM);
}
+
/**
* Reads a 16 bit word from the EEPROM.
*
@@ -1102,6 +1106,7 @@ e1000_get_hw_eeprom_semaphore(struct e1000_hw *hw)
return E1000_SUCCESS;
}
+/* Take ownership of the PHY */
static int32_t
e1000_swfw_sync_acquire(struct e1000_hw *hw, uint16_t mask)
{
@@ -1141,6 +1146,21 @@ e1000_swfw_sync_acquire(struct e1000_hw *hw, uint16_t
mask)
return E1000_SUCCESS;
}
+static void e1000_swfw_sync_release(struct e1000_hw *hw, uint16_t mask)
+{
+ uint32_t swfw_sync = 0;
+
+ DEBUGFUNC();
+ while (e1000_get_hw_eeprom_semaphore(hw))
+ ; /* Empty */
+
+ swfw_sync = E1000_READ_REG(hw, SW_FW_SYNC);
+ swfw_sync = ~mask;
+ E1000_WRITE_REG(hw, SW_FW_SYNC, swfw_sync);
+
+ e1000_put_hw_eeprom_semaphore(hw);
+}
+
static bool e1000_is_second_port(struct e1000_hw *hw)
{
switch (hw-mac_type) {
@@ -4462,6 +4482,8 @@ e1000_phy_hw_reset(struct e1000_hw *hw)
E1000_WRITE_REG(hw, LEDCTL, led_ctrl);
}
+ e1000_swfw_sync_release(hw, swfw);
+
/* Wait for FW to finish PHY configuration. */
ret_val = e1000_get_phy_cfg_done(hw);
if (ret_val != E1000_SUCCESS)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch 2/3] Revert e1000: fix sw fw sync on igb i210/i211
This reverts commit 17da7120249bfdef877f46be5bbcb3cc01212eb9.
The i210/i211 do have the SW_FW_SYNC (0x5b5c) register and this is what should
be used when acquiring the semaphore.
I believe the issue that this patch was trying to resolve is now resolved
by properly releasing the semaphore once no longer needed.
Cc: Marcel Ziswiler mar...@ziswiler.com
Cc: Marek Vasut ma...@denx.de
Cc: Aneesh Bansal aneesh.ban...@freescale.com
Cc: Naveen Burmi naveenbu...@freescale.com
Cc: Po Liu po@freescale.com
Cc: Bin Meng bmeng...@gmail.com
Cc: Alison Wang alison.w...@freescale.com
Cc: Reinhard Arlt reinhard.a...@esd-electronics.com
Cc: Shengzhou Liu shengzhou@freescale.com
Cc: York Sun york...@freescale.com
Signed-off-by: Tim Harvey thar...@gateworks.com
---
drivers/net/e1000.c | 6 ++
drivers/net/e1000.h | 1 -
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index a64bc7b..f960024 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -1120,10 +1120,7 @@ e1000_swfw_sync_acquire(struct e1000_hw *hw, uint16_t
mask)
if (e1000_get_hw_eeprom_semaphore(hw))
return -E1000_ERR_SWFW_SYNC;
- if (hw-mac_type == e1000_igb)
- swfw_sync = E1000_READ_REG(hw, I210_SW_FW_SYNC);
- else
- swfw_sync = E1000_READ_REG(hw, SW_FW_SYNC);
+ swfw_sync = E1000_READ_REG(hw, SW_FW_SYNC);
if (!(swfw_sync (fwmask | swmask)))
break;
@@ -4458,6 +4455,7 @@ e1000_phy_hw_reset(struct e1000_hw *hw)
if (hw-mac_type = e1000_82571)
mdelay(10);
+
} else {
/* Read the Extended Device Control Register, assert the
PHY_RESET_DIR
* bit to put the PHY into reset. Then, take it out of reset.
diff --git a/drivers/net/e1000.h b/drivers/net/e1000.h
index f3b77b1..232c95d 100644
--- a/drivers/net/e1000.h
+++ b/drivers/net/e1000.h
@@ -2496,7 +2496,6 @@ struct e1000_hw {
#define ICH_GFPREG_BASE_MASK 0x1FFF
#define ICH_FLASH_LINEAR_ADDR_MASK 0x00FF
-#define E1000_I210_SW_FW_SYNC 0x5B50 /* Software-Firmware Synchronization - RW
*/
#define E1000_SW_FW_SYNC 0x05B5C /* Software-Firmware Synchronization - RW */
/* SPI EEPROM Status Register */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] e1000: fix semaphore sync issues
The following patchset resolves semaphore sync issues I've encountered on a board with an i210 (programmed, copper mode) using the internal phy. The first patch adds releasing of the semaphore once they are no longer needed, and the other two patches revert logic that I believe was working around the fact that they were previsouly not released. This will need testing on the various configurations of e1000 so I've taken care to Cc the maintainers that were listed by boards using CONFIG_E1000 as well as the authors of the patches I'm reverting sections from. Cc: Marcel Ziswiler mar...@ziswiler.com Cc: Marek Vasut ma...@denx.de Cc: Aneesh Bansal aneesh.ban...@freescale.com Cc: Naveen Burmi naveenbu...@freescale.com Cc: Po Liu po@freescale.com Cc: Bin Meng bmeng...@gmail.com Cc: Alison Wang alison.w...@freescale.com Cc: Reinhard Arlt reinhard.a...@esd-electronics.com Cc: Shengzhou Liu shengzhou@freescale.com Cc: York Sun york...@freescale.com Signed-off-by: Tim Harvey thar...@gateworks.com Tim Harvey (3): e1000: fix eeprom sync issues by releasing semaphore once no longer needed Revert e1000: fix sw fw sync on igb i210/i211 e1000: remove unnecessary clearing of SWSM.SWSM_SMBI drivers/net/e1000.c | 32 drivers/net/e1000.h | 1 - 2 files changed, 24 insertions(+), 9 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fdt: Pass the board serial number through devicetree
Hi Paul, On 19 May 2015 at 10:57, Paul Kocialkowski cont...@paulk.fr wrote: Le mardi 19 mai 2015 à 18:37 +0200, Hans de Goede a écrit : Hi Simon, About: https://patchwork.ozlabs.org/patch/455720/ AFAIK on the kernel side all the relevant patches (including devicetree binding documentation binding) have been queued up for 4.2, so this ready to be merged now. Paul, can you confirm this ? Correct, the two patches adding support for this in Linux have been accepted by Russell King: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8354/1 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8355/1 I didn't resend the patch in U-Boot yet (along with the use of ATAGs for sunxi) but if you're willing to accept it while the change has not yet landed in Linus' tree, I could wrap a new version soon. OK with me. Should I also document the dt property in the U-Boot documentation? Document is normally a good idea. Regards, Simon -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 1/9] moveconfig: Always run savedefconfig on the moved config
This will ensure that the order of the defconfig entries will always
match that of the Kconfig files. After one slightly painful (but
still early in the process) pass over all boards, this should keep
the defconfigs clean from here on.
Users must edit the Kconfig first to add the menu entries and then run
moveconfig.py to update the defconfig files and the include configs.
As such, moveconfig.py cannot compare against the '.config' contents.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
This is based on https://patchwork.ozlabs.org/patch/472591/
Changes in v5:
-Removed warning that may never be reached
Changes in v4:
-Rebased series on Masahiro's v2
Changes in v3: None
Changes in v2: None
tools/moveconfig.py | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index c39ea95..c9984b4 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -46,6 +46,9 @@ should look like this:
CONFIG_CMD_USB bool n
CONFIG_SYS_TEXT_BASE hex 0x
+Next you must edit the Kconfig to add the menu entries for the configs
+you are moving.
+
And then run this tool giving the file name of the recipe
$ tools/moveconfig.py recipe
@@ -192,6 +195,7 @@ CROSS_COMPILE = {
STATE_IDLE = 0
STATE_DEFCONFIG = 1
STATE_AUTOCONF = 2
+STATE_SAVEDEFCONFIG = 3
ACTION_MOVE = 0
ACTION_DEFAULT_VALUE = 1
@@ -390,8 +394,7 @@ class KconfigParser:
return CROSS_COMPILE.get(arch, '')
-def parse_one_config(self, config_attr, defconfig_lines,
- dotconfig_lines, autoconf_lines):
+def parse_one_config(self, config_attr, defconfig_lines, autoconf_lines):
Parse .config, defconfig, include/autoconf.mk for one config.
This function looks for the config options in the lines from
@@ -402,7 +405,6 @@ class KconfigParser:
config_attr: A dictionary including the name, the type,
and the default value of the target config.
defconfig_lines: lines from the original defconfig file.
- dotconfig_lines: lines from the .config file.
autoconf_lines: lines from the include/autoconf.mk file.
Returns:
@@ -418,7 +420,7 @@ class KconfigParser:
else:
default = config + '=' + config_attr['default']
-for line in defconfig_lines + dotconfig_lines:
+for line in defconfig_lines:
line = line.rstrip()
if line.startswith(config + '=') or line == not_set:
return (ACTION_ALREADY_EXIST, line)
@@ -463,15 +465,12 @@ class KconfigParser:
with open(defconfig_path) as f:
defconfig_lines = f.readlines()
-with open(dotconfig_path) as f:
-dotconfig_lines = f.readlines()
-
with open(autoconf_path) as f:
autoconf_lines = f.readlines()
for config_attr in self.config_attrs:
result = self.parse_one_config(config_attr, defconfig_lines,
- dotconfig_lines, autoconf_lines)
+ autoconf_lines)
results.append(result)
log = ''
@@ -499,7 +498,7 @@ class KconfigParser:
print log,
if not self.options.dry_run:
-with open(defconfig_path, 'a') as f:
+with open(dotconfig_path, 'a') as f:
for (action, value) in results:
if action == ACTION_MOVE:
f.write(value + '\n')
@@ -608,6 +607,19 @@ class Slot:
if self.state == STATE_AUTOCONF:
self.parser.update_defconfig(self.defconfig)
+
+Save off the defconfig in a consistent way
+cmd = list(self.make_cmd)
+cmd.append('savedefconfig')
+self.ps = subprocess.Popen(cmd, stdout=self.devnull,
+ stderr=self.devnull)
+self.state = STATE_SAVEDEFCONFIG
+return False
+
+if self.state == STATE_SAVEDEFCONFIG:
+defconfig_path = os.path.join(self.build_dir, 'defconfig')
+shutil.move(defconfig_path,
+os.path.join('configs', self.defconfig))
self.state = STATE_IDLE
return True
--
1.7.11.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 5/9] moveconfig: Cleanup headers in arch and board
Some config.h files live in arch and board directories. They will need
to be cleaned up as well, so run the same filters there.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v5:
-Consolidate code to clean up dirs
Changes in v4:
-New for version 4
Changes in v3: None
Changes in v2: None
tools/moveconfig.py | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index 561cd9a..f38dac1 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -347,11 +347,12 @@ def cleanup_headers(config_attrs, dry_run):
patterns.append(re.compile(r'#\s*define\s+%s\W' % config))
patterns.append(re.compile(r'#\s*undef\s+%s\W' % config))
-for (dirpath, dirnames, filenames) in os.walk('include'):
-for filename in filenames:
-if not fnmatch.fnmatch(filename, '*~'):
-cleanup_one_header(os.path.join(dirpath, filename), patterns,
- dry_run)
+for dir in 'include', 'arch', 'board':
+for (dirpath, dirnames, filenames) in os.walk(dir):
+for filename in filenames:
+if not fnmatch.fnmatch(filename, '*~'):
+cleanup_one_header(os.path.join(dirpath, filename),
+ patterns, dry_run)
### classes ###
class KconfigParser:
--
1.7.11.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/9] moveconfig: Ignore duplicate configs when moving
When moving configs, it is important to know what was defined in the
config header even if it duplicates the configs coming from Kconfig.
This is specifically needed for the case where a config is set to
default 'y' in the Kconfig. This would previously cause the actual value
from the include config to be filtered out, and moveconfig.py would
think that it was 'n'... This means that the value that should be 'y'
is now (in every defconfig) set to 'not set'.
tools/moveconfig.py now defines KCONFIG_IGNORE_DUPLICATES to prevent the
filtering from happening and selecting wrong values for the defconfig.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
Acked-by: Masahiro Yamada yamada.masah...@socionext.com
---
Changes in v5: None
Changes in v4: None
Changes in v3:
-New for version 3
Changes in v2: None
scripts/Makefile.autoconf | 3 ++-
tools/moveconfig.py | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/scripts/Makefile.autoconf b/scripts/Makefile.autoconf
index f054081..36bfa17 100644
--- a/scripts/Makefile.autoconf
+++ b/scripts/Makefile.autoconf
@@ -58,7 +58,8 @@ quiet_cmd_autoconf = GEN $@
$(CPP) $(c_flags) $2 -DDO_DEPS_ONLY -dM $(srctree)/include/common.h
$@.tmp { \
sed -n -f $(srctree)/tools/scripts/define2mk.sed $@.tmp |
\
while read line; do
\
- if ! grep -q $${line%=*}= include/config/auto.conf;
then \
+ if [ -n ${KCONFIG_IGNORE_DUPLICATES} ] ||
\
+ ! grep -q $${line%=*}= include/config/auto.conf;
then \
echo $$line;
\
fi
\
done $@;
\
diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index c9984b4..dd9434d 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -627,6 +627,7 @@ class Slot:
cmd = list(self.make_cmd)
if cross_compile:
cmd.append('CROSS_COMPILE=%s' % cross_compile)
+cmd.append('KCONFIG_IGNORE_DUPLICATES=1')
cmd.append('include/config/auto.conf')
self.ps = subprocess.Popen(cmd, stdout=self.devnull)
self.state = STATE_AUTOCONF
--
1.7.11.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 7/9] moveconfig: Print a message for missing compiler
A common case for failed builds is a missing compiler. Print a message
for that case to tell the user concisely which compiler was expected
that was not found.
This patch also has the effect of not printing build errors any longer.
The next patch will add a switch to optionally bring that back.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v5:
-Use scoped PIPE instead of importing it
-Set LANG=C for calling the compiler when planning to screen-scrape
-Use PIPE for all Popen
-Make missing compilers yellow
Changes in v4: None
Changes in v3: None
Changes in v2: None
tools/moveconfig.py | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index 8b8eed6..2fa98e3 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -572,7 +572,8 @@ class Slot:
return False
cmd = list(self.make_cmd)
cmd.append(defconfig)
-self.ps = subprocess.Popen(cmd, stdout=self.devnull)
+self.ps = subprocess.Popen(cmd, stdout=self.devnull,
+ stderr=subprocess.PIPE)
self.defconfig = defconfig
self.state = STATE_DEFCONFIG
return True
@@ -597,11 +598,18 @@ class Slot:
return False
if self.ps.poll() != 0:
-
+errmsg = 'Failed to process.'
+errout = self.ps.stderr.read()
+if errout.find('gcc: command not found') != -1:
+errmsg = 'Compiler not found ('
+errmsg += color_text(self.options.color, COLOR_YELLOW,
+ self.cross_compile)
+errmsg += color_text(self.options.color, COLOR_LIGHT_RED,
+ ')')
print sys.stderr, log_msg(self.options.color,
COLOR_LIGHT_RED,
self.defconfig,
- failed to process.)
+ errmsg),
if self.options.exit_on_error:
sys.exit(Exit on error.)
else:
@@ -619,7 +627,7 @@ class Slot:
cmd = list(self.make_cmd)
cmd.append('savedefconfig')
self.ps = subprocess.Popen(cmd, stdout=self.devnull,
- stderr=self.devnull)
+ stderr=subprocess.PIPE)
self.state = STATE_SAVEDEFCONFIG
return False
@@ -630,13 +638,17 @@ class Slot:
self.state = STATE_IDLE
return True
-cross_compile = self.parser.get_cross_compile()
+self.cross_compile = self.parser.get_cross_compile()
cmd = list(self.make_cmd)
-if cross_compile:
-cmd.append('CROSS_COMPILE=%s' % cross_compile)
+if self.cross_compile:
+cmd.append('CROSS_COMPILE=%s' % self.cross_compile)
cmd.append('KCONFIG_IGNORE_DUPLICATES=1')
cmd.append('include/config/auto.conf')
-self.ps = subprocess.Popen(cmd, stdout=self.devnull)
+This will be screen-scraped, so be sure the expected text will be
+returned consistently on every machine by setting LANG=C
+self.ps = subprocess.Popen(cmd, stdout=self.devnull,
+ env=dict(os.environ, LANG='C'),
+ stderr=subprocess.PIPE)
self.state = STATE_AUTOCONF
return False
--
1.7.11.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 6/9] moveconfig: Output a list of failed boards
If boards fail, output that list to a file so that it can easily be
passed back into moveconfig.py using the -d option.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v5:
-Changed file handling to use with/as
Changes in v4: None
Changes in v3: None
Changes in v2: None
tools/moveconfig.py | 4
1 file changed, 4 insertions(+)
diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index f38dac1..8b8eed6 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -716,6 +716,10 @@ class Slots:
print sys.stderr, color_text(self.options.color,
COLOR_LIGHT_RED, line)
+with open('moveconfig.failed', 'w') as f:
+for board in failed_boards:
+f.write(board + '\n')
+
def move_config(config_attrs, options):
Move config options to defconfig files.
--
1.7.11.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 8/9] moveconfig: Add a switch to enable printing errors
In some cases the build for the autoconf breaks. This outputs the errors
following the status so that action can be taken without building again
manually.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v5:
-Remove redundant destination
Changes in v4: None
Changes in v3: None
Changes in v2:
-New for version 2
tools/moveconfig.py | 8
1 file changed, 8 insertions(+)
diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index 2fa98e3..a6f1853 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -153,6 +153,9 @@ Available options
Specify the number of threads to run simultaneously. If not specified,
the number of threads is the same as the number of CPU cores.
+ -v, --verbose
+ Show any build errors as boards are built
+
To see the complete list of supported options, run
$ tools/moveconfig.py -h
@@ -610,6 +613,9 @@ class Slot:
COLOR_LIGHT_RED,
self.defconfig,
errmsg),
+if self.options.verbose:
+print sys.stderr, color_text(self.options.color,
+COLOR_LIGHT_CYAN, errout)
if self.options.exit_on_error:
sys.exit(Exit on error.)
else:
@@ -875,6 +881,8 @@ def main():
help='only cleanup the headers')
parser.add_option('-j', '--jobs', type='int', default=cpu_count,
help='the number of jobs to run simultaneously')
+parser.add_option('-v', '--verbose', action='store_true', default=False,
+ help='show any build errors as boards are built')
parser.usage += ' recipe_file\n\n' + \
'The recipe_file should describe config options you want
to move.\n' + \
'Each line should contain config_name, type,
default_value\n\n' + \
--
1.7.11.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 9/9] moveconfig: Print status about the processed defconfigs
This gives a basic idea about progress.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v5: None
Changes in v4: None
Changes in v3:
-New for version 3
Changes in v2: None
tools/moveconfig.py | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index a6f1853..a6e7c22 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -558,7 +558,7 @@ class Slot:
pass
shutil.rmtree(self.build_dir)
-def add(self, defconfig):
+def add(self, defconfig, num, total):
Assign a new subprocess for defconfig and add it to the slot.
If the slot is vacant, create a new subprocess for processing the
@@ -579,6 +579,8 @@ class Slot:
stderr=subprocess.PIPE)
self.defconfig = defconfig
self.state = STATE_DEFCONFIG
+self.num = num
+self.total = total
return True
def poll(self):
@@ -629,6 +631,9 @@ class Slot:
if self.state == STATE_AUTOCONF:
self.parser.update_defconfig(self.defconfig)
+print ' %d defconfigs out of %d\r' % (self.num + 1, self.total),
+sys.stdout.flush()
+
Save off the defconfig in a consistent way
cmd = list(self.make_cmd)
cmd.append('savedefconfig')
@@ -682,7 +687,7 @@ class Slots:
for i in range(options.jobs):
self.slots.append(Slot(config_attrs, options, devnull, make_cmd))
-def add(self, defconfig):
+def add(self, defconfig, num, total):
Add a new subprocess if a vacant slot is found.
Arguments:
@@ -692,7 +697,7 @@ class Slots:
Return True on success or False on failure
for slot in self.slots:
-if slot.add(defconfig):
+if slot.add(defconfig, num, total):
return True
return False
@@ -777,8 +782,8 @@ def move_config(config_attrs, options):
# Main loop to process defconfig files:
# Add a new subprocess into a vacant slot.
# Sleep if there is no available slot.
-for defconfig in defconfigs:
-while not slots.add(defconfig):
+for i, defconfig in enumerate(defconfigs):
+while not slots.add(defconfig, i, len(defconfigs)):
while not slots.available():
# No available slot: sleep for a while
time.sleep(SLEEP_TIME)
@@ -787,6 +792,7 @@ def move_config(config_attrs, options):
while not slots.empty():
time.sleep(SLEEP_TIME)
+print ''
slots.show_failed_boards()
def bad_recipe(filename, linenum, msg):
--
1.7.11.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 4/9] moveconfig: Add a switch to only cleanup headers
In some case you may want to only cleanup the headers. Make it possible
without waiting for all boards to compile.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v5:
-Move check_top_directory to main
Changes in v4: None
Changes in v3:
-New for version 3
Changes in v2: None
tools/moveconfig.py | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index e93548c..561cd9a 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -146,6 +146,9 @@ Available options
Exit immediately if Make exits with a non-zero status while processing
a defconfig file.
+ -H, --headers-only
+ Only cleanup the headers; skip the defconfig processing
+
-j, --jobs
Specify the number of threads to run simultaneously. If not specified,
the number of threads is the same as the number of CPU cores.
@@ -720,8 +723,6 @@ def move_config(config_attrs, options):
the type, and the default value of the target config.
options: option flags
-check_top_directory()
-
if len(config_attrs) == 0:
print 'Nothing to do. exit.'
sys.exit(0)
@@ -765,8 +766,6 @@ def move_config(config_attrs, options):
slots.show_failed_boards()
-cleanup_headers(config_attrs, options.dry_run)
-
def bad_recipe(filename, linenum, msg):
Print error message with the file name and the line number and exit.
sys.exit(%s: line %d: error : % (filename, linenum) + msg)
@@ -854,6 +853,9 @@ def main():
parser.add_option('-e', '--exit-on-error', action='store_true',
default=False,
help='exit immediately on any error')
+parser.add_option('-H', '--headers-only', dest='cleanup_headers_only',
+ action='store_true', default=False,
+ help='only cleanup the headers')
parser.add_option('-j', '--jobs', type='int', default=cpu_count,
help='the number of jobs to run simultaneously')
parser.usage += ' recipe_file\n\n' + \
@@ -874,7 +876,12 @@ def main():
update_cross_compile()
-move_config(config_attrs, options)
+check_top_directory()
+
+if not options.cleanup_headers_only:
+move_config(config_attrs, options)
+
+cleanup_headers(config_attrs, options.dry_run)
if __name__ == '__main__':
main()
--
1.7.11.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 3/9] moveconfig: Add a parameter to accept a list to build
This is helpful to re-attempt to move failed boards from a previous run
without starting over.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v5:
-Remove default 'r' mode on open
Changes in v4: None
Changes in v3:
-Fixed command line options order (alphabetize)
Changes in v2:
-New for version 2
tools/moveconfig.py | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index dd9434d..e93548c 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -135,6 +135,9 @@ Available options
Surround each portion of the log with escape sequences to display it
in color on the terminal.
+ -d, --defconfigs
+ Specify a file containing a list of defconfigs to move
+
-n, --dry-run
Peform a trial run that does not make any changes. It is useful to
see what is going to happen before one actually runs it.
@@ -729,12 +732,21 @@ def move_config(config_attrs, options):
config_attr['type'],
config_attr['default'])
-# All the defconfig files to be processed
-defconfigs = []
-for (dirpath, dirnames, filenames) in os.walk('configs'):
-dirpath = dirpath[len('configs') + 1:]
-for filename in fnmatch.filter(filenames, '*_defconfig'):
-defconfigs.append(os.path.join(dirpath, filename))
+if options.defconfigs:
+defconfigs = [line.strip() for line in open(options.defconfigs)]
+for i, defconfig in enumerate(defconfigs):
+if not defconfig.endswith('_defconfig'):
+defconfigs[i] = defconfig + '_defconfig'
+if not os.path.exists(os.path.join('configs', defconfigs[i])):
+sys.exit('%s - defconfig does not exist. Stopping.' %
+ defconfigs[i])
+else:
+# All the defconfig files to be processed
+defconfigs = []
+for (dirpath, dirnames, filenames) in os.walk('configs'):
+dirpath = dirpath[len('configs') + 1:]
+for filename in fnmatch.filter(filenames, '*_defconfig'):
+defconfigs.append(os.path.join(dirpath, filename))
slots = Slots(config_attrs, options)
@@ -835,6 +847,8 @@ def main():
# Add options here
parser.add_option('-c', '--color', action='store_true', default=False,
help='display the log in color')
+parser.add_option('-d', '--defconfigs', type='string',
+ help='a file containing a list of defconfigs to move')
parser.add_option('-n', '--dry-run', action='store_true', default=False,
help='perform a trial run (show log with no changes)')
parser.add_option('-e', '--exit-on-error', action='store_true',
--
1.7.11.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] sunxi: Make DRAM_ODT_EN Kconfig setting a bool
On Tue, 2015-05-19 at 18:39 +0200, Hans de Goede wrote:
Hi,
On 05/19/2015 04:13 PM, Ian Campbell wrote:
On Tue, 2015-05-19 at 14:56 +0200, Hans de Goede wrote:
diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
b/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
index c736fa3..f7b4915 100644
--- a/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
+++ b/arch/arm/cpu/armv7/sunxi/dram_sun4i.c
@@ -508,7 +508,7 @@ static void mctl_ddr3_initialize(void)
/*
* Perform impedance calibration on the DRAM controller side of the wire.
*/
-static void mctl_set_impedance(u32 zq, u32 odt_en)
+static void mctl_set_impedance(u32 zq, bool odt_en)
{
struct sunxi_dram_reg *dram = (struct sunxi_dram_reg *)SUNXI_DRAMC_BASE;
u32 reg_val;
@@ -556,7 +556,7 @@ static void mctl_set_impedance(u32 zq, u32 odt_en)
clrbits_le32(dram-zqcr0, DRAM_ZQCR0_ZCAL);
/* Set I/O configure register */
- writel(DRAM_IOCR_ODT_EN(odt_en), dram-iocr);
+ writel(DRAM_IOCR_ODT_EN, dram-iocr);
I think at this point previously odt_en would always be 0x1 here (0x0
having been short circuited earlier).
Whereas this...
-#define DRAM_IOCR_ODT_EN(n) n) 0x3) 30) | ((n) 0x3) 0)
-#define DRAM_IOCR_ODT_EN_MASK DRAM_IOCR_ODT_EN(0x3)
+#define DRAM_IOCR_ODT_EN ((3 30) | (3 0))
... now behaves as if it were always 0x3.
AFAICT up until now, at least with the in-tree defconfigs, odt_en was
always 0 for sun4i anyway, but this is a surprising change I think.
This is deliberate, as Siarhei explained in his reply to v2 the 2 bits
we are setting here enable odt for the DQ resp. DQS lines, having them
enabled for one but not the other does not really make sense.
I'll amend the commit message to explicitly mention this.
Thanks.
Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-net.git master
Hi Tom, This contains a few bug fixes and features from earlier in the merge window. The following changes since commit 0e6b7a28243175ae0874d53b6e6e4eff8548d71f: Merge git://git.denx.de/u-boot-samsung (2015-05-18 09:15:15 -0400) are available in the git repository at: git://git.denx.de/u-boot-net.git master for you to fetch changes up to d6bf59abead4069aa1164951d76a00d91f8f0298: net: Remove all calls to net_random_ethaddr() (2015-05-19 13:33:22 -0500) Joe Hershberger (4): net: Update hardware MAC address if it changes in env net: Implement random ethaddr fallback in eth.c net: Remove all references to CONFIG_ETHADDR and friends net: Remove all calls to net_random_ethaddr() Michal Simek (1): net: phy: Add support for all targets which requires MANUAL_RELOC Shengzhou Liu (2): net/phy: Add support for realtek RTL8211F net/phy: refactor RTL8211F initialization README | 19 ++ board/bct-brettl2/bct-brettl2.c| 13 board/bf518f-ezbrd/bf518f-ezbrd.c | 28 ++-- board/bf526-ezbrd/bf526-ezbrd.c| 28 ++-- board/bf527-ezkit/bf527-ezkit.c| 9 +-- board/bf537-minotaur/bf537-minotaur.c | 18 - board/bf537-pnav/bf537-pnav.c | 18 - board/bf537-srv1/bf537-srv1.c | 19 -- board/bf537-stamp/bf537-stamp.c| 28 ++-- board/buffalo/lsxl/lsxl.c | 10 --- board/cm-bf527/cm-bf527.c | 11 +--- board/cm-bf537e/cm-bf537e.c| 15 - board/cm-bf537u/cm-bf537u.c| 15 - board/dnp5370/dnp5370.c| 28 ++-- board/ip04/ip04.c | 12 board/tcm-bf518/tcm-bf518.c| 40 --- board/tcm-bf537/tcm-bf537.c| 15 - configs/bct-brettl2_defconfig | 3 +- configs/bf518f-ezbrd_defconfig | 2 + configs/bf526-ezbrd_defconfig | 2 + configs/bf527-ezkit_defconfig | 2 + configs/bf537-minotaur_defconfig | 2 + configs/bf537-pnav_defconfig | 2 + configs/bf537-srv1_defconfig | 2 + configs/bf537-stamp_defconfig | 2 + configs/cm-bf527_defconfig | 2 + configs/cm-bf537e_defconfig| 2 + configs/cm-bf537u_defconfig| 2 + configs/dnp5370_defconfig | 2 + configs/ip04_defconfig | 2 + configs/lschlv2_defconfig | 2 + configs/lsxhl_defconfig| 2 + configs/tcm-bf518_defconfig| 2 + configs/tcm-bf537_defconfig| 2 + doc/README.enetaddr| 4 +- drivers/net/bcm-sf2-eth.c | 6 -- drivers/net/designware.c | 4 -- drivers/net/dm9000x.c | 6 -- drivers/net/ftmac110.c | 3 - drivers/net/greth.c| 10 +-- drivers/net/lan91c96.c | 7 -- drivers/net/macb.c | 9 --- drivers/net/phy/phy.c | 16 + drivers/net/phy/realtek.c | 102 + examples/standalone/README.smc9_eeprom | 23 --- include/configs/M5208EVBE.h| 2 - include/configs/M5235EVB.h | 2 - include/configs/M5272C3.h | 2 - include/configs/M5282EVB.h | 2 - include/configs/M53017EVB.h| 3 - include/configs/M5329EVB.h | 2 - include/configs/M5373EVB.h | 2 - include/configs/M54418TWR.h| 3 - include/configs/M54451EVB.h| 2 - include/configs/M54455EVB.h| 3 - include/configs/M5475EVB.h | 5 -- include/configs/M5485EVB.h | 3 - include/configs/MPC8536DS.h| 4 -- include/configs/MPC8540ADS.h | 5 +- include/configs/MPC8541CDS.h | 3 - include/configs/MPC8544DS.h| 2 - include/configs/MPC8548CDS.h | 6 -- include/configs/MPC8555CDS.h | 5 -- include/configs/MPC8560ADS.h | 8 +-- include/configs/MPC8568MDS.h | 4 -- include/configs/MPC8572DS.h| 6 -- include/configs/MPC8610HPCD.h | 1 - include/configs/MPC8641HPCN.h | 10 +-- include/configs/a4m072.h | 1 - include/configs/bct-brettl2.h | 2 - include/configs/bf518f-ezbrd.h | 2 - include/configs/bf526-ezbrd.h | 2 - include/configs/bf527-ezkit.h | 2 - include/configs/bf533-ezkit.h | 2 -
Re: [U-Boot] [PATCH 20/20] tegra: config: nyan-big: Add options required by Chrome OS boot
On 05/18/2015 03:33 PM, Simon Glass wrote: Hi Stephen, On 15 May 2015 at 09:34, Stephen Warren swar...@wwwdotorg.org wrote: On 05/13/2015 07:56 AM, Simon Glass wrote: Hi Stephen, On 25 February 2015 at 16:31, Stephen Warren swar...@wwwdotorg.org wrote: On 02/17/2015 03:29 PM, Simon Glass wrote: We need to match the device tree in the FIT with the U-Boot model so we can automatically select the right device tree. Also adjust the load address so that the device tree is not in the way when a zImage kernel tries to extract itself. We don't tend to use LOADADDR in any of the default boot scripts any more. Rather, we explicitly load files to a semantic location indicated by one of the following variables in tegra124-common.h: #define MEM_LAYOUT_ENV_SETTINGS \ scriptaddr=0x9000\0 \ pxefile_addr_r=0x9010\0 \ kernel_addr_r=0x8100\0 \ fdt_addr_r=0x8200\0 \ ramdisk_addr_r=0x8210\0 Perhaps the ChromeOS boot scripts could be adjusted to use one/some of those variables? If the value of CONFIG_LOADADDR isn't appropriate, perhaps we should fix it for all Tegra SoCs/boards? I forgot about this comment sorry. I had problems with the image overwriting itself. It is a bzImage inside a FIT so doesn't use the proper FIT decompression. Anyway I'd like to clarify what is meant by kernel_addr_r. Is that where the FIT is loaded or where the kernel will decompress to, or something else? kernel_addr_r is the address in RAM at which a kernel zImage is loaded by config_distro_bootcmd.h scripts (and likely other scripts too). It's usually deliberately chosen to be a fair way into RAM, so that when the zImage decompresses (to approx the start of RAM), the decompressed image doesn't overlap the compressed image at kernel_addr_r. This avoids the kernel decompressor having to move/copy the zImage somewhere else before copying to avoid any overlap during decompression. config_distro_bootcmd.h doesn't support FIT, so I haven't tried out loading FIT images. That said, if U-Boot simply jumps to the location of the kernel in the FIT image itself without any copying, I would expect everything to work fine if you loaded a FIT image to kernel_addr_r. However, if the processing of the FIT image requires the kernel to be copied out of the FIT image to some other location, you'd have to carefully choose that location so it didn't overlap anything. I'd strongly recommend avoiding any unnecessary copies like that though, if at all possible, from the perspective of both pointlessly wasted execution time and simplicity of the boot process. Perhaps storing a a kernel_noload image type inside the FIT rather than a kernel image type might help there? Perhaps you want to introduce a new standard variable that defines where FIT images are loaded. I wonder what would be involved in adjusting config_distro_bootcmd to support FIT? Well, it goes against the very idea of config_distro_bootcmd, which is to provide a single standard mechanism that doesn't rely on any bootloader-specific file formats etc. That mechanism is a raw zImage, a raw initrd, and a plain text extlinux.cfg file to specify things like file paths/names, command-line, etc. The boot.scr support there is legacy, and not something that should be built upon going forward. So, that's not an argument for adding support for a third mechanism! Would it make it simpler or harder? To me, we should be moving to using FIT with U-Boot as it is much more flexible and better designed from the ground up to provide the required features. I disagree that FIT is a good idea, but that's a separate topic. Anyway, normally FIT has a compressed kernel (e.g. with LZO), not a bzImage. Do you mean FIT normally contains an originally uncompressed kernel (i.e. an Image file in ARM land at least), but then compresses it itself as part of FIT image generation? A bzImage is also a compressed kernel. So it seems like we need an additional decompression address. I suppose we could always use malloc() instead... But perhaps a FIT load address makes sense. But then we don't really need a kernel load address do we? Shouldn't that be specified in the FIT itself? A FIT load address does sound like it makes sense. If U-Boot copies the kernel image out of the FIT image to somewhere else, the FIT image shouldn't specify the address to copy it to. This varies per SoC, so if this address is hard-coded into FIT, it means the FIT image can't be used on different SoCs (or perhaps even different boards, depending on how differing RAM sizes work on various HW). This is why with config_distro_bootcmd, all the addresses come from the U-Boot environment, not hard-coded into a file on the disk. That way, the files are all generic and can be used on various different systems that require different addresses. It possibly makes sense for kernel_addr_r to be the destination of that copy?
Re: [U-Boot] [RFC PATCH] tools: get-toolchais: a tool to get cross-tools for all architectures
Hi Masahiro, On 18 May 2015 at 23:04, Masahiro Yamada yamada.masah...@socionext.com wrote: Hi Simon, 2015-05-18 2:50 GMT+09:00 Simon Glass s...@chromium.org: Hi Masahiro, On 15 May 2015 at 22:58, Masahiro Yamada yamada.masah...@socionext.com wrote: Hi Joe, (added Simon) 2015-05-16 4:52 GMT+09:00 Joe Hershberger joe.hershber...@gmail.com: Hi Masahiro-san, On Fri, May 15, 2015 at 6:01 AM, Masahiro Yamada yamada.masah...@socionext.com wrote: When we send patches, we are supposed to test them by build utilities such as MAKEALL, buildman. When we want to test global changes, the first hurdle is, I think, to collect toolchains for all the architectures. We have some documents about build utilities, but I have not seen any official information about how to get the suitable cross-tools. Of course, it is possible to build them from sources, but it is not necessarily feasible. Fortunately, the kernel.org site provides us pre-built toolchains, but some architectures are missing. Also, some boards fail to build with the kernel.org tools. We sometimes see, where can I get the compiler for this architecture? things on the ML. We should be able to prepare cross-compilers more easily. It is true that buildman provides --fetch-arch option for downloading kernel.org toolchains, but it does not have access to others. And what we really want to know is most likely how to get compilers for such minor architectures as kernel.org does not provide. Maybe just integrate this into buildman? Or remove it from buildman? In buildman has the benefit that it updates buildman's config to know how to find the compiler. I wanted to add more options to provide better flexibility. For example, I wanted --destdir option because I think installing tools under /opt/ or /usr/loca/ is a generic demand. That's why I implemented this tool as a separate script. I also want to hear Simon's opinion. I think a separate script is fine - it helps if we can reduce the functionality in buildman. But buildman should call this script. We cannot mix up python 2 and 3 script. If buildman should call this script, it must be re-written in 2. Could it not call it at the command line instead of importing it? Then it would not matter. What benefit do we get with Python 3? Also I think your script should use urllib2 and IMO the simple progress update that buildman provides is plenty. In python 2, there exist two libraries, urllib and urlib2, to do similar things. In python 3, the former was discontinued and the latter was renamed into urllib. So, the urllib I am using in my python 3 script is equivalent to what you call urllib2 in python 2. Re the destination, buildman could provide its own destination for its download operation. But I suggest we use the same default one for both. OK, I can do this. Perhaps your default makes more sense that buildman's? After all, buildman doesn't really care where it is. This tool intends to be more generic design without hard-coding such kernel.org things. To achieve that, this tool consists of two files: Python script (this file) and the database file containing URLs of tarballs. We just need to update the latter when new version compilers are released (or better compilers are found.) The file is in the form of RFC 822 for easier editing. Any reason not to just maintain this list on the wiki. It seem this is the primary issue for everyone... not figuring out how to download or extract the toolchain. I can just note URLs down in README or wiki. Of course, everyone knows how to download a tarball and extract it, but isn't it more convenient to prepare a utility that can do everything for you? The script only uses Python libraries, not relies on external programs although it displays wget-like log when downloading tarballs. :-) It seems like using wget would be more appropriate. Why reinvent the wheel? My intention was to not depend on particular external programs like wget, curl. But, you are right, we should not reinvent the wheel. I will replace my implementation with a caller of wget. I think urllib2 is a better solution. Now I understand we must depend on tar anyway. So my first intention no external program dependency seems impossible (at least on Python 2). I do not mind depending on wget, and it seems easier. Is wget always installed? Maybe urllib is better just in case. This is RFC because I am thinking it can be more brushed up. If the basis idea is OK, I will improve code, add more comments. Note this script is written in Python 3 and only works on Python 3.3 or later. I do not think it is too much limitation, but some popular distributions under support might include older version. For example, looks like Ubuntu 12.04 LTS is shipped with Python 3.2. Why not write it in something that exists everywhere? If it's just for downloading tool-chains, seems it should be easy to
Re: [U-Boot] [PATCH v4 00/26] Improve env var handling for net stack
Hi Tom, On Thu, May 7, 2015 at 4:48 AM, Joe Hershberger joe.hershber...@ni.com wrote: This includes moving CONFIG_REGEX to Kconfig and adding support for regex to the env_attr lists (when CONFIG_REGEX is enabled). This allows ethaddrs to all be checked for access and format by default. Also use callbacks to keep network stack variables up to date instead of polling them on each call to net_loop. This is a step in the right direction to refactoring the network stack to be similar to that of barebox. Also added a test command to host unit tests for the env functions. Changes in v4: -Fixed bisectability issue -New for version 4 Changes in v3: -Moved test from env subcommand to ut subcommand -New for version 3 Changes in v2: -Added comments about the use of .flags in the dm eth test -Added description to README -Fix bisectability issue -Fix corner case in reverse_name_search() where searched starts with ' ' -New for version 2 -Simplified test for H_PROGRAMMATIC Joe Hershberger (26): sandbox: Cleanup order and extra defines in defconfig sandbox: Use defconfig to enable features sandbox: Enable some ENV commands kconfig: Move REGEX to Kconfig env: Fix return values in env_attr_lookup() env: Simplify the reverse_strstr() interface env: Allow env_attr_walk to pass a priv * to callback env: Add regex support to env_attrs env: Distinguish finer between source of env change net: Apply default format rules to all ethaddr net: Use env callbacks for net variables net: Add default flags for common net env vars net: Remove duplicate bootfile syncing functionality net: Handle ethaddr changes as an env callback test: Generalize the unit test framework test: Add a common unit test command test: dm: Move the dm tests over to the ut command test: Move the unit tests to their own menu test: dm: Don't bail on all tests if one test fails test: dm: eth: Handle failed test env cleanup test: Return values from the asserts compatible with cmds test: dm: Recover the driver model tree after tests test: env: Add test framework for env test: env: Add test for verifying env attrs test: env: Add a test of the new regex behavior for attrs sandbox: Enable env unit tests Please pull this in. Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] usb: kbd: Fix key repeat not always working
The usb-kbd key repeat code assumes that reports get repeated every 40 ms,
this is never true when using CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP, and
does not always works for CONFIG_SYS_USB_EVENT_POLL and
CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE since not all usb keyboards honor
the usb_set_idle() command.
For CONFIG_SYS_USB_EVENT_POLL we must use usb_set_idle() since we do a
blocking wait for the hid report, so if we do not tell the keyboard to send
a hid report every 40ms even if nothing changes then we will block u-boot
for 1s (the default u-boot usb interrupt packet timeout). Note that in this
case on keyboards which do not support usb_set_idle() we loose and we actually
get 1s latencies on other u-boot activities.
For the other poll-methods this commit stops using usb_set_idle() and instead
repeats the last received hid-report every 40 ms as long as no new hid-report
is received. This fixes key-repeat not working at all with
CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP and fixes it not working with
keyboards which do not implement usb_set_idle() when using
CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v2:
-Change last_report type to unsigned long to match the get_timer return type
Changes in v3:
-Fix compilation when none of the 3 types of CONFIG_SYS_USB_EVENT_POLL*
settings is defined
---
common/usb_kbd.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/common/usb_kbd.c b/common/usb_kbd.c
index 24a1a56..49bfc09 100644
--- a/common/usb_kbd.c
+++ b/common/usb_kbd.c
@@ -31,7 +31,7 @@ int overwrite_console(void)
#endif
/* Keyboard sampling rate */
-#define REPEAT_RATE(40 / 4)/* 40msec - 25cps */
+#define REPEAT_RATE40 /* 40msec - 25cps */
#define REPEAT_DELAY 10 /* 10 x REPEAT_RATE = 400msec */
#define NUM_LOCK 0x53
@@ -103,6 +103,7 @@ struct usb_kbd_pdata {
unsigned long intpipe;
int intpktsize;
int intinterval;
+ unsigned long last_report;
struct int_queue *intq;
uint32_trepeat_delay;
@@ -310,7 +311,7 @@ static int usb_kbd_irq(struct usb_device *dev)
/* Interrupt polling */
static inline void usb_kbd_poll_for_event(struct usb_device *dev)
{
-#ifdefined(CONFIG_SYS_USB_EVENT_POLL)
+#if defined(CONFIG_SYS_USB_EVENT_POLL)
struct usb_kbd_pdata *data = dev-privptr;
/* Submit a interrupt transfer request */
@@ -318,15 +319,17 @@ static inline void usb_kbd_poll_for_event(struct
usb_device *dev)
data-intinterval);
usb_kbd_irq_worker(dev);
-#elif defined(CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP)
+#elif defined(CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP) || \
+ defined(CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE)
+#if defined(CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP)
struct usb_interface *iface;
struct usb_kbd_pdata *data = dev-privptr;
iface = dev-config.if_desc[0];
usb_get_report(dev, iface-desc.bInterfaceNumber,
1, 0, data-new, USB_KBD_BOOT_REPORT_SIZE);
- if (memcmp(data-old, data-new, USB_KBD_BOOT_REPORT_SIZE))
+ if (memcmp(data-old, data-new, USB_KBD_BOOT_REPORT_SIZE)) {
usb_kbd_irq_worker(dev);
-#elif defined(CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE)
+#else
struct usb_kbd_pdata *data = dev-privptr;
if (poll_int_queue(dev, data-intq)) {
usb_kbd_irq_worker(dev);
@@ -335,6 +338,13 @@ static inline void usb_kbd_poll_for_event(struct
usb_device *dev)
data-intq = create_int_queue(dev, data-intpipe, 1,
USB_KBD_BOOT_REPORT_SIZE, data-new,
data-intinterval);
+#endif
+ data-last_report = get_timer(0);
+ /* Repeat last usb hid report every REPEAT_RATE ms for keyrepeat */
+ } else if (data-last_report != -1
+ get_timer(data-last_report) REPEAT_RATE) {
+ usb_kbd_irq_worker(dev);
+ data-last_report = get_timer(0);
}
#endif
}
@@ -445,12 +455,16 @@ static int usb_kbd_probe(struct usb_device *dev, unsigned
int ifnum)
data-intpktsize = min(usb_maxpacket(dev, data-intpipe),
USB_KBD_BOOT_REPORT_SIZE);
data-intinterval = ep-bInterval;
+ data-last_report = -1;
/* We found a USB Keyboard, install it. */
usb_set_protocol(dev, iface-desc.bInterfaceNumber, 0);
+#if !defined(CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP) \
+!defined(CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE)
debug(USB KBD: found set idle...\n);
- usb_set_idle(dev, iface-desc.bInterfaceNumber, REPEAT_RATE, 0);
+ usb_set_idle(dev, iface-desc.bInterfaceNumber, REPEAT_RATE / 4, 0);
+#endif
debug(USB KBD: enable interrupt pipe...\n);
#ifdef
Re: [U-Boot] [PATCH V2 11/13] test: dm: test.dts - move to sandbox dts directory
Hi Joe, On 19 May 2015 at 13:23, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Simon, On Tue, May 19, 2015 at 2:21 PM, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Simon, On Fri, May 15, 2015 at 8:56 AM, Simon Glass s...@chromium.org wrote: On 13 May 2015 at 05:38, Przemyslaw Marczak p.marc...@samsung.com wrote: The file test.dts from driver model test directory, was compiled by call dtc in script: test/dm/test-dm.sh. This doesn't allow for including of dtsi files and using of C preprocessor routines in this dts file. Since the mentioned script builds U-Boot before tests, then moving the test.dts file into sandbox dts directory is reasonable. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Acked-by: Simon Glass s...@chromium.org Tested on sandbox: Tested-by: Simon Glass s...@chromium.org --- Changes V2: - new commit --- arch/sandbox/dts/Makefile | 1 + arch/sandbox/dts/test.dts | 230 ++ test/dm/.gitignore| 1 - test/dm/test-dm.sh| 3 +- test/dm/test-main.c | 3 +- test/dm/test.dts | 230 -- 6 files changed, 233 insertions(+), 235 deletions(-) create mode 100644 arch/sandbox/dts/test.dts delete mode 100644 test/dm/.gitignore delete mode 100644 test/dm/test.dts Applied to u-boot-dm, thanks! This patch effectively reverted fbe07ba0f: dm: test: dts: Sort the aliases in the test device tree file It seems this file was moved before other patches went in and never updated. Maybe there are other merge-conflict resolution errors? Ah yes... it also reverted 4772511: dm: rtc: Add tests for real-time clocks Thanks for spotting that. There was another one in uclass-ids.h for which I have a patch sitting behind various other work. But I'll see if I can get something out sooner. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 20/20] tegra: config: nyan-big: Add options required by Chrome OS boot
On 05/19/2015 12:01 PM, Simon Glass wrote: Hi Stephen, On 19 May 2015 at 09:41, Stephen Warren swar...@wwwdotorg.org wrote: On 05/18/2015 03:33 PM, Simon Glass wrote: Hi Stephen, On 15 May 2015 at 09:34, Stephen Warren swar...@wwwdotorg.org wrote: On 05/13/2015 07:56 AM, Simon Glass wrote: Hi Stephen, On 25 February 2015 at 16:31, Stephen Warren swar...@wwwdotorg.org wrote: On 02/17/2015 03:29 PM, Simon Glass wrote: We need to match the device tree in the FIT with the U-Boot model so we can automatically select the right device tree. Also adjust the load address so that the device tree is not in the way when a zImage kernel tries to extract itself. We don't tend to use LOADADDR in any of the default boot scripts any more. Rather, we explicitly load files to a semantic location indicated by one of the following variables in tegra124-common.h: #define MEM_LAYOUT_ENV_SETTINGS \ scriptaddr=0x9000\0 \ pxefile_addr_r=0x9010\0 \ kernel_addr_r=0x8100\0 \ fdt_addr_r=0x8200\0 \ ramdisk_addr_r=0x8210\0 Perhaps the ChromeOS boot scripts could be adjusted to use one/some of those variables? If the value of CONFIG_LOADADDR isn't appropriate, perhaps we should fix it for all Tegra SoCs/boards? I forgot about this comment sorry. I had problems with the image overwriting itself. It is a bzImage inside a FIT so doesn't use the proper FIT decompression. Anyway I'd like to clarify what is meant by kernel_addr_r. Is that where the FIT is loaded or where the kernel will decompress to, or something else? kernel_addr_r is the address in RAM at which a kernel zImage is loaded by config_distro_bootcmd.h scripts (and likely other scripts too). It's usually deliberately chosen to be a fair way into RAM, so that when the zImage decompresses (to approx the start of RAM), the decompressed image doesn't overlap the compressed image at kernel_addr_r. This avoids the kernel decompressor having to move/copy the zImage somewhere else before copying to avoid any overlap during decompression. config_distro_bootcmd.h doesn't support FIT, so I haven't tried out loading FIT images. That said, if U-Boot simply jumps to the location of the kernel in the FIT image itself without any copying, I would expect everything to work fine if you loaded a FIT image to kernel_addr_r. However, if the processing of the FIT image requires the kernel to be copied out of the FIT image to some other location, you'd have to carefully choose that location so it didn't overlap anything. I'd strongly recommend avoiding any unnecessary copies like that though, if at all possible, from the perspective of both pointlessly wasted execution time and simplicity of the boot process. Perhaps storing a a kernel_noload image type inside the FIT rather than a kernel image type might help there? Perhaps you want to introduce a new standard variable that defines where FIT images are loaded. I wonder what would be involved in adjusting config_distro_bootcmd to support FIT? Well, it goes against the very idea of config_distro_bootcmd, which is to provide a single standard mechanism that doesn't rely on any bootloader-specific file formats etc. That mechanism is a raw zImage, a raw initrd, and a plain text extlinux.cfg file to specify things like file paths/names, command-line, etc. The boot.scr support there is legacy, and not something that should be built upon going forward. So, that's not an argument for adding support for a third mechanism! Do we need to adjust the mechanism? The only difference I see is that FIT brings the files together. No, it's just fine as it is. The benefit of the existing mechanism is precisely that nobody has to package the zImage/initrd/... together, whereas that appears to be precisely the purpose of FIT. The two schemes are by definition opposites of each-other. Would it make it simpler or harder? To me, we should be moving to using FIT with U-Boot as it is much more flexible and better designed from the ground up to provide the required features. I disagree that FIT is a good idea, but that's a separate topic. Anyway, normally FIT has a compressed kernel (e.g. with LZO), not a bzImage. Do you mean FIT normally contains an originally uncompressed kernel (i.e. an Image file in ARM land at least), but then compresses it itself as part of FIT image generation? A bzImage is also a compressed kernel. That's right, that's what I mean. So it seems like we need an additional decompression address. I suppose we could always use malloc() instead... But perhaps a FIT load address makes sense. But then we don't really need a kernel load address do we? Shouldn't that be specified in the FIT itself? A FIT load address does sound like it makes sense. If U-Boot copies the kernel image out of the FIT image to somewhere else, the FIT image shouldn't specify the address to copy it to. This varies per SoC, so if this address
Re: [U-Boot] [PATCH v6 1/4] mtd, spi: add MTD layer driver
Hi Heiko, I have tested this sf-mtd stuff, please see below and enabled prints in all the func calls. zynq-uboot mtdparts add nor0 0x1@0x0 env mtdparts variable not set, see 'help mtdparts' zynq-uboot mtdparts device nor0 zynq-sf.0, # parts = 1 #: namesizeoffset mask_flags 0: env 0x0001 0x 0 active partition: nor0,0 - (env) 0x0001 @ 0x defaults: mtdids : nor0=zynq-sf.0 mtdparts: none zynq-uboot sf erase env 0x1 spi_flash_erase spi_flash_cmd_erase_ops SF: erase d8 0 0 0 (0) SF: 65536 bytes @ 0x0 Erased: OK zynq-uboot mw.b 0x100 0x44 0x1 zynq-uboot sf write 0x100 env device 0 offset 0x0, size 0x1 spi_flash_cmd_write_ops SF: 65536 bytes @ 0x0 Written: OK zynq-uboot sf read 0x4 env device 0 offset 0x0, size 0x1 spi_flash_cmd_read_ops off = 0x1, len = 0 SF: 65536 bytes @ 0x0 Read: OK zynq-uboot cmp.b 0x100 0x4 0x1 Total of 65536 byte(s) were the same I wonder none of the sf_mtd_info._* getting called, why? On 27 April 2015 at 11:12, Heiko Schocher h...@denx.de wrote: From: Daniel Schwierzeck daniel.schwierz...@gmail.com add MTD layer driver for spi, original patch from: http://git.denx.de/?p=u-boot/u-boot-mips.git;a=commitdiff;h=bb246819cdc90493dd7089eaa51b9e639765cced changes from Heiko Schocher against this patch: - remove compile error if not defining CONFIG_SPI_FLASH_MTD: LD drivers/mtd/spi/built-in.o drivers/mtd/spi/sf_probe.o: In function `spi_flash_mtd_unregister': /home/hs/abb/imx6/u-boot/drivers/mtd/spi/sf_internal.h:168: multiple definition of `spi_flash_mtd_unregister' drivers/mtd/spi/sf_params.o:/home/hs/abb/imx6/u-boot/drivers/mtd/spi/sf_internal.h:168: first defined here drivers/mtd/spi/sf_ops.o: In function `spi_flash_mtd_unregister': /home/hs/abb/imx6/u-boot/drivers/mtd/spi/sf_internal.h:168: multiple definition of `spi_flash_mtd_unregister' drivers/mtd/spi/sf_params.o:/home/hs/abb/imx6/u-boot/drivers/mtd/spi/sf_internal.h:168: first defined here make[1]: *** [drivers/mtd/spi/built-in.o] Fehler 1 make: *** [drivers/mtd/spi] Fehler 2 - add a README entry. - add correct writebufsize, to fit with Linux v3.14 MTD, UBI/UBIFS sync. Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com Signed-off-by: Heiko Schocher h...@denx.de --- Changes in v6: None Changes in v2: - add comment from Daniel Schwierzeck: fix compile error from original patch with static inline rather than static __maybe_unused Series-changes: 3 - rebase with d6c1ffc7d23f4fe4ae8c91101861055b8e1501b6 Series-changes: 4 - rebased against 385a08a60f042061b004642d6b9bb6cfb794ad5a Series-changes: 5 - no changes Series-changes: 6 - add comments from Jagan Teki: move code, which checks if flash pointer is used into a new patch. - use #ifdef in Code - call mtd register before the spi_release_bus README| 3 ++ common/cmd_sf.c | 2 - drivers/mtd/spi/Makefile | 1 + drivers/mtd/spi/sf_internal.h | 5 ++ drivers/mtd/spi/sf_mtd.c | 104 ++ drivers/mtd/spi/sf_probe.c| 10 ++-- 6 files changed, 119 insertions(+), 6 deletions(-) create mode 100644 drivers/mtd/spi/sf_mtd.c diff --git a/README b/README index fc1fd52..36f6fc9 100644 --- a/README +++ b/README @@ -3097,6 +3097,9 @@ CBFS (Coreboot Filesystem) support operation will not execute. The only way to exit this hardware-protected mode is to drive W#/VPP HIGH. + CONFIG_SPI_FLASH_MTD + add MTD translation layer driver. + - SystemACE Support: CONFIG_SYSTEMACE diff --git a/common/cmd_sf.c b/common/cmd_sf.c index 6aabf39..0250011 100644 --- a/common/cmd_sf.c +++ b/common/cmd_sf.c @@ -139,8 +139,6 @@ static int do_spi_flash_probe(int argc, char * const argv[]) return 1; } - if (flash) - spi_flash_free(flash); flash = new; #endif diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile index c61b784e..f8580cd 100644 --- a/drivers/mtd/spi/Makefile +++ b/drivers/mtd/spi/Makefile @@ -17,5 +17,6 @@ obj-$(CONFIG_SPI_FLASH) += sf_probe.o #endif obj-$(CONFIG_CMD_SF) += sf.o obj-$(CONFIG_SPI_FLASH) += sf_ops.o sf_params.o +obj-$(CONFIG_SPI_FLASH_MTD) += sf_mtd.o obj-$(CONFIG_SPI_FLASH_SANDBOX) += sandbox.o obj-$(CONFIG_SPI_M95XXX) += eeprom_m95xxx.o diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h index 785f7a9..8a2eb6e 100644 --- a/drivers/mtd/spi/sf_internal.h +++ b/drivers/mtd/spi/sf_internal.h @@ -221,4 +221,9 @@ int spi_flash_read_common(struct spi_flash *flash, const u8 *cmd, int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 offset, size_t len, void *data); +#ifdef CONFIG_SPI_FLASH_MTD +int spi_flash_mtd_register(struct spi_flash *flash);
Re: [U-Boot] [PATCH 04/12] sunxi: Update sunxi-common.h to deal with different DRAM base addr on sun9i
Hi Ian, On 01/17/2015 11:44 PM, Ian Campbell wrote: On Thu, 2015-01-15 at 15:52 +0100, Hans de Goede wrote: The DRAM Base differs between sun9i and the others and we cannot use math in various places like the environment setting and linker scripts, so simply define everything which contains the SDRAM_BASE twice. Is it really not possible to use maths in linker scripts? How have I never noticed that... Anyway, given that things only differ in the most significant nibble of the RAM base address I think something like this might work: /* NB: find out if one of these is already available somewhere */ #define __stringify(x) #x #define stringify(x) __stringify(x) #define SDRAM_OFFSET(x) 0x2##x /* or 0x4 */ #define CONFIG_SYS_SDRAM_BASE SDRAM_OFFSET(000) #define MEM_LAYOUT_ENV_SETTINGS \ kernel_addr_r= stringify(SDRAM_OFFSET(20)) \0 ... I've finally brushed of these patches and I'm working on cleaning them up now. Unfortunately a lot of the CONFIG_xxx variables with dram base address derived values get exported through cpp -E -dM which does not do macro expansion, and then used in Makefiles to pass to the linker and such. So I've been unable to get big of the #ifdef ... #else ... #endif block setting various defines for this. I've been able to make the environment block use the trick you suggested, so this does give a nice cleanup. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-sunxi master
Hi Tom, Please pull u-boot-sunxi/master into master for various small bugfixes, improvements and one new board. The following changes since commit 0e6b7a28243175ae0874d53b6e6e4eff8548d71f: Merge git://git.denx.de/u-boot-samsung (2015-05-18 09:15:15 -0400) are available in the git repository at: http://git.denx.de/u-boot-sunxi.git for you to fetch changes up to 8a65f69c9cef09aebc20aca98a4ddbf2b4829995: sunxi: Cache line size definition (2015-05-19 18:46:44 +0200) Hans de Goede (6): sunxi: Set SYS_MALLOC_CLEAR_ON_INIT to n console: Fix pre-console flushing via cfb_console being very slow sunxi: Fix dram initialization not working on some a33 devices sunxi: Make DRAM_ODT_EN Kconfig setting a bool sunxi: video: Fix lvds panel support for sun6i+ sunxi: Add ga10h v1.1 defconfig Laurent Itti (1): sunxi: add support for UART2 on A23/A33 Paul Kocialkowski (3): sunxi: Pass serial number through ATAG sunxi: VBUS detection function fixup in g_dnl_board_usb_cable_connected sunxi: Cache line size definition README | 3 ++ arch/arm/cpu/armv7/sunxi/board.c | 4 +++ arch/arm/cpu/armv7/sunxi/dram_sun4i.c| 4 +-- arch/arm/cpu/armv7/sunxi/dram_sun8i_a23.c| 19 ++- arch/arm/cpu/armv7/sunxi/dram_sun8i_a33.c| 6 ++-- arch/arm/include/asm/arch-sunxi/clock_sun6i.h| 3 ++ arch/arm/include/asm/arch-sunxi/display.h| 12 +++ arch/arm/include/asm/arch-sunxi/dram_sun4i.h | 3 +- arch/arm/include/asm/arch-sunxi/dram_sun8i_a23.h | 1 + arch/arm/include/asm/arch-sunxi/gpio.h | 1 + board/sunxi/Kconfig | 28 - board/sunxi/MAINTAINERS | 1 + board/sunxi/board.c | 22 - board/sunxi/dram_sun4i_auto.c| 3 +- board/sunxi/dram_sun5i_auto.c| 3 +- common/console.c | 40 +--- configs/ga10h_v1_1_defconfig | 29 + drivers/video/sunxi_display.c| 18 ++- include/configs/sunxi-common.h | 8 - 19 files changed, 161 insertions(+), 47 deletions(-) create mode 100644 configs/ga10h_v1_1_defconfig Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: imx: Switch Wandboard to use config_distro_bootcmd.h.
On 2015-05-19, XoD wrote: Any new of this ? it can be merged ? I think my submitted patch was a bit too invasive by removing most of the environment, and have reworked the patch to leave much of the environment: https://anonscm.debian.org/cgit/collab-maint/u-boot.git/tree/debian/patches/wandboard/config_distro_bootcmd.patch?h=experimental-2015.04 I haven't yet reworked it for resubmission, but I'd be happy to do so. I was hoping to see the wandboard SPL support added before reworking, as that will require a few minor changes to the config_distro_bootcmd patch as well: https://patchwork.ozlabs.org/patch/471092/ I have tested and successfully boot a fedora on a Wandboard Quad with this. The improvement of the console variable management can be done with an other patch ? It would be nice if switching to config_distro_bootcmd.h was not dependent on sorting out the console variable switch... though I'd be fine with switching the default console to include the baudrate as well. Thank you for working on this. Thanks for testing! live well, vagrant 2015-03-29 15:05 GMT+02:00 Tom Rini tr...@konsulko.com: On Sat, Mar 28, 2015 at 02:15:38PM +0100, Karsten Merker wrote: On Fri, Mar 27, 2015 at 06:24:43PM -0700, Vagrant Cascadian wrote: This allows for more flexible and standardized boot across multiple platforms. Remove most redundant legacy boot environment. Cc: Otavio Salvador ota...@ossystems.com.br Signed-off-by: Vagrant Cascadian vagr...@debian.org --- include/configs/wandboard.h | 139 ++-- 1 file changed, 17 insertions(+), 122 deletions(-) diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h [...] #define CONFIG_EXTRA_ENV_SETTINGS \ - script=boot.scr\0 \ - image=zImage\0 \ console=ttymxc0\0 \ Hello, regarding the boot environment standardization there is still the open topic of standardizing the console variable format for serial consoles - most platforms include the console baudrate in the console variable (e.g. console=ttyS0,115200) while some others, in particular the i.MX6 platforms, do not. This means that distributions like Debian currently need to add special-case handling for i.MX6-based platforms in their boot scripts which goes against the idea of having one generic boot script for all platforms that use config_distro_bootcmd.h. It would be nice if the i.MX6 platforms could - while adopting config_distro_bootcmd.h and thereby changing their default environment to a large extend - also change their console variable from console=ttymxc0 to console=ttymxc0,115200. Yes please. And Karsten can you do a patch that updates the README to note that as an expectation? Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Fix fsl_elbc_nand driver
On Mon, 2015-05-18 at 19:16 -0700, Andrei Yakimov wrote: This is my best try. I have test it with my old u-boot, but not with master. Do not have a bench for it. A bench? This is not very important patch. I do not find any other ONFI user in u-boot. Andrei From d76b4ae8e866affa15dd9da860574d0600969d57 Mon Sep 17 00:00:00 2001 From: Andrei Yakimov ayaki...@iptec-inc.com Date: Mon, 18 May 2015 18:50:12 -0700 Subject: [PATCH] ONFI detect reading only first parameter page. NAND_CMD_PARAM read only first parameter page. Need to read all 3 (as per ONFI spec) due to no error correction for this area Signed-off-by: Andrei Yakimov ayaki...@iptec-inc.com --- drivers/mtd/nand/fsl_elbc_nand.c |9 + drivers/mtd/nand/fsl_ifc_nand.c | 10 ++ 2 files changed, 11 insertions(+), 8 deletions(-) diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c index e85832d..8ac470f 100644 --- a/drivers/mtd/nand/fsl_elbc_nand.c +++ b/drivers/mtd/nand/fsl_elbc_nand.c @@ -336,11 +336,12 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command, (FIR_OP_RBW FIR_OP2_SHIFT)); out_be32(lbc-fcr, command FCR_CMD0_SHIFT); /* - * although currently it's 8 bytes for READID, we always read - * the maximum 256 bytes(for PARAM) + * although currently it's 8 bytes for READID + * param page containg at least 3 copy for + * robustnes, we need to read them all. */ - out_be32(lbc-fbcr, 256); - ctrl-read_bytes = 256; + out_be32(lbc-fbcr, (command == NAND_CMD_PARAM) ? 786 : 8); + ctrl-read_bytes = (command == NAND_CMD_PARAM) ? 786 : 8; 786? Not 768? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 07/10] moveconfig: Output a list of failed boards
Hi Masahiro-san,
On Mon, May 18, 2015 at 10:12 PM, Masahiro Yamada
yamada.masah...@socionext.com wrote:
2015-05-16 6:40 GMT+09:00 Joe Hershberger joe.hershber...@ni.com:
If boards fail, output that list to a file so that it can easily be
passed back into moveconfig.py using the -d option.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
tools/moveconfig.py | 4
1 file changed, 4 insertions(+)
diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index 15b0f2b..9e923da 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -728,6 +728,10 @@ class Slots:
for line in msg:
print sys.stderr, color_text(self.options.color,
COLOR_LIGHT_RED, line)
+ffail = open('moveconfig.failed', 'w')
+for failed_board in failed_boards:
+ffail.write(%s\n % failed_board)
+ffail.close()
def move_config(config_attrs, options):
Move config options to defconfig files.
If you use with ... as ..., it will automatically close
the file on exit.
with open('moveconfig.failed', 'w') as f:
for board in failed_boards:
f.write(board + '\n')
OK.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
On Tue, May 19, 2015 at 12:48:19PM +0200, Marek Vasut wrote: The following changes since commit 0e6b7a28243175ae0874d53b6e6e4eff8548d71f: Merge git://git.denx.de/u-boot-samsung (2015-05-18 09:15:15 -0400) are available in the git repository at: git://git.denx.de/u-boot-usb.git HEAD for you to fetch changes up to 9cf3c384ad96c3e00c12e1d151d7f32c5b760a03: include:configs:ls1021aqds: Enable USB IP support (2015-05-19 12:42:16 +0200) NAK. This introduces various breakage: 12: Merge branch 'master' of git://git.denx.de/u-boot-usb arm: + VCMA9 beagle_x15 at91rm9200ek_ram peach-pi snow smdk5250 am43xx_evm dr a7xx_evm_uart3 k2l_evm am43xx_evm_qspiboot smdk5420 dra7xx_evm smdk2410 at91rm9200ek dr a7xx_evm_qspiboot k2hk_evm k2e_evm peach-pit powerpc: + PIP405 MIP405 The powerpc board breakage is the same as some of the ARM ones so fix it once and they'll come along. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 20/20] tegra: config: nyan-big: Add options required by Chrome OS boot
Hi Stephen, On 19 May 2015 at 09:41, Stephen Warren swar...@wwwdotorg.org wrote: On 05/18/2015 03:33 PM, Simon Glass wrote: Hi Stephen, On 15 May 2015 at 09:34, Stephen Warren swar...@wwwdotorg.org wrote: On 05/13/2015 07:56 AM, Simon Glass wrote: Hi Stephen, On 25 February 2015 at 16:31, Stephen Warren swar...@wwwdotorg.org wrote: On 02/17/2015 03:29 PM, Simon Glass wrote: We need to match the device tree in the FIT with the U-Boot model so we can automatically select the right device tree. Also adjust the load address so that the device tree is not in the way when a zImage kernel tries to extract itself. We don't tend to use LOADADDR in any of the default boot scripts any more. Rather, we explicitly load files to a semantic location indicated by one of the following variables in tegra124-common.h: #define MEM_LAYOUT_ENV_SETTINGS \ scriptaddr=0x9000\0 \ pxefile_addr_r=0x9010\0 \ kernel_addr_r=0x8100\0 \ fdt_addr_r=0x8200\0 \ ramdisk_addr_r=0x8210\0 Perhaps the ChromeOS boot scripts could be adjusted to use one/some of those variables? If the value of CONFIG_LOADADDR isn't appropriate, perhaps we should fix it for all Tegra SoCs/boards? I forgot about this comment sorry. I had problems with the image overwriting itself. It is a bzImage inside a FIT so doesn't use the proper FIT decompression. Anyway I'd like to clarify what is meant by kernel_addr_r. Is that where the FIT is loaded or where the kernel will decompress to, or something else? kernel_addr_r is the address in RAM at which a kernel zImage is loaded by config_distro_bootcmd.h scripts (and likely other scripts too). It's usually deliberately chosen to be a fair way into RAM, so that when the zImage decompresses (to approx the start of RAM), the decompressed image doesn't overlap the compressed image at kernel_addr_r. This avoids the kernel decompressor having to move/copy the zImage somewhere else before copying to avoid any overlap during decompression. config_distro_bootcmd.h doesn't support FIT, so I haven't tried out loading FIT images. That said, if U-Boot simply jumps to the location of the kernel in the FIT image itself without any copying, I would expect everything to work fine if you loaded a FIT image to kernel_addr_r. However, if the processing of the FIT image requires the kernel to be copied out of the FIT image to some other location, you'd have to carefully choose that location so it didn't overlap anything. I'd strongly recommend avoiding any unnecessary copies like that though, if at all possible, from the perspective of both pointlessly wasted execution time and simplicity of the boot process. Perhaps storing a a kernel_noload image type inside the FIT rather than a kernel image type might help there? Perhaps you want to introduce a new standard variable that defines where FIT images are loaded. I wonder what would be involved in adjusting config_distro_bootcmd to support FIT? Well, it goes against the very idea of config_distro_bootcmd, which is to provide a single standard mechanism that doesn't rely on any bootloader-specific file formats etc. That mechanism is a raw zImage, a raw initrd, and a plain text extlinux.cfg file to specify things like file paths/names, command-line, etc. The boot.scr support there is legacy, and not something that should be built upon going forward. So, that's not an argument for adding support for a third mechanism! Do we need to adjust the mechanism? The only difference I see is that FIT brings the files together. Would it make it simpler or harder? To me, we should be moving to using FIT with U-Boot as it is much more flexible and better designed from the ground up to provide the required features. I disagree that FIT is a good idea, but that's a separate topic. Anyway, normally FIT has a compressed kernel (e.g. with LZO), not a bzImage. Do you mean FIT normally contains an originally uncompressed kernel (i.e. an Image file in ARM land at least), but then compresses it itself as part of FIT image generation? A bzImage is also a compressed kernel. That's right, that's what I mean. So it seems like we need an additional decompression address. I suppose we could always use malloc() instead... But perhaps a FIT load address makes sense. But then we don't really need a kernel load address do we? Shouldn't that be specified in the FIT itself? A FIT load address does sound like it makes sense. If U-Boot copies the kernel image out of the FIT image to somewhere else, the FIT image shouldn't specify the address to copy it to. This varies per SoC, so if this address is hard-coded into FIT, it means the FIT image can't be used on different SoCs (or perhaps even different boards, depending on how differing RAM sizes work on various HW). This is why with config_distro_bootcmd, all the addresses come
Re: [U-Boot] fdt: Pass the board serial number through devicetree
Hi, On 05/19/2015 06:57 PM, Paul Kocialkowski wrote: Le mardi 19 mai 2015 à 18:37 +0200, Hans de Goede a écrit : Hi Simon, About: https://patchwork.ozlabs.org/patch/455720/ AFAIK on the kernel side all the relevant patches (including devicetree binding documentation binding) have been queued up for 4.2, so this ready to be merged now. Paul, can you confirm this ? Correct, the two patches adding support for this in Linux have been accepted by Russell King: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8354/1 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8355/1 I didn't resend the patch in U-Boot yet (along with the use of ATAGs for sunxi) but if you're willing to accept it while the change has not yet landed in Linus' tree, I could wrap a new version soon. No need to resend the sunxi patch, I've already queued it up for merging. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] tools: get-toolchais: a tool to get cross-tools for all architectures
Hi Joe, On 19 May 2015 at 12:13, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Simon, On Tue, May 19, 2015 at 12:16 PM, Simon Glass s...@chromium.org wrote: Hi Masahiro, On 18 May 2015 at 23:04, Masahiro Yamada yamada.masah...@socionext.com wrote: Hi Simon, 2015-05-18 2:50 GMT+09:00 Simon Glass s...@chromium.org: Hi Masahiro, On 15 May 2015 at 22:58, Masahiro Yamada yamada.masah...@socionext.com wrote: Hi Joe, (added Simon) 2015-05-16 4:52 GMT+09:00 Joe Hershberger joe.hershber...@gmail.com: Hi Masahiro-san, On Fri, May 15, 2015 at 6:01 AM, Masahiro Yamada yamada.masah...@socionext.com wrote: 8 snip 8 This tool intends to be more generic design without hard-coding such kernel.org things. To achieve that, this tool consists of two files: Python script (this file) and the database file containing URLs of tarballs. We just need to update the latter when new version compilers are released (or better compilers are found.) The file is in the form of RFC 822 for easier editing. Any reason not to just maintain this list on the wiki. It seem this is the primary issue for everyone... not figuring out how to download or extract the toolchain. I can just note URLs down in README or wiki. Of course, everyone knows how to download a tarball and extract it, but isn't it more convenient to prepare a utility that can do everything for you? The script only uses Python libraries, not relies on external programs although it displays wget-like log when downloading tarballs. :-) It seems like using wget would be more appropriate. Why reinvent the wheel? My intention was to not depend on particular external programs like wget, curl. But, you are right, we should not reinvent the wheel. I will replace my implementation with a caller of wget. I think urllib2 is a better solution. Now I understand we must depend on tar anyway. So my first intention no external program dependency seems impossible (at least on Python 2). I do not mind depending on wget, and it seems easier. Is wget always installed? Maybe urllib is better just in case. In my case I do some work on an old distro and on that machine I have wget, but not python 3. 8 snip 8 One option there might be Python 2 and urllib2 like buildman? In general it is nice to support older platforms if we can as it reduces friction. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 08/10] moveconfig: Print a message for missing compiler
Hi Masahiro-san,
On Mon, May 18, 2015 at 10:23 PM, Masahiro Yamada
yamada.masah...@socionext.com wrote:
2015-05-16 6:40 GMT+09:00 Joe Hershberger joe.hershber...@ni.com:
A common case for failed builds is a missing compiler. Print a message
for that case to tell the user concisely which compiler was expected
that was not found.
This patch also has the effect of not printing build errors any longer.
The next patch will add a switch to optionally bring that back.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
tools/moveconfig.py | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index 9e923da..f986f55 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -166,6 +166,7 @@ import os
import re
import shutil
import subprocess
+from subprocess import PIPE
Personally I do not prefer from ... import
because it disturbs the naming space.
Could you use subprocess.PIPE instead?
OK.
import sys
import tempfile
import time
@@ -606,11 +607,14 @@ class Slot:
return False
if self.ps.poll() != 0:
-
+errmsg = 'Failed to process.'
+errout = self.ps.stderr.read()
This throws exception if make *_defconfig or make savedefconfig fail.
Traceback (most recent call last):
File tools/moveconfig.py, line 924, in module
main()
File tools/moveconfig.py, line 919, in main
move_config(config_attrs, options)
File tools/moveconfig.py, line 794, in move_config
while not slots.available():
File tools/moveconfig.py, line 717, in available
if slot.poll():
File tools/moveconfig.py, line 616, in poll
errout = self.ps.stderr.read()
AttributeError: 'NoneType' object has no attribute 'read'
Seems better to add PIPE for all the call of subprocess.Popen()
OK
+if errout.find('gcc: command not found') != -1:
+errmsg = 'Compiler not found (%s)' % self.cross_compile
If you do this, should the locale be changed?
Without LANG=C, command not found is displayed in Japanese on my computer.
If --verbose is given, we will be able to know the cause of erorr.
missing compiler is a special case error?
That's true, but at least for my use-case before I spent several days
getting all tool-chains working, it was nice to know what the build
was trying to use for a cross tool-chain in a concise one-liner
instead of parsing a bunch of error prints. That's part of why I added
the -v flag. It's also helpful (naturally) in getting the compilers
all working.
print sys.stderr, log_msg(self.options.color,
COLOR_LIGHT_RED,
self.defconfig,
- failed to process.)
+ errmsg),
if self.options.exit_on_error:
sys.exit(Exit on error.)
else:
@@ -644,13 +648,13 @@ class Slot:
self.state = STATE_IDLE
return True
-cross_compile = self.parser.get_cross_compile()
+self.cross_compile = self.parser.get_cross_compile()
cmd = list(self.make_cmd)
-if cross_compile:
-cmd.append('CROSS_COMPILE=%s' % cross_compile)
+if self.cross_compile:
+cmd.append('CROSS_COMPILE=%s' % self.cross_compile)
cmd.append('KCONFIG_IGNORE_DUPLICATES=1')
cmd.append('include/config/auto.conf')
-self.ps = subprocess.Popen(cmd, stdout=self.devnull)
+self.ps = subprocess.Popen(cmd, stdout=self.devnull, stderr=PIPE)
self.state = STATE_AUTOCONF
return False
--
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 09/10] moveconfig: Add a switch to enable printing errors
Hi Masahiro-san,
On Mon, May 18, 2015 at 10:25 PM, Masahiro Yamada
yamada.masah...@socionext.com wrote:
2015-05-16 6:40 GMT+09:00 Joe Hershberger joe.hershber...@ni.com:
In some cases the build for the autoconf breaks. This outputs the errors
following the status so that action can be taken without building again
manually.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v4: None
Changes in v3: None
Changes in v2:
-New for version 2
tools/moveconfig.py | 9 +
1 file changed, 9 insertions(+)
diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index f986f55..685b47b 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -153,6 +153,9 @@ Available options
Specify the number of threads to run simultaneously. If not specified,
the number of threads is the same as the number of CPU cores.
+ -v, --verbose
+ Show any build errors as boards are built
+
To see the complete list of supported options, run
$ tools/moveconfig.py -h
@@ -615,6 +618,9 @@ class Slot:
COLOR_LIGHT_RED,
self.defconfig,
errmsg),
+if self.options.verbose:
+print sys.stderr, color_text(self.options.color,
+COLOR_LIGHT_CYAN, errout)
if self.options.exit_on_error:
sys.exit(Exit on error.)
else:
@@ -882,6 +888,9 @@ def main():
help='only cleanup the headers')
parser.add_option('-j', '--jobs', type='int', default=cpu_count,
help='the number of jobs to run simultaneously')
+parser.add_option('-v', '--verbose', dest='verbose',
+ action='store_true', default=False,
+ help='show any build errors as boards are built')
dest='verbose' is redundant.
The destination is chosen based on the long option name.
OK. Dropped.
Apart from that, I think this is a nice improvement.
--
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] usb: kbd: Fix key repeat not always using
On Wednesday, May 13, 2015 at 02:47:51 PM, Hans de Goede wrote: The usb-kbd key repeat code assumes that reports get repeated every 40 ms, this is never true when using CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP, and does not always works for CONFIG_SYS_USB_EVENT_POLL and CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE since not all usb keyboards honor the usb_set_idle() command. For CONFIG_SYS_USB_EVENT_POLL we must use usb_set_idle() since we do a blocking wait for the hid report, so if we do not tell the keyboard to send a hid report every 40ms even if nothing changes then we will block u-boot for 1s (the default u-boot usb interrupt packet timeout). Note that in this case on keyboards which do not support usb_set_idle() we loose and we actually get 1s latencies on other u-boot activities. For the other poll-methods this commit stops using usb_set_idle() and instead repeats the last received hid-report every 40 ms as long as no new hid-report is received. This fixes key-repeat not working at all with CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP and fixes it not working with keyboards which do not implement usb_set_idle() when using CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE. Signed-off-by: Hans de Goede hdego...@redhat.com Hi, this broke a couple of machines, quoting Tom. I'm dropping it for now. NAK. This introduces various breakage: 12: Merge branch 'master' of git://git.denx.de/u-boot-usb arm: + VCMA9 beagle_x15 at91rm9200ek_ram peach-pi snow smdk5250 am43xx_evm dr a7xx_evm_uart3 k2l_evm am43xx_evm_qspiboot smdk5420 dra7xx_evm smdk2410 at91rm9200ek dr a7xx_evm_qspiboot k2hk_evm k2e_evm peach-pit powerpc: + PIP405 MIP405 The powerpc board breakage is the same as some of the ARM ones so fix it once and they'll come along. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
Updated PR, dropped the patch from Hans and picked the OHCI cache patch instead: The following changes since commit 0e6b7a28243175ae0874d53b6e6e4eff8548d71f: Merge git://git.denx.de/u-boot-samsung (2015-05-18 09:15:15 -0400) are available in the git repository at: git://git.denx.de/u-boot-usb.git HEAD for you to fetch changes up to d07e7c0b5bd9dc0044eafc730131d32539608303: usb: ohci: enable cache support (2015-05-19 19:57:30 +0200) Hans de Goede (1): usb: Remove unused variable in usb_setup_descriptor() Josh Wu (1): usb: ohci: enable cache support Peter Griffin (1): usb: dwc2: Add support for v3 snpsid value Ramneek Mehresh (5): drivers:usb:dwc3: Add DWC3 controller driver support drivers:usb:fsl: Add XHCI driver support arch:arm:fsl: Add XHCI support for LS1021A include:configs:ls1021atwr: Enable USB IP support include:configs:ls1021aqds: Enable USB IP support Siva Durga Prasad Paladugu (1): ci_udc: Update the ci_udc driver to support bulk transfers arch/arm/include/asm/arch-ls102xa/config.h| 1 + arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 10 +++ common/usb.c | 2 -- drivers/usb/gadget/ci_udc.c | 135 +++- drivers/usb/gadget/ci_udc.h | 1 + drivers/usb/host/Makefile | 2 ++ drivers/usb/host/dwc2.c | 3 +- drivers/usb/host/dwc2.h | 1 + drivers/usb/host/ohci-hcd.c | 10 +-- drivers/usb/host/ohci.h | 2 +- drivers/usb/host/xhci-dwc3.c | 74 drivers/usb/host/xhci-fsl.c | 109 +++ include/configs/ls1021aqds.h | 22 +++ include/configs/ls1021atwr.h | 38 + include/linux/usb/dwc3.h | 4 +++ include/linux/usb/xhci-fsl.h | 54 +++ 16 files changed, 431 insertions(+), 37 deletions(-) create mode 100644 drivers/usb/host/xhci-dwc3.c create mode 100644 drivers/usb/host/xhci-fsl.c create mode 100644 include/linux/usb/xhci-fsl.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ohci: enable cache support
On Tuesday, May 19, 2015 at 12:44:24 PM, Josh Wu wrote: Remove the CONFIG_DM_USB limitation to enable cache support functions. Tested on SAMA5D3x-EK board. Signed-off-by: Josh Wu josh...@atmel.com Applied, thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 03/10] moveconfig: Add a parameter to accept a list to build
Hi Masahiro-san,
On Mon, May 18, 2015 at 11:33 PM, Masahiro Yamada
yamada.masah...@socionext.com wrote:
2015-05-16 6:40 GMT+09:00 Joe Hershberger joe.hershber...@ni.com:
This is helpful to re-attempt to move failed boards from a previous run
without starting over.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v4: None
Changes in v3:
-Fixed command line options order (alphabetize)
Changes in v2:
-New for version 2
tools/moveconfig.py | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index d3009de..3f31e81 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -135,6 +135,9 @@ Available options
Surround each portion of the log with escape sequences to display it
in color on the terminal.
+ -d, --defconfigs
+ Specify a file containing a list of defconfigs to move
+
-n, --dry-run
Peform a trial run that does not make any changes. It is useful to
see what is going to happen before one actually runs it.
@@ -734,12 +737,21 @@ def move_config(config_attrs, options):
config_attr['type'],
config_attr['default'])
-# All the defconfig files to be processed
-defconfigs = []
-for (dirpath, dirnames, filenames) in os.walk('configs'):
-dirpath = dirpath[len('configs') + 1:]
-for filename in fnmatch.filter(filenames, '*_defconfig'):
-defconfigs.append(os.path.join(dirpath, filename))
+if options.defconfigs:
+defconfigs = [line.strip() for line in open(options.defconfigs,
'r')]
+for i, defconfig in enumerate(defconfigs):
+if not defconfig.endswith('_defconfig'):
+defconfigs[i] = defconfig + '_defconfig'
+if not os.path.exists(os.path.join('configs', defconfigs[i])):
+sys.exit('%s - defconfig does not exist. Stopping.' %
+ defconfigs[i])
'r' is redundant for open() because read-mode is default.
OK.
moveconfig.failed always prefixes _defconfig,
so we need not to do so again, I think. (or will we make this file by hand?)
I have done both moveconfig.failed as well as a hand-written file for
testing certain boards. That's why I added both the append
'_defconfig' as well as the check for it actually existing.
Then, we can drop enumarate and write the error message within 80 columns.
if options.defconfigs:
defconfigs = [line.strip() for line in open(options.defconfigs)]
for defconfig in defconfigs:
if not os.path.exists(os.path.join('configs', defconfig)):
sys.exit('%s: defconfig does not exist. Stopping.' %
defconfig)
I think we should keep the check for endswith('_defconfig').
slots = Slots(config_attrs, options)
@@ -840,6 +852,8 @@ def main():
# Add options here
parser.add_option('-c', '--color', action='store_true', default=False,
help='display the log in color')
+parser.add_option('-d', '--defconfigs', type='string',
+ help='a file containing a list of defconfigs to move')
parser.add_option('-n', '--dry-run', action='store_true', default=False,
help='perform a trial run (show log with no changes)')
parser.add_option('-e', '--exit-on-error', action='store_true',
Cheers,
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 01/10] moveconfig: Always run savedefconfig on the moved config
Hi Masahiro-san, On Mon, May 18, 2015 at 8:58 PM, Masahiro Yamada yamada.masah...@socionext.com wrote: Hi Joe, 2015-05-16 6:40 GMT+09:00 Joe Hershberger joe.hershber...@ni.com: This will ensure that the order of the defconfig entries will always match that of the Kconfig files. After one slightly painful (but still early in the process) pass over all boards, this should keep the defconfigs clean from here on. Users must edit the Kconfig first to add the menu entries and then run moveconfig.py to update the defconfig files and the include configs. As such, moveconfig.py cannot compare against the '.config' contents. Signed-off-by: Joe Hershberger joe.hershber...@ni.com This feature expects the defconfigs are all clean. Otherwise, savedefconfig would make git diff noisier. It is safer to use make menuconfig make savedefconfig for adding new options, but some people still try to edit the defconfig directly... Perhaps, should do the global cleanup periodically? I agree that until people (both contributors and custodians) get used to this as the best way, we will likely need a few global clean-ups, but I think with the addition of this tool to main-line the instance of this will likely drop sharply. Moving configs is a hassle, so with a tool available I doubt many people will do it manually. That's why it is important that the tool do it the cleanest way. Hopefully for the case where a config is changed on a board, the custodian will notice if it is just added to the bottom of the file. It seems to work out for Linux. Cheers, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] tools: get-toolchais: a tool to get cross-tools for all architectures
Hi Simon, On Tue, May 19, 2015 at 12:16 PM, Simon Glass s...@chromium.org wrote: Hi Masahiro, On 18 May 2015 at 23:04, Masahiro Yamada yamada.masah...@socionext.com wrote: Hi Simon, 2015-05-18 2:50 GMT+09:00 Simon Glass s...@chromium.org: Hi Masahiro, On 15 May 2015 at 22:58, Masahiro Yamada yamada.masah...@socionext.com wrote: Hi Joe, (added Simon) 2015-05-16 4:52 GMT+09:00 Joe Hershberger joe.hershber...@gmail.com: Hi Masahiro-san, On Fri, May 15, 2015 at 6:01 AM, Masahiro Yamada yamada.masah...@socionext.com wrote: 8 snip 8 This tool intends to be more generic design without hard-coding such kernel.org things. To achieve that, this tool consists of two files: Python script (this file) and the database file containing URLs of tarballs. We just need to update the latter when new version compilers are released (or better compilers are found.) The file is in the form of RFC 822 for easier editing. Any reason not to just maintain this list on the wiki. It seem this is the primary issue for everyone... not figuring out how to download or extract the toolchain. I can just note URLs down in README or wiki. Of course, everyone knows how to download a tarball and extract it, but isn't it more convenient to prepare a utility that can do everything for you? The script only uses Python libraries, not relies on external programs although it displays wget-like log when downloading tarballs. :-) It seems like using wget would be more appropriate. Why reinvent the wheel? My intention was to not depend on particular external programs like wget, curl. But, you are right, we should not reinvent the wheel. I will replace my implementation with a caller of wget. I think urllib2 is a better solution. Now I understand we must depend on tar anyway. So my first intention no external program dependency seems impossible (at least on Python 2). I do not mind depending on wget, and it seems easier. Is wget always installed? Maybe urllib is better just in case. In my case I do some work on an old distro and on that machine I have wget, but not python 3. 8 snip 8 Cheers -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 11/13] test: dm: test.dts - move to sandbox dts directory
Hi Simon, On Fri, May 15, 2015 at 8:56 AM, Simon Glass s...@chromium.org wrote: On 13 May 2015 at 05:38, Przemyslaw Marczak p.marc...@samsung.com wrote: The file test.dts from driver model test directory, was compiled by call dtc in script: test/dm/test-dm.sh. This doesn't allow for including of dtsi files and using of C preprocessor routines in this dts file. Since the mentioned script builds U-Boot before tests, then moving the test.dts file into sandbox dts directory is reasonable. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Acked-by: Simon Glass s...@chromium.org Tested on sandbox: Tested-by: Simon Glass s...@chromium.org --- Changes V2: - new commit --- arch/sandbox/dts/Makefile | 1 + arch/sandbox/dts/test.dts | 230 ++ test/dm/.gitignore| 1 - test/dm/test-dm.sh| 3 +- test/dm/test-main.c | 3 +- test/dm/test.dts | 230 -- 6 files changed, 233 insertions(+), 235 deletions(-) create mode 100644 arch/sandbox/dts/test.dts delete mode 100644 test/dm/.gitignore delete mode 100644 test/dm/test.dts Applied to u-boot-dm, thanks! This patch effectively reverted fbe07ba0f: dm: test: dts: Sort the aliases in the test device tree file It seems this file was moved before other patches went in and never updated. Maybe there are other merge-conflict resolution errors? Cheers, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 11/13] test: dm: test.dts - move to sandbox dts directory
Hi Simon, On Tue, May 19, 2015 at 2:21 PM, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Simon, On Fri, May 15, 2015 at 8:56 AM, Simon Glass s...@chromium.org wrote: On 13 May 2015 at 05:38, Przemyslaw Marczak p.marc...@samsung.com wrote: The file test.dts from driver model test directory, was compiled by call dtc in script: test/dm/test-dm.sh. This doesn't allow for including of dtsi files and using of C preprocessor routines in this dts file. Since the mentioned script builds U-Boot before tests, then moving the test.dts file into sandbox dts directory is reasonable. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Acked-by: Simon Glass s...@chromium.org Tested on sandbox: Tested-by: Simon Glass s...@chromium.org --- Changes V2: - new commit --- arch/sandbox/dts/Makefile | 1 + arch/sandbox/dts/test.dts | 230 ++ test/dm/.gitignore| 1 - test/dm/test-dm.sh| 3 +- test/dm/test-main.c | 3 +- test/dm/test.dts | 230 -- 6 files changed, 233 insertions(+), 235 deletions(-) create mode 100644 arch/sandbox/dts/test.dts delete mode 100644 test/dm/.gitignore delete mode 100644 test/dm/test.dts Applied to u-boot-dm, thanks! This patch effectively reverted fbe07ba0f: dm: test: dts: Sort the aliases in the test device tree file It seems this file was moved before other patches went in and never updated. Maybe there are other merge-conflict resolution errors? Ah yes... it also reverted 4772511: dm: rtc: Add tests for real-time clocks Cheers, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
