[U-Boot] [PATCH v4 2/3] arm:vf610:Enable the DSPI for Freescale vf610 platform

[Chao Fu]

From: Chao Fu 

This patch enable the DSPI moudle on VF610 platform with following udpate:
Add get_dspi_clk() function and enable DPSI clock gate.
Add DSPI iomux definition and set the iomux for DSPI.

Signed-off-by: Chao Fu 
---
Change in v2:
Separated vf610-twr update into patch 3/4.
Change in v3:
None.
Change in v4:
None.

 arch/arm/cpu/armv7/vf610/generic.c| 7 +++
 arch/arm/include/asm/arch-vf610/clock.h   | 1 +
 arch/arm/include/asm/arch-vf610/crm_regs.h| 1 +
 arch/arm/include/asm/arch-vf610/iomux-vf610.h | 8 
 arch/arm/include/asm/imx-common/iomux-v3.h| 2 ++
 5 files changed, 19 insertions(+)

diff --git a/arch/arm/cpu/armv7/vf610/generic.c 
b/arch/arm/cpu/armv7/vf610/generic.c
index a26d63e..266343e 100644
--- a/arch/arm/cpu/armv7/vf610/generic.c
+++ b/arch/arm/cpu/armv7/vf610/generic.c
@@ -196,6 +196,11 @@ static u32 get_i2c_clk(void)
return get_ipg_clk();
 }
 
+static u32 get_dspi_clk(void)
+{
+   return get_ipg_clk();
+}
+
 unsigned int mxc_get_clock(enum mxc_clock clk)
 {
switch (clk) {
@@ -213,6 +218,8 @@ unsigned int mxc_get_clock(enum mxc_clock clk)
return get_fec_clk();
case MXC_I2C_CLK:
return get_i2c_clk();
+   case MXC_DSPI_CLK:
+   return get_dspi_clk();
default:
break;
}
diff --git a/arch/arm/include/asm/arch-vf610/clock.h 
b/arch/arm/include/asm/arch-vf610/clock.h
index 535adad..e5a5c6d 100644
--- a/arch/arm/include/asm/arch-vf610/clock.h
+++ b/arch/arm/include/asm/arch-vf610/clock.h
@@ -17,6 +17,7 @@ enum mxc_clock {
MXC_ESDHC_CLK,
MXC_FEC_CLK,
MXC_I2C_CLK,
+   MXC_DSPI_CLK,
 };
 
 void enable_ocotp_clk(unsigned char enable);
diff --git a/arch/arm/include/asm/arch-vf610/crm_regs.h 
b/arch/arm/include/asm/arch-vf610/crm_regs.h
index 724682c..54fb748 100644
--- a/arch/arm/include/asm/arch-vf610/crm_regs.h
+++ b/arch/arm/include/asm/arch-vf610/crm_regs.h
@@ -189,6 +189,7 @@ struct anadig_reg {
 #define CCM_REG_CTRL_MASK  0x
 #define CCM_CCGR0_UART0_CTRL_MASK   (0x3 << 14)
 #define CCM_CCGR0_UART1_CTRL_MASK  (0x3 << 16)
+#define CCM_CCGR0_DSPI0_CTRL_MASK  (0x3 << 24)
 #define CCM_CCGR1_PIT_CTRL_MASK(0x3 << 14)
 #define CCM_CCGR1_WDOGA5_CTRL_MASK (0x3 << 28)
 #define CCM_CCGR2_QSPI0_CTRL_MASK  (0x3 << 8)
diff --git a/arch/arm/include/asm/arch-vf610/iomux-vf610.h 
b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
index 7464da8..fdb7e40 100644
--- a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
+++ b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
@@ -29,6 +29,10 @@
 
 #define VF610_QSPI_PAD_CTRL(PAD_CTL_SPEED_HIGH | PAD_CTL_DSE_150ohm | \
PAD_CTL_PUS_22K_UP | PAD_CTL_OBE_IBE_ENABLE)
+#define VF610_DSPI_PAD_CTRL(PAD_CTL_OBE | PAD_CTL_DSE_25ohm | \
+   PAD_CTL_SPEED_MED)
+#define VF610_DSPI_SIN_PAD_CTRL(PAD_CTL_IBE | PAD_CTL_DSE_25ohm | \
+   PAD_CTL_SPEED_MED)
 
 enum {
VF610_PAD_PTA6__RMII0_CLKIN = IOMUX_PAD(0x, 0x, 2, 
__NA_, 0, VF610_ENET_PAD_CTRL),
@@ -63,6 +67,10 @@ enum {
VF610_PAD_PTA29__ESDHC1_DAT3= IOMUX_PAD(0x004c, 0x004c, 5, 
__NA_, 0, VF610_SDHC_PAD_CTRL),
VF610_PAD_PTB14__I2C0_SCL   = IOMUX_PAD(0x0090, 0x0090, 2, 
0x033c, 1, VF610_I2C_PAD_CTRL),
VF610_PAD_PTB15__I2C0_SDA   = IOMUX_PAD(0x0094, 0x0094, 2, 
0x0340, 1, VF610_I2C_PAD_CTRL),
+   VF610_PAD_PTB19__DSPI0_CS0  = IOMUX_PAD(0x00a4, 0x00a4, 1, 
__NA_, 0, VF610_DSPI_PAD_CTRL),
+   VF610_PAD_PTB20__DSPI0_SIN  = IOMUX_PAD(0x00a8, 0x00a8, 1, 
__NA_, 0, VF610_DSPI_SIN_PAD_CTRL),
+   VF610_PAD_PTB21__DSPI0_SOUT = IOMUX_PAD(0x00ac, 0x00ac, 1, 
__NA_, 0, VF610_DSPI_PAD_CTRL),
+   VF610_PAD_PTB22__DSPI0_SCK  = IOMUX_PAD(0x00b0, 0x00b0, 1, 
__NA_, 0, VF610_DSPI_PAD_CTRL),
VF610_PAD_PTD31__NF_IO15= IOMUX_PAD(0x00fc, 0x00fc, 2, 
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
VF610_PAD_PTD30__NF_IO14= IOMUX_PAD(0x0100, 0x0100, 2, 
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
VF610_PAD_PTD29__NF_IO13= IOMUX_PAD(0x0104, 0x0104, 2, 
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
diff --git a/arch/arm/include/asm/imx-common/iomux-v3.h 
b/arch/arm/include/asm/imx-common/iomux-v3.h
index 70ee86c..afade7e 100644
--- a/arch/arm/include/asm/imx-common/iomux-v3.h
+++ b/arch/arm/include/asm/imx-common/iomux-v3.h
@@ -152,6 +152,8 @@ typedef u64 iomux_v3_cfg_t;
 #define PAD_CTL_PUS_47K_UP (1 << 4 | PAD_CTL_PUE)
 #define PAD_CTL_PUS_100K_UP(2 << 4 | PAD_CTL_PUE)
 #define PAD_CTL_PUS_22K_UP (3 << 4 | PAD_CTL_PUE)
+#define PAD_CTL_OBE(1 << 1)
+#define PAD_CTL_IBE(1 << 0)
 
 #define PAD_CTL_ODE(1 << 3)
 
-- 
1.8.4

Re: [U-Boot] A minor question on a Driver Model function

[Masahiro Yamada]

On Fri, 19 Sep 2014 09:34:53 +0300
Igor Grinberg  wrote:

> On 09/18/14 18:46, Bill Pringlemeir wrote:
> > 
>  On 12 September 2014 05:25, Masahiro Yamada
>   wrote:
> >>>
>  I have a qustion about lists_driver_lookup_name() function.
> > 
> >> On 09/14/14 21:28, Simon Glass wrote:
> >>>
> >> I would suggest still using strncmp as it is safer,
> >> but count also the '\0', so something like:
> >>>
> >>> On 17 Sep 2014, grinb...@compulab.co.il wrote:
> >>>
> > Why safer?
> >>>
> > Could you give me more detailed explanation?
> >>>
>  On 09/17/14 11:18, Masahiro Yamada wrote:
> >>>
>  Well, I'm not an expert in s/w security, but I'll try to explain...
> >>>
> >>> [snip]
> >>>
>  But, again, I'm not an expert in this area, so its only a
>  suggestion.
> >>>
> > 
> >> On 09/17/14 18:25, Bill Pringlemeir wrote:
> > 
> >>> I thought it was fairly apparent that the current code supports
> >>> passing a string that is *NOT* null terminated.  This can be
> >>> convenient if you extract a sub-string from a command line and do not
> >>> need to make a copy that is NULL terminate or perform 'strtok()' type
> >>> magic.
> > 
> > On 18 Sep 2014, grinb...@compulab.co.il wrote:
> > 
> >> Here is the whole function:
> >>
> >> --cut--
> >> struct driver *lists_driver_lookup_name(const char *name)
> >> {
> >> struct driver *drv =
> >> ll_entry_start(struct driver, driver);
> >> const int n_ents = ll_entry_count(struct driver, driver);
> >> struct driver *entry;
> >> int len;
> >>
> >> if (!drv || !n_ents)
> >> return NULL;
> >>
> >> len = strlen(name);
> >>
> >> for (entry = drv; entry != drv + n_ents; entry++) {
> >> if (strncmp(name, entry->name, len))
> >> continue;
> >>
> >> /* Full match */
> >> if (len == strlen(entry->name))
> >> return entry;
> >>>
> >>
> >> /* Not found */
> >> return NULL;
> >>>
> >> --cut--
> >>
> >> and... no, the code does not support passing a string that is
> >> not null terminated.
> > 
> > Then using the strncmp() seems useless for security reasons?  The 'len'
> > is not passed in by the caller and 'strlen()' will have the same
> > problems that 'strcmp()' would for read buffer overflows?  I would guess
> > the code was cribbed from where 'len' was passed?  In that case, it
> > would support strings that are not null terminated.
> 
> Yes, that is correct.
> 
> Since we are dealing with device/driver names here.
> I think the best would be to define a sane name length limit
> (say 20 or more characters) and use it as the maximal length
> if no '\0' found before the limit.
> 
> 


I disagre.

The argument "name" of this function may be derived from a device tree,
that is, it is possibly not NULL-terminated
if U-Boot is accidentally given a corrupted device tree.


On the other hand, "entry->name" originates in
a U_BOOT_DRIVER() instance.

For example, something like this

U_BOOT_DRIVER(root_driver) = {
.name   = "root_driver",
.id = UCLASS_ROOT,
};


The .name member of U_BOOT_DRIVER is guaranteed
to be NULL-terminated.


I'd say,  strcmp(name, entry->name) is always safe.




(In the current code,


len = strlen(name);  is *NOT* safe,


but,


len = strlen(entry->name);  is safe





Best Regards
Masahiro Yamada

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 3/3] arm:vf610:vf610-twr:Enable the DSPI for Freesacale vf610-twr board

[Chao Fu]

From: Chao Fu 

Enable DSPI iomux for vf610twr board.
Add the SPI configuration for vf610twr board.

Signed-off-by: Chao Fu 
---
Change in v2 :
New.
Change in v3 :
None.
Change in v4 :
None.

 board/freescale/vf610twr/vf610twr.c | 15 ++-
 include/configs/vf610twr.h  | 13 +
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/board/freescale/vf610twr/vf610twr.c 
b/board/freescale/vf610twr/vf610twr.c
index 54a9f2c..08200b5 100644
--- a/board/freescale/vf610twr/vf610twr.c
+++ b/board/freescale/vf610twr/vf610twr.c
@@ -298,6 +298,18 @@ static void setup_iomux_qspi(void)
imx_iomux_v3_setup_multiple_pads(qspi0_pads, ARRAY_SIZE(qspi0_pads));
 }
 
+static void setup_iomux_dspi(void)
+{
+   static const iomux_v3_cfg_t dspi0_pads[] = {
+   VF610_PAD_PTB19__DSPI0_CS0,
+   VF610_PAD_PTB20__DSPI0_SIN,
+   VF610_PAD_PTB21__DSPI0_SOUT,
+   VF610_PAD_PTB22__DSPI0_SCK,
+   };
+
+   imx_iomux_v3_setup_multiple_pads(dspi0_pads, ARRAY_SIZE(dspi0_pads));
+}
+
 #ifdef CONFIG_FSL_ESDHC
 struct fsl_esdhc_cfg esdhc_cfg[1] = {
{ESDHC1_BASE_ADDR},
@@ -335,7 +347,7 @@ static void clock_init(void)
struct anadig_reg *anadig = (struct anadig_reg *)ANADIG_BASE_ADDR;
 
clrsetbits_le32(&ccm->ccgr0, CCM_REG_CTRL_MASK,
-   CCM_CCGR0_UART1_CTRL_MASK);
+   CCM_CCGR0_UART1_CTRL_MASK | CCM_CCGR0_DSPI0_CTRL_MASK);
clrsetbits_le32(&ccm->ccgr1, CCM_REG_CTRL_MASK,
CCM_CCGR1_PIT_CTRL_MASK | CCM_CCGR1_WDOGA5_CTRL_MASK);
clrsetbits_le32(&ccm->ccgr2, CCM_REG_CTRL_MASK,
@@ -411,6 +423,7 @@ int board_early_init_f(void)
setup_iomux_enet();
setup_iomux_i2c();
setup_iomux_qspi();
+   setup_iomux_dspi();
 
return 0;
 }
diff --git a/include/configs/vf610twr.h b/include/configs/vf610twr.h
index 0342550..8c89a6b 100644
--- a/include/configs/vf610twr.h
+++ b/include/configs/vf610twr.h
@@ -80,6 +80,19 @@
 #define CONFIG_SYS_FSL_QSPI_LE
 #endif
 
+/* DSPI Configs */
+#ifdef CONFIG_FSL_DSPI
+#define MMAP_DSPI  SPI0_BASE_ADDR
+#define CONFIG_SYS_FSL_DSPI_LE
+#define CONFIG_SYS_DSPI_CTAR0  (DSPI_CTAR_TRSZ(7) | \
+DSPI_CTAR_PCSSCK_1CLK | \
+DSPI_CTAR_PASC(0) | \
+DSPI_CTAR_PDT(0) | \
+DSPI_CTAR_CSSCK(0) | \
+DSPI_CTAR_ASC(0) | \
+DSPI_CTAR_DT(0))
+#endif
+
 /* I2C Configs */
 #define CONFIG_CMD_I2C
 #define CONFIG_SYS_I2C
-- 
1.8.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 1/3] spi:rewrite the Freescale DSPI driver.

[Chao Fu]

From: Chao Fu 

Freescale DSPI module is used on both the ColdFire platform and the ARM
platform. The original DSPI driver is written for ColdFire platform only,
this patch rewrite the driver to make it be used across the platforms.
Some files, functions, variables and macros were changed accordingly for
some ColdFire boards and Arm boards.
The rewrite including the following changes:

Rename the file name :
cf_spi.c -> fsl_dspi.c
Move the file:
arch/m68k/include/asm/coldfire/dspi.h -> include/fsl_dspi.h
Rename the functions and variables:
cfxxx -> dspixxx
Renamed macros:
CONFIG_CF_DSPI -> CONFIG_FSL_DSPI
Keep the following functions for ColdFire:
cfspi_port_conf()
cfspi_claim_bus()
cfspi_release_bus()
Add function for ColdFire:
get_dspi_clk()

Add endian convert for different platform.
dspi_write32()
dspi_read32()
Tested on board M54455EVB, ls1021a-qds and VF610-twr.

Signed-off-by: Chao Fu 
Signed-off-by: Alison Wang 
---
Change in v2:
Merge m68k update and driver update into the patch.
Change in v3:
Remove some unstandard coding style.
Change in v4:
Add two-endian support, and ls1021a support.

 arch/m68k/cpu/mcf5227x/cpu_init.c |   3 +-
 arch/m68k/cpu/mcf5227x/speed.c|   7 +
 arch/m68k/cpu/mcf52x2/speed.c |   7 +
 arch/m68k/cpu/mcf5445x/cpu_init.c |   3 +-
 arch/m68k/cpu/mcf5445x/speed.c|   7 +
 arch/m68k/include/asm/coldfire/dspi.h | 142 -
 arch/m68k/include/asm/immap_5227x.h   |   1 -
 arch/m68k/include/asm/immap_5301x.h   |   1 -
 arch/m68k/include/asm/immap_5441x.h   |   1 -
 arch/m68k/include/asm/immap_5445x.h   |   1 -
 arch/m68k/include/asm/immap_547x_8x.h |   1 -
 drivers/spi/Makefile  |   2 +-
 drivers/spi/cf_spi.c  | 347 ---
 drivers/spi/fsl_dspi.c| 373 ++
 include/configs/M52277EVB.h   |   3 +-
 include/configs/M54418TWR.h   |   3 +-
 include/configs/M54451EVB.h   |   3 +-
 include/configs/M54455EVB.h   |   3 +-
 include/fsl_dspi.h| 142 +
 19 files changed, 545 insertions(+), 505 deletions(-)
 delete mode 100644 arch/m68k/include/asm/coldfire/dspi.h
 delete mode 100644 drivers/spi/cf_spi.c
 create mode 100644 drivers/spi/fsl_dspi.c
 create mode 100644 include/fsl_dspi.h

diff --git a/arch/m68k/cpu/mcf5227x/cpu_init.c 
b/arch/m68k/cpu/mcf5227x/cpu_init.c
index 91b5fad..bd0b4ab 100644
--- a/arch/m68k/cpu/mcf5227x/cpu_init.c
+++ b/arch/m68k/cpu/mcf5227x/cpu_init.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Breath some life into the CPU...
@@ -139,7 +140,7 @@ void uart_port_conf(int port)
}
 }
 
-#ifdef CONFIG_CF_DSPI
+#ifdef CONFIG_FSL_DSPI
 void cfspi_port_conf(void)
 {
gpio_t *gpio = (gpio_t *) MMAP_GPIO;
diff --git a/arch/m68k/cpu/mcf5227x/speed.c b/arch/m68k/cpu/mcf5227x/speed.c
index 44de4a6..2bfff13 100644
--- a/arch/m68k/cpu/mcf5227x/speed.c
+++ b/arch/m68k/cpu/mcf5227x/speed.c
@@ -124,3 +124,10 @@ int get_clocks(void)
 
return (0);
 }
+
+#ifdef CONFIG_FSL_DSPI
+int get_dspi_clk(void)
+{
+   return gd->bus_clk;
+}
+#endif
diff --git a/arch/m68k/cpu/mcf52x2/speed.c b/arch/m68k/cpu/mcf52x2/speed.c
index c5961d4..69b49c7 100644
--- a/arch/m68k/cpu/mcf52x2/speed.c
+++ b/arch/m68k/cpu/mcf52x2/speed.c
@@ -83,3 +83,10 @@ int get_clocks (void)
 
return (0);
 }
+
+#ifdef CONFIG_FSL_DSPI
+int get_dspi_clk(void)
+{
+   return gd->bus_clk;
+}
+#endif
diff --git a/arch/m68k/cpu/mcf5445x/cpu_init.c 
b/arch/m68k/cpu/mcf5445x/cpu_init.c
index 9c324dc..bb7a4cd 100644
--- a/arch/m68k/cpu/mcf5445x/cpu_init.c
+++ b/arch/m68k/cpu/mcf5445x/cpu_init.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #if defined(CONFIG_CMD_NET)
 #include 
@@ -423,7 +424,7 @@ int fecpin_setclear(struct eth_device *dev, int setclear)
 }
 #endif
 
-#ifdef CONFIG_CF_DSPI
+#ifdef CONFIG_FSL_DSPI
 void cfspi_port_conf(void)
 {
gpio_t *gpio = (gpio_t *) MMAP_GPIO;
diff --git a/arch/m68k/cpu/mcf5445x/speed.c b/arch/m68k/cpu/mcf5445x/speed.c
index 07a9b35..29c858e 100644
--- a/arch/m68k/cpu/mcf5445x/speed.c
+++ b/arch/m68k/cpu/mcf5445x/speed.c
@@ -279,3 +279,10 @@ int get_clocks(void)
 
return (0);
 }
+
+#ifdef CONFIG_FSL_DSPI
+int get_dspi_clk(void)
+{
+   return gd->bus_clk;
+}
+#endif
diff --git a/arch/m68k/include/asm/coldfire/dspi.h 
b/arch/m68k/include/asm/coldfire/dspi.h
deleted file mode 100644
index fda7138..000
--- a/arch/m68k/include/asm/coldfire/dspi.h
+++ /dev/null
@@ -1,142 +0,0 @@
-/*
- * MCF5227x Internal Memory Map
- *
- * Copyright (C) 2004-2007 Freescale Semiconductor, Inc.
- * TsiChung Liew (tsi-chung.l...@freescale.com)
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef __DSPI_H__
-#define __DSPI_H__
-
-/* DMA Serial Peripheral Interface (DSPI) */
-typedef struct dspi {
-   u32 mcr

Re: [U-Boot] A minor question on a Driver Model function

[Igor Grinberg]

On 09/18/14 18:46, Bill Pringlemeir wrote:
> 
 On 12 September 2014 05:25, Masahiro Yamada
  wrote:
>>>
 I have a qustion about lists_driver_lookup_name() function.
> 
>> On 09/14/14 21:28, Simon Glass wrote:
>>>
>> I would suggest still using strncmp as it is safer,
>> but count also the '\0', so something like:
>>>
>>> On 17 Sep 2014, grinb...@compulab.co.il wrote:
>>>
> Why safer?
>>>
> Could you give me more detailed explanation?
>>>
 On 09/17/14 11:18, Masahiro Yamada wrote:
>>>
 Well, I'm not an expert in s/w security, but I'll try to explain...
>>>
>>> [snip]
>>>
 But, again, I'm not an expert in this area, so its only a
 suggestion.
>>>
> 
>> On 09/17/14 18:25, Bill Pringlemeir wrote:
> 
>>> I thought it was fairly apparent that the current code supports
>>> passing a string that is *NOT* null terminated.  This can be
>>> convenient if you extract a sub-string from a command line and do not
>>> need to make a copy that is NULL terminate or perform 'strtok()' type
>>> magic.
> 
> On 18 Sep 2014, grinb...@compulab.co.il wrote:
> 
>> Here is the whole function:
>>
>> --cut--
>> struct driver *lists_driver_lookup_name(const char *name)
>> {
>> struct driver *drv =
>> ll_entry_start(struct driver, driver);
>> const int n_ents = ll_entry_count(struct driver, driver);
>> struct driver *entry;
>> int len;
>>
>> if (!drv || !n_ents)
>> return NULL;
>>
>> len = strlen(name);
>>
>> for (entry = drv; entry != drv + n_ents; entry++) {
>> if (strncmp(name, entry->name, len))
>> continue;
>>
>> /* Full match */
>> if (len == strlen(entry->name))
>> return entry;
>>>
>>
>> /* Not found */
>> return NULL;
>>>
>> --cut--
>>
>> and... no, the code does not support passing a string that is
>> not null terminated.
> 
> Then using the strncmp() seems useless for security reasons?  The 'len'
> is not passed in by the caller and 'strlen()' will have the same
> problems that 'strcmp()' would for read buffer overflows?  I would guess
> the code was cribbed from where 'len' was passed?  In that case, it
> would support strings that are not null terminated.

Yes, that is correct.

Since we are dealing with device/driver names here.
I think the best would be to define a sane name length limit
(say 20 or more characters) and use it as the maximal length
if no '\0' found before the limit.


-- 
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PULL] u-boot-atmel/master -> u-boot-arm/master

[Andreas Bießmann]

Dear Albert Aribaud,

please pull the following changes into u-boot-arm/master.

The following changes since commit 9170818a4e004af7893fa0113f6e5b4afafded55:

  kconfiglib: change SPDX-License-Identifier to ISC (2014-09-17 21:03:18 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-atmel.git master

for you to fetch changes up to 015b18c642d9b0f92d1b35f6d6ed73a6a0b29675:

  ARM: at91sam9rlek: convert to generic board support (2014-09-19 00:11:24 
+0200)


Bo Shen (7):
  ARM: atmel: sama5d3xek: add nor flash init function
  ARM: atmel: sama5d3xek: enable NOR flash support
  ARM: atmel: sama5d3: add timings register
  ARM: atmel: use pcr to enable or disable peripheral clock
  ARM: atmel: add pcr related definition
  USB: ohci-at91: use pcr to enable or disable clock
  USB: ehci-atmel: use pcr to enable or disable clock

Boris BREZILLON (1):
  mtd: atmel_nand: Disable subpage NAND write when using Atmel PMECC

Wu, Josh (3):
  mtd: atmel-nand: use pmecc_readl(b)/pmecc_writel to access the pmecc 
register
  ARM: at91sam9n12ek: convert to generic board support
  ARM: at91sam9rlek: convert to generic board support

 arch/arm/cpu/armv7/at91/clock.c  |   24 +--
 arch/arm/include/asm/arch-at91/at91_pmc.h|6 ++-
 arch/arm/include/asm/arch-at91/clk.h |1 +
 arch/arm/include/asm/arch-at91/sama5d3.h |1 +
 arch/arm/include/asm/arch-at91/sama5d3_smc.h |3 +-
 board/atmel/sama5d3xek/sama5d3xek.c  |   58 ++
 drivers/mtd/nand/atmel_nand.c|   22 +-
 drivers/mtd/nand/atmel_nand_ecc.h|3 ++
 drivers/usb/host/ehci-atmel.c|8 
 drivers/usb/host/ohci-at91.c |8 ++--
 include/configs/at91sam9n12ek.h  |1 +
 include/configs/at91sam9rlek.h   |2 +
 include/configs/sama5d3xek.h |   13 +-
 13 files changed, 129 insertions(+), 21 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM: at91sam9n12ek: convert to generic board support

[Andreas Bießmann]

Dear Josh Wu,

Josh Wu  writes:
>Signed-off-by: Josh Wu 
>---
> include/configs/at91sam9n12ek.h | 1 +
> 1 file changed, 1 insertion(+)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM: at91sam9rlek: convert to generic board support

[Andreas Bießmann]

Dear Josh Wu,

Josh Wu  writes:
>Signed-off-by: Josh Wu 
>---
> include/configs/at91sam9rlek.h | 2 ++
> 1 file changed, 2 insertions(+)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mtd: atmel_nand: Disable subpage NAND write when using Atmel PMECC

[Andreas Bießmann]

Dear Boris BREZILLON,

Boris BREZILLON  writes:
>Disable subpage write when using PMECC to prevent buggy partial page write.
>
>This fix has been taken from linux sources (see commit
>90445ff6241e2a13445310803e2efa606c61f276)
>
>Signed-off-by: Boris BREZILLON 
>Acked-by: Josh Wu 
>---
>Hi,
>
>Here is a link to the linux commit:
>https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/mtd/nand/atmel_nand.c?id=90445ff6241e2a13445310803e2efa606c61f276
>
>Best Regards,
>
>Boris
>
> drivers/mtd/nand/atmel_nand.c | 1 +
> 1 file changed, 1 insertion(+)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,3/4] USB: ohci-at91: use pcr to enable or disable clock

[Andreas Bießmann]

Dear Bo Shen,

Bo Shen  writes:
>If the SoC has pcr, we use pcr (peripheral control register)
>to enable or disable clock.
>
>Signed-off-by: Bo Shen 
>---
>
> drivers/usb/host/ohci-at91.c | 8 
> 1 file changed, 4 insertions(+), 4 deletions(-)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,2/4] ARM: atmel: add pcr related definition

[Andreas Bießmann]

Dear Bo Shen,

Bo Shen  writes:
>Using CPU_HAS_PCR micro to present the SoC has pcr
>(peripheral control register).
>
>Signed-off-by: Bo Shen 
>---
>
> arch/arm/include/asm/arch-at91/at91_pmc.h | 2 +-
> arch/arm/include/asm/arch-at91/sama5d3.h  | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM: atmel: sama5d3: add timings register

[Andreas Bießmann]

Dear Bo Shen,

Bo Shen  writes:
>Signed-off-by: Bo Shen 
>Reviewed-by: Andreas Bießmann 
>---
> arch/arm/include/asm/arch-at91/sama5d3_smc.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 1/4] ARM: atmel: use pcr to enable or disable peripheral clock

[Andreas Bießmann]

Dear Bo Shen,

Bo Shen  writes:
>When use pcr (peripheral control register), then we won't need
>to care about the peripheral ID.
>
>Signed-off-by: Bo Shen 
>---
>
> arch/arm/cpu/armv7/at91/clock.c   | 24 
> arch/arm/include/asm/arch-at91/at91_pmc.h |  4 
> arch/arm/include/asm/arch-at91/clk.h  |  1 +
> 3 files changed, 25 insertions(+), 4 deletions(-)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,v2,2/2] ARM: atmel: sama5d3xek: enable NOR flash support

[Andreas Bießmann]

Dear Bo Shen,

Bo Shen  writes:
>Signed-off-by: Bo Shen 
>---
>Changes in v2:
>  - Add CONFIG_SYS_FLASH_PROTECTION
>  - Correct the max sector number
>
> include/configs/sama5d3xek.h | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,4/4] USB: ehci-atmel: use pcr to enable or disable clock

[Andreas Bießmann]

Dear Bo Shen,

Bo Shen  writes:
>If the SoC has pcr, we use pcr (peripheral control register)
>to enable or disable clock.
>
>Signed-off-by: Bo Shen 
>---
>
> drivers/usb/host/ehci-atmel.c | 8 
> 1 file changed, 8 insertions(+)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] compulab trimslice build error due to 52658fda7abc ("compulab: eeprom: add support for defining eeprom i2c bus")

[Igor Grinberg]

Hi Stephen,

On 09/18/14 20:21, Stephen Warren wrote:
> After commit 52658fda7abc ("compulab: eeprom: add support for defining eeprom 
> i2c bus"), the trimslice board fails to build with:
> 
> .../board/compulab/common/eeprom.c: In function ‘cl_eeprom_read’:
> .../board/compulab/common/eeprom.c:37:24: error: ‘CONFIG_SYS_I2C_EEPROM_BUS’ 
> undeclared (first use in this function)
> .../board/compulab/common/eeprom.c:37:24: note: each undeclared identifier is 
> reported only once for each function it appears in
> 
> I have no idea if this EEPROM code should even run on TrimSlice or not. Can 
> you take a look at the correct fix?

We have already submitted a temporary fix, see [1].
The intend is to switch to Kconfig for all CompuLab boards
and that will bring the proper fix for the problem.
After this, the temporary fixes can be removed.

[1] https://patchwork.ozlabs.org/patch/390381/

-- 
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,v2,1/2] ARM: atmel: sama5d3xek: add nor flash init function

[Andreas Bießmann]

Dear Bo Shen,

Bo Shen  writes:
>Add NOR flash hardware init function, including SMC and PIO
>configuration.
>
>Signed-off-by: Bo Shen 
>Reviewed-by: Andreas Bießmann 
>---
>Changes in v2: None
>
> board/atmel/sama5d3xek/sama5d3xek.c | 58 +
> 1 file changed, 58 insertions(+)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mtd: atmel-nand: use pmecc_readl(b)/pmecc_writel to access the pmecc register

[Andreas Bießmann]

Dear Josh Wu,

Josh Wu  writes:
>We defined the macro pmecc_readl(b)/pmecc_writel for pmecc register access.
>But in the driver we also use the readl(b)/writel.
>To keep consistent, this patch make all use pmecc_readl(b)/pmecc_writel.
>
>Signed-off-by: Josh Wu 
>Reviewed-by: Andreas Bießmann 
>---
> drivers/mtd/nand/atmel_nand.c |   21 +++--
> drivers/mtd/nand/atmel_nand_ecc.h |3 +++
> 2 files changed, 14 insertions(+), 10 deletions(-)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] usb: gadget: fastboot: improve download progress bar

[Bo Shen]

When download is ongoing, if the actual size of one transfer
is not the same as BTYES_PER_DOT, which will cause the dot
won't print anymore. Then it will let the user thinking it
is stuck, actually it is transfering without dot printed.

So, improve the method to show the progress bar (print dot).

Signed-off-by: Bo Shen 
---
Changes in v2:
  - get rid of the global variable.
  - avoid the dot print after showing the total download length.

 drivers/usb/gadget/f_fastboot.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 7a1acb9..dda9d1c 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -380,6 +380,7 @@ static void rx_handler_dl_image(struct usb_ep *ep, struct 
usb_request *req)
unsigned int transfer_size = download_size - download_bytes;
const unsigned char *buffer = req->buf;
unsigned int buffer_size = req->actual;
+   unsigned int pre_dot_num, now_dot_num;
 
if (req->status != 0) {
printf("Bad status: %d\n", req->status);
@@ -392,7 +393,15 @@ static void rx_handler_dl_image(struct usb_ep *ep, struct 
usb_request *req)
memcpy((void *)CONFIG_USB_FASTBOOT_BUF_ADDR + download_bytes,
   buffer, transfer_size);
 
+   pre_dot_num = download_bytes / BYTES_PER_DOT;
download_bytes += transfer_size;
+   now_dot_num = download_bytes / BYTES_PER_DOT;
+
+   if (pre_dot_num != now_dot_num) {
+   putc('.');
+   if (!(now_dot_num % 74))
+   putc('\n');
+   }
 
/* Check if transfer is done */
if (download_bytes >= download_size) {
@@ -414,11 +423,6 @@ static void rx_handler_dl_image(struct usb_ep *ep, struct 
usb_request *req)
req->length = ep->maxpacket;
}
 
-   if (download_bytes && !(download_bytes % BYTES_PER_DOT)) {
-   putc('.');
-   if (!(download_bytes % (74 * BYTES_PER_DOT)))
-   putc('\n');
-   }
req->actual = 0;
usb_ep_queue(ep, req, 0);
 }
-- 
2.1.0.24.g4109c28

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] dm: avoid dev->req_seq overflow

[Robert Baldyga]

On 09/18/2014 08:00 PM, Simon Glass wrote:
> Hi Robert,
> 
> On 18 September 2014 09:13, Robert Baldyga  > wrote:
> 
> Since dev->req_seq value is initialized from "reg" property of fdt node,
> there is posibility, that address value contained in fdt is greater than
> INT_MAX, and then value in dev->req_seq is negative which led to probe()
> fail.
> 
> This patch fix this problem by ensuring that req_seq is positive, unless
> it's one of errno codes.
> 
> 
> Wouldn't this be a bug in the device tree file? What does it mean to
> have a -ve value?
> 

Device tree seems to be ok. We have:

pinctrl0: pinctrl@e020 {
compatible = "samsung,s5pc110-pinctrl";
reg = <0xe020 0x1000>;
};

So when we take address from "reg" as dev->req_seq, then value
0xe020 after casting to int gives -534773760. Function
uclass_resolve_seq() returns it as proper seq number, because it's
unique. But then in file drivers/core/device.c, in function
device_probe() we have:

seq = uclass_resolve_seq(dev);
if (seq < 0) {
ret = seq;
goto fail;
}

And it will obviously fail.

Using "reg" value as req_seq doesn't work when this value is greater
than INT_MAX.

> 
> Signed-off-by: Robert Baldyga  >
> ---
>  drivers/core/device.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/core/device.c b/drivers/core/device.c
> index 166b073..35ffce0 100644
> --- a/drivers/core/device.c
> +++ b/drivers/core/device.c
> @@ -107,6 +107,8 @@ int device_bind(struct udevice *parent, struct
> driver *drv, const char *name,
>  * when the device is probed.
>  */
> dev->req_seq = fdtdec_get_int(gd->fdt_blob, of_offset,
> "reg", -1);
> +   if (!IS_ERR_VALUE(dev->req_seq))
> +   dev->req_seq &= INT_MAX;
> dev->seq = -1;
> if (uc->uc_drv->name && of_offset != -1) {
> fdtdec_get_alias_seq(gd->fdt_blob, uc->uc_drv->name,
> of_offset,
> --
> 1.9.1
> 

Thanks,
Robert Baldyga
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 6/7] arm: ls102xa: Add SD boot support for LS1021AQDS board

[Huan Wang]

Hi, Albert,

> > +   . = ALIGN(4);
> > +   .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
> > +
> > +   . = ALIGN(4);
> > +   .data : {
> > +   *(.data*)
> > +   }
> > +
> > +   . = ALIGN(4);
> > +   .u_boot_list : {
> > +   KEEP(*(SORT(.u_boot_list*_i2c_*)));
> > +   }
> 
> IS this required? And if it is, could it not be added to the
> arch/arm/cpu/u-boot-spl.lds file? This way you would not need an .lds
> file at all.
> 
[Alison Wang] Yes, it is required. I would like to add it in 
arch/arm/cpu/u-boot-spl.lds. I was not sure adding it in 
arch/arm/cpu/u-boot-spl.lds is acceptable or not.


Best Regards,
Alison Wang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Call for participation in the U-Boot Mini Summit 2014

[Marek Vasut]

On Thursday, September 18, 2014 at 10:52:12 AM, Alexey Brodkin wrote:
> Hi Detlev,
> 
> On Wed, 2014-09-03 at 18:56 +0200, Przemyslaw Marczak wrote:
> > Hello Detlev,
> > 
> > On 08/11/2014 05:48 PM, Przemyslaw Marczak wrote:
> > > Hello Detlev,
> > > 
> > > On 01/13/2014 06:12 PM, Detlev Zundel wrote:
> > >> Hi,
> > >> 
> > >> as already indicated, we are looking forward to our next U-Boot Mini
> > >> Summit at Embedded Linux Conference Europe 2014 which will take place
> > >> in Düsseldorf, Germany from October 13 - 15.
> > >> 
> > >> The call for papers of the main conference is now open[1] and if you
> > >> want to submit a talk for the main tracks, you should note the
> > >> deadline of July 11.
> > >> 
> > >> For our U-Boot Mini Summit, I'd like to get the schedule completed
> > >> synchronized to the schedule release of the main event, which is
> > >> August 12.  So please submit talk proposals here with at least me on
> > >> CC.
> > >> 
> > >> To coordinate the event better, I have setup another wiki page[2] that
> > >> can and _should_ be edited by the interested parties.  Feel free for
> > >> example to add yourself to the "interested participants" so that we
> > >> get an idea of how many of the U-Boot developers will be there.
> > >> 
> > >> Best wishes
> > >> 
> > >>Detlev
> 
> Sorry for my late input on this regard.
> But if there's still a possibility to have another talk I'd like to
> propose mine "ARC - new first-class citizen in U-Boot" (which was
> declined for main ELCE2014 event).
> 
> Abstract is in-lined below.
> 
> ===
> U-Boot is a de-facto standard bootloader for Linux-driven embedded
> systems. It provides flexible means for loading kernel and if required
> image of filesystem from different media be it embedded non-volatile
> memory, attached storage or even network share. Linux kernel was ported
> to DesignWare ARC a while ago and starting from version 3.9 the port was
> accepted upstream. Now to enable real-life device booting on custom
> hardware decision was made to port U-Boot for ARC. This presentation
> unveils reasons to start the project, highlights milestones passed
> during porting process, touches some pitfalls and encourages more
> engineers and companies to use and contribute to U-Boot project.
> ===
> 
> I'm not sure if this kind of speech is of any interest for existing
> U-boot developers, but I may indeed emphasize technical aspects now.
> 
> Any feedback is more than welcome.

If that's an introduction to porting U-Boot, it might bring to light some new 
ideas about the porting process and also point out some obstacles we were not 
aware of. I think it's a good idea to have such a war story ;-)

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] FW: [PATCH] usb: gadget: fastboot: improve download progress bar

[Marek Vasut]

On Friday, September 19, 2014 at 05:27:05 AM, Bo Shen wrote:
> Hi Marek,
[...]
> >> Transfer I mean here is a usb request, which trying to transfer
> >> EP_BUFFER_SIZE at one time.
> >> In my test case, sometime it transfer less than EP_BUFFER_SIZE in a usb
> >> request. So, it cause dot won't print the dot, and seems stuck. However,
> >> it will finish transfer after some time.
> > 
> > I see now. This code is really weird.
> > 
> > What would happen if the following condition is met in the code for k>0 ?
> > (download_bytes == download_size) AND (download_bytes = k *
> > BYTES_PER_DOT)
> 
> I am not fully understand what you plan to present here.
> 
> > I think the original code would happily print a dot after printing this
> > output: printf("\ndownloading of %d bytes finished\n", download_bytes);
> > 
> > Do you agree ? If yes, then I believe this code should go into the else
> > branch only.
> 
> Yes, I agree. This may happen, if the (download_bytes % BTYES_PER_DOT)
> equals to 0.
> 
> > Also, you can probably avoid the counting variable if you do something
> > like:
> > 
> > if (download_bytes / CONST != (download_bytes + transfer_size) / CONST) {
> > 
> > print(dot);
> > if (download_bytes / (74 * CONST) != ((download_bytes + transfer_size) /
> > 
> > (74 * CONST))
> > 
> > print(\n);
> > 
> > }
> > 
> > Surely, the code can be simplified . You would also need to be careful
> > about this assignment at the top of the function : download_bytes +=
> > transfer_size;
> > 
> > What do you think ?
> 
> I think this piece of code is better, which won't introduce new variable.
> 
> If no other comments, I will modify the code like this and send the v2
> patch.

Well OK then. Thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/7] spl: pbl: Add new SPL image for pblimage tool

[Huan Wang]

Hi, Albert,

> On Thu, 18 Sep 2014 13:47:13 +0800, Alison Wang 
> wrote:
> 
> > For the pblimage tool, the SPL image is splitted into 64 byte chunks,
> > and PBL needs a command for each piece. In current pblimage structure,
> > the size of the SPL image should be a fixed value. Well, for LS102xA
> > and some other ARM platforms, the size of the SPL image is changeable.
> > So a new image spl/u-boot-spl-pbl-pad.bin is built, and the size of
> it
> > is a fixed value "CONFIG_SPL_MAX_SIZE". Use it instead of
> > spl/u-boot-spl.bin for LS102xA.
> >
> > CONFIG_SPL_PBL_PAD is used to enable this function.
> >
> > Signed-off-by: Alison Wang 
> > ---
> 
> There is already a CONFIG_SPL_PAD_TO (see ./README). Can you not use
> this?
> 
[Alison Wang] I have already used CONFIG_SPL_PAD_TO to determine the offset to 
which u-boot-spl.pbl should be padded when generating u-boot-with-spl-pbl.bin. 
Well, I used CONFIG_SPL_MAX_SIZE to determine the size of 
u-boot-spl-pbl-pad.bin. u-boot-spl-pbl-pad.bin is generated by padding 
u-boot-spl.bin to CONFIG_SPL_MAX_SIZE.

Best Regards,
Alison Wang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: ls102xa: Fixed a register definition error

[Huan Wang]

Verified on board ls1021qds.

Regards,
Alison.

> -Original Message-
> From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
> Sent: Thursday, September 18, 2014 7:25 PM
> To: Tang Yuantian-B29983
> Cc: Wang Huan-B18965; Lu Jingchang-B35083; Jin Zhengxiong-R64188;
> Kushwaha Prabhakar-B32579; u-boot@lists.denx.de
> Subject: Re: [PATCH] arm: ls102xa: Fixed a register definition error
> 
> Hi Tang,
> 
> On Thu, 18 Sep 2014 17:12:06 +0800, Tang Yuantian
>  wrote:
> 
> > There are 8 SCFG_SPARECR registers in SCFG memory block, not just one.
> >
> > Signed-off-by: Tang Yuantian 
> > ---
> >  arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
> > b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
> > index 7995fe2..b5db720 100644
> > --- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
> > +++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
> > @@ -182,7 +182,7 @@ struct ccsr_scfg {
> > u32 etsecmcr;
> > u32 sdhciovserlcr;
> > u32 resv14[61];
> > -   u32 sparecr;
> > +   u32 sparecr[8];
> >  };
> >
> >  /* Clocking */
> 
> Obviously the original code was not problematic as sparecr was not used.
> Is your change dictated by a patch or series that you are preparing and
> that will use sparecr?
> 
> Amicalement,
> --
> Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 6/7] arm: ls102xa: Add SD boot support for LS1021AQDS board

[Alison Wang]

Hi, Albert,

On Thu, 18 Sep 2014 13:47:18 +0800, Alison Wang 
wrote:

> +
> + . = ALIGN(4);
> + .u_boot_list : {
> + KEEP(*(SORT(.u_boot_list*_i2c_*)));
> + }

IS this required? And if it is, could it not be added to the
arch/arm/cpu/u-boot-spl.lds file? This way you would not need an .lds file
at all.

[Alison Wang] Yes, it is required. I would like to add it in
arch/arm/cpu/u-boot-spl.lds. I was not sure adding it in
arch/arm/cpu/u-boot-spl.lds is acceptable or not.

Alison



--
View this message in context: 
http://u-boot.10912.n7.nabble.com/PATCH-0-7-Add-SD-boot-support-for-LS1021AQDS-TWR-board-tp189678p189759.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Need help with u-boot problem with usb-keyboard / kvm switch

[Bo Shen]

Hi All,

On 09/18/2014 03:29 AM, Eric Nelson wrote:

Hi Hans,

On 09/17/2014 12:11 PM, Hans de Goede wrote:

Hi Marek, et al,

I'm working on cleaning up Luc's hdmi out support patchset for
sunxi.

As part of this I want to also add support for usb keyboards,
so as to get a full console without needing to solder wires
to testpoints on some boards :)

So when I plug in the usb coming from my kvm I get this:

(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
3 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found

And the usb keyboard does not work.

If I plug in a single usb-2 hub (no ohci support for sunxi in u-boot
yet), then things do work, but after a few minutes of inactivity the
usb code starts spamming the console with:

EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
...

Could this be a problem with the phy settings (iow a sunxi specific
problem)?



Probably not.

We've seen the same thing on SABRE Lite and Nitrogen6X boards.

U-Boot > usb start ; setenv stdin serial,usbkbd
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
USB1:   USB EHCI 1.00
scanning bus 1 for devices... EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
6 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
scanning usb for ethernet devices... 0 Ethernet Device(s) found
Timeout poll on interrupt endpoint
Failed to get keyboard state from device 1c4f:0002
U-Boot > usb tree
USB device tree:
   1  Hub (480 Mb/s, 0mA)
   |  u-boot EHCI Host Controller
   |
   +-2  Mass Storage (480 Mb/s, 100mA)
Generic Mass Storage 4A3709D5

   3  Hub (480 Mb/s, 0mA)
   |  u-boot EHCI Host Controller
   |
   +-4  Hub (480 Mb/s, 2mA)
 |
 +-5  Human Interface (1.5 Mb/s, 100mA)
 |Logitech USB Optical Mouse
 |
 +-6  Hub (480 Mb/s, 100mA)
 | |   USB 2.0 Hub
 | |
 | +-7  Human Interface (1.5 Mb/s, 98mA)
 |  USB USB Keykoard
 |
 +-8   (12 Mb/s, 100mA)

Oddly, the issue seems to be specific to **some** USB keyboards.

We have some (mostly older) USB keyboards that just work and
have had investigation on our to-do list for quite some
time now.

I was going to start with a question to the list:

Is anyone else using USB keyboard support?


I use the USB keyboard with following hack patch (which based on 
v2013.04), then it works well on my side.


--->8---
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index bc17b85..b74bfd7 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -515,6 +515,7 @@ static inline int sohci_return_job(struct ohci *hc, 
urb_priv_t *urb)
ohci_readl(®s->intrdisable); /* PCI posting 
flush */

}
urb->actual_length = 0;
+#if 0
td_submit_job(
urb->dev,
urb->pipe,
@@ -523,6 +524,8 @@ static inline int sohci_return_job(struct ohci *hc, 
urb_priv_t *urb)

NULL,
urb,
urb->interval);
+#endif
+   urb_free_priv(urb);
break;
case PIPE_CONTROL:
case PIPE_BULK:
---8<---


USB mass storage seems to be pretty reliable. We have
folks using it as an alternate boot for emergency
situations.

Regards,


Eric


Best Regards,
Bo Shen

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] FW: [PATCH] usb: gadget: fastboot: improve download progress bar

[Bo Shen]

Hi Marek,

On 09/18/2014 05:59 PM, Marek Vasut wrote:

On Thursday, September 18, 2014 at 10:11:49 AM, Bo Shen wrote:

Hi Marek,

On 09/18/2014 10:32 AM, Marek Vasut wrote:

On Thursday, September 18, 2014 at 03:34:18 AM, Bo Shen wrote:

Hi Marek,

On 09/17/2014 07:16 PM, Marek Vasut wrote:

On Wednesday, September 17, 2014 at 12:28:57 PM, Bo Shen wrote:

Hi Marek,

On 09/17/2014 06:10 PM, Marek Vasut wrote:

On Wednesday, September 17, 2014 at 09:43:56 AM, Bo Shen wrote:

+CC Lukasz, this is his turf.


When download is ongoing, if the actual size of one transfer is
not the same as BTYES_PER_DOT, which will cause the dot won't
print anymore. Then it will let the user thinking it is stuck,
actually it is transfering without dot printed.

So, improve the method to show the progress bar (print dot).

Signed-off-by: Bo Shen 
---

 drivers/usb/gadget/f_fastboot.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/f_fastboot.c
b/drivers/usb/gadget/f_fastboot.c index 7a1acb9..2f13bf0 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -51,6 +51,7 @@ static inline struct f_fastboot
*func_to_fastboot(struct usb_function *f) static struct
f_fastboot *fastboot_func;

 static unsigned int download_size;
 static unsigned int download_bytes;

+static unsigned int num_of_dot;

 static struct usb_endpoint_descriptor fs_ep_in = {

.bLength= USB_DT_ENDPOINT_SIZE,

@@ -414,9 +415,10 @@ static void rx_handler_dl_image(struct
usb_ep *ep, struct usb_request *req) req->length = ep->maxpacket;

}

-   if (download_bytes && !(download_bytes % BYTES_PER_DOT)) {
+   if (download_bytes && ((download_bytes / BYTES_PER_DOT) >
num_of_dot)) { +num_of_dot = download_bytes /

BYTES_PER_DOT;


putc('.');

-   if (!(download_bytes % (74 * BYTES_PER_DOT)))
+   if (!(num_of_dot % 74))

putc('\n');

}
req->actual = 0;

@@ -431,6 +433,7 @@ static void cb_download(struct usb_ep *ep,
struct usb_request *req) strsep(&cmd, ":");

download_size = simple_strtoul(cmd, NULL, 16);
download_bytes = 0;

+   num_of_dot = 0;


Make it a 'download_total' and log the total amount of bytes
transferred please, that way it can be re-used for other purposes
in the future ; for example for printing how much data were
already transferred ;-)


The download_bytes record the total amount of bytes transferred.
And the download_bytes will print after finishing transfer.


So why can this not be used to indicate the total progress ? Because
the transfeer speed is variating too much ?


As I described in the commit message. If the transfer length is not
exactly the same as the request length, then the old method

 "download_bytes % BYTES_PER_DOT"

won't be 0 anymore, so for the following transfer, it won't print dot
anymore.


And can you not reset the "download_bytes" for each transfer ?


No, I don't reset the "download_bytes" for each transfer. It reset the
"download_bytes" before transfer start.
The "download_bytes" is increase in rx_handler_dl_image function.


OK


Maybe we're not even aligned on what "transfer" means, so we might want
to sync on this word first. What does "transfer" mean in this case?


Transfer I mean here is a usb request, which trying to transfer
EP_BUFFER_SIZE at one time.
In my test case, sometime it transfer less than EP_BUFFER_SIZE in a usb
request. So, it cause dot won't print the dot, and seems stuck. However,
it will finish transfer after some time.


I see now. This code is really weird.

What would happen if the following condition is met in the code for k>0 ?
(download_bytes == download_size) AND (download_bytes = k * BYTES_PER_DOT)


I am not fully understand what you plan to present here.


I think the original code would happily print a dot after printing this output:
printf("\ndownloading of %d bytes finished\n", download_bytes);

Do you agree ? If yes, then I believe this code should go into the else branch
only.


Yes, I agree. This may happen, if the (download_bytes % BTYES_PER_DOT) 
equals to 0.



Also, you can probably avoid the counting variable if you do something like:

if (download_bytes / CONST != (download_bytes + transfer_size) / CONST) {
print(dot);
if (download_bytes / (74 * CONST) != ((download_bytes + transfer_size) /
(74 * CONST))
print(\n);
}

Surely, the code can be simplified . You would also need to be careful about
this assignment at the top of the function : download_bytes += transfer_size;

What do you think ?



I think this piece of code is better, which won't introduce new variable.

If no other comments, I will modify the code like this and send the v2 
patch.


Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boo

Re: [U-Boot] [PATCH 0/2] sama5d3xek: get GMAC working

[Bo Shen]

Hi Andreas,

On 09/19/2014 05:46 AM, Andreas Bießmann wrote:


I had a strange behaviour for my sama5d34ek board which could sometimes not get
up GMAC in U-Boot. It turned out, that we missed to initialize the PHY
correctly.

Bo, could you please verify correct behaviour on 100MiB devices like
sama5d31ek?


Test OK on sama5d31ek board, you can add Tested-by tag for this patch 
series.


Tested-by: Bo Shen 

Thanks.



Andreas Bießmann (2):
   macb: simplify gmac initialisation
   sama5d3xek: run PHY's config

  board/atmel/sama5d3xek/sama5d3xek.c |   29 -
  drivers/net/macb.c  |   25 -
  2 files changed, 28 insertions(+), 26 deletions(-)



Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/3] compiler_gcc: prevent redefining attributes

[Masahiro Yamada]

On Thu, 18 Sep 2014 20:10:27 +0200
Jeroen Hofstee  wrote:

> The libc headers on FreeBSD and likely related projects as well contain an
> header file, cdefs.h which provides similiar functionality as 
> linux/compiler.h.
> It provides compiler independent defines like __weak __packed, to allow
> compiling with multiple compilers which might have a different syntax for such
> extension.
> 
> Since that header file is included in multiple standard headers, like stddef.h
> and stdarg.h, multiple definitions of those defines will be present if both 
> are
> included. When compiling u-boot the compiler will warn about it hundreds of
> times since e.g. common.h will include both files indirectly.
> 
> commit 7ea50d52849fe8ffa5b5b74c979b60b1045d6fc9 "compiler_gcc: do not redefine
> __gnu_attributes" prevented such redefinitions, but this was undone by commit
> fb8ffd7cfc68b3dc44e182356a207d784cb30b34 "compiler*.h: sync
> include/linux/compiler*.h with Linux 3.16".
> 
> Add the checks back where necessary to prevent such warnings.
> 
> As the original patch this checkpatch warning is ignored:
> "WARNING: Adding new packed members is to be done with care"
> 
> Cc: Masahiro Yamada 
> Cc: Tom Rini 
> Signed-off-by: Jeroen Hofstee 


Acked-by: Masahiro Yamada 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] ARM: HYP/non-sec: Make variable gic_dist_addr as a local one

[Tang Yuantian]

Defining variable gic_dist_addr as a globe one prevents some
functions, which use it, from being used before relocation
which is the case in the deep sleep resume process on Freescale
SoC platforms.
Besides, we can always get the GIC base address by calling
get_gicd_base_address() without referring gic_dist_addr.

Signed-off-by: Tang Yuantian 
---
v2:
- refine the subjuct and commit message.

 arch/arm/cpu/armv7/virt-v7.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c
index 651ca40..b69fd37 100644
--- a/arch/arm/cpu/armv7/virt-v7.c
+++ b/arch/arm/cpu/armv7/virt-v7.c
@@ -15,8 +15,6 @@
 #include 
 #include 
 
-unsigned long gic_dist_addr;
-
 static unsigned int read_id_pfr1(void)
 {
unsigned int reg;
@@ -68,6 +66,12 @@ static void kick_secondary_cpus_gic(unsigned long gicdaddr)
 
 void __weak smp_kick_all_cpus(void)
 {
+   unsigned long gic_dist_addr;
+
+   gic_dist_addr = get_gicd_base_address();
+   if (gic_dist_addr == -1)
+   return;
+
kick_secondary_cpus_gic(gic_dist_addr);
 }
 
@@ -75,6 +79,7 @@ int armv7_init_nonsec(void)
 {
unsigned int reg;
unsigned itlinesnr, i;
+   unsigned long gic_dist_addr;
 
/* check whether the CPU supports the security extensions */
reg = read_id_pfr1();
-- 
2.1.0.27.g96db324

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: HYP/non-sec: Make a variable as a local one

[Yuantian Tang]

> -Original Message-
> From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
> Sent: Thursday, September 18, 2014 5:44 PM
> To: Tang Yuantian-B29983
> Cc: andre.przyw...@linaro.org; i...@hellion.org.uk; marc.zyng...@arm.com;
> u-boot@lists.denx.de; Jin Zhengxiong-R64188
> Subject: Re: [PATCH] ARM: HYP/non-sec: Make a variable as a local one
> 
> Hi Tang,
> 
> Please fix subject / commit summary to indicate which variable is to be made
> local.
> 
> On Thu, 18 Sep 2014 17:12:34 +0800, Tang Yuantian
>  wrote:
> 
> > Defining variable gic_dist_addr as a globe one prevents some
> > functions, which use this variable, from being used before relocation
> > which happened in the deep sleep resume process on Freescale SoC
> > platforms.
> >
> > Signed-off-by: Tang Yuantian 
> > ---
> >  arch/arm/cpu/armv7/virt-v7.c | 9 +++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/cpu/armv7/virt-v7.c
> > b/arch/arm/cpu/armv7/virt-v7.c index 651ca40..b69fd37 100644
> > --- a/arch/arm/cpu/armv7/virt-v7.c
> > +++ b/arch/arm/cpu/armv7/virt-v7.c
> > @@ -15,8 +15,6 @@
> >  #include 
> >  #include 
> >
> > -unsigned long gic_dist_addr;
> > -
> >  static unsigned int read_id_pfr1(void)  {
> > unsigned int reg;
> > @@ -68,6 +66,12 @@ static void kick_secondary_cpus_gic(unsigned long
> > gicdaddr)
> >
> >  void __weak smp_kick_all_cpus(void)
> >  {
> > +   unsigned long gic_dist_addr;
> > +
> > +   gic_dist_addr = get_gicd_base_address();
> > +   if (gic_dist_addr == -1)
> > +   return;
> > +
> > kick_secondary_cpus_gic(gic_dist_addr);
> >  }
> >
> > @@ -75,6 +79,7 @@ int armv7_init_nonsec(void)  {
> > unsigned int reg;
> > unsigned itlinesnr, i;
> > +   unsigned long gic_dist_addr;
> >
> > /* check whether the CPU supports the security extensions */
> > reg = read_id_pfr1();
> 
> Did you check that the global was not used as a common variable between the
> functions?
> 
Yes, I grep it globally. It was referred by only 2 places which are both in 
virt-v7.c file.

I will fix the subject.

Thanks,
Yuantian

> Amicalement,
> --
> Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: ls102xa: Fixed a register definition error

[Yuantian Tang]

> -Original Message-
> From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
> Sent: Thursday, September 18, 2014 7:25 PM
> To: Tang Yuantian-B29983
> Cc: Wang Huan-B18965; Lu Jingchang-B35083; Jin Zhengxiong-R64188;
> Kushwaha Prabhakar-B32579; u-boot@lists.denx.de
> Subject: Re: [PATCH] arm: ls102xa: Fixed a register definition error
> 
> Hi Tang,
> 
> On Thu, 18 Sep 2014 17:12:06 +0800, Tang Yuantian
>  wrote:
> 
> > There are 8 SCFG_SPARECR registers in SCFG memory block, not just one.
> >
> > Signed-off-by: Tang Yuantian 
> > ---
> >  arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
> > b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
> > index 7995fe2..b5db720 100644
> > --- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
> > +++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
> > @@ -182,7 +182,7 @@ struct ccsr_scfg {
> > u32 etsecmcr;
> > u32 sdhciovserlcr;
> > u32 resv14[61];
> > -   u32 sparecr;
> > +   u32 sparecr[8];
> >  };
> >
> >  /* Clocking */
> 
> Obviously the original code was not problematic as sparecr was not used. Is 
> your
> change dictated by a patch or series that you are preparing and that will use
> sparecr?
> 
Yes, they will be used by deep sleep patches I am preparing.

Thanks,
Yuantian

> Amicalement,
> --
> Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] compiler.h: remove duplicated uninitialized_var

[Tom Rini]

On Thu, Sep 18, 2014 at 11:39:44AM +0200, Jeroen Hofstee wrote:
> Hello Masahiro,
> 
> On 18-09-14 04:14, Masahiro Yamada wrote:
> >>Since clang has a different definition for uninitialized_var
> >>it will complain that it is redefined in include/compiler.h.
> >>Since these are already defined in linux/compiler.h just remove
> >>this instance.
> >>
> >>Cc: Masahiro Yamada 
> >>Cc: Tom Rini 
> >>Signed-off-by: Jeroen Hofstee 
> >
> >
> >I don't mind this patch but it has made me realize
> >another problem.
> >
> >
> >We have both include/compiler.h and include/linux/compiler.h.
> >Some sources use tha former and others use the latter.
> >
> >I don't know how to use the right one in the right place.
> 
> no me neither, although it seems arch / drivers tend to use
> linux/compiler.h more while tools include compiler.h more.

My first guess is that we can't as easily throw  into
tools and thus need that around just for tools.  Perhaps we should note
as much in  and fix regular code to use  ?

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] sama5d3xek: run PHY's config

[Andreas Bießmann]

Signed-off-by: Andreas Bießmann 
Cc: Bo Shen 

---

 board/atmel/sama5d3xek/sama5d3xek.c |   29 -
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/board/atmel/sama5d3xek/sama5d3xek.c 
b/board/atmel/sama5d3xek/sama5d3xek.c
index f53754b..ca4f79d 100644
--- a/board/atmel/sama5d3xek/sama5d3xek.c
+++ b/board/atmel/sama5d3xek/sama5d3xek.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -273,15 +274,25 @@ int dram_init(void)
 
 int board_phy_config(struct phy_device *phydev)
 {
-   /* rx data delay */
-   ksz9021_phy_extended_write(phydev,
-  MII_KSZ9021_EXT_RGMII_RX_DATA_SKEW, 0x);
-   /* tx data delay */
-   ksz9021_phy_extended_write(phydev,
-  MII_KSZ9021_EXT_RGMII_TX_DATA_SKEW, 0x);
-   /* rx/tx clock delay */
-   ksz9021_phy_extended_write(phydev,
-  MII_KSZ9021_EXT_RGMII_CLOCK_SKEW, 0xf2f4);
+   /* board specific timings for GMAC */
+   if (has_gmac()) {
+   /* rx data delay */
+   ksz9021_phy_extended_write(phydev,
+  MII_KSZ9021_EXT_RGMII_RX_DATA_SKEW,
+  0x);
+   /* tx data delay */
+   ksz9021_phy_extended_write(phydev,
+  MII_KSZ9021_EXT_RGMII_TX_DATA_SKEW,
+  0x);
+   /* rx/tx clock delay */
+   ksz9021_phy_extended_write(phydev,
+  MII_KSZ9021_EXT_RGMII_CLOCK_SKEW,
+  0xf2f4);
+   }
+
+   /* always run the PHY's config routine */
+   if (phydev->drv->config)
+   return phydev->drv->config(phydev);
 
return 0;
 }
-- 
1.7.10.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/2] macb: simplify gmac initialisation

[Andreas Bießmann]

Signed-off-by: Andreas Bießmann 
Cc: Joe Hershberger 
Cc: Bo Shen 
---

 drivers/net/macb.c |   25 -
 1 file changed, 8 insertions(+), 17 deletions(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 01a94a4..375c8a4 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -479,31 +479,22 @@ static int macb_phy_init(struct macb_device *macb)
/* First check for GMAC */
if (macb_is_gem(macb)) {
lpa = macb_mdio_read(macb, MII_STAT1000);
-   if (lpa & (1 << 11)) {
-   speed = 1000;
-   duplex = 1;
-   } else {
-  if (lpa & (1 << 10)) {
-   speed = 1000;
-   duplex = 1;
-   } else {
-   speed = 0;
-   }
-   }
 
-   if (speed == 1000) {
-   printf("%s: link up, %dMbps %s-duplex (lpa: 0x%04x)\n",
+   if (lpa & (LPA_1000FULL | LPA_1000HALF)) {
+   duplex = ((lpa & LPA_1000FULL) ? 1 : 0);
+
+   printf("%s: link up, 1000Mbps %s-duplex (lpa: 
0x%04x)\n",
   netdev->name,
-  speed,
   duplex ? "full" : "half",
   lpa);
 
ncfgr = macb_readl(macb, NCFGR);
-   ncfgr &= ~(GEM_BIT(GBE) | MACB_BIT(SPD) | MACB_BIT(FD));
-   if (speed)
-   ncfgr |= GEM_BIT(GBE);
+   ncfgr &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
+   ncfgr |= GEM_BIT(GBE);
+
if (duplex)
ncfgr |= MACB_BIT(FD);
+
macb_writel(macb, NCFGR, ncfgr);
 
return 1;
-- 
1.7.10.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/2] sama5d3xek: get GMAC working

[Andreas Bießmann]

I had a strange behaviour for my sama5d34ek board which could sometimes not get
up GMAC in U-Boot. It turned out, that we missed to initialize the PHY
correctly.

Bo, could you please verify correct behaviour on 100MiB devices like
sama5d31ek?


Andreas Bießmann (2):
  macb: simplify gmac initialisation
  sama5d3xek: run PHY's config

 board/atmel/sama5d3xek/sama5d3xek.c |   29 -
 drivers/net/macb.c  |   25 -
 2 files changed, 28 insertions(+), 26 deletions(-)

-- 
1.7.10.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] compulab: eeprom: add default eeprom bus

[Albert ARIBAUD]

Hi Nikita,

On Thu, 18 Sep 2014 16:21:07 +0300, Nikita Kiryanov
 wrote:

> Hi ALbert,
> 
> On 18/09/14 15:26, Albert ARIBAUD wrote:
> > Hi Igor,
> >
> > On Wed, 17 Sep 2014 17:18:49 +0300, Igor Grinberg
> >  wrote:
> >
> >> On 09/17/14 15:59, Nikita Kiryanov wrote:
> >>> Add default eeprom bus setting.
> >>> This addresses the trimslice compile error that was introduced
> >>> with the addition of this setting.
> >>>
> >>> Cc: Albert ARIBAUD 
> >>> Cc: Igor Grinberg 
> >>> Signed-off-by: Nikita Kiryanov 
> >>
> >> Acked-by: Igor Grinberg 
> >>
> >> Albert, this should be a temporary fix to not break the trimslice support.
> >> We intend to rework this while switching Kconfig for all boards.
> >>
> >> Thanks!
> >>
> >>> ---
> >>>   board/compulab/common/eeprom.c | 4 
> >>>   1 file changed, 4 insertions(+)
> >>>
> >>> diff --git a/board/compulab/common/eeprom.c 
> >>> b/board/compulab/common/eeprom.c
> >>> index 85442cd..2df3ada 100644
> >>> --- a/board/compulab/common/eeprom.c
> >>> +++ b/board/compulab/common/eeprom.c
> >>> @@ -15,6 +15,10 @@
> >>>   # define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1
> >>>   #endif
> >>>
> >>> +#ifndef CONFIG_SYS_I2C_EEPROM_BUS
> >>> +#define CONFIG_SYS_I2C_EEPROM_BUS0
> >>> +#endif
> >>> +
> >>>   #define EEPROM_LAYOUT_VER_OFFSET44
> >>>   #define BOARD_SERIAL_OFFSET 20
> >>>   #define BOARD_SERIAL_OFFSET_LEGACY  8
> >>>
> >
> > a 'git grep CONFIG_SYS_I2C_EEPROM_BUS' shows that all values for
> > CONFIG_SYS_I2C_EEPROM_BUS are set in include/configs/*.h.
> >
> > Therefore I would prefer that the temporary fix be in
> > include/configs/trimslice.h header file too.
> >
> 
> Given that trimslice does not use the eeprom code, I feel that
> it's cleaner to not populate its config file with irrelevant
> defines. It's also consistent with the way CONFIG_SYS_I2C_EEPROM_ADDR
> and CONFIG_SYS_I2C_EEPROM_ADDR_LEN are handled.

Makes sense enough.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 1/3] compiler_gcc: prevent redefining attributes

[Jeroen Hofstee]

The libc headers on FreeBSD and likely related projects as well contain an
header file, cdefs.h which provides similiar functionality as linux/compiler.h.
It provides compiler independent defines like __weak __packed, to allow
compiling with multiple compilers which might have a different syntax for such
extension.

Since that header file is included in multiple standard headers, like stddef.h
and stdarg.h, multiple definitions of those defines will be present if both are
included. When compiling u-boot the compiler will warn about it hundreds of
times since e.g. common.h will include both files indirectly.

commit 7ea50d52849fe8ffa5b5b74c979b60b1045d6fc9 "compiler_gcc: do not redefine
__gnu_attributes" prevented such redefinitions, but this was undone by commit
fb8ffd7cfc68b3dc44e182356a207d784cb30b34 "compiler*.h: sync
include/linux/compiler*.h with Linux 3.16".

Add the checks back where necessary to prevent such warnings.

As the original patch this checkpatch warning is ignored:
"WARNING: Adding new packed members is to be done with care"

Cc: Masahiro Yamada 
Cc: Tom Rini 
Signed-off-by: Jeroen Hofstee 
---
changes since v1:
  As requested by Masahiro, elaborate a bit about what cdefs.h is and how these
  warnings are caused. Only this patch is reposted.
---
 include/linux/compiler-gcc.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 02ae99e..e057bd2 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -64,8 +64,12 @@
 #endif
 
 #define __deprecated   __attribute__((deprecated))
+#ifndef __packed
 #define __packed   __attribute__((packed))
+#endif
+#ifndef __weak
 #define __weak __attribute__((weak))
+#endif
 
 /*
  * it doesn't make sense on ARM (currently the only user of __naked) to trace
@@ -91,8 +95,12 @@
  * would be.
  * [...]
  */
+#ifndef __pure
 #define __pure __attribute__((pure))
+#endif
+#ifndef __aligned
 #define __aligned(x)   __attribute__((aligned(x)))
+#endif
 #define __printf(a, b) __attribute__((format(printf, a, b)))
 #define __scanf(a, b)  __attribute__((format(scanf, a, b)))
 #define  noinline  __attribute__((noinline))
@@ -115,4 +123,6 @@
  */
 #define uninitialized_var(x) x = x
 
+#ifndef __always_inline
 #define __always_inlineinline __attribute__((always_inline))
+#endif
-- 
2.1.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 00/40] ARM: tegra: Add PCIe support

[Simon Glass]

HI Albert,

On 18 September 2014 02:43, Albert ARIBAUD 
wrote:

> Hi Simon,
>
> On Thu, 11 Sep 2014 13:20:03 -0600, Simon Glass 
> wrote:
>
> > Hi,
> >
> > On 11 September 2014 10:17, Stephen Warren 
> wrote:
> > > On 09/11/2014 10:00 AM, Albert ARIBAUD wrote:
> > >>
> > >> Hi Thierry,
> > >>
> > >> On Tue, 26 Aug 2014 17:33:48 +0200, Thierry Reding
> > >>  wrote:
> > >>
> > >>> From: Thierry Reding 
> > >>
> > >>
> > >> Note: this series was split over several custodians (including
> myself).
> > >> It might thus get applied piecewise... Shouldn't it rather be assigned
> > >> a single custodian -with others giving their Ack) and be applied as a
> > >> whole? And yes, I'm ok with getting all the pieces.
> > >
> > >
> > > Yes, applying it all in one place would probably make sense.
> > >
> > > IIRC, Simon Glass already applied some of the DT patches early in the
> > > series? I CC'd him to check,
> >
> > Yes I applied the fdt patches to u-boot-fdt/next. I can do a pull
> > request to ARM if that helps, or you can just grab them.
>
> Well, the idea was applying it all in one place :) and I don't like the
> idea of pulling the fdt tree into the arm tree, so I'll pick them up,
> but please give your Acked-by to them, so that PW sees it and puts it in
> when I apply the patches.
>

They should all be acked already (I did that before I pulled them in) so
please go ahead.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] dm: avoid dev->req_seq overflow

[Simon Glass]

Hi Robert,

On 18 September 2014 09:13, Robert Baldyga  wrote:

> Since dev->req_seq value is initialized from "reg" property of fdt node,
> there is posibility, that address value contained in fdt is greater than
> INT_MAX, and then value in dev->req_seq is negative which led to probe()
> fail.
>
> This patch fix this problem by ensuring that req_seq is positive, unless
> it's one of errno codes.
>

Wouldn't this be a bug in the device tree file? What does it mean to have a
-ve value?


> Signed-off-by: Robert Baldyga 
> ---
>  drivers/core/device.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/core/device.c b/drivers/core/device.c
> index 166b073..35ffce0 100644
> --- a/drivers/core/device.c
> +++ b/drivers/core/device.c
> @@ -107,6 +107,8 @@ int device_bind(struct udevice *parent, struct driver
> *drv, const char *name,
>  * when the device is probed.
>  */
> dev->req_seq = fdtdec_get_int(gd->fdt_blob, of_offset, "reg", -1);
> +   if (!IS_ERR_VALUE(dev->req_seq))
> +   dev->req_seq &= INT_MAX;
> dev->seq = -1;
> if (uc->uc_drv->name && of_offset != -1) {
> fdtdec_get_alias_seq(gd->fdt_blob, uc->uc_drv->name,
> of_offset,
> --
> 1.9.1
>
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 8/8] ARMv8: PSCI: Enable SMC

[arnab.b...@freescale.com]

> -Original Message-
> From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
> Sent: Thursday, September 18, 2014 2:48 PM
> To: Basu Arnab-B45036
> Cc: marc.zyng...@arm.com; mark.rutl...@arm.com; Sun York-R58495; Yoder
> Stuart-B08248; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH 8/8] ARMv8: PSCI: Enable SMC
> 
> Hi Arnab,
> 
> On Thu, 28 Aug 2014 02:00:01 +0530, Arnab Basu 
> wrote:
> 
> > Enable the SMC instruction so that the kernel can use the psci code
> >
> > Signed-off-by: Arnab Basu 
> > Reviewed-by: Bhupesh Sharma 
> > Cc: Marc Zyngier 
> > ---
> >  arch/arm/include/asm/macro.h |4 
> >  1 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/macro.h
> > b/arch/arm/include/asm/macro.h index 0009c28..94a1e68 100644
> > --- a/arch/arm/include/asm/macro.h
> > +++ b/arch/arm/include/asm/macro.h
> > @@ -106,7 +106,11 @@ lr .reqx30
> >  .endm
> >
> >  .macro armv8_switch_to_el2_m, xreg1
> > +#ifdef CONFIG_ARMV8_PSCI
> > +   mov \xreg1, #0x531  /* Non-secure EL0/EL1 | HVC | 64bit EL2 */
> > +#else
> > mov \xreg1, #0x5b1  /* Non-secure EL0/EL1 | HVC | 64bit EL2 */
> 
> The 'mov' lines have different constant arguments in the instruction;
> their explanatory comments should not be the same.
> 

Right, I'll fix the comment.

Thanks
Arnab

> > +#endif
> > msr scr_el3, \xreg1
> > msr cptr_el3, xzr   /* Disable coprocessor traps to EL3 */
> > mov \xreg1, #0x33ff
> 
> 
> Amicalement,
> --
> Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] compulab trimslice build error due to 52658fda7abc ("compulab: eeprom: add support for defining eeprom i2c bus")

[Stephen Warren]

After commit 52658fda7abc ("compulab: eeprom: add support for defining 
eeprom i2c bus"), the trimslice board fails to build with:


.../board/compulab/common/eeprom.c: In function ‘cl_eeprom_read’:
.../board/compulab/common/eeprom.c:37:24: error: 
‘CONFIG_SYS_I2C_EEPROM_BUS’ undeclared (first use in this function)
.../board/compulab/common/eeprom.c:37:24: note: each undeclared 
identifier is reported only once for each function it appears in


I have no idea if this EEPROM code should even run on TrimSlice or not. 
Can you take a look at the correct fix?

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards

[Siarhei Siamashka]

On Sun, 27 Jul 2014 23:25:21 +0200
Hans de Goede  wrote:

> Add support for boards which I own and which already have a dts file in the
> upstream kernel.

Hi Hans,

It's good to know that you have all this hardware and can take care of
maintaining it.

> Signed-off-by: Henrik Nordstrom 
> Signed-off-by: Stefan Roese 
> Signed-off-by: Hans de Goede 
> ---
>  board/sunxi/Makefile|  6 ++
>  board/sunxi/dram_a10_olinuxino_l.c  | 31 +++
>  board/sunxi/dram_sun4i_360_1024_iow16.c | 31 +++
>  board/sunxi/dram_sun4i_360_1024_iow8.c  | 31 +++
>  board/sunxi/dram_sun4i_360_512.c| 31 +++
>  board/sunxi/dram_sun4i_384_1024_iow8.c  | 31 +++
>  boards.cfg  |  6 ++
>  7 files changed, 167 insertions(+)
>  create mode 100644 board/sunxi/dram_a10_olinuxino_l.c
>  create mode 100644 board/sunxi/dram_sun4i_360_1024_iow16.c
>  create mode 100644 board/sunxi/dram_sun4i_360_1024_iow8.c
>  create mode 100644 board/sunxi/dram_sun4i_360_512.c
>  create mode 100644 board/sunxi/dram_sun4i_384_1024_iow8.c
> 
> diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
> index 03f55cc..b1db5d9 100644
> --- a/board/sunxi/Makefile
> +++ b/board/sunxi/Makefile
> @@ -11,8 +11,14 @@
>  obj-y+= board.o
>  obj-$(CONFIG_SUNXI_GMAC) += gmac.o
>  obj-$(CONFIG_SUNXI_AHCI) += ahci.o
> +obj-$(CONFIG_A10_OLINUXINO_L)+= dram_a10_olinuxino_l.o

Which revision of A10-OLinuXino-LIME do you have? Revision A is known
to have troubles running stable at 1008MHz CPU clock speed, as confirmed
on a sample set of two boards (mine and Oliver Schinagl's):
https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04343.html

A bunch of revision C boards were all fine in Oliver's tests. And
nobody has ever tested revision B so far, so we have no idea whether
it is stable or not. A mysterious thing is that the Olimex
representatives on IRC were not aware of any fixes of this kind
applied to the PCB.

My understanding is that the revision A was just a small pre-production
batch, donated by OLIMEX to a number of open source developers. Some of
these boards were distributed at FOSDEM. I'm not sure if we should
really worry about the reliability of the revision A, because none of
the 'normal' customers probably have such boards. We only need to
clarify the status of revision B.

But if we want to support the revision A too, then it probably needs
its own config, which would somehow restrict the CPU clock speed.

>  obj-$(CONFIG_A13_OLINUXINOM) += dram_a13_oli_micro.o
> +obj-$(CONFIG_BA10_TV_BOX)+= dram_sun4i_384_1024_iow8.o
>  obj-$(CONFIG_CUBIEBOARD) += dram_cubieboard.o
>  obj-$(CONFIG_CUBIEBOARD2)+= dram_cubieboard2.o
>  obj-$(CONFIG_CUBIETRUCK) += dram_cubietruck.o
> +obj-$(CONFIG_MELE_A1000) += dram_sun4i_360_512.o
> +obj-$(CONFIG_MELE_A1000G)+= dram_sun4i_360_1024_iow8.o
> +obj-$(CONFIG_MINI_X) += dram_sun4i_360_512.o
> +obj-$(CONFIG_MINI_X_1GB) += dram_sun4i_360_1024_iow16.o
>  obj-$(CONFIG_R7DONGLE)   += dram_r7dongle.o
> diff --git a/board/sunxi/dram_a10_olinuxino_l.c 
> b/board/sunxi/dram_a10_olinuxino_l.c
> new file mode 100644
> index 000..24a1bd9
> --- /dev/null
> +++ b/board/sunxi/dram_a10_olinuxino_l.c
> @@ -0,0 +1,31 @@
> +/* this file is generated, don't edit it yourself */
> +
> +#include 
> +#include 
> +
> +static struct dram_para dram_para = {
> + .clock = 480,
> + .type = 3,
> + .rank_num = 1,
> + .density = 4096,
> + .io_width = 16,
> + .bus_width = 16,
> + .cas = 6,

The CAS=6 is not quite right for the 480MHz DRAM clock speed if we
are dealing with the typical DDR3 chips, with the timings mostly
representing the standard JEDEC speed bins.

CAS=6 is good up to 400MHz. CAS=7 is good up to 533MHz. And CAS=9 is
good up to 667MHz.

> + .zq = 123,
> + .odt_en = 0,
> + .size = 512,
> + .tpr0 = 0x30926692,
> + .tpr1 = 0x1090,
> + .tpr2 = 0x1a0c8,

The .tpr0/.tpr1/.tpr2 settings here are simply using the default reset
values of the DRAM controller hardware registers. Which happen to
match the DDR2-800E speed bin, as identified by Jens Kuske:
https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg03548.html

Either way, these settings are outside of the valid range when running
at 480MHz (which would be something like DDR3-960 in our case).

The fundamental problem here is that u-boot-sunxi essentially trusted
the device manufacturers to pick the correct DRAM settings. However
it looks like the device manufacturers did not have any proper DRAM
documentation either. And they just ended up picking some random
settings, which seemed to kinda work (and then copy/pasted these
settings from one device to another with minor variation). Also
without doubt, they were all under a heavy time-to-market pressure.

Now thi

Re: [U-Boot] A minor question on a Driver Model function

[Bill Pringlemeir]

>>> On 12 September 2014 05:25, Masahiro Yamada
>>>  wrote:
>>
>>> I have a qustion about lists_driver_lookup_name() function.

> On 09/14/14 21:28, Simon Glass wrote:
>>
> I would suggest still using strncmp as it is safer,
> but count also the '\0', so something like:
>>
>> On 17 Sep 2014, grinb...@compulab.co.il wrote:
>>
 Why safer?
>>
 Could you give me more detailed explanation?
>>
>>> On 09/17/14 11:18, Masahiro Yamada wrote:
>>
>>> Well, I'm not an expert in s/w security, but I'll try to explain...
>>
>> [snip]
>>
>>> But, again, I'm not an expert in this area, so its only a
>>> suggestion.
>>

> On 09/17/14 18:25, Bill Pringlemeir wrote:

>> I thought it was fairly apparent that the current code supports
>> passing a string that is *NOT* null terminated.  This can be
>> convenient if you extract a sub-string from a command line and do not
>> need to make a copy that is NULL terminate or perform 'strtok()' type
>> magic.

On 18 Sep 2014, grinb...@compulab.co.il wrote:

> Here is the whole function:
>
> --cut--
> struct driver *lists_driver_lookup_name(const char *name)
> {
> struct driver *drv =
> ll_entry_start(struct driver, driver);
> const int n_ents = ll_entry_count(struct driver, driver);
> struct driver *entry;
> int len;
>
> if (!drv || !n_ents)
> return NULL;
>
> len = strlen(name);
>
> for (entry = drv; entry != drv + n_ents; entry++) {
> if (strncmp(name, entry->name, len))
> continue;
>
> /* Full match */
> if (len == strlen(entry->name))
> return entry;
>>
>
> /* Not found */
> return NULL;
>>
> --cut--
>
> and... no, the code does not support passing a string that is
> not null terminated.

Then using the strncmp() seems useless for security reasons?  The 'len'
is not passed in by the caller and 'strlen()' will have the same
problems that 'strcmp()' would for read buffer overflows?  I would guess
the code was cribbed from where 'len' was passed?  In that case, it
would support strings that are not null terminated.

Sorry, I didn't look and understand your query now.

Fwiw,
Bill Pringlemeir.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] Re: [PATCH 0/7] ARM: sunxi: Add basic support for Allwinner A31 (sun6i)

[Chen-Yu Tsai]

Hi,

On Thu, Sep 18, 2014 at 4:31 PM, Hans de Goede  wrote:
> Hi,
>
> On 09/18/2014 06:27 AM, Siarhei Siamashka wrote:
>> On Tue, 09 Sep 2014 09:00:57 +0200
>> Hans de Goede  wrote:
>>
>>> Hi,
>>>
>>> On 09/08/2014 03:28 PM, Chen-Yu Tsai wrote:
 Hi everyone,

 This series add basic support for Allwinner's A31 SoC. The patches,
 excluding the first one, were cherry-picked from u-boot-sunxi. Due to
 the difference between u-boot mainline and u-boot-sunxi, some patches
 were rearranged or squashed to better fit the current state of u-boot,
 and not introduce any build breaks. It follows Ian's initial merge
 method of sun7i support: introducing various components first, then
 enabling them in the last commit. I tried to keep the commits separate,
 thus retaining the original author and Signed-off-bys.

 Patch 1 adds a wrapper around "func(USB, usb, 0)" in BOOT_TARGET_DEVICES
 to deal with breakage when USB support is not enabled.

 Patch 2 adds memory addresses for some hardware blocks new in sun6i.

 Patch 3 adds support for the new PRCM (power reset and clock management)
 block, which also contains PLL bias voltage control.

 Patch 4 adds support for the clock module. This patch is a bunch of
 different sun6i related patches on the clock code, from when sun6i
 support was introduced to u-boot-sunxi, up to its current form.
 This is done to avoid various conflicts and needlessly introducing
 then removing macros.

 Patch 5 adds mmc support on sun6i.

 Patch 6 adds uart0 muxing on sun6i.

 Patch 7 enables sun6i support and adds defconfig for the Colombus board.
>>>
>>> Chen,
>>>
>>> Many thanks for working on this!
>>>
>>> Just a quick not for people celebrating too early, this is the *incomplete*
>>> sun7i support from the linux-sunxi/u-boot-sunxi git repo. It is fine to
>>> merge this upstream, but this does not include SPL support.
>>>
>>> This allows replacing u-boot.bin on allwinnner sd-card images, which is
>>> very useful. But it does not get us all the way to booting sun7i devices
>>> we still need boot0 and boot1 binaries from allwinner for that (for now).
>>
>> If I understand it correctly, one of the things that needs to be done
>> in SPL is the initialization of the DRAM controller. A few weeks ago
>> Oliver has updated the http://linux-sunxi.org/DRAM_Controller page
>> and added a link to the 'dram_sun6i.c' file from the rhombus-tech.net
>> u-boot repository:
>> 
>> http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/sunxi/dram_sun6i.c;hb=refs/heads/allwinner-sunxi-a31
>> Does this repository look like exactly the missing part of code?
>
> Yes it does, interesting. I had found that file before, but this one
> was missing in the repo I found then:
>
> http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-sunxi/dram.h;hb=refs/heads/allwinner-sunxi-a31
>
> But with that one added, this is definitely interesting.

The A31 Hummingbird's SDK has provided us with full boot0/boot1,
which also includes the dram code:

http://dl.linux-sunxi.org/SDK/A31/unpacked-stripped/a31_v4.5_hummingbird_kfb_ok/lichee/boot-v1.0/boot/source/init_dram/

It is more complex than what we found in u-boot.
This code also shows what is encoded into the dram parameters
found in the fex files.

>> Assuming that this code works, it provides a usable starting point
>> for us.
>
> Yep, assuming :) If no one beats me to it I'll take a look at this as
> time permits.
>
>> It looks like the Allwinner A31 DRAM controller registers are very
>> similar to what is used in RK3288 (I have not checked the details,
>> but if we are very lucky, it might be even a 100% perfect match):
>> https://chromium-review.googlesource.com/#/c/209419/
>> And thanks to the Rockchip developers (who are contributing this
>> DRAM controller support code to coreboot), now we have a lot of
>> named defines for the individual bitfields in the hardware
>> registers. So we can decode the magic constants used in the
>> Allwinner code. And thanks to Texas Instruments, we also have
>> some useful documentation, which also happens to be a reasonably
>> good match:
>> http://www.ti.com/lit/ug/spruhn7a/spruhn7a.pdf
>
> Sounds good / useful.
>
>> In general, if we are on our own, then we just need to do all the
>> boring work again (similar to what we did with the Allwinner
>> A10/A13/A20 DRAM controller earlier). Starting with the creation of the
>> http://linux-sunxi.org/A31_DRAM_Controller_Register_Guide
>> wiki page and populating it with the information gathered from the
>> Allwinner and Rockchip source code and also from the TI Keystone2
>> documentation. Naturally, every bit of this information needs to
>> be verified on real Allwinner A31 hardware before we can make any
>> assumptions.
>
> Yep.

Matching the register bits with the parts decoded from dram
parameters seems like a place to start

Re: [U-Boot] [PATCH 4/8] ARMv8: PSCI: Add linker section to hold PSCI code

[Marc Zyngier]

On Thu, Sep 18 2014 at 10:12:17 AM, Albert ARIBAUD  
wrote:
> Hi Arnab,
>
> On Thu, 28 Aug 2014 01:59:57 +0530, Arnab Basu
>  wrote:
>
>> A separate linker section makes it possible to keep this code either
>> in DDR or in some secure memory location provided specifically for the
>> purpose.
>> 
>> So far no one is using this section.
>> 
>> Signed-off-by: Arnab Basu 
>> Reviewed-by: Bhupesh Sharma 
>> Cc: Marc Zyngier 
>> ---
>>  arch/arm/config.mk|2 +-
>>  arch/arm/cpu/armv8/u-boot.lds |   30 ++
>>  2 files changed, 31 insertions(+), 1 deletions(-)
>> 
>> diff --git a/arch/arm/config.mk b/arch/arm/config.mk
>> index c339e6d..9272e9c 100644
>> --- a/arch/arm/config.mk
>> +++ b/arch/arm/config.mk
>> @@ -111,7 +111,7 @@ endif
>>  
>>  # limit ourselves to the sections we want in the .bin.
>>  ifdef CONFIG_ARM64
>> -OBJCOPYFLAGS += -j .text -j .rodata -j .data -j .u_boot_list -j .rela.dyn
>> +OBJCOPYFLAGS += -j .text -j .secure_text -j .rodata -j .data -j 
>> .u_boot_list -j .rela.dyn
>>  else
>>  OBJCOPYFLAGS += -j .text -j .secure_text -j .rodata -j .hash -j .data -j 
>> .got.plt -j .u_boot_list -j .rel.dyn
>>  endif
>> diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds
>> index 4c1..bd95fff 100644
>> --- a/arch/arm/cpu/armv8/u-boot.lds
>> +++ b/arch/arm/cpu/armv8/u-boot.lds
>> @@ -8,6 +8,8 @@
>>   * SPDX-License-Identifier: GPL-2.0+
>>   */
>>  
>> +#include 
>> +
>>  OUTPUT_FORMAT("elf64-littleaarch64", "elf64-littleaarch64", 
>> "elf64-littleaarch64")
>>  OUTPUT_ARCH(aarch64)
>>  ENTRY(_start)
>> @@ -23,6 +25,34 @@ SECTIONS
>>  *(.text*)
>>  }
>>  
>> +#ifdef CONFIG_ARMV8_PSCI
>> +
>> +#ifndef CONFIG_ARMV8_SECURE_BASE
>> +#define CONFIG_ARMV8_SECURE_BASE
>> +#endif
>> +
>> +.__secure_start : {
>> +. = ALIGN(0x1000);
>> +*(.__secure_start)
>> +}
>> +
>> +.secure_text CONFIG_ARMV8_SECURE_BASE :
>> +AT(ADDR(.__secure_start) + SIZEOF(.__secure_start))
>> +{
>> +*(._secure.text)
>> +}
>> +
>> +. = LOADADDR(.__secure_start) +
>> +SIZEOF(.__secure_start) +
>> +SIZEOF(.secure_text);
>> +
>> +__secure_end_lma = .;
>> +.__secure_end : AT(__secure_end_lma) {
>> +*(.__secure_end)
>> +LONG(0x1d1071c);/* Must output something to reset LMA */
>
> Can you explain in more detail what issue this fixes?

If you use AT to force a new load address (LMA), you must ensure that
you actually output something at this address. Here, if *(.__secure_end)
ends up being empty, whatever follows would be as if the AT never
happened, ending up at the wrong LMA.

The workaround is to force the output of a dummy value in all
cases, ensuring that the rest of the text is at a sensible LMA. This is
an issue that has been in GNU ld for years, and this workaround is a
copy/paste of the same one in the ARMv7 ld script.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes

[Pavel Machek]

Hi!

> What board are doing your testing on? The Arrow Sockit?

I have board similar to SocKit, yes.

> I also see this error print:
> 
> U-Boot 2014.10-rc2-00139-g70e9e3e-dirty (Sep 16 2014 - 16:26:56)
> 
> CPU:   Altera SoCFPGA Platform
> BOARD: Altera SoCFPGA Cyclone5 Board
>Watchdog enabled
> DRAM:  1 GiB
> WARNING: Caches not enabled
> Using default environment
> 
> In:serial
> Out:   serial
> Err:   serial
> Net:   dwmac.ff702000
> Error: dwmac.ff702000 address not set. 
> ^
> 
> Do you see this on your side? I can track it down...

i2c code that reads address from ROM was not part of the merge, so you
need to either set address manually or port it from rocketboards version.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] dm: avoid dev->req_seq overflow

[Robert Baldyga]

Since dev->req_seq value is initialized from "reg" property of fdt node,
there is posibility, that address value contained in fdt is greater than
INT_MAX, and then value in dev->req_seq is negative which led to probe()
fail.

This patch fix this problem by ensuring that req_seq is positive, unless
it's one of errno codes.

Signed-off-by: Robert Baldyga 
---
 drivers/core/device.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index 166b073..35ffce0 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -107,6 +107,8 @@ int device_bind(struct udevice *parent, struct driver *drv, 
const char *name,
 * when the device is probed.
 */
dev->req_seq = fdtdec_get_int(gd->fdt_blob, of_offset, "reg", -1);
+   if (!IS_ERR_VALUE(dev->req_seq))
+   dev->req_seq &= INT_MAX;
dev->seq = -1;
if (uc->uc_drv->name && of_offset != -1) {
fdtdec_get_alias_seq(gd->fdt_blob, uc->uc_drv->name, of_offset,
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 16/35] arm: socfpga: clock: Trim down code duplication

[Pavel Machek]

On Mon 2014-09-15 13:06:09, Marek Vasut wrote:
> Pull out functions to read frequency of Main clock VCO and
> PLL clock VCO as the code is duplicated multiple times.
> 
> Signed-off-by: Marek Vasut 
> Cc: Chin Liang See 
> Cc: Dinh Nguyen 
> Cc: Albert Aribaud 
> Cc: Tom Rini 
> Cc: Wolfgang Denk 
Acked-by   : Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 14/35] arm: socfpga: clock: Add missing stubs into board file

[Pavel Machek]

On Mon 2014-09-15 13:06:07, Marek Vasut wrote:
> Add some stub defines, which are used by the clock code, but are
> missing from the auto-generated header file for the SoCFPGA family.
> 
> Signed-off-by: Marek Vasut 
> Cc: Chin Liang See 
> Cc: Dinh Nguyen 
> Cc: Albert Aribaud 
> Cc: Tom Rini 
> Cc: Wolfgang Denk 
Acked-by: Pavel Machek 
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 09/11] dm: imx: gpio: Support driver model in MXC gpio driver

[Simon Glass]

Hi Igor,

On 18 September 2014 01:35, Igor Grinberg  wrote:
>
> On 09/17/14 18:02, Simon Glass wrote:
> > Add driver model support with this driver. In this case the platform data
> > is in the driver. It would be better to put this into an SOC-specific file,
> > but this is best attempted when more boards are moved over to use driver
> > model.
> >
> > Signed-off-by: Simon Glass 
>
> Acked-by: Igor Grinberg 

Thanks for reviewing these.

The latest experimental state of driver model is at u-boot-dm/working.
There is also an imx-working branch with this series in it.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot panasonic repo

[Masahiro YAMADA]

Hi Albert,

2014-09-18 20:44 GMT+09:00 Albert ARIBAUD :
> Hi Masahiro,
>
> On Thu, 18 Sep 2014 19:13:04 +0900, Masahiro Yamada
>  wrote:
>
>> Hi Michal,
>>
>>
>>
>> On Thu, 18 Sep 2014 10:24:39 +0200
>> Michal Simek  wrote:
>>
>> > Hi guys,
>> >
>> > On 09/18/2014 10:02 AM, Marek Vasut wrote:
>> > > On Thursday, September 18, 2014 at 09:58:47 AM, Michal Simek wrote:
>> > >> On 09/18/2014 09:27 AM, Marek Vasut wrote:
>> > >>> On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote:
>> >  Hi Michal,
>> > >>>
>> > >>> Hi,
>> > >>>
>> >  On Thu, 11 Sep 2014 06:56:04 +0200
>> > 
>> >  Michal Simek  wrote:
>> > > Hi,
>> > >
>> > > On 09/11/2014 05:09 AM, Masahiro Yamada wrote:
>> > >> On Thu, 11 Sep 2014 01:33:20 +0200
>> > >>
>> > >> Marek Vasut  wrote:
>> > >>> Hello,
>> > >>>
>> > >>> I'd be interested in maintaining u-boot-socfpga repository. So far,
>> > >>> we don't have a repo for this platform and there is a large flurry
>> > >>> of patches flying around without any kind of central point for 
>> > >>> them.
>> > >>> I'd like to get your formal consent for starting this and if you
>> > >>> agree, I'd start sending PR to Albert once the repo is in place.
>> > >>
>> > >> Me too.  I'd like to own u-boot-uniphier to collect
>> > >> Panasonic-SoC-specific changes.
>> > >>
>> > >> That would be faster and would not disturb Albert.
>> > >
>> > > I am not sure if you need to have separate repo to work like this.
>> > > I am keeping zynq patches in my microblaze repo and sending pull
>> > > request to Albert (or Tom now) and there is no problem with that.
>> > 
>> >  The point is that you collect Zynq-specific patches in your own place 
>> >  by
>> >  yourself and then send a pull-req to Albert or Tom, right?
>> > 
>> >  It does not matter whether it is a separate u-boot-zynq repo or
>> >  u-boot-microbraze/zynq branch.
>> > 
>> > 
>> >  I have sent the first series to add the core support of Panasonic SoCs
>> >  and boards (but it is taking much longer than I have expected)
>> >  and then I am planning to send more features and boards in the next
>> >  phase.
>> > 
>> > 
>> >  What's the difference between what I want to do for Panasonic SoCs
>> >  and what you usually do for Zynq SoCs?
>> > >>>
>> > >>> [...]
>> > >>>
>> > >>> I fully support that we should have a repo for the panasonic socs, it's
>> > >>> pointless to load Albert by making him apply patches by hand and you 
>> > >>> have
>> > >>> proven numerous times that you do know what you're doing. I really see 
>> > >>> no
>> > >>> blocker for doing this.
>> > >>
>> > >> +1 on this if Masahiro wants to have separate repo.
>> > >
>> > > There is no repo for those SoCs at all, so I'd be all for it.
>> >
>> > This is the flow which is IMHO the best.
>>
>>
>> Thanks for your suggestion!
>>
>>
>> > Masahiro will send the RFC patch for MAINTAINERS file to Albert
>> > with adding his fragment for Panasonic SoCs. If Albert ACK but not apply it
>> > that it means that he agrees with that person to be responsible for this 
>> > part.
>> > Based on that Masahiro asks for repo (if he wants it) and repo will be 
>> > created.
>>
>> The patch for MAINTAINERS is already on our patchwork.
>> Is this the one you mentioned?
>> http://patchwork.ozlabs.org/patch/386108/
>>
>> If so, all I have to do now is to just wait until Albert ackes it?
>
> Your wait is over. :)

Thanks!!



> I assume you're going to re-delegate the uniphier series to yourself
> once this is done? Or do you want me to apply it?

Do not apply it, please.

I've received some comments on this version
and I am planning to send v5.

I will change the state of this version to Superseded lator.


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] compulab: eeprom: add default eeprom bus

[Nikita Kiryanov]

Hi ALbert,

On 18/09/14 15:26, Albert ARIBAUD wrote:

Hi Igor,

On Wed, 17 Sep 2014 17:18:49 +0300, Igor Grinberg
 wrote:


On 09/17/14 15:59, Nikita Kiryanov wrote:

Add default eeprom bus setting.
This addresses the trimslice compile error that was introduced
with the addition of this setting.

Cc: Albert ARIBAUD 
Cc: Igor Grinberg 
Signed-off-by: Nikita Kiryanov 


Acked-by: Igor Grinberg 

Albert, this should be a temporary fix to not break the trimslice support.
We intend to rework this while switching Kconfig for all boards.

Thanks!


---
  board/compulab/common/eeprom.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/board/compulab/common/eeprom.c b/board/compulab/common/eeprom.c
index 85442cd..2df3ada 100644
--- a/board/compulab/common/eeprom.c
+++ b/board/compulab/common/eeprom.c
@@ -15,6 +15,10 @@
  # define CONFIG_SYS_I2C_EEPROM_ADDR_LEN   1
  #endif

+#ifndef CONFIG_SYS_I2C_EEPROM_BUS
+#define CONFIG_SYS_I2C_EEPROM_BUS  0
+#endif
+
  #define EEPROM_LAYOUT_VER_OFFSET  44
  #define BOARD_SERIAL_OFFSET   20
  #define BOARD_SERIAL_OFFSET_LEGACY8



a 'git grep CONFIG_SYS_I2C_EEPROM_BUS' shows that all values for
CONFIG_SYS_I2C_EEPROM_BUS are set in include/configs/*.h.

Therefore I would prefer that the temporary fix be in
include/configs/trimslice.h header file too.



Given that trimslice does not use the eeprom code, I feel that
it's cleaner to not populate its config file with irrelevant
defines. It's also consistent with the way CONFIG_SYS_I2C_EEPROM_ADDR
and CONFIG_SYS_I2C_EEPROM_ADDR_LEN are handled.

--
Regards,
Nikita Kiryanov
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Need help with u-boot problem with usb-keyboard / kvm switch

[Luc Verhaegen]

On Thu, Sep 18, 2014 at 10:34:04AM +0200, Hans de Goede wrote:
> Hi,
> 
> Cleaning up may not have been the best choice of words, I was
> talking about the rebase on top of upstream u-boot + the various
> fixes you already know about.
> 
> I plan to submit a patch-set to the kernel for the clock resource
> stuff for simplefb to the proper lists for that discussion soon,
> and assuming that gets accepted I would like to land the
> hdmi support in upstream u-boot soon.

Ok, thanks for getting me up to date on this.

As for simplefb, i had given up on that, and wanted to cough up 
an alternate driver that simply wouldn't be called that. But as usual, i 
am all over the place. So let's see how the simplefb route goes. Good 
luck.

Thanks,

Luc Verhaegen.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] A minor question on a Driver Model function

[Igor Grinberg]

Hi Bill,

On 09/17/14 18:25, Bill Pringlemeir wrote:
> 
>> On 12 September 2014 05:25, Masahiro Yamada  
>> wrote:
> 
>> I have a qustion about lists_driver_lookup_name() function.
> 
>> for (entry = drv; entry != drv + n_ents; entry++) {
>> if (strncmp(name, entry->name, len))
>> continue;
> 
>> /* Full match */
>> if (len == strlen(entry->name))
>> return entry;
>> }
> 
 On 09/14/14 21:28, Simon Glass wrote:
> 
 I would suggest still using strncmp as it is safer,
 but count also the '\0', so something like:
> 
> On 17 Sep 2014, grinb...@compulab.co.il wrote:
> 
>>> Why safer?
> 
>>> Could you give me more detailed explanation?
> 
>> On 09/17/14 11:18, Masahiro Yamada wrote:
> 
>> Well, I'm not an expert in s/w security, but I'll try to explain...
> 
> [snip]
> 
>> But, again, I'm not an expert in this area, so its only a suggestion.
> 
> I thought it was fairly apparent that the current code supports passing
> a string that is *NOT* null terminated.  This can be convenient if you
> extract a sub-string from a command line and do not need to make a copy
> that is NULL terminate or perform 'strtok()' type magic.

Here is the whole function:

--cut--
struct driver *lists_driver_lookup_name(const char *name)
{
struct driver *drv =
ll_entry_start(struct driver, driver);
const int n_ents = ll_entry_count(struct driver, driver);
struct driver *entry;
int len;

if (!drv || !n_ents)
return NULL;

len = strlen(name);

for (entry = drv; entry != drv + n_ents; entry++) {
if (strncmp(name, entry->name, len))
continue;

/* Full match */
if (len == strlen(entry->name))
return entry;
}

/* Not found */
return NULL;
}
--cut--

and... no, the code does not support passing a string that is
not null terminated.

-- 
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Please pull u-boot-ti/master

[Tom Rini]

Hello,

The following changes since commit c292adae170fa8c27dca75963bdb0a9afc640e57:

  Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' (2014-09-17 
23:35:34 +0200)

are available in the git repository at:


  git://git.denx.de/u-boot-ti.git master

for you to fetch changes up to 3aae66e2a74ac89724d16b6e8908dcd0d2825eeb:

  am335x_evm: Add boot script support to am335x_evm (2014-09-17 21:06:56 -0400)


Guillaume GARDET (2):
  OMAP4: Use generic 'load' command instead of 'fatload' for 
'loadbootscript' and 'loadbootenv' as already done for 'loadimage' and 
'loaduimage'.
  am335x_evm: Add boot script support to am335x_evm

Murali Karicheri (1):
  ARM: keystone: ddr3: workaround for ddr3a/3b memory issue

 arch/arm/cpu/armv7/keystone/ddr3.c|   75 +
 arch/arm/include/asm/arch-keystone/ddr3.h |1 +
 arch/arm/include/asm/arch-keystone/hardware.h |2 +
 board/ti/ks2_evm/ddr3_k2hk.c  |4 ++
 include/configs/am335x_evm.h  |   29 ++
 include/configs/ti_omap4_common.h |4 +-
 6 files changed, 102 insertions(+), 13 deletions(-)

-- 
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] am335x_evm: Add boot script support to am335x_evm

[Tom Rini]

On Thu, Sep 11, 2014 at 09:23:08AM +0200, Guillaume GARDET wrote:

> This patch adds boot script support to am335x_evm
> 
> Signed-off-by: Guillaume GARDET 
> Cc: Tom Rini 

Applied to u-boot-ti/master, thanks!

-- 
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] [U-Boot, U-boot, v2] ARM: keystone: ddr3: workaround for ddr3a/3b memory issue

[Tom Rini]

On Wed, Sep 10, 2014 at 03:54:59PM +0300, Khoronzhuk, Ivan wrote:

> From: Murali Karicheri 
> 
> This patch implements a workaround to fix DDR3 memory issue.
> The code for workaround detects PGSR0 errors and then preps for
> and executes a software-controlled hard reset.In board_early_init,
> where logic has been added to identify whether or not the previous
> reset was a PORz. PLL initialization is skipped in the case of a
> software-controlled hard reset.
> 
> Signed-off-by: Murali Karicheri 
> Signed-off-by: Keegan Garcia 
> Signed-off-by: Ivan Khoronzhuk 

Applied to u-boot-ti/master, thanks!

-- 
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] OMAP4: Use generic 'load' command instead of 'fatload' for 'loadbootscript' and 'loadbootenv' as already done for 'loadimage' and 'loaduimage'.

[Tom Rini]

On Fri, Sep 05, 2014 at 03:32:46PM +0200, Guillaume GARDET wrote:

> This patch uses generic 'load' command instead of 'fatload' for 
> 'loadbootscript' and 'loadbootenv' as already done for 'loadimage' and 
> 'loaduimage' for OMAP4 boards.
> 
> This allows to use EXT partition instead of FAT, while keeping FAT 
> compatibility.
> 
> Signed-off-by: Guillaume GARDET 
>   
>
> Cc: Tom Rini 

Applied to u-boot-ti/master, thanks!

-- 
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] compulab: eeprom: add default eeprom bus

[Albert ARIBAUD]

Hi Igor,

On Wed, 17 Sep 2014 17:18:49 +0300, Igor Grinberg
 wrote:

> On 09/17/14 15:59, Nikita Kiryanov wrote:
> > Add default eeprom bus setting.
> > This addresses the trimslice compile error that was introduced
> > with the addition of this setting.
> > 
> > Cc: Albert ARIBAUD 
> > Cc: Igor Grinberg 
> > Signed-off-by: Nikita Kiryanov 
> 
> Acked-by: Igor Grinberg 
> 
> Albert, this should be a temporary fix to not break the trimslice support.
> We intend to rework this while switching Kconfig for all boards.
> 
> Thanks!
> 
> > ---
> >  board/compulab/common/eeprom.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/board/compulab/common/eeprom.c b/board/compulab/common/eeprom.c
> > index 85442cd..2df3ada 100644
> > --- a/board/compulab/common/eeprom.c
> > +++ b/board/compulab/common/eeprom.c
> > @@ -15,6 +15,10 @@
> >  # define CONFIG_SYS_I2C_EEPROM_ADDR_LEN1
> >  #endif
> >  
> > +#ifndef CONFIG_SYS_I2C_EEPROM_BUS
> > +#define CONFIG_SYS_I2C_EEPROM_BUS  0
> > +#endif
> > +
> >  #define EEPROM_LAYOUT_VER_OFFSET   44
> >  #define BOARD_SERIAL_OFFSET20
> >  #define BOARD_SERIAL_OFFSET_LEGACY 8
> > 

a 'git grep CONFIG_SYS_I2C_EEPROM_BUS' shows that all values for
CONFIG_SYS_I2C_EEPROM_BUS are set in include/configs/*.h.

Therefore I would prefer that the temporary fix be in
include/configs/trimslice.h header file too.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot panasonic repo

[Albert ARIBAUD]

Hi Masahiro,

On Thu, 18 Sep 2014 19:13:04 +0900, Masahiro Yamada
 wrote:

> Hi Michal,
> 
> 
> 
> On Thu, 18 Sep 2014 10:24:39 +0200
> Michal Simek  wrote:
> 
> > Hi guys,
> > 
> > On 09/18/2014 10:02 AM, Marek Vasut wrote:
> > > On Thursday, September 18, 2014 at 09:58:47 AM, Michal Simek wrote:
> > >> On 09/18/2014 09:27 AM, Marek Vasut wrote:
> > >>> On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote:
> >  Hi Michal,
> > >>>
> > >>> Hi,
> > >>>
> >  On Thu, 11 Sep 2014 06:56:04 +0200
> > 
> >  Michal Simek  wrote:
> > > Hi,
> > >
> > > On 09/11/2014 05:09 AM, Masahiro Yamada wrote:
> > >> On Thu, 11 Sep 2014 01:33:20 +0200
> > >>
> > >> Marek Vasut  wrote:
> > >>> Hello,
> > >>>
> > >>> I'd be interested in maintaining u-boot-socfpga repository. So far,
> > >>> we don't have a repo for this platform and there is a large flurry
> > >>> of patches flying around without any kind of central point for them.
> > >>> I'd like to get your formal consent for starting this and if you
> > >>> agree, I'd start sending PR to Albert once the repo is in place.
> > >>
> > >> Me too.  I'd like to own u-boot-uniphier to collect
> > >> Panasonic-SoC-specific changes.
> > >>
> > >> That would be faster and would not disturb Albert.
> > >
> > > I am not sure if you need to have separate repo to work like this.
> > > I am keeping zynq patches in my microblaze repo and sending pull
> > > request to Albert (or Tom now) and there is no problem with that.
> > 
> >  The point is that you collect Zynq-specific patches in your own place 
> >  by
> >  yourself and then send a pull-req to Albert or Tom, right?
> > 
> >  It does not matter whether it is a separate u-boot-zynq repo or
> >  u-boot-microbraze/zynq branch.
> > 
> > 
> >  I have sent the first series to add the core support of Panasonic SoCs
> >  and boards (but it is taking much longer than I have expected)
> >  and then I am planning to send more features and boards in the next
> >  phase.
> > 
> > 
> >  What's the difference between what I want to do for Panasonic SoCs
> >  and what you usually do for Zynq SoCs?
> > >>>
> > >>> [...]
> > >>>
> > >>> I fully support that we should have a repo for the panasonic socs, it's
> > >>> pointless to load Albert by making him apply patches by hand and you 
> > >>> have
> > >>> proven numerous times that you do know what you're doing. I really see 
> > >>> no
> > >>> blocker for doing this.
> > >>
> > >> +1 on this if Masahiro wants to have separate repo.
> > > 
> > > There is no repo for those SoCs at all, so I'd be all for it.
> > 
> > This is the flow which is IMHO the best.
> 
> 
> Thanks for your suggestion!
> 
> 
> > Masahiro will send the RFC patch for MAINTAINERS file to Albert
> > with adding his fragment for Panasonic SoCs. If Albert ACK but not apply it
> > that it means that he agrees with that person to be responsible for this 
> > part.
> > Based on that Masahiro asks for repo (if he wants it) and repo will be 
> > created.
> 
> The patch for MAINTAINERS is already on our patchwork.
> Is this the one you mentioned?
> http://patchwork.ozlabs.org/patch/386108/
> 
> If so, all I have to do now is to just wait until Albert ackes it?

Your wait is over. :)

I assume you're going to re-delegate the uniphier series to yourself
once this is done? Or do you want me to apply it?

> Best Regards
> Masahiro Yamada

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 5/6] MAINTAINERS: add me as a maintainer of UniPhier platform

[Michal Simek]

Hi Masahiro,

On 09/18/2014 01:33 PM, Albert ARIBAUD wrote:
> Hi Masahiro,
> 
> On Fri,  5 Sep 2014 14:50:22 +0900, Masahiro Yamada
>  wrote:
> 
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> Changes in v4: None
>> Changes in v3: None
>> Changes in v2:
>>   - Newly added
>>
>>  MAINTAINERS | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index af194ca..cb5b3f0 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -149,6 +149,14 @@ F:  arch/arm/include/asm/arch-davinci/
>>  F:  arch/arm/include/asm/arch-omap*/
>>  F:  arch/arm/include/asm/ti-common/
>>  
>> +ARM UNIPHIER
>> +M:  Masahiro Yamada 
>> +S:  Maintained
>> +F:  arch/arm/cpu/armv7/uniphier/
>> +F:  arch/arm/include/asm/arch-uniphier/
>> +F:  configs/ph1_*_defconfig
>> +F:  drivers/serial/serial_uniphier.c
>> +
>>  ARM ZYNQ
>>  M:  Michal Simek 
>>  S:  Maintained
> 
> Acked-by: Albert ARIBAUD 

Acked-by: Michal Simek 

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 5/6] MAINTAINERS: add me as a maintainer of UniPhier platform

[Albert ARIBAUD]

Hi Masahiro,

On Fri,  5 Sep 2014 14:50:22 +0900, Masahiro Yamada
 wrote:

> Signed-off-by: Masahiro Yamada 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
>   - Newly added
> 
>  MAINTAINERS | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index af194ca..cb5b3f0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -149,6 +149,14 @@ F:   arch/arm/include/asm/arch-davinci/
>  F:   arch/arm/include/asm/arch-omap*/
>  F:   arch/arm/include/asm/ti-common/
>  
> +ARM UNIPHIER
> +M:   Masahiro Yamada 
> +S:   Maintained
> +F:   arch/arm/cpu/armv7/uniphier/
> +F:   arch/arm/include/asm/arch-uniphier/
> +F:   configs/ph1_*_defconfig
> +F:   drivers/serial/serial_uniphier.c
> +
>  ARM ZYNQ
>  M:   Michal Simek 
>  S:   Maintained

Acked-by: Albert ARIBAUD 

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: ls102xa: Fixed a register definition error

[Albert ARIBAUD]

Hi Tang,

On Thu, 18 Sep 2014 17:12:06 +0800, Tang Yuantian
 wrote:

> There are 8 SCFG_SPARECR registers in SCFG memory block, not
> just one.
> 
> Signed-off-by: Tang Yuantian 
> ---
>  arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h 
> b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
> index 7995fe2..b5db720 100644
> --- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
> +++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
> @@ -182,7 +182,7 @@ struct ccsr_scfg {
>   u32 etsecmcr;
>   u32 sdhciovserlcr;
>   u32 resv14[61];
> - u32 sparecr;
> + u32 sparecr[8];
>  };
>  
>  /* Clocking */

Obviously the original code was not problematic as sparecr was not
used. Is your change dictated by a patch or series that you are
preparing and that will use sparecr?

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 6/7] arm: ls102xa: Add SD boot support for LS1021AQDS board

[Albert ARIBAUD]

Hi Alison,

On Thu, 18 Sep 2014 13:47:18 +0800, Alison Wang 
wrote:

> This patch adds SD boot support for LS1021AQDS board. SPL
> framework is used. PBL initialize the internal RAM and copy
> SPL to it, then SPL initialize DDR using SPD and copy u-boot
> from SD card to DDR, finally SPL transfer control to u-boot.
> 
> Signed-off-by: Alison Wang 
> Signed-off-by: Jason Jin 
> ---
>  arch/arm/cpu/armv7/ls102xa/Makefile   |  1 +
>  arch/arm/cpu/armv7/ls102xa/spl.c  | 35 +++
>  arch/arm/cpu/armv7/ls102xa/u-boot-spl.lds | 89 
> +++
>  arch/arm/include/asm/arch-ls102xa/spl.h   | 20 ++
>  board/freescale/ls1021aqds/MAINTAINERS|  1 +
>  board/freescale/ls1021aqds/ddr.c  |  5 +-
>  board/freescale/ls1021aqds/ls1021aqds.c   | 31 ++
>  board/freescale/ls1021aqds/ls102xa_pbi.cfg|  8 +++
>  board/freescale/ls1021aqds/ls102xa_rcw_sd.cfg | 14 +
>  configs/ls1021aqds_sdcard_defconfig   |  4 ++
>  include/configs/ls1021aqds.h  | 67 
>  11 files changed, 274 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/cpu/armv7/ls102xa/spl.c
>  create mode 100644 arch/arm/cpu/armv7/ls102xa/u-boot-spl.lds
>  create mode 100644 arch/arm/include/asm/arch-ls102xa/spl.h
>  create mode 100644 board/freescale/ls1021aqds/ls102xa_pbi.cfg
>  create mode 100644 board/freescale/ls1021aqds/ls102xa_rcw_sd.cfg
>  create mode 100644 configs/ls1021aqds_sdcard_defconfig
> 
> diff --git a/arch/arm/cpu/armv7/ls102xa/Makefile 
> b/arch/arm/cpu/armv7/ls102xa/Makefile
> index d82ce8d..56ef3a7 100644
> --- a/arch/arm/cpu/armv7/ls102xa/Makefile
> +++ b/arch/arm/cpu/armv7/ls102xa/Makefile
> @@ -10,3 +10,4 @@ obj-y   += timer.o
>  
>  obj-$(CONFIG_OF_LIBFDT) += fdt.o
>  obj-$(CONFIG_SYS_HAS_SERDES) += fsl_ls1_serdes.o ls102xa_serdes.o
> +obj-$(CONFIG_SPL) += spl.o
> diff --git a/arch/arm/cpu/armv7/ls102xa/spl.c 
> b/arch/arm/cpu/armv7/ls102xa/spl.c
> new file mode 100644
> index 000..77ea1ee
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/ls102xa/spl.c
> @@ -0,0 +1,35 @@
> +/*
> + * Copyright 2014 Freescale Semiconductor, Inc.
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +
> +u32 spl_boot_device(void)
> +{
> +#ifdef CONFIG_SPL_MMC_SUPPORT
> + return BOOT_DEVICE_MMC1;
> +#endif
> + return BOOT_DEVICE_NAND;
> +}
> +
> +u32 spl_boot_mode(void)
> +{
> + switch (spl_boot_device()) {
> + case BOOT_DEVICE_MMC1:
> +#ifdef CONFIG_SPL_FAT_SUPPORT
> + return MMCSD_MODE_FAT;
> +#else
> + return MMCSD_MODE_RAW;
> +#endif
> + break;
> + case BOOT_DEVICE_NAND:
> + return 0;
> + break;
> + default:
> + puts("spl: error: unsupported device\n");
> + hang();
> + }
> +}
> diff --git a/arch/arm/cpu/armv7/ls102xa/u-boot-spl.lds 
> b/arch/arm/cpu/armv7/ls102xa/u-boot-spl.lds
> new file mode 100644
> index 000..10671e7
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/ls102xa/u-boot-spl.lds
> @@ -0,0 +1,89 @@
> +/*
> + * Copyright (c) 2004-2008 Texas Instruments
> + *
> + * (C) Copyright 2002
> + * Gary Jennejohn, DENX Software Engineering, 
> + *
> + * Copyright 2014 Freescale Semiconductor, Inc.
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
> +OUTPUT_ARCH(arm)
> +ENTRY(_start)
> +SECTIONS
> +{
> + . = 0x;
> +
> + . = ALIGN(4);
> + .text :
> + {
> + __image_copy_start = .;
> + *(.vectors)
> + CPUDIR/start.o (.text*)
> + *(.text*)
> + }
> +
> + . = ALIGN(4);
> + .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
> +
> + . = ALIGN(4);
> + .data : {
> + *(.data*)
> + }
> +
> + . = ALIGN(4);
> + .u_boot_list : {
> + KEEP(*(SORT(.u_boot_list*_i2c_*)));
> + }

IS this required? And if it is, could it not be added to the
arch/arm/cpu/u-boot-spl.lds file? This way you would not need an .lds
file at all.

> + . = .;
> +
> + __image_copy_end = .;
> +
> + .rel.dyn : {
> + __rel_dyn_start = .;
> + *(.rel*)
> + __rel_dyn_end = .;
> + }
> +
> + .end :
> + {
> + *(.__end)
> + }
> +
> + _image_binary_end = .;
> +
> + .bss __rel_dyn_start (OVERLAY) : {
> + __bss_start = .;
> + *(.bss*)
> +  . = ALIGN(4);
> + __bss_end = .;
> + }
> +
> + .dynsym _image_binary_end : { *(.dynsym) }
> + .dynbss : { *(.dynbss) }
> + .dynstr : { *(.dynstr*) }
> + .dynamic : { *(.dynamic*) }
> + .hash : { *(.hash*) }
> + .plt : { *(.plt*) }
> + .interp : { *(.interp*) }
> + .gnu : { *(.gnu*) }
> + .ARM.exidx : { *(.ARM.exidx*) }
> +}
> +
> +#if defined(CONFIG_SPL_MAX_SIZE)
> +ASSERT(__image_copy_end - __image_copy_start < (CON

Re: [U-Boot] U-Boot panasonic repo

[Masahiro Yamada]

Hi Michal,



On Thu, 18 Sep 2014 10:24:39 +0200
Michal Simek  wrote:

> Hi guys,
> 
> On 09/18/2014 10:02 AM, Marek Vasut wrote:
> > On Thursday, September 18, 2014 at 09:58:47 AM, Michal Simek wrote:
> >> On 09/18/2014 09:27 AM, Marek Vasut wrote:
> >>> On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote:
>  Hi Michal,
> >>>
> >>> Hi,
> >>>
>  On Thu, 11 Sep 2014 06:56:04 +0200
> 
>  Michal Simek  wrote:
> > Hi,
> >
> > On 09/11/2014 05:09 AM, Masahiro Yamada wrote:
> >> On Thu, 11 Sep 2014 01:33:20 +0200
> >>
> >> Marek Vasut  wrote:
> >>> Hello,
> >>>
> >>> I'd be interested in maintaining u-boot-socfpga repository. So far,
> >>> we don't have a repo for this platform and there is a large flurry
> >>> of patches flying around without any kind of central point for them.
> >>> I'd like to get your formal consent for starting this and if you
> >>> agree, I'd start sending PR to Albert once the repo is in place.
> >>
> >> Me too.  I'd like to own u-boot-uniphier to collect
> >> Panasonic-SoC-specific changes.
> >>
> >> That would be faster and would not disturb Albert.
> >
> > I am not sure if you need to have separate repo to work like this.
> > I am keeping zynq patches in my microblaze repo and sending pull
> > request to Albert (or Tom now) and there is no problem with that.
> 
>  The point is that you collect Zynq-specific patches in your own place by
>  yourself and then send a pull-req to Albert or Tom, right?
> 
>  It does not matter whether it is a separate u-boot-zynq repo or
>  u-boot-microbraze/zynq branch.
> 
> 
>  I have sent the first series to add the core support of Panasonic SoCs
>  and boards (but it is taking much longer than I have expected)
>  and then I am planning to send more features and boards in the next
>  phase.
> 
> 
>  What's the difference between what I want to do for Panasonic SoCs
>  and what you usually do for Zynq SoCs?
> >>>
> >>> [...]
> >>>
> >>> I fully support that we should have a repo for the panasonic socs, it's
> >>> pointless to load Albert by making him apply patches by hand and you have
> >>> proven numerous times that you do know what you're doing. I really see no
> >>> blocker for doing this.
> >>
> >> +1 on this if Masahiro wants to have separate repo.
> > 
> > There is no repo for those SoCs at all, so I'd be all for it.
> 
> This is the flow which is IMHO the best.


Thanks for your suggestion!


> Masahiro will send the RFC patch for MAINTAINERS file to Albert
> with adding his fragment for Panasonic SoCs. If Albert ACK but not apply it
> that it means that he agrees with that person to be responsible for this part.
> Based on that Masahiro asks for repo (if he wants it) and repo will be 
> created.

The patch for MAINTAINERS is already on our patchwork.
Is this the one you mentioned?
http://patchwork.ozlabs.org/patch/386108/

If so, all I have to do now is to just wait until Albert ackes 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] FW: [PATCH] usb: gadget: fastboot: improve download progress bar

[Marek Vasut]

On Thursday, September 18, 2014 at 10:11:49 AM, Bo Shen wrote:
> Hi Marek,
> 
> On 09/18/2014 10:32 AM, Marek Vasut wrote:
> > On Thursday, September 18, 2014 at 03:34:18 AM, Bo Shen wrote:
> >> Hi Marek,
> >> 
> >> On 09/17/2014 07:16 PM, Marek Vasut wrote:
> >>> On Wednesday, September 17, 2014 at 12:28:57 PM, Bo Shen wrote:
>  Hi Marek,
>  
>  On 09/17/2014 06:10 PM, Marek Vasut wrote:
> > On Wednesday, September 17, 2014 at 09:43:56 AM, Bo Shen wrote:
> > 
> > +CC Lukasz, this is his turf.
> > 
> >> When download is ongoing, if the actual size of one transfer is
> >> not the same as BTYES_PER_DOT, which will cause the dot won't
> >> print anymore. Then it will let the user thinking it is stuck,
> >> actually it is transfering without dot printed.
> >> 
> >> So, improve the method to show the progress bar (print dot).
> >> 
> >> Signed-off-by: Bo Shen 
> >> ---
> >> 
> >> drivers/usb/gadget/f_fastboot.c | 7 +--
> >> 1 file changed, 5 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/drivers/usb/gadget/f_fastboot.c
> >> b/drivers/usb/gadget/f_fastboot.c index 7a1acb9..2f13bf0 100644
> >> --- a/drivers/usb/gadget/f_fastboot.c
> >> +++ b/drivers/usb/gadget/f_fastboot.c
> >> @@ -51,6 +51,7 @@ static inline struct f_fastboot
> >> *func_to_fastboot(struct usb_function *f) static struct
> >> f_fastboot *fastboot_func;
> >> 
> >> static unsigned int download_size;
> >> static unsigned int download_bytes;
> >> 
> >> +static unsigned int num_of_dot;
> >> 
> >> static struct usb_endpoint_descriptor fs_ep_in = {
> >> 
> >>.bLength= USB_DT_ENDPOINT_SIZE,
> >> 
> >> @@ -414,9 +415,10 @@ static void rx_handler_dl_image(struct
> >> usb_ep *ep, struct usb_request *req) req->length = ep->maxpacket;
> >> 
> >>}
> >> 
> >> -  if (download_bytes && !(download_bytes % BYTES_PER_DOT)) {
> >> +  if (download_bytes && ((download_bytes / BYTES_PER_DOT) >
> >> num_of_dot)) { +   num_of_dot = download_bytes / 
BYTES_PER_DOT;
> >> 
> >>putc('.');
> >> 
> >> -  if (!(download_bytes % (74 * BYTES_PER_DOT)))
> >> +  if (!(num_of_dot % 74))
> >> 
> >>putc('\n');
> >>
> >>}
> >>req->actual = 0;
> >> 
> >> @@ -431,6 +433,7 @@ static void cb_download(struct usb_ep *ep,
> >> struct usb_request *req) strsep(&cmd, ":");
> >> 
> >>download_size = simple_strtoul(cmd, NULL, 16);
> >>download_bytes = 0;
> >> 
> >> +  num_of_dot = 0;
> > 
> > Make it a 'download_total' and log the total amount of bytes
> > transferred please, that way it can be re-used for other purposes
> > in the future ; for example for printing how much data were
> > already transferred ;-)
>  
>  The download_bytes record the total amount of bytes transferred.
>  And the download_bytes will print after finishing transfer.
> >>> 
> >>> So why can this not be used to indicate the total progress ? Because
> >>> the transfeer speed is variating too much ?
> >> 
> >> As I described in the commit message. If the transfer length is not
> >> exactly the same as the request length, then the old method
> >> 
> >> "download_bytes % BYTES_PER_DOT"
> >> 
> >> won't be 0 anymore, so for the following transfer, it won't print dot
> >> anymore.
> > 
> > And can you not reset the "download_bytes" for each transfer ?
> 
> No, I don't reset the "download_bytes" for each transfer. It reset the
> "download_bytes" before transfer start.
> The "download_bytes" is increase in rx_handler_dl_image function.

OK

> > Maybe we're not even aligned on what "transfer" means, so we might want
> > to sync on this word first. What does "transfer" mean in this case?
> 
> Transfer I mean here is a usb request, which trying to transfer
> EP_BUFFER_SIZE at one time.
> In my test case, sometime it transfer less than EP_BUFFER_SIZE in a usb
> request. So, it cause dot won't print the dot, and seems stuck. However,
> it will finish transfer after some time.

I see now. This code is really weird.

What would happen if the following condition is met in the code for k>0 ?
(download_bytes == download_size) AND (download_bytes = k * BYTES_PER_DOT)

I think the original code would happily print a dot after printing this output:
printf("\ndownloading of %d bytes finished\n", download_bytes);

Do you agree ? If yes, then I believe this code should go into the else branch 
only.

Also, you can probably avoid the counting variable if you do something like:

if (download_bytes / CONST != (download_bytes + transfer_size) / CONST) {
print(dot);
if (download_bytes / (74 * CONST) != ((download_bytes + transfer_size) 
/ 
(74 * CONST))
 

Re: [U-Boot] [PATCH] kbuild: refactor some makefiles

[Marek Vasut]

On Thursday, September 18, 2014 at 08:43:41 AM, Masahiro Yamada wrote:
> [1] Move driver/core/, driver/input/ and drivers/input/ entries
> from the top Makefile to drivers/Makefile
> 
> [2] Remove the conditional by CONFIG_DM in drivers/core/Makefile
> because the whole drivers/core directory is already selected
> by CONFIG_DM in the upper level
> 
> [3] Likewise for CONFIG_DM_DEMO in drivers/demo/Makefile
> 
> [4] Simplify common/Makefile - both CONFIG_DDR_SPD and
> CONFIG_SPD_EEPROM are boolean macros so they can directly
> select objects
> 
> Signed-off-by: Masahiro Yamada 
> ---
[...]

Acked-by: Marek Vasut 

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 1/3] compiler_gcc: do not redefine __gnu_attributes

[Masahiro Yamada]

Hi Jeroen,


On Thu, 18 Sep 2014 11:15:25 +0200
Jeroen Hofstee  wrote:

> Hello Masahiro,
> 
> On 18-09-14 04:13, Masahiro Yamada wrote:
> > Jeroen,
> >
> >> commit fb8ffd7cfc68b3dc44e182356a207d784cb30b34 "compiler*.h:
> >> sync include/linux/compiler*.h with Linux 3.16" undid the changes
> >> of 7ea50d52849fe8ffa5b5b74c979b60b1045d6fc9 "compiler_gcc: do
> >> not redefine __gnu_attributes". Add the checks back whether these
> >> macro's are already defined (as it causes a lot of noise on e.g.
> >> FreeBSD where these defines are already in cdefs.h)
> >>
> >> As the original patch this checkpatch warning is ignored:
> >> "WARNING: Adding new packed members is to be done with care"
> >
> > Strange.
> >
> > Which source files include cdefs.h?
> The host std* include this file, not a source file.
> 
> > For building u-boot images, sources should
> > only include headers in the u-boot source tree.
> > The standard system headers should not be used
> > except only a few files such as .
> >
> > This is the same as Linux Kernel.
> 
> Yes, and stdarg.h includes cdefs.h. So each include of common.h
> causes several warnings.

Oh, my dear!
This is really unfortunate.


> >
> > On the contrary, host programs are allowed to use
> > standard system headers such as ,  etc,
> > where  should not be included.
> >
> >
> > The root cause of warnings is _not_ that
> > __packed and __weak are always defined in compiler-gcc.h.
> 
> This only works properly it u-boot for the target does not depend
> on any host header at all, which as you mentioned is not the case.
> Hence we shouldn't be surprised if they define something in their
> namespace and hence checking if that is done is fine.
> 
> > I believe the real problem is there are some source files include
> > both system headers and  at the same time.
> >
> 
> No it is a header issue only. The only alternative I can think of is a
> custom version of stdarg etc and I don't really like that idea.

Me neither.


Thanks for explaining this and fully understood.

Acked-by: Masahiro Yamada 


(Ideally, I hope a little more comments
because I did not know  on FreeBSD defines __packed, __weak etc.)




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 2/7] ls102xa: pblimage: Add pblimage tool support for LS102xA

[Albert ARIBAUD]

Hi Alison,

On Thu, 18 Sep 2014 13:47:14 +0800, Alison Wang 
wrote:

> For LS102xA, the initialized next_pbl_cmd should be the sum of
> 0x8100, the lower 24 bits of CONFIG_SPL_TEXT_BASE and
> CONFIG_SPL_MAX_SIZE(0x1a000). The sum is different from PowerPC.
> The PBI CRC command is different from PowerPC too.
> In pblimage tool, add the support for the above two issues.
> 
> Signed-off-by: Alison Wang 
> ---
>  tools/pblimage.c | 20 
>  1 file changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/pblimage.c b/tools/pblimage.c
> index 6e6e801..152678b 100644
> --- a/tools/pblimage.c
> +++ b/tools/pblimage.c
> @@ -12,6 +12,10 @@
>   * Initialize to an invalid value.
>   */
>  static uint32_t next_pbl_cmd = 0x8200;
> +static uint32_t pbl_cmd_initaddr = 0x8200;
> +static uint32_t pbi_crc_cmd1 = 0x13;
> +static uint32_t pbi_crc_cmd2 = 0x80;
> +
>  /*
>   * need to store all bytes in memory for calculating crc32, then write the
>   * bytes to image file for PBL boot.
> @@ -49,7 +53,7 @@ static void init_next_pbl_cmd(FILE *fp_uboot)
>   exit(EXIT_FAILURE);
>   }
>  
> - next_pbl_cmd = 0x8200 - st.st_size;
> + next_pbl_cmd = pbl_cmd_initaddr - st.st_size;
>  }
>  
>  static void generate_pbl_cmd(void)
> @@ -81,7 +85,7 @@ static void pbl_fget(size_t size, FILE *stream)
>  static void load_uboot(FILE *fp_uboot)
>  {
>   init_next_pbl_cmd(fp_uboot);
> - while (next_pbl_cmd < 0x8200) {
> + while (next_pbl_cmd < pbl_cmd_initaddr) {
>   generate_pbl_cmd();
>   pbl_fget(64, fp_uboot);
>   }
> @@ -111,6 +115,14 @@ static void pbl_parser(char *name)
>   size_t len = 0;
>  
>   fname = name;
> +
> + if (strstr(fname, "ls102xa")) {
> + next_pbl_cmd = 0x8101a000;
> + pbl_cmd_initaddr = 0x8101a000;
> + pbi_crc_cmd1 = 0x61;
> + pbi_crc_cmd2 = 0;
> + }

Basing the tool's behaviour on the file name is not a good approach
IMO. Can't we add some command line option to the tool to select the
right set of values?

>   fd = fopen(name, "r");
>   if (fd == NULL) {
>   printf("Error:%s - Can't open\n", fname);
> @@ -172,8 +184,8 @@ static void add_end_cmd(void)
>  
>   /* Add PBI CRC command. */
>   *pmem_buf++ = 0x08;
> - *pmem_buf++ = 0x13;
> - *pmem_buf++ = 0x80;
> + *pmem_buf++ = pbi_crc_cmd1;
> + *pmem_buf++ = pbi_crc_cmd2;
>   *pmem_buf++ = 0x40;
>   pbl_size += 4;
>  


Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: HYP/non-sec: Make a variable as a local one

[Albert ARIBAUD]

Hi Tang,

Please fix subject / commit summary to indicate which variable is to be
made local.

On Thu, 18 Sep 2014 17:12:34 +0800, Tang Yuantian
 wrote:

> Defining variable gic_dist_addr as a globe one prevents some
> functions, which use this variable, from being used before relocation
> which happened in the deep sleep resume process on Freescale SoC
> platforms.
> 
> Signed-off-by: Tang Yuantian 
> ---
>  arch/arm/cpu/armv7/virt-v7.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c
> index 651ca40..b69fd37 100644
> --- a/arch/arm/cpu/armv7/virt-v7.c
> +++ b/arch/arm/cpu/armv7/virt-v7.c
> @@ -15,8 +15,6 @@
>  #include 
>  #include 
>  
> -unsigned long gic_dist_addr;
> -
>  static unsigned int read_id_pfr1(void)
>  {
>   unsigned int reg;
> @@ -68,6 +66,12 @@ static void kick_secondary_cpus_gic(unsigned long gicdaddr)
>  
>  void __weak smp_kick_all_cpus(void)
>  {
> + unsigned long gic_dist_addr;
> +
> + gic_dist_addr = get_gicd_base_address();
> + if (gic_dist_addr == -1)
> + return;
> +
>   kick_secondary_cpus_gic(gic_dist_addr);
>  }
>  
> @@ -75,6 +79,7 @@ int armv7_init_nonsec(void)
>  {
>   unsigned int reg;
>   unsigned itlinesnr, i;
> + unsigned long gic_dist_addr;
>  
>   /* check whether the CPU supports the security extensions */
>   reg = read_id_pfr1();

Did you check that the global was not used as a common variable between
the functions?

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] compiler.h: remove duplicated uninitialized_var

[Jeroen Hofstee]

Hello Masahiro,

On 18-09-14 04:14, Masahiro Yamada wrote:

Since clang has a different definition for uninitialized_var
it will complain that it is redefined in include/compiler.h.
Since these are already defined in linux/compiler.h just remove
this instance.

Cc: Masahiro Yamada 
Cc: Tom Rini 
Signed-off-by: Jeroen Hofstee 



I don't mind this patch but it has made me realize
another problem.


We have both include/compiler.h and include/linux/compiler.h.
Some sources use tha former and others use the latter.

I don't know how to use the right one in the right place.


no me neither, although it seems arch / drivers tend to use
linux/compiler.h more while tools include compiler.h more.


Header file policy is one of the biggest problem in U-boot.

Everyone has added ugly work-arounds to solve his own problem
without correct views or judgement.



diff --git a/include/compiler.h b/include/compiler.h
index 9afc11b..1451916 100644
--- a/include/compiler.h
+++ b/include/compiler.h
@@ -129,9 +129,6 @@ typedef unsigned long int uintptr_t;
  
  #endif /* USE_HOSTCC */
  
-/* compiler options */

-#define uninitialized_var(x)   x = x
-
  #define likely(x) __builtin_expect(!!(x), 1)
  #define unlikely(x)   __builtin_expect(!!(x), 0)
  


I am not sure if likely(x) and unlikely(x) should also
duplicated here.



yup I wondered about that too. likely / unlikely are used a lot
more though then the isolated use of uninitialized_var. And as they
don't cause any problems (the definitions are the same) I let
them alone, but I think they should be removed as well some day.

Regards,
Jeroen


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/7] spl: pbl: Add new SPL image for pblimage tool

[Albert ARIBAUD]

Hi Alison,

On Thu, 18 Sep 2014 13:47:13 +0800, Alison Wang 
wrote:

> For the pblimage tool, the SPL image is splitted into 64 byte chunks,
> and PBL needs a command for each piece. In current pblimage structure,
> the size of the SPL image should be a fixed value. Well, for LS102xA
> and some other ARM platforms, the size of the SPL image is changeable.
> So a new image spl/u-boot-spl-pbl-pad.bin is built, and the size of
> it is a fixed value "CONFIG_SPL_MAX_SIZE". Use it instead of
> spl/u-boot-spl.bin for LS102xA.
> 
> CONFIG_SPL_PBL_PAD is used to enable this function.
> 
> Signed-off-by: Alison Wang 
> ---

There is already a CONFIG_SPL_PAD_TO (see ./README). Can you not use
this?

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] ARM: HYP/non-sec: Make a variable as a local one

[Tang Yuantian]

Defining variable gic_dist_addr as a globe one prevents some
functions, which use this variable, from being used before relocation
which happened in the deep sleep resume process on Freescale SoC
platforms.

Signed-off-by: Tang Yuantian 
---
 arch/arm/cpu/armv7/virt-v7.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c
index 651ca40..b69fd37 100644
--- a/arch/arm/cpu/armv7/virt-v7.c
+++ b/arch/arm/cpu/armv7/virt-v7.c
@@ -15,8 +15,6 @@
 #include 
 #include 
 
-unsigned long gic_dist_addr;
-
 static unsigned int read_id_pfr1(void)
 {
unsigned int reg;
@@ -68,6 +66,12 @@ static void kick_secondary_cpus_gic(unsigned long gicdaddr)
 
 void __weak smp_kick_all_cpus(void)
 {
+   unsigned long gic_dist_addr;
+
+   gic_dist_addr = get_gicd_base_address();
+   if (gic_dist_addr == -1)
+   return;
+
kick_secondary_cpus_gic(gic_dist_addr);
 }
 
@@ -75,6 +79,7 @@ int armv7_init_nonsec(void)
 {
unsigned int reg;
unsigned itlinesnr, i;
+   unsigned long gic_dist_addr;
 
/* check whether the CPU supports the security extensions */
reg = read_id_pfr1();
-- 
2.1.0.27.g96db324

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] arm: ls102xa: Fixed a register definition error

[Tang Yuantian]

There are 8 SCFG_SPARECR registers in SCFG memory block, not
just one.

Signed-off-by: Tang Yuantian 
---
 arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h 
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index 7995fe2..b5db720 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -182,7 +182,7 @@ struct ccsr_scfg {
u32 etsecmcr;
u32 sdhciovserlcr;
u32 resv14[61];
-   u32 sparecr;
+   u32 sparecr[8];
 };
 
 /* Clocking */
-- 
2.1.0.27.g96db324

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 8/8] ARMv8: PSCI: Enable SMC

[Albert ARIBAUD]

Hi Arnab,

On Thu, 28 Aug 2014 02:00:01 +0530, Arnab Basu
 wrote:

> Enable the SMC instruction so that the kernel can use the psci code
> 
> Signed-off-by: Arnab Basu 
> Reviewed-by: Bhupesh Sharma 
> Cc: Marc Zyngier 
> ---
>  arch/arm/include/asm/macro.h |4 
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h
> index 0009c28..94a1e68 100644
> --- a/arch/arm/include/asm/macro.h
> +++ b/arch/arm/include/asm/macro.h
> @@ -106,7 +106,11 @@ lr   .reqx30
>  .endm
>  
>  .macro armv8_switch_to_el2_m, xreg1
> +#ifdef CONFIG_ARMV8_PSCI
> + mov \xreg1, #0x531  /* Non-secure EL0/EL1 | HVC | 64bit EL2 */
> +#else
>   mov \xreg1, #0x5b1  /* Non-secure EL0/EL1 | HVC | 64bit EL2 */

The 'mov' lines have different constant arguments in the instruction;
their explanatory comments should not be the same.

> +#endif
>   msr scr_el3, \xreg1
>   msr cptr_el3, xzr   /* Disable coprocessor traps to EL3 */
>   mov \xreg1, #0x33ff


Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] compiler_gcc: do not redefine __gnu_attributes

[Jeroen Hofstee]

Hello Masahiro,

On 18-09-14 04:13, Masahiro Yamada wrote:

Jeroen,


commit fb8ffd7cfc68b3dc44e182356a207d784cb30b34 "compiler*.h:
sync include/linux/compiler*.h with Linux 3.16" undid the changes
of 7ea50d52849fe8ffa5b5b74c979b60b1045d6fc9 "compiler_gcc: do
not redefine __gnu_attributes". Add the checks back whether these
macro's are already defined (as it causes a lot of noise on e.g.
FreeBSD where these defines are already in cdefs.h)

As the original patch this checkpatch warning is ignored:
"WARNING: Adding new packed members is to be done with care"


Strange.

Which source files include cdefs.h?

The host std* include this file, not a source file.


For building u-boot images, sources should
only include headers in the u-boot source tree.
The standard system headers should not be used
except only a few files such as .

This is the same as Linux Kernel.


Yes, and stdarg.h includes cdefs.h. So each include of common.h
causes several warnings.



On the contrary, host programs are allowed to use
standard system headers such as ,  etc,
where  should not be included.


The root cause of warnings is _not_ that
__packed and __weak are always defined in compiler-gcc.h.


This only works properly it u-boot for the target does not depend
on any host header at all, which as you mentioned is not the case.
Hence we shouldn't be surprised if they define something in their
namespace and hence checking if that is done is fine.


I believe the real problem is there are some source files include
both system headers and  at the same time.



No it is a header issue only. The only alternative I can think of is a
custom version of stdarg etc and I don't really like that idea.

Regards,
Jeroen



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/8] ARMv8: PSCI: Add linker section to hold PSCI code

[Albert ARIBAUD]

Hi Arnab,

On Thu, 28 Aug 2014 01:59:57 +0530, Arnab Basu
 wrote:

> A separate linker section makes it possible to keep this code either
> in DDR or in some secure memory location provided specifically for the
> purpose.
> 
> So far no one is using this section.
> 
> Signed-off-by: Arnab Basu 
> Reviewed-by: Bhupesh Sharma 
> Cc: Marc Zyngier 
> ---
>  arch/arm/config.mk|2 +-
>  arch/arm/cpu/armv8/u-boot.lds |   30 ++
>  2 files changed, 31 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/config.mk b/arch/arm/config.mk
> index c339e6d..9272e9c 100644
> --- a/arch/arm/config.mk
> +++ b/arch/arm/config.mk
> @@ -111,7 +111,7 @@ endif
>  
>  # limit ourselves to the sections we want in the .bin.
>  ifdef CONFIG_ARM64
> -OBJCOPYFLAGS += -j .text -j .rodata -j .data -j .u_boot_list -j .rela.dyn
> +OBJCOPYFLAGS += -j .text -j .secure_text -j .rodata -j .data -j .u_boot_list 
> -j .rela.dyn
>  else
>  OBJCOPYFLAGS += -j .text -j .secure_text -j .rodata -j .hash -j .data -j 
> .got.plt -j .u_boot_list -j .rel.dyn
>  endif
> diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds
> index 4c1..bd95fff 100644
> --- a/arch/arm/cpu/armv8/u-boot.lds
> +++ b/arch/arm/cpu/armv8/u-boot.lds
> @@ -8,6 +8,8 @@
>   * SPDX-License-Identifier:  GPL-2.0+
>   */
>  
> +#include 
> +
>  OUTPUT_FORMAT("elf64-littleaarch64", "elf64-littleaarch64", 
> "elf64-littleaarch64")
>  OUTPUT_ARCH(aarch64)
>  ENTRY(_start)
> @@ -23,6 +25,34 @@ SECTIONS
>   *(.text*)
>   }
>  
> +#ifdef CONFIG_ARMV8_PSCI
> +
> +#ifndef CONFIG_ARMV8_SECURE_BASE
> +#define CONFIG_ARMV8_SECURE_BASE
> +#endif
> +
> + .__secure_start : {
> + . = ALIGN(0x1000);
> + *(.__secure_start)
> + }
> +
> + .secure_text CONFIG_ARMV8_SECURE_BASE :
> + AT(ADDR(.__secure_start) + SIZEOF(.__secure_start))
> + {
> + *(._secure.text)
> + }
> +
> + . = LOADADDR(.__secure_start) +
> + SIZEOF(.__secure_start) +
> + SIZEOF(.secure_text);
> +
> + __secure_end_lma = .;
> + .__secure_end : AT(__secure_end_lma) {
> + *(.__secure_end)
> + LONG(0x1d1071c);/* Must output something to reset LMA */

Can you explain in more detail what issue this fixes?

> + }
> +#endif
> +
>   . = ALIGN(8);
>   .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
>  


Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot panasonic repo

[Wolfgang Denk]

Dear Masahiro,

In message <20140918174315.70f0.aa925...@jp.panasonic.com> you wrote:
> 
> > I did not see any negative comments for this.  So is it OK to create
> > the panasonic repo as suggested?
> 
> I really appreciate it!

OK.   I think Michal Simek posted a nice proposal for the actual work
flow to set this up.  Could you please do as he suggested?

In parallel, please send me you public SSH key (private mail).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Programmer's Lament: (Shakespeare, Macbeth, Act I, Scene vii)
"That we but teach bloody instructions,
which, being taught, return to plague the inventor..."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Call for participation in the U-Boot Mini Summit 2014

[Alexey Brodkin]

Hi Detlev,

On Wed, 2014-09-03 at 18:56 +0200, Przemyslaw Marczak wrote:
> Hello Detlev,
> 
> On 08/11/2014 05:48 PM, Przemyslaw Marczak wrote:
> > Hello Detlev,
> >
> > On 01/13/2014 06:12 PM, Detlev Zundel wrote:
> >> Hi,
> >>
> >> as already indicated, we are looking forward to our next U-Boot Mini
> >> Summit at Embedded Linux Conference Europe 2014 which will take place in
> >> Düsseldorf, Germany from October 13 - 15.
> >>
> >> The call for papers of the main conference is now open[1] and if you
> >> want to submit a talk for the main tracks, you should note the deadline
> >> of July 11.
> >>
> >> For our U-Boot Mini Summit, I'd like to get the schedule completed
> >> synchronized to the schedule release of the main event, which is August
> >> 12.  So please submit talk proposals here with at least me on CC.
> >>
> >> To coordinate the event better, I have setup another wiki page[2] that
> >> can and _should_ be edited by the interested parties.  Feel free for
> >> example to add yourself to the "interested participants" so that we get
> >> an idea of how many of the U-Boot developers will be there.
> >>
> >> Best wishes
> >>Detlev

Sorry for my late input on this regard.
But if there's still a possibility to have another talk I'd like to
propose mine "ARC - new first-class citizen in U-Boot" (which was
declined for main ELCE2014 event).

Abstract is in-lined below.

===
U-Boot is a de-facto standard bootloader for Linux-driven embedded
systems. It provides flexible means for loading kernel and if required
image of filesystem from different media be it embedded non-volatile
memory, attached storage or even network share. Linux kernel was ported
to DesignWare ARC a while ago and starting from version 3.9 the port was
accepted upstream. Now to enable real-life device booting on custom
hardware decision was made to port U-Boot for ARC. This presentation
unveils reasons to start the project, highlights milestones passed
during porting process, touches some pitfalls and encourages more
engineers and companies to use and contribute to U-Boot project.
===

I'm not sure if this kind of speech is of any interest for existing
U-boot developers, but I may indeed emphasize technical aspects now.

Any feedback is more than welcome.

Regards,
Alexey
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 00/40] ARM: tegra: Add PCIe support

[Albert ARIBAUD]

Hi Simon,

On Thu, 11 Sep 2014 13:20:03 -0600, Simon Glass 
wrote:

> Hi,
> 
> On 11 September 2014 10:17, Stephen Warren  wrote:
> > On 09/11/2014 10:00 AM, Albert ARIBAUD wrote:
> >>
> >> Hi Thierry,
> >>
> >> On Tue, 26 Aug 2014 17:33:48 +0200, Thierry Reding
> >>  wrote:
> >>
> >>> From: Thierry Reding 
> >>
> >>
> >> Note: this series was split over several custodians (including myself).
> >> It might thus get applied piecewise... Shouldn't it rather be assigned
> >> a single custodian -with others giving their Ack) and be applied as a
> >> whole? And yes, I'm ok with getting all the pieces.
> >
> >
> > Yes, applying it all in one place would probably make sense.
> >
> > IIRC, Simon Glass already applied some of the DT patches early in the
> > series? I CC'd him to check,
> 
> Yes I applied the fdt patches to u-boot-fdt/next. I can do a pull
> request to ARM if that helps, or you can just grab them.

Well, the idea was applying it all in one place :) and I don't like the
idea of pulling the fdt tree into the arm tree, so I'll pick them up,
but please give your Acked-by to them, so that PW sees it and puts it in
when I apply the patches.
  
> > BTW, Thierry is on vacation at the moment, so I don't expect he'll respond.
> 
> Regards,
> Simon

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot panasonic repo

[Masahiro Yamada]

Hi Wolfgang,



On Thu, 18 Sep 2014 10:32:46 +0200
Wolfgang Denk  wrote:

> Dear Tom,
> 
> In message <201409180927.35918.ma...@denx.de> Marek Vasut wrote:
> > 
> > I fully support that we should have a repo for the panasonic socs, it's 
> > pointless to load Albert by making him apply patches by hand and you have
> > proven numerous times that you do know what you're doing. I really see no
> > blocker for doing this.
> 
> I did not see any negative comments for this.  So is it OK to create
> the panasonic repo as suggested?


I really appreciate it!


> @ Marek and Masahiro: if we reach an agreement to create such repos,
>   please send me your SSH public keys that shall be used for
>   these.  Also, what should the names be - u-boot-socfpga ?
>   And u-boot-uniphier ? [But is there not a chance that Pana-
>   sonic might have other SoCs that might be mainlines?  So
>   maybe we should use u-boot-panasonic instead?]


This is a question I have not answered yet.


Wolfgang,
UniPhier is kind of a brand name of system LSIs developed by Panasonic.
I'd like to name u-boot-uniphier.git for some (not technical but political) 
reason.



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] arch/arm: Add individual TLB size support.

[Albert ARIBAUD]

Hi Albert,

On Thu, 11 Sep 2014 17:55:00 +0200, Albert ARIBAUD
 wrote:

> Hi li.xi...@freescale.com,
> 
> On Wed, 10 Sep 2014 03:10:27 +, "li.xi...@freescale.com"
>  wrote:
> 
> > Hi Albert,
> > 
> > > Subject: Re: [PATCH] arch/arm: Add individual TLB size support.
> > > 
> > > Hi Xiubo,
> > > 
> > > On Mon, 7 Jul 2014 13:19:11 +0800, Xiubo Li 
> > > wrote:
> > > 
> > > > This adds CONFIG_TLB_SIZE for individual board, whose TLB size maybe
> > > > larger than PGTABLE_SIZE.
> > > >
> > > > Signed-off-by: Xiubo Li 
> > > > ---
> > > >  arch/arm/lib/board.c | 4 
> > > >  1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
> > > > index dc34190..b7327ce 100644
> > > > --- a/arch/arm/lib/board.c
> > > > +++ b/arch/arm/lib/board.c
> > > > @@ -353,7 +353,11 @@ void board_init_f(ulong bootflag)
> > > >
> > > >  #if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
> > > > /* reserve TLB table */
> > > > +#ifdef CONFIG_TLB_SIZE
> > > > +   gd->arch.tlb_size = CONFIG_TLB_SIZE;
> > > > +#else
> > > > gd->arch.tlb_size = PGTABLE_SIZE;
> > > > +#endif
> > > > addr -= gd->arch.tlb_size;
> > > >
> > > > /* round down to next 64 kB limit */
> > > 
> > > There is no code in current mainline which defines CONFIG_TLB_SIZE;
> > > that makes the patch a dead code addition.
> > >
> > 
> > Yes, this will be used by our LS1 SoC first, and it is still doing
> > The upstream.
> 
> Then please sumbit this patch as part of the LS1 SoC support series,
> where the code it creates will actually be used.
>  
> > > Besides, what's the point of this as opposed to, e.g., just defining the
> > > right PGTABLE_SIZE, or renaming PGTABLE_SIZE as CONFIG_TLB_SIZE?
> > > 
> > 
> > We'll add the LPAE support in uboot and need more space for tlb.
> 
> I still don't get it. Is gd->arch.tlb_size the size of a page table or
> of a translation lookahead buffer?

Ping on both points. Meanwhile I've put the patch in 'Changes
Requested' state.

> > Thanks very much,
> > 
> > BRs
> > Xiubo
> 
> Amicalement,

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Need help with u-boot problem with usb-keyboard / kvm switch

[Hans de Goede]

Hi,

On 09/17/2014 09:19 PM, Luc Verhaegen wrote:
> On Wed, Sep 17, 2014 at 09:11:38PM +0200, Hans de Goede wrote:
>> Hi Marek, et al,
>>
>> I'm working on cleaning up Luc's hdmi out support patchset for
>> sunxi.
> 
> ?

Cleaning up may not have been the best choice of words, I was
talking about the rebase on top of upstream u-boot + the various
fixes you already know about.

I plan to submit a patch-set to the kernel for the clock resource
stuff for simplefb to the proper lists for that discussion soon,
and assuming that gets accepted I would like to land the
hdmi support in upstream u-boot soon.

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot panasonic repo

[Wolfgang Denk]

Dear Tom,

In message <201409180927.35918.ma...@denx.de> Marek Vasut wrote:
> 
> I fully support that we should have a repo for the panasonic socs, it's 
> pointless to load Albert by making him apply patches by hand and you have
> proven numerous times that you do know what you're doing. I really see no
> blocker for doing this.

I did not see any negative comments for this.  So is it OK to create
the panasonic repo as suggested?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Wisdom is one of the few things that looks bigger the further away it
is.   - Terry Pratchett, _Witches Abroad_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] Re: [PATCH 0/7] ARM: sunxi: Add basic support for Allwinner A31 (sun6i)

[Hans de Goede]

Hi,

On 09/18/2014 06:27 AM, Siarhei Siamashka wrote:
> On Tue, 09 Sep 2014 09:00:57 +0200
> Hans de Goede  wrote:
> 
>> Hi,
>>
>> On 09/08/2014 03:28 PM, Chen-Yu Tsai wrote:
>>> Hi everyone,
>>>
>>> This series add basic support for Allwinner's A31 SoC. The patches,
>>> excluding the first one, were cherry-picked from u-boot-sunxi. Due to
>>> the difference between u-boot mainline and u-boot-sunxi, some patches
>>> were rearranged or squashed to better fit the current state of u-boot,
>>> and not introduce any build breaks. It follows Ian's initial merge
>>> method of sun7i support: introducing various components first, then
>>> enabling them in the last commit. I tried to keep the commits separate,
>>> thus retaining the original author and Signed-off-bys.
>>>
>>> Patch 1 adds a wrapper around "func(USB, usb, 0)" in BOOT_TARGET_DEVICES
>>> to deal with breakage when USB support is not enabled.
>>>
>>> Patch 2 adds memory addresses for some hardware blocks new in sun6i.
>>>
>>> Patch 3 adds support for the new PRCM (power reset and clock management)
>>> block, which also contains PLL bias voltage control.
>>>
>>> Patch 4 adds support for the clock module. This patch is a bunch of
>>> different sun6i related patches on the clock code, from when sun6i
>>> support was introduced to u-boot-sunxi, up to its current form.
>>> This is done to avoid various conflicts and needlessly introducing
>>> then removing macros.
>>>
>>> Patch 5 adds mmc support on sun6i.
>>>
>>> Patch 6 adds uart0 muxing on sun6i.
>>>
>>> Patch 7 enables sun6i support and adds defconfig for the Colombus board.
>>
>> Chen,
>>
>> Many thanks for working on this!
>>
>> Just a quick not for people celebrating too early, this is the *incomplete*
>> sun7i support from the linux-sunxi/u-boot-sunxi git repo. It is fine to
>> merge this upstream, but this does not include SPL support.
>>
>> This allows replacing u-boot.bin on allwinnner sd-card images, which is
>> very useful. But it does not get us all the way to booting sun7i devices
>> we still need boot0 and boot1 binaries from allwinner for that (for now).
> 
> If I understand it correctly, one of the things that needs to be done
> in SPL is the initialization of the DRAM controller. A few weeks ago
> Oliver has updated the http://linux-sunxi.org/DRAM_Controller page
> and added a link to the 'dram_sun6i.c' file from the rhombus-tech.net
> u-boot repository:
> 
> http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/sunxi/dram_sun6i.c;hb=refs/heads/allwinner-sunxi-a31
> Does this repository look like exactly the missing part of code?

Yes it does, interesting. I had found that file before, but this one
was missing in the repo I found then:

http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-sunxi/dram.h;hb=refs/heads/allwinner-sunxi-a31

But with that one added, this is definitely interesting.

> Assuming that this code works, it provides a usable starting point
> for us.

Yep, assuming :) If no one beats me to it I'll take a look at this as
time permits.

> It looks like the Allwinner A31 DRAM controller registers are very
> similar to what is used in RK3288 (I have not checked the details,
> but if we are very lucky, it might be even a 100% perfect match):
> https://chromium-review.googlesource.com/#/c/209419/
> And thanks to the Rockchip developers (who are contributing this
> DRAM controller support code to coreboot), now we have a lot of
> named defines for the individual bitfields in the hardware
> registers. So we can decode the magic constants used in the
> Allwinner code. And thanks to Texas Instruments, we also have
> some useful documentation, which also happens to be a reasonably
> good match:
> http://www.ti.com/lit/ug/spruhn7a/spruhn7a.pdf

Sounds good / useful.

> In general, if we are on our own, then we just need to do all the
> boring work again (similar to what we did with the Allwinner
> A10/A13/A20 DRAM controller earlier). Starting with the creation of the
> http://linux-sunxi.org/A31_DRAM_Controller_Register_Guide
> wiki page and populating it with the information gathered from the
> Allwinner and Rockchip source code and also from the TI Keystone2
> documentation. Naturally, every bit of this information needs to
> be verified on real Allwinner A31 hardware before we can make any
> assumptions.

Yep.

> However Allwinner has promised to provide us with some better
> documentation later this month:
> https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg06840.html
> I don't know if they are going to include the documentation for the
> DRAM controller in the first new documentation delivery. It surely
> may be complicated, because Allwinner is obviously licensing the DRAM
> controller IP from a third party and not designing it from scratch
> (in a nice company with Rockchip and Texas Instruments). But Texas
> Instruments somehow can provide the DRAM controller documentation
> in free public access. So I 

Re: [U-Boot] U-Boot panasonic repo

[Michal Simek]

Hi guys,

On 09/18/2014 10:02 AM, Marek Vasut wrote:
> On Thursday, September 18, 2014 at 09:58:47 AM, Michal Simek wrote:
>> On 09/18/2014 09:27 AM, Marek Vasut wrote:
>>> On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote:
 Hi Michal,
>>>
>>> Hi,
>>>
 On Thu, 11 Sep 2014 06:56:04 +0200

 Michal Simek  wrote:
> Hi,
>
> On 09/11/2014 05:09 AM, Masahiro Yamada wrote:
>> On Thu, 11 Sep 2014 01:33:20 +0200
>>
>> Marek Vasut  wrote:
>>> Hello,
>>>
>>> I'd be interested in maintaining u-boot-socfpga repository. So far,
>>> we don't have a repo for this platform and there is a large flurry
>>> of patches flying around without any kind of central point for them.
>>> I'd like to get your formal consent for starting this and if you
>>> agree, I'd start sending PR to Albert once the repo is in place.
>>
>> Me too.  I'd like to own u-boot-uniphier to collect
>> Panasonic-SoC-specific changes.
>>
>> That would be faster and would not disturb Albert.
>
> I am not sure if you need to have separate repo to work like this.
> I am keeping zynq patches in my microblaze repo and sending pull
> request to Albert (or Tom now) and there is no problem with that.

 The point is that you collect Zynq-specific patches in your own place by
 yourself and then send a pull-req to Albert or Tom, right?

 It does not matter whether it is a separate u-boot-zynq repo or
 u-boot-microbraze/zynq branch.


 I have sent the first series to add the core support of Panasonic SoCs
 and boards (but it is taking much longer than I have expected)
 and then I am planning to send more features and boards in the next
 phase.


 What's the difference between what I want to do for Panasonic SoCs
 and what you usually do for Zynq SoCs?
>>>
>>> [...]
>>>
>>> I fully support that we should have a repo for the panasonic socs, it's
>>> pointless to load Albert by making him apply patches by hand and you have
>>> proven numerous times that you do know what you're doing. I really see no
>>> blocker for doing this.
>>
>> +1 on this if Masahiro wants to have separate repo.
> 
> There is no repo for those SoCs at all, so I'd be all for it.

This is the flow which is IMHO the best.

Masahiro will send the RFC patch for MAINTAINERS file to Albert
with adding his fragment for Panasonic SoCs. If Albert ACK but not apply it
that it means that he agrees with that person to be responsible for this part.
Based on that Masahiro asks for repo (if he wants it) and repo will be created.

Then he sends update patch to mailing list and after review he will apply this
patch to his repo and start to collect SoC specific patches and then send pull
request to Albert.
Also record on wiki will be updated based on that.

This seems to me like a sensible way how to do it which is transparent for 
everybody.

The same for Masahiro regarding Kconfig if Tom agrees with it.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] FW: [PATCH] usb: gadget: fastboot: improve download progress bar

[Bo Shen]

Hi Marek,

On 09/18/2014 10:32 AM, Marek Vasut wrote:

On Thursday, September 18, 2014 at 03:34:18 AM, Bo Shen wrote:

Hi Marek,

On 09/17/2014 07:16 PM, Marek Vasut wrote:

On Wednesday, September 17, 2014 at 12:28:57 PM, Bo Shen wrote:

Hi Marek,

On 09/17/2014 06:10 PM, Marek Vasut wrote:

On Wednesday, September 17, 2014 at 09:43:56 AM, Bo Shen wrote:

+CC Lukasz, this is his turf.


When download is ongoing, if the actual size of one transfer is
not the same as BTYES_PER_DOT, which will cause the dot won't
print anymore. Then it will let the user thinking it is stuck,
actually it is transfering without dot printed.

So, improve the method to show the progress bar (print dot).

Signed-off-by: Bo Shen 
---

drivers/usb/gadget/f_fastboot.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/f_fastboot.c
b/drivers/usb/gadget/f_fastboot.c index 7a1acb9..2f13bf0 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -51,6 +51,7 @@ static inline struct f_fastboot
*func_to_fastboot(struct usb_function *f) static struct
f_fastboot *fastboot_func;

static unsigned int download_size;
static unsigned int download_bytes;

+static unsigned int num_of_dot;

static struct usb_endpoint_descriptor fs_ep_in = {

.bLength= USB_DT_ENDPOINT_SIZE,

@@ -414,9 +415,10 @@ static void rx_handler_dl_image(struct
usb_ep *ep, struct usb_request *req) req->length = ep->maxpacket;

}

-   if (download_bytes && !(download_bytes % BYTES_PER_DOT)) {
+   if (download_bytes && ((download_bytes / BYTES_PER_DOT) >
num_of_dot)) { +num_of_dot = download_bytes / BYTES_PER_DOT;

putc('.');

-   if (!(download_bytes % (74 * BYTES_PER_DOT)))
+   if (!(num_of_dot % 74))

putc('\n');

}
req->actual = 0;

@@ -431,6 +433,7 @@ static void cb_download(struct usb_ep *ep,
struct usb_request *req) strsep(&cmd, ":");

download_size = simple_strtoul(cmd, NULL, 16);
download_bytes = 0;

+   num_of_dot = 0;


Make it a 'download_total' and log the total amount of bytes
transferred please, that way it can be re-used for other purposes
in the future ; for example for printing how much data were
already transferred ;-)


The download_bytes record the total amount of bytes transferred.
And the download_bytes will print after finishing transfer.


So why can this not be used to indicate the total progress ? Because
the transfeer speed is variating too much ?


As I described in the commit message. If the transfer length is not
exactly the same as the request length, then the old method
"download_bytes % BYTES_PER_DOT"
won't be 0 anymore, so for the following transfer, it won't print dot
anymore.


And can you not reset the "download_bytes" for each transfer ?


No, I don't reset the "download_bytes" for each transfer. It reset the 
"download_bytes" before transfer start.

The "download_bytes" is increase in rx_handler_dl_image function.


Maybe we're not even aligned on what "transfer" means, so we might want to sync on this 
word first. What does "transfer" mean in this case?


Transfer I mean here is a usb request, which trying to transfer 
EP_BUFFER_SIZE at one time.
In my test case, sometime it transfer less than EP_BUFFER_SIZE in a usb 
request. So, it cause dot won't print the dot, and seems stuck. However, 
it will finish transfer after some time.


Best Regards,
Bo Shen

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Cannot boot fitImage on RPi

[Jens Lucius]

Hello,

I am trying to use fitImage instead of uImage on different test-systems, 
but ran into some issues and don´t know how to proceed further.


I am building fitImage with an Yocto build system using the patches 
provided by Marek Vasut to Yocto.


My first target was the Beaglebone Black, which worked fine, it created 
a fitImage, which I booted from sd-card using the values provided in the 
docs

(U-Boot 2014.07 TI staging):

ext2load mmc 0:2 8200 /boot/fitImage
setenv bootargs root=/dev/mmcblk0p2 rootwait console=ttyO2,115200
bootm 8200



My second target was a Raspberry Pi, which I tried boot the same way:
(U-Boot 2014.07 denx master)

ext2load mmc 0:2 ${kernel_addr_r} /boot/fitImage
setenv bootargs console=ttyAMA0 kgdboc=ttyAMA0 root=/dev/mmcblk0p2 
rootfstype=ext4 rootwait

bootm ${kernel_addr_r}


Wrong Image Format for bootm command
ERROR: can't get kernel image!

iminfo ${kernel_addr_r}
## Checking Image at 0100 ...
Unknown image format!

The strange thing is, if I copy the fitImage from the Raspberry PI to 
the Beagleboard SD card and try to read it from the Beagle:


ext2load mmc 0:2 8200 /boot/fitImage.rpi
iminfo 8200

## Checking Image at 8200 ...
FIT image found
FIT description: U-Boot fitImage for Poky (Yocto Project Reference 
Distro)/3.16.2+git6159fc07f1bbda28dc967163a49fadb71225f5b3/raspberrypi



I don´t know what I did wrong, the fitImage itself seems to be working. 
Do I use the wrong address to load the Image? The commands for the RPi 
work if using uImage. I also changed the U-Boot on the RPi from the Denx 
to the TI version, also with no luck.


Any ideas?

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot panasonic repo

[Marek Vasut]

On Thursday, September 18, 2014 at 09:58:47 AM, Michal Simek wrote:
> On 09/18/2014 09:27 AM, Marek Vasut wrote:
> > On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote:
> >> Hi Michal,
> > 
> > Hi,
> > 
> >> On Thu, 11 Sep 2014 06:56:04 +0200
> >> 
> >> Michal Simek  wrote:
> >>> Hi,
> >>> 
> >>> On 09/11/2014 05:09 AM, Masahiro Yamada wrote:
>  On Thu, 11 Sep 2014 01:33:20 +0200
>  
>  Marek Vasut  wrote:
> > Hello,
> > 
> > I'd be interested in maintaining u-boot-socfpga repository. So far,
> > we don't have a repo for this platform and there is a large flurry
> > of patches flying around without any kind of central point for them.
> > I'd like to get your formal consent for starting this and if you
> > agree, I'd start sending PR to Albert once the repo is in place.
>  
>  Me too.  I'd like to own u-boot-uniphier to collect
>  Panasonic-SoC-specific changes.
>  
>  That would be faster and would not disturb Albert.
> >>> 
> >>> I am not sure if you need to have separate repo to work like this.
> >>> I am keeping zynq patches in my microblaze repo and sending pull
> >>> request to Albert (or Tom now) and there is no problem with that.
> >> 
> >> The point is that you collect Zynq-specific patches in your own place by
> >> yourself and then send a pull-req to Albert or Tom, right?
> >> 
> >> It does not matter whether it is a separate u-boot-zynq repo or
> >> u-boot-microbraze/zynq branch.
> >> 
> >> 
> >> I have sent the first series to add the core support of Panasonic SoCs
> >> and boards (but it is taking much longer than I have expected)
> >> and then I am planning to send more features and boards in the next
> >> phase.
> >> 
> >> 
> >> What's the difference between what I want to do for Panasonic SoCs
> >> and what you usually do for Zynq SoCs?
> > 
> > [...]
> > 
> > I fully support that we should have a repo for the panasonic socs, it's
> > pointless to load Albert by making him apply patches by hand and you have
> > proven numerous times that you do know what you're doing. I really see no
> > blocker for doing this.
> 
> +1 on this if Masahiro wants to have separate repo.

There is no repo for those SoCs at all, so I'd be all for it.

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot panasonic repo

[Michal Simek]

On 09/18/2014 09:27 AM, Marek Vasut wrote:
> On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote:
>> Hi Michal,
> 
> Hi,
> 
>> On Thu, 11 Sep 2014 06:56:04 +0200
>>
>> Michal Simek  wrote:
>>> Hi,
>>>
>>> On 09/11/2014 05:09 AM, Masahiro Yamada wrote:
 On Thu, 11 Sep 2014 01:33:20 +0200

 Marek Vasut  wrote:
> Hello,
>
> I'd be interested in maintaining u-boot-socfpga repository. So far, we
> don't have a repo for this platform and there is a large flurry of
> patches flying around without any kind of central point for them. I'd
> like to get your formal consent for starting this and if you agree,
> I'd start sending PR to Albert once the repo is in place.

 Me too.  I'd like to own u-boot-uniphier to collect
 Panasonic-SoC-specific changes.

 That would be faster and would not disturb Albert.
>>>
>>> I am not sure if you need to have separate repo to work like this.
>>> I am keeping zynq patches in my microblaze repo and sending pull request
>>> to Albert (or Tom now) and there is no problem with that.
>>
>> The point is that you collect Zynq-specific patches in your own place by
>> yourself and then send a pull-req to Albert or Tom, right?
>>
>> It does not matter whether it is a separate u-boot-zynq repo or
>> u-boot-microbraze/zynq branch.
>>
>>
>> I have sent the first series to add the core support of Panasonic SoCs
>> and boards (but it is taking much longer than I have expected)
>> and then I am planning to send more features and boards in the next phase.
>>
>>
>> What's the difference between what I want to do for Panasonic SoCs
>> and what you usually do for Zynq SoCs?
> 
> [...]
> 
> I fully support that we should have a repo for the panasonic socs, it's 
> pointless to load Albert by making him apply patches by hand and you have
> proven numerous times that you do know what you're doing. I really see no
> blocker for doing this.

+1 on this if Masahiro wants to have separate repo.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 09/11] dm: imx: gpio: Support driver model in MXC gpio driver

[Igor Grinberg]

On 09/17/14 18:02, Simon Glass wrote:
> Add driver model support with this driver. In this case the platform data
> is in the driver. It would be better to put this into an SOC-specific file,
> but this is best attempted when more boards are moved over to use driver
> model.
> 
> Signed-off-by: Simon Glass 

Acked-by: Igor Grinberg 


-- 
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 08/11] dm: imx: Use gpio_request() to request GPIOs

[Igor Grinberg]

On 09/17/14 18:02, Simon Glass wrote:
> GPIOs should be requested before use. Without this, driver model will not
> permit the GPIO to be used.
> 
> Signed-off-by: Simon Glass 


Acked-by: Igor Grinberg 

-- 
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 07/11] imx: Add error checking to setup_i2c()

[Igor Grinberg]

On 09/17/14 18:02, Simon Glass wrote:
> Since this function can fail, check its return value.
> 
> Signed-off-by: Simon Glass 

Thanks!

Acked-by: Igor Grinberg 

-- 
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] U-Boot panasonic repo

[Marek Vasut]

On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote:
> Hi Michal,

Hi,

> On Thu, 11 Sep 2014 06:56:04 +0200
> 
> Michal Simek  wrote:
> > Hi,
> > 
> > On 09/11/2014 05:09 AM, Masahiro Yamada wrote:
> > > On Thu, 11 Sep 2014 01:33:20 +0200
> > > 
> > > Marek Vasut  wrote:
> > >> Hello,
> > >> 
> > >> I'd be interested in maintaining u-boot-socfpga repository. So far, we
> > >> don't have a repo for this platform and there is a large flurry of
> > >> patches flying around without any kind of central point for them. I'd
> > >> like to get your formal consent for starting this and if you agree,
> > >> I'd start sending PR to Albert once the repo is in place.
> > > 
> > > Me too.  I'd like to own u-boot-uniphier to collect
> > > Panasonic-SoC-specific changes.
> > > 
> > > That would be faster and would not disturb Albert.
> > 
> > I am not sure if you need to have separate repo to work like this.
> > I am keeping zynq patches in my microblaze repo and sending pull request
> > to Albert (or Tom now) and there is no problem with that.
> 
> The point is that you collect Zynq-specific patches in your own place by
> yourself and then send a pull-req to Albert or Tom, right?
> 
> It does not matter whether it is a separate u-boot-zynq repo or
> u-boot-microbraze/zynq branch.
> 
> 
> I have sent the first series to add the core support of Panasonic SoCs
> and boards (but it is taking much longer than I have expected)
> and then I am planning to send more features and boards in the next phase.
> 
> 
> What's the difference between what I want to do for Panasonic SoCs
> and what you usually do for Zynq SoCs?

[...]

I fully support that we should have a repo for the panasonic socs, it's 
pointless to load Albert by making him apply patches by hand and you have
proven numerous times that you do know what you're doing. I really see no
blocker for doing this.

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Need help with u-boot problem with usb-keyboard / kvm switch

[Marek Vasut]

On Wednesday, September 17, 2014 at 09:19:11 PM, Luc Verhaegen wrote:
> On Wed, Sep 17, 2014 at 09:11:38PM +0200, Hans de Goede wrote:
> > Hi Marek, et al,
> > 
> > I'm working on cleaning up Luc's hdmi out support patchset for
> > sunxi.
> 
> ?

Your email is missing it's contents, is that at typo ?

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] usb: gadget: fastboot: improve download progress bar

[Marek Vasut]

On Thursday, September 18, 2014 at 03:34:18 AM, Bo Shen wrote:
> Hi Marek,
> 
> On 09/17/2014 07:16 PM, Marek Vasut wrote:
> > On Wednesday, September 17, 2014 at 12:28:57 PM, Bo Shen wrote:
> >> Hi Marek,
> >> 
> >> On 09/17/2014 06:10 PM, Marek Vasut wrote:
> >>> On Wednesday, September 17, 2014 at 09:43:56 AM, Bo Shen wrote:
> >>> 
> >>> +CC Lukasz, this is his turf.
> >>> 
>  When download is ongoing, if the actual size of one transfer
>  is not the same as BTYES_PER_DOT, which will cause the dot
>  won't print anymore. Then it will let the user thinking it
>  is stuck, actually it is transfering without dot printed.
>  
>  So, improve the method to show the progress bar (print dot).
>  
>  Signed-off-by: Bo Shen 
>  ---
>  
> drivers/usb/gadget/f_fastboot.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>  
>  diff --git a/drivers/usb/gadget/f_fastboot.c
>  b/drivers/usb/gadget/f_fastboot.c index 7a1acb9..2f13bf0 100644
>  --- a/drivers/usb/gadget/f_fastboot.c
>  +++ b/drivers/usb/gadget/f_fastboot.c
>  @@ -51,6 +51,7 @@ static inline struct f_fastboot
>  *func_to_fastboot(struct usb_function *f) static struct f_fastboot
>  *fastboot_func;
>  
> static unsigned int download_size;
> static unsigned int download_bytes;
>  
>  +static unsigned int num_of_dot;
>  
> static struct usb_endpoint_descriptor fs_ep_in = {
> 
>   .bLength= USB_DT_ENDPOINT_SIZE,
>  
>  @@ -414,9 +415,10 @@ static void rx_handler_dl_image(struct usb_ep
>  *ep, struct usb_request *req) req->length = ep->maxpacket;
>  
>   }
>  
>  -if (download_bytes && !(download_bytes % BYTES_PER_DOT)) {
>  +if (download_bytes && ((download_bytes / BYTES_PER_DOT) >
>  num_of_dot)) { + num_of_dot = download_bytes / BYTES_PER_DOT;
>  
>   putc('.');
>  
>  -if (!(download_bytes % (74 * BYTES_PER_DOT)))
>  +if (!(num_of_dot % 74))
>  
>   putc('\n');
>   
>   }
>   req->actual = 0;
>  
>  @@ -431,6 +433,7 @@ static void cb_download(struct usb_ep *ep, struct
>  usb_request *req) strsep(&cmd, ":");
>  
>   download_size = simple_strtoul(cmd, NULL, 16);
>   download_bytes = 0;
>  
>  +num_of_dot = 0;
> >>> 
> >>> Make it a 'download_total' and log the total amount of bytes
> >>> transferred please, that way it can be re-used for other purposes in
> >>> the future ; for example for printing how much data were already
> >>> transferred ;-)
> >> 
> >> The download_bytes record the total amount of bytes transferred.
> >> And the download_bytes will print after finishing transfer.
> > 
> > So why can this not be used to indicate the total progress ? Because the
> > transfeer speed is variating too much ?
> 
> As I described in the commit message. If the transfer length is not
> exactly the same as the request length, then the old method
>"download_bytes % BYTES_PER_DOT"
> won't be 0 anymore, so for the following transfer, it won't print dot
> anymore.

And can you not reset the "download_bytes" for each transfer ?

Maybe we're not even aligned on what "transfer" means, so we might want to sync 
on this word first. What does "transfer" mean in this case?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Need help with u-boot problem with usb-keyboard / kvm switch

[Marek Vasut]

On Wednesday, September 17, 2014 at 09:29:07 PM, Eric Nelson wrote:
> Hi Hans,
> 
> On 09/17/2014 12:11 PM, Hans de Goede wrote:
> > Hi Marek, et al,
> > 
> > I'm working on cleaning up Luc's hdmi out support patchset for
> > sunxi.
> > 
> > As part of this I want to also add support for usb keyboards,
> > so as to get a full console without needing to solder wires
> > to testpoints on some boards :)
> > 
> > So when I plug in the usb coming from my kvm I get this:
> > 
> > (Re)start USB...
> > USB0:   USB EHCI 1.00
> > scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
> > 3 USB Device(s) found
> > 
> >scanning usb for storage devices... 0 Storage Device(s) found
> > 
> > And the usb keyboard does not work.
> > 
> > If I plug in a single usb-2 hub (no ohci support for sunxi in u-boot
> > yet), then things do work, but after a few minutes of inactivity the
> > usb code starts spamming the console with:
> > 
> > EHCI timed out on TD - token=0x80008c80
> > EHCI timed out on TD - token=0x80008c80
> > ...
> > 
> > Could this be a problem with the phy settings (iow a sunxi specific
> > problem)?
> 
> Probably not.
> 
> We've seen the same thing on SABRE Lite and Nitrogen6X boards.

I agree, this happens. Which controller and driver do you use on the Sunxi 
hardware?

btw you can check if this is a cache issue by disabling dcache (set 
CONFIG_CMD_CACHE in the config and use 'dcache off' before 'usb start'). You 
can 
also patch the arch/arm/lib/cache-cp15.c functions to do additional alignment 
checks (always a good idea) , just like I did that in 
arch/arm/cpu/arm926ejs/cache.c

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 v2 08/11] dm: imx: Use gpio_request() to request GPIOs

[Igor Grinberg]

On 09/17/14 17:34, Simon Glass wrote:
> Hi Igor,
> 
> On 17 September 2014 08:31, Igor Grinberg  > wrote:
> 
> On 09/17/14 17:00, Simon Glass wrote:
> > Hi Igor,
> >
> > On 17 September 2014 06:13, Igor Grinberg    >> wrote:
> >
> > Hi Simon,
> >
> > On 09/17/14 06:51, Simon Glass wrote:
> > > GPIOs should be requested before use. Without this, driver model 
> will not
> > > permit the GPIO to be used.
> > >
> > > Signed-off-by: Simon Glass    >>
> > > ---
> > >
> > > Changes in v2:
> > > - Check return values of gpio_request()
> > >
> > >  arch/arm/imx-common/i2c-mxv7.c | 24 
> > >  board/compulab/cm_fx6/cm_fx6.c | 15 +++
> > >  board/compulab/cm_fx6/common.c |  7 +++
> > >  3 files changed, 46 insertions(+)
> > >
> 
> [...]
> 
> > > diff --git a/board/compulab/cm_fx6/common.c 
> b/board/compulab/cm_fx6/common.c
> > > index 1f39679..e4d7e2e 100644
> > > --- a/board/compulab/cm_fx6/common.c
> > > +++ b/board/compulab/cm_fx6/common.c
> > > @@ -79,6 +79,13 @@ void cm_fx6_set_ecspi_iomux(void)
> > >
> > >  int board_spi_cs_gpio(unsigned bus, unsigned cs)
> > >  {
> > > +#ifndef CONFIG_SPL_BUILD
> > > + int ret;
> > > +
> > > + ret = gpio_request(CM_FX6_ECSPI_BUS0_CS0, "ecspi_bus0_cs0");
> > > + if (ret)
> > > + return ret;
> > > +#endif
> >
> > Is there a reason for excluding this request from spl builds?
> > We do build with CONFIG_SPL_GPIO_SUPPORT and we don't have a
> > problem with spl size.
> > So, if there is no strong reason to exclude it from spl build,
> > I'd like to remove the #ifndef.
> >
> >
> > It isn't supported by DM yet.
> 
> AFAICS, gpio_request() is available for SPL.
> So in such case the non-DM version will be used and
> I can't see any problem with this (unless it does not work for some 
> reason).
> 
> 
> I suggest that if you wanted the gpio_request() in the non-DM case you would 
> already have added it?

I would thought so too... Unfortunately, it has slipped through...

> 
> I would prefer not to have an #ifdef CONFIG_DM_GPIO here also. Can we revisit 
> when DM supports SPL?

Yes, no problem.

-- 
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot