Re: [U-Boot] [PATCH V2 17/18] arm: mx6: cm_fx6: use eeprom

2014-08-14 Thread Igor Grinberg
On 08/10/14 20:12, Nikita Kiryanov wrote:
> Use Compulab eeprom module to obtain revision number, serial number, and
> mac address from the EEPROM.
> 
> Cc: Igor Grinberg 
> Cc: Stefano Babic 
> Cc: Tom Rini 
> Signed-off-by: Nikita Kiryanov 
> ---
> Changes in V2:
>   - No changes
> 
>  board/compulab/cm_fx6/cm_fx6.c | 26 +-
>  include/configs/cm_fx6.h   |  2 ++
>  2 files changed, 27 insertions(+), 1 deletion(-)
> 
> diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
> index 1b967e5..76d7430 100644
> --- a/board/compulab/cm_fx6/cm_fx6.c
> +++ b/board/compulab/cm_fx6/cm_fx6.c

[...]

> @@ -348,5 +372,5 @@ int dram_init(void)
>  
>  u32 get_board_rev(void)
>  {
> - return 100;
> + return cl_eeprom_get_board_rev();
>  }

I would expect this function to be introduced here and
not before this patch - along with I2C support and CONFIG_REVISION_TAG.

> diff --git a/include/configs/cm_fx6.h b/include/configs/cm_fx6.h
> index 0aa88fd..adfd55e 100644
> --- a/include/configs/cm_fx6.h
> +++ b/include/configs/cm_fx6.h
> @@ -236,6 +236,8 @@
>  #define CONFIG_SYS_BOOTMAPSZ (8 << 20)
>  #define CONFIG_SETUP_MEMORY_TAGS
>  #define CONFIG_INITRD_TAG
> +#define CONFIG_REVISION_TAG
> +#define CONFIG_SERIAL_TAG
>  
>  /* misc */
>  #define CONFIG_SYS_GENERIC_BOARD
> 

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


Re: [U-Boot] [PATCH V2 18/18] arm: mx6: cm_fx6: add sata support

2014-08-14 Thread Igor Grinberg
Hi Nikita,

On 08/10/14 20:13, Nikita Kiryanov wrote:
> Add support for SATA.
> 
> Cc: Igor Grinberg 
> Cc: Stefano Babic 
> Cc: Tom Rini 
> Signed-off-by: Nikita Kiryanov 
> ---
> Changes in V2:
>   - No changes
> 
>  board/compulab/cm_fx6/cm_fx6.c | 90 
> ++
>  board/compulab/cm_fx6/common.h | 13 ++
>  include/configs/cm_fx6.h   | 36 -
>  3 files changed, 138 insertions(+), 1 deletion(-)
> 
> diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
> index 76d7430..8a48f9d 100644
> --- a/board/compulab/cm_fx6/cm_fx6.c
> +++ b/board/compulab/cm_fx6/cm_fx6.c

[...]

> @@ -23,6 +25,94 @@
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> +#ifdef CONFIG_DWC_AHSATA
> +static int cm_fx6_issd_gpios[] = {
> + /* The order of the GPIOs in the array is important! */
> + CM_FX6_SATA_PHY_SLP,
> + CM_FX6_SATA_NRSTDLY,
> + CM_FX6_SATA_PWREN,
> + CM_FX6_SATA_NSTANDBY1,
> + CM_FX6_SATA_NSTANDBY2,
> + CM_FX6_SATA_LDO_EN,
> +};
> +
> +static void cm_fx6_sata_power(int on)

Will it be/look better to use bool here?

> +{
> + int i;
> +
> + if (!on) { /* tell the iSSD that the power will be removed */
> + gpio_direction_output(CM_FX6_SATA_PWLOSS_INT, 1);
> + mdelay(10);
> + }
> +
> + for (i = 0; i < ARRAY_SIZE(cm_fx6_issd_gpios); i++) {
> + gpio_direction_output(cm_fx6_issd_gpios[i], on);
> + udelay(100);
> + }
> +
> + if (!on) /* for compatibility lower the power loss interrupt */
> + gpio_direction_output(CM_FX6_SATA_PWLOSS_INT, 0);
> +}

[...]

> +static void cm_fx6_setup_issd(void)
> +{
> + SETUP_IOMUX_PADS(sata_pads);
> + /* Make sure this gpio has logical 0 value */
> + gpio_direction_output(CM_FX6_SATA_PWLOSS_INT, 0);
> + udelay(100);
> +
> + cm_fx6_sata_power(0);
> + mdelay(250);
> + cm_fx6_sata_power(1);
> +}
> +
> +#define CM_FX6_SATA_INIT_RETRIES 10
> +int sata_initialize(void)
> +{
> + int err, i;
> +
> + cm_fx6_setup_issd();
> + for (i = 0; i < CM_FX6_SATA_INIT_RETRIES; i++) {
> + err = setup_sata();
> + if (err) {
> + printf("SATA setup failed: %d\n", err);
> + return err;
> + }
> +
> + udelay(100);
> +
> + err = __sata_initialize();
> + if (!err)
> + break;
> +
> + /* There is no device on the SATA port */
> + if (sata_port_status(0, 0) == 0)
> + break;
> +
> + /* There's a device, but link not established. Retry */
> + }
> +
> + return err;
> +}
> +#else
> +static void cm_fx6_setup_issd(void) {}

Why do you need this one?
It is only called from sata_initialize(), which is inside
#ifdef CONFIG_DWC_AHSATA
and is not available otherwise.

> +#endif
> +
>  #ifdef CONFIG_SYS_I2C_MXC
>  #define I2C_PAD_CTRL (PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
>   PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \

[...]

> diff --git a/include/configs/cm_fx6.h b/include/configs/cm_fx6.h
> index adfd55e..88925cd 100644
> --- a/include/configs/cm_fx6.h
> +++ b/include/configs/cm_fx6.h
> @@ -132,6 +132,19 @@
>   "mmcboot=echo Booting from mmc ...; " \
>   "run mmcargs; " \
>   "run doboot\0" \
> + "satadev=0\0" \
> + "sataroot=/dev/sda2 rw rootwait\0" \
> + "sataargs=setenv bootargs console=${console} " \
> + "root=${sataroot} " \
> + "${video}\0" \
> + "loadsatabootscript=fatload sata ${satadev} ${loadaddr} ${bootscr}\0" \
> + "satabootscript=echo Running bootscript from sata ...; " \
> + "source ${loadaddr}\0" \
> + "sataloadkernel=fatload sata ${satadev} ${loadaddr} ${kernel}\0" \
> + "sataloadfdt=fatload sata ${satadev} ${fdtaddr} ${fdtfile}\0" \

Can we switch to use load instead of explicit fatload?

[...]


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


Re: [U-Boot] [PATCH V3 12/18] arm: mx6: add support for Compulab cm-fx6 CoM

2014-08-14 Thread Igor Grinberg
On 08/13/14 15:55, Igor Grinberg wrote:
> Hi Nikita,
> 
> Several comments below in addition to Simon's.
> 
> On 08/11/14 19:22, Nikita Kiryanov wrote:
>> Add initial support for Compulab CM-FX6 CoM.
>> Support includes MMC, SPI flash, and SPL with dynamic DRAM detection.
>>
>> Cc: Igor Grinberg 
>> Cc: Stefano Babic 
>> Cc: Tom Rini 
>> Cc: Marek Vasut 
>> Acked-by: Marek Vasut 
>> Signed-off-by: Nikita Kiryanov 
>> ---

[...]

>> +#define CONFIG_EXTRA_ENV_SETTINGS \
>> +"kernel=uImage-cm-fx6\0" \
>> +"autoload=no\0" \
>> +"loadaddr=0x1080\0" \
>> +"fdtaddr=0x1100\0" \
>> +"console=ttymxc3,115200\0" \
>> +"ethprime=FEC0\0" \
>> +"bootscr=boot.scr\0" \
>> +"bootm_low=1800\0" \
>> +"video_hdmi=mxcfb0:dev=hdmi,1920x1080M-32@50,if=RGB32\0" \
>> +"video_dvi=mxcfb0:dev=dvi,1280x800M-32@50,if=RGB32\0" \
>> +"fdtfile=cm-fx6.dtb\0" \
>> +"doboot=bootm ${loadaddr}\0" \
>> +"loadfdt=false\0" \
>> +"setboottypez=setenv kernel zImage-cm-fx6;" \
>> +"setenv doboot bootz ${loadaddr} - ${fdtaddr};" \
>> +"setenv loadfdt true;\0" \
>> +"setboottypem=setenv kernel uImage-cm-fx6;" \
>> +"setenv doboot bootm ${loadaddr};" \
>> +"setenv loadfdt false;\0"\
>> +"run_eboot=echo Starting EBOOT ...; "\
>> +"mmc dev ${mmcdev} && " \
>> +"mmc rescan && mmc read 10042000 a 400 && go 10042000\0" \
>> +"mmcdev=2\0" \
>> +"mmcroot=/dev/mmcblk0p2 rw rootwait\0" \
>> +"loadmmcbootscript=fatload mmc ${mmcdev} ${loadaddr} ${bootscr}\0" \
> 
> Can we switch to use load instead of fatload?
> 
>> +"mmcbootscript=echo Running bootscript from mmc ...; "\
>> +"source ${loadaddr}\0" \
>> +"mmcargs=setenv bootargs console=${console} " \
>> +"root=${mmcroot} " \
>> +"${video}\0" \
>> +"mmcloadkernel=fatload mmc ${mmcdev} ${loadaddr} ${kernel}\0" \
>> +"mmcloadfdt=fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile}\0" \
>> +"mmcboot=echo Booting from mmc ...; " \
>> +"run mmcargs; " \
>> +"run doboot\0" \
>> +"nandroot=/dev/mtdblock4 rw\0" \
>> +"nandrootfstype=ubifs\0" \
>> +"nandargs=setenv bootargs console=${console} " \
>> +"root=${nandroot} " \
>> +"rootfstype=${nandrootfstype} " \
>> +"${video}\0" \
>> +"nandloadfdt=nand read ${fdtaddr} 78 8;\0" \
>> +"nandboot=echo Booting from nand ...; " \
>> +"run nandargs; " \
>> +"nand read ${loadaddr} 0 78; " \
>> +"if ${loadfdt}; then " \
>> +"run nandloadfdt;" \
>> +"fi; " \
>> +"run doboot\0" \

I think, if we add NAND support in a separate patch, then probably
it will be better also to add nand boot related environment stuff
along with the NAND support.

>> +"boot=mmc dev ${mmcdev}; " \
>> +"if mmc rescan; then " \
>> +"if run loadmmcbootscript; then " \
>> +"run mmcbootscript;" \
>> +"else " \
>> +"if run mmcloadkernel; then " \
>> +"if ${loadfdt}; then " \
>> +"run mmcloadfdt;" \
>> +"fi;" \
>> +"run mmcboot;" \
>> +"fi;" \
>> +"fi;" \
>> +"fi;"

Also, you add NAND boot commands neither here, nor in the NAND
support patch. Can we have them too? Please?


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


[U-Boot] [PATCH v4 02/18] ls102xa: i2c: Add i2c support for LS102xA

2014-08-14 Thread Alison Wang
This patch is to add I2C 1,2,3 support for LS102xA.

