Re: [U-Boot] [Patch v3 0/4] imx: mx6: use OTP for teperature grade info

2015-05-19 Thread Stefano Babic
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 
> 

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

2015-05-19 Thread Stefano Babic
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 
>> ---
>>  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 
>>  #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 
> 

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 

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] usb: ohci: enable cache support

2015-05-19 Thread Hans de Goede

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 


Looks good to me:

Acked-by: Hans de Goede 

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

2015-05-19 Thread Josh Wu
Remove the CONFIG_DM_USB limitation to enable cache support functions.
Tested on SAMA5D3x-EK board.

Signed-off-by: Josh Wu 
---

 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

2015-05-19 Thread Marek Vasut
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

2015-05-19 Thread Josh Wu
From: Bo Shen 

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 
[rebase to mainline]
Signed-off-by: Josh Wu 
---

 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] [PATCH] ARM: atmel: switch to usb ehci for sama5d3 boards

2015-05-19 Thread Hans de Goede

Hi,

On 19-05-15 12:54, Josh Wu wrote:

From: Bo Shen 

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 
[rebase to mainline]
Signed-off-by: Josh Wu 


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

2015-05-19 Thread Josh Wu

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 

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 
[rebase to mainline]
Signed-off-by: Josh Wu 


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_NAME"SAMA5D3 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_NAME"sama5d3"
-#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 0/10 v2] i.MX6: move duplicated options to mx6_common to standardise mx6 config

2015-05-19 Thread Stefano Babic
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 
> 

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 v2] sunxi: Make dram odt-en configurable through Kconfig for A33 based boards

2015-05-19 Thread Hans de Goede

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

2015-05-19 Thread Hans de Goede
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 
---
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 
 #include 
 #include 
+#include 
 
 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 
 #include 
 #include 
+#include 
 
 /* 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 << 0);
 
/* Set ODT */
-   if ((CONFIG_DRAM_CLK > 400) && DRAM_ODT_EN) {
+   if ((CONFIG_DRAM

Re: [U-Boot] [PATCH] env_nand: use nand_spl_load_image for readenv if SPL

2015-05-19 Thread Stefano Babic
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 
>> ---
>>  common/env_nand.c | 7 +++
>>  1 file changed, 7 insertions(+)
> 
> Acked-by: Scott Wood 
> 

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

2015-05-19 Thread Stefano Babic


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 
> ---
> v2: remove unnecessary CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR define
> 
> Signed-off-by: Tim Harvey 
> ---
>  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 v2 17/19] imx: ventana: add pmic_setup to SPL

2015-05-19 Thread Stefano Babic


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 
> ---
> 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

2015-05-19 Thread Stefano Babic


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 
> ---

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] hummingboard: Remove unused directory

2015-05-19 Thread Stefano Babic


On 15/05/2015 21:10, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> 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 
> ---
>  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 1/3] imx: riotboard, marsboard: Enable thermal support

2015-05-19 Thread Stefano Babic


On 18/05/2015 01:10, Nikolay Dimitrov wrote:
> Signed-off-by: Nikolay Dimitrov 
> ---
>  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 2/3] imx: riotboard: Enable thermal DM support

2015-05-19 Thread Stefano Babic


On 18/05/2015 01:10, Nikolay Dimitrov wrote:
> Signed-off-by: Nikolay Dimitrov 
> ---
>  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

2015-05-19 Thread Stefano Babic


On 18/05/2015 01:10, Nikolay Dimitrov wrote:
> Signed-off-by: Nikolay Dimitrov 
> ---
>  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] imx: mx6sx enable SION for i2c pin mux

2015-05-19 Thread Stefano Babic
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 
> ---

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

2015-05-19 Thread Stefano Babic


On 18/05/2015 07:37, Peng Fan wrote:
> Change PUZE_100_SW1ABCONF to PFUZE100_SW1ABCONF
> 
> Signed-off-by: Peng Fan 
> ---


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

2015-05-19 Thread Stefano Babic


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 
> ---


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

2015-05-19 Thread Stefano Babic


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 
> ---

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

2015-05-19 Thread Tim Harvey
On Mon, May 18, 2015 at 4:25 PM, Fabio Estevam  wrote:
> Hi Tim,
>
> On Fri, May 8, 2015 at 10:28 PM, Tim Harvey  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 19/19] imx: ventana: config: enable Falcon mode

2015-05-19 Thread Fabio Estevam
Hi Tim,

On Tue, May 19, 2015 at 10:26 AM, Tim Harvey  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

2015-05-19 Thread Ian Campbell
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 v4 05/10] moveconfig: Cleanup headers in arch and board

2015-05-19 Thread Joe Hershberger
On Mon, May 18, 2015 at 8:41 PM, Masahiro Yamada
 wrote:
> Hi Joe,
>
>
> 2015-05-16 6:40 GMT+09:00 Joe Hershberger :
>> 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 
>>
>> ---
>>
>> 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 v3] sunxi: Make DRAM_ODT_EN Kconfig setting a bool

2015-05-19 Thread Siarhei Siamashka
On Tue, 19 May 2015 14:56:39 +0200
Hans de Goede  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 

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 

-- 
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 v3] sunxi: Make DRAM_ODT_EN Kconfig setting a bool

2015-05-19 Thread Siarhei Siamashka
On Tue, 19 May 2015 15:13:18 +0100
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).

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] [RFC PATCH] tools: get-toolchais: a tool to get cross-tools for all architectures

2015-05-19 Thread Joe Hershberger
On Fri, May 15, 2015 at 6:01 AM, Masahiro Yamada
 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 
> ---

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 v2] tools: moveconfig: a tool to move CONFIGs from headers to defconfigs

2015-05-19 Thread Joe Hershberger
Hi Masahiro-san

On Thu, May 14, 2015 at 11:44 PM, Masahiro Yamada
 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 
> Signed-off-by: Joe Hershberger 
> ---
>
> 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 
> +#
> +# 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:
> +  
> +(the fields must be separated with whitespaces.)
> +
> + is the name of config option.
> +
> + is the type of the option.  It must be one of bool, tristate,
> +string, int, and hex.
> +
> + 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
> +   :  
> +
> + is the name of the defconfig
> +(without the suffix _defconfig).
> +
> + 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

Re: [U-Boot] [PATCH v4 01/10] moveconfig: Always run savedefconfig on the moved config

2015-05-19 Thread Joe Hershberger
Hi Masahiro-san,

On Mon, May 18, 2015 at 8:58 PM, Masahiro Yamada
 wrote:
> Hi Joe,
>
> 2015-05-16 6:40 GMT+09:00 Joe Hershberger :
>> 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 
>
>
> 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 =

Re: [U-Boot] [PATCH v4 04/10] moveconfig: Add a switch to only cleanup headers

2015-05-19 Thread Joe Hershberger
Hi Masahiro-san,

On Mon, May 18, 2015 at 9:03 PM, Masahiro Yamada
 wrote:
> Hi Joe,
>
> 2015-05-16 6:40 GMT+09:00 Joe Hershberger :
>> 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 
>>
>> ---
>>
>> 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 06/10] moveconfig: Remove probable debug print

2015-05-19 Thread Joe Hershberger
Hi Masahiro-san,

On Mon, May 18, 2015 at 9:10 PM, Masahiro Yamada
 wrote:
> Hi Joe
>
> 2015-05-16 6:40 GMT+09:00 Joe Hershberger :
>> This print seems to be redundant and unformatted compared to the next
>> few lines, so remove it.
>>
>> Signed-off-by: Joe Hershberger 
>> ---
>>
>> 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 
>
>
> (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 07/10] moveconfig: Output a list of failed boards

2015-05-19 Thread Joe Hershberger
Hi Masahiro-san,

On Mon, May 18, 2015 at 10:12 PM, Masahiro Yamada
 wrote:
> 2015-05-16 6:40 GMT+09:00 Joe Hershberger :
>> 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 
>> ---
>>
>> 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] [PATCH 20/20] tegra: config: nyan-big: Add options required by Chrome OS boot

2015-05-19 Thread Stephen Warren

On 05/18/2015 03:33 PM, Simon Glass wrote:

Hi Stephen,

On 15 May 2015 at 09:34, Stephen Warren  wrote:

On 05/13/2015 07:56 AM, Simon Glass wrote:


Hi Stephen,

On 25 February 2015 at 16:31, Stephen Warren 
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?

___
U-Boot ma

Re: [U-Boot] fdt: Pass the board serial number through devicetree

2015-05-19 Thread Hans de Goede

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 v3] sunxi: Make DRAM_ODT_EN Kconfig setting a bool

2015-05-19 Thread Hans de Goede

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] arm: imx: Switch Wandboard to use config_distro_bootcmd.h.

2015-05-19 Thread XoD
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 :

> 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 
> > > Signed-off-by: Vagrant Cascadian 
> > > ---
> > >
> > >  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 v3] sunxi: Make DRAM_ODT_EN Kconfig setting a bool

2015-05-19 Thread Hans de Goede

Hi,

On 05/19/2015 04:54 PM, Siarhei Siamashka wrote:

On Tue, 19 May 2015 14:56:39 +0200
Hans de Goede  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 


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] [PATCH 1/2] sunxi: VBUS detection function fixup in g_dnl_board_usb_cable_connected

2015-05-19 Thread Hans de Goede

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 
---
  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


Re: [U-Boot] fdt: Pass the board serial number through devicetree

2015-05-19 Thread Paul Kocialkowski
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 3/3] e1000: remove unnecessary clearing of SWSM.SWSM_SMBI

2015-05-19 Thread Tim Harvey
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 
Cc: Marek Vasut 
Cc: Aneesh Bansal 
Cc: Naveen Burmi 
Cc: Po Liu 
Cc: Bin Meng 
Cc: Alison Wang 
Cc: Reinhard Arlt 
Cc: Shengzhou Liu  
Cc: York Sun 
Signed-off-by: Tim Harvey 
---
 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


[U-Boot] [Patch 1/3] e1000: releasing semaphore once no longer needed

2015-05-19 Thread Tim Harvey
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 
Cc: Marek Vasut 
Cc: Aneesh Bansal 
Cc: Naveen Burmi 
Cc: Po Liu 
Cc: Bin Meng 
Cc: Alison Wang 
Cc: Reinhard Arlt 
Cc: Shengzhou Liu  
Cc: York Sun 
Signed-off-by: Tim Harvey 
---
 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"

2015-05-19 Thread Tim Harvey
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 
Cc: Marek Vasut 
Cc: Aneesh Bansal 
Cc: Naveen Burmi 
Cc: Po Liu 
Cc: Bin Meng 
Cc: Alison Wang 
Cc: Reinhard Arlt 
Cc: Shengzhou Liu  
Cc: York Sun 
Signed-off-by: Tim Harvey 
---
 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

2015-05-19 Thread Tim Harvey
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 
Cc: Marek Vasut 
Cc: Aneesh Bansal 
Cc: Naveen Burmi 
Cc: Po Liu 
Cc: Bin Meng 
Cc: Alison Wang 
Cc: Reinhard Arlt 
Cc: Shengzhou Liu  
Cc: York Sun 
Signed-off-by: Tim Harvey 

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

2015-05-19 Thread Simon Glass
Hi Paul,

On 19 May 2015 at 10:57, 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.

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


Re: [U-Boot] [RFC PATCH] tools: get-toolchais: a tool to get cross-tools for all architectures

2015-05-19 Thread Simon Glass
Hi Masahiro,

On 18 May 2015 at 23:04, Masahiro Yamada  wrote:
> Hi Simon,
>
>
> 2015-05-18 2:50 GMT+09:00 Simon Glass :
>> Hi Masahiro,
>>
>> On 15 May 2015 at 22:58, Masahiro Yamada 
>> wrote:
>>> Hi Joe,
>>> (added Simon)
>>>
>>> 2015-05-16 4:52 GMT+09:00 Joe Hershberger :
 Hi Masahiro-san,

 On Fri, May 15, 2015 at 6:01 AM, Masahiro Yamada
  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

Re: [U-Boot] [PULL] u-boot-usb/master

2015-05-19 Thread Tom Rini
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 v4 08/10] moveconfig: Print a message for missing compiler

2015-05-19 Thread Joe Hershberger
Hi Masahiro-san,

On Mon, May 18, 2015 at 10:23 PM, Masahiro Yamada
 wrote:
> 2015-05-16 6:40 GMT+09:00 Joe Hershberger :
>> 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 
>> ---
>>
>> 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 
> 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

2015-05-19 Thread Joe Hershberger
Hi Masahiro-san,

On Mon, May 18, 2015 at 10:25 PM, Masahiro Yamada
 wrote:
> 2015-05-16 6:40 GMT+09:00 Joe Hershberger :
>> 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 
>>
>> ---
>>
>> 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

2015-05-19 Thread Marek Vasut
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 

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

2015-05-19 Thread Marek Vasut
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

2015-05-19 Thread Marek Vasut
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 

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

2015-05-19 Thread Joe Hershberger
Hi Masahiro-san,

On Mon, May 18, 2015 at 11:33 PM, Masahiro Yamada
 wrote:
> 2015-05-16 6:40 GMT+09:00 Joe Hershberger :
>> This is helpful to re-attempt to move failed boards from a previous run
>> without starting over.
>>
>> Signed-off-by: Joe Hershberger 
>>
>> ---
>>
>> 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 20/20] tegra: config: nyan-big: Add options required by Chrome OS boot

2015-05-19 Thread Simon Glass
Hi Stephen,

On 19 May 2015 at 09:41, Stephen Warren  wrote:
> On 05/18/2015 03:33 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 15 May 2015 at 09:34, Stephen Warren  wrote:
>>>
>>> On 05/13/2015 07:56 AM, Simon Glass wrote:


 Hi Stephen,

 On 25 February 2015 at 16:31, Stephen Warren 
 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 o

Re: [U-Boot] fdt: Pass the board serial number through devicetree

2015-05-19 Thread Hans de Goede

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] [PATCH v4 01/10] moveconfig: Always run savedefconfig on the moved config

2015-05-19 Thread Joe Hershberger
Hi Masahiro-san,

On Mon, May 18, 2015 at 8:58 PM, Masahiro Yamada
 wrote:
> Hi Joe,
>
> 2015-05-16 6:40 GMT+09:00 Joe Hershberger :
>> 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 
>
>
> 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

2015-05-19 Thread Joe Hershberger
Hi Simon,

On Tue, May 19, 2015 at 12:16 PM, Simon Glass  wrote:
> Hi Masahiro,
>
> On 18 May 2015 at 23:04, Masahiro Yamada  
> wrote:
>> Hi Simon,
>>
>>
>> 2015-05-18 2:50 GMT+09:00 Simon Glass :
>>> Hi Masahiro,
>>>
>>> On 15 May 2015 at 22:58, Masahiro Yamada 
>>> wrote:
 Hi Joe,
 (added Simon)

 2015-05-16 4:52 GMT+09:00 Joe Hershberger :
> Hi Masahiro-san,
>
> On Fri, May 15, 2015 at 6:01 AM, Masahiro Yamada
>  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] [RFC PATCH] tools: get-toolchais: a tool to get cross-tools for all architectures

2015-05-19 Thread Simon Glass
Hi Joe,

On 19 May 2015 at 12:13, Joe Hershberger  wrote:
>
> Hi Simon,
>
> On Tue, May 19, 2015 at 12:16 PM, Simon Glass  wrote:
> > Hi Masahiro,
> >
> > On 18 May 2015 at 23:04, Masahiro Yamada  
> > wrote:
> >> Hi Simon,
> >>
> >>
> >> 2015-05-18 2:50 GMT+09:00 Simon Glass :
> >>> Hi Masahiro,
> >>>
> >>> On 15 May 2015 at 22:58, Masahiro Yamada 
> >>> wrote:
>  Hi Joe,
>  (added Simon)
> 
>  2015-05-16 4:52 GMT+09:00 Joe Hershberger :
> > Hi Masahiro-san,
> >
> > On Fri, May 15, 2015 at 6:01 AM, Masahiro Yamada
> >  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


[U-Boot] [PATCH v5 1/9] moveconfig: Always run savedefconfig on the moved config

2015-05-19 Thread Joe Hershberger
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 
---
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 2/9] moveconfig: Ignore duplicate configs when moving

2015-05-19 Thread Joe Hershberger
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 
Acked-by: Masahiro Yamada 

---

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 5/9] moveconfig: Cleanup headers in arch and board

2015-05-19 Thread Joe Hershberger
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 

---

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 7/9] moveconfig: Print a message for missing compiler

2015-05-19 Thread Joe Hershberger
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 

---

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

2015-05-19 Thread Joe Hershberger
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 

---

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

2015-05-19 Thread Joe Hershberger
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 

---

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

2015-05-19 Thread Joe Hershberger
This gives a basic idea about progress.

Signed-off-by: Joe Hershberger 

---

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

2015-05-19 Thread Joe Hershberger
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 

---

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

2015-05-19 Thread Joe Hershberger
This is helpful to re-attempt to move failed boards from a previous run
without starting over.

Signed-off-by: Joe Hershberger 

---

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

2015-05-19 Thread Ian Campbell
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

2015-05-19 Thread Joe Hershberger
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 -
 include/configs/

Re: [U-Boot] [PATCH V2 11/13] test: dm: test.dts - move to sandbox dts directory

2015-05-19 Thread Joe Hershberger
Hi Simon,

On Fri, May 15, 2015 at 8:56 AM, Simon Glass  wrote:
> On 13 May 2015 at 05:38, Przemyslaw Marczak  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 
>> Acked-by: Simon Glass 
>> Tested on sandbox:
>> Tested-by: Simon Glass 
>> ---
>> 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

2015-05-19 Thread Joe Hershberger
Hi Simon,

On Tue, May 19, 2015 at 2:21 PM, Joe Hershberger
 wrote:
> Hi Simon,
>
> On Fri, May 15, 2015 at 8:56 AM, Simon Glass  wrote:
>> On 13 May 2015 at 05:38, Przemyslaw Marczak  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 
>>> Acked-by: Simon Glass 
>>> Tested on sandbox:
>>> Tested-by: Simon Glass 
>>> ---
>>> 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


Re: [U-Boot] [PATCH v6 1/4] mtd, spi: add MTD layer driver

2015-05-19 Thread Jagan Teki
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 , # 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  wrote:
> From: Daniel Schwierzeck 
>
> 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 
> Signed-off-by: Heiko Schocher 
>
> ---
>
> 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_registe

Re: [U-Boot] [PATCH 04/12] sunxi: Update sunxi-common.h to deal with different DRAM base addr on sun9i

2015-05-19 Thread Hans de Goede

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

2015-05-19 Thread Hans de Goede

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 v4 00/26] Improve env var handling for net stack

2015-05-19 Thread Joe Hershberger
Hi Tom,

On Thu, May 7, 2015 at 4:48 AM, Joe Hershberger  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


Re: [U-Boot] [PATCH] arm: imx: Switch Wandboard to use config_distro_bootcmd.h.

2015-05-19 Thread Vagrant Cascadian
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 :
>
>> 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 
>> > > Signed-off-by: Vagrant Cascadian 
>> > > ---
>> > >
>> > >  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


[U-Boot] [PATCH v4] usb: kbd: Fix key repeat not always working

2015-05-19 Thread Hans de Goede
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 
---
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 CONFIG_SYS_USB_E

Re: [U-Boot] [PATCH V2 11/13] test: dm: test.dts - move to sandbox dts directory

2015-05-19 Thread Simon Glass
Hi Joe,

On 19 May 2015 at 13:23, Joe Hershberger  wrote:
>
> Hi Simon,
>
> On Tue, May 19, 2015 at 2:21 PM, Joe Hershberger
>  wrote:
> > Hi Simon,
> >
> > On Fri, May 15, 2015 at 8:56 AM, Simon Glass  wrote:
> >> On 13 May 2015 at 05:38, Przemyslaw Marczak  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 
> >>> Acked-by: Simon Glass 
> >>> Tested on sandbox:
> >>> Tested-by: Simon Glass 
> >>> ---
> >>> 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

2015-05-19 Thread Stephen Warren

On 05/19/2015 12:01 PM, Simon Glass wrote:

Hi Stephen,

On 19 May 2015 at 09:41, Stephen Warren  wrote:

On 05/18/2015 03:33 PM, Simon Glass wrote:


Hi Stephen,

On 15 May 2015 at 09:34, Stephen Warren  wrote:


On 05/13/2015 07:56 AM, Simon Glass wrote:



Hi Stephen,

On 25 February 2015 at 16:31, Stephen Warren 
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 is hard-coded into FIT, it means the FIT image ca

Re: [U-Boot] Fix fsl_elbc_nand driver

2015-05-19 Thread Scott Wood
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 
> 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 
> ---
> 
>  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] u-boot compilation error for altera socfpga cyclon 5 if gpio included

2015-05-19 Thread Simon Glass
Hi,

On 12 May 2015 at 07:53, Altunbas Sabri (DC-IA/EAH2)
 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 
>^
> 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 20/20] tegra: config: nyan-big: Add options required by Chrome OS boot

2015-05-19 Thread Simon Glass
+Tom Rini in case he is interested...

Hi Stephen,

On 19 May 2015 at 15:36, Stephen Warren  wrote:
> On 05/19/2015 12:01 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 19 May 2015 at 09:41, Stephen Warren  wrote:
>>>
>>> On 05/18/2015 03:33 PM, Simon Glass wrote:


 Hi Stephen,

 On 15 May 2015 at 09:34, Stephen Warren  wrote:
>
>
> On 05/13/2015 07:56 AM, Simon Glass wrote:
>>
>>
>>
>> Hi Stephen,
>>
>> On 25 February 2015 at 16:31, Stephen Warren 
>> 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.

>
>
 Wou

Re: [U-Boot] Fix fsl_elbc_nand driver

2015-05-19 Thread Andrei Yakimov
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


Re: [U-Boot] [PATCH 20/20] tegra: config: nyan-big: Add options required by Chrome OS boot

2015-05-19 Thread Stephen Warren
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  wrote:
>> On 05/19/2015 12:01 PM, Simon Glass wrote:
>>>
>>> Hi Stephen,
>>>
>>> On 19 May 2015 at 09:41, Stephen Warren  wrote:

 On 05/18/2015 03:33 PM, Simon Glass wrote:
>
>
> Hi Stephen,
>
> On 15 May 2015 at 09:34, Stephen Warren  wrote:
>>
>>
>> On 05/13/2015 07:56 AM, Simon Glass wrote:
>>>
>>>
>>>
>>> Hi Stephen,
>>>
>>> On 25 February 2015 at 16:31, Stephen Warren 
>>> 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? Wel

[U-Boot] [PATCH] imx: dma: correct MXS_DMA_ALIGNMENT

2015-05-19 Thread Peng Fan
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 
---
 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


[U-Boot] [PATCH v3] tools: moveconfig: a tool to move CONFIGs from headers to defconfigs

2015-05-19 Thread Masahiro Yamada
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 
Signed-off-by: Joe Hershberger 
---

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 
+#
+# 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:
+  
+(the fields must be separated with whitespaces.)
+
+ is the name of config option.
+
+ is the type of the option.  It must be one of bool, tristate,
+string, int, and hex.
+
+ 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
+   :  
+
+ is the name of the defconfig
+(without the suffix _defconfig).
+
+ 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 automatically created and deleted as
+needed.  The number of threads are chosen based on the number of the CPU
+cores of your system although you can change it via 

[U-Boot] [PATCH v4] tools: moveconfig: a tool to move CONFIGs from headers to defconfigs

2015-05-19 Thread Masahiro Yamada
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 
Signed-off-by: Joe Hershberger 
---

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 
+#
+# 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:
+  
+(the fields must be separated with whitespaces.)
+
+ is the name of config option.
+
+ is the type of the option.  It must be one of bool, tristate,
+string, int, and hex.
+
+ 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
+   :  
+
+ is the name of the defconfig
+(without the suffix _defconfig).
+
+ 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 automatically created and deleted as
+needed.  The number of threads are chosen based on t

Re: [U-Boot] i.MX53 USB Client not working

2015-05-19 Thread Fabio Estevam
Hi Matthew,

On Thu, May 14, 2015 at 7:39 PM, Matthew Starr  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

2015-05-19 Thread Simon Glass
Hi Stephen,

On 19 May 2015 at 19:44, Stephen Warren  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  wrote:
>>> On 05/19/2015 12:01 PM, Simon Glass wrote:

 Hi Stephen,

 On 19 May 2015 at 09:41, Stephen Warren  wrote:
>
> On 05/18/2015 03:33 PM, Simon Glass wrote:
>>
>>
>> Hi Stephen,
>>
>> On 15 May 2015 at 09:34, Stephen Warren  wrote:
>>>
>>>
>>> On 05/13/2015 07:56 AM, Simon Glass wrote:



 Hi Stephen,

 On 25 February 2015 at 16:31, Stephen Warren 
 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 pre

Re: [U-Boot] [PATCH v4 03/10] moveconfig: Add a parameter to accept a list to build

2015-05-19 Thread Masahiro Yamada
2015-05-20 2:58 GMT+09:00 Joe Hershberger :
> Hi Masahiro-san,
>
> On Mon, May 18, 2015 at 11:33 PM, Masahiro Yamada
>  wrote:
>> 2015-05-16 6:40 GMT+09:00 Joe Hershberger :
>>> This is helpful to re-attempt to move failed boards from a previous run
>>> without starting over.
>>>
>>> Signed-off-by: Joe Hershberger 
>>>
>>> ---
>>>
>>> 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 v4 08/10] moveconfig: Print a message for missing compiler

2015-05-19 Thread Masahiro Yamada
2015-05-20 2:51 GMT+09:00 Joe Hershberger :
> Hi Masahiro-san,
>
> On Mon, May 18, 2015 at 10:23 PM, Masahiro Yamada
>  wrote:
>> 2015-05-16 6:40 GMT+09:00 Joe Hershberger :
>>> 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 
>>> ---
>>>
>>> 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 
>> 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 v2] tools: moveconfig: a tool to move CONFIGs from headers to defconfigs

2015-05-19 Thread Masahiro Yamada
2015-05-20 0:33 GMT+09:00 Joe Hershberger :

>> +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] [PATCH v5 1/9] moveconfig: Always run savedefconfig on the moved config

2015-05-19 Thread Masahiro Yamada
Hi Joe,



2015-05-20 3:21 GMT+09:00 Joe Hershberger :
> 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 
> ---
> 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-19 Thread Masahiro Yamada
2015-05-20 3:17 GMT+09:00 Simon Glass :

>> 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

2015-05-19 Thread Masahiro Yamada
Signed-off-by: Masahiro Yamada 
---

 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] [PATCH v6 1/4] mtd, spi: add MTD layer driver

2015-05-19 Thread Heiko Schocher

Hello Jagan,

Am 19.05.2015 22:09, schrieb Jagan Teki:

Hi Heiko,

I have tested this sf-mtd stuff, please see below and enabled prints
in all the func calls.


Thanks for testing!


zynq-uboot> mtdparts add nor0 0x1@0x0 env
mtdparts variable not set, see 'help mtdparts'
zynq-uboot> mtdparts

device nor0 , # 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


Looks good ...


I wonder none of the sf_mtd_info._* getting called, why?


Hmm.. good question .. you use the "sf ..." commands, they do not
use the mtd interface, right?

I tested this functions with using UBI on the SPI NOR on the
aristainetos and aristianetos2 boards... I added for example in

diff --git a/drivers/mtd/spi/sf_mtd.c b/drivers/mtd/spi/sf_mtd.c
index 0b9cb62..6063ed7 100644
--- a/drivers/mtd/spi/sf_mtd.c
+++ b/drivers/mtd/spi/sf_mtd.c
@@ -39,6 +40,7 @@ static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t 
from, size_t len,
struct spi_flash *flash = mtd->priv;
int err;

+printf("%s \n", __func__);
err = spi_flash_read(flash, from, len, buf);
if (!err)
*retlen = len;

and see:

=> sf probe
SF: Detected N25Q128A with page size 256 Bytes, erase size 64 KiB, total 16 MiB
=> mtdparts

device nor0 , # parts = 4
 #: namesizeoffset  mask_flags
 0: u-boot  0x000d  0x  0
 1: env 0x0001  0x000d  0
 2: env-red 0x0001  0x000e  0
 3: rescue-system   0x00f1  0x000f  0

device nand0 , # parts = 1
 #: namesizeoffset  mask_flags
 0: ubi 0x4000  0x  0

active partition: nor0,0 - (u-boot) 0x000d @ 0x

defaults:
mtdids  : none
mtdparts: none
=> ubi part rescue-system
UBI: default fastmap pool size: 10
UBI: default fastmap WL pool size: 25
UBI: attaching mtd2 to ubi0
UBI DBG gen (pid 1): sizeof(struct ubi_ainf_peb) 48
UBI DBG gen (pid 1): sizeof(struct ubi_wl_entry) 20
UBI DBG gen (pid 1): min_io_size  1
UBI DBG gen (pid 1): max_write_size   256
UBI DBG gen (pid 1): hdrs_min_io_size 1
UBI DBG gen (pid 1): ec_hdr_alsize64
UBI DBG gen (pid 1): vid_hdr_alsize   64
UBI DBG gen (pid 1): vid_hdr_offset   64
UBI DBG gen (pid 1): vid_hdr_aloffset 64
UBI DBG gen (pid 1): vid_hdr_shift0
UBI DBG gen (pid 1): leb_start128
UBI DBG gen (pid 1): max_erroneous24
UBI DBG gen (pid 1): process PEB 0
UBI DBG bld (pid 1): scan PEB 0
UBI DBG io (pid 1): read EC header from PEB 0
UBI DBG io (pid 1): read 64 bytes from PEB 0:0
spi_flash_mtd_read 
UBI DBG io (pid 1): read VID header from PEB 0
UBI DBG io (pid 1): read 64 bytes from PEB 0:64
spi_flash_mtd_read 
[...]

UBI uses the MTD layer ... the sf command not ...
Hope this helps?

bye,
Heiko


On 27 April 2015 at 11:12, Heiko Schocher  wrote:

From: Daniel Schwierzeck 

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 
Signed-off-by: Heiko Schocher 

---

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 d6c1ffc7d23f4fe4ae8c91101861055