Signed-off-by: Alison Wang 
---
Change log:
 v4: Add commit messages.
 v3: Add I2C 3 support.
 v2: No change.

 drivers/i2c/mxc_i2c.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index c14797c..83a9ffa 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -423,7 +423,7 @@ static void * const i2c_bases[] = {
(void *)IMX_I2C2_BASE
 #elif defined(CONFIG_MX31) || defined(CONFIG_MX35) || \
defined(CONFIG_MX51) || defined(CONFIG_MX53) || \
-   defined(CONFIG_MX6)
+   defined(CONFIG_MX6) || defined(CONFIG_LS102xA)
(void *)I2C1_BASE_ADDR,
(void *)I2C2_BASE_ADDR,
(void *)I2C3_BASE_ADDR
@@ -545,7 +545,7 @@ U_BOOT_I2C_ADAP_COMPLETE(mxc1, mxc_i2c_init, mxc_i2c_probe,
 CONFIG_SYS_MXC_I2C2_SLAVE, 1)
 #if defined(CONFIG_MX31) || defined(CONFIG_MX35) ||\
defined(CONFIG_MX51) || defined(CONFIG_MX53) ||\
-   defined(CONFIG_MX6)
+   defined(CONFIG_MX6) || defined(CONFIG_LS102xA)
 U_BOOT_I2C_ADAP_COMPLETE(mxc2, mxc_i2c_init, mxc_i2c_probe,
 mxc_i2c_read, mxc_i2c_write,
 mxc_i2c_set_bus_speed,
-- 
1.8.4

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


[U-Boot] [PATCH v4 03/18] net: Merge asm/fsl_enet.h into fsl_mdio.h

2014-08-14 Thread Alison Wang
From: Claudiu Manoil 

fsl_enet.h defines the mapping of the usual MII management
registers, which are included in the MDIO register block
common to Freescale ethernet controllers. So it shouldn't
depend on the CPU architecture but it should be actually
part of the arch independent fsl_mdio.h.

To remove the arch dependency, merge the content of
asm/fsl_enet.h into fsl_mdio.h.
Some files (like fm_eth.h) were simply including fsl_enet.h
only for phy.h. These were updated to include phy.h instead.

Signed-off-by: Claudiu Manoil 
---
Change log:
 v4: No change.
 v3: No change.
 v2: No change.

 arch/powerpc/include/asm/fsl_enet.h   | 24 
 board/freescale/mpc8360emds/mpc8360emds.c |  2 +-
 board/freescale/mpc837xemds/mpc837xemds.c |  1 -
 drivers/net/fm/dtsec.c|  1 -
 drivers/net/fm/fm.h   |  2 +-
 drivers/net/fm/init.c |  1 +
 drivers/net/fm/memac.c|  1 -
 drivers/net/fm/tgec.c |  1 -
 drivers/net/fsl_mdio.c|  1 -
 drivers/qe/uec.h  |  1 -
 include/fm_eth.h  |  2 +-
 include/fsl_mdio.h| 13 -
 include/tsec.h|  2 +-
 13 files changed, 17 insertions(+), 35 deletions(-)
 delete mode 100644 arch/powerpc/include/asm/fsl_enet.h

diff --git a/arch/powerpc/include/asm/fsl_enet.h 
b/arch/powerpc/include/asm/fsl_enet.h
deleted file mode 100644
index 96146b6..000
--- a/arch/powerpc/include/asm/fsl_enet.h
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * Copyright 2010 Freescale Semiconductor, Inc.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef __ASM_PPC_FSL_ENET_H
-#define __ASM_PPC_FSL_ENET_H
-
-#include 
-
-struct tsec_mii_mng {
-   u32 miimcfg;/* MII management configuration reg */
-   u32 miimcom;/* MII management command reg */
-   u32 miimadd;/* MII management address reg */
-   u32 miimcon;/* MII management control reg */
-   u32 miimstat;   /* MII management status reg  */
-   u32 miimind;/* MII management indication reg */
-   u32 ifstat; /* Interface Status Register */
-} __attribute__ ((packed));
-
-int fdt_fixup_phy_connection(void *blob, int offset, phy_interface_t phyc);
-
-#endif /* __ASM_PPC_FSL_ENET_H */
diff --git a/board/freescale/mpc8360emds/mpc8360emds.c 
b/board/freescale/mpc8360emds/mpc8360emds.c
index ac96163..5ff9dff 100644
--- a/board/freescale/mpc8360emds/mpc8360emds.c
+++ b/board/freescale/mpc8360emds/mpc8360emds.c
@@ -11,13 +11,13 @@
 #include 
 #include 
 #include 
+#include 
 #if defined(CONFIG_PCI)
 #include 
 #endif
 #include 
 #include 
 #include 
-#include 
 #include 
 #if defined(CONFIG_OF_LIBFDT)
 #include 
diff --git a/board/freescale/mpc837xemds/mpc837xemds.c 
b/board/freescale/mpc837xemds/mpc837xemds.c
index 0a3c972..c749e55 100644
--- a/board/freescale/mpc837xemds/mpc837xemds.c
+++ b/board/freescale/mpc837xemds/mpc837xemds.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/net/fm/dtsec.c b/drivers/net/fm/dtsec.c
index 78bbd43..8d3dc0e 100644
--- a/drivers/net/fm/dtsec.c
+++ b/drivers/net/fm/dtsec.c
@@ -7,7 +7,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/net/fm/fm.h b/drivers/net/fm/fm.h
index 316e06e..a9691c6 100644
--- a/drivers/net/fm/fm.h
+++ b/drivers/net/fm/fm.h
@@ -8,8 +8,8 @@
 #define __FM_H__
 
 #include 
+#include 
 #include 
-#include 
 #include 
 
 /* Port ID */
diff --git a/drivers/net/fm/init.c b/drivers/net/fm/init.c
index ff04695..6cf21c6 100644
--- a/drivers/net/fm/init.c
+++ b/drivers/net/fm/init.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "fm.h"
 
diff --git a/drivers/net/fm/memac.c b/drivers/net/fm/memac.c
index 592a67f..9499290 100644
--- a/drivers/net/fm/memac.c
+++ b/drivers/net/fm/memac.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "fm.h"
diff --git a/drivers/net/fm/tgec.c b/drivers/net/fm/tgec.c
index f450f80..5017123 100644
--- a/drivers/net/fm/tgec.c
+++ b/drivers/net/fm/tgec.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "fm.h"
diff --git a/drivers/net/fsl_mdio.c b/drivers/net/fsl_mdio.c
index 1d88e65..8d09f5d 100644
--- a/drivers/net/fsl_mdio.c
+++ b/drivers/net/fsl_mdio.c
@@ -11,7 +11,6 @@
 #include 
 #include 
 #include 
-#include 
 
 void tsec_local_mdio_write(struct tsec_mii_mng __iomem *phyregs, int port_addr,
int dev_addr, int regnum, int value)
diff --git a/drivers/qe/uec.h b/drivers/qe/uec.h
index 48a1634..6b559f7 100644
--- a/drivers/qe/uec.h
+++ b/drivers/qe/uec.h
@@ -13,7 +13,6 @@
 #include "qe.h"
 #include "uccf.h"
 #include 
-#include 
 
 #define MAX_TX_THREADS 8
 #define MAX_RX_THREADS

[U-Boot] [PATCH v4 05/18] net: mdio: Use mb() to be compatible for both ARM and PowerPC

2014-08-14 Thread Alison Wang
Use mb() instead of sync assembly instruction to be
compatible for both ARM and PowerPC.

Signed-off-by: Alison Wang 
---
Change log:
 v4: No change.
 v3: Use mb() to be compatible for both ARM and PowerPC.
 Split from the 0004-arm-ls102xa-Add-etsec-support-for-LS102xA patch.
 v2: Add private mdio read and write support. 

 drivers/net/fsl_mdio.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/fsl_mdio.c b/drivers/net/fsl_mdio.c
index 6eae78f..2657c44 100644
--- a/drivers/net/fsl_mdio.c
+++ b/drivers/net/fsl_mdio.c
@@ -19,7 +19,7 @@ void tsec_local_mdio_write(struct tsec_mii_mng __iomem 
*phyregs, int port_addr,
 
out_be32(&phyregs->miimadd, (port_addr << 8) | (regnum & 0x1f));
out_be32(&phyregs->miimcon, value);
-   asm("sync");
+   mb();
 
while ((in_be32(&phyregs->miimind) & MIIMIND_BUSY) && timeout--)
;
@@ -37,11 +37,11 @@ int tsec_local_mdio_read(struct tsec_mii_mng __iomem 
*phyregs, int port_addr,
 
/* Clear the command register, and wait */
out_be32(&phyregs->miimcom, 0);
-   asm("sync");
+   mb();
 
/* Initiate a read command, and wait */
out_be32(&phyregs->miimcom, MIIMCOM_READ_CYCLE);
-   asm("sync");
+   mb();
 
/* Wait for the the indication that the read is done */
while ((in_be32(&phyregs->miimind) & (MIIMIND_NOTVALID | MIIMIND_BUSY))
-- 
1.8.4

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


[U-Boot] [PATCH v4 07/18] ls102xa: esdhc: Add esdhc support for LS102xA

2014-08-14 Thread Alison Wang
For LS102xA, the platform is little endian, while esdhc IP is
big endian. So two macros are added, CONFIG_SYS_FSL_ESDHC_LE
and CONFIG_SYS_FSL_ESDHC_BE, to determine the registers'
reading/writing in big or little endian format.

Signed-off-by: Alison Wang 
---
Change log:
 v4: No change.
 v3: Add commit messages.
 v2: No change.

 drivers/mmc/fsl_esdhc.c |  4 ++--
 include/fsl_esdhc.h | 14 +-
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 5541613..aec459f 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -96,7 +96,7 @@ static uint esdhc_xfertyp(struct mmc_cmd *cmd, struct 
mmc_data *data)
else if (cmd->resp_type & MMC_RSP_PRESENT)
xfertyp |= XFERTYP_RSPTYP_48;
 
-#if defined(CONFIG_MX53) || defined(CONFIG_PPC_T4240)
+#if defined(CONFIG_MX53) || defined(CONFIG_PPC_T4240) || 
defined(CONFIG_LS102xA)
if (cmd->cmdidx == MMC_CMD_STOP_TRANSMISSION)
xfertyp |= XFERTYP_CMDTYP_ABORT;
 #endif
@@ -561,7 +561,7 @@ int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg 
*cfg)
memset(&cfg->cfg, 0, sizeof(cfg->cfg));
 
voltage_caps = 0;
-   caps = regs->hostcapblt;
+   caps = esdhc_read32(®s->hostcapblt);
 
 #ifdef CONFIG_SYS_FSL_ERRATUM_ESDHC135
caps = caps & ~(ESDHC_HOSTCAPBLT_SRS |
diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
index 9814964..c1b6648 100644
--- a/include/fsl_esdhc.h
+++ b/include/fsl_esdhc.h
@@ -162,7 +162,19 @@ struct fsl_esdhc_cfg {
 };
 
 /* Select the correct accessors depending on endianess */
-#if __BYTE_ORDER == __LITTLE_ENDIAN
+#if defined CONFIG_SYS_FSL_ESDHC_LE
+#define esdhc_read32   in_le32
+#define esdhc_write32  out_le32
+#define esdhc_clrsetbits32 clrsetbits_le32
+#define esdhc_clrbits32clrbits_le32
+#define esdhc_setbits32setbits_le32
+#elif defined(CONFIG_SYS_FSL_ESDHC_BE)
+#define esdhc_read32in_be32
+#define esdhc_write32   out_be32
+#define esdhc_clrsetbits32  clrsetbits_be32
+#define esdhc_clrbits32 clrbits_be32
+#define esdhc_setbits32 setbits_be32
+#elif __BYTE_ORDER == __LITTLE_ENDIAN
 #define esdhc_read32   in_le32
 #define esdhc_write32  out_le32
 #define esdhc_clrsetbits32 clrsetbits_le32
-- 
1.8.4

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


[U-Boot] [PATCH v4 01/18] arm: ls102xa: Add Freescale LS102xA SoC support

2014-08-14 Thread Alison Wang
From: Wang Huan 

The QorIQ LS1 family is built on Layerscape architecture,
the industry's first software-aware, core-agnostic networking
architecture to offer unprecedented efficiency and scale.

Freescale LS102xA is a set of SoCs combines two ARM
Cortex-A7 cores that have been optimized for high
reliability and pack the highest level of integration
available for sub-3 W embedded communications processors
with Layerscape architecture and with a comprehensive
enablement model focused on ease of programmability.

Signed-off-by: Alison Wang 
Signed-off-by: Jason Jin 
Signed-off-by: Jingchang Lu 
Signed-off-by: Prabhakar Kushwaha 
---
Change log:
 v4: No change.
 v3: Fix checkpatch errors.
 v2: Add serdes support.
 Update DDR frequency and data rate information.
 Fix overflow condition error for the timer.

 arch/arm/cpu/armv7/ls102xa/Makefile   |  12 +
 arch/arm/cpu/armv7/ls102xa/clock.c| 130 ++
 arch/arm/cpu/armv7/ls102xa/cpu.c  | 103 +
 arch/arm/cpu/armv7/ls102xa/fdt.c  | 128 ++
 arch/arm/cpu/armv7/ls102xa/fsl_ls1_serdes.c   | 119 ++
 arch/arm/cpu/armv7/ls102xa/fsl_ls1_serdes.h   |  12 +
 arch/arm/cpu/armv7/ls102xa/ls102xa_serdes.c   |  41 ++
 arch/arm/cpu/armv7/ls102xa/timer.c| 127 ++
 arch/arm/include/asm/arch-ls102xa/clock.h |  23 ++
 arch/arm/include/asm/arch-ls102xa/config.h|  71 
 arch/arm/include/asm/arch-ls102xa/fsl_serdes.h|  33 ++
 arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 461 ++
 arch/arm/include/asm/arch-ls102xa/imx-regs.h  |  53 +++
 arch/arm/include/asm/config.h |   4 +
 arch/arm/include/asm/io.h |   8 +-
 drivers/watchdog/Makefile |   2 +-
 16 files changed, 1325 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/ls102xa/Makefile
 create mode 100644 arch/arm/cpu/armv7/ls102xa/clock.c
 create mode 100644 arch/arm/cpu/armv7/ls102xa/cpu.c
 create mode 100644 arch/arm/cpu/armv7/ls102xa/fdt.c
 create mode 100644 arch/arm/cpu/armv7/ls102xa/fsl_ls1_serdes.c
 create mode 100644 arch/arm/cpu/armv7/ls102xa/fsl_ls1_serdes.h
 create mode 100644 arch/arm/cpu/armv7/ls102xa/ls102xa_serdes.c
 create mode 100644 arch/arm/cpu/armv7/ls102xa/timer.c
 create mode 100644 arch/arm/include/asm/arch-ls102xa/clock.h
 create mode 100644 arch/arm/include/asm/arch-ls102xa/config.h
 create mode 100644 arch/arm/include/asm/arch-ls102xa/fsl_serdes.h
 create mode 100644 arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
 create mode 100644 arch/arm/include/asm/arch-ls102xa/imx-regs.h

diff --git a/arch/arm/cpu/armv7/ls102xa/Makefile 
b/arch/arm/cpu/armv7/ls102xa/Makefile
new file mode 100644
index 000..d82ce8d
--- /dev/null
+++ b/arch/arm/cpu/armv7/ls102xa/Makefile
@@ -0,0 +1,12 @@
+#
+# Copyright 2014 Freescale Semiconductor, Inc.
+#
+# SPDX-License-Identifier:  GPL-2.0+
+#
+
+obj-y  += cpu.o
+obj-y  += clock.o
+obj-y  += timer.o
+
+obj-$(CONFIG_OF_LIBFDT) += fdt.o
+obj-$(CONFIG_SYS_HAS_SERDES) += fsl_ls1_serdes.o ls102xa_serdes.o
diff --git a/arch/arm/cpu/armv7/ls102xa/clock.c 
b/arch/arm/cpu/armv7/ls102xa/clock.c
new file mode 100644
index 000..8f80c61
--- /dev/null
+++ b/arch/arm/cpu/armv7/ls102xa/clock.c
@@ -0,0 +1,130 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifndef CONFIG_SYS_FSL_NUM_CC_PLLS
+#define CONFIG_SYS_FSL_NUM_CC_PLLS  2
+#endif
+
+void get_sys_info(struct sys_info *sys_info)
+{
+   struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
+#ifdef CONFIG_FSL_IFC
+   struct fsl_ifc *ifc_regs = (void *)CONFIG_SYS_IFC_ADDR;
+   u32 ccr;
+#endif
+   struct ccsr_clk *clk = (void *)(CONFIG_SYS_FSL_LS1_CLK_ADDR);
+   unsigned int cpu;
+   const u8 core_cplx_pll[6] = {
+   [0] = 0,/* CC1 PPL / 1 */
+   [1] = 0,/* CC1 PPL / 2 */
+   [4] = 1,/* CC2 PPL / 1 */
+   [5] = 1,/* CC2 PPL / 2 */
+   };
+
+   const u8 core_cplx_pll_div[6] = {
+   [0] = 1,/* CC1 PPL / 1 */
+   [1] = 2,/* CC1 PPL / 2 */
+   [4] = 1,/* CC2 PPL / 1 */
+   [5] = 2,/* CC2 PPL / 2 */
+   };
+
+   uint i;
+   uint freq_c_pll[CONFIG_SYS_FSL_NUM_CC_PLLS];
+   uint ratio[CONFIG_SYS_FSL_NUM_CC_PLLS];
+   unsigned long sysclk = CONFIG_SYS_CLK_FREQ;
+
+   sys_info->freq_systembus = sysclk;
+#ifdef CONFIG_DDR_CLK_FREQ
+   sys_info->freq_ddrbus = CONFIG_DDR_CLK_FREQ;
+#else
+   sys_info->freq_ddrbus = sysclk;
+#endif
+
+   sys_info->freq_systembus *= (in_be32(&gur->rcwsr[0]) >>
+   RCWSR0_SYS_PLL_RAT_SHIFT) & RCWSR0_SYS_PLL_RAT_MASK;
+   sys_info->freq_ddrbus *= (in_be32(&gur->rcwsr[0]) >>

[U-Boot] [PATCH v4 0/18] arm: ls102xa: Add Freescale LS102xA SoC and LS1021AQDS/TWR board support

2014-08-14 Thread Alison Wang
This series contain the support for Freescale LS102xA SoC
and LS1021AQDS/TWR board.

The QorIQ LS1 family is built on Layerscape architecture,
the industry's first software-aware, core-agnostic networking
architecture to offer unprecedented efficiency and scale.

Freescale LS102xA is a set of SoCs combines two ARM Cortex-A7
cores that have been optimized for high reliability and pack
the highest level of integration available for sub-3 W embedded
communications processors with Layerscape architecture and with
a comprehensive enablement model focused on ease of programmability.

For the detail information about LS1021AQDS/TWR board, please
refer to README in the patch.

Changes in v4:
- Add commit messages.

Changes in v3:
- Fix checkpatch errors.
- Add I2C 3 support.
- Split arm: ls102xa: Add etsec support for LS102xA into 3 patches. The 
3 patches:
  net: mdio: Add private MDIO read/write function,
  net: mdio: Use mb() to be compatible for both ARM and PowerPC,
  ls102xa: etsec: Add etsec support for LS102xA.
- Use mb() to be compatible for both ARM and PowerPC.
- Update to Kconfig.
- Add new patches:
  net: tsec: Remove tx snooping support from LS1
  serial: lpuart: add 32-bit registers lpuart support
  arm: ls102xa: Add LETECH support for LS1021AQDS/TWR board
  video: dcu: Add Sii9022A HDMI Transmitter support
  video: dcu: Add DCU driver support
  ls102xa: dcu: Add platform support for DCU on LS1021ATWR board

Changes in v2:
- Add serdes support.
- Update DDR frequency and data rate information.
- Fix overflow condition error for the timer.
- Add private mdio read and write support.
- Remove ethaddr/ipaddr setting.
- Add board maintainer.
- Add serdes and multiple ethernet controllers support.
- Add new patch:
  arm: ls102xa: Add basic support for LS1021ATWR board

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


[U-Boot] [PATCH v4 09/18] driver/ddr/freescale: Fix DDR3 driver for ARM

2014-08-14 Thread Alison Wang
From: York Sun 

Reading DDR register should use ddr_in32() for proper endianess.
This patch fixes incorrect waiting time for ARM platforms.

Signed-off-by: York Sun 
---
Change log:
 v4: No change.
 v3: No change.
 v2: No change.

 drivers/ddr/fsl/arm_ddr_gen3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ddr/fsl/arm_ddr_gen3.c b/drivers/ddr/fsl/arm_ddr_gen3.c
index d4ed9ae..59f2fd6 100644
--- a/drivers/ddr/fsl/arm_ddr_gen3.c
+++ b/drivers/ddr/fsl/arm_ddr_gen3.c
@@ -194,7 +194,7 @@ step2:
 * For example, 2GB on 666MT/s 64-bit bus takes about 402ms
 * Let's wait for 800ms
 */
-   bus_width = 3 - ((ddr->sdram_cfg & SDRAM_CFG_DBW_MASK)
+   bus_width = 3 - ((ddr_in32(&ddr->sdram_cfg) & SDRAM_CFG_DBW_MASK)
>> SDRAM_CFG_DBW_SHIFT);
timeout = ((total_gb_size_per_controller << (6 - bus_width)) * 100 /
(get_ddr_freq(0) >> 20)) << 1;
-- 
1.8.4

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


[U-Boot] [PATCH v4 06/18] ls102xa: etsec: Add etsec support for LS102xA

2014-08-14 Thread Alison Wang
For LS102xA, RxBDs and TxBDs are interpreted with little-endian
bytes ordering. The offset for each of eTSECs and MDIOs is
256K bytes.

Signed-off-by: Alison Wang 
---
Change log:
 v4: No change.
 v3: No change.
 v2: Add private mdio read and write support.

 drivers/net/tsec.c | 7 +++
 include/tsec.h | 7 ++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index e9138f0..a220221 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -270,6 +271,9 @@ void redundant_init(struct eth_device *dev)
out_be32(®s->tstat, TSTAT_CLEAR_THALT);
out_be32(®s->rstat, RSTAT_CLEAR_RHALT);
clrbits_be32(®s->dmactrl, DMACTRL_GRS | DMACTRL_GTS);
+#ifdef CONFIG_LS102xA
+   setbits_be32(®s->dmactrl, DMACTRL_LE);
+#endif
 
do {
uint16_t status;
@@ -366,6 +370,9 @@ static void startup_tsec(struct eth_device *dev)
out_be32(®s->tstat, TSTAT_CLEAR_THALT);
out_be32(®s->rstat, RSTAT_CLEAR_RHALT);
clrbits_be32(®s->dmactrl, DMACTRL_GRS | DMACTRL_GTS);
+#ifdef CONFIG_LS102xA
+   setbits_be32(®s->dmactrl, DMACTRL_LE);
+#endif
 }
 
 /* This returns the status bits of the device. The return value
diff --git a/include/tsec.h b/include/tsec.h
index 2054715..5b74f67 100644
--- a/include/tsec.h
+++ b/include/tsec.h
@@ -20,10 +20,14 @@
 #include 
 #include 
 #include 
-#include 
 
+#ifdef CONFIG_LS102xA
+#define TSEC_SIZE  0x4
+#define TSEC_MDIO_OFFSET   0x4
+#else
 #define TSEC_SIZE  0x01000
 #define TSEC_MDIO_OFFSET   0x01000
+#endif
 
 #define CONFIG_SYS_MDIO_BASE_ADDR (MDIO_BASE_ADDR + 0x520)
 
@@ -128,6 +132,7 @@
 #define DMACTRL_INIT_SETTINGS  0x00c3
 #define DMACTRL_GRS0x0010
 #define DMACTRL_GTS0x0008
+#define DMACTRL_LE 0x8000
 
 #define TSTAT_CLEAR_THALT  0x8000
 #define RSTAT_CLEAR_RHALT  0x0080
-- 
1.8.4

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


[U-Boot] [PATCH v4 08/18] driver/ddr/freescale: Add support of accumulate ECC

2014-08-14 Thread Alison Wang
From: York Sun 

If less than 8 ECC pins are used for DDR data bus width smaller than 64
bits, the 8-bit ECC code will be transmitted/received across several beats,
and it will be used to check 64-bits of data once 8-bits of ECC are
accumulated.

Signed-off-by: York Sun 
---
Change log:
 v4: No change.
 v3: No change.
 v2: No change.

 drivers/ddr/fsl/ctrl_regs.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c
index 04e4178..5e0ee77 100644
--- a/drivers/ddr/fsl/ctrl_regs.c
+++ b/drivers/ddr/fsl/ctrl_regs.c
@@ -693,6 +693,7 @@ static void set_ddr_sdram_cfg(fsl_ddr_cfg_regs_t *ddr,
unsigned int x32_en = 0;/* x32 enable */
unsigned int pchb8 = 0; /* precharge bit 8 enable */
unsigned int hse;   /* Global half strength override */
+   unsigned int acc_ecc_en = 0;/* Accumulated ECC enable */
unsigned int mem_halt = 0;  /* memory controller halt */
unsigned int bi = 0;/* Bypass initialization */
 
@@ -736,6 +737,9 @@ static void set_ddr_sdram_cfg(fsl_ddr_cfg_regs_t *ddr,
ba_intlv_ctl = popts->ba_intlv_ctl;
hse = popts->half_strength_driver_enable;
 
+   /* set when ddr bus width < 64 */
+   acc_ecc_en = (dbw != 0 && ecc_en == 1) ? 1 : 0;
+
ddr->ddr_sdram_cfg = (0
| ((mem_en & 0x1) << 31)
| ((sren & 0x1) << 30)
@@ -752,6 +756,7 @@ static void set_ddr_sdram_cfg(fsl_ddr_cfg_regs_t *ddr,
| ((x32_en & 0x1) << 5)
| ((pchb8 & 0x1) << 4)
| ((hse & 0x1) << 3)
+   | ((acc_ecc_en & 0x1) << 2)
| ((mem_halt & 0x1) << 1)
| ((bi & 0x1) << 0)
);
-- 
1.8.4

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


[U-Boot] [PATCH v4 10/18] driver/ddr/fsl: Add support of overriding chip select write leveling

2014-08-14 Thread Alison Wang
From: York Sun 

JEDEC spec allows DRAM vendors to use prime DQ for write leveling. This
is not an issue unless some DQ pins are not connected. If a platform uses
regular DIMMs but with reduced DDR ECC pins, the prime DQ may end up on
those floating pins for the second rank. The workaround is to use a known
good chip select for this purpose.

Signed-off-by: York Sun 
---
Change log:
 v4: No change.
 v3: No change.
 v2: No change.

 drivers/ddr/fsl/ctrl_regs.c   | 3 +++
 drivers/ddr/fsl/interactive.c | 2 ++
 include/fsl_ddr_sdram.h   | 2 ++
 3 files changed, 7 insertions(+)

diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c
index 5e0ee77..d9cac22 100644
--- a/drivers/ddr/fsl/ctrl_regs.c
+++ b/drivers/ddr/fsl/ctrl_regs.c
@@ -2276,6 +2276,9 @@ compute_fsl_memctl_config_regs(const memctl_options_t 
*popts,
if (ip_rev > 0x40400)
unq_mrs_en = 1;
 
+   if (ip_rev > 0x40700)
+   ddr->debug[18] = popts->cswl_override;
+
set_ddr_sdram_cfg_2(ddr, popts, unq_mrs_en);
set_ddr_sdram_mode(ddr, popts, common_dimm,
cas_latency, additive_latency, unq_mrs_en);
diff --git a/drivers/ddr/fsl/interactive.c b/drivers/ddr/fsl/interactive.c
index 7fb4187..6aa16b2 100644
--- a/drivers/ddr/fsl/interactive.c
+++ b/drivers/ddr/fsl/interactive.c
@@ -511,6 +511,7 @@ static void fsl_ddr_options_edit(fsl_ddr_info_t *pinfo,
CTRL_OPTIONS(wrlvl_override),
CTRL_OPTIONS(wrlvl_sample),
CTRL_OPTIONS(wrlvl_start),
+   CTRL_OPTIONS(cswl_override),
CTRL_OPTIONS(rcw_override),
CTRL_OPTIONS(rcw_1),
CTRL_OPTIONS(rcw_2),
@@ -801,6 +802,7 @@ static void print_memctl_options(const memctl_options_t 
*popts)
CTRL_OPTIONS(wrlvl_override),
CTRL_OPTIONS(wrlvl_sample),
CTRL_OPTIONS(wrlvl_start),
+   CTRL_OPTIONS_HEX(cswl_override),
CTRL_OPTIONS(rcw_override),
CTRL_OPTIONS(rcw_1),
CTRL_OPTIONS(rcw_2),
diff --git a/include/fsl_ddr_sdram.h b/include/fsl_ddr_sdram.h
index e8a2db9..987119b 100644
--- a/include/fsl_ddr_sdram.h
+++ b/include/fsl_ddr_sdram.h
@@ -281,6 +281,7 @@ typedef struct memctl_options_partial_s {
 #define DDR_DATA_BUS_WIDTH_64 0
 #define DDR_DATA_BUS_WIDTH_32 1
 #define DDR_DATA_BUS_WIDTH_16 2
+#define DDR_CSWL_CS0   0x0401
 /*
  * Generalized parameters for memory controller configuration,
  * might be a little specific to the FSL memory controller
@@ -340,6 +341,7 @@ typedef struct memctl_options_s {
unsigned int cpo_override;
unsigned int write_data_delay;  /* DQS adjust */
 
+   unsigned int cswl_override;
unsigned int wrlvl_override;
unsigned int wrlvl_sample;  /* Write leveling */
unsigned int wrlvl_start;
-- 
1.8.4

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


[U-Boot] [PATCH v4 14/18] serial: lpuart: add 32-bit registers lpuart support

2014-08-14 Thread Alison Wang
From: Jingchang Lu 

On vybrid, lpuart's registers are 8-bit. On LS102xA, lpuart's registers
are 32-bit. This patch adds the support for 32-bit registers on
LS102xA.

Signed-off-by: Jingchang Lu 
Signed-off-by: Yuan Yao 
---
Change log:
 v4: Add commit messages.
 v3: New file.

 drivers/serial/serial_lpuart.c | 122 +
 1 file changed, 122 insertions(+)

diff --git a/drivers/serial/serial_lpuart.c b/drivers/serial/serial_lpuart.c
index da5f9a2..6e639b7 100644
--- a/drivers/serial/serial_lpuart.c
+++ b/drivers/serial/serial_lpuart.c
@@ -17,10 +17,34 @@
 #define UC2_TE  (1 << 3)
 #define UC2_RE  (1 << 2)
 
+#define STAT_LBKDIF(1 << 31)
+#define STAT_RXEDGIF   (1 << 30)
+#define STAT_TDRE  (1 << 23)
+#define STAT_RDRF  (1 << 21)
+#define STAT_IDLE  (1 << 20)
+#define STAT_OR(1 << 19)
+#define STAT_NF(1 << 18)
+#define STAT_FE(1 << 17)
+#define STAT_PF(1 << 16)
+#define STAT_MA1F  (1 << 15)
+#define STAT_MA2F  (1 << 14)
+#define STAT_FLAGS (STAT_LBKDIF | STAT_RXEDGIF | STAT_IDLE | STAT_OR | \
+   STAT_NF | STAT_FE | STAT_PF | STAT_MA1F | STAT_MA2F)
+
+#define CTRL_TE(1 << 19)
+#define CTRL_RE(1 << 18)
+
+#define FIFO_TXFE  0x80
+#define FIFO_RXFE  0x40
+
+#define WATER_TXWATER_OFF  1
+#define WATER_RXWATER_OFF  16
+
 DECLARE_GLOBAL_DATA_PTR;
 
 struct lpuart_fsl *base = (struct lpuart_fsl *)LPUART_BASE;
 
+#ifndef CONFIG_LPUART_32B_REG
 static void lpuart_serial_setbrg(void)
 {
u32 clk = mxc_get_clock(MXC_UART_CLK);
@@ -107,13 +131,111 @@ static struct serial_device lpuart_serial_drv = {
.getc = lpuart_serial_getc,
.tstc = lpuart_serial_tstc,
 };
+#else
+static void lpuart32_serial_setbrg(void)
+{
+   u32 clk = CONFIG_SYS_CLK_FREQ;
+   u32 sbr;
+
+   if (!gd->baudrate)
+   gd->baudrate = CONFIG_BAUDRATE;
+
+   sbr = (clk / (16 * gd->baudrate));
+   /* place adjustment later - n/32 BRFA */
+
+   out_be32(&base->baud, sbr);
+}
+
+static int lpuart32_serial_getc(void)
+{
+   u32 stat;
+
+   while (((stat = in_be32(&base->stat)) & STAT_RDRF) == 0) {
+   out_be32(&base->stat, STAT_FLAGS);
+   WATCHDOG_RESET();
+   }
+
+   return in_be32(&base->data) & 0x3ff;
+}
+
+static void lpuart32_serial_putc(const char c)
+{
+   if (c == '\n')
+   serial_putc('\r');
+
+   while (!(in_be32(&base->stat) & STAT_TDRE))
+   WATCHDOG_RESET();
+
+   out_be32(&base->data, c);
+}
+
+/*
+ * Test whether a character is in the RX buffer
+ */
+static int lpuart32_serial_tstc(void)
+{
+   if ((in_be32(&base->water) >> 24) == 0)
+   return 0;
+
+   return 1;
+}
+
+/*
+ * Initialise the serial port with the given baudrate. The settings
+ * are always 8 data bits, no parity, 1 stop bit, no start bits.
+ */
+static int lpuart32_serial_init(void)
+{
+   u8 ctrl;
+
+   ctrl = in_be32(&base->ctrl);
+   ctrl &= ~CTRL_RE;
+   ctrl &= ~CTRL_TE;
+   out_be32(&base->ctrl, ctrl);
+
+   out_be32(&base->modir, 0);
+   out_be32(&base->fifo, ~(FIFO_TXFE | FIFO_RXFE));
+
+   out_be32(&base->match, 0);
+   /* provide data bits, parity, stop bit, etc */
+
+   serial_setbrg();
+
+   out_be32(&base->ctrl, CTRL_RE | CTRL_TE);
+
+   return 0;
+}
+
+static struct serial_device lpuart32_serial_drv = {
+   .name = "lpuart32_serial",
+   .start = lpuart32_serial_init,
+   .stop = NULL,
+   .setbrg = lpuart32_serial_setbrg,
+   .putc = lpuart32_serial_putc,
+   .puts = default_serial_puts,
+   .getc = lpuart32_serial_getc,
+   .tstc = lpuart32_serial_tstc,
+};
+#endif
+void lpuart32_serial_initialize(void)
+{
+   serial_register(&lpuart32_serial_drv);
+}
 
 void lpuart_serial_initialize(void)
 {
+#ifdef CONFIG_LPUART_32B_REG
+   serial_register(&lpuart32_serial_drv);
+#else
serial_register(&lpuart_serial_drv);
+#endif
 }
 
 __weak struct serial_device *default_serial_console(void)
 {
+#ifdef CONFIG_LPUART_32B_REG
+   return &lpuart32_serial_drv;
+#else
return &lpuart_serial_drv;
+#endif
 }
-- 
1.8.4

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


[U-Boot] [PATCH v4 13/18] net: tsec: Remove tx snooping support from LS1

2014-08-14 Thread Alison Wang
From: Claudiu Manoil 

Remove the DMCTRL Tx snooping bits (TDSEN and TBDSEN) as a
workaround for LS1.  It has been observed that currently
the Tx stops functioning after a fair amount of Tx traffic
with these settings on.  These bits are sticky and once set
they cannot be reset from Linux, for instance.

Signed-off-by: Claudiu Manoil 
---
Change log:
 v4: No change.
 v3: New file.

 include/tsec.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/tsec.h b/include/tsec.h
index 5b74f67..1f0c233 100644
--- a/include/tsec.h
+++ b/include/tsec.h
@@ -129,7 +129,11 @@
 
 #define MINFLR_INIT_SETTINGS   0x0040
 
+#ifdef CONFIG_LS102xA
+#define DMACTRL_INIT_SETTINGS  0x0003
+#else
 #define DMACTRL_INIT_SETTINGS  0x00c3
+#endif
 #define DMACTRL_GRS0x0010
 #define DMACTRL_GTS0x0008
 #define DMACTRL_LE 0x8000
-- 
1.8.4

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


[U-Boot] [PATCH v4 16/18] video: dcu: Add Sii9022A HDMI Transmitter support

2014-08-14 Thread Alison Wang
On LS1021ATWR, Silicon's Sii9022A HDMI Transmitter
is used. This patch adds the common setting for this
chip.

Signed-off-by: Alison Wang 
---
Change log:
 v4: Add commit messages.
 v3: New file.

 board/freescale/common/Makefile   |   2 +
 board/freescale/common/dcu_sii9022a.c | 153 ++
 board/freescale/common/dcu_sii9022a.h |  13 +++
 3 files changed, 168 insertions(+)
 create mode 100644 board/freescale/common/dcu_sii9022a.c
 create mode 100644 board/freescale/common/dcu_sii9022a.h

diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile
index 22b57cc..808ddd0 100644
--- a/board/freescale/common/Makefile
+++ b/board/freescale/common/Makefile
@@ -34,6 +34,8 @@ ifndef CONFIG_RAMBOOT_PBL
 obj-$(CONFIG_FSL_FIXED_MMC_LOCATION)   += sdhc_boot.o
 endif
 
+obj-$(CONFIG_FSL_DCU_SII9022A)+= dcu_sii9022a.o
+
 obj-$(CONFIG_MPC8541CDS)   += cds_pci_ft.o
 obj-$(CONFIG_MPC8548CDS)   += cds_pci_ft.o
 obj-$(CONFIG_MPC8555CDS)   += cds_pci_ft.o
diff --git a/board/freescale/common/dcu_sii9022a.c 
b/board/freescale/common/dcu_sii9022a.c
new file mode 100644
index 000..2da627e
--- /dev/null
+++ b/board/freescale/common/dcu_sii9022a.c
@@ -0,0 +1,153 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PIXEL_CLK_LSB_REG  0x00
+#define PIXEL_CLK_MSB_REG  0x01
+#define VERT_FREQ_LSB_REG  0x02
+#define VERT_FREQ_MSB_REG  0x03
+#define TOTAL_PIXELS_LSB_REG   0x04
+#define TOTAL_PIXELS_MSB_REG   0x05
+#define TOTAL_LINES_LSB_REG0x06
+#define TOTAL_LINES_MSB_REG0x07
+#define TPI_INBUS_FMT_REG  0x08
+#define TPI_INPUT_FMT_REG  0x09
+#define TPI_OUTPUT_FMT_REG 0x0A
+#define TPI_SYS_CTRL_REG   0x1A
+#define TPI_PWR_STAT_REG   0x1E
+#define TPI_AUDIO_HANDING_REG  0x25
+#define TPI_AUDIO_INTF_REG 0x26
+#define TPI_AUDIO_FREQ_REG 0x27
+#define TPI_SET_PAGE_REG   0xBC
+#define TPI_SET_OFFSET_REG 0xBD
+#define TPI_RW_ACCESS_REG  0xBE
+#define TPI_TRANS_MODE_REG 0xC7
+
+#define TPI_INBUS_CLOCK_RATIO_1(1 << 6)
+#define TPI_INBUS_FULL_PIXEL_WIDE  (1 << 5)
+#define TPI_INBUS_RISING_EDGE  (1 << 4)
+#define TPI_INPUT_CLR_DEPTH_8BIT   (0 << 6)
+#define TPI_INPUT_VRANGE_EXPAN_AUTO(0 << 2)
+#define TPI_INPUT_CLR_RGB  (0 << 0)
+#define TPI_OUTPUT_CLR_DEPTH_8BIT  (0 << 6)
+#define TPI_OUTPUT_VRANGE_COMPRE_AUTO  (0 << 2)
+#define TPI_OUTPUT_CLR_HDMI_RGB(0 << 0)
+#define TPI_SYS_TMDS_OUTPUT(0 << 4)
+#define TPI_SYS_AV_NORAML  (0 << 3)
+#define TPI_SYS_AV_MUTE(1 << 3)
+#define TPI_SYS_DVI_MODE   (0 << 0)
+#define TPI_SYS_HDMI_MODE  (1 << 0)
+#define TPI_PWR_STAT_MASK  (3 << 0)
+#define TPI_PWR_STAT_D0(0 << 0)
+#define TPI_AUDIO_PASS_BASIC   (0 << 0)
+#define TPI_AUDIO_INTF_I2S (2 << 6)
+#define TPI_AUDIO_INTF_NORMAL  (0 << 4)
+#define TPI_AUDIO_TYPE_PCM (1 << 0)
+#define TPI_AUDIO_SAMP_SIZE_16BIT  (1 << 6)
+#define TPI_AUDIO_SAMP_FREQ_44K(2 << 3)
+#define TPI_SET_PAGE_SII9022A  0x01
+#define TPI_SET_OFFSET_SII9022A0x82
+#define TPI_RW_EN_SRC_TERMIN   (1 << 0)
+#define TPI_TRANS_MODE_ENABLE  (0 << 7)
+
+/* Programming of Silicon SIi9022a HDMI Transmitter */
+int dcu_set_dvi_encoder(struct fb_videomode *videomode)
+{
+   u8 temp;
+   u16 temp1, temp2;
+   u32 temp3;
+
+   i2c_set_bus_num(CONFIG_SYS_I2C_DVI_BUS_NUM);
+
+   /* Enable TPI transmitter mode */
+   temp = TPI_TRANS_MODE_ENABLE;
+   i2c_write(CONFIG_SYS_I2C_DVI_ADDR, TPI_TRANS_MODE_REG, 1, &temp, 1);
+
+   /* Enter into D0 state, full operation */
+   i2c_read(CONFIG_SYS_I2C_DVI_ADDR, TPI_PWR_STAT_REG, 1, &temp, 1);
+   temp &= ~TPI_PWR_STAT_MASK;
+   temp |= TPI_PWR_STAT_D0;
+   i2c_write(CONFIG_SYS_I2C_DVI_ADDR, TPI_PWR_STAT_REG, 1, &temp, 1);
+
+   /* Enable source termination */
+   temp = TPI_SET_PAGE_SII9022A;
+   i2c_write(CONFIG_SYS_I2C_DVI_ADDR, TPI_SET_PAGE_REG, 1, &temp, 1);
+   temp = TPI_SET_OFFSET_SII9022A;
+   i2c_write(CONFIG_SYS_I2C_DVI_ADDR, TPI_SET_OFFSET_REG, 1, &temp, 1);
+
+   i2c_read(CONFIG_SYS_I2C_DVI_ADDR, TPI_RW_ACCESS_REG, 1, &temp, 1);
+   temp |= TPI_RW_EN_SRC_TERMIN;
+   i2c_write(CONFIG_SYS_I2C_DVI_ADDR, TPI_RW_ACCESS_REG, 1, &temp, 1);
+
+   /* Set TPI system control */
+   temp = TPI_SYS_TMDS_OUTPUT | TPI_SYS_AV_NORAML | TPI_SYS_DVI_MODE;
+   i2c_write(CONFIG_SYS_I2C_DVI_ADDR, TPI_SYS_CTRL_REG, 1, &temp, 1);
+
+   /* Set pixel clock */
+   temp1 = PICOS2KHZ(videomode->pixclo

[U-Boot] [PATCH v4 11/18] arm: ls102xa: Add basic support for LS1021AQDS board

2014-08-14 Thread Alison Wang
From: Wang Huan 

LS102xA is an ARMv7 implementation. This patch is to add
basic support for LS1021AQDS board.
 One DDR controller
 DUART1 is used as the console

For the detail board information, please refer to README.

Signed-off-by: Alison Wang 
Signed-off-by: Jason Jin 
Signed-off-by: York Sun 
Signed-off-by: Yuan Yao 
Signed-off-by: Prabhakar Kushwaha 
---
Change log:
 v4: Add more commit messages.
 v3: Fix checkpatch error.
 Update to Kconfig. 
 v2: Remove ethaddr/ipaddr setting.
 Add board maintainer.
 Add serdes and multiple ethernet controllers support.

 arch/arm/Kconfig  |   4 +
 board/freescale/ls1021aqds/Kconfig|  23 ++
 board/freescale/ls1021aqds/MAINTAINERS|   6 +
 board/freescale/ls1021aqds/Makefile   |   9 +
 board/freescale/ls1021aqds/README | 112 +++
 board/freescale/ls1021aqds/ddr.c  | 166 ++
 board/freescale/ls1021aqds/ddr.h  |  64 
 board/freescale/ls1021aqds/eth.c  | 129 
 board/freescale/ls1021aqds/ls1021aqds.c   | 248 +++
 board/freescale/ls1021aqds/ls1021aqds_qixis.h |  35 +++
 configs/ls1021aqds_nor_defconfig  |   2 +
 include/configs/ls1021aqds.h  | 424 ++
 12 files changed, 1222 insertions(+)
 create mode 100644 board/freescale/ls1021aqds/Kconfig
 create mode 100644 board/freescale/ls1021aqds/MAINTAINERS
 create mode 100644 board/freescale/ls1021aqds/Makefile
 create mode 100644 board/freescale/ls1021aqds/README
 create mode 100644 board/freescale/ls1021aqds/ddr.c
 create mode 100644 board/freescale/ls1021aqds/ddr.h
 create mode 100644 board/freescale/ls1021aqds/eth.c
 create mode 100644 board/freescale/ls1021aqds/ls1021aqds.c
 create mode 100644 board/freescale/ls1021aqds/ls1021aqds_qixis.h
 create mode 100644 configs/ls1021aqds_nor_defconfig
 create mode 100644 include/configs/ls1021aqds.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e385eda..62b3cc8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -731,6 +731,9 @@ config TARGET_LS2085A_EMU
 config TARGET_LS2085A_SIMU
bool "Support ls2085a_simu"
 
+config TARGET_LS1021AQDS
+   bool "Support ls1021aqds_nor"
+
 config TARGET_BALLOON3
bool "Support balloon3"
 
@@ -865,6 +868,7 @@ source "board/eukrea/cpu9260/Kconfig"
 source "board/eukrea/cpuat91/Kconfig"
 source "board/faraday/a320evb/Kconfig"
 source "board/freescale/ls2085a/Kconfig"
+source "board/freescale/ls1021aqds/Kconfig"
 source "board/freescale/mx23evk/Kconfig"
 source "board/freescale/mx25pdk/Kconfig"
 source "board/freescale/mx28evk/Kconfig"
diff --git a/board/freescale/ls1021aqds/Kconfig 
b/board/freescale/ls1021aqds/Kconfig
new file mode 100644
index 000..c28bd2b
--- /dev/null
+++ b/board/freescale/ls1021aqds/Kconfig
@@ -0,0 +1,23 @@
+if TARGET_LS1021AQDS
+
+config SYS_CPU
+   string
+   default "armv7"
+
+config SYS_BOARD
+   string
+   default "ls1021aqds"
+
+config SYS_VENDOR
+   string
+   default "freescale"
+
+config SYS_SOC
+   string
+   default "ls102xa"
+
+config SYS_CONFIG_NAME
+   string
+   default "ls1021aqds"
+
+endif
diff --git a/board/freescale/ls1021aqds/MAINTAINERS 
b/board/freescale/ls1021aqds/MAINTAINERS
new file mode 100644
index 000..021d82b
--- /dev/null
+++ b/board/freescale/ls1021aqds/MAINTAINERS
@@ -0,0 +1,6 @@
+LS1021AQDS BOARD
+M: Alison Wang 
+S: Maintained
+F: board/freescale/ls1021aqds/
+F: include/configs/ls1021aqds.h
+F: configs/ls1021aqds_nor_defconfig
diff --git a/board/freescale/ls1021aqds/Makefile 
b/board/freescale/ls1021aqds/Makefile
new file mode 100644
index 000..3b6903c
--- /dev/null
+++ b/board/freescale/ls1021aqds/Makefile
@@ -0,0 +1,9 @@
+#
+# Copyright 2014 Freescale Semiconductor, Inc.
+#
+# SPDX-License-Identifier:  GPL-2.0+
+#
+
+obj-y += ls1021aqds.o
+obj-y += ddr.o
+obj-y += eth.o
diff --git a/board/freescale/ls1021aqds/README 
b/board/freescale/ls1021aqds/README
new file mode 100644
index 000..c561776
--- /dev/null
+++ b/board/freescale/ls1021aqds/README
@@ -0,0 +1,112 @@
+Overview
+
+The LS1021AQDS is a Freescale reference board that hosts the LS1021A SoC.
+
+LS1021A SoC Overview
+--
+The QorIQ LS1 family, which includes the LS1021A communications processor,
+is built on Layerscape architecture, the industry's first software-aware,
+core-agnostic networking architecture to offer unprecedented efficiency
+and scale.
+
+A member of the value-performance tier, the QorIQ LS1021A processor provides
+extensive integration and power efficiency for fanless, small form factor
+enterprise networking applications. Incorporating dual ARM Cortex-A7 cores
+running up to 1.0 GHz, the LS1021A processor delivers pre-silicon CoreMark
+performance of over 6,000, as well as virtualization support, advanced
+security features and the broadest array of high-speed interconnects and
+optimiz

[U-Boot] [PATCH v4 17/18] video: dcu: Add DCU driver support

2014-08-14 Thread Alison Wang
From: Wang Huan 

This patch is to add DCU driver support. DCU also named
2D-ACE(Two Dimensional Animation and Compositing Engine)
is a system master that fetches graphics stored in internal
or external memory and displays them on a TFT LCD panel.

Signed-off-by: Alison Wang 
---
Change log:
 v4: No change.
 v3: New file.

 arch/arm/include/asm/arch-ls102xa/config.h |   4 +
 drivers/video/Makefile |   1 +
 drivers/video/fsl_dcu_fb.c | 365 +
 include/fsl_dcu_fb.h   |  16 ++
 4 files changed, 386 insertions(+)
 create mode 100644 drivers/video/fsl_dcu_fb.c
 create mode 100644 include/fsl_dcu_fb.h

diff --git a/arch/arm/include/asm/arch-ls102xa/config.h 
b/arch/arm/include/asm/arch-ls102xa/config.h
index ddc747f..dfc5668 100644
--- a/arch/arm/include/asm/arch-ls102xa/config.h
+++ b/arch/arm/include/asm/arch-ls102xa/config.h
@@ -21,6 +21,7 @@
 #define CONFIG_SYS_FSL_LS1_CLK_ADDR(CONFIG_SYS_IMMR + 0x00ee1000)
 #define CONFIG_SYS_NS16550_COM1(CONFIG_SYS_IMMR + 
0x011c0500)
 #define CONFIG_SYS_NS16550_COM2(CONFIG_SYS_IMMR + 
0x011d0500)
+#define CONFIG_SYS_DCU_ADDR(CONFIG_SYS_IMMR + 0x01ce)
 
 #define CONFIG_SYS_TSEC1_OFFSET0x01d1
 #define CONFIG_SYS_TSEC2_OFFSET0x01d5
@@ -57,6 +58,9 @@
 #define CONFIG_SYS_FSL_WDOG_BE
 #define CONFIG_SYS_FSL_DSPI_BE
 #define CONFIG_SYS_FSL_QSPI_BE
+#define CONFIG_SYS_FSL_DCU_BE
+
+#define DCU_LAYER_MAX_NUM  16
 
 #define CONFIG_SYS_FSL_SRDS_1
 
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 945f35d..3dafef3 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_EXYNOS_MIPI_DSIM) += exynos_mipi_dsi.o 
exynos_mipi_dsi_common.o \
exynos_mipi_dsi_lowlevel.o
 obj-$(CONFIG_EXYNOS_PWM_BL) += exynos_pwm_bl.o
 obj-$(CONFIG_FSL_DIU_FB) += fsl_diu_fb.o videomodes.o
+obj-$(CONFIG_FSL_DCU_FB) += fsl_dcu_fb.o videomodes.o
 obj-$(CONFIG_L5F31188) += l5f31188.o
 obj-$(CONFIG_MPC8XX_LCD) += mpc8xx_lcd.o
 obj-$(CONFIG_PXA_LCD) += pxa_lcd.o
diff --git a/drivers/video/fsl_dcu_fb.c b/drivers/video/fsl_dcu_fb.c
new file mode 100644
index 000..36c1566
--- /dev/null
+++ b/drivers/video/fsl_dcu_fb.c
@@ -0,0 +1,365 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * FSL DCU Framebuffer driver
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "videomodes.h"
+
+/* Convert the X,Y resolution pair into a single number */
+#define RESOLUTION(x, y) (((u32)(x) << 16) | (y))
+
+#ifdef CONFIG_SYS_FSL_DCU_LE
+#definedcu_read32  in_le32
+#definedcu_write32 out_le32
+#elif defined(CONFIG_SYS_FSL_DCU_BE)
+#definedcu_read32  in_be32
+#definedcu_write32 out_be32
+#endif
+
+#define DCU_MODE_BLEND_ITER(x)  ((x) << 20)
+#define DCU_MODE_RASTER_EN (1 << 14)
+#define DCU_MODE_NORMAL1
+#define DCU_MODE_COLORBAR   3
+#define DCU_BGND_R(x)  ((x) << 16)
+#define DCU_BGND_G(x)  ((x) << 8)
+#define DCU_BGND_B(x)  (x)
+#define DCU_DISP_SIZE_DELTA_Y(x)   ((x) << 16)
+#define DCU_DISP_SIZE_DELTA_X(x)   (x)
+#define DCU_HSYN_PARA_BP(x)((x) << 22)
+#define DCU_HSYN_PARA_PW(x)((x) << 11)
+#define DCU_HSYN_PARA_FP(x)(x)
+#define DCU_VSYN_PARA_BP(x)((x) << 22)
+#define DCU_VSYN_PARA_PW(x)((x) << 11)
+#define DCU_VSYN_PARA_FP(x)(x)
+#define DCU_SYN_POL_INV_PXCK_FALL  (0 << 6)
+#define DCU_SYN_POL_NEG_REMAIN (0 << 5)
+#define DCU_SYN_POL_INV_VS_LOW (1 << 1)
+#define DCU_SYN_POL_INV_HS_LOW (1)
+#define DCU_THRESHOLD_LS_BF_VS(x)  ((x) << 16)
+#define DCU_THRESHOLD_OUT_BUF_HIGH(x)  ((x) << 8)
+#define DCU_THRESHOLD_OUT_BUF_LOW(x)   (x)
+#define DCU_UPDATE_MODE_MODE(1 << 31)
+#define DCU_UPDATE_MODE_READREG (1 << 30)
+
+#define DCU_CTRLDESCLN_1_HEIGHT(x) ((x) << 16)
+#define DCU_CTRLDESCLN_1_WIDTH(x)  (x)
+#define DCU_CTRLDESCLN_2_POSY(x)   ((x) << 16)
+#define DCU_CTRLDESCLN_2_POSX(x)   (x)
+#define DCU_CTRLDESCLN_4_EN(1 << 31)
+#define DCU_CTRLDESCLN_4_TILE_EN   (1 << 30)
+#define DCU_CTRLDESCLN_4_DATA_SEL_CLUT (1 << 29)
+#define DCU_CTRLDESCLN_4_SAFETY_EN (1 << 28)
+#define DCU_CTRLDESCLN_4_TRANS(x)  ((x) << 20)
+#define DCU_CTRLDESCLN_4_BPP(x)((x) << 16)
+#define DCU_CTRLDESCLN_4_RLE_EN(1 << 15)
+#define DCU_CTRLDESCLN_4_LUOFFS(x) ((x) << 4)
+#define DCU_CTRLDESCLN_4_BB_ON (1 << 2)
+#define DCU_CTRLDESCLN_4_AB(x) (x)
+#define DCU_CTRLDESCLN_5_CKMAX_R(x)((x) << 16)
+#define DCU_CTRLDESCLN_5_CKMAX_G(x)((x) << 8)
+#define DCU_CTRLDESCLN_5_CKMAX

[U-Boot] [PATCH v4 12/18] arm: ls102xa: Add basic support for LS1021ATWR board

2014-08-14 Thread Alison Wang
From: Wang Huan 

LS102xA is an ARMv7 implementation. This patch is to add
basic support for LS1021ATWR board.
 One DDR controller
 DUART1 is used as the console

For the detail board information, please refer to README.

Signed-off-by: Chen Lu 
Signed-off-by: Yuan Yao 
Signed-off-by: Alison Wang 
---
Change log:
 v4: Add more commit messages.
 v3: Fix checkpatch error.
 Update to Kconfig. 
 v2: New file.

 arch/arm/Kconfig|   4 +
 board/freescale/ls1021atwr/Kconfig  |  23 ++
 board/freescale/ls1021atwr/MAINTAINERS  |   6 +
 board/freescale/ls1021atwr/Makefile |   7 +
 board/freescale/ls1021atwr/README   | 109 +++
 board/freescale/ls1021atwr/ls1021atwr.c | 494 
 configs/ls1021atwr_nor_defconfig|   2 +
 include/configs/ls1021atwr.h| 284 ++
 8 files changed, 929 insertions(+)
 create mode 100644 board/freescale/ls1021atwr/Kconfig
 create mode 100644 board/freescale/ls1021atwr/MAINTAINERS
 create mode 100644 board/freescale/ls1021atwr/Makefile
 create mode 100644 board/freescale/ls1021atwr/README
 create mode 100644 board/freescale/ls1021atwr/ls1021atwr.c
 create mode 100644 configs/ls1021atwr_nor_defconfig
 create mode 100644 include/configs/ls1021atwr.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 62b3cc8..d207db7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -734,6 +734,9 @@ config TARGET_LS2085A_SIMU
 config TARGET_LS1021AQDS
bool "Support ls1021aqds_nor"
 
+config TARGET_LS1021ATWR
+   bool "Support ls1021atwr_nor"
+
 config TARGET_BALLOON3
bool "Support balloon3"
 
@@ -869,6 +872,7 @@ source "board/eukrea/cpuat91/Kconfig"
 source "board/faraday/a320evb/Kconfig"
 source "board/freescale/ls2085a/Kconfig"
 source "board/freescale/ls1021aqds/Kconfig"
+source "board/freescale/ls1021atwr/Kconfig"
 source "board/freescale/mx23evk/Kconfig"
 source "board/freescale/mx25pdk/Kconfig"
 source "board/freescale/mx28evk/Kconfig"
diff --git a/board/freescale/ls1021atwr/Kconfig 
b/board/freescale/ls1021atwr/Kconfig
new file mode 100644
index 000..057808d
--- /dev/null
+++ b/board/freescale/ls1021atwr/Kconfig
@@ -0,0 +1,23 @@
+if TARGET_LS1021ATWR
+
+config SYS_CPU
+   string
+   default "armv7"
+
+config SYS_BOARD
+   string
+   default "ls1021atwr"
+
+config SYS_VENDOR
+   string
+   default "freescale"
+
+config SYS_SOC
+   string
+   default "ls102xa"
+
+config SYS_CONFIG_NAME
+   string
+   default "ls1021atwr"
+
+endif
diff --git a/board/freescale/ls1021atwr/MAINTAINERS 
b/board/freescale/ls1021atwr/MAINTAINERS
new file mode 100644
index 000..4e5bc15
--- /dev/null
+++ b/board/freescale/ls1021atwr/MAINTAINERS
@@ -0,0 +1,6 @@
+LS1021ATWR BOARD
+M: Alison Wang 
+S: Maintained
+F: board/freescale/ls1021atwr/
+F: include/configs/ls1021atwr.h
+F: configs/ls1021atwr_nor_defconfig
diff --git a/board/freescale/ls1021atwr/Makefile 
b/board/freescale/ls1021atwr/Makefile
new file mode 100644
index 000..b5df668
--- /dev/null
+++ b/board/freescale/ls1021atwr/Makefile
@@ -0,0 +1,7 @@
+#
+# Copyright 2014 Freescale Semiconductor, Inc.
+#
+# SPDX-License-Identifier:  GPL-2.0+
+#
+
+obj-y += ls1021atwr.o
diff --git a/board/freescale/ls1021atwr/README 
b/board/freescale/ls1021atwr/README
new file mode 100644
index 000..d2821cb
--- /dev/null
+++ b/board/freescale/ls1021atwr/README
@@ -0,0 +1,109 @@
+Overview
+
+The LS1021ATWR is a Freescale reference board that hosts the LS1021A SoC.
+
+LS1021A SoC Overview
+--
+The QorIQ LS1 family, which includes the LS1021A communications processor,
+is built on Layerscape architecture, the industry's first software-aware,
+core-agnostic networking architecture to offer unprecedented efficiency
+and scale.
+
+A member of the value-performance tier, the QorIQ LS1021A processor provides
+extensive integration and power efficiency for fanless, small form factor
+enterprise networking applications. Incorporating dual ARM Cortex-A7 cores
+running up to 1.0 GHz, the LS1021A processor delivers pre-silicon CoreMark
+performance of over 6,000, as well as virtualization support, advanced
+security features and the broadest array of high-speed interconnects and
+optimized peripheral features ever offered in a sub-3 W processor.
+
+The QorIQ LS1021A processor features an integrated LCD controller,
+CAN controller for implementing industrial protocols, DDR3L/4 running
+up to 1600 MHz, integrated security engine and QUICC Engine, and ECC
+protection on both L1 and L2 caches. The LS1021A processor is pin- and
+software-compatible with the QorIQ LS1020A and LS1022A processors.
+
+The LS1021A SoC includes the following function and features:
+
+ - ARM Cortex-A7 MPCore compliant with ARMv7-A architecture
+ - Dual high-preformance ARM Cortex-A7 cores, each core includes:
+   - 32 Kbyte L1 Instruction Cache and Data Cache for each core (ECC 
protection)
+   - 512 Kb

[U-Boot] [PATCH v4 04/18] net: mdio: Add private MDIO read/write function

2014-08-14 Thread Alison Wang
As extra FPGA settings is needed for MDIO read/write
on LS1021AQDS, private MDIO read/write functions are
created.

Signed-off-by: Alison Wang 
---
Change log:
 v4: No change.
 v3: Split from the 0004-arm-ls102xa-Add-etsec-support-for-LS102xA patch.
 v2: Add private mdio read and write support. 

 drivers/net/fsl_mdio.c | 9 +++--
 include/fsl_mdio.h | 4 
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/net/fsl_mdio.c b/drivers/net/fsl_mdio.c
index 8d09f5d..6eae78f 100644
--- a/drivers/net/fsl_mdio.c
+++ b/drivers/net/fsl_mdio.c
@@ -98,8 +98,13 @@ int fsl_pq_mdio_init(bd_t *bis, struct fsl_pq_mdio_info 
*info)
return -1;
}
 
-   bus->read = tsec_phy_read;
-   bus->write = tsec_phy_write;
+   if (info->priv_mdio_read) {
+   bus->read = info->priv_mdio_read;
+   bus->write = info->priv_mdio_write;
+   } else {
+   bus->read = tsec_phy_read;
+   bus->write = tsec_phy_write;
+   }
bus->reset = fsl_pq_mdio_reset;
sprintf(bus->name, info->name);
 
diff --git a/include/fsl_mdio.h b/include/fsl_mdio.h
index a531edf..633123c 100644
--- a/include/fsl_mdio.h
+++ b/include/fsl_mdio.h
@@ -57,6 +57,10 @@ int memac_mdio_read(struct mii_dev *bus, int port_addr, int 
dev_addr,
 struct fsl_pq_mdio_info {
struct tsec_mii_mng __iomem *regs;
char *name;
+   int (*priv_mdio_read)(struct mii_dev *bus, int addr,
+ int devad, int reg);
+   int (*priv_mdio_write)(struct mii_dev *bus, int addr, int devad,
+  int reg, u16 val);
 };
 int fsl_pq_mdio_init(bd_t *bis, struct fsl_pq_mdio_info *info);
 
-- 
1.8.4

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


[U-Boot] [PATCH v4 15/18] arm: ls102xa: Add LETECH support for LS1021AQDS/TWR board

2014-08-14 Thread Alison Wang
From: Wang Huan 

This patch is to add LETECH support for LS1021AQDS/TWR board.
For LETECH, lpuart is used as console.

Signed-off-by: Jason Jin 
Signed-off-by: Yuan Yao 
Signed-off-by: Alison Wang 
---
Change log:
 v4: No change.
 v3: New file.

 board/freescale/ls1021aqds/MAINTAINERS |  1 +
 board/freescale/ls1021atwr/MAINTAINERS |  1 +
 configs/ls1021aqds_letech_defconfig|  3 +++
 configs/ls1021atwr_letech_defconfig|  3 +++
 include/configs/ls1021aqds.h   | 13 +
 include/configs/ls1021atwr.h   | 12 
 6 files changed, 33 insertions(+)
 create mode 100644 configs/ls1021aqds_letech_defconfig
 create mode 100644 configs/ls1021atwr_letech_defconfig

diff --git a/board/freescale/ls1021aqds/MAINTAINERS 
b/board/freescale/ls1021aqds/MAINTAINERS
index 021d82b..590b89b 100644
--- a/board/freescale/ls1021aqds/MAINTAINERS
+++ b/board/freescale/ls1021aqds/MAINTAINERS
@@ -4,3 +4,4 @@ S:  Maintained
 F: board/freescale/ls1021aqds/
 F: include/configs/ls1021aqds.h
 F: configs/ls1021aqds_nor_defconfig
+F: configs/ls1021aqds_letech_defconfig
diff --git a/board/freescale/ls1021atwr/MAINTAINERS 
b/board/freescale/ls1021atwr/MAINTAINERS
index 4e5bc15..14a7441 100644
--- a/board/freescale/ls1021atwr/MAINTAINERS
+++ b/board/freescale/ls1021atwr/MAINTAINERS
@@ -4,3 +4,4 @@ S:  Maintained
 F: board/freescale/ls1021atwr/
 F: include/configs/ls1021atwr.h
 F: configs/ls1021atwr_nor_defconfig
+F: configs/ls1021atwr_letech_defconfig
diff --git a/configs/ls1021aqds_letech_defconfig 
b/configs/ls1021aqds_letech_defconfig
new file mode 100644
index 000..b70971e
--- /dev/null
+++ b/configs/ls1021aqds_letech_defconfig
@@ -0,0 +1,3 @@
+CONFIG_SYS_EXTRA_OPTIONS="LETECH"
++S:CONFIG_ARM=y
++S:CONFIG_TARGET_LS1021AQDS=y
diff --git a/configs/ls1021atwr_letech_defconfig 
b/configs/ls1021atwr_letech_defconfig
new file mode 100644
index 000..4b187b3
--- /dev/null
+++ b/configs/ls1021atwr_letech_defconfig
@@ -0,0 +1,3 @@
+CONFIG_SYS_EXTRA_OPTIONS="LETECH"
++S:CONFIG_ARM=y
++S:CONFIG_TARGET_LS1021ATWR=y
diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
index 856fdfc..5a8bf21 100644
--- a/include/configs/ls1021aqds.h
+++ b/include/configs/ls1021aqds.h
@@ -279,11 +279,16 @@ unsigned long get_board_ddr_clk(void);
 /*
  * Serial Port
  */
+#ifdef CONFIG_LETECH
+#define CONFIG_FSL_LPUART
+#define CONFIG_LPUART_32B_REG
+#else
 #define CONFIG_CONS_INDEX  1
 #define CONFIG_SYS_NS16550
 #define CONFIG_SYS_NS16550_SERIAL
 #define CONFIG_SYS_NS16550_REG_SIZE1
 #define CONFIG_SYS_NS16550_CLK get_serial_clock()
+#endif
 
 #define CONFIG_BAUDRATE115200
 
@@ -367,11 +372,19 @@ unsigned long get_board_ddr_clk(void);
 
 #define CONFIG_BOOTDELAY   3
 
+#ifdef CONFIG_LETECH
+#define CONFIG_EXTRA_ENV_SETTINGS  \
+   "bootargs=root=/dev/ram0 rw console=ttyLP0,115200\0" \
+   "fdt_high=0xcfff\0" \
+   "initrd_high=0xcfff\0"  \
+   "hwconfig=fsl_ddr:ctlr_intlv=null,bank_intlv=null\0"
+#else
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"bootargs=root=/dev/ram0 rw console=ttyS0,115200\0" \
"fdt_high=0xcfff\0" \
"initrd_high=0xcfff\0"  \
"hwconfig=fsl_ddr:ctlr_intlv=null,bank_intlv=null\0"
+#endif
 
 /*
  * Miscellaneous configurable options
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index f8cbe32..b268a70 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -147,11 +147,16 @@ unsigned long get_board_ddr_clk(void);
 /*
  * Serial Port
  */
+#ifdef CONFIG_LETECH
+#define CONFIG_FSL_LPUART
+#define CONFIG_LPUART_32B_REG
+#else
 #define CONFIG_CONS_INDEX  1
 #define CONFIG_SYS_NS16550
 #define CONFIG_SYS_NS16550_SERIAL
 #define CONFIG_SYS_NS16550_REG_SIZE1
 #define CONFIG_SYS_NS16550_CLK get_serial_clock()
+#endif
 
 #define CONFIG_BAUDRATE115200
 
@@ -228,10 +233,17 @@ unsigned long get_board_ddr_clk(void);
 
 #define CONFIG_BOOTDELAY   3
 
+#ifdef CONFIG_LETECH
+#define CONFIG_EXTRA_ENV_SETTINGS  \
+   "bootargs=root=/dev/ram0 rw console=ttyLP0,115200\0" \
+   "initrd_high=0xcfff\0"  \
+   "fdt_high=0xcfff\0"
+#else
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"bootargs=root=/dev/ram0 rw console=ttyS0,115200\0" \
"initrd_high=0xcfff\0"  \
"fdt_high=0xcfff\0"
+#endif
 
 /*
  * Miscellaneous configurable options
-- 
1.8.4

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


[U-Boot] [PATCH v4 18/18] ls102xa: dcu: Add platform support for DCU on LS1021ATWR board

2014-08-14 Thread Alison Wang
From: Wang Huan 

This patch adds the TWR_LCD_RGB card/HDMI options and the common
configuration for DCU on LS1021ATWR board.

Signed-off-by: Alison Wang 
---
Change log:
 v4: Add commit messages.
 v3: New file.

 board/freescale/ls1021atwr/Makefile |  1 +
 board/freescale/ls1021atwr/dcu.c| 47 +
 board/freescale/ls1021atwr/ls1021atwr.c |  6 +
 include/configs/ls1021atwr.h| 18 +
 4 files changed, 72 insertions(+)
 create mode 100644 board/freescale/ls1021atwr/dcu.c

diff --git a/board/freescale/ls1021atwr/Makefile 
b/board/freescale/ls1021atwr/Makefile
index b5df668..01296c0 100644
--- a/board/freescale/ls1021atwr/Makefile
+++ b/board/freescale/ls1021atwr/Makefile
@@ -5,3 +5,4 @@
 #
 
 obj-y += ls1021atwr.o
+obj-$(CONFIG_FSL_DCU_FB) += dcu.o
diff --git a/board/freescale/ls1021atwr/dcu.c b/board/freescale/ls1021atwr/dcu.c
new file mode 100644
index 000..8fe4ccb
--- /dev/null
+++ b/board/freescale/ls1021atwr/dcu.c
@@ -0,0 +1,47 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * FSL DCU Framebuffer driver
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include "div64.h"
+#include "../common/dcu_sii9022a.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+unsigned int dcu_set_pixel_clock(unsigned int pixclock)
+{
+   unsigned long long div;
+
+   div = (unsigned long long)(gd->bus_clk / 1000);
+   div *= (unsigned long long)pixclock;
+   do_div(div, 10);
+
+   return div;
+}
+
+int platform_dcu_init(unsigned int xres, unsigned int yres,
+ const char *port,
+ struct fb_videomode *dcu_fb_videomode)
+{
+   const char *name;
+   unsigned int pixel_format;
+
+   if (strncmp(port, "twr_lcd", 4) == 0) {
+   name = "TWR_LCD_RGB card";
+   } else {
+   name = "HDMI";
+   dcu_set_dvi_encoder(dcu_fb_videomode);
+   }
+
+   printf("DCU: Switching to %s monitor @ %ux%u\n", name, xres, yres);
+
+   pixel_format = 32;
+   fsl_dcu_init(xres, yres, pixel_format);
+
+   return 0;
+}
diff --git a/board/freescale/ls1021atwr/ls1021atwr.c 
b/board/freescale/ls1021atwr/ls1021atwr.c
index 7fdcbcd..e4364dd 100644
--- a/board/freescale/ls1021atwr/ls1021atwr.c
+++ b/board/freescale/ls1021atwr/ls1021atwr.c
@@ -264,6 +264,12 @@ int board_early_init_f(void)
init_early_memctl_regs();
 #endif
 
+#ifdef CONFIG_FSL_DCU_FB
+   out_be32(&scfg->scfgrevcr, 0x);
+   out_be32(&scfg->pixclkcr, 0x8000);
+   out_be32(&scfg->scfgrevcr, 0x);
+#endif
+
out_le32(&cci->ctrl_ord, 0x0008);
 
return 0;
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index b268a70..fb2cf08 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -182,6 +182,24 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_GENERIC_MMC
 
 /*
+ * Video
+ */
+#define CONFIG_FSL_DCU_FB
+
+#ifdef CONFIG_FSL_DCU_FB
+#define CONFIG_VIDEO
+#define CONFIG_CMD_BMP
+#define CONFIG_CFB_CONSOLE
+#define CONFIG_VGA_AS_SINGLE_DEVICE
+#define CONFIG_VIDEO_LOGO
+#define CONFIG_VIDEO_BMP_LOGO
+
+#define CONFIG_FSL_DCU_SII9022A
+#define CONFIG_SYS_I2C_DVI_BUS_NUM 1
+#define CONFIG_SYS_I2C_DVI_ADDR0x39
+#endif
+
+/*
  * eTSEC
  */
 #define CONFIG_TSEC_ENET
-- 
1.8.4

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


Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings

2014-08-14 Thread Alexander Holler

Am 31.07.2014 21:57, schrieb Stephen Warren:


Huh, I do see that now. I must have been looking at the content of
common/cmd_nvedit.c from the wrong branch, which didn't include that
patch. I could have sworn I checked git history too, but evidently not.
It is indeed clearly there right before the patches which use it. Sorry
for the noise.


As I've just remembered where I did see your name before, the config for 
the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to 
execute commands when using uEnv.txt.


It's easily done with something like the following:

   "env import -t -r $loadaddr $filesize;" \
   "if test -n \"$uenvcmd\"; then " \
   "echo \"Running uenvcmd ...\";" \
   "run uenvcmd;" \
   "fi;" \

Regards,

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


Re: [U-Boot] Passing bootargs to arm64 kernel

2014-08-14 Thread Arnab Basu
On 08/14/2014 08:04 AM, Youngmin Nam wrote:
> Thank you for reply Tom,
> Let me ask you some questions.
> 
> Can we set kernel's bootargs without re-compiling device tree on arm64
> kernel by u-boot?
> 
> I mean, I want to set kernel's bootargs by u-boot without re-compiling
> device tree.
> 
> Is it possible?

This is done anyway, whatever is defined in CONFIG_BOOTARGS will be
stored in the U-Boot environment variable bootargs and passed as
bootargs to the kernel via the "chosen" node.

See fdt_chosen in common/fdt-support.c.

So if you want the change the bootargs passed to the kernel, just do

> set bootargs ''

at the u-boot prompt and the boot the kernel.

Thanks
Arnab

> 2014. 8. 13. 오후 7:39에 "Tom Rini" 님이 작성:
> 
>> On Wed, Aug 13, 2014 at 11:21:32AM +0900, Youngmin Nam wrote:
>>
>>> Hello.
>>> I'm trying to find a way how to pass bootargs to arm64 kernel.
>>>
>>> In arm32 kernel, we can pass bootargs with atag from u-boot to kernel.
>> So,
>>> we can overwrite kernel's bootargs with u-boot's bootargs.
>>>
>>> But from arm64 kernel, the dtb is the only argument that should be passed
>>> from bootloader which is mandatory.
>>> you can find this contents in kernel
>>> documentation.(Documentation/arm64/Booting.txt)
>>>
>>> So,  is there any way how to set bootargs by u-boot?
>>
>> Yes, within the device tree, like we do today.  There's a few issues we
>> have today, but I need to re-post the booti command support patches,
>> given what's coming in 3.17 in the kernel.
>>
>> --
>> Tom
>>

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


Re: [U-Boot] [PATCH] tools, fit_info: increase buffer for command name

2014-08-14 Thread Anatolij Gustschin
On Mon, 11 Aug 2014 11:17:08 +0200
Heiko Schocher  wrote:

> currently the buffer for command name is 50 bytes only. If using
> fit_info with long absolute paths, this is not enough, so raise
> it to 256 (as it is in fit_check_sign)
> 
> Signed-off-by: Heiko Schocher 
> Cc: Simon Glass 
> ---
>  tools/fit_info.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

applied to u-boot-staging/ag...@denx.de. thanks!

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


Re: [U-Boot] [PATCH] tools: fix typo in tools/image-host.c

2014-08-14 Thread Anatolij Gustschin
On Mon, 11 Aug 2014 11:02:17 +0200
Heiko Schocher  wrote:

> fix a typo in error printf. If FIT_CONFS_PATH is not found
> print FIT_CONFS_PATH not FIT_IMAGES_PATH.
> 
> Signed-off-by: Heiko Schocher 
> Cc: Simon Glass 
> ---
>  tools/image-host.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied to u-boot-staging/ag...@denx.de. thanks!

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


Re: [U-Boot] [PATCH] mx6: Fix ECSPI typo in soc_boot_modes

2014-08-14 Thread Anatolij Gustschin
On Sun, 10 Aug 2014 20:03:07 +0300
picmas...@mail.bg wrote:

> From: Nikolay Dimitrov 
> 
> Signed-off-by: Nikolay Dimitrov 
> Cc: Stefano Babic 
> ---
>  arch/arm/cpu/armv7/mx6/soc.c |8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Acked-by: Anatolij Gustschin 

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


Re: [U-Boot] [PATCH] pci: fix overflow in __pci_hose_bus_to_phys w/ large RAM

2014-08-14 Thread Anatolij Gustschin
On Mon, 11 Aug 2014 16:09:28 -0600
Stephen Warren  wrote:

> From: Stephen Warren 
> 
> If a 32-bit system has 2GB of RAM, and the base address of that RAM is
> 2GB, then start+size will overflow a 32-bit value (to a value of 0).
> 
> To avoid such an overflow, convert __pci_hose_bus_to_phys() to calculate
> the offset of a bus address into a PCI region, rather than comparing a
> bus address against the end of a PCI region.
> 
> Signed-off-by: Stephen Warren 
> ---
>  drivers/pci/pci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied to u-boot-staging/ag...@denx.de. thanks!

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


[U-Boot] [PATCH] Makefile: Use Kbuild style for system_map.o generation step

2014-08-14 Thread Vasili Galka
The command generating the "common/system_map.o" file was always shown
during the build making the output messy. Now it is called using the
Kbuild "cmd" macro, so that the full command is shown only when
building in verbose mode.

Signed-off-by: Vasili Galka 
---
 Makefile |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index b5d5e01..7c0352c 100644
--- a/Makefile
+++ b/Makefile
@@ -1006,13 +1006,17 @@ quiet_cmd_u-boot__ ?= LD  $@
   --start-group $(u-boot-main) --end-group \
   $(PLATFORM_LIBS) -Map u-boot.map
 
-u-boot:$(u-boot-init) $(u-boot-main) u-boot.lds
-   $(call if_changed,u-boot__)
-ifeq ($(CONFIG_KALLSYMS),y)
+quiet_cmd_smap = GEN common/system_map.o
+cmd_smap = \
smap=`$(call SYSTEM_MAP,u-boot) | \
awk '$$2 ~ /[tTwW]/ {printf $$1 $$3 "000"}'` ; \
$(CC) $(c_flags) -DSYSTEM_MAP="\"$${smap}\"" \
-c $(srctree)/common/system_map.c -o common/system_map.o
+
+u-boot:$(u-boot-init) $(u-boot-main) u-boot.lds
+   $(call if_changed,u-boot__)
+ifeq ($(CONFIG_KALLSYMS),y)
+   $(call cmd,smap)
$(call cmd,u-boot__) common/system_map.o
 endif
 
-- 
1.7.9

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


[U-Boot] [PATCH] bfin: Use optimization for size instead of speed on two boards

2014-08-14 Thread Vasili Galka
The build of bf533-stamp and bf538f-ezkit boards is broken. The code
does not fit into the available RAM. This fixes the build by favoring
size optimization over speed optimization for the code in lib
directory.

Signed-off-by: Vasili Galka 
Cc: Sonic Zhang 
---
 include/configs/bf533-stamp.h  |1 -
 include/configs/bf538f-ezkit.h |1 -
 2 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/include/configs/bf533-stamp.h b/include/configs/bf533-stamp.h
index d82c5b2..f5b9658 100644
--- a/include/configs/bf533-stamp.h
+++ b/include/configs/bf533-stamp.h
@@ -185,7 +185,6 @@
  */
 #define CONFIG_RTC_BFIN
 #define CONFIG_UART_CONSOLE0
-#define CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEED
 
 /* FLASH/ETHERNET uses the same async bank */
 #define SHARED_RESOURCES   1
diff --git a/include/configs/bf538f-ezkit.h b/include/configs/bf538f-ezkit.h
index 742c299..2837cf8 100644
--- a/include/configs/bf538f-ezkit.h
+++ b/include/configs/bf538f-ezkit.h
@@ -134,7 +134,6 @@
  */
 #define CONFIG_RTC_BFIN
 #define CONFIG_UART_CONSOLE0
-#define CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEED
 
 /*
  * Pull in common ADI header for remaining command/environment setup
-- 
1.7.9

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


Re: [U-Boot] [PATCH] mkimage: fix compilation issues on OpenBSD

2014-08-14 Thread Anatolij Gustschin
On Sat,  9 Aug 2014 18:17:47 +0200
Luka Perkov  wrote:

> Signed-off-by: Luka Perkov 
> ---
>  tools/mkimage.c | 2 ++
>  1 file changed, 2 insertions(+)

applied to u-boot-staging/ag...@denx.de. thanks!

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


Re: [U-Boot] Build broken for bf538f-ezkit board - not enough ram

2014-08-14 Thread Vasili Galka
Hi Simon,

On Thu, Aug 14, 2014 at 7:20 AM, Simon Glass  wrote:

> Hi,
>
> On 12 August 2014 10:12, Vasili Galka  wrote:
> > On Sun, Jun 29, 2014 at 6:01 PM, Vasili Galka  wrote:
> >
> >> Hi,
> >>
> >> Some of the recent commits on u-boot/master have broken the build of
> >> bf538f-ezkit board. The build was fine for v2014.07-rc3. However, now
> >> there is the following error:
> >>
> >> bfin-elf-ld.bfd: u-boot section `.bss' will not fit in region `ram'
> >> bfin-elf-ld.bfd: region `ram' overflowed by 40 bytes
> >>
> >> I did not pin-point exactly what has increased the image size, and if
> >> the growth is in the .text or .bss section.
> >>
> >> Maybe some of the features shall be dropped from the board config to
> >> decrease the size.
> >>
> >> Also, may be related:
> >> http://lists.denx.de/pipermail/u-boot/2014-April/177928.html
> >>
> >> Best,
> >> Vasili
> >>
> >
> > This is still broken and now the bf533-stamp board seems to have the same
> > error.
> > Best,
> > Vasili
> >
>
> Can you fix it?
>
> Regards,
> Simon
>

The only way I see to fix it is dropping some features from there boards
to reduce the image size. As I'm not a user of these boards, I don't know
what can be dropped. However, I can suggest sacrificing performance
instead of features. Proposed patch:

http://patchwork.ozlabs.org/patch/379886/

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


[U-Boot] [PATCH v2 4/4] vexpress_aemv8a.h: Enable CONFIG_CMD_BOOTI and CONFIG_CMD_UNZIP

2014-08-14 Thread Tom Rini
Add support for booting Images and for unzipping Image.gz files.

Signed-off-by: Tom Rini 
---
 include/configs/vexpress_aemv8a.h |2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/vexpress_aemv8a.h 
b/include/configs/vexpress_aemv8a.h
index 6f31fcf..0897932 100644
--- a/include/configs/vexpress_aemv8a.h
+++ b/include/configs/vexpress_aemv8a.h
@@ -154,6 +154,8 @@
 /*#define CONFIG_MENU_SHOW*/
 #define CONFIG_CMD_CACHE
 #define CONFIG_CMD_BDI
+#define CONFIG_CMD_BOOTI
+#define CONFIG_CMD_UNZIP
 #define CONFIG_CMD_DHCP
 #define CONFIG_CMD_PXE
 #define CONFIG_CMD_ENV
-- 
1.7.9.5

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


[U-Boot] [PATCH v2 3/4] vexpress_aemv8a.h: Clean up the config

2014-08-14 Thread Tom Rini
- Drop DEBUG
- Drop defines we can use the default of.
- Provide a larger malloc pool.
- Correct default locations for kernel / initrd / device tree

Signed-off-by: Tom Rini 
---
Changes in v1:
- Don't drop GIC portions, per Rob Herring's recommendation
---
 include/configs/vexpress_aemv8a.h |   13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/include/configs/vexpress_aemv8a.h 
b/include/configs/vexpress_aemv8a.h
index 1905d13..6f31fcf 100644
--- a/include/configs/vexpress_aemv8a.h
+++ b/include/configs/vexpress_aemv8a.h
@@ -8,8 +8,6 @@
 #ifndef __VEXPRESS_AEMV8A_H
 #define __VEXPRESS_AEMV8A_H
 
-#define DEBUG
-
 #ifdef CONFIG_BASE_FVP
 #ifndef CONFIG_SEMIHOSTING
 #error CONFIG_BASE_FVP requires CONFIG_SEMIHOSTING
@@ -134,7 +132,7 @@
 #define CONFIG_SYS_MEMTEST_END (V2M_BASE + 0x8000)
 
 /* Size of malloc() pool */
-#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 128 * 1024)
+#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + (8 << 20))
 
 /* SMSC91C111 Ethernet Configuration */
 #define CONFIG_SMC91
@@ -215,10 +213,9 @@
 #else
 
 #define CONFIG_EXTRA_ENV_SETTINGS  \
-   "kernel_addr_r=0x20\0"  \
-   "initrd_addr_r=0xa0\0"  \
-   "initrd_size=0x200\0"   \
-   "fdt_addr_r=0x10\0" \
+   "kernel_addr_r=0x8000\0"\
+   "initrd_addr_r=0x8800\0"\
+   "fdt_addr_r=0x8300\0"   
\
"fdt_high=0xa000\0"
 
 #define CONFIG_BOOTARGS"console=ttyAMA0 root=/dev/ram0"
@@ -239,7 +236,7 @@
 #define CONFIG_SYS_HUSH_PARSER
 #define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE
 #define CONFIG_SYS_LONGHELP
-#define CONFIG_CMDLINE_EDITING 1
+#define CONFIG_CMDLINE_EDITING
 #define CONFIG_SYS_MAXARGS 64  /* max command args */
 
 #endif /* __VEXPRESS_AEMV8A_H */
-- 
1.7.9.5

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


[U-Boot] [PATCH v2 1/4] arm64: Correct passing of Linux kernel args

2014-08-14 Thread Tom Rini
The Documentation/arm64/booting.txt document says that pass in x1/x2/x3
as 0 as they are reserved for future use.

Signed-off-by: Tom Rini 
---
 arch/arm/lib/bootm.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 178e8fb..39fe7a1 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -239,10 +239,12 @@ static void boot_prep_linux(bootm_headers_t *images)
 static void boot_jump_linux(bootm_headers_t *images, int flag)
 {
 #ifdef CONFIG_ARM64
-   void (*kernel_entry)(void *fdt_addr);
+   void (*kernel_entry)(void *fdt_addr, void *res0, void *res1,
+   void *res2);
int fake = (flag & BOOTM_STATE_OS_FAKE_GO);
 
-   kernel_entry = (void (*)(void *fdt_addr))images->ep;
+   kernel_entry = (void (*)(void *fdt_addr, void *res0, void *res1,
+   void *res2))images->ep;
 
debug("## Transferring control to Linux (at address %lx)...\n",
(ulong) kernel_entry);
@@ -252,7 +254,7 @@ static void boot_jump_linux(bootm_headers_t *images, int 
flag)
 
if (!fake) {
do_nonsec_virt_switch();
-   kernel_entry(images->ft_addr);
+   kernel_entry(images->ft_addr, NULL, NULL, NULL);
}
 #else
unsigned long machid = gd->bd->bi_arch_number;
-- 
1.7.9.5

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


[U-Boot] [PATCH v2 2/4] cmd_bootm.c: Add 'booti' for ARM64 Linux kernel Images

2014-08-14 Thread Tom Rini
The default format for arm64 Linux kernels is the "Image" format,
described in Documentation/arm64/booting.txt.  This, along with an
optional gzip compression on top is all that is generated by default.
The Image format has a magic number within the header for verification,
a text_offset where the Image must be run from, an image_size that
includes the BSS and reserved fields.

This does not support automatic detection of a gzip compressed image.

Signed-off-by: Tom Rini 

---
Changes in v1:
- Adopt to Mark Rutland's changes now in mainline kernel wrt text_offset
  / image_size
---
 README |1 +
 common/cmd_bootm.c |  140 
 include/bootm.h|2 +-
 3 files changed, 142 insertions(+), 1 deletion(-)

diff --git a/README b/README
index 1d71359..b9af7ac 100644
--- a/README
+++ b/README
@@ -959,6 +959,7 @@ The following options need to be configured:
CONFIG_CMD_BMP  * BMP support
CONFIG_CMD_BSP  * Board specific commands
CONFIG_CMD_BOOTD  bootd
+   CONFIG_CMD_BOOTI* ARM64 Linux kernel Image support
CONFIG_CMD_CACHE* icache, dcache
CONFIG_CMD_CLK  * clock command support
CONFIG_CMD_CONSOLEconinfo
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 8b897c8d..843ec6e 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -627,3 +627,143 @@ U_BOOT_CMD(
"boot Linux zImage image from memory", bootz_help_text
 );
 #endif /* CONFIG_CMD_BOOTZ */
+
+#ifdef CONFIG_CMD_BOOTI
+/* See Documentation/arm64/booting.txt in the Linux kernel */
+struct Image_header {
+   uint32_tcode0;  /* Executable code */
+   uint32_tcode1;  /* Executable code */
+   uint64_ttext_offset;/* Image load offset, LE */
+   uint64_timage_size; /* Effective Image size, LE */
+   uint64_tres1;   /* reserved */
+   uint64_tres2;   /* reserved */
+   uint64_tres3;   /* reserved */
+   uint64_tres4;   /* reserved */
+   uint32_tmagic;  /* Magic number */
+   uint32_tres5;
+};
+
+#define LINUX_ARM64_IMAGE_MAGIC0x644d5241
+
+static int booti_setup(bootm_headers_t *images)
+{
+   struct Image_header *ih;
+   uint64_t dst;
+
+   ih = (struct Image_header *)map_sysmem(images->ep, 0);
+
+   if (ih->magic != le32_to_cpu(LINUX_ARM64_IMAGE_MAGIC)) {
+   puts("Bad Linux ARM64 Image magic!\n");
+   return 1;
+   }
+   
+   if (ih->image_size == 0) {
+   puts("Image lacks image_size field, assuming 16MiB\n");
+   ih->image_size = (16 << 20);
+   }
+
+   /*
+* If we are not at the correct run-time location, set the new
+* correct location and then move the image there.
+*/
+   dst = gd->bd->bi_dram[0].start + le32_to_cpu(ih->text_offset);
+   if (images->ep != dst) {
+   void *src;
+
+   debug("Moving Image from 0x%lx to 0x%llx\n", images->ep, dst);
+
+   src = (void *)images->ep;
+   images->ep = dst;
+   memmove((void *)dst, src, le32_to_cpu(ih->image_size));
+   }
+
+   return 0;
+}
+
+/*
+ * Image booting support
+ */
+static int booti_start(cmd_tbl_t *cmdtp, int flag, int argc,
+   char * const argv[], bootm_headers_t *images)
+{
+   int ret;
+   struct Image_header *ih;
+
+   ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START,
+ images, 1);
+
+   /* Setup Linux kernel Image entry point */
+   if (!argc) {
+   images->ep = load_addr;
+   debug("*  kernel: default image load address = 0x%08lx\n",
+   load_addr);
+   } else {
+   images->ep = simple_strtoul(argv[0], NULL, 16);
+   debug("*  kernel: cmdline image address = 0x%08lx\n",
+   images->ep);
+   }
+
+   ret = booti_setup(images);
+   if (ret != 0)
+   return 1;
+
+   ih = (struct Image_header *)map_sysmem(images->ep, 0);
+
+   lmb_reserve(&images->lmb, images->ep, le32_to_cpu(ih->image_size));
+
+   /*
+* Handle the BOOTM_STATE_FINDOTHER state ourselves as we do not
+* have a header that provide this informaiton.
+*/
+   if (bootm_find_ramdisk_fdt(flag, argc, argv))
+   return 1;
+
+   return 0;
+}
+
+int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   int ret;
+
+   /* Consume 'booti' */
+   argc--; argv++;
+
+   if (booti_start(cmdtp, flag, argc, argv, &images))
+   return 1;
+
+   /*
+* We are doing the BOOTM_STATE_LOADOS state ourselves, so must
+* dis

[U-Boot] [PATCH v2 0/3] test: Extending USB gadget tests infrastructure

2014-08-14 Thread Lukasz Majewski
New test for UMS regressions catching has been added.
Moreover some DFU enhancements have been included as well.

Lukasz Majewski (3):
  test: dfu: Extend dfu_gadget_test_init.sh to accept sizes of test
files
  test: dfu: cosmetic: Add missing license information to DFU test
scripts
  test: ums: Add script for testing UMS gadget operation

 test/dfu/dfu_gadget_test.sh  |  10 +++
 test/dfu/dfu_gadget_test_init.sh |  16 +++-
 test/ums/README  |  26 ++
 test/ums/ums_gadget_test.sh  | 169 +++
 4 files changed, 220 insertions(+), 1 deletion(-)
 create mode 100644 test/ums/README
 create mode 100755 test/ums/ums_gadget_test.sh

-- 
2.0.0.rc2

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


[U-Boot] [PATCH v2 2/3] test: dfu: cosmetic: Add missing license information to DFU test scripts

2014-08-14 Thread Lukasz Majewski
By mistake I've forgotten to add the SPDX license tags for the DFU testing
scripts.
This commit fixes that and also provides some other relevant information.

Signed-off-by: Lukasz Majewski 
Acked-by: Stephen Warren 
---
Changes for v2:
- None
---
 test/dfu/dfu_gadget_test.sh  | 10 ++
 test/dfu/dfu_gadget_test_init.sh | 10 ++
 2 files changed, 20 insertions(+)

diff --git a/test/dfu/dfu_gadget_test.sh b/test/dfu/dfu_gadget_test.sh
index 4133155..2f5b7db 100755
--- a/test/dfu/dfu_gadget_test.sh
+++ b/test/dfu/dfu_gadget_test.sh
@@ -1,5 +1,15 @@
 #! /bin/bash
 
+# Copyright (C) 2014 Samsung Electronics
+# Lukasz Majewski 
+#
+# Script fixes, enhancements and testing:
+# Stephen Warren 
+#
+# DFU operation test script
+#
+# SPDX-License-Identifier: GPL-2.0+
+
 set -e # any command return if not equal to zero
 clear
 
diff --git a/test/dfu/dfu_gadget_test_init.sh b/test/dfu/dfu_gadget_test_init.sh
index 0d5c6c0..640628e 100755
--- a/test/dfu/dfu_gadget_test_init.sh
+++ b/test/dfu/dfu_gadget_test_init.sh
@@ -1,5 +1,15 @@
 #! /bin/bash
 
+# Copyright (C) 2014 Samsung Electronics
+# Lukasz Majewski 
+#
+# Script fixes, enhancements and testing:
+# Stephen Warren 
+#
+# Script for test files generation
+#
+# SPDX-License-Identifier: GPL-2.0+
+
 set -e # any command return if not equal to zero
 clear
 
-- 
2.0.0.rc2

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


[U-Boot] [PATCH v2 1/3] test: dfu: Extend dfu_gadget_test_init.sh to accept sizes of test files

2014-08-14 Thread Lukasz Majewski
It is now possible to pass to the dfu_gadget_test_init.sh script the sizes
of files to be generated.

This feature is required by UMS tests which reuse this code.

Signed-off-by: Lukasz Majewski 
Acked-by: Stephen Warren 
---
Changes for v2:
- None
---
 test/dfu/dfu_gadget_test_init.sh | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/test/dfu/dfu_gadget_test_init.sh b/test/dfu/dfu_gadget_test_init.sh
index 2163a68..0d5c6c0 100755
--- a/test/dfu/dfu_gadget_test_init.sh
+++ b/test/dfu/dfu_gadget_test_init.sh
@@ -9,7 +9,11 @@ COLOUR_DEFAULT="\33[0m"
 
 LOG_DIR="./log"
 
-TEST_FILES_SIZES="63 64 65 127 128 129 4095 4096 4097 959 960 961 1048575 
1048576 8M"
+if [ $# -eq 0 ]; then
+TEST_FILES_SIZES="63 64 65 127 128 129 4095 4096 4097 959 960 961 1048575 
1048576 8M"
+else
+TEST_FILES_SIZES=$@
+fi
 
 printf "Init script for generating data necessary for DFU test script"
 
-- 
2.0.0.rc2

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


[U-Boot] [PATCH v2 3/3] test: ums: Add script for testing UMS gadget operation

2014-08-14 Thread Lukasz Majewski
This commit adds new test for UMS USB gadget to u-boot mainline tree.
It is similar in operation to the one already available in test/dfu
directory.

Signed-off-by: Lukasz Majewski 

---
Changes for v2:
- Add -f switch for optional FS creation on target UMS partition
- Remove need for passing FS type to script
- Remove syncs
- Use named variables instead of $1, $2, $3 ... etc
- Create temporary mount directory at /mnt/tmp-ums-test/
- Use target device's VID/PID to find exact mount device (/dev/sdX)
- Add support for Ctrl+C tap
- Rewrite README entry
---
 test/ums/README |  26 +++
 test/ums/ums_gadget_test.sh | 169 
 2 files changed, 195 insertions(+)
 create mode 100644 test/ums/README
 create mode 100755 test/ums/ums_gadget_test.sh

diff --git a/test/ums/README b/test/ums/README
new file mode 100644
index 000..84906be
--- /dev/null
+++ b/test/ums/README
@@ -0,0 +1,26 @@
+UMS test script.
+
+ums_gadget_test.sh
+==
+
+Example usage:
+1. On the target:
+   create UMS exportable partitions (with e.g. gpt write)
+   ums 0 mmc 0
+2. On the host:
+   sudo test/ums/ums_gadget_test.sh VID PID PART_NUM [-f FILE_SYSTEM] 
[test_file]
+   e.g. sudo test/ums/ums_gadget_test.sh 04e8 6601 6 -f vfat ./dat_14M.img
+
+... where:
+VID - UMS device USB Vendor ID
+PID - UMS device USB Product ID
+PART_NUM - is the partition number on which UMS operates
+
+Information about available partitions on the target one can read with using
+the 'mmc part' or 'part list' commands.
+
+The [-f FILE_SYSTEM] optional switch allows for formatting target partition to
+FILE_SYSTEM.
+
+The last, optional [test_file] parameter is for specifying the exact test file
+to use.
diff --git a/test/ums/ums_gadget_test.sh b/test/ums/ums_gadget_test.sh
new file mode 100755
index 000..2cfa208
--- /dev/null
+++ b/test/ums/ums_gadget_test.sh
@@ -0,0 +1,169 @@
+#! /bin/bash
+
+# Copyright (C) 2014 Samsung Electronics
+# Lukasz Majewski 
+#
+# UMS operation test script
+#
+# SPDX-License-Identifier: GPL-2.0+
+
+clear
+
+COLOUR_RED="\33[31m"
+COLOUR_GREEN="\33[32m"
+COLOUR_DEFAULT="\33[0m"
+
+DIR=./
+SUFFIX=img
+RCV_DIR=rcv/
+LOG_FILE=./log/log-`date +%d-%m-%Y_%H-%M-%S`
+
+cd `dirname $0`
+../dfu/dfu_gadget_test_init.sh 33M 97M
+
+cleanup () {
+rm -rf $RCV_DIR $MNT_DIR
+}
+
+control_c()
+# run if user hits control-c
+{
+   echo -en "\n*** CTRL+C ***\n"
+   umount $MNT_DIR
+   cleanup
+   exit 0
+}
+
+# trap keyboard interrupt (control-c)
+trap control_c SIGINT
+
+die () {
+printf "   $COLOUR_RED FAILED $COLOUR_DEFAULT \n"
+cleanup
+exit 1
+}
+
+calculate_md5sum () {
+MD5SUM=`md5sum $1`
+MD5SUM=`echo $MD5SUM | cut -d ' ' -f1`
+echo "md5sum:"$MD5SUM
+}
+
+ums_test_file () {
+printf 
"$COLOUR_GREEN=
 $COLOUR_DEFAULT\n"
+printf "File:$COLOUR_GREEN %s $COLOUR_DEFAULT\n" $1
+
+mount /dev/$MEM_DEV $MNT_DIR
+if [ -f $MNT_DIR/dat_* ]; then
+   rm $MNT_DIR/dat_*
+fi
+
+cp ./$1 $MNT_DIR
+umount $MNT_DIR
+
+
+echo -n "TX: "
+calculate_md5sum $1
+
+MD5_TX=$MD5SUM
+sleep 1
+N_FILE=$DIR$RCV_DIR${1:2}"_rcv"
+
+mount /dev/$MEM_DEV $MNT_DIR
+cp $MNT_DIR/$1 $N_FILE || die $?
+rm $MNT_DIR/$1
+umount $MNT_DIR
+
+echo -n "RX: "
+calculate_md5sum $N_FILE
+MD5_RX=$MD5SUM
+
+if [ "$MD5_TX" == "$MD5_RX" ]; then
+   printf "   $COLOUR_GREEN ---> OK $COLOUR_DEFAULT \n"
+else
+   printf "   $COLOUR_RED ---> FAILED $COLOUR_DEFAULT \n"
+   cleanup
+   exit 1
+fi
+}
+
+printf 
"$COLOUR_GREEN=
 $COLOUR_DEFAULT\n"
+echo "U-boot UMS test program"
+
+if [ $EUID -ne 0 ]; then
+   echo "You must be root to do this." 1>&2
+   exit 100
+fi
+
+if [ $# -lt 3 ]; then
+echo "Wrong number of arguments"
+echo "Example:"
+echo "sudo ./ums_gadget_test.sh VID PID PART_NUM [-f ext4] [test_file]"
+die
+fi
+
+MNT_DIR="/mnt/tmp-ums-test"
+
+VID=$1; shift
+PID=$1; shift
+PART_NUM=$1; shift
+
+if [ "$1" == "-f" ]; then
+shift
+FS_TO_FORMAT=$1; shift
+fi
+
+TEST_FILE=$1
+
+idVendor=`find /sys -type f -name "idVendor" -exec grep -w $VID {} \;`
+idProduct=`find /sys -type f -name "idProduct" -exec grep -w $PID {} \;`
+if [ -z "$idVendor" ] || [ -z "$idProduct" ]; then
+echo "Device $VID:$PID not connected!"
+exit 0
+fi
+
+USB_DEV=`find /sys -type f -name "idProduct" -exec grep -l $PID {} \;`
+USB_DEV=`dirname $USB_DEV`
+
+MEM_DEV=`find $USB_DEV -name "sd[a-z]" | awk -F/ '{print $(NF)}' -`
+if [ -z $MEM_DEV ]; then
+echo "Connect target"
+echo "e.g. ums 0 mmc 0"
+die
+fi
+
+mkdir -p $RCV_DIR
+if [ ! -d $MNT_DIR ]; then
+mkdir -p $MNT_DIR
+fi
+
+MEM_DEV=$MEM_DEV$PART_NUM
+
+if [ -n "$FS_TO_FORMAT" ]; then
+echo -n "Formatting partition /dev/

Re: [U-Boot] [PATCH 1/3] README: document CONFIG_BOARD_SIZE_LIMIT

2014-08-14 Thread Anatolij Gustschin
On Sun, 11 Aug 2013 16:40:43 +0200
Sascha Silbe  wrote:

> CONFIG_BOARD_SIZE_LIMIT was introduced by f3a14d37 [Makefile: allow
> boards to check file size limits] and is in use by several boards, but
> never got documented.
> 
> Signed-off-by: Sascha Silbe 
> ---
>  README | 5 +
>  1 file changed, 5 insertions(+)

applied to u-boot-staging/ag...@denx.de. thanks!

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


Re: [U-Boot] [PATCH 3/3] openrd: fail build if U-Boot would overlap with environment in flash

2014-08-14 Thread Anatolij Gustschin
On Sun, 11 Aug 2013 16:40:45 +0200
Sascha Silbe  wrote:

> Set CONFIG_BOARD_SIZE_LIMIT so we'll notice at build time if U-Boot
> has grown so large that it would overlap with the environment area in
> flash, rather than bricking the device at run-time on first saveenv.
> 
> Signed-off-by: Sascha Silbe 
> ---
>  include/configs/openrd.h | 5 +
>  1 file changed, 5 insertions(+)

applied to u-boot-staging/ag...@denx.de. thanks!

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


Re: [U-Boot] [PATCH 2/3] Makefile: check native boot image sizes against CONFIG_BOARD_SIZE_LIMIT

2014-08-14 Thread Anatolij Gustschin
On Sun, 11 Aug 2013 16:40:44 +0200
Sascha Silbe  wrote:

> The purpose of CONFIG_BOARD_SIZE_LIMIT is to make sure that U-Boot
> fits into the space reserved for it in some permanent storage. This
> includes any overhead incurred by native boot image formats, so check
> the final image against the size limit, too.
> 
> Signed-off-by: Sascha Silbe 
> ---
>  Makefile | 3 +++
>  1 file changed, 3 insertions(+)

this patch doesn't apply any more.

Anatolij

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


Re: [U-Boot] [PATCH 3/4] mtd: nand: add Freescale NFC driver

2014-08-14 Thread Bill Pringlemeir
On 13 Aug 2014, scottw...@freescale.com wrote:

> On Wed, 2014-08-13 at 17:44 -0400, Bill Pringlemeir wrote:
>> Regarding "can't know in advance", I think that some of the register
>> values maybe set by the boot rom.  This might make more sense for
>> Linux than U-Boot.  However, after the initial configuration, many do
>> need the 'read/modify/write' as there are many bit fields with
>> different functionality.

> If the register is only modified by software, and not asynchronously
> by hardware, then you could read the value once when the driver
> starts, and cache its value to avoid a reportedly expensive I/O access
> every time you need to modify it.

Yes, that is a good point.  The regmap interface could be used in the
Linux kernel.  I don't see any infrastructure like that in U-Boot?  It
is fairly simple to re-invent as this driver only needs the flat
structure.

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


[U-Boot] [PATCH] nios2: Fix printf size_t format related warnings (again...)

2014-08-14 Thread Vasili Galka
When compiling the current code on GCC 4.8.3, the following warnings
appear:

warning: format '%zu' expects argument of type 'size_t', but argument
2 has type 'long unsigned int' [-Wformat=]

There were many mails about such warnings on different architectures.
This patch limits itself to the nios2 architecture.

The problem is that for the size_t (%zu, %zd, ...) arguments of
printf GCC does not verify the type match to size_t type. It verifies
the type match to the compiler-defined __SIZE_TYPE__ type. Thus, if
size_t is defined different from __SIZE_TYPE__ - warnings inevitably
appear.

There is a comment by Thomas Chou to the (rejected) patch:
http://patchwork.ozlabs.org/patch/272102/
which explains that the older GCC toolchains (gcc-3.4.6 and gcc-4.1.2)
expect size_t to be "unsigned long" and the newer expect it to be
"unsigned int". Thus, no matter how we define size_t - either way
warnings appear when using some GCC version.

By rejecting that patch, a choice was made to prefer older GCC versions
and leave the warnings when building with the newer toolchains.
Personally, I disagree with this choice...

In any case, this patch proposes a way to fix the warnings for any GCC
version. Just define size_t using the __SIZE_TYPE__ compiler-defined
type and the type verification will pass.

I tested that this fixes the warning on GCC 4.8.3. I don't have an
older toolchain to test with, but __SIZE_TYPE__ was definitely defined
in GCC 3.4.6, so it should work there too.

Signed-off-by: Vasili Galka 
Cc: Thomas Chou 
---
 arch/nios2/include/asm/posix_types.h |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/nios2/include/asm/posix_types.h 
b/arch/nios2/include/asm/posix_types.h
index 6733640..6b6c39b 100644
--- a/arch/nios2/include/asm/posix_types.h
+++ b/arch/nios2/include/asm/posix_types.h
@@ -16,7 +16,11 @@ typedef int  __kernel_pid_t;
 typedef unsigned short __kernel_ipc_pid_t;
 typedef unsigned short __kernel_uid_t;
 typedef unsigned short __kernel_gid_t;
+#ifdef __GNUC__
+typedef __SIZE_TYPE__  __kernel_size_t;
+#else
 typedef unsigned long  __kernel_size_t;
+#endif
 typedef long   __kernel_ssize_t;
 typedef int__kernel_ptrdiff_t;
 typedef long   __kernel_time_t;
-- 
1.7.9

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


[U-Boot] [PATCH] sbc8548: enable and test CONFIG_SYS_GENERIC_BOARD

2014-08-14 Thread Paul Gortmaker
Tested on the following baseline (note "dirty" since I enabled
ALT_BOOT in the config in order to use the alternate boot bank.)

Everything seems to work fine with no additional changes.  The
banner warning message is now gone.

 ---

U-Boot 2014.10-rc1-00075-ge49f14af1349-dirty (Aug 14 2014 - 10:26:15)

CPU:   8548E, Version: 2.1, (0x80390021)
Core:  e500, Version: 2.2, (0x80210022)
Clock Configuration:
   CPU0:990  MHz,
   CCB:396  MHz,
   DDR:198  MHz (396 MT/s data rate), LBC:99   MHz
L1:D-cache 32 KiB enabled
   I-cache 32 KiB enabled
I2C:   ready
DRAM:  Detected UDIMM
SDRAM: 128 MiB
256 MiB (DDR2, 64-bit, CL=3, ECC off)
Flash: 72 MiB
L2:512 KiB enabled
*** Warning - bad CRC, using default environment

PCI: Host, 64 bit, 66 MHz, sync, arbiter
  00:01.0 - 8086:1026 - Network controller
PCI1: Bus 00 - 00

PCIe1: Root Complex, x1 gen1, regs @ 0xe000a000
  02:00.0 - 1148:9e00 - Network controller
PCIe1: Bus 01 - 02
In:serial
Out:   serial
Err:   serial
Net:   eTSEC0 [PRIME], eTSEC1
Hit any key to stop autoboot:  0
=> ver

U-Boot 2014.10-rc1-00075-ge49f14af1349-dirty (Aug 14 2014 - 10:26:15)
powerpc-linux-gcc (GCC) 4.5.2
GNU ld (GNU Binutils) 2.21
=>

 ---

Signed-off-by: Paul Gortmaker 
---
 include/configs/sbc8548.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/sbc8548.h b/include/configs/sbc8548.h
index f28f350fcc86..aee0d9e27309 100644
--- a/include/configs/sbc8548.h
+++ b/include/configs/sbc8548.h
@@ -13,6 +13,8 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
+#define CONFIG_SYS_GENERIC_BOARD
+
 /*
  * Top level Makefile configuration choices
  */
-- 
1.9.2

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


Re: [U-Boot] [PATCH v2 2/4] cmd_bootm.c: Add 'booti' for ARM64 Linux kernel Images

2014-08-14 Thread Mark Rutland
Hi Tom,

On Thu, Aug 14, 2014 at 11:42:36AM +0100, Tom Rini wrote:
> The default format for arm64 Linux kernels is the "Image" format,
> described in Documentation/arm64/booting.txt.  This, along with an
> optional gzip compression on top is all that is generated by default.
> The Image format has a magic number within the header for verification,
> a text_offset where the Image must be run from, an image_size that
> includes the BSS and reserved fields.
> 
> This does not support automatic detection of a gzip compressed image.
> 
> Signed-off-by: Tom Rini 
> 
> ---
> Changes in v1:
> - Adopt to Mark Rutland's changes now in mainline kernel wrt text_offset
>   / image_size
> ---
>  README |1 +
>  common/cmd_bootm.c |  140 
> 
>  include/bootm.h|2 +-
>  3 files changed, 142 insertions(+), 1 deletion(-)
> 
> diff --git a/README b/README
> index 1d71359..b9af7ac 100644
> --- a/README
> +++ b/README
> @@ -959,6 +959,7 @@ The following options need to be configured:
>   CONFIG_CMD_BMP  * BMP support
>   CONFIG_CMD_BSP  * Board specific commands
>   CONFIG_CMD_BOOTD  bootd
> + CONFIG_CMD_BOOTI* ARM64 Linux kernel Image support
>   CONFIG_CMD_CACHE* icache, dcache
>   CONFIG_CMD_CLK  * clock command support
>   CONFIG_CMD_CONSOLEconinfo
> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
> index 8b897c8d..843ec6e 100644
> --- a/common/cmd_bootm.c
> +++ b/common/cmd_bootm.c
> @@ -627,3 +627,143 @@ U_BOOT_CMD(
>   "boot Linux zImage image from memory", bootz_help_text
>  );
>  #endif   /* CONFIG_CMD_BOOTZ */
> +
> +#ifdef CONFIG_CMD_BOOTI
> +/* See Documentation/arm64/booting.txt in the Linux kernel */
> +struct Image_header {
> + uint32_tcode0;  /* Executable code */
> + uint32_tcode1;  /* Executable code */
> + uint64_ttext_offset;/* Image load offset, LE */
> + uint64_timage_size; /* Effective Image size, LE */
> + uint64_tres1;   /* reserved */
> + uint64_tres2;   /* reserved */
> + uint64_tres3;   /* reserved */
> + uint64_tres4;   /* reserved */
> + uint32_tmagic;  /* Magic number */
> + uint32_tres5;
> +};
> +
> +#define LINUX_ARM64_IMAGE_MAGIC  0x644d5241
> +
> +static int booti_setup(bootm_headers_t *images)
> +{
> + struct Image_header *ih;
> + uint64_t dst;
> +
> + ih = (struct Image_header *)map_sysmem(images->ep, 0);
> +
> + if (ih->magic != le32_to_cpu(LINUX_ARM64_IMAGE_MAGIC)) {
> + puts("Bad Linux ARM64 Image magic!\n");
> + return 1;
> + }
> + 
> + if (ih->image_size == 0) {
> + puts("Image lacks image_size field, assuming 16MiB\n");
> + ih->image_size = (16 << 20);
> + }

This should work for a defconfig, but it might be possible to build a
larger kernel. From experiments with an allyesconfig, I can build a
~60MB kernel with ~20MB of uninitialised data after the end of the
Image.

Modifying the Image feels a little dodgy, but I can't think of anything
this would break.

> +
> + /*
> +  * If we are not at the correct run-time location, set the new
> +  * correct location and then move the image there.
> +  */
> + dst = gd->bd->bi_dram[0].start + le32_to_cpu(ih->text_offset);

This should be le64_to_cpu(ih->text_offset) to be strictly correct.

I wouldn't imagine we'd ever have a text_offset larger than 4GB, but it
would be nice to keep things consistent with the documentation and
kernel code.

> + if (images->ep != dst) {
> + void *src;
> +
> + debug("Moving Image from 0x%lx to 0x%llx\n", images->ep, dst);
> +
> + src = (void *)images->ep;
> + images->ep = dst;
> + memmove((void *)dst, src, le32_to_cpu(ih->image_size));

Likewise.

> + }
> +
> + return 0;
> +}
> +
> +/*
> + * Image booting support
> + */
> +static int booti_start(cmd_tbl_t *cmdtp, int flag, int argc,
> + char * const argv[], bootm_headers_t *images)
> +{
> + int ret;
> + struct Image_header *ih;
> +
> + ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START,
> +   images, 1);
> +
> + /* Setup Linux kernel Image entry point */
> + if (!argc) {
> + images->ep = load_addr;
> + debug("*  kernel: default image load address = 0x%08lx\n",
> + load_addr);
> + } else {
> + images->ep = simple_strtoul(argv[0], NULL, 16);
> + debug("*  kernel: cmdline image address = 0x%08lx\n",
> + images->ep);
> + }
> +
> + ret = booti_setup(images);
> + if (ret != 0)
> + return 1;
> +
>

Re: [U-Boot] [PATCH 02/11] imx: ventana: added cputype env var

2014-08-14 Thread Stefano Babic
On 08/08/2014 07:35, Tim Harvey wrote:
> There are many similarities between the IMX6QUAD/IMX6DUAL and there are
> many similarities between the IMX6SOLO/IMX6DUALITE. Add a 'soctype' env
> variable that tells you which type you have.
> 
> Signed-off-by: Tim Harvey 
> ---
>  board/gateworks/gw_ventana/gw_ventana.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/board/gateworks/gw_ventana/gw_ventana.c 
> b/board/gateworks/gw_ventana/gw_ventana.c
> index a8fcb5d..de2336e 100644
> --- a/board/gateworks/gw_ventana/gw_ventana.c
> +++ b/board/gateworks/gw_ventana/gw_ventana.c
> @@ -1264,6 +1264,7 @@ int misc_init_r(void)
>   else if (is_cpu_type(MXC_CPU_MX6DL) ||
>is_cpu_type(MXC_CPU_MX6SOLO))
>   cputype = "imx6dl";
> + setenv("soctype", cputype);

So you have soc=mx6 and soctype=, if CONFIG_SYS_SOC is
set.

Is it important to have both or you can simply redefine the variable "soc" ?

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings

2014-08-14 Thread Stephen Warren

On 08/14/2014 02:25 AM, Alexander Holler wrote:

Am 31.07.2014 21:57, schrieb Stephen Warren:


Huh, I do see that now. I must have been looking at the content of
common/cmd_nvedit.c from the wrong branch, which didn't include that
patch. I could have sworn I checked git history too, but evidently not.
It is indeed clearly there right before the patches which use it. Sorry
for the noise.


As I've just remembered where I did see your name before, the config for
the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to
execute commands when using uEnv.txt.

It's easily done with something like the following:

"env import -t -r $loadaddr $filesize;" \
"if test -n \"$uenvcmd\"; then " \
"echo \"Running uenvcmd ...\";" \
"run uenvcmd;" \
"fi;" \


My intention was that uEnv.txt be used to set up environment variables, 
not to allow its use for custom scripts.


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


[U-Boot] [PATCH v2 2/4] arm: vf610: add NFC clock support

2014-08-14 Thread Stefan Agner
Add NFC (NAND Flash Controller) clock support and enable them
at board initialization time.

Signed-off-by: Stefan Agner 
---
 arch/arm/include/asm/arch-vf610/crm_regs.h | 14 ++
 arch/arm/include/asm/arch-vf610/imx-regs.h |  1 +
 2 files changed, 15 insertions(+)

diff --git a/arch/arm/include/asm/arch-vf610/crm_regs.h 
b/arch/arm/include/asm/arch-vf610/crm_regs.h
index 5256624..724682c 100644
--- a/arch/arm/include/asm/arch-vf610/crm_regs.h
+++ b/arch/arm/include/asm/arch-vf610/crm_regs.h
@@ -156,14 +156,27 @@ struct anadig_reg {
 #define CCM_CSCMR1_ESDHC1_CLK_SEL_OFFSET   18
 #define CCM_CSCMR1_ESDHC1_CLK_SEL_MASK (0x3 << 18)
 #define CCM_CSCMR1_ESDHC1_CLK_SEL(v)   (((v) & 0x3) << 18)
+#define CCM_CSCMR1_NFC_CLK_SEL_OFFSET  12
+#define CCM_CSCMR1_NFC_CLK_SEL_MASK(0x3 << 12)
+#define CCM_CSCMR1_NFC_CLK_SEL(v)  (((v) & 0x3) << 12)
 
 #define CCM_CSCDR1_RMII_CLK_EN (1 << 24)
 
+#define CCM_CSCDR2_NFC_EN  (1 << 9)
+#define CCM_CSCDR2_NFC_FRAC_DIV_EN (1 << 13)
+#define CCM_CSCDR2_NFC_CLK_INV (1 << 14)
+#define CCM_CSCDR2_NFC_FRAC_DIV_OFFSET 4
+#define CCM_CSCDR2_NFC_FRAC_DIV_MASK   (0xf << 4)
+#define CCM_CSCDR2_NFC_FRAC_DIV(v) (((v) & 0xf) << 4)
+
 #define CCM_CSCDR2_ESDHC1_EN   (1 << 29)
 #define CCM_CSCDR2_ESDHC1_CLK_DIV_OFFSET   20
 #define CCM_CSCDR2_ESDHC1_CLK_DIV_MASK (0xf << 20)
 #define CCM_CSCDR2_ESDHC1_CLK_DIV(v)   (((v) & 0xf) << 20)
 
+#define CCM_CSCDR3_NFC_PRE_DIV_OFFSET  13
+#define CCM_CSCDR3_NFC_PRE_DIV_MASK(0x7 << 13)
+#define CCM_CSCDR3_NFC_PRE_DIV(v)  (((v) & 0x7) << 13)
 #define CCM_CSCDR3_QSPI0_EN(1 << 4)
 #define CCM_CSCDR3_QSPI0_DIV(v)((v) << 3)
 #define CCM_CSCDR3_QSPI0_X2_DIV(v) ((v) << 2)
@@ -195,6 +208,7 @@ struct anadig_reg {
 #define CCM_CCGR7_SDHC1_CTRL_MASK  (0x3 << 4)
 #define CCM_CCGR9_FEC0_CTRL_MASK   0x3
 #define CCM_CCGR9_FEC1_CTRL_MASK   (0x3 << 2)
+#define CCM_CCGR10_NFC_CTRL_MASK   0x3
 
 #define ANADIG_PLL5_CTRL_BYPASS (1 << 16)
 #define ANADIG_PLL5_CTRL_ENABLE (1 << 13)
diff --git a/arch/arm/include/asm/arch-vf610/imx-regs.h 
b/arch/arm/include/asm/arch-vf610/imx-regs.h
index bd6f680..bb00217 100644
--- a/arch/arm/include/asm/arch-vf610/imx-regs.h
+++ b/arch/arm/include/asm/arch-vf610/imx-regs.h
@@ -86,6 +86,7 @@
 #define ESDHC1_BASE_ADDR   (AIPS1_BASE_ADDR + 0x00032000)
 #define ENET_BASE_ADDR (AIPS1_BASE_ADDR + 0x0005)
 #define ENET1_BASE_ADDR(AIPS1_BASE_ADDR + 0x00051000)
+#define NFC_BASE_ADDR  (AIPS1_BASE_ADDR + 0x0006)
 
 #define QSPI0_AMBA_BASE0x2000
 
-- 
2.0.4

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


[U-Boot] [PATCH v2 4/4] arm: vf610: add NAND support for vf610twr

2014-08-14 Thread Stefan Agner
This adds NAND Flash Controller (NFC) support for the Vybrid tower
system (TWR-VF65GS10). Full 16-Bit bus width is supported. Also an
aditional config vf610twr_nand is introduced which gets the
environment from NAND. However, booting U-Boot from NAND is not
yet possible due to missing boot configuration block (BCB).

Signed-off-by: Stefan Agner 
---
 board/freescale/vf610twr/vf610twr.c | 47 ++---
 configs/vf610twr_defconfig  |  2 +-
 configs/vf610twr_nand_defconfig |  3 +++
 include/configs/vf610twr.h  | 46 +++-
 4 files changed, 93 insertions(+), 5 deletions(-)
 create mode 100644 configs/vf610twr_nand_defconfig

diff --git a/board/freescale/vf610twr/vf610twr.c 
b/board/freescale/vf610twr/vf610twr.c
index 54a9f2c..4d09796 100644
--- a/board/freescale/vf610twr/vf610twr.c
+++ b/board/freescale/vf610twr/vf610twr.c
@@ -278,6 +278,39 @@ static void setup_iomux_i2c(void)
imx_iomux_v3_setup_multiple_pads(i2c0_pads, ARRAY_SIZE(i2c0_pads));
 }
 
+#ifdef CONFIG_NAND_VF610_NFC
+static void setup_iomux_nfc(void)
+{
+   static const iomux_v3_cfg_t nfc_pads[] = {
+   VF610_PAD_PTD31__NF_IO15,
+   VF610_PAD_PTD30__NF_IO14,
+   VF610_PAD_PTD29__NF_IO13,
+   VF610_PAD_PTD28__NF_IO12,
+   VF610_PAD_PTD27__NF_IO11,
+   VF610_PAD_PTD26__NF_IO10,
+   VF610_PAD_PTD25__NF_IO9,
+   VF610_PAD_PTD24__NF_IO8,
+   VF610_PAD_PTD23__NF_IO7,
+   VF610_PAD_PTD22__NF_IO6,
+   VF610_PAD_PTD21__NF_IO5,
+   VF610_PAD_PTD20__NF_IO4,
+   VF610_PAD_PTD19__NF_IO3,
+   VF610_PAD_PTD18__NF_IO2,
+   VF610_PAD_PTD17__NF_IO1,
+   VF610_PAD_PTD16__NF_IO0,
+   VF610_PAD_PTB24__NF_WE_B,
+   VF610_PAD_PTB25__NF_CE0_B,
+   VF610_PAD_PTB27__NF_RE_B,
+   VF610_PAD_PTC26__NF_RB_B,
+   VF610_PAD_PTC27__NF_ALE,
+   VF610_PAD_PTC28__NF_CLE
+   };
+
+   imx_iomux_v3_setup_multiple_pads(nfc_pads, ARRAY_SIZE(nfc_pads));
+}
+#endif
+
+
 static void setup_iomux_qspi(void)
 {
static const iomux_v3_cfg_t qspi0_pads[] = {
@@ -354,6 +387,8 @@ static void clock_init(void)
CCM_CCGR7_SDHC1_CTRL_MASK);
clrsetbits_le32(&ccm->ccgr9, CCM_REG_CTRL_MASK,
CCM_CCGR9_FEC0_CTRL_MASK | CCM_CCGR9_FEC1_CTRL_MASK);
+   clrsetbits_le32(&ccm->ccgr10, CCM_REG_CTRL_MASK,
+   CCM_CCGR10_NFC_CTRL_MASK);
 
clrsetbits_le32(&anadig->pll2_ctrl, ANADIG_PLL2_CTRL_POWERDOWN,
ANADIG_PLL2_CTRL_ENABLE | ANADIG_PLL2_CTRL_DIV_SELECT);
@@ -373,14 +408,17 @@ static void clock_init(void)
CCM_CACRR_IPG_CLK_DIV(1) | CCM_CACRR_BUS_CLK_DIV(2) |
CCM_CACRR_ARM_CLK_DIV(0));
clrsetbits_le32(&ccm->cscmr1, CCM_REG_CTRL_MASK,
-   CCM_CSCMR1_ESDHC1_CLK_SEL(3) | CCM_CSCMR1_QSPI0_CLK_SEL(3));
+   CCM_CSCMR1_ESDHC1_CLK_SEL(3) | CCM_CSCMR1_QSPI0_CLK_SEL(3) |
+   CCM_CSCMR1_NFC_CLK_SEL(0));
clrsetbits_le32(&ccm->cscdr1, CCM_REG_CTRL_MASK,
CCM_CSCDR1_RMII_CLK_EN);
clrsetbits_le32(&ccm->cscdr2, CCM_REG_CTRL_MASK,
-   CCM_CSCDR2_ESDHC1_EN | CCM_CSCDR2_ESDHC1_CLK_DIV(0));
+   CCM_CSCDR2_ESDHC1_EN | CCM_CSCDR2_ESDHC1_CLK_DIV(0) |
+   CCM_CSCDR2_NFC_EN);
clrsetbits_le32(&ccm->cscdr3, CCM_REG_CTRL_MASK,
CCM_CSCDR3_QSPI0_EN | CCM_CSCDR3_QSPI0_DIV(1) |
-   CCM_CSCDR3_QSPI0_X2_DIV(1) | CCM_CSCDR3_QSPI0_X4_DIV(3));
+   CCM_CSCDR3_QSPI0_X2_DIV(1) | CCM_CSCDR3_QSPI0_X4_DIV(3) |
+   CCM_CSCDR3_NFC_PRE_DIV(5));
clrsetbits_le32(&ccm->cscmr2, CCM_REG_CTRL_MASK,
CCM_CSCMR2_RMII_CLK_SEL(0));
 }
@@ -411,6 +449,9 @@ int board_early_init_f(void)
setup_iomux_enet();
setup_iomux_i2c();
setup_iomux_qspi();
+#ifdef CONFIG_NAND_VF610_NFC
+   setup_iomux_nfc();
+#endif
 
return 0;
 }
diff --git a/configs/vf610twr_defconfig b/configs/vf610twr_defconfig
index 10e6432..7de374a 100644
--- a/configs/vf610twr_defconfig
+++ b/configs/vf610twr_defconfig
@@ -1,3 +1,3 @@
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/vf610twr/imximage.cfg"
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/vf610twr/imximage.cfg,ENV_IS_IN_MMC"
 CONFIG_ARM=y
 CONFIG_TARGET_VF610TWR=y
diff --git a/configs/vf610twr_nand_defconfig b/configs/vf610twr_nand_defconfig
new file mode 100644
index 000..e78db26
--- /dev/null
+++ b/configs/vf610twr_nand_defconfig
@@ -0,0 +1,3 @@
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/vf610twr/imximage.cfg,ENV_IS_IN_NAND"
+CONFIG_ARM=y
+CONFIG_TARGET_VF610TWR=y
diff --git a/include/configs/vf610twr.h b/include/configs/vf610twr.h
index 0342550..6fd0b17 100644
--- a/include/configs/vf610twr.h
+++ b/include/configs/vf610twr.h

[U-Boot] [PATCH v2 0/4] arm: vf610: add NAND flash support

2014-08-14 Thread Stefan Agner
This patch set adds NAND Flash Controller (NFC) support for
Freescale Vybrid ARM SoCs (vf610).

The driver is based on Bill Pringlemeirs prelineary patch sent
in January 2014 to the MTD mailing list:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226623.html

Changes in v2:
- Renamed the driver from fsl_nfc to vf610_nfc
- Use writel/readl in register access functions
- Optimized some register accesses by read/write value only once in code
- Use CONFIG_SYS_NAND_SELF_INIT and fix board_nand_init implementation
- Removed uncommented code/fixed comments
- Add CONFIG_USE_ARCH_MEMCPY for improved NAND performance
- Use hweight32 for improved count_written_bits performance
- Implement page_read/page_write rather than reuse MTD stacks version

Due to the duplicated initialization (missing SELF_INIT), page size was
actually set to 0 which lead count_written_bits to not count the amount of
written bits at all.

Performance numbers:
V1 => optimized count_written_bits
Read empty pages: 0.8MiB/s => 1.4MiB/s
V1 => optimized memcpy => optimized page_read/page_write
Read full pages: 3.6MiB/s => 7MiB/s => 10.3MiB/s

Stefan Agner (4):
  arm: vf610: add NFC pin mux
  arm: vf610: add NFC clock support
  mtd: nand: add Freescale NFC driver
  arm: vf610: add NAND support for vf610twr

 arch/arm/include/asm/arch-vf610/crm_regs.h|  14 +
 arch/arm/include/asm/arch-vf610/imx-regs.h|   1 +
 arch/arm/include/asm/arch-vf610/iomux-vf610.h |  34 ++
 arch/arm/include/asm/imx-common/iomux-v3.h|   4 +
 board/freescale/vf610twr/vf610twr.c   |  47 +-
 configs/vf610twr_defconfig|   2 +-
 configs/vf610twr_nand_defconfig   |   3 +
 drivers/mtd/nand/Makefile |   1 +
 drivers/mtd/nand/vf610_nfc.c  | 706 ++
 include/configs/vf610twr.h|  46 +-
 10 files changed, 853 insertions(+), 5 deletions(-)
 create mode 100644 configs/vf610twr_nand_defconfig
 create mode 100644 drivers/mtd/nand/vf610_nfc.c

-- 
2.0.4

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


[U-Boot] [PATCH v2 1/4] arm: vf610: add NFC pin mux

2014-08-14 Thread Stefan Agner
Add pin mux for NAND Flash Controller (NFC). NAND can be connected
using 8 or 16 data lines, this patch adds pin mux entries for all
16 data lines.

Signed-off-by: Stefan Agner 
---
 arch/arm/include/asm/arch-vf610/iomux-vf610.h | 34 +++
 arch/arm/include/asm/imx-common/iomux-v3.h|  4 
 2 files changed, 38 insertions(+)

diff --git a/arch/arm/include/asm/arch-vf610/iomux-vf610.h 
b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
index a965641..7464da8 100644
--- a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
+++ b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
@@ -19,6 +19,13 @@
 #define VF610_DDR_PAD_CTRL PAD_CTL_DSE_25ohm
 #define VF610_I2C_PAD_CTRL (PAD_CTL_PUS_47K_UP | PAD_CTL_DSE_50ohm | \
PAD_CTL_SPEED_HIGH | PAD_CTL_OBE_IBE_ENABLE)
+#define VF610_NFC_IO_PAD_CTRL  (PAD_CTL_SPEED_MED | PAD_CTL_SRE | \
+   PAD_CTL_DSE_50ohm | PAD_CTL_PUS_47K_UP | \
+   PAD_CTL_OBE_IBE_ENABLE)
+#define VF610_NFC_CN_PAD_CTRL  (PAD_CTL_SPEED_MED | PAD_CTL_SRE | \
+   PAD_CTL_DSE_25ohm | PAD_CTL_OBE_ENABLE)
+#define VF610_NFC_RB_PAD_CTRL  (PAD_CTL_SPEED_MED | PAD_CTL_SRE | \
+   PAD_CTL_PUS_22K_UP | PAD_CTL_IBE_ENABLE)
 
 #define VF610_QSPI_PAD_CTRL(PAD_CTL_SPEED_HIGH | PAD_CTL_DSE_150ohm | \
PAD_CTL_PUS_22K_UP | PAD_CTL_OBE_IBE_ENABLE)
@@ -56,6 +63,15 @@ 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_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),
+   VF610_PAD_PTD28__NF_IO12= IOMUX_PAD(0x0108, 0x0108, 2, 
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+   VF610_PAD_PTD27__NF_IO11= IOMUX_PAD(0x010c, 0x010c, 2, 
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+   VF610_PAD_PTD26__NF_IO10= IOMUX_PAD(0x0110, 0x0110, 2, 
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+   VF610_PAD_PTD25__NF_IO9 = IOMUX_PAD(0x0114, 0x0114, 2, 
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+   VF610_PAD_PTD24__NF_IO8 = IOMUX_PAD(0x0118, 0x0118, 2, 
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+   VF610_PAD_PTD23__NF_IO7 = IOMUX_PAD(0x011c, 0x011c, 2, 
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
VF610_PAD_PTD0__QSPI0_A_QSCK= IOMUX_PAD(0x013c, 0x013c, 1, 
__NA_, 0, VF610_QSPI_PAD_CTRL),
VF610_PAD_PTD1__QSPI0_A_CS0 = IOMUX_PAD(0x0140, 0x0140, 1, 
__NA_, 0, VF610_QSPI_PAD_CTRL),
VF610_PAD_PTD2__QSPI0_A_DATA3   = IOMUX_PAD(0x0144, 0x0144, 1, 
__NA_, 0, VF610_QSPI_PAD_CTRL),
@@ -68,6 +84,24 @@ enum {
VF610_PAD_PTD10__QSPI0_B_DATA2  = IOMUX_PAD(0x0164, 0x0164, 1, 
__NA_, 0, VF610_QSPI_PAD_CTRL),
VF610_PAD_PTD11__QSPI0_B_DATA1  = IOMUX_PAD(0x0168, 0x0168, 1, 
__NA_, 0, VF610_QSPI_PAD_CTRL),
VF610_PAD_PTD12__QSPI0_B_DATA0  = IOMUX_PAD(0x016c, 0x016c, 1, 
__NA_, 0, VF610_QSPI_PAD_CTRL),
+   VF610_PAD_PTD22__NF_IO6 = IOMUX_PAD(0x0120, 0x0120, 2, 
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+   VF610_PAD_PTD21__NF_IO5 = IOMUX_PAD(0x0124, 0x0124, 2, 
__NA_, 0, VF610_NFC_IO_PAD_CTRL), 
+   VF610_PAD_PTD20__NF_IO4 = IOMUX_PAD(0x0128, 0x0128, 2, 
__NA_, 0, VF610_NFC_IO_PAD_CTRL), 
+   VF610_PAD_PTD19__NF_IO3 = IOMUX_PAD(0x012c, 0x012c, 2, 
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+   VF610_PAD_PTD18__NF_IO2 = IOMUX_PAD(0x0130, 0x0130, 2, 
__NA_, 0, VF610_NFC_IO_PAD_CTRL), 
+   VF610_PAD_PTD17__NF_IO1 = IOMUX_PAD(0x0134, 0x0134, 2, 
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+   VF610_PAD_PTD16__NF_IO0 = IOMUX_PAD(0x0138, 0x0138, 2, 
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+   VF610_PAD_PTB24__NF_WE_B= IOMUX_PAD(0x0178, 0x0178, 5, 
__NA_, 0, VF610_NFC_CN_PAD_CTRL),
+   VF610_PAD_PTB25__NF_CE0_B   = IOMUX_PAD(0x017c, 0x017c, 5, 
__NA_, 0, VF610_NFC_CN_PAD_CTRL),
+
+   VF610_PAD_PTB27__NF_RE_B= IOMUX_PAD(0x0184, 0x0184, 6, 
__NA_, 0, VF610_NFC_CN_PAD_CTRL),
+
+   VF610_PAD_PTC26__NF_RB_B= IOMUX_PAD(0x018C, 0x018C, 5, 
__NA_, 0, VF610_NFC_RB_PAD_CTRL),
+
+   VF610_PAD_PTC27__NF_ALE = IOMUX_PAD(0x0190, 0x0190, 6, 
__NA_, 0, VF610_NFC_CN_PAD_CTRL),
+
+   VF610_PAD_PTC28__NF_CLE = IOMUX_PAD(0x0194, 0x0194, 

[U-Boot] [PATCH v2 3/4] mtd: nand: add Freescale NFC driver

2014-08-14 Thread Stefan Agner
This adds initial support for Freescale NFC (NAND Flash Controller)
found in ARM Vybrid SoC's, Power Architecture MPC5125 and others.
However, this driver is only tested on Vybrid.

Signed-off-by: Stefan Agner 
---
 drivers/mtd/nand/Makefile|   1 +
 drivers/mtd/nand/vf610_nfc.c | 706 +++
 2 files changed, 707 insertions(+)
 create mode 100644 drivers/mtd/nand/vf610_nfc.c

diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index bf1312a..eef86d1 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_NAND_KB9202) += kb9202_nand.o
 obj-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o
 obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o
 obj-$(CONFIG_NAND_MPC5121_NFC) += mpc5121_nfc.o
+obj-$(CONFIG_NAND_VF610_NFC) += vf610_nfc.o
 obj-$(CONFIG_NAND_MXC) += mxc_nand.o
 obj-$(CONFIG_NAND_MXS) += mxs_nand.o
 obj-$(CONFIG_NAND_NDFC) += ndfc.o
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
new file mode 100644
index 000..3150ac1
--- /dev/null
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -0,0 +1,706 @@
+/*
+ * Copyright 2009-2014 Freescale Semiconductor, Inc. and others
+ *
+ * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver.
+ * Ported to U-Boot by Stefan Agner
+ * Based on RFC driver posted on Kernel Mailing list by Bill Pringlemeir
+ * Jason ported to M54418TWR and MVFA5.
+ * Authors: Stefan Agner 
+ *  Bill Pringlemeir 
+ *  Shaohui Xie 
+ *  Jason Jin 
+ *
+ * Based on original driver mpc5121_nfc.c.
+ *
+ * This is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Limitations:
+ * - Untested on MPC5125 and M54418.
+ * - DMA not used.
+ * - 2K pages or less.
+ * - Only 2K page w. 64+OOB and hardware ECC.
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#defineDRV_NAME"fsl_nfc"
+
+/* Register Offsets */
+#define NFC_FLASH_CMD1 0x3F00
+#define NFC_FLASH_CMD2 0x3F04
+#define NFC_COL_ADDR   0x3F08
+#define NFC_ROW_ADDR   0x3F0c
+#define NFC_ROW_ADDR_INC   0x3F14
+#define NFC_FLASH_STATUS1  0x3F18
+#define NFC_FLASH_STATUS2  0x3F1c
+#define NFC_CACHE_SWAP 0x3F28
+#define NFC_SECTOR_SIZE0x3F2c
+#define NFC_FLASH_CONFIG   0x3F30
+#define NFC_IRQ_STATUS 0x3F38
+
+/* Addresses for NFC MAIN RAM BUFFER areas */
+#define NFC_MAIN_AREA(n)   ((n) *  0x1000)
+
+#define PAGE_2K0x0800
+#define OOB_64 0x0040
+
+/*
+ * NFC_CMD2[CODE] values. See section:
+ *  - 31.4.7 Flash Command Code Description, Vybrid manual
+ *  - 23.8.6 Flash Command Sequencer, MPC5125 manual
+ *
+ * Briefly these are bitmasks of controller cycles.
+ */
+#define READ_PAGE_CMD_CODE 0x7EE0
+#define PROGRAM_PAGE_CMD_CODE  0x7FC0
+#define ERASE_CMD_CODE 0x4EC0
+#define READ_ID_CMD_CODE   0x4804
+#define RESET_CMD_CODE 0x4040
+#define STATUS_READ_CMD_CODE   0x4068
+
+/* NFC ECC mode define */
+#define ECC_BYPASS 0
+#define ECC_45_BYTE6
+
+/*** Register Mask and bit definitions */
+
+/* NFC_FLASH_CMD1 Field */
+#define CMD_BYTE2_MASK 0xFF00
+#define CMD_BYTE2_SHIFT24
+
+/* NFC_FLASH_CM2 Field */
+#define CMD_BYTE1_MASK 0xFF00
+#define CMD_BYTE1_SHIFT24
+#define CMD_CODE_MASK  0x0000
+#define CMD_CODE_SHIFT 8
+#define BUFNO_MASK 0x0006
+#define BUFNO_SHIFT1
+#define START_BIT  (1<<0)
+
+/* NFC_COL_ADDR Field */
+#define COL_ADDR_MASK  0x
+#define COL_ADDR_SHIFT 0
+
+/* NFC_ROW_ADDR Field */
+#define ROW_ADDR_MASK  0x00FF
+#define ROW_ADDR_SHIFT 0
+#define ROW_ADDR_CHIP_SEL_RB_MASK  0xF000
+#define ROW_ADDR_CHIP_SEL_RB_SHIFT 28
+#define ROW_ADDR_CHIP_SEL_MASK 0x0F00
+#define ROW_ADDR_CHIP_SEL_SHIFT24
+
+/* NFC_FLASH_STATUS2 Field */
+#define STATUS_BYTE1_MASK  0x00FF
+
+/* NFC_FLASH_CONFIG Field */
+#define CONFIG_ECC_SRAM_ADDR_MASK  0x7FC0
+#define CONFIG_ECC_SRAM_ADDR_SHIFT 22
+#define CONFIG_ECC_SRAM_REQ_BIT(1<<21)
+#define CONFIG_DMA_REQ_BIT (1<<20)
+#define CONF

[U-Boot] uboot halts when stdio configured for netconsole and network cable disconnected

2014-08-14 Thread Les Loveridge (INT)
Hi,

I found an old reference 
(http://lists.denx.de/pipermail/u-boot/2012-January/114850.html) to a problem 
that I am currently experiencing when configuring my target for netconsole 
startup.

Everything works fine when the network cable is connected, boot count expires 
and the kernel is loaded, but when the network cable is disconnected uboot 
halts and boot count does not expire.

As soon as the network cable is re-connected then the boot count counts down 
and expires and the kernel is loaded.

For my application I want the system to boot and load the kernel regardless of 
whether the network cable is connected or not.

I was wondering whether a patch was ever produced to address this behaviour?

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


Re: [U-Boot] [PATCH v4 04/18] net: mdio: Add private MDIO read/write function

2014-08-14 Thread York Sun
On 08/13/2014 11:44 PM, Alison Wang wrote:
> As extra FPGA settings is needed for MDIO read/write
> on LS1021AQDS, private MDIO read/write functions are
> created.
> 
> Signed-off-by: Alison Wang 
> ---
> Change log:
>  v4: No change.
>  v3: Split from the 0004-arm-ls102xa-Add-etsec-support-for-LS102xA patch.
>  v2: Add private mdio read and write support. 
> 
>  drivers/net/fsl_mdio.c | 9 +++--
>  include/fsl_mdio.h | 4 
>  2 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/fsl_mdio.c b/drivers/net/fsl_mdio.c
> index 8d09f5d..6eae78f 100644
> --- a/drivers/net/fsl_mdio.c
> +++ b/drivers/net/fsl_mdio.c
> @@ -98,8 +98,13 @@ int fsl_pq_mdio_init(bd_t *bis, struct fsl_pq_mdio_info 
> *info)
>   return -1;
>   }
>  
> - bus->read = tsec_phy_read;
> - bus->write = tsec_phy_write;
> + if (info->priv_mdio_read) {
> + bus->read = info->priv_mdio_read;
> + bus->write = info->priv_mdio_write;
> + } else {
> + bus->read = tsec_phy_read;
> + bus->write = tsec_phy_write;
> + }
>   bus->reset = fsl_pq_mdio_reset;
>   sprintf(bus->name, info->name);
>  
> diff --git a/include/fsl_mdio.h b/include/fsl_mdio.h
> index a531edf..633123c 100644
> --- a/include/fsl_mdio.h
> +++ b/include/fsl_mdio.h
> @@ -57,6 +57,10 @@ int memac_mdio_read(struct mii_dev *bus, int port_addr, 
> int dev_addr,
>  struct fsl_pq_mdio_info {
>   struct tsec_mii_mng __iomem *regs;
>   char *name;
> + int (*priv_mdio_read)(struct mii_dev *bus, int addr,
> +   int devad, int reg);
> + int (*priv_mdio_write)(struct mii_dev *bus, int addr, int devad,
> +int reg, u16 val);
>  };
>  int fsl_pq_mdio_init(bd_t *bis, struct fsl_pq_mdio_info *info);
>  
> 

Alison,

Please check if Shaohui's comment on your v3 patch is valid. He suggested you
don't need to add a new private functions.

York

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


Re: [U-Boot] [PATCH v4 02/18] ls102xa: i2c: Add i2c support for LS102xA

2014-08-14 Thread York Sun
On 08/13/2014 11:44 PM, Alison Wang wrote:
> This patch is to add I2C 1,2,3 support for LS102xA.
> 

I think the commit message should say which existing I2C driver is compatible
with the controller of LS201x. From the change, you are using the same driver
for i.MX. But it is not clear if you are using the 8-bit driver or the 32-bit
driver. I can tell from your patch 01/18 that you enabled I2C_QUIRK_REG to use
8-bit driver. This should go into the commit message to help other follow the
suit if another SoC is added the same way.

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


Re: [U-Boot] [PATCH v4 16/18] video: dcu: Add Sii9022A HDMI Transmitter support

2014-08-14 Thread York Sun
On 08/13/2014 11:45 PM, Alison Wang wrote:
> On LS1021ATWR, Silicon's Sii9022A HDMI Transmitter
> is used. This patch adds the common setting for this
> chip.
> 
> Signed-off-by: Alison Wang 
> ---
> Change log:
>  v4: Add commit messages.
>  v3: New file.
> 
>  board/freescale/common/Makefile   |   2 +
>  board/freescale/common/dcu_sii9022a.c | 153 
> ++
>  board/freescale/common/dcu_sii9022a.h |  13 +++
>  3 files changed, 168 insertions(+)
>  create mode 100644 board/freescale/common/dcu_sii9022a.c
>  create mode 100644 board/freescale/common/dcu_sii9022a.h

Shouldn't this driver stay under driver/video? It is for the HDMI transmitter,
not Freescale board specific, is it?

> 
> diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile
> index 22b57cc..808ddd0 100644
> --- a/board/freescale/common/Makefile
> +++ b/board/freescale/common/Makefile
> @@ -34,6 +34,8 @@ ifndef CONFIG_RAMBOOT_PBL
>  obj-$(CONFIG_FSL_FIXED_MMC_LOCATION) += sdhc_boot.o
>  endif
>  
> +obj-$(CONFIG_FSL_DCU_SII9022A)+= dcu_sii9022a.o
> +
>  obj-$(CONFIG_MPC8541CDS) += cds_pci_ft.o
>  obj-$(CONFIG_MPC8548CDS) += cds_pci_ft.o
>  obj-$(CONFIG_MPC8555CDS) += cds_pci_ft.o
> diff --git a/board/freescale/common/dcu_sii9022a.c 
> b/board/freescale/common/dcu_sii9022a.c
> new file mode 100644
> index 000..2da627e
> --- /dev/null
> +++ b/board/freescale/common/dcu_sii9022a.c
> @@ -0,0 +1,153 @@
> +/*
> + * Copyright 2014 Freescale Semiconductor, Inc.
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
>
I think you put the patches in wrong order. DCU driver has not been added before
this patch.

York

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


Re: [U-Boot] [PATCH v4 15/18] arm: ls102xa: Add LETECH support for LS1021AQDS/TWR board

2014-08-14 Thread York Sun
On 08/13/2014 11:45 PM, Alison Wang wrote:
> From: Wang Huan 
> 
> This patch is to add LETECH support for LS1021AQDS/TWR board.
> For LETECH, lpuart is used as console.
> 
> Signed-off-by: Jason Jin 
> Signed-off-by: Yuan Yao 
> Signed-off-by: Alison Wang 
> ---
> Change log:
>  v4: No change.
>  v3: New file.
> 
>  board/freescale/ls1021aqds/MAINTAINERS |  1 +
>  board/freescale/ls1021atwr/MAINTAINERS |  1 +
>  configs/ls1021aqds_letech_defconfig|  3 +++
>  configs/ls1021atwr_letech_defconfig|  3 +++
>  include/configs/ls1021aqds.h   | 13 +
>  include/configs/ls1021atwr.h   | 12 
>  6 files changed, 33 insertions(+)
>  create mode 100644 configs/ls1021aqds_letech_defconfig
>  create mode 100644 configs/ls1021atwr_letech_defconfig

I suggest you update README to add some information about this LETECH. I have no
idea what it is until I dig into some internal documents.

York

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


Re: [U-Boot] [PATCH v2 3/4] mtd: nand: add Freescale NFC driver

2014-08-14 Thread Bill Pringlemeir
On 14 Aug 2014, ste...@agner.ch wrote:

> This adds initial support for Freescale NFC (NAND Flash Controller)
> found in ARM Vybrid SoC's, Power Architecture MPC5125 and others.
> However, this driver is only tested on Vybrid.
> 
> Signed-off-by: Stefan Agner 
> ---
>  drivers/mtd/nand/Makefile|   1 +
>  drivers/mtd/nand/vf610_nfc.c | 706
> ++> +
>  2 files changed, 707 insertions(+)
>  create mode 100644 drivers/mtd/nand/vf610_nfc.c
> 
> diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
> new file mode 100644
> index 000..3150ac1
> --- /dev/null
> +++ b/drivers/mtd/nand/vf610_nfc.c
> @@ -0,0 +1,706 @@
> +/*
> + * Copyright 2009-2014 Freescale Semiconductor, Inc. and others
> + *

[snip]

> +/* Count the number of 0's in buff upto max_bits */
> +static inline int count_written_bits(uint8_t *buff, int size, int max_bits)
> +{
> + uint32_t *buff32 = (uint32_t *)buff;
> + int k, written_bits = 0;
> +
> + for (k = 0; k < (size / 4); k++) {
> + written_bits += hweight32(~buff32[k]);
> + if (written_bits > max_bits)
> + break;
> + }
> +
> + return written_bits;
> +}
 
That is a nice change. 
 
> +static inline int vf610_nfc_correct_data(struct mtd_info *mtd, u_char *dat)
> +{
> + struct vf610_nfc *nfc = mtd_to_nfc(mtd);
> + u8 ecc_status;
> + u8 ecc_count;
> + int flip;
> +
> + ecc_status = __raw_readb(nfc->regs + ECC_SRAM_ADDR * 8 + ECC_OFFSET);
> + ecc_count = ecc_status & ECC_ERR_COUNT;
> + if (!(ecc_status & ECC_STATUS_MASK))
> + return ecc_count;
> +
> + /* If 'ecc_count' zero or less then buffer is all 0xff or erased. */
> + flip = count_written_bits(dat, nfc->chip.ecc.size, ecc_count);
> +
> + /* ECC failed. */
> + if (flip > ecc_count)
> + return -1;

Sorry, I missed this in version one of the patch.  The original had,

<   if (flip > ecc_count) {
<   nfc->page = -1;
---
>   if (flip > ecc_count)
522d508
<   }

I can see why you removed this (nfc->page = -1).  However, I think that
higher layers may want to re-read on an error in case of un-stable bits?
It is very little code to ensure a re-read in case of ECC failure.  The
2nd physical read may pass whereas the first failed.  This path is rare,
but maybe important?  A higher layer may migrate the data in this case;
just as with a corrected bits.  But maybe U-Boot will never do this?

> +
> + /* Erased page. */
> + memset(dat, 0xff, nfc->chip.ecc.size);
> + return 0;
> +}

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


Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings

2014-08-14 Thread Robert Nelson
On Thu, Aug 14, 2014 at 10:49 AM, Stephen Warren  wrote:
> On 08/14/2014 02:25 AM, Alexander Holler wrote:
>>
>> Am 31.07.2014 21:57, schrieb Stephen Warren:
>>
>>> Huh, I do see that now. I must have been looking at the content of
>>> common/cmd_nvedit.c from the wrong branch, which didn't include that
>>> patch. I could have sworn I checked git history too, but evidently not.
>>> It is indeed clearly there right before the patches which use it. Sorry
>>> for the noise.
>>
>>
>> As I've just remembered where I did see your name before, the config for
>> the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to
>> execute commands when using uEnv.txt.
>>
>> It's easily done with something like the following:
>>
>> "env import -t -r $loadaddr $filesize;" \
>> "if test -n \"$uenvcmd\"; then " \
>> "echo \"Running uenvcmd ...\";" \
>> "run uenvcmd;" \
>> "fi;" \
>
>
> My intention was that uEnv.txt be used to set up environment variables, not
> to allow its use for custom scripts.

The check for if uenvcmd is set then run uenvcmd syntax, should really
be pushed into the distro default stuff.  As that syntax is used by
default for a lot of different targets in u-boot.  Most users who deal
with u-boot (even if they don't want to) seem to understand it.

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/4] cmd_bootm.c: Add 'booti' for ARM64 Linux kernel Images

2014-08-14 Thread Tom Rini
On Thu, Aug 14, 2014 at 04:16:50PM +0100, Mark Rutland wrote:
> Hi Tom,
> 
> On Thu, Aug 14, 2014 at 11:42:36AM +0100, Tom Rini wrote:
> > The default format for arm64 Linux kernels is the "Image" format,
> > described in Documentation/arm64/booting.txt.  This, along with an
> > optional gzip compression on top is all that is generated by default.
> > The Image format has a magic number within the header for verification,
> > a text_offset where the Image must be run from, an image_size that
> > includes the BSS and reserved fields.
> > 
> > This does not support automatic detection of a gzip compressed image.
> > 
> > Signed-off-by: Tom Rini 
> > 
> > ---
> > Changes in v1:
> > - Adopt to Mark Rutland's changes now in mainline kernel wrt text_offset
> >   / image_size
> > ---
> >  README |1 +
> >  common/cmd_bootm.c |  140 
> > 
> >  include/bootm.h|2 +-
> >  3 files changed, 142 insertions(+), 1 deletion(-)
> > 
> > diff --git a/README b/README
> > index 1d71359..b9af7ac 100644
> > --- a/README
> > +++ b/README
> > @@ -959,6 +959,7 @@ The following options need to be configured:
> > CONFIG_CMD_BMP  * BMP support
> > CONFIG_CMD_BSP  * Board specific commands
> > CONFIG_CMD_BOOTD  bootd
> > +   CONFIG_CMD_BOOTI* ARM64 Linux kernel Image support
> > CONFIG_CMD_CACHE* icache, dcache
> > CONFIG_CMD_CLK  * clock command support
> > CONFIG_CMD_CONSOLEconinfo
> > diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
> > index 8b897c8d..843ec6e 100644
> > --- a/common/cmd_bootm.c
> > +++ b/common/cmd_bootm.c
> > @@ -627,3 +627,143 @@ U_BOOT_CMD(
> > "boot Linux zImage image from memory", bootz_help_text
> >  );
> >  #endif /* CONFIG_CMD_BOOTZ */
> > +
> > +#ifdef CONFIG_CMD_BOOTI
> > +/* See Documentation/arm64/booting.txt in the Linux kernel */
> > +struct Image_header {
> > +   uint32_tcode0;  /* Executable code */
> > +   uint32_tcode1;  /* Executable code */
> > +   uint64_ttext_offset;/* Image load offset, LE */
> > +   uint64_timage_size; /* Effective Image size, LE */
> > +   uint64_tres1;   /* reserved */
> > +   uint64_tres2;   /* reserved */
> > +   uint64_tres3;   /* reserved */
> > +   uint64_tres4;   /* reserved */
> > +   uint32_tmagic;  /* Magic number */
> > +   uint32_tres5;
> > +};
> > +
> > +#define LINUX_ARM64_IMAGE_MAGIC0x644d5241
> > +
> > +static int booti_setup(bootm_headers_t *images)
> > +{
> > +   struct Image_header *ih;
> > +   uint64_t dst;
> > +
> > +   ih = (struct Image_header *)map_sysmem(images->ep, 0);
> > +
> > +   if (ih->magic != le32_to_cpu(LINUX_ARM64_IMAGE_MAGIC)) {
> > +   puts("Bad Linux ARM64 Image magic!\n");
> > +   return 1;
> > +   }
> > +   
> > +   if (ih->image_size == 0) {
> > +   puts("Image lacks image_size field, assuming 16MiB\n");
> > +   ih->image_size = (16 << 20);
> > +   }
> 
> This should work for a defconfig, but it might be possible to build a
> larger kernel. From experiments with an allyesconfig, I can build a
> ~60MB kernel with ~20MB of uninitialised data after the end of the
> Image.

Part of me just wants to error out in this case.  Today people are
wrapping vmlinux up with a legacy header and making uImages.  My hope is
that with this and 3.17 we can encourage Image/Image.*/FIT Image usage
instead.  We could just as easily whack in 128MB, all the same.

> Modifying the Image feels a little dodgy, but I can't think of anything
> this would break.

Yeah.  In my mind, an Image without this information is the corner case,
not the normal case.  Doing it this way (a fixup to the data) means we
don't have to error check this twice or play some other games.

> > +   /*
> > +* If we are not at the correct run-time location, set the new
> > +* correct location and then move the image there.
> > +*/
> > +   dst = gd->bd->bi_dram[0].start + le32_to_cpu(ih->text_offset);
> 
> This should be le64_to_cpu(ih->text_offset) to be strictly correct.
> 
> I wouldn't imagine we'd ever have a text_offset larger than 4GB, but it
> would be nice to keep things consistent with the documentation and
> kernel code.

Oh that's right, sixty-four bits is what we have...

> > +#ifdef CONFIG_SYS_LONGHELP
> > +static char booti_help_text[] =
> > +   "[addr [initrd[:size]] [fdt]]\n"
> > +   "- boot Linux Image stored in memory\n"
> > +   "\tThe argument 'initrd' is optional and specifies the address\n"
> > +   "\tof the initrd in memory. The optional argument ':size' allows\n"
> > +   "\tspecifying the size of RAW initrd.\n"
> > +#if defined(CONFIG_OF_LIBFDT)
> > +   "\tSince booting a Linux kernelrequires a flat device-tree\n"
> 
> Nit: space between "kernel" and "requ

Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings

2014-08-14 Thread Tom Rini
On Thu, Aug 14, 2014 at 01:41:16PM -0500, Robert Nelson wrote:
> On Thu, Aug 14, 2014 at 10:49 AM, Stephen Warren  
> wrote:
> > On 08/14/2014 02:25 AM, Alexander Holler wrote:
> >>
> >> Am 31.07.2014 21:57, schrieb Stephen Warren:
> >>
> >>> Huh, I do see that now. I must have been looking at the content of
> >>> common/cmd_nvedit.c from the wrong branch, which didn't include that
> >>> patch. I could have sworn I checked git history too, but evidently not.
> >>> It is indeed clearly there right before the patches which use it. Sorry
> >>> for the noise.
> >>
> >>
> >> As I've just remembered where I did see your name before, the config for
> >> the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to
> >> execute commands when using uEnv.txt.
> >>
> >> It's easily done with something like the following:
> >>
> >> "env import -t -r $loadaddr $filesize;" \
> >> "if test -n \"$uenvcmd\"; then " \
> >> "echo \"Running uenvcmd ...\";" \
> >> "run uenvcmd;" \
> >> "fi;" \
> >
> >
> > My intention was that uEnv.txt be used to set up environment variables, not
> > to allow its use for custom scripts.
> 
> The check for if uenvcmd is set then run uenvcmd syntax, should really
> be pushed into the distro default stuff.  As that syntax is used by
> default for a lot of different targets in u-boot.  Most users who deal
> with u-boot (even if they don't want to) seem to understand it.

Right.  The intention was to provide a "just do what I want you to do"
hook to the end user.

-- 
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 1/4] Add option -r to env import to allow import of text files with CRLF as line endings

2014-08-14 Thread Alexander Holler

Am 14.08.2014 17:49, schrieb Stephen Warren:

On 08/14/2014 02:25 AM, Alexander Holler wrote:



As I've just remembered where I did see your name before, the config for
the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to
execute commands when using uEnv.txt.

It's easily done with something like the following:

"env import -t -r $loadaddr $filesize;" \
"if test -n \"$uenvcmd\"; then " \
"echo \"Running uenvcmd ...\";" \
"run uenvcmd;" \
"fi;" \


My intention was that uEnv.txt be used to set up environment variables,
not to allow its use for custom scripts.



Sure. In most cases changing the predefined available variables is 
enough. But it's a very hand option if someone wants or needs to do 
stuff which can't be done by just changing some environment variables 
(one never knows what ideas people will have).


And as it now seems to be possible to write the environment back to disk 
too, one should be make sure that uenvcmd will be cleared before writing 
the environment back to disk. Personally I prefer to not let the 
bootloader write to any (real) filesystem, but just in case someone does 
so ...


Regards,

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


Re: [U-Boot] [PATCH v2 3/4] mtd: nand: add Freescale NFC driver

2014-08-14 Thread Scott Wood
On Thu, 2014-08-14 at 18:30 +0200, Stefan Agner wrote:
> +#define  DRV_NAME"fsl_nfc"

DRV_NAME doesn't match filename (neither does the patch title), and it
doesn't seem all that useful anyway -- the one place that uses it would
be better off using __func__.

> +static int vf610_nfc_nand_init(int devnum, u8 *addr)

Why u8?  Either use void or u32.  Also should have __iomem.

...OK, I see you copied that from the examples I pointed out.  I have no
idea why those use u8 either. :-(

> + chip->IO_ADDR_R = chip->IO_ADDR_W = nfc->regs = (void __iomem *)addr;

Don't set IO_ADDR_R/IO_ADDR_W if they're not going to be used.

-Scott


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


Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings

2014-08-14 Thread Stephen Warren

On 08/14/2014 12:41 PM, Robert Nelson wrote:

On Thu, Aug 14, 2014 at 10:49 AM, Stephen Warren  wrote:

On 08/14/2014 02:25 AM, Alexander Holler wrote:


Am 31.07.2014 21:57, schrieb Stephen Warren:


Huh, I do see that now. I must have been looking at the content of
common/cmd_nvedit.c from the wrong branch, which didn't include that
patch. I could have sworn I checked git history too, but evidently not.
It is indeed clearly there right before the patches which use it. Sorry
for the noise.



As I've just remembered where I did see your name before, the config for
the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to
execute commands when using uEnv.txt.

It's easily done with something like the following:

 "env import -t -r $loadaddr $filesize;" \
 "if test -n \"$uenvcmd\"; then " \
 "echo \"Running uenvcmd ...\";" \
 "run uenvcmd;" \
 "fi;" \



My intention was that uEnv.txt be used to set up environment variables, not
to allow its use for custom scripts.


The check for if uenvcmd is set then run uenvcmd syntax, should really
be pushed into the distro default stuff.  As that syntax is used by
default for a lot of different targets in u-boot.  Most users who deal
with u-boot (even if they don't want to) seem to understand it.


I don't think this is anything to do with distro defaults.

Distro defaults are intended to provide a single common interface 
between the bootloader and Linux/... distro. As such, locating and 
loading extlinux.conf fits the bill there. The whole idea is that 
distros/OSs wouldn't have to know anything about the bootloader at all; 
command script formats, etc.


uenv.txt is the opposite; it's very U-Boot specific, and more about 
internal implementation details of U-Boot. In particular, I only see a 
use-case for uenv.txt on systems that have nowhere to store the U-Boot 
environment other than in some filesystem. That's the reason the RPi 
port loads uenv.txt, so the environment can be modified somehow. Perhaps 
there's an ENV_IS_IN_FAT that could be used instead on the Pi? For 
example, none of the Tegra boards use uEnv.txt since "saveenv" to flash 
works there.


So, perhaps I could see providing include/common_bootenv.h to make the 
definition you wrote above common between boards, but I certainly would 
not expect that opting in to distro defaults automatically added support 
for uEnv.txt.

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


Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings

2014-08-14 Thread Stephen Warren

On 08/14/2014 01:38 PM, Alexander Holler wrote:

Am 14.08.2014 17:49, schrieb Stephen Warren:

On 08/14/2014 02:25 AM, Alexander Holler wrote:



As I've just remembered where I did see your name before, the config for
the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to
execute commands when using uEnv.txt.

It's easily done with something like the following:

"env import -t -r $loadaddr
$filesize;" \
"if test -n \"$uenvcmd\"; then " \
"echo \"Running uenvcmd
...\";" \
"run uenvcmd;" \
"fi;" \


My intention was that uEnv.txt be used to set up environment variables,
not to allow its use for custom scripts.



Sure. In most cases changing the predefined available variables is
enough. But it's a very hand option if someone wants or needs to do
stuff which can't be done by just changing some environment variables
(one never knows what ideas people will have).


For such presumably non-standard things, why can't the user simply edit 
$bootcmd, and pre-pend whatever they want?

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


Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings

2014-08-14 Thread Alexander Holler

Am 14.08.2014 21:51, schrieb Stephen Warren:

On 08/14/2014 01:38 PM, Alexander Holler wrote:

Am 14.08.2014 17:49, schrieb Stephen Warren:

On 08/14/2014 02:25 AM, Alexander Holler wrote:



As I've just remembered where I did see your name before, the config
for
the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to
execute commands when using uEnv.txt.

It's easily done with something like the following:

"env import -t -r $loadaddr
$filesize;" \
"if test -n \"$uenvcmd\"; then " \
"echo \"Running uenvcmd
...\";" \
"run uenvcmd;" \
"fi;" \


My intention was that uEnv.txt be used to set up environment variables,
not to allow its use for custom scripts.



Sure. In most cases changing the predefined available variables is
enough. But it's a very hand option if someone wants or needs to do
stuff which can't be done by just changing some environment variables
(one never knows what ideas people will have).


For such presumably non-standard things, why can't the user simply edit
$bootcmd, and pre-pend whatever they want?


Depends on when the bootcmd will be constructed. Usually that is done 
after having read uEnv.txt to include variables defined in uEnv.txt in 
bootcmd. So whatever bootcmd one sets in uEnv.txt, it just will be 
overwritten.


Regards,

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


Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings

2014-08-14 Thread Stephen Warren

On 08/14/2014 01:59 PM, Alexander Holler wrote:

Am 14.08.2014 21:51, schrieb Stephen Warren:

On 08/14/2014 01:38 PM, Alexander Holler wrote:

Am 14.08.2014 17:49, schrieb Stephen Warren:

On 08/14/2014 02:25 AM, Alexander Holler wrote:



As I've just remembered where I did see your name before, the config
for
the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to
execute commands when using uEnv.txt.

It's easily done with something like the following:

"env import -t -r $loadaddr
$filesize;" \
"if test -n \"$uenvcmd\"; then " \
"echo \"Running uenvcmd
...\";" \
"run uenvcmd;" \
"fi;" \


My intention was that uEnv.txt be used to set up environment variables,
not to allow its use for custom scripts.



Sure. In most cases changing the predefined available variables is
enough. But it's a very hand option if someone wants or needs to do
stuff which can't be done by just changing some environment variables
(one never knows what ideas people will have).


For such presumably non-standard things, why can't the user simply edit
$bootcmd, and pre-pend whatever they want?


Depends on when the bootcmd will be constructed. Usually that is done
after having read uEnv.txt to include variables defined in uEnv.txt in
bootcmd. So whatever bootcmd one sets in uEnv.txt, it just will be
overwritten.


What would over-write bootcmd? None of the boards I've looked at 
auto-generates bootcmd. bootargs perhaps (which is a string passed to 
the kernel) but not bootargs (which is a U-Boot command sequence that 
U-Boot executes automatically at boot).


If some board does auto-generate bootcmd, I'd suggest that it not. The 
static bootcmd could execute some kind of user-(or uenv-)set variable 
and/or the auto-generation of bootcmd could happen before uenv.txt was 
pulled in, so that whatever was in uenv.txt would have ultimate "power".

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


[U-Boot] Magically determining the correct root

2014-08-14 Thread Alexander Holler

Hello,

Over the years I've seen many error message from beginners because root= 
wasn't set or was set wrong. Often they call the cryptic message from 
the Linux kernel memory error or something similiar (because they just 
look at the stuff after the "init not found").


One of the reason they run into that is because they use a different 
partition layout than which is enforced by the board-config.


So here are my 2¢ to give people some more freedom in regard to the 
partition layout:


-
...
   "find_root=" \
   "setenv stdout nulldev;" \
   "for i in 0 1 2; do " \
   "setexpr rootpart $part + $i;" \
   "if ls $hw $dev:$rootpart dev; then " \
   "setenv stderr serial;" \
   "setenv stdout serial;" \
   "exit;" \
   "fi;" \
   "done;" \
   "setenv stdout serial;" \
   "setenv rootpart\0" \
   "linuxmmc=mmcblk0p\0" \
   "set_root=" \
   "run find_root;" \
   "if test -z \"$rootpart\"; then " \
   "echo \"NO ROOT FOUND! (no partition with 
directory /dev)\";" \

   "setexpr rootpart $part + 1;" \
   "fi;" \
   "if test $hw = mmc; then " \
   "setenv root /dev/${linuxmmc}${rootpart};" \
"else " \
   "setenv root /dev/sda${rootpart};" \
   "fi;" \
   "echo \"root is $root\"\0" \
...
-

What it does is the following:

It uses the variable $hw, $dev, $part and $linuxmmc as input and
$root as output.

- $hw might be mmc, usb or sata (or whatever "ls" does understand
- $dev is the device number (usually 0)
- $part is the partition number where the kernel is loaded from (most of 
the time 1 for the first partition)

- $linuxmmc is the linux-name of the mmc-device (e.g. mmcblk0p).

It then searches the partition from which the kernel was loaded from and 
the following two partitions for a "/dev" and assumes that will be the 
correct root partition.


So, assuming /dev does only exist on the root partition that little 
magic supports parition layouts like the following:


- boot (with kernel), root, something else
- root (with kernel), something else
- swap, boot (with kernel), root, something else
- boot (with kernel), swap, root, something else
...

Maybe someone does find usefull.

Regards,

Alexander Holler

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


Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings

2014-08-14 Thread Alexander Holler

Am 14.08.2014 22:08, schrieb Stephen Warren:

On 08/14/2014 01:59 PM, Alexander Holler wrote:

Am 14.08.2014 21:51, schrieb Stephen Warren:

On 08/14/2014 01:38 PM, Alexander Holler wrote:

Am 14.08.2014 17:49, schrieb Stephen Warren:

On 08/14/2014 02:25 AM, Alexander Holler wrote:



As I've just remembered where I did see your name before, the config
for
the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to
execute commands when using uEnv.txt.

It's easily done with something like the following:

"env import -t -r $loadaddr
$filesize;" \
"if test -n \"$uenvcmd\"; then " \
"echo \"Running uenvcmd
...\";" \
"run uenvcmd;" \
"fi;" \


My intention was that uEnv.txt be used to set up environment
variables,
not to allow its use for custom scripts.



Sure. In most cases changing the predefined available variables is
enough. But it's a very hand option if someone wants or needs to do
stuff which can't be done by just changing some environment variables
(one never knows what ideas people will have).


For such presumably non-standard things, why can't the user simply edit
$bootcmd, and pre-pend whatever they want?


Depends on when the bootcmd will be constructed. Usually that is done
after having read uEnv.txt to include variables defined in uEnv.txt in
bootcmd. So whatever bootcmd one sets in uEnv.txt, it just will be
overwritten.


What would over-write bootcmd? None of the boards I've looked at
auto-generates bootcmd. bootargs perhaps (which is a string passed to
the kernel) but not bootargs (which is a U-Boot command sequence that
U-Boot executes automatically at boot).

If some board does auto-generate bootcmd, I'd suggest that it not. The
static bootcmd could execute some kind of user-(or uenv-)set variable
and/or the auto-generation of bootcmd could happen before uenv.txt was
pulled in, so that whatever was in uenv.txt would have ultimate "power".


Ah, yes. Sorry, I confused bootcmd with bootargs (I don't live in u-boot 
and just fiddle once a year or such with it).


But overwriting bootcmd needs to read uEnv.txt in PREBOOT (or how it is 
named). I originally have read uEnv.txt in the bootcmd itself, so 
overwriting it didn't work. But I don't want to dive too deep into that 
discussion, as I think it's up to the board-maintainers to write the 
config however they want and seem to fit for there users. I've just 
mentioned the uenvcmd, because it was the first, I've added to my u-boot 
for the rpi (to have the same interface I use with my other boards). ;)


Regards,

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


Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings

2014-08-14 Thread Tom Rini
On Thu, Aug 14, 2014 at 01:50:31PM -0600, Stephen Warren wrote:

[snip]
> uenv.txt is the opposite; it's very U-Boot specific, and more about
> internal implementation details of U-Boot. In particular, I only see
> a use-case for uenv.txt on systems that have nowhere to store the
> U-Boot environment other than in some filesystem. That's the reason
> the RPi port loads uenv.txt, so the environment can be modified
> somehow. Perhaps there's an ENV_IS_IN_FAT that could be used instead
> on the Pi? For example, none of the Tegra boards use uEnv.txt since
> "saveenv" to flash works there.

Even with ENV_IS_IN_FAT you need to be in U-Boot to modify the
environment (fw_setenv/printenv should be adaptable easily enough I
would hope, but aren't today).  uEnv.txt is the way for a user to pop
the SD card into their PC, tweak the env as needed (or fiddle some
bits), eject the card and boot their target.

-- 
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 1/4] Add option -r to env import to allow import of text files with CRLF as line endings

2014-08-14 Thread Alexander Holler

Am 14.08.2014 22:53, schrieb Tom Rini:

On Thu, Aug 14, 2014 at 01:50:31PM -0600, Stephen Warren wrote:

[snip]

uenv.txt is the opposite; it's very U-Boot specific, and more about
internal implementation details of U-Boot. In particular, I only see
a use-case for uenv.txt on systems that have nowhere to store the
U-Boot environment other than in some filesystem. That's the reason
the RPi port loads uenv.txt, so the environment can be modified
somehow. Perhaps there's an ENV_IS_IN_FAT that could be used instead
on the Pi? For example, none of the Tegra boards use uEnv.txt since
"saveenv" to flash works there.


Even with ENV_IS_IN_FAT you need to be in U-Boot to modify the
environment (fw_setenv/printenv should be adaptable easily enough I
would hope, but aren't today).  uEnv.txt is the way for a user to pop
the SD card into their PC, tweak the env as needed (or fiddle some
bits), eject the card and boot their target.


Yes, many "developers" today (those which do buy development boards) are 
having problems to use a serial which most of the time is needed to 
access the u-boot command line. The reasons are various, most devices 
people do use don't have a serial anymore, the voltage of the serial 
changes every few years (12, 5, 3.3 and now 1.8 Volt), sometimes a 
nullmodem (just 3 wires) is needed, ...


Whatever the reason is, sometimes it can be very hard to access the 
u-boot command line. But most are able to modifying or create a file on 
disk. ;)


Regards,

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


Re: [U-Boot] [PATCH] vf610twr: Tune DDR initialization settings

2014-08-14 Thread Stefan Agner
Am 2014-07-22 00:42, schrieb Stefan Agner:
> Am 2014-05-14 23:29, schrieb Anthony Felice:
>> Removed settings in unsupported register fields. They didn’t
>> do anything, and in most cases, were not documented in the
>> reference manual.
>>
>> Changed register settings to comply with JEDEC required values.
>>
>> Changed timing parameters because they included full clock
>> periods that were doing nothing.
>>
>> Signed-off-by: Anthony Felice 
>> ---
>>  arch/arm/include/asm/arch-vf610/imx-regs.h| 50 +++---
>>  arch/arm/include/asm/arch-vf610/iomux-vf610.h | 44 +++--
>>  arch/arm/include/asm/imx-common/iomux-v3.h|  2 +
>>  board/freescale/vf610twr/vf610twr.c   | 93 
>> +--
>>  4 files changed, 128 insertions(+), 61 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/arch-vf610/imx-regs.h
>> b/arch/arm/include/asm/arch-vf610/imx-regs.h
>> index c2f9761..a11b419 100644
>> --- a/arch/arm/include/asm/arch-vf610/imx-regs.h
>> +++ b/arch/arm/include/asm/arch-vf610/imx-regs.h
>> @@ -100,9 +100,11 @@
>>  /* DDRMC */
>>  #define DDRMC_PHY_DQ_TIMING 0x2613
>>  #define DDRMC_PHY_DQS_TIMING0x2615
>> -#define DDRMC_PHY_CTRL  0x01210080
>> +#define DDRMC_PHY_CTRL  0x0021
>>  #define DDRMC_PHY_MASTER_CTRL   0x0001012a
>> -#define DDRMC_PHY_SLAVE_CTRL0x00012020
>> +#define DDRMC_PHY_SLAVE_CTRL0x2000
>> +#define DDRMC_PHY_OFF   0x
>> +#define DDRMC_PHY_PROC_PAD_ODT  0x00010101
>>
>>  #define DDRMC_PHY50_DDR3_MODE   (1 << 12)
>>  #define DDRMC_PHY50_EN_SW_HALF_CYCLE(1 << 8)
>> @@ -135,7 +137,7 @@
>>  #define DDRMC_CR21_CCMAP_EN 1
>>  #define DDRMC_CR22_TDAL(v)  (((v) & 0x3f) << 16)
>>  #define DDRMC_CR23_BSTLEN(v)(((v) & 0x7) << 
>> 24)
>> -#define DDRMC_CR23_TDLL(v)  ((v) & 0xff)
>> +#define DDRMC_CR23_TDLL(v)  ((v) & 0x)
>>  #define DDRMC_CR24_TRP_AB(v)((v) & 0x1f)
>>  #define DDRMC_CR25_TREF_EN  (1 << 16)
>>  #define DDRMC_CR26_TREF(v)  (((v) & 0x) << 16)
>> @@ -148,7 +150,7 @@
>>  #define DDRMC_CR33_EN_QK_SREF   (1 << 16)
>>  #define DDRMC_CR34_CKSRX(v) (((v) & 0xf) << 16)
>>  #define DDRMC_CR34_CKSRE(v) (((v) & 0xf) << 8)
>> -#define DDRMC_CR38_FREQ_CHG_EN  (1 << 8)
>> +#define DDRMC_CR38_FREQ_CHG_EN(v)   (((v) & 0x1) << 8)
>>  #define DDRMC_CR39_PHY_INI_COM(v)   (((v) & 0x) << 16)
>>  #define DDRMC_CR39_PHY_INI_STA(v)   (((v) & 0xff) << 8)
>>  #define DDRMC_CR39_FRQ_CH_DLLOFF(v) ((v) & 0x3)
>> @@ -160,7 +162,7 @@
>>  #define DDRMC_CR67_ZQCS(v)  ((v) & 0xfff)
>>  #define DDRMC_CR69_ZQ_ON_SREF_EX(v) (((v) & 0xf) << 8)
>>  #define DDRMC_CR70_REF_PER_ZQ(v)(v)
>> -#define DDRMC_CR72_ZQCS_ROTATE  (1 << 24)
>> +#define DDRMC_CR72_ZQCS_ROTATE(v)   (((v) & 0x1) << 24)
>>  #define DDRMC_CR73_APREBIT(v)   (((v) & 0xf) << 
>> 24)
>>  #define DDRMC_CR73_COL_DIFF(v)  (((v) & 0x7) << 
>> 16)
>>  #define DDRMC_CR73_ROW_DIFF(v)  (((v) & 0x3) << 
>> 8)
>> @@ -179,9 +181,10 @@
>>  #define DDRMC_CR77_CS_MAP   (1 << 24)
>>  #define DDRMC_CR77_DI_RD_INTLEAVE   (1 << 8)
>>  #define DDRMC_CR77_SWAP_EN  1
>> +#define DDRMC_CR78_Q_FULLNESS(v)(((v) & 0x7) << 24)
>>  #define DDRMC_CR78_BUR_ON_FLY_BIT(v)((v) & 0xf)
>> -#define DDRMC_CR79_CTLUPD_AREF  (1 << 24)
>> -#define DDRMC_CR82_INT_MASK 0x1fff
>> +#define DDRMC_CR79_CTLUPD_AREF(v)   (((v) & 0x1) << 24)
>> +#define DDRMC_CR82_INT_MASK 0x1000
>>  #define DDRMC_CR87_ODT_WR_MAPCS0(1 << 24)
>>  #define DDRMC_CR87_ODT_RD_MAPCS0(1 << 16)
>>  #define DDRMC_CR88_TODTL_CMD(v) (((v) & 0x1f) 
>> << 16)
>> @@ -189,9 +192,17 @@
>>  #define DDRMC_CR91_R2W_SMCSDL(v)(((v) & 0x7) << 16)
>>  #define DDRMC_CR96_WLMRD(v) (((v) & 0x3f) << 8)
>>  #define DDRMC_CR96_WLDQSEN(v)   ((v) & 0x3f)
>> +#define DDRMC_CR97_WRLVL_EN (1 << 24)
>> +#define DDRMC_CR98_WRLVL_DL_0  

Re: [U-Boot] [PATCH v2 3/4] mtd: nand: add Freescale NFC driver

2014-08-14 Thread Bill Pringlemeir


> On 14 Aug 2014, ste...@agner.ch wrote:
> 
> This adds initial support for Freescale NFC (NAND Flash Controller)
> found in ARM Vybrid SoC's, Power Architecture MPC5125 and others.
> However, this driver is only tested on Vybrid.

This is only to expand on the nand controller register and SRAM use.

[snip]
 
> diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
> new file mode 100644
> index 000..3150ac1
> --- /dev/null
> +++ b/drivers/mtd/nand/vf610_nfc.c

[snip]

> +static inline u32 vf610_nfc_read(struct mtd_info *mtd, uint reg)
> +{
> + struct vf610_nfc *nfc = mtd_to_nfc(mtd);
> +
> + return readl(nfc->regs + reg);
> +}
> +
> +static inline void vf610_nfc_write(struct mtd_info *mtd, uint reg, u32 val)
> +{
> + struct vf610_nfc *nfc = mtd_to_nfc(mtd);
> +
> + writel(val, nfc->regs + reg);
> +}

Ok, we always use readl/writel.  This is fine, but a little slower and
bigger.  I may try a register cache if I resubmit to the Linux MTD as
per Scott's suggestion.  Especially, this version is good for an
incremental patch.

I think these are in 'arch/arm/include/asm/io.h' of U-Boot.

#define dmb()   __asm__ __volatile__ ("" : : : "memory")
#define __iormb()   dmb()
#define __iowmb()   dmb()

#define readl(c)({ u32 __v = __arch_getl(c); __iormb(); __v; })
#define writel(v,c) ({ u32 __v = v; __iowmb(); __arch_putl(__v,c); __v; })

Currently, these look like compiler barriers to me.  Fine so far.

> +
> +static inline void vf610_nfc_set(struct mtd_info *mtd, uint reg, u32 bits)
> +{
> + vf610_nfc_write(mtd, reg, vf610_nfc_read(mtd, reg) | bits);
> +}
> +
> +static inline void vf610_nfc_clear(struct mtd_info *mtd, uint reg, u32 bits)
> +{
> + vf610_nfc_write(mtd, reg, vf610_nfc_read(mtd, reg) & ~bits);
> +}
> +
> +static inline void vf610_nfc_set_field(struct mtd_info *mtd, u32 reg,
> +u32 mask, u32 shift, u32 val)
> +{
> + vf610_nfc_write(mtd, reg,
> + (vf610_nfc_read(mtd, reg) & (~mask)) | val << shift);
> +}
> +
> +/* Clear flags for upcoming command */
> +static inline void vf610_nfc_clear_status(struct mtd_info *mtd)
> +{
> + u32 tmp = vf610_nfc_read(mtd, NFC_IRQ_STATUS);
> + tmp |= CMD_DONE_CLEAR_BIT | IDLE_CLEAR_BIT;
> + vf610_nfc_write(mtd, NFC_IRQ_STATUS, tmp);
> +}
> +
> +/* Wait for complete operation */
> +static inline void vf610_nfc_done(struct mtd_info *mtd)
> +{
> + uint start;
> +
> + vf610_nfc_set(mtd, NFC_FLASH_CMD2, START_BIT);
> + barrier();

This barrier() is not needed then.  The  vf610_nfc_set() should have
done it twice already, plus everything is volatile.

[snip]

> +static inline void vf610_nfc_read_spare(struct mtd_info *mtd, void *buf,
> + int len)
> +{
> + struct vf610_nfc *nfc = mtd_to_nfc(mtd);
> +
> + len = min(mtd->oobsize, (uint)len);
> + if (len > 0)
> + memcpy(buf, nfc->regs + mtd->writesize, len);

Notice the 'memcpy(.. nfc->regs);'...

> +}
> +
> +/* Read data from NFC buffers */
> +static void vf610_nfc_read_buf(struct mtd_info *mtd, u_char *buf, int len)
> +{
> + struct vf610_nfc *nfc = mtd_to_nfc(mtd);
> + uint c = nfc->column;
> + uint l;
> +
> + /* Handle main area */
> + if (!nfc->spareonly) {
> +
> + l = min((uint)len, mtd->writesize - c);
> + nfc->column += l;
> +
> + if (!nfc->alt_buf)
> + memcpy(buf, nfc->regs + NFC_MAIN_AREA(0) + c, l);

Another 'memcpy(.. nfc->regs);'...

> + else
> + if (nfc->alt_buf & ALT_BUF_ID)
> + *buf = vf610_nfc_get_id(mtd, c);
> + else
> + *buf = vf610_nfc_get_status(mtd);
> +
> + buf += l;
> + len -= l;
> + }
> +
> + /* Handle spare area access */
> + if (len) {
> + nfc->column += len;
> + vf610_nfc_read_spare(mtd, buf, len);
> + }
> +}
> +
> +/* Write data to NFC buffers */
> +static void vf610_nfc_write_buf(struct mtd_info *mtd, const u_char *buf,
> + int len)
> +{
> + struct vf610_nfc *nfc = mtd_to_nfc(mtd);
> + uint c = nfc->column;
> + uint l;
> +
> + l = min((uint)len, mtd->writesize + mtd->oobsize - c);
> + nfc->column += l;
> + memcpy(nfc->regs + NFC_MAIN_AREA(0) + c, buf, l);

Another 'memcpy(.. nfc->regs);'...

[snip]

These memcpy's are the same 'bus' interface as the registers.  We should
be just as worried about this SRAM buffer memory as the memory mapped
registers, shouldn't we?  Is a barrier() before reading and a barrier()
after writing fine for U-Boot?  Personally, I think they are safe as
only the 'vf610_nfc_set(mtd, NFC_FLASH_CMD2, START_BIT)' needs some
care.  Maybe a comment is fine?  It seems the Vybrid is safe for
different access sizes, but it is possible that some other CPU might not
be able to acce

Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings

2014-08-14 Thread Stephen Warren

On 08/14/2014 02:53 PM, Tom Rini wrote:

On Thu, Aug 14, 2014 at 01:50:31PM -0600, Stephen Warren wrote:

[snip]

uenv.txt is the opposite; it's very U-Boot specific, and more about
internal implementation details of U-Boot. In particular, I only see
a use-case for uenv.txt on systems that have nowhere to store the
U-Boot environment other than in some filesystem. That's the reason
the RPi port loads uenv.txt, so the environment can be modified
somehow. Perhaps there's an ENV_IS_IN_FAT that could be used instead
on the Pi? For example, none of the Tegra boards use uEnv.txt since
"saveenv" to flash works there.


Even with ENV_IS_IN_FAT you need to be in U-Boot to modify the
environment (fw_setenv/printenv should be adaptable easily enough I
would hope, but aren't today).  uEnv.txt is the way for a user to pop
the SD card into their PC, tweak the env as needed (or fiddle some
bits), eject the card and boot their target.


What, you don't link binary-editing the file to fix the CRC? :-P
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] how to read the buildman report

2014-08-14 Thread York Sun
Simon,

I need some help to understand the report of buildman. Use this example, when I
build all arm and powerpc boards,

$ tools/buildman/buildman -b working_qoriq arm powerpc -s

Summary of 19 commits for 1023 boards (24 threads, 1 job per thread)
01: ls102xa: dcu: Add platform support for DCU on LS1021ATWR board
   arm: +   tricorder_flash vf610twr tricorder
   powerpc: +   taishan dlvision
02: video: dcu: Add DCU driver support
03: video: dcu: Add Sii9022A HDMI Transmitter support
04: arm: ls102xa: Add LETECH support for LS1021AQDS/TWR board
05: serial: lpuart: add 32-bit registers lpuart support
06: net: tsec: Remove tx snooping support from LS1
   arm:vf610twr
07: arm: ls102xa: Add basic support for LS1021ATWR board
08: arm: ls102xa: Add basic support for LS1021AQDS board
   arm: +   ls1021atwr_nor ls1021atwr_letech
09: driver/ddr/fsl: Add support of overriding chip select write leveling
   arm: +   ls1021aqds_nor ls1021aqds_letech
10: driver/ddr/freescale: Fix DDR3 driver for ARM
11: driver/ddr/freescale: Add support of accumulate ECC
12: ls102xa: esdhc: Add esdhc support for LS102xA
13: ls102xa: etsec: Add etsec support for LS102xA
14: net: mdio: Use mb() to be compatible for both ARM and PowerPC
15: net: mdio: Add private MDIO read/write function
16: net: Merge asm/fsl_enet.h into fsl_mdio.h
17: ls102xa: i2c: Add i2c support for LS102xA
18: arm: ls102xa: Add Freescale LS102xA SoC support
19: patman: Only use git's --no-decorate when available

First, is the build supposed to be top down or bottom up? It looks like buildman
starts to build from the last commit and works it way down. What I don't
understand is the new board. Under patch 08 and 09, I see two boards failed. But
these two boards don't exist until a later commit. Should I use --force-reconfig
switch?

Second, when I see a failed board under a commit, is this commit causing the
failure? It is not the case in my example. I see vf610twr failed under 01, but
the actual failure is caused by commit 05.

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


Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings

2014-08-14 Thread Alexander Holler

Am 14.08.2014 23:35, schrieb Stephen Warren:

On 08/14/2014 02:53 PM, Tom Rini wrote:

On Thu, Aug 14, 2014 at 01:50:31PM -0600, Stephen Warren wrote:

[snip]

uenv.txt is the opposite; it's very U-Boot specific, and more about
internal implementation details of U-Boot. In particular, I only see
a use-case for uenv.txt on systems that have nowhere to store the
U-Boot environment other than in some filesystem. That's the reason
the RPi port loads uenv.txt, so the environment can be modified
somehow. Perhaps there's an ENV_IS_IN_FAT that could be used instead
on the Pi? For example, none of the Tegra boards use uEnv.txt since
"saveenv" to flash works there.


Even with ENV_IS_IN_FAT you need to be in U-Boot to modify the
environment (fw_setenv/printenv should be adaptable easily enough I
would hope, but aren't today).  uEnv.txt is the way for a user to pop
the SD card into their PC, tweak the env as needed (or fiddle some
bits), eject the card and boot their target.


What, you don't link binary-editing the file to fix the CRC? :-P


That reminds me that I thought about adding uEnv.sha1 (and CMD_SHA1) to 
have the same protection (or even better through sha1) as boot.cmd for 
environments where it makes sense. So in regard to "untrustworthy" 
sd-cards most boards. ;)


Regards,

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


Re: [U-Boot] how to read the buildman report

2014-08-14 Thread Simon Glass
Hi York,

On 14 August 2014 15:36, York Sun  wrote:

> Simon,
>
> I need some help to understand the report of buildman. Use this example,
> when I
> build all arm and powerpc boards,
>
>
I assume you've checked out the README.


> $ tools/buildman/buildman -b working_qoriq arm powerpc -s
>
> Summary of 19 commits for 1023 boards (24 threads, 1 job per thread)
> 01: ls102xa: dcu: Add platform support for DCU on LS1021ATWR board
>arm: +   tricorder_flash vf610twr tricorder
>powerpc: +   taishan dlvision
>

This means that in commit 01 these boards fail to build.

02: video: dcu: Add DCU driver support
> 03: video: dcu: Add Sii9022A HDMI Transmitter support
> 04: arm: ls102xa: Add LETECH support for LS1021AQDS/TWR board
> 05: serial: lpuart: add 32-bit registers lpuart support
> 06: net: tsec: Remove tx snooping support from LS1
>arm:vf610twr
>

This board got fixed by this commit.


> 07: arm: ls102xa: Add basic support for LS1021ATWR board
> 08: arm: ls102xa: Add basic support for LS1021AQDS board
>arm: +   ls1021atwr_nor ls1021atwr_letech
>

This commit causes these board to fail, in addition to the previous ones.

09: driver/ddr/fsl: Add support of overriding chip select write leveling
>arm: +   ls1021aqds_nor ls1021aqds_letech
> 10: driver/ddr/freescale: Fix DDR3 driver for ARM
> 11: driver/ddr/freescale: Add support of accumulate ECC
> 12: ls102xa: esdhc: Add esdhc support for LS102xA
> 13: ls102xa: etsec: Add etsec support for LS102xA
> 14: net: mdio: Use mb() to be compatible for both ARM and PowerPC
> 15: net: mdio: Add private MDIO read/write function
> 16: net: Merge asm/fsl_enet.h into fsl_mdio.h
> 17: ls102xa: i2c: Add i2c support for LS102xA
> 18: arm: ls102xa: Add Freescale LS102xA SoC support
> 19: patman: Only use git's --no-decorate when available
>
> First, is the build supposed to be top down or bottom up? It looks like
> buildman
> starts to build from the last commit and works it way down. What I don't
> understand is the new board. Under patch 08 and 09, I see two boards
> failed. But
> these two boards don't exist until a later commit. Should I use
> --force-reconfig
> switch?
>

It builds from the oldest commit to the newest, and shows in that order.

buildman does not understand boards that are created during a series. This
is a limitation. So you will get failures for commits that don't have the
board.


>
> Second, when I see a failed board under a commit, is this commit causing
> the
> failure? It is not the case in my example. I see vf610twr failed under 01,
> but
> the actual failure is caused by commit 05.
>

It seems that there is a problem for commit 01 also - perhaps just a
warning?

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


Re: [U-Boot] [PATCH v4 15/15] dm: tegra: Enable driver model for serial

2014-08-14 Thread Simon Glass
Hi Stephen,

On 11 August 2014 09:27, Simon Glass  wrote:

> Use driver model for serial ports (for test and comment only).
>
> dm: tegra: Use V_NS16550_CLK only in SPL builds
>
> Since Tegra now uses driver model for serial, adjust the definition of
> V_NS16550_CLK so that it is clear that this is only used for SPL.
>
> Signed-off-by: Simon Glass 

---
>
> Changes in v4:
> - Add a separate Tegra serial driver to deal with the clock issue
> - Add new CONFIG_TEGRA_SERIAL option to enable dm driver
> - Use hard-coded UART clock from Tegra configuration
>

Just checking in to see if this patch looks good?

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


Re: [U-Boot] how to read the buildman report

2014-08-14 Thread York Sun
On 08/14/2014 03:17 PM, Simon Glass wrote:
> Hi York,
> 
> On 14 August 2014 15:36, York Sun  > wrote:
> 
> Simon,
> 
> I need some help to understand the report of buildman. Use this example, 
> when I
> build all arm and powerpc boards,
> 
> 
> I assume you've checked out the README.

Yes, but not the latest one merged.
>  
> 
> $ tools/buildman/buildman -b working_qoriq arm powerpc -s
> 
> Summary of 19 commits for 1023 boards (24 threads, 1 job per thread)
> 01: ls102xa: dcu: Add platform support for DCU on LS1021ATWR board
>arm: +   tricorder_flash vf610twr tricorder
>powerpc: +   taishan dlvision
> 
> 
> This means that in commit 01 these boards fail to build.
> 
> 02: video: dcu: Add DCU driver support
> 03: video: dcu: Add Sii9022A HDMI Transmitter support
> 04: arm: ls102xa: Add LETECH support for LS1021AQDS/TWR board
> 05: serial: lpuart: add 32-bit registers lpuart support
> 06: net: tsec: Remove tx snooping support from LS1
>arm:vf610twr
> 
> 
> This board got fixed by this commit.
>  
> 
> 07: arm: ls102xa: Add basic support for LS1021ATWR board
> 08: arm: ls102xa: Add basic support for LS1021AQDS board
>arm: +   ls1021atwr_nor ls1021atwr_letech
> 
> 
> This commit causes these board to fail, in addition to the previous ones.
> 
> 09: driver/ddr/fsl: Add support of overriding chip select write leveling
>arm: +   ls1021aqds_nor ls1021aqds_letech
> 10: driver/ddr/freescale: Fix DDR3 driver for ARM
> 11: driver/ddr/freescale: Add support of accumulate ECC
> 12: ls102xa: esdhc: Add esdhc support for LS102xA
> 13: ls102xa: etsec: Add etsec support for LS102xA
> 14: net: mdio: Use mb() to be compatible for both ARM and PowerPC
> 15: net: mdio: Add private MDIO read/write function
> 16: net: Merge asm/fsl_enet.h into fsl_mdio.h
> 17: ls102xa: i2c: Add i2c support for LS102xA
> 18: arm: ls102xa: Add Freescale LS102xA SoC support
> 19: patman: Only use git's --no-decorate when available
> 
> First, is the build supposed to be top down or bottom up? It looks like 
> buildman
> starts to build from the last commit and works it way down. What I don't
> understand is the new board. Under patch 08 and 09, I see two boards 
> failed. But
> these two boards don't exist until a later commit. Should I use 
> --force-reconfig
> switch?
> 
> 
> It builds from the oldest commit to the newest, and shows in that order.

Doesn't looks so. The 19 is the oldest. The 18 is the first commit I am testing.
The 01 is the newest.

> 
> buildman does not understand boards that are created during a series. This is 
> a
> limitation. So you will get failures for commits that don't have the board.

That explains it.

>  
> 
> 
> Second, when I see a failed board under a commit, is this commit causing 
> the
> failure? It is not the case in my example. I see vf610twr failed under 
> 01, but
> the actual failure is caused by commit 05.
> 
> 
> It seems that there is a problem for commit 01 also - perhaps just a warning?

I think the build order is backward now. Before the latest merge, it did build
from the oldest to the newest. I confirmed that by checking out v2014.10-rc1.

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


Re: [U-Boot] how to read the buildman report

2014-08-14 Thread Simon Glass
Hi York,

On 14 August 2014 16:33, York Sun  wrote:

> On 08/14/2014 03:17 PM, Simon Glass wrote:
> > Hi York,
> >
> > On 14 August 2014 15:36, York Sun  > > wrote:
> >
> > Simon,
> >
> > I need some help to understand the report of buildman. Use this
> example, when I
> > build all arm and powerpc boards,
> >
> >
> > I assume you've checked out the README.
>
> Yes, but not the latest one merged.
> >
> >
> > $ tools/buildman/buildman -b working_qoriq arm powerpc -s
> >
> > Summary of 19 commits for 1023 boards (24 threads, 1 job per thread)
> > 01: ls102xa: dcu: Add platform support for DCU on LS1021ATWR board
> >arm: +   tricorder_flash vf610twr tricorder
> >powerpc: +   taishan dlvision
> >
> >
> > This means that in commit 01 these boards fail to build.
> >
> > 02: video: dcu: Add DCU driver support
> > 03: video: dcu: Add Sii9022A HDMI Transmitter support
> > 04: arm: ls102xa: Add LETECH support for LS1021AQDS/TWR board
> > 05: serial: lpuart: add 32-bit registers lpuart support
> > 06: net: tsec: Remove tx snooping support from LS1
> >arm:vf610twr
> >
> >
> > This board got fixed by this commit.
> >
> >
> > 07: arm: ls102xa: Add basic support for LS1021ATWR board
> > 08: arm: ls102xa: Add basic support for LS1021AQDS board
> >arm: +   ls1021atwr_nor ls1021atwr_letech
> >
> >
> > This commit causes these board to fail, in addition to the previous ones.
> >
> > 09: driver/ddr/fsl: Add support of overriding chip select write
> leveling
> >arm: +   ls1021aqds_nor ls1021aqds_letech
> > 10: driver/ddr/freescale: Fix DDR3 driver for ARM
> > 11: driver/ddr/freescale: Add support of accumulate ECC
> > 12: ls102xa: esdhc: Add esdhc support for LS102xA
> > 13: ls102xa: etsec: Add etsec support for LS102xA
> > 14: net: mdio: Use mb() to be compatible for both ARM and PowerPC
> > 15: net: mdio: Add private MDIO read/write function
> > 16: net: Merge asm/fsl_enet.h into fsl_mdio.h
> > 17: ls102xa: i2c: Add i2c support for LS102xA
> > 18: arm: ls102xa: Add Freescale LS102xA SoC support
> > 19: patman: Only use git's --no-decorate when available
> >
> > First, is the build supposed to be top down or bottom up? It looks
> like buildman
> > starts to build from the last commit and works it way down. What I
> don't
> > understand is the new board. Under patch 08 and 09, I see two boards
> failed. But
> > these two boards don't exist until a later commit. Should I use
> --force-reconfig
> > switch?
> >
> >
> > It builds from the oldest commit to the newest, and shows in that order.
>
> Doesn't looks so. The 19 is the oldest. The 18 is the first commit I am
> testing.
> The 01 is the newest.
>

Well you have found a bug!


> >
> > buildman does not understand boards that are created during a series.
> This is a
> > limitation. So you will get failures for commits that don't have the
> board.
>
> That explains it.
>
> >
> >
> >
> > Second, when I see a failed board under a commit, is this commit
> causing the
> > failure? It is not the case in my example. I see vf610twr failed
> under 01, but
> > the actual failure is caused by commit 05.
> >
> >
> > It seems that there is a problem for commit 01 also - perhaps just a
> warning?
>
> I think the build order is backward now. Before the latest merge, it did
> build
> from the oldest to the newest. I confirmed that by checking out
> v2014.10-rc1.
>

Ah, yes I changed something during the 'git log' refactoring.  I'll submit
a fix as that would be very confusing. Thanks for testing this. I should
have left those last two patches out until I heard from you.

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


[U-Boot] [PATCH v7 2/5] patman: Fix indentation in terminal.py

2014-08-14 Thread Simon Glass
This code came from a different project with 2-character indentation. Fix
it for U-Boot.

Signed-off-by: Simon Glass 
---

Changes in v7: None
Changes in v6:
- Add new patch to fix indentation in teminal.py

Changes in v5: None

 tools/patman/terminal.py | 108 ---
 1 file changed, 55 insertions(+), 53 deletions(-)

diff --git a/tools/patman/terminal.py b/tools/patman/terminal.py
index 597d526..11f80d8 100644
--- a/tools/patman/terminal.py
+++ b/tools/patman/terminal.py
@@ -15,66 +15,68 @@ import sys
 COLOR_IF_TERMINAL, COLOR_ALWAYS, COLOR_NEVER = range(3)
 
 class Color(object):
-  """Conditionally wraps text in ANSI color escape sequences."""
-  BLACK, RED, GREEN, YELLOW, BLUE, MAGENTA, CYAN, WHITE = range(8)
-  BOLD = -1
-  BRIGHT_START = '\033[1;%dm'
-  NORMAL_START = '\033[22;%dm'
-  BOLD_START = '\033[1m'
-  RESET = '\033[0m'
+"""Conditionally wraps text in ANSI color escape sequences."""
+BLACK, RED, GREEN, YELLOW, BLUE, MAGENTA, CYAN, WHITE = range(8)
+BOLD = -1
+BRIGHT_START = '\033[1;%dm'
+NORMAL_START = '\033[22;%dm'
+BOLD_START = '\033[1m'
+RESET = '\033[0m'
 
-  def __init__(self, colored=COLOR_IF_TERMINAL):
-"""Create a new Color object, optionally disabling color output.
+def __init__(self, colored=COLOR_IF_TERMINAL):
+"""Create a new Color object, optionally disabling color output.
 
-Args:
-  enabled: True if color output should be enabled. If False then this
-class will not add color codes at all.
-"""
-self._enabled = (colored == COLOR_ALWAYS or
-(colored == COLOR_IF_TERMINAL and os.isatty(sys.stdout.fileno(
+Args:
+  enabled: True if color output should be enabled. If False then this
+class will not add color codes at all.
+"""
+self._enabled = (colored == COLOR_ALWAYS or
+(colored == COLOR_IF_TERMINAL and os.isatty(sys.stdout.fileno(
 
-  def Start(self, color, bright=True):
-"""Returns a start color code.
+def Start(self, color, bright=True):
+"""Returns a start color code.
 
-Args:
-  color: Color to use, .e.g BLACK, RED, etc.
+Args:
+  color: Color to use, .e.g BLACK, RED, etc.
 
-Returns:
-  If color is enabled, returns an ANSI sequence to start the given color,
-  otherwise returns empty string
-"""
-if self._enabled:
-base = self.BRIGHT_START if bright else self.NORMAL_START
-return base % (color + 30)
-return ''
+Returns:
+  If color is enabled, returns an ANSI sequence to start the given
+  color, otherwise returns empty string
+"""
+if self._enabled:
+base = self.BRIGHT_START if bright else self.NORMAL_START
+return base % (color + 30)
+return ''
 
-  def Stop(self):
-"""Retruns a stop color code.
+def Stop(self):
+"""Retruns a stop color code.
 
-Returns:
-  If color is enabled, returns an ANSI color reset sequence, otherwise
-  returns empty string
-"""
-if self._enabled:
-return self.RESET
-return ''
+Returns:
+  If color is enabled, returns an ANSI color reset sequence,
+  otherwise returns empty string
+"""
+if self._enabled:
+return self.RESET
+return ''
 
-  def Color(self, color, text, bright=True):
-"""Returns text with conditionally added color escape sequences.
+def Color(self, color, text, bright=True):
+"""Returns text with conditionally added color escape sequences.
 
-Keyword arguments:
-  color: Text color -- one of the color constants defined in this class.
-  text: The text to color.
+Keyword arguments:
+  color: Text color -- one of the color constants defined in this
+  class.
+  text: The text to color.
 
-Returns:
-  If self._enabled is False, returns the original text. If it's True,
-  returns text with color escape sequences based on the value of color.
-"""
-if not self._enabled:
-return text
-if color == self.BOLD:
-start = self.BOLD_START
-else:
-base = self.BRIGHT_START if bright else self.NORMAL_START
-start = base % (color + 30)
-return start + text + self.RESET
+Returns:
+  If self._enabled is False, returns the original text. If it's True,
+  returns text with color escape sequences based on the value of
+  color.
+"""
+if not self._enabled:
+return text
+if color == self.BOLD:
+start = self.BOLD_START
+else:
+base = self.BRIGHT_START if bright else self.NORMAL_START
+start = base % (color + 30)
+return start + text + self.RESET
-- 
2.1.0.rc2.206.gedb03e5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de

[U-Boot] [PATCH v7 1/5] patman: Support the 'reverse' option for 'git log'

2014-08-14 Thread Simon Glass
This option is currently not supported, but needs to be, for buildman to
operate as expected.

Reported-by: York Sun 
Signed-off-by: Simon Glass 
---

Changes in v7:
- Add new patch to fix the 'reverse' bug

Changes in v6: None
Changes in v5: None

 tools/patman/gitutil.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py
index 735c8dd..e2b4959 100644
--- a/tools/patman/gitutil.py
+++ b/tools/patman/gitutil.py
@@ -38,6 +38,8 @@ def LogCmd(commit_range, git_dir=None, oneline=False, 
reverse=False,
 cmd.append('--oneline')
 if use_no_decorate:
 cmd.append('--no-decorate')
+if reverse:
+cmd.append('--reverse')
 if count is not None:
 cmd.append('-n%d' % count)
 if commit_range:
-- 
2.1.0.rc2.206.gedb03e5

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


[U-Boot] [PATCH v7 0/5] Add some missing buildman features and deprecate MAKEALL

2014-08-14 Thread Simon Glass
Buildman has been around for a little over a year and is used by a fair
number of U-Boot developers. However quite a few people still use MAKEALL.

Buildman was intended to replace MAKEALL, so perhaps now is a good time to
start that process.

The reasons to deprecate MAKEALL are:
- We don't want to maintain two build systems
- Buildman is typically faster
- Buildman has a lot more features

This series adds a few features to buildman to fill some gaps, adds some
information into the README on how to migrate from MAKEALL, and adds a
deprecation message to MAKEALL.

Changes in v7:
- Add new patch to fix the 'reverse' bug
- Remove already-applied patches from the series
- Add the deprecation message at the end of the build also
- Drop the 'colour' patch sadly

Changes in v6:
- Add new patch to fix indentation in teminal.py
- Add new patch to fix patman unit tests
- Add new patch to remove patman's -a option

Changes in v5:
- Drop patch to search for *cc instead of *gcc for the compiler

Simon Glass (5):
  patman: Support the 'reverse' option for 'git log'
  patman: Fix indentation in terminal.py
  patman: Correct unit tests to run correctly
  patman: Remove the -a option
  RFC: Deprecate MAKEALL

 MAKEALL |  10 
 tools/patman/gitutil.py |  98 +++---
 tools/patman/patchstream.py |   7 ++-
 tools/patman/patman.py  |   7 ---
 tools/patman/terminal.py| 112 +++-
 tools/patman/test.py|  13 ++---
 6 files changed, 87 insertions(+), 160 deletions(-)

-- 
2.1.0.rc2.206.gedb03e5

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


[U-Boot] [PATCH v7 3/5] patman: Correct unit tests to run correctly

2014-08-14 Thread Simon Glass
It seems that doctest behaves differently now, and some of the unit tests
do not run. Adjust the tests to work correctly.

 ./tools/patman/patman --test


Signed-off-by: Simon Glass 
---

Changes in v7: None
Changes in v6:
- Add new patch to fix patman unit tests

Changes in v5: None

 tools/patman/gitutil.py |  8 
 tools/patman/patchstream.py |  7 +--
 tools/patman/terminal.py|  8 ++--
 tools/patman/test.py| 13 +++--
 4 files changed, 22 insertions(+), 14 deletions(-)

diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py
index e2b4959..29e6fdd 100644
--- a/tools/patman/gitutil.py
+++ b/tools/patman/gitutil.py
@@ -478,13 +478,13 @@ def LookupEmail(lookup_name, alias=None, 
raise_on_error=True, level=0):
 ...
 OSError: Recursive email alias at 'other'
 >>> LookupEmail('odd', alias, raise_on_error=False)
-\033[1;31mAlias 'odd' not found\033[0m
+Alias 'odd' not found
 []
 >>> # In this case the loop part will effectively be ignored.
 >>> LookupEmail('loop', alias, raise_on_error=False)
-\033[1;31mRecursive email alias at 'other'\033[0m
-\033[1;31mRecursive email alias at 'john'\033[0m
-\033[1;31mRecursive email alias at 'mary'\033[0m
+Recursive email alias at 'other'
+Recursive email alias at 'john'
+Recursive email alias at 'mary'
 ['j.blo...@napier.co.nz', 'm.popp...@cloud.net']
 """
 if not alias:
diff --git a/tools/patman/patchstream.py b/tools/patman/patchstream.py
index 0040468..322374c 100644
--- a/tools/patman/patchstream.py
+++ b/tools/patman/patchstream.py
@@ -275,7 +275,7 @@ class PatchStream:
 
 # Suppress duplicate signoffs
 elif signoff_match:
-if (self.is_log or
+if (self.is_log or not self.commit or
 self.commit.CheckDuplicateSignoff(signoff_match.group(1))):
 out = [line]
 
@@ -312,7 +312,10 @@ class PatchStream:
 out = []
 log = self.series.MakeChangeLog(self.commit)
 out += self.FormatTags(self.tags)
-out += [line] + self.commit.notes + [''] + log
+out += [line]
+if self.commit:
+out += self.commit.notes
+out += [''] + log
 elif self.found_test:
 if not re_allowed_after_test.match(line):
 self.lines_after_test += 1
diff --git a/tools/patman/terminal.py b/tools/patman/terminal.py
index 11f80d8..963f2f8 100644
--- a/tools/patman/terminal.py
+++ b/tools/patman/terminal.py
@@ -30,8 +30,12 @@ class Color(object):
   enabled: True if color output should be enabled. If False then this
 class will not add color codes at all.
 """
-self._enabled = (colored == COLOR_ALWAYS or
-(colored == COLOR_IF_TERMINAL and os.isatty(sys.stdout.fileno(
+try:
+self._enabled = (colored == COLOR_ALWAYS or
+(colored == COLOR_IF_TERMINAL and
+ os.isatty(sys.stdout.fileno(
+except:
+self._enabled = False
 
 def Start(self, color, bright=True):
 """Returns a start color code.
diff --git a/tools/patman/test.py b/tools/patman/test.py
index 8fcfe53..e8f7472 100644
--- a/tools/patman/test.py
+++ b/tools/patman/test.py
@@ -55,6 +55,7 @@ This adds functions to enable/disable clocks and reset to 
on-chip peripherals.
 
 Signed-off-by: Simon Glass 
 ---
+
  arch/arm/cpu/armv7/tegra2/Makefile |2 +-
  arch/arm/cpu/armv7/tegra2/ap20.c   |   57 ++
  arch/arm/cpu/armv7/tegra2/clock.c  |  163 +
@@ -200,7 +201,7 @@ index 000..2234c87
 self.assertEqual(result.errors, 0)
 self.assertEqual(result.warnings, 0)
 self.assertEqual(result.checks, 0)
-self.assertEqual(result.lines, 67)
+self.assertEqual(result.lines, 56)
 os.remove(inf)
 
 def testNoSignoff(self):
@@ -211,18 +212,18 @@ index 000..2234c87
 self.assertEqual(result.errors, 1)
 self.assertEqual(result.warnings, 0)
 self.assertEqual(result.checks, 0)
-self.assertEqual(result.lines, 67)
+self.assertEqual(result.lines, 56)
 os.remove(inf)
 
 def testSpaces(self):
 inf = self.SetupData('spaces')
 result = checkpatch.CheckPatch(inf)
 self.assertEqual(result.ok, False)
-self.assertEqual(len(result.problems), 1)
+self.assertEqual(len(result.problems), 2)
 self.assertEqual(result.errors, 0)
-self.assertEqual(result.warnings, 1)
+self.assertEqual(result.warnings, 2)
 self.assertEqual(result.checks, 0)
-self.assertEqual(result.lines, 67)
+self.assertEqual(result.lines, 56)
 os.remove(inf)
 
 def testIndent(self):
@@ -233,7 +234,7 @@ index 000..2234c87
 self.assertEqual(result.errors, 0)
 self.assertEqual(resu

[U-Boot] [PATCH v7 4/5] patman: Remove the -a option

2014-08-14 Thread Simon Glass
It seems that this is no longer needed, since checkpatch.pl will catch
whitespace problems in patches. Also the option is not widely used, so
it seems safe to just remove it.

Suggested-by: Masahiro Yamada 
Signed-off-by: Simon Glass 
---

Changes in v7: None
Changes in v6:
- Add new patch to remove patman's -a option

Changes in v5: None

 tools/patman/gitutil.py | 88 -
 tools/patman/patman.py  |  7 
 2 files changed, 95 deletions(-)

diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py
index 29e6fdd..45276e6 100644
--- a/tools/patman/gitutil.py
+++ b/tools/patman/gitutil.py
@@ -215,94 +215,6 @@ def CreatePatches(start, count, series):
 else:
return None, files
 
-def ApplyPatch(verbose, fname):
-"""Apply a patch with git am to test it
-
-TODO: Convert these to use command, with stderr option
-
-Args:
-fname: filename of patch file to apply
-"""
-col = terminal.Color()
-cmd = ['git', 'am', fname]
-pipe = subprocess.Popen(cmd, stdout=subprocess.PIPE,
-stderr=subprocess.PIPE)
-stdout, stderr = pipe.communicate()
-re_error = re.compile('^error: patch failed: (.+):(\d+)')
-for line in stderr.splitlines():
-if verbose:
-print line
-match = re_error.match(line)
-if match:
-print checkpatch.GetWarningMsg(col, 'warning', match.group(1),
-   int(match.group(2)), 'Patch failed')
-return pipe.returncode == 0, stdout
-
-def ApplyPatches(verbose, args, start_point):
-"""Apply the patches with git am to make sure all is well
-
-Args:
-verbose: Print out 'git am' output verbatim
-args: List of patch files to apply
-start_point: Number of commits back from HEAD to start applying.
-Normally this is len(args), but it can be larger if a start
-offset was given.
-"""
-error_count = 0
-col = terminal.Color()
-
-# Figure out our current position
-cmd = ['git', 'name-rev', 'HEAD', '--name-only']
-pipe = subprocess.Popen(cmd, stdout=subprocess.PIPE)
-stdout, stderr = pipe.communicate()
-if pipe.returncode:
-str = 'Could not find current commit name'
-print col.Color(col.RED, str)
-print stdout
-return False
-old_head = stdout.splitlines()[0]
-if old_head == 'undefined':
-str = "Invalid HEAD '%s'" % stdout.strip()
-print col.Color(col.RED, str)
-return False
-
-# Checkout the required start point
-cmd = ['git', 'checkout', 'HEAD~%d' % start_point]
-pipe = subprocess.Popen(cmd, stdout=subprocess.PIPE,
-stderr=subprocess.PIPE)
-stdout, stderr = pipe.communicate()
-if pipe.returncode:
-str = 'Could not move to commit before patch series'
-print col.Color(col.RED, str)
-print stdout, stderr
-return False
-
-# Apply all the patches
-for fname in args:
-ok, stdout = ApplyPatch(verbose, fname)
-if not ok:
-print col.Color(col.RED, 'git am returned errors for %s: will '
-'skip this patch' % fname)
-if verbose:
-print stdout
-error_count += 1
-cmd = ['git', 'am', '--skip']
-pipe = subprocess.Popen(cmd, stdout=subprocess.PIPE)
-stdout, stderr = pipe.communicate()
-if pipe.returncode != 0:
-print col.Color(col.RED, 'Unable to skip patch! Aborting...')
-print stdout
-break
-
-# Return to our previous position
-cmd = ['git', 'checkout', old_head]
-pipe = subprocess.Popen(cmd, stdout=subprocess.PIPE, 
stderr=subprocess.PIPE)
-stdout, stderr = pipe.communicate()
-if pipe.returncode:
-print col.Color(col.RED, 'Could not move back to head commit')
-print stdout, stderr
-return error_count == 0
-
 def BuildEmailList(in_list, tag=None, alias=None, raise_on_error=True):
 """Build a list of email addresses based on an input list.
 
diff --git a/tools/patman/patman.py b/tools/patman/patman.py
index c60aa5a..902fb36 100755
--- a/tools/patman/patman.py
+++ b/tools/patman/patman.py
@@ -25,9 +25,6 @@ import test
 
 
 parser = OptionParser()
-parser.add_option('-a', '--no-apply', action='store_false',
-  dest='apply_patches', default=True,
-  help="Don't test-apply patches with git am")
 parser.add_option('-H', '--full-help', action='store_true', dest='full_help',
default=False, help='Display the README file')
 parser.add_option('-c', '--count', dest='count', type='int',
@@ -144,10 +141,6 @@ else:
 ok = checkpatch.CheckPatches(options.verbose, args)
 else:
 ok = True
-if options.apply_patches:
-if not gitutil.ApplyPatches(options.verbose, args,
-options.count + options.start):
-   

[U-Boot] [PATCH v7 5/5] RFC: Deprecate MAKEALL

2014-08-14 Thread Simon Glass
Since buildman now includes most of the features of MAKEALL it is probably
time to talk about deprecating MAKEALL.

Comments welcome.

Signed-off-by: Simon Glass 
---

Changes in v7:
- Remove already-applied patches from the series
- Add the deprecation message at the end of the build also
- Drop the 'colour' patch sadly

Changes in v6: None
Changes in v5:
- Drop patch to search for *cc instead of *gcc for the compiler

 MAKEALL | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/MAKEALL b/MAKEALL
index 929fe88..e412336 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -60,6 +60,14 @@ usage()
exit ${ret}
 }
 
+deprecation() {
+   echo "** Note: MAKEALL is deprecated - please use buildman instead"
+   echo "** See tools/buildman/README for details"
+   echo
+}
+
+deprecation
+
 SHORT_OPTS="ha:c:v:s:b:lmMCnr"
 
LONG_OPTS="help,arch:,cpu:,vendor:,soc:,board:,list,maintainers,mails,check,continue,rebuild-errors"
 
@@ -849,6 +857,8 @@ print_stats() {
kill_children
fi
 
+   deprecation
+
exit $RC
 }
 
-- 
2.1.0.rc2.206.gedb03e5

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


[U-Boot] [PATCH] mx6sxsabresd: Convert to the new Kconfig style

2014-08-14 Thread Fabio Estevam
From: Fabio Estevam 

mx6sxsabresd was not in the master branch when the conversion to the new Kconfig
style happened, so convert it now so that it can build again.

Signed-off-by: Fabio Estevam 
---
 arch/arm/Kconfig |  4 
 board/freescale/mx6sxsabresd/Kconfig | 23 +++
 board/freescale/mx6sxsabresd/MAINTAINERS |  6 ++
 configs/mx6sxsabresd_defconfig   |  3 +++
 4 files changed, 36 insertions(+)
 create mode 100644 board/freescale/mx6sxsabresd/Kconfig
 create mode 100644 board/freescale/mx6sxsabresd/MAINTAINERS
 create mode 100644 configs/mx6sxsabresd_defconfig

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e385eda..c041e8a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -524,6 +524,9 @@ config TARGET_MX6SABRESD
 config TARGET_MX6SLEVK
bool "Support mx6slevk"
 
+config TARGET_MX6SXSABRESD
+   bool "Support mx6sxsabresd"
+
 config TARGET_GW_VENTANA
bool "Support gw_ventana"
 
@@ -880,6 +883,7 @@ source "board/freescale/mx6qarm2/Kconfig"
 source "board/freescale/mx6qsabreauto/Kconfig"
 source "board/freescale/mx6sabresd/Kconfig"
 source "board/freescale/mx6slevk/Kconfig"
+source "board/freescale/mx6sxsabresd/Kconfig"
 source "board/freescale/vf610twr/Kconfig"
 source "board/gateworks/gw_ventana/Kconfig"
 source "board/genesi/mx51_efikamx/Kconfig"
diff --git a/board/freescale/mx6sxsabresd/Kconfig 
b/board/freescale/mx6sxsabresd/Kconfig
new file mode 100644
index 000..ee8f4a6
--- /dev/null
+++ b/board/freescale/mx6sxsabresd/Kconfig
@@ -0,0 +1,23 @@
+if TARGET_MX6SXSABRESD
+
+config SYS_CPU
+   string
+   default "armv7"
+
+config SYS_BOARD
+   string
+   default "mx6sxsabresd"
+
+config SYS_VENDOR
+   string
+   default "freescale"
+
+config SYS_SOC
+   string
+   default "mx6"
+
+config SYS_CONFIG_NAME
+   string
+   default "mx6sxsabresd"
+
+endif
diff --git a/board/freescale/mx6sxsabresd/MAINTAINERS 
b/board/freescale/mx6sxsabresd/MAINTAINERS
new file mode 100644
index 000..f52f300
--- /dev/null
+++ b/board/freescale/mx6sxsabresd/MAINTAINERS
@@ -0,0 +1,6 @@
+MX6SXSABRESD BOARD
+M: Fabio Estevam 
+S: Maintained
+F: board/freescale/mx6sxsabresd/
+F: include/configs/mx6sxsabresd.h
+F: configs/mx6sxsabresd_defconfig
diff --git a/configs/mx6sxsabresd_defconfig b/configs/mx6sxsabresd_defconfig
new file mode 100644
index 000..f23d48f
--- /dev/null
+++ b/configs/mx6sxsabresd_defconfig
@@ -0,0 +1,3 @@
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6sxsabresd/imximage.cfg,MX6SX"
+CONFIG_ARM=y
+CONFIG_TARGET_MX6SXSABRESD=y
-- 
1.9.1

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


Re: [U-Boot] [PATCH 2/3] mtd, nand: move common functions from cmd_nand.c to common place

2014-08-14 Thread Scott Wood
On Mon, 2014-08-11 at 10:40 +0200, Heiko Schocher wrote:
> Hello Scott,
> 
> Am 30.07.2014 02:29, schrieb Scott Wood:
> > On Mon, 2014-07-14 at 09:39 +0200, Heiko Schocher wrote:
> >> move common functions from cmd_nand.c (for calculating offset
> >> and size from cmdline paramter) to common place, so they could
> >> used from other commands which use mtd partitions.
> >>
> >> For onenand the arg_off_size() is left in common/cmd_onenand.c.
> >> It should use now the common arg_off() function, but as I could
> >> not test onenand I let it there ...
> >>
> >> Signed-off-by: Heiko Schocher
> >> Cc: Scott Wood
> >> Cc: Tom Rini
> >> ---
> >>   common/cmd_nand.c   | 140 
> >> +---
> >>   common/cmd_onenand.c|  19 +++
> >>   drivers/mtd/Makefile|   4 +-
> >>   drivers/mtd/mtd_uboot.c | 114 +++
> >>   include/linux/mtd/mtd.h |   7 +++
> >>   5 files changed, 154 insertions(+), 130 deletions(-)
> >>   create mode 100644 drivers/mtd/mtd_uboot.c
> >
> > ACK the concept, some nits below.
> >
> > Have you given any more thought to formally taking over the
> > custodianship?  If not, Tom, are you expecting another pull request from
> > me or were you going to apply Heiko's patches directly?
> 
> I thinking about it, yes, but I am really busy ... but it seems
> nobody else want to volunteer ... I discussed with Wolfgang, if
> it would make sense to create a mtd branch ... so, if you could not
> longer maintain the nand branch, we can set it to orphaned (in the
> hope, someone will volunteer ...) and I can also handle the nand
> patches ... but Wolfgang is currently on vacation, so this step
> maybe take a while ...

OK.  I can still review things now and then, but it's getting hard to be
responsive to the extent expected of a custodian.

> >> diff --git a/drivers/mtd/mtd_uboot.c b/drivers/mtd/mtd_uboot.c
> >> new file mode 100644
> >> index 000..66e49c3
> >> --- /dev/null
> >> +++ b/drivers/mtd/mtd_uboot.c
> >> @@ -0,0 +1,114 @@
> >> +/*
> >> + * (C) Copyright 2014
> >> + * Heiko Schocher, DENX Software Engineering, h...@denx.de.
> >> + *
> >> + * SPDX-License-Identifier:   GPL-2.0+
> >> + */
> >> +#include
> >> +#include
> >> +#include
> >
> > What do you use from the jffs2 header?
> 
> Yes, good question ... because missing common mtd defines, like:
> 
> struct mtd_device {
> 
> found in include/jffs2/load_kernel.h
> used in common/cmd_nand.c for example ... its really time to
> cleanup the mtd subsystem!
> 
> Where to move this common defines? include/linux/mtd/mtd.h ?
> 
> But before the mtd/ubi/ubifs sync patches are not in mainline, I do
> not want change this ... maybe it is okay to do this in a second step?

Sure.

-Scott


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


Re: [U-Boot] [PATCH v2 3/3] bootm: use genimg_get_kernel_addr()

2014-08-14 Thread York Sun
On 08/04/2014 05:43 PM, Bryan Wu wrote:
> Use the new API which is originally taken out from boot_get_kernel
> of bootm.c
> 
> Signed-off-by: Bryan Wu 
> Tested-by: Stephen Warren 
> Reviewed-by: Stephen Warren 
> ---
>  common/bootm.c | 25 +
>  1 file changed, 5 insertions(+), 20 deletions(-)
> 
> diff --git a/common/bootm.c b/common/bootm.c
> index 7ec2ed8..621bff2 100644
> --- a/common/bootm.c
> +++ b/common/bootm.c



>   bootstage_mark(BOOTSTAGE_ID_CHECK_MAGIC);
>  
> @@ -807,6 +788,10 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int 
> flag, int argc,
>  #endif
>  #if defined(CONFIG_FIT)
>   case IMAGE_FORMAT_FIT:
> + if (!fit_parse_conf(argv[0], load_addr, &img_addr,
> + fit_uname_config))
> + fit_parse_subimage(argv[0], load_addr, &img_addr,
> + fit_uname_kernel);
>   os_noffset = fit_image_load(images, img_addr,
>   &fit_uname_kernel, &fit_uname_config,
>   IH_ARCH_DEFAULT, IH_TYPE_KERNEL,
> 

Did anyone test this addition? It breaks my booting. The variable img_addr get
changed for calling fit_parse_conf(). If I don't use load_addr variable and run
"bootm " with a FIT image, this will fail. It took me hours to figure out.

Why is this change needed? What does it fix?

York

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


Re: [U-Boot] [PATCH v2 3/3] bootm: use genimg_get_kernel_addr()

2014-08-14 Thread Bryan Wu
On Thu, Aug 14, 2014 at 6:00 PM, York Sun  wrote:
> On 08/04/2014 05:43 PM, Bryan Wu wrote:
>> Use the new API which is originally taken out from boot_get_kernel
>> of bootm.c
>>
>> Signed-off-by: Bryan Wu 
>> Tested-by: Stephen Warren 
>> Reviewed-by: Stephen Warren 
>> ---
>>  common/bootm.c | 25 +
>>  1 file changed, 5 insertions(+), 20 deletions(-)
>>
>> diff --git a/common/bootm.c b/common/bootm.c
>> index 7ec2ed8..621bff2 100644
>> --- a/common/bootm.c
>> +++ b/common/bootm.c
>
> 
>
>>   bootstage_mark(BOOTSTAGE_ID_CHECK_MAGIC);
>>
>> @@ -807,6 +788,10 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, 
>> int flag, int argc,
>>  #endif
>>  #if defined(CONFIG_FIT)
>>   case IMAGE_FORMAT_FIT:
>> + if (!fit_parse_conf(argv[0], load_addr, &img_addr,
>> + fit_uname_config))
>> + fit_parse_subimage(argv[0], load_addr, &img_addr,
>> + fit_uname_kernel);
>>   os_noffset = fit_image_load(images, img_addr,
>>   &fit_uname_kernel, &fit_uname_config,
>>   IH_ARCH_DEFAULT, IH_TYPE_KERNEL,
>>
>
> Did anyone test this addition? It breaks my booting. The variable img_addr get
> changed for calling fit_parse_conf(). If I don't use load_addr variable and 
> run
> "bootm " with a FIT image, this will fail. It took me hours to figure 
> out.
>
> Why is this change needed? What does it fix?
>
> York
>

I think Tom merged one with the fixing:


+ if (!fit_parse_conf(argv[0], load_addr, &img_addr,
+ &fit_uname_config))
+ fit_parse_subimage(argv[0], load_addr, &img_addr,
+ &fit_uname_kernel);


Can you try that?
-Bryan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 3/3] bootm: use genimg_get_kernel_addr()

2014-08-14 Thread York Sun
Sorry for top posting from my phone.

I tested with the latest code merged, not your original patch.

York


From: Bryan Wu
Sent: Thu, 14/08/2014 18:05
To: Sun York-R58495 
CC: Tom Rini ; Stephen Warren ; 
u-boot@lists.denx.de; simon Glass ; Basu Arnab-B45036 

Subject: Re: [U-Boot] [PATCH v2 3/3] bootm: use genimg_get_kernel_addr()


On Thu, Aug 14, 2014 at 6:00 PM, York Sun  wrote:
> On 08/04/2014 05:43 PM, Bryan Wu wrote:
>> Use the new API which is originally taken out from boot_get_kernel
>> of bootm.c
>>
>> Signed-off-by: Bryan Wu 
>> Tested-by: Stephen Warren 
>> Reviewed-by: Stephen Warren 
>> ---
>>  common/bootm.c | 25 +
>>  1 file changed, 5 insertions(+), 20 deletions(-)
>>
>> diff --git a/common/bootm.c b/common/bootm.c
>> index 7ec2ed8..621bff2 100644
>> --- a/common/bootm.c
>> +++ b/common/bootm.c
>
> 
>
>>   bootstage_mark(BOOTSTAGE_ID_CHECK_MAGIC);
>>
>> @@ -807,6 +788,10 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, 
>> int flag, int argc,
>>  #endif
>>  #if defined(CONFIG_FIT)
>>   case IMAGE_FORMAT_FIT:
>> + if (!fit_parse_conf(argv[0], load_addr, &img_addr,
>> + fit_uname_config))
>> + fit_parse_subimage(argv[0], load_addr, &img_addr,
>> + fit_uname_kernel);
>>   os_noffset = fit_image_load(images, img_addr,
>>   &fit_uname_kernel, &fit_uname_config,
>>   IH_ARCH_DEFAULT, IH_TYPE_KERNEL,
>>
>
> Did anyone test this addition? It breaks my booting. The variable img_addr get
> changed for calling fit_parse_conf(). If I don't use load_addr variable and 
> run
> "bootm " with a FIT image, this will fail. It took me hours to figure 
> out.
>
> Why is this change needed? What does it fix?
>
> York
>

I think Tom merged one with the fixing:


+ if (!fit_parse_conf(argv[0], load_addr, &img_addr,
+ &fit_uname_config))
+ fit_parse_subimage(argv[0], load_addr, &img_addr,
+ &fit_uname_kernel);


Can you try that?
-Bryan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 3/3] bootm: use genimg_get_kernel_addr()

2014-08-14 Thread Tom Rini
On Thu, Aug 14, 2014 at 06:00:31PM -0700, York Sun wrote:
> On 08/04/2014 05:43 PM, Bryan Wu wrote:
> > Use the new API which is originally taken out from boot_get_kernel
> > of bootm.c
> > 
> > Signed-off-by: Bryan Wu 
> > Tested-by: Stephen Warren 
> > Reviewed-by: Stephen Warren 
> > ---
> >  common/bootm.c | 25 +
> >  1 file changed, 5 insertions(+), 20 deletions(-)
> > 
> > diff --git a/common/bootm.c b/common/bootm.c
> > index 7ec2ed8..621bff2 100644
> > --- a/common/bootm.c
> > +++ b/common/bootm.c
> 
> 
> 
> > bootstage_mark(BOOTSTAGE_ID_CHECK_MAGIC);
> >  
> > @@ -807,6 +788,10 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, 
> > int flag, int argc,
> >  #endif
> >  #if defined(CONFIG_FIT)
> > case IMAGE_FORMAT_FIT:
> > +   if (!fit_parse_conf(argv[0], load_addr, &img_addr,
> > +   fit_uname_config))
> > +   fit_parse_subimage(argv[0], load_addr, &img_addr,
> > +   fit_uname_kernel);
> > os_noffset = fit_image_load(images, img_addr,
> > &fit_uname_kernel, &fit_uname_config,
> > IH_ARCH_DEFAULT, IH_TYPE_KERNEL,
> > 
> 
> Did anyone test this addition? It breaks my booting. The variable img_addr get
> changed for calling fit_parse_conf(). If I don't use load_addr variable and 
> run
> "bootm " with a FIT image, this will fail. It took me hours to figure 
> out.

How exactly are you booting?  I tested a fit with bootm addr#conf@1 or
so.

-- 
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 v2 3/3] bootm: use genimg_get_kernel_addr()

2014-08-14 Thread York Sun
Tom,

I tested with "bootm 806f". My FIT image is loaded there. I don't have 
load_addr variable. My default load_addr (from CONFIG macro) is different from 
this address.

York


From: Tom Rini
Sent: Thu, 14/08/2014 18:38
To: Sun York-R58495 
CC: Bryan Wu ; s...@chromium.org; swar...@wwwdotorg.org; 
u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH v2 3/3] bootm: use genimg_get_kernel_addr()


On Thu, Aug 14, 2014 at 06:00:31PM -0700, York Sun wrote:
> On 08/04/2014 05:43 PM, Bryan Wu wrote:
> > Use the new API which is originally taken out from boot_get_kernel
> > of bootm.c
> >
> > Signed-off-by: Bryan Wu 
> > Tested-by: Stephen Warren 
> > Reviewed-by: Stephen Warren 
> > ---
> >  common/bootm.c | 25 +
> >  1 file changed, 5 insertions(+), 20 deletions(-)
> >
> > diff --git a/common/bootm.c b/common/bootm.c
> > index 7ec2ed8..621bff2 100644
> > --- a/common/bootm.c
> > +++ b/common/bootm.c
>
> 
>
> >  bootstage_mark(BOOTSTAGE_ID_CHECK_MAGIC);
> >
> > @@ -807,6 +788,10 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, 
> > int flag, int argc,
> >  #endif
> >  #if defined(CONFIG_FIT)
> >  case IMAGE_FORMAT_FIT:
> > +   if (!fit_parse_conf(argv[0], load_addr, &img_addr,
> > +   fit_uname_config))
> > +   fit_parse_subimage(argv[0], load_addr, &img_addr,
> > +   fit_uname_kernel);
> >  os_noffset = fit_image_load(images, img_addr,
> >  &fit_uname_kernel, &fit_uname_config,
> >  IH_ARCH_DEFAULT, IH_TYPE_KERNEL,
> >
>
> Did anyone test this addition? It breaks my booting. The variable img_addr get
> changed for calling fit_parse_conf(). If I don't use load_addr variable and 
> run
> "bootm " with a FIT image, this will fail. It took me hours to figure 
> out.

How exactly are you booting?  I tested a fit with bootm addr#conf@1 or
so.

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


[U-Boot] [PATCH 1/2] mx6sx: Adjust enable_fec_anatop_clock() for mx6solox

2014-08-14 Thread Fabio Estevam
From: Fabio Estevam 

Configure and enable the ethernet clock for mx6solox.

Signed-off-by: Fabio Estevam 
---
 arch/arm/cpu/armv7/mx6/clock.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index abd9d61..820b8d5 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -373,6 +373,27 @@ int enable_fec_anatop_clock(enum enet_freq freq)
reg &= ~BM_ANADIG_PLL_ENET_BYPASS;
writel(reg, &anatop->pll_enet);
 
+#ifdef CONFIG_MX6SX
+   /*
+* Set enet ahb clock to 200MHz
+* pll2_pfd2_396m-> ENET_PODF-> ENET_AHB
+*/
+   reg = readl(&imx_ccm->chsccdr);
+   reg &= ~(MXC_CCM_CHSCCDR_ENET_PRE_CLK_SEL_MASK
+| MXC_CCM_CHSCCDR_ENET_PODF_MASK
+| MXC_CCM_CHSCCDR_ENET_CLK_SEL_MASK);
+   /* PLL2 PFD2 */
+   reg |= (4 << MXC_CCM_CHSCCDR_ENET_PRE_CLK_SEL_OFFSET);
+   /* Div = 2*/
+   reg |= (1 << MXC_CCM_CHSCCDR_ENET_PODF_OFFSET);
+   reg |= (0 << MXC_CCM_CHSCCDR_ENET_CLK_SEL_OFFSET);
+   writel(reg, &imx_ccm->chsccdr);
+
+   /* Enable enet system clock */
+   reg = readl(&imx_ccm->CCGR3);
+   reg |= MXC_CCM_CCGR3_ENET_MASK;
+   writel(reg, &imx_ccm->CCGR3);
+#endif
return 0;
 }
 #endif
-- 
1.9.1

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


[U-Boot] [PATCH 2/2] mx6sxsabresd: Add Ethernet support

2014-08-14 Thread Fabio Estevam
From: Fabio Estevam 

mx6sxsabresd board has 2 FEC ports, each one connected to a AR8031.

Add support for one FEC port initially.

Signed-off-by: Fabio Estevam 
---
FEC is not functional after this series.

There is still another patch for FEC that I will submit later that makes
FEC functional on mx6solox, but it is orthogonal to this series.

 arch/arm/include/asm/arch-mx6/crm_regs.h|   1 +
 arch/arm/include/asm/arch-mx6/iomux.h   |  10 +++
 board/freescale/mx6sxsabresd/mx6sxsabresd.c | 116 
 include/configs/mx6sxsabresd.h  |  17 
 4 files changed, 144 insertions(+)

diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h 
b/arch/arm/include/asm/arch-mx6/crm_regs.h
index 9a7fb34..e67b5b9 100644
--- a/arch/arm/include/asm/arch-mx6/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
@@ -981,6 +981,7 @@ struct mxc_ccm_reg {
 #define BM_ANADIG_PLL_ENET_RSVD1 0x7FE0
 #define BF_ANADIG_PLL_ENET_RSVD1(v)  \
(((v) << 21) & BM_ANADIG_PLL_ENET_RSVD1)
+#define BM_ANADIG_PLL_ENET_REF_25M_ENABLE 0x0020
 #define BM_ANADIG_PLL_ENET_ENABLE_SATA 0x0010
 #define BM_ANADIG_PLL_ENET_ENABLE_PCIE 0x0008
 #define BM_ANADIG_PLL_ENET_PFD_OFFSET_EN 0x0004
diff --git a/arch/arm/include/asm/arch-mx6/iomux.h 
b/arch/arm/include/asm/arch-mx6/iomux.h
index 6a4a632..f54db69 100644
--- a/arch/arm/include/asm/arch-mx6/iomux.h
+++ b/arch/arm/include/asm/arch-mx6/iomux.h
@@ -65,6 +65,16 @@
 #define IOMUX_GPR1_FEC_MASK(IOMUX_GPR1_FEC_CLOCK_MUX1_SEL_MASK \
| IOMUX_GPR1_FEC_CLOCK_MUX2_SEL_MASK)
 
+#define IOMUX_GPR1_FEC1_CLOCK_MUX1_SEL_MASK (0x1 << 17)
+#define IOMUX_GPR1_FEC1_CLOCK_MUX2_SEL_MASK (0x1 << 13)
+#define IOMUX_GPR1_FEC1_MASK   (IOMUX_GPR1_FEC1_CLOCK_MUX1_SEL_MASK \
+   | IOMUX_GPR1_FEC1_CLOCK_MUX2_SEL_MASK)
+
+#define IOMUX_GPR1_FEC2_CLOCK_MUX1_SEL_MASK (0x1 << 18)
+#define IOMUX_GPR1_FEC2_CLOCK_MUX2_SEL_MASK (0x1 << 14)
+#define IOMUX_GPR1_FEC2_MASK   (IOMUX_GPR1_FEC2_CLOCK_MUX1_SEL_MASK \
+   | IOMUX_GPR1_FEC2_CLOCK_MUX2_SEL_MASK)
+
 #define IOMUXC_GPR13_SATA_PHY_8_RXEQ_0P5DB (0<<24)
 #define IOMUXC_GPR13_SATA_PHY_8_RXEQ_1P0DB (1<<24)
 #define IOMUXC_GPR13_SATA_PHY_8_RXEQ_1P5DB (2<<24)
diff --git a/board/freescale/mx6sxsabresd/mx6sxsabresd.c 
b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
index 6cd2b4a..5eaec1b 100644
--- a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
+++ b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -20,6 +21,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -38,6 +41,21 @@ DECLARE_GLOBAL_DATA_PTR;
PAD_CTL_DSE_40ohm | PAD_CTL_HYS |   \
PAD_CTL_ODE)
 
+#define ENET_PAD_CTRL  (PAD_CTL_PUS_100K_UP | PAD_CTL_PUE | \
+   PAD_CTL_SPEED_HIGH   |   \
+   PAD_CTL_DSE_48ohm   | PAD_CTL_SRE_FAST)
+
+#define ENET_CLK_PAD_CTRL  (PAD_CTL_SPEED_MED | \
+   PAD_CTL_DSE_120ohm   | PAD_CTL_SRE_FAST)
+
+#define ENET_RX_PAD_CTRL  (PAD_CTL_PKE | PAD_CTL_PUE |  \
+   PAD_CTL_SPEED_HIGH   | PAD_CTL_SRE_FAST)
+
+#define I2C_PAD_CTRL(PAD_CTL_PKE | PAD_CTL_PUE |\
+   PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED |   \
+   PAD_CTL_DSE_40ohm | PAD_CTL_HYS |   \
+   PAD_CTL_ODE)
+
 int dram_init(void)
 {
gd->ram_size = PHYS_SDRAM_SIZE;
@@ -60,11 +78,83 @@ static iomux_v3_cfg_t const usdhc4_pads[] = {
MX6_PAD_SD4_DATA7__GPIO6_IO_21 | MUX_PAD_CTRL(NO_PAD_CTRL),
 };
 
+static iomux_v3_cfg_t const fec1_pads[] = {
+   MX6_PAD_ENET1_MDC__ENET1_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6_PAD_ENET1_MDIO__ENET1_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6_PAD_RGMII1_RX_CTL__ENET1_RX_EN | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
+   MX6_PAD_RGMII1_RD0__ENET1_RX_DATA_0 | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
+   MX6_PAD_RGMII1_RD1__ENET1_RX_DATA_1 | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
+   MX6_PAD_RGMII1_RD2__ENET1_RX_DATA_2 | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
+   MX6_PAD_RGMII1_RD3__ENET1_RX_DATA_3 | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
+   MX6_PAD_RGMII1_RXC__ENET1_RX_CLK | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
+   MX6_PAD_RGMII1_TX_CTL__ENET1_TX_EN | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6_PAD_RGMII1_TD0__ENET1_TX_DATA_0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6_PAD_RGMII1_TD1__ENET1_TX_DATA_1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6_PAD_RGMII1_TD2__ENET1_TX_DATA_2 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6_PAD_RGMII1_TD3__ENET1_TX_DATA_3 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6_PAD_RGMII1_TXC__ENET1_RGMII_TXC | MUX_PAD_CTRL(ENET_PAD_CTRL),
+};
+
+static iomux_v3_cfg_t const peri_3v3_pads[] = {
+   MX6_PAD_QSPI1A_DATA0__GPIO4_IO_16 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
+static iomux_v3_cfg_t const phy_control_pads[] = {
+   /* 25MHz Ethernet PHY Clock */
+   MX6_PAD_ENE

Re: [U-Boot] [PATCH v2 3/3] bootm: use genimg_get_kernel_addr()

2014-08-14 Thread Simon Glass
Hi York,

On 14 August 2014 19:42, York Sun  wrote:
> Tom,
>
> I tested with "bootm 806f". My FIT image is loaded there. I don't have
> load_addr variable. My default load_addr (from CONFIG macro) is different
> from this address.

Yes unfortunately this is completely wrong. I did not catch this in my
review unfortunately, perhaps because the & was removed in the code I
reviewed.

fit_uname_config and fit_uname_kernel must be passed back from
genimg_get_kernel_addr() - that function will need two new parameters.

Regards,
Simon

>
> York
>
> 
> From: Tom Rini
> Sent: Thu, 14/08/2014 18:38
> To: Sun York-R58495 
> CC: Bryan Wu ; s...@chromium.org; swar...@wwwdotorg.org;
> u-boot@lists.denx.de
>
> Subject: Re: [U-Boot] [PATCH v2 3/3] bootm: use genimg_get_kernel_addr()
>
> On Thu, Aug 14, 2014 at 06:00:31PM -0700, York Sun wrote:
>> On 08/04/2014 05:43 PM, Bryan Wu wrote:
>> > Use the new API which is originally taken out from boot_get_kernel
>> > of bootm.c
>> >
>> > Signed-off-by: Bryan Wu 
>> > Tested-by: Stephen Warren 
>> > Reviewed-by: Stephen Warren 
>> > ---
>> >  common/bootm.c | 25 +
>> >  1 file changed, 5 insertions(+), 20 deletions(-)
>> >
>> > diff --git a/common/bootm.c b/common/bootm.c
>> > index 7ec2ed8..621bff2 100644
>> > --- a/common/bootm.c
>> > +++ b/common/bootm.c
>>
>> 
>>
>> >  bootstage_mark(BOOTSTAGE_ID_CHECK_MAGIC);
>> >
>> > @@ -807,6 +788,10 @@ static const void *boot_get_kernel(cmd_tbl_t
>> > *cmdtp, int flag, int argc,
>> >  #endif
>> >  #if defined(CONFIG_FIT)
>> >  case IMAGE_FORMAT_FIT:
>> > +   if (!fit_parse_conf(argv[0], load_addr, &img_addr,
>> > +   fit_uname_config))
>> > +   fit_parse_subimage(argv[0], load_addr, &img_addr,
>> > +   fit_uname_kernel);
>> >  os_noffset = fit_image_load(images, img_addr,
>> >  &fit_uname_kernel, &fit_uname_config,
>> >  IH_ARCH_DEFAULT, IH_TYPE_KERNEL,
>> >
>>
>> Did anyone test this addition? It breaks my booting. The variable img_addr
>> get
>> changed for calling fit_parse_conf(). If I don't use load_addr variable
>> and run
>> "bootm " with a FIT image, this will fail. It took me hours to
>> figure out.
>
> How exactly are you booting?  I tested a fit with bootm addr#conf@1 or
> so.
>
> --
> Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v8 0/6] Add some missing buildman features and deprecate MAKEALL

2014-08-14 Thread Simon Glass
Buildman has been around for a little over a year and is used by a fair
number of U-Boot developers. However quite a few people still use MAKEALL.

Buildman was intended to replace MAKEALL, so perhaps now is a good time to
start that process.

The reasons to deprecate MAKEALL are:
- We don't want to maintain two build systems
- Buildman is typically faster
- Buildman has a lot more features

This series adds a few features to buildman to fill some gaps, adds some
information into the README on how to migrate from MAKEALL, and adds a
deprecation message to MAKEALL.

Changes in v8:
- Add new patch to disable the pager in git

Changes in v7:
- Add new patch to fix the 'reverse' bug
- Remove already-applied patches from the series
- Add the deprecation message at the end of the build also
- Drop the 'colour' patch sadly

Changes in v6:
- Add new patch to fix indentation in teminal.py
- Add new patch to fix patman unit tests
- Add new patch to remove patman's -a option

Changes in v5:
- Drop patch to search for *cc instead of *gcc for the compiler

Simon Glass (6):
  patman: Support the 'reverse' option for 'git log'
  patman: Fix indentation in terminal.py
  patman: Correct unit tests to run correctly
  patman: Remove the -a option
  patman: Use --no-pager' to stop git from forking a pager
  RFC: Deprecate MAKEALL

 MAKEALL |  10 
 tools/patman/gitutil.py | 100 +++
 tools/patman/patchstream.py |   7 ++-
 tools/patman/patman.py  |   7 ---
 tools/patman/terminal.py| 112 +++-
 tools/patman/test.py|  13 ++---
 6 files changed, 88 insertions(+), 161 deletions(-)

-- 
2.1.0.rc2.206.gedb03e5

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


[U-Boot] [PATCH v8 1/6] patman: Support the 'reverse' option for 'git log'

2014-08-14 Thread Simon Glass
This option is currently not supported, but needs to be, for buildman to
operate as expected.

Reported-by: York Sun 
Signed-off-by: Simon Glass 
---

Changes in v8: None
Changes in v7:
- Add new patch to fix the 'reverse' bug

Changes in v6: None
Changes in v5: None

 tools/patman/gitutil.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py
index 735c8dd..e2b4959 100644
--- a/tools/patman/gitutil.py
+++ b/tools/patman/gitutil.py
@@ -38,6 +38,8 @@ def LogCmd(commit_range, git_dir=None, oneline=False, 
reverse=False,
 cmd.append('--oneline')
 if use_no_decorate:
 cmd.append('--no-decorate')
+if reverse:
+cmd.append('--reverse')
 if count is not None:
 cmd.append('-n%d' % count)
 if commit_range:
-- 
2.1.0.rc2.206.gedb03e5

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


  1   2   >