date:20140501

On Thu, May 1, 2014 at 5:39 PM, Fabio Estevam feste...@gmail.com wrote:
 [Removing wandboard list, as it bounces when I reply to it]

 On Thu, May 1, 2014 at 5:16 PM, Otavio Salvador ota...@ossystems.com.br 
 wrote:
 mmcargs=setenv bootargs console=${console},${baudrate}  \
 -   root=${mmcroot}\0 \
 +   root=${mmcroot}; run videoargs\0 \
 +   videoargs= \
 +   setenv nextcon 0;  \
 +   if hdmidet; then  \
 +   setenv bootargs ${bootargs}  \
 +   
 video=mxcfb${nextcon}:dev=hdmi,1280x720M@60, \
 +   if=RGB24;  \

 This video line is specific to some FSL kernel version. Mainline
 kernel does not need this, so I prefer not to pass such argument in
 the kernel command line.

This works with Wandboard supported kernel and seems to be very widely
used. I think it won't work in this user case.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Patch v3 1/2] common/board_f: Preserve early global data

On 05/01/2014 08:54 AM, Simon Glass wrote:
 Hi York,
 
 On 30 April 2014 18:01, York Sun york...@freescale.com wrote:
 Some platforms (including mpc85xx, mpc86xx) use global data before calling
 function baord_inti_f(). This data should not be cleared later. Any arch
 which needs to preserve global data should define CONFIG_SYS_EARLY_GD.

 Signed-off-by: York Sun york...@freescale.com
 CC: Scott Wood scottw...@freescale.com
 CC: Simon Glass s...@chromium.org
 ---
 Change log

  v3: Introduce CONFIG_SYS_EARLY_GD instead of using a list
  v2: Instead of adding back gd init for all PPC, preserve gd for mpc85xx and 
 mpc86xx.

  README|3 +++
  arch/powerpc/include/asm/config.h |2 ++
  arch/x86/include/asm/config.h |1 +
  common/board_f.c  |   10 +-
  4 files changed, 11 insertions(+), 5 deletions(-)

 diff --git a/README b/README
 index 12758dc..1a51b11 100644
 --- a/README
 +++ b/README
 @@ -440,6 +440,9 @@ The following options need to be configured:
 supported, core will start to execute uboot when wakes up.

  - Generic CPU options:
 +   CONFIG_SYS_EARLY_GD
 +   Defines global data is used before board_init_f().
 +
 
 This looks like a good solution, but I believe that 'early' is in fact
 where we are headed. So perhaps you should create an inverted option
 and define it for archs that don't support it?

I don't disagree for the long term. But since we just start to convert to
generic board, fewer archs need this than those don't. I suggest we try this and
when most archs convert to generic board, we can invert it if needed.

 
 For what you have, I think CONFIG_SYS_EARLY_GLOBAL_DATA might be more
 descriptive. Also I think you should describe the purpose more
 precisely here - it's not just the use that you need to discuss.
 
 - The CPU init code must set it up and zero it
 - Then board_init_f() doesn't zero it
 

Will add these.

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

Re: [U-Boot] [Patch v3 1/2] common/board_f: Preserve early global data

On Thu, 2014-05-01 at 14:16 -0700, York Sun wrote:
 On 05/01/2014 08:54 AM, Simon Glass wrote:
  Hi York,
  
  On 30 April 2014 18:01, York Sun york...@freescale.com wrote:
  Some platforms (including mpc85xx, mpc86xx) use global data before calling
  function baord_inti_f(). This data should not be cleared later. Any arch
  which needs to preserve global data should define CONFIG_SYS_EARLY_GD.
 
  Signed-off-by: York Sun york...@freescale.com
  CC: Scott Wood scottw...@freescale.com
  CC: Simon Glass s...@chromium.org
  ---
  Change log
 
   v3: Introduce CONFIG_SYS_EARLY_GD instead of using a list
   v2: Instead of adding back gd init for all PPC, preserve gd for mpc85xx 
  and mpc86xx.
 
   README|3 +++
   arch/powerpc/include/asm/config.h |2 ++
   arch/x86/include/asm/config.h |1 +
   common/board_f.c  |   10 +-
   4 files changed, 11 insertions(+), 5 deletions(-)
 
  diff --git a/README b/README
  index 12758dc..1a51b11 100644
  --- a/README
  +++ b/README
  @@ -440,6 +440,9 @@ The following options need to be configured:
  supported, core will start to execute uboot when wakes up.
 
   - Generic CPU options:
  +   CONFIG_SYS_EARLY_GD
  +   Defines global data is used before board_init_f().
  +
  
  This looks like a good solution, but I believe that 'early' is in fact
  where we are headed. So perhaps you should create an inverted option
  and define it for archs that don't support it?
 
 I don't disagree for the long term. But since we just start to convert to
 generic board, fewer archs need this than those don't. I suggest we try this 
 and
 when most archs convert to generic board, we can invert it if needed.

Why wait to do it right?  Which arches actually don't need this, given
that Simon said he thinks ARM needs it as well?

-Scott


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

Re: [U-Boot] [Patch v3 1/2] common/board_f: Preserve early global data

On 05/01/2014 02:21 PM, Scott Wood wrote:
 On Thu, 2014-05-01 at 14:16 -0700, York Sun wrote:
 On 05/01/2014 08:54 AM, Simon Glass wrote:
 Hi York,

 On 30 April 2014 18:01, York Sun york...@freescale.com wrote:
 Some platforms (including mpc85xx, mpc86xx) use global data before calling
 function baord_inti_f(). This data should not be cleared later. Any arch
 which needs to preserve global data should define CONFIG_SYS_EARLY_GD.

 Signed-off-by: York Sun york...@freescale.com
 CC: Scott Wood scottw...@freescale.com
 CC: Simon Glass s...@chromium.org
 ---
 Change log

  v3: Introduce CONFIG_SYS_EARLY_GD instead of using a list
  v2: Instead of adding back gd init for all PPC, preserve gd for mpc85xx 
 and mpc86xx.

  README|3 +++
  arch/powerpc/include/asm/config.h |2 ++
  arch/x86/include/asm/config.h |1 +
  common/board_f.c  |   10 +-
  4 files changed, 11 insertions(+), 5 deletions(-)

 diff --git a/README b/README
 index 12758dc..1a51b11 100644
 --- a/README
 +++ b/README
 @@ -440,6 +440,9 @@ The following options need to be configured:
 supported, core will start to execute uboot when wakes up.

  - Generic CPU options:
 +   CONFIG_SYS_EARLY_GD
 +   Defines global data is used before board_init_f().
 +

 This looks like a good solution, but I believe that 'early' is in fact
 where we are headed. So perhaps you should create an inverted option
 and define it for archs that don't support it?

 I don't disagree for the long term. But since we just start to convert to
 generic board, fewer archs need this than those don't. I suggest we try this 
 and
 when most archs convert to generic board, we can invert it if needed.
 
 Why wait to do it right?  Which arches actually don't need this, given
 that Simon said he thinks ARM needs it as well?
 

Adding something I can't test?

Even Simon said he thinks ARM needs it, it is not what current code has. If I
revert this logic,

#ifdef CONFIG_SYS_GLOBAL_DATA_STACK
   gd_dt data;

   gd = data;
   zero_global_data();
#endif

I need to add #define CONFIG_SYS_GLOBAL_DATA_STACK to the board/arch who needs
it. I have no idea which needs in the 70+ boards with CONFIG_DISPLAY_BOARDINFO
defined.


York

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

[U-Boot] [PATCH v2] wandboard: add Future Eletronics 7 WVGA LCD extension board

This adds support for the 7 WVGA produced by Future Eletronics and
make it dynamically detect if it is connected or not based on the
touchscreen controller.

Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Fabio, I haven't change the environment script as I consider important
to have it working with Wandboard kernel. Please take a look and comment
accordingly.

Changes in v2:
- Drop LDB related code (unused)

 board/wandboard/wandboard.c | 165 +---
 include/configs/wandboard.h |  36 +-
 2 files changed, 174 insertions(+), 27 deletions(-)

diff --git a/board/wandboard/wandboard.c b/board/wandboard/wandboard.c
index f1951dc..d88e9b7 100644
--- a/board/wandboard/wandboard.c
+++ b/board/wandboard/wandboard.c
@@ -1,5 +1,6 @@
 /*
  * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2014 O.S. Systems Software LTDA.
  *
  * Author: Fabio Estevam fabio.este...@freescale.com
  *
@@ -15,18 +16,19 @@
 #include asm/arch/sys_proto.h
 #include asm/gpio.h
 #include asm/imx-common/iomux-v3.h
+#include asm/imx-common/mxc_i2c.h
 #include asm/imx-common/boot_mode.h
+#include asm/imx-common/video.h
 #include asm/io.h
 #include linux/sizes.h
 #include common.h
 #include fsl_esdhc.h
-#include ipu_pixfmt.h
 #include mmc.h
 #include miiphy.h
 #include netdev.h
-#include linux/fb.h
 #include phy.h
 #include input.h
+#include i2c.h
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -41,6 +43,10 @@ DECLARE_GLOBAL_DATA_PTR;
 #define ENET_PAD_CTRL  (PAD_CTL_PUS_100K_UP |  \
PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
 
+#define I2C_PAD_CTRL   (PAD_CTL_PUS_100K_UP |  \
+   PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS |   \
+   PAD_CTL_ODE | PAD_CTL_SRE_FAST)
+
 #define USDHC1_CD_GPIO IMX_GPIO_NR(1, 2)
 #define USDHC3_CD_GPIO IMX_GPIO_NR(3, 9)
 #define ETH_PHY_RESET  IMX_GPIO_NR(3, 29)
@@ -210,41 +216,124 @@ int board_phy_config(struct phy_device *phydev)
 }
 
 #if defined(CONFIG_VIDEO_IPUV3)
-static struct fb_videomode const hdmi = {
-   .name   = HDMI,
-   .refresh= 60,
-   .xres   = 1024,
-   .yres   = 768,
-   .pixclock   = 15385,
-   .left_margin= 220,
-   .right_margin   = 40,
-   .upper_margin   = 21,
-   .lower_margin   = 7,
-   .hsync_len  = 60,
-   .vsync_len  = 10,
-   .sync   = FB_SYNC_EXT,
-   .vmode  = FB_VMODE_NONINTERLACED
+struct i2c_pads_info i2c2_pad_info = {
+   .scl = {
+   .i2c_mode = MX6_PAD_KEY_COL3__I2C2_SCL
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gpio_mode = MX6_PAD_KEY_COL3__GPIO4_IO12
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gp = IMX_GPIO_NR(4, 12)
+   },
+   .sda = {
+   .i2c_mode = MX6_PAD_KEY_ROW3__I2C2_SDA
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gpio_mode = MX6_PAD_KEY_ROW3__GPIO4_IO13
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gp = IMX_GPIO_NR(4, 13)
+   }
 };
 
-int board_video_skip(void)
-{
-   int ret;
+static iomux_v3_cfg_t const fwadapt_7wvga_pads[] = {
+   MX6_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK,
+   MX6_PAD_DI0_PIN2__IPU1_DI0_PIN02, /* HSync */
+   MX6_PAD_DI0_PIN3__IPU1_DI0_PIN03, /* VSync */
+   MX6_PAD_DI0_PIN4__IPU1_DI0_PIN04
+   | MUX_PAD_CTRL(PAD_CTL_DSE_120ohm), /* Contrast */
+   MX6_PAD_DI0_PIN15__IPU1_DI0_PIN15, /* DISP0_DRDY */
+
+   MX6_PAD_DISP0_DAT0__IPU1_DISP0_DATA00,
+   MX6_PAD_DISP0_DAT1__IPU1_DISP0_DATA01,
+   MX6_PAD_DISP0_DAT2__IPU1_DISP0_DATA02,
+   MX6_PAD_DISP0_DAT3__IPU1_DISP0_DATA03,
+   MX6_PAD_DISP0_DAT4__IPU1_DISP0_DATA04,
+   MX6_PAD_DISP0_DAT5__IPU1_DISP0_DATA05,
+   MX6_PAD_DISP0_DAT6__IPU1_DISP0_DATA06,
+   MX6_PAD_DISP0_DAT7__IPU1_DISP0_DATA07,
+   MX6_PAD_DISP0_DAT8__IPU1_DISP0_DATA08,
+   MX6_PAD_DISP0_DAT9__IPU1_DISP0_DATA09,
+   MX6_PAD_DISP0_DAT10__IPU1_DISP0_DATA10,
+   MX6_PAD_DISP0_DAT11__IPU1_DISP0_DATA11,
+   MX6_PAD_DISP0_DAT12__IPU1_DISP0_DATA12,
+   MX6_PAD_DISP0_DAT13__IPU1_DISP0_DATA13,
+   MX6_PAD_DISP0_DAT14__IPU1_DISP0_DATA14,
+   MX6_PAD_DISP0_DAT15__IPU1_DISP0_DATA15,
+   MX6_PAD_DISP0_DAT16__IPU1_DISP0_DATA16,
+   MX6_PAD_DISP0_DAT17__IPU1_DISP0_DATA17,
+
+   MX6_PAD_SD4_DAT2__GPIO2_IO10
+   | MUX_PAD_CTRL(NO_PAD_CTRL), /* DISP0_BKLEN */
+   MX6_PAD_SD4_DAT3__GPIO2_IO11
+   | MUX_PAD_CTRL(NO_PAD_CTRL), /* DISP0_VDDEN */
+};
 
-   ret = ipuv3_fb_init(hdmi, 0, IPU_PIX_FMT_RGB24);
+static void do_enable_hdmi(struct display_info_t const *dev)
+{
+   imx_enable_hdmi_phy();
+}
 
-   if (ret) {
-   printf(HDMI cannot be configured: %d\n, ret);
-   return ret;
-   }
+static int detect_i2c(struct display_info_t const *dev)
+{
+   return (0 ==

Re: [U-Boot] [Patch v3 1/2] common/board_f: Preserve early global data

On Thu, 2014-05-01 at 14:29 -0700, York Sun wrote:
 On 05/01/2014 02:21 PM, Scott Wood wrote:
  On Thu, 2014-05-01 at 14:16 -0700, York Sun wrote:
  On 05/01/2014 08:54 AM, Simon Glass wrote:
  Hi York,
 
  On 30 April 2014 18:01, York Sun york...@freescale.com wrote:
  Some platforms (including mpc85xx, mpc86xx) use global data before 
  calling
  function baord_inti_f(). This data should not be cleared later. Any arch
  which needs to preserve global data should define CONFIG_SYS_EARLY_GD.
 
  Signed-off-by: York Sun york...@freescale.com
  CC: Scott Wood scottw...@freescale.com
  CC: Simon Glass s...@chromium.org
  ---
  Change log
 
   v3: Introduce CONFIG_SYS_EARLY_GD instead of using a list
   v2: Instead of adding back gd init for all PPC, preserve gd for mpc85xx 
  and mpc86xx.
 
   README|3 +++
   arch/powerpc/include/asm/config.h |2 ++
   arch/x86/include/asm/config.h |1 +
   common/board_f.c  |   10 +-
   4 files changed, 11 insertions(+), 5 deletions(-)
 
  diff --git a/README b/README
  index 12758dc..1a51b11 100644
  --- a/README
  +++ b/README
  @@ -440,6 +440,9 @@ The following options need to be configured:
  supported, core will start to execute uboot when wakes 
  up.
 
   - Generic CPU options:
  +   CONFIG_SYS_EARLY_GD
  +   Defines global data is used before board_init_f().
  +
 
  This looks like a good solution, but I believe that 'early' is in fact
  where we are headed. So perhaps you should create an inverted option
  and define it for archs that don't support it?
 
  I don't disagree for the long term. But since we just start to convert to
  generic board, fewer archs need this than those don't. I suggest we try 
  this and
  when most archs convert to generic board, we can invert it if needed.
  
  Why wait to do it right?  Which arches actually don't need this, given
  that Simon said he thinks ARM needs it as well?
  
 
 Adding something I can't test?

By that rationale nobody could ever make changes that aren't localized
to a few boards.  That type of development produces the sort of mess
that the generic board is meant to remedy.

 Even Simon said he thinks ARM needs it, it is not what current code has. If I
 revert this logic,
 
 #ifdef CONFIG_SYS_GLOBAL_DATA_STACK

This looks like a global stack of data, not global data on the stack.

How about CONFIG_SYS_GENERIC_GLOBAL_DATA?

gd_dt data;
 
gd = data;
zero_global_data();
 #endif
 
 I need to add #define CONFIG_SYS_GLOBAL_DATA_STACK to the board/arch who needs
 it. I have no idea which needs in the 70+ boards with CONFIG_DISPLAY_BOARDINFO
 defined.

I see only 10 boards that currently use CONFIG_SYS_GENERIC_BOARD in
include/configs, plus sandbox and x86 which hide it in config.mk.  I
don't know what CONFIG_DISPLAY_BOARDINFO has to do with it.  To invert
the symbol, add the new symbol to all of the current users.  Removal
from ARM boards can come afterward if it's confirmed that it's the right
thing to do.

-Scott


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

[U-Boot] [PATCH] usb: ums: add error handling for failed registration

From: Stephen Warren swar...@nvidia.com

Without this, if g_dnl_register() fails, the UMS code continues on
blindly and crashes. This fix makes it simply print an error message
instead.

Signed-off-by: Stephen Warren swar...@nvidia.com
---
 common/cmd_usb_mass_storage.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/common/cmd_usb_mass_storage.c b/common/cmd_usb_mass_storage.c
index d8d9efd4f62b..31b7eb0b57ef 100644
--- a/common/cmd_usb_mass_storage.c
+++ b/common/cmd_usb_mass_storage.c
@@ -40,7 +40,11 @@ int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
return CMD_RET_FAILURE;
}
 
-   g_dnl_register(usb_dnl_ums);
+   rc = g_dnl_register(usb_dnl_ums);
+   if (rc) {
+   error(g_dnl_register failed);
+   return CMD_RET_FAILURE;
+   }
 
/* Timeout unit: seconds */
int cable_ready_timeout = UMS_CABLE_READY_TIMEOUT;
-- 
1.8.1.5

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

[U-Boot] [PATCH] USB: gadget: save driver name before registering it

From: Stephen Warren swar...@nvidia.com

g_dnl_register() currently first attempts to register a composite
driver by name, and then saves the driver name once it's registered.
Internally to the registration code, g_dnl_do_config() is called and
attempts to compare the composite device's name with the list of known
device names. This fails since the composite device's name has not yet
been stored. This means that the first time ums 0 0 is run, it fails,
but subsequent attempts succeed.

Re-order the name-saving and registration code to solve this.

Fixes: e5b834e07f51 (USB: gadget: added a saner gadget downloader registration 
API)
Signed-off-by: Stephen Warren swar...@nvidia.com
---
This should likely be applied to u-boot-dfu/master along with Mateusz's
original patch, or folded into it.

 drivers/usb/gadget/g_dnl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index 743bae535ac8..25611acd607f 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -245,11 +245,12 @@ static struct usb_composite_driver g_dnl_driver = {
  */
 int g_dnl_register(const char *name)
 {
-   int ret = usb_composite_register(g_dnl_driver);
+   int ret;
 
debug(%s: g_dnl_driver.name = %s\n, __func__, name);
g_dnl_driver.name = name;
 
+   ret = usb_composite_register(g_dnl_driver);
if (ret) {
printf(%s: failed!, error: %d\n, __func__, ret);
return ret;
-- 
1.8.1.5

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

Re: [U-Boot] [PATCH 7/8] ums: move all variable declarations to the start of the block

On 05/01/2014 01:43 PM, Lukasz Majewski wrote:
 Hi Stephen,
 

 On 05/01/2014 04:51 AM, Marek Vasut wrote:
 On Wednesday, April 30, 2014 at 11:13:21 PM, Stephen Warren wrote:
 From: Stephen Warren swar...@nvidia.com

 It's easier to assign values to the variables inside an if
 statement body if the assignment and declaration are separate.

 Cc: Przemyslaw Marczak p.marc...@samsung.com
 Cc: Lukasz Majewski l.majew...@samsung.com
 Signed-off-by: Stephen Warren swar...@nvidia.com
 ---
  common/cmd_usb_mass_storage.c | 24 
  1 file changed, 16 insertions(+), 8 deletions(-)

 This doesn't apply on u-boot-usb/master, sorry.

 Is this the first patch in the series which doesn't apply? Did you
 apply any of the earlier patches? I guess I'll go try to rebase the
 series and find out myself...

 This is why we need a uboot-next just like linux-next, and stricter
 controls on which git repos take patches that touch subsystem code, to
 avoid cross-repo conflicts:-(
 
 +1
 
 Yesterday Marek and I agreed that some patches regarding DFU and
 gadgets (patches 1 to 8) done by Mateusz:
 
 http://patchwork.ozlabs.org/patch/343517/
 
 will be go through u-boot-dfu tree, which will be rebased on top of
 u-boot-usb tree. Afterwards I will send PR to Marek.
 
 Unfortunately I didn't manage to add them to u-boot-denx tree yesterday.
 I will do it on Monday as well as the review regarding your ums work. I
 hope, that you can wait until then.

OK, that's fine.

FWIW, I have applied that series locally and rebased my patches on top
of it. If you want to see the latest version, feel free to look at:

git://github.com/swarren/u-boot.git tegra_dev

Note that branch gets rebased as I do local development.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] wandboard: add Future Eletronics 7 WVGA LCD extension board

2014-05-01 Thread Fabio Estevam

On Thu, May 1, 2014 at 6:35 PM, Otavio Salvador ota...@ossystems.com.br wrote:

  static void setup_display(void)
  {
 struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
 +   struct iomuxc *iomux = (struct iomuxc *)IOMUXC_BASE_ADDR;
 int reg;

 enable_ipu_clock();
 @@ -254,6 +343,28 @@ static void setup_display(void)
 reg |= (CHSCCDR_CLK_SEL_LDB_DI0
  MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_OFFSET);
 writel(reg, mxc_ccm-chsccdr);
 +
 +   reg = IOMUXC_GPR2_BGREF_RRMODE_EXTERNAL_RES
 +| IOMUXC_GPR2_DI1_VS_POLARITY_ACTIVE_LOW
 +| IOMUXC_GPR2_DI0_VS_POLARITY_ACTIVE_LOW
 +| IOMUXC_GPR2_BIT_MAPPING_CH1_SPWG
 +| IOMUXC_GPR2_DATA_WIDTH_CH1_18BIT
 +| IOMUXC_GPR2_BIT_MAPPING_CH0_SPWG
 +| IOMUXC_GPR2_DATA_WIDTH_CH0_18BIT
 +| IOMUXC_GPR2_LVDS_CH0_MODE_DISABLED
 +| IOMUXC_GPR2_LVDS_CH1_MODE_ENABLED_DI0;
 +   writel(reg, iomux-gpr[2]);

This is all LVDS related and the LCD you are adding is not a LVDS.

 +
 +   reg = readl(iomux-gpr[3]);
 +   reg = (reg  ~(IOMUXC_GPR3_LVDS1_MUX_CTL_MASK
 +   | IOMUXC_GPR3_HDMI_MUX_CTL_MASK))
 +   | (IOMUXC_GPR3_MUX_SRC_IPU1_DI0
 +   IOMUXC_GPR3_LVDS1_MUX_CTL_OFFSET);
 +   writel(reg, iomux-gpr[3]);

Same here.

  #if defined(CONFIG_MX6DL) || defined(CONFIG_MX6S)
  #define CONFIG_DEFAULT_FDT_FILEimx6dl-wandboard.dtb
 @@ -152,7 +160,33 @@
 fi;   \
 fi\0 \
 mmcargs=setenv bootargs console=${console},${baudrate}  \
 -   root=${mmcroot}\0 \
 +   root=${mmcroot}; run videoargs\0 \
 +   videoargs= \
 +   setenv nextcon 0;  \
 +   if hdmidet; then  \
 +   setenv bootargs ${bootargs}  \
 +   
 video=mxcfb${nextcon}:dev=hdmi,1280x720M@60, \
 +   if=RGB24;  \

This is unrelated to adding a LVDS display and would be better handled
on a separate patch.

 +   setenv fbmen fbmem=28M;  \
 +   setexpr nextcon ${nextcon} + 1;  \
 +   else  \
 +   echo - no HDMI monitor; \
 +   fi;  \
 +   i2c dev 1;  \
 +   if i2c probe 0x10; then  \
 +   setenv bootargs ${bootargs}  \
 +   video=mxcfb${nextcon}:dev=lcd,800x480@60, \
 +   if=RGB666;  \
 +   if test 0 -eq ${nextcon}; then  \
 +   setenv fbmem fbmem=10M;  \
 +   else  \
 +   setenv fbmem ${fbmem},10M;  \
 +   fi;  \
 +   setexpr nextcon ${nextcon} + 1;  \
 +   else  \
 +   echo '- no FWBADAPT-7WVGA-LCD-F07A-0102 display'; \
 +   fi;  \
 +   setenv bootargs ${bootargs} ${fbmem}\0 \

Changing the environment variables would be more appropriate on a
separate patch, but still don't like the idea of hardcoding the video
argument specific to a FSL kernel version.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Patch v3 1/2] common/board_f: Preserve early global data

2014-05-01 Thread Simon Glass

+Albert

Hi,

On 1 May 2014 15:41, Scott Wood scottw...@freescale.com wrote:
 On Thu, 2014-05-01 at 14:29 -0700, York Sun wrote:
 On 05/01/2014 02:21 PM, Scott Wood wrote:
  On Thu, 2014-05-01 at 14:16 -0700, York Sun wrote:
  On 05/01/2014 08:54 AM, Simon Glass wrote:
  Hi York,
 
  On 30 April 2014 18:01, York Sun york...@freescale.com wrote:
  Some platforms (including mpc85xx, mpc86xx) use global data before 
  calling
  function baord_inti_f(). This data should not be cleared later. Any arch
  which needs to preserve global data should define CONFIG_SYS_EARLY_GD.
 
  Signed-off-by: York Sun york...@freescale.com
  CC: Scott Wood scottw...@freescale.com
  CC: Simon Glass s...@chromium.org
  ---
  Change log
 
   v3: Introduce CONFIG_SYS_EARLY_GD instead of using a list
   v2: Instead of adding back gd init for all PPC, preserve gd for 
  mpc85xx and mpc86xx.
 
   README|3 +++
   arch/powerpc/include/asm/config.h |2 ++
   arch/x86/include/asm/config.h |1 +
   common/board_f.c  |   10 +-
   4 files changed, 11 insertions(+), 5 deletions(-)
 
  diff --git a/README b/README
  index 12758dc..1a51b11 100644
  --- a/README
  +++ b/README
  @@ -440,6 +440,9 @@ The following options need to be configured:
  supported, core will start to execute uboot when wakes 
  up.
 
   - Generic CPU options:
  +   CONFIG_SYS_EARLY_GD
  +   Defines global data is used before board_init_f().
  +
 
  This looks like a good solution, but I believe that 'early' is in fact
  where we are headed. So perhaps you should create an inverted option
  and define it for archs that don't support it?
 
  I don't disagree for the long term. But since we just start to convert to
  generic board, fewer archs need this than those don't. I suggest we try 
  this and
  when most archs convert to generic board, we can invert it if needed.
 
  Why wait to do it right?  Which arches actually don't need this, given
  that Simon said he thinks ARM needs it as well?

Thanks for working on this, York.

I looked at ARM and I think it is similar. See arch/arm/lib/crt0.S. It
sets up gd - the only problem is that it does not zero the area
unfortunately. But once that is added we can switch ARM over.

 

 Adding something I can't test?

 By that rationale nobody could ever make changes that aren't localized
 to a few boards.  That type of development produces the sort of mess
 that the generic board is meant to remedy.

 Even Simon said he thinks ARM needs it, it is not what current code has. If I
 revert this logic,

 #ifdef CONFIG_SYS_GLOBAL_DATA_STACK

 This looks like a global stack of data, not global data on the stack.

 How about CONFIG_SYS_GENERIC_GLOBAL_DATA?

gd_dt data;

gd = data;
zero_global_data();
 #endif

 I need to add #define CONFIG_SYS_GLOBAL_DATA_STACK to the board/arch who 
 needs
 it. I have no idea which needs in the 70+ boards with 
 CONFIG_DISPLAY_BOARDINFO
 defined.

 I see only 10 boards that currently use CONFIG_SYS_GENERIC_BOARD in
 include/configs, plus sandbox and x86 which hide it in config.mk.  I
 don't know what CONFIG_DISPLAY_BOARDINFO has to do with it.  To invert
 the symbol, add the new symbol to all of the current users.  Removal
 from ARM boards can come afterward if it's confirmed that it's the right
 thing to do.

SGTM.

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

[U-Boot] [PATCH v3 1/2] wandboard: add Future Eletronics 7 WVGA LCD extension board

This adds support for the 7 WVGA produced by Future Eletronics and
make it dynamically detect if it is connected or not based on the
touchscreen controller.

Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---

Changes in v3:
- Drop LVDS related code (unused)

Changes in v2:
- Drop LDB related code (unused)

 board/wandboard/wandboard.c | 147 
 include/configs/wandboard.h |   7 +++
 2 files changed, 128 insertions(+), 26 deletions(-)

diff --git a/board/wandboard/wandboard.c b/board/wandboard/wandboard.c
index f1951dc..311a442 100644
--- a/board/wandboard/wandboard.c
+++ b/board/wandboard/wandboard.c
@@ -1,5 +1,6 @@
 /*
  * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2014 O.S. Systems Software LTDA.
  *
  * Author: Fabio Estevam fabio.este...@freescale.com
  *
@@ -15,18 +16,19 @@
 #include asm/arch/sys_proto.h
 #include asm/gpio.h
 #include asm/imx-common/iomux-v3.h
+#include asm/imx-common/mxc_i2c.h
 #include asm/imx-common/boot_mode.h
+#include asm/imx-common/video.h
 #include asm/io.h
 #include linux/sizes.h
 #include common.h
 #include fsl_esdhc.h
-#include ipu_pixfmt.h
 #include mmc.h
 #include miiphy.h
 #include netdev.h
-#include linux/fb.h
 #include phy.h
 #include input.h
+#include i2c.h
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -41,6 +43,10 @@ DECLARE_GLOBAL_DATA_PTR;
 #define ENET_PAD_CTRL  (PAD_CTL_PUS_100K_UP |  \
PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
 
+#define I2C_PAD_CTRL   (PAD_CTL_PUS_100K_UP |  \
+   PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS |   \
+   PAD_CTL_ODE | PAD_CTL_SRE_FAST)
+
 #define USDHC1_CD_GPIO IMX_GPIO_NR(1, 2)
 #define USDHC3_CD_GPIO IMX_GPIO_NR(3, 9)
 #define ETH_PHY_RESET  IMX_GPIO_NR(3, 29)
@@ -210,41 +216,124 @@ int board_phy_config(struct phy_device *phydev)
 }
 
 #if defined(CONFIG_VIDEO_IPUV3)
-static struct fb_videomode const hdmi = {
-   .name   = HDMI,
-   .refresh= 60,
-   .xres   = 1024,
-   .yres   = 768,
-   .pixclock   = 15385,
-   .left_margin= 220,
-   .right_margin   = 40,
-   .upper_margin   = 21,
-   .lower_margin   = 7,
-   .hsync_len  = 60,
-   .vsync_len  = 10,
-   .sync   = FB_SYNC_EXT,
-   .vmode  = FB_VMODE_NONINTERLACED
+struct i2c_pads_info i2c2_pad_info = {
+   .scl = {
+   .i2c_mode = MX6_PAD_KEY_COL3__I2C2_SCL
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gpio_mode = MX6_PAD_KEY_COL3__GPIO4_IO12
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gp = IMX_GPIO_NR(4, 12)
+   },
+   .sda = {
+   .i2c_mode = MX6_PAD_KEY_ROW3__I2C2_SDA
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gpio_mode = MX6_PAD_KEY_ROW3__GPIO4_IO13
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gp = IMX_GPIO_NR(4, 13)
+   }
 };
 
-int board_video_skip(void)
-{
-   int ret;
+static iomux_v3_cfg_t const fwadapt_7wvga_pads[] = {
+   MX6_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK,
+   MX6_PAD_DI0_PIN2__IPU1_DI0_PIN02, /* HSync */
+   MX6_PAD_DI0_PIN3__IPU1_DI0_PIN03, /* VSync */
+   MX6_PAD_DI0_PIN4__IPU1_DI0_PIN04
+   | MUX_PAD_CTRL(PAD_CTL_DSE_120ohm), /* Contrast */
+   MX6_PAD_DI0_PIN15__IPU1_DI0_PIN15, /* DISP0_DRDY */
+
+   MX6_PAD_DISP0_DAT0__IPU1_DISP0_DATA00,
+   MX6_PAD_DISP0_DAT1__IPU1_DISP0_DATA01,
+   MX6_PAD_DISP0_DAT2__IPU1_DISP0_DATA02,
+   MX6_PAD_DISP0_DAT3__IPU1_DISP0_DATA03,
+   MX6_PAD_DISP0_DAT4__IPU1_DISP0_DATA04,
+   MX6_PAD_DISP0_DAT5__IPU1_DISP0_DATA05,
+   MX6_PAD_DISP0_DAT6__IPU1_DISP0_DATA06,
+   MX6_PAD_DISP0_DAT7__IPU1_DISP0_DATA07,
+   MX6_PAD_DISP0_DAT8__IPU1_DISP0_DATA08,
+   MX6_PAD_DISP0_DAT9__IPU1_DISP0_DATA09,
+   MX6_PAD_DISP0_DAT10__IPU1_DISP0_DATA10,
+   MX6_PAD_DISP0_DAT11__IPU1_DISP0_DATA11,
+   MX6_PAD_DISP0_DAT12__IPU1_DISP0_DATA12,
+   MX6_PAD_DISP0_DAT13__IPU1_DISP0_DATA13,
+   MX6_PAD_DISP0_DAT14__IPU1_DISP0_DATA14,
+   MX6_PAD_DISP0_DAT15__IPU1_DISP0_DATA15,
+   MX6_PAD_DISP0_DAT16__IPU1_DISP0_DATA16,
+   MX6_PAD_DISP0_DAT17__IPU1_DISP0_DATA17,
+
+   MX6_PAD_SD4_DAT2__GPIO2_IO10
+   | MUX_PAD_CTRL(NO_PAD_CTRL), /* DISP0_BKLEN */
+   MX6_PAD_SD4_DAT3__GPIO2_IO11
+   | MUX_PAD_CTRL(NO_PAD_CTRL), /* DISP0_VDDEN */
+};
 
-   ret = ipuv3_fb_init(hdmi, 0, IPU_PIX_FMT_RGB24);
+static void do_enable_hdmi(struct display_info_t const *dev)
+{
+   imx_enable_hdmi_phy();
+}
 
-   if (ret) {
-   printf(HDMI cannot be configured: %d\n, ret);
-   return ret;
-   }
+static int detect_i2c(struct display_info_t const *dev)
+{
+   return (0 == i2c_set_bus_num(dev-bus)) 
+   (0 == i2c_probe(dev-addr));
+}
 
-   imx_enable_hdmi_phy();
+static void

[U-Boot] [PATCH v3 2/2] wandboard: Pass video kernel arguments for HDMI and LCD

This checks if the 7 WVGA produced by Future Eletronics is detected
and pass the needed kernel arguments for it to work.

Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---

Changes in v3:
- New patch

Changes in v2: None

 include/configs/wandboard.h | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index 6defc00..ac78ede 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -121,6 +121,7 @@
 #define CONFIG_VIDEO_LOGO
 #define CONFIG_VIDEO_BMP_LOGO
 #define CONFIG_IPUV3_CLK 26000
+#define CONFIG_CMD_HDMIDETECT
 #define CONFIG_IMX_HDMI
 #define CONFIG_IMX_VIDEO_SKIP
 
@@ -159,7 +160,33 @@
fi;   \
fi\0 \
mmcargs=setenv bootargs console=${console},${baudrate}  \
-   root=${mmcroot}\0 \
+   root=${mmcroot}; run videoargs\0 \
+   videoargs= \
+   setenv nextcon 0;  \
+   if hdmidet; then  \
+   setenv bootargs ${bootargs}  \
+   video=mxcfb${nextcon}:dev=hdmi,1280x720M@60, \
+   if=RGB24;  \
+   setenv fbmen fbmem=28M;  \
+   setexpr nextcon ${nextcon} + 1;  \
+   else  \
+   echo - no HDMI monitor; \
+   fi;  \
+   i2c dev 1;  \
+   if i2c probe 0x10; then  \
+   setenv bootargs ${bootargs}  \
+   video=mxcfb${nextcon}:dev=lcd,800x480@60, \
+   if=RGB666;  \
+   if test 0 -eq ${nextcon}; then  \
+   setenv fbmem fbmem=10M;  \
+   else  \
+   setenv fbmem ${fbmem},10M;  \
+   fi;  \
+   setexpr nextcon ${nextcon} + 1;  \
+   else  \
+   echo '- no FWBADAPT-7WVGA-LCD-F07A-0102 display'; \
+   fi;  \
+   setenv bootargs ${bootargs} ${fbmem}\0 \
loadbootscript= \
fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0 \
bootscript=echo Running bootscript from mmc ...;  \
-- 
2.0.0.rc0

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

Re: [U-Boot] [PATCH v2] wandboard: add Future Eletronics 7 WVGA LCD extension board

Hello Fabio,

On Thu, May 1, 2014 at 6:48 PM, Fabio Estevam feste...@gmail.com wrote:
 On Thu, May 1, 2014 at 6:35 PM, Otavio Salvador ota...@ossystems.com.br 
 wrote:

  static void setup_display(void)
  {
 struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
 +   struct iomuxc *iomux = (struct iomuxc *)IOMUXC_BASE_ADDR;
 int reg;

 enable_ipu_clock();
 @@ -254,6 +343,28 @@ static void setup_display(void)
 reg |= (CHSCCDR_CLK_SEL_LDB_DI0
  MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_OFFSET);
 writel(reg, mxc_ccm-chsccdr);
 +
 +   reg = IOMUXC_GPR2_BGREF_RRMODE_EXTERNAL_RES
 +| IOMUXC_GPR2_DI1_VS_POLARITY_ACTIVE_LOW
 +| IOMUXC_GPR2_DI0_VS_POLARITY_ACTIVE_LOW
 +| IOMUXC_GPR2_BIT_MAPPING_CH1_SPWG
 +| IOMUXC_GPR2_DATA_WIDTH_CH1_18BIT
 +| IOMUXC_GPR2_BIT_MAPPING_CH0_SPWG
 +| IOMUXC_GPR2_DATA_WIDTH_CH0_18BIT
 +| IOMUXC_GPR2_LVDS_CH0_MODE_DISABLED
 +| IOMUXC_GPR2_LVDS_CH1_MODE_ENABLED_DI0;
 +   writel(reg, iomux-gpr[2]);

 This is all LVDS related and the LCD you are adding is not a LVDS.

 +
 +   reg = readl(iomux-gpr[3]);
 +   reg = (reg  ~(IOMUXC_GPR3_LVDS1_MUX_CTL_MASK
 +   | IOMUXC_GPR3_HDMI_MUX_CTL_MASK))
 +   | (IOMUXC_GPR3_MUX_SRC_IPU1_DI0
 +   IOMUXC_GPR3_LVDS1_MUX_CTL_OFFSET);
 +   writel(reg, iomux-gpr[3]);

 Same here.

  #if defined(CONFIG_MX6DL) || defined(CONFIG_MX6S)
  #define CONFIG_DEFAULT_FDT_FILEimx6dl-wandboard.dtb
 @@ -152,7 +160,33 @@
 fi;   \
 fi\0 \
 mmcargs=setenv bootargs console=${console},${baudrate}  \
 -   root=${mmcroot}\0 \
 +   root=${mmcroot}; run videoargs\0 \
 +   videoargs= \
 +   setenv nextcon 0;  \
 +   if hdmidet; then  \
 +   setenv bootargs ${bootargs}  \
 +   
 video=mxcfb${nextcon}:dev=hdmi,1280x720M@60, \
 +   if=RGB24;  \

 This is unrelated to adding a LVDS display and would be better handled
 on a separate patch.

 +   setenv fbmen fbmem=28M;  \
 +   setexpr nextcon ${nextcon} + 1;  \
 +   else  \
 +   echo - no HDMI monitor; \
 +   fi;  \
 +   i2c dev 1;  \
 +   if i2c probe 0x10; then  \
 +   setenv bootargs ${bootargs}  \
 +   video=mxcfb${nextcon}:dev=lcd,800x480@60, \
 +   if=RGB666;  \
 +   if test 0 -eq ${nextcon}; then  \
 +   setenv fbmem fbmem=10M;  \
 +   else  \
 +   setenv fbmem ${fbmem},10M;  \
 +   fi;  \
 +   setexpr nextcon ${nextcon} + 1;  \
 +   else  \
 +   echo '- no FWBADAPT-7WVGA-LCD-F07A-0102 display'; \
 +   fi;  \
 +   setenv bootargs ${bootargs} ${fbmem}\0 \

 Changing the environment variables would be more appropriate on a
 separate patch, but still don't like the idea of hardcoding the video
 argument specific to a FSL kernel version.

I hope to have handled all the comments in v3 :-)

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Patch v3 1/2] common/board_f: Preserve early global data

On 05/01/2014 02:41 PM, Scott Wood wrote:
 On Thu, 2014-05-01 at 14:29 -0700, York Sun wrote:
 On 05/01/2014 02:21 PM, Scott Wood wrote:
 On Thu, 2014-05-01 at 14:16 -0700, York Sun wrote:
 On 05/01/2014 08:54 AM, Simon Glass wrote:
 Hi York,

 On 30 April 2014 18:01, York Sun york...@freescale.com wrote:
 Some platforms (including mpc85xx, mpc86xx) use global data before 
 calling
 function baord_inti_f(). This data should not be cleared later. Any arch
 which needs to preserve global data should define CONFIG_SYS_EARLY_GD.

 Signed-off-by: York Sun york...@freescale.com
 CC: Scott Wood scottw...@freescale.com
 CC: Simon Glass s...@chromium.org
 ---
 Change log

  v3: Introduce CONFIG_SYS_EARLY_GD instead of using a list
  v2: Instead of adding back gd init for all PPC, preserve gd for mpc85xx 
 and mpc86xx.

  README|3 +++
  arch/powerpc/include/asm/config.h |2 ++
  arch/x86/include/asm/config.h |1 +
  common/board_f.c  |   10 +-
  4 files changed, 11 insertions(+), 5 deletions(-)

 diff --git a/README b/README
 index 12758dc..1a51b11 100644
 --- a/README
 +++ b/README
 @@ -440,6 +440,9 @@ The following options need to be configured:
 supported, core will start to execute uboot when wakes 
 up.

  - Generic CPU options:
 +   CONFIG_SYS_EARLY_GD
 +   Defines global data is used before board_init_f().
 +

 This looks like a good solution, but I believe that 'early' is in fact
 where we are headed. So perhaps you should create an inverted option
 and define it for archs that don't support it?

 I don't disagree for the long term. But since we just start to convert to
 generic board, fewer archs need this than those don't. I suggest we try 
 this and
 when most archs convert to generic board, we can invert it if needed.

 Why wait to do it right?  Which arches actually don't need this, given
 that Simon said he thinks ARM needs it as well?


 Adding something I can't test?
 
 By that rationale nobody could ever make changes that aren't localized
 to a few boards.  That type of development produces the sort of mess
 that the generic board is meant to remedy.
 
 Even Simon said he thinks ARM needs it, it is not what current code has. If I
 revert this logic,

 #ifdef CONFIG_SYS_GLOBAL_DATA_STACK
 
 This looks like a global stack of data, not global data on the stack.
 
 How about CONFIG_SYS_GENERIC_GLOBAL_DATA?
 
gd_dt data;

gd = data;
zero_global_data();
 #endif

 I need to add #define CONFIG_SYS_GLOBAL_DATA_STACK to the board/arch who 
 needs
 it. I have no idea which needs in the 70+ boards with 
 CONFIG_DISPLAY_BOARDINFO
 defined.
 
 I see only 10 boards that currently use CONFIG_SYS_GENERIC_BOARD in
 include/configs, plus sandbox and x86 which hide it in config.mk.  I
 don't know what CONFIG_DISPLAY_BOARDINFO has to do with it.  To invert
 the symbol, add the new symbol to all of the current users.  Removal
 from ARM boards can come afterward if it's confirmed that it's the right
 thing to do.

I made a typo when I search it. Yes, it is only 10 boards. I can add the new
macro to their arch header file.

York


York

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

Re: [U-Boot] Possible race condition when accessing SPI NOR Flash ?

2014-05-01 Thread Wolfgang Denk

Dear Valentin,

In message 53623597.8040...@keymile.com you wrote:

 Now when fw_setenv ([1], [2]) updates the environment variables, it sometimes
 (approximately 1 out of 100 runs) triggers such kernel errors:
...
 I see the same behavior with both the 2013.10 and the 2014.04 releases of
 u-boot/fw_env. The kernel we are using is 3.10.36.
 
 I suspect that the problem is related to SPI NOR/m25p80 driver: on the system 
 we
 have a NAND Flash device with UBI volumes. If I create 2 ubi volumes on the 
 NAND
 Flash and configure fw_setenv (/etc/fw_env.config) to use them instead of the
 the mtd devices targetting the s25fl256s1, I am not able to reproduce the
 problem, even over more than 10'000 runs.

Um... this is _Linux_ crashing - at this point the U-Boot driver has
nothing to do with it..  If there is a problem, then with the Linux
kernel / driver code.  I guess you should rather post this on the MTD
mailing ist.

 One other possible culprit that I see is the fsl_espi.c driver for the
 underlying hardware connection from the CPU to the NOR Flash, but I wanted to
 ask here if someone had an idea about what's going wrong.

It's Linux code

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Don't hit a man when he's down - kick him; it's easier.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 03/11] kconfig: add board Kconfig and defconfig files

On Mon, 2014-04-28 at 11:47 -0600, Stephen Warren wrote:
 I guess the main issue I see here is that all the HW-configuration needs
 to be repeated in seaboard_defconfig and spl/seaboard_defconfig.
 
 (As an aside, if there's nothing special about SPL-vs-not and they're
 just different builds of U-Boot, why put the SPL configurations into a
 special-case sub-directory, why not name them seaboard_spl_defconfig and
 seaboard_defconfig, and put them in the same configs directory).

It's special in that both configs are built and assembled into what
looks to the user like one output image.

 Can we allow one defconfig to include or inherit from another? I know
 that ChromeOS stores kernel defconfigs in split configs that build
 upon each-other. Probably, this feature comes from elsewhere, and we
 could just crib the config split/combine script for U-Boot's use.

Yes, that'd be nice.

  To make this work, we'd probably need the user to run something like:
 
 ./build-u-boot seaboard
 or:
 ./build-u-boot seaboard_spl
 
 ... rather than running make directly, so that script could generate the
 .config from a set of defconfigs, and then invoke make.

Why couldn't the makefile do this when asked to use a board's defconfig?

The user shouldn't need to know about the details of SPL or that there
are separate sub-builds.  Both seaboard and seaboard_spl would need to
be built, not one or the other.

 (as an aside, having the user run a script to build rather than make
 directly gives us a huge amount more flexibility to add run arbitrary
 code to set up the build process before invoking make. I've found this
 kind of thing extremely useful in the past on other projects).

What arbitrary code do you want to run that can't be run in the config
makefile target?  There is MAKEALL for users that want a one-step build.

-Scott


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

[U-Boot] [Patch v4 1/2] common/board_f: Initialized global data for generic board

Some platforms (tested on mpc85xx, mpc86xx) use global data before calling
function baord_inti_f(). The data should not be cleared later. Any arch
which uses global data in generic board board_init_f() should define
CONFIG_SYS_GENERIC_GLOBAL_DATA.

Signed-off-by: York Sun york...@freescale.com
CC: Scott Wood scottw...@freescale.com
CC: Simon Glass s...@chromium.org
CC: Albert ARIBAUD albert.u.b...@aribaud.net
---
Change log

 v4: Replace with CONFIG_SYS_GENERIC_GLOBAL_DATA, a positive logic
 v3: Introduce CONFIG_SYS_EARLY_GD instead of using a list
 v2: Instead of adding back gd init for all PPC, preserve gd for mpc85xx and 
mpc86xx.

 README |6 ++
 arch/arc/include/asm/config.h  |2 ++
 arch/arm/include/asm/config.h  |2 ++
 arch/mips/include/asm/config.h |2 ++
 common/board_f.c   |   12 +++-
 5 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/README b/README
index 12758dc..c66f988 100644
--- a/README
+++ b/README
@@ -440,6 +440,12 @@ The following options need to be configured:
supported, core will start to execute uboot when wakes up.
 
 - Generic CPU options:
+   CONFIG_SYS_GENERIC_GLOBAL_DATA
+   Defines global data is initialized in generic board 
board_init_f().
+   If this macro is defined, global data is created and cleared in
+   generic board board_init_f(). Without this macro, 
architecture/board
+   should initialize global data before calling board_init_f().
+
CONFIG_SYS_BIG_ENDIAN, CONFIG_SYS_LITTLE_ENDIAN
 
Defines the endianess of the CPU. Implementation of those
diff --git a/arch/arc/include/asm/config.h b/arch/arc/include/asm/config.h
index 5761def..3d331cc 100644
--- a/arch/arc/include/asm/config.h
+++ b/arch/arc/include/asm/config.h
@@ -7,6 +7,8 @@
 #ifndef __ASM_ARC_CONFIG_H_
 #define __ASM_ARC_CONFIG_H_
 
+#define CONFIG_SYS_GENERIC_GLOBAL_DATA
+
 #define CONFIG_LMB
 
 #endif /*__ASM_ARC_CONFIG_H_ */
diff --git a/arch/arm/include/asm/config.h b/arch/arm/include/asm/config.h
index abf79e5..2a20a77 100644
--- a/arch/arm/include/asm/config.h
+++ b/arch/arm/include/asm/config.h
@@ -7,6 +7,8 @@
 #ifndef _ASM_CONFIG_H_
 #define _ASM_CONFIG_H_
 
+#define CONFIG_SYS_GENERIC_GLOBAL_DATA
+
 #define CONFIG_LMB
 #define CONFIG_SYS_BOOT_RAMDISK_HIGH
 
diff --git a/arch/mips/include/asm/config.h b/arch/mips/include/asm/config.h
index 3a891ba..1c8a42b 100644
--- a/arch/mips/include/asm/config.h
+++ b/arch/mips/include/asm/config.h
@@ -7,6 +7,8 @@
 #ifndef _ASM_CONFIG_H_
 #define _ASM_CONFIG_H_
 
+#define CONFIG_SYS_GENERIC_GLOBAL_DATA
+
 #define CONFIG_LMB
 #define CONFIG_SYS_BOOT_RAMDISK_HIGH
 
diff --git a/common/board_f.c b/common/board_f.c
index cbdf06f..7601a98 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -970,20 +970,22 @@ static init_fnc_t init_sequence_f[] = {
 
 void board_init_f(ulong boot_flags)
 {
-#ifndef CONFIG_X86
+#ifdef CONFIG_SYS_GENERIC_GLOBAL_DATA
+   /*
+* For some archtectures, global data is initialized and used before
+* calling this function. The data should be preserved. For others,
+* CONFIG_SYS_GENERIC_GLOBAL_DATA should be defined and use the stack
+* here to host global data until relocation.
+*/
gd_t data;
 
gd = data;
-#endif
 
/*
 * Clear global data before it is accessed at debug print
 * in initcall_run_list. Otherwise the debug print probably
 * get the wrong vaule of gd-have_console.
 */
-#if !defined(CONFIG_CPM2)  !defined(CONFIG_MPC512X)  \
-   !defined(CONFIG_MPC83xx)  !defined(CONFIG_MPC85xx)  \
-   !defined(CONFIG_MPC86xx)  !defined(CONFIG_X86)
zero_global_data();
 #endif
 
-- 
1.7.9.5

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

[U-Boot] [Patch v4 2/2] common/board_f: Fix size variable

DRAM size should use 64-bit variable when the size could be more than 4GB.
Caught and verified on P4080DS with 4GB DDR.

Signed-off-by: York Sun york...@freescale.com
---
Change log
 v4: no change since v1

 common/board_f.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/board_f.c b/common/board_f.c
index 7601a98..c268cf9 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -194,7 +194,7 @@ static int init_func_ram(void)
 
 static int show_dram_config(void)
 {
-   ulong size;
+   unsigned long long size;
 
 #ifdef CONFIG_NR_DRAM_BANKS
int i;
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH 7/8] ums: move all variable declarations to the start of the block

2014-05-01 Thread Lukasz Majewski

Hi Stephen,

 
 On 05/01/2014 04:51 AM, Marek Vasut wrote:
  On Wednesday, April 30, 2014 at 11:13:21 PM, Stephen Warren wrote:
  From: Stephen Warren swar...@nvidia.com
 
  It's easier to assign values to the variables inside an if
  statement body if the assignment and declaration are separate.
 
  Cc: Przemyslaw Marczak p.marc...@samsung.com
  Cc: Lukasz Majewski l.majew...@samsung.com
  Signed-off-by: Stephen Warren swar...@nvidia.com
  ---
   common/cmd_usb_mass_storage.c | 24 
   1 file changed, 16 insertions(+), 8 deletions(-)
  
  This doesn't apply on u-boot-usb/master, sorry.
 
 Is this the first patch in the series which doesn't apply? Did you
 apply any of the earlier patches? I guess I'll go try to rebase the
 series and find out myself...
 
 This is why we need a uboot-next just like linux-next, and stricter
 controls on which git repos take patches that touch subsystem code, to
 avoid cross-repo conflicts:-(

+1

Yesterday Marek and I agreed that some patches regarding DFU and
gadgets (patches 1 to 8) done by Mateusz:

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

will be go through u-boot-dfu tree, which will be rebased on top of
u-boot-usb tree. Afterwards I will send PR to Marek.

Unfortunately I didn't manage to add them to u-boot-denx tree yesterday.
I will do it on Monday as well as the review regarding your ums work. I
hope, that you can wait until then.


Best regards,
Lukasz Majewski

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



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

Re: [U-Boot] [Patch v4 1/2] common/board_f: Initialized global data for generic board

2014-05-01 Thread Simon Glass

On 1 May 2014 16:00, York Sun york...@freescale.com wrote:
 Some platforms (tested on mpc85xx, mpc86xx) use global data before calling
 function baord_inti_f(). The data should not be cleared later. Any arch
 which uses global data in generic board board_init_f() should define
 CONFIG_SYS_GENERIC_GLOBAL_DATA.

 Signed-off-by: York Sun york...@freescale.com
 CC: Scott Wood scottw...@freescale.com
 CC: Simon Glass s...@chromium.org
 CC: Albert ARIBAUD albert.u.b...@aribaud.net
 ---
 Change log

  v4: Replace with CONFIG_SYS_GENERIC_GLOBAL_DATA, a positive logic
  v3: Introduce CONFIG_SYS_EARLY_GD instead of using a list
  v2: Instead of adding back gd init for all PPC, preserve gd for mpc85xx and 
 mpc86xx.

  README |6 ++
  arch/arc/include/asm/config.h  |2 ++
  arch/arm/include/asm/config.h  |2 ++
  arch/mips/include/asm/config.h |2 ++

I think you will need sandbox also. Otherwise looks good.

Reviewed-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] U-Boot, dm, ubi: struct device is declared twice

2014-05-01 Thread Heiko Schocher


Hello Simon, Marek,

just updating to current mainline code and defining
CONFIG_SYS_GENERIC_BOARD pops up the following error:

 CC  common/board_r.o
In file included from include/linux/mtd/flashchip.h:21:0,
 from include/linux/mtd/nand.h:31,
 from include/nand.h:39,
 from common/board_r.c:40:
include/ubi_uboot.h:202:8: error: redefinition of 'struct device'
 struct device {
^
In file included from include/dm.h:10:0,
 from common/board_r.c:21:
include/dm/device.h:56:8: note: originally defined here
 struct device {
^
make[1]: *** [common/board_r.o] Fehler 1
make: *** [common] Fehler 2
pollux:u-boot hs [20140502] $

for a not yet mainlined imx6 board using UBI/UBIFS on nand. I am
currently sync current Linux MTD/UBI and UBIFS code to U-Boot, but
I think this error should pop up for all boards using DM and UBI ...

How to solve this double named struct? I do not want to change this
in Linux code as struct device is very much used, and this would
be a maintaining nightmare for future syncs with linux code.

Should we rename the DM struct device in include/dm/device.h ?

diff --git a/include/dm/device.h b/include/dm/device.h
index 4cd38ed..ba9f128 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -24,7 +24,7 @@ struct driver_info;
 #define DM_FLAG_ALLOC_PDATA(2  0)

 /**
- * struct device - An instance of a driver
+ * struct dm_device - An instance of a driver
  *
  * This holds information about a device, which is a driver bound to a
  * particular port or peripheral (essentially a driver instance).
@@ -53,12 +53,12 @@ struct driver_info;
  * @sibling_node: Next device in list of all devices
  * @flags: Flags for this device DM_FLAG_...
  */
-struct device {
+struct dm_device {

What do you think?

bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot, dm, ubi: struct device is declared twice

2014-05-01 Thread Wolfgang Denk

Dear Heiko,

In message 53632ac5.1030...@denx.de you wrote:
 
 How to solve this double named struct? I do not want to change this
 in Linux code as struct device is very much used, and this would
 be a maintaining nightmare for future syncs with linux code.
 
 Should we rename the DM struct device in include/dm/device.h ?
...
 - * struct device - An instance of a driver
 + * struct dm_device - An instance of a driver

I agree that we should keep U-Boot code as compatible with Linux as
possible, i. e. I would suggest to rename our U-Boot struct.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
If I had to live my life again,  I'd  make  the  same  mistakes, only
sooner.  -- Tallulah Bankhead
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ums: respect CONFIG_USB_CABLE_CHECK

2014-05-01 Thread Marek Vasut

On Wednesday, April 30, 2014 at 11:10:35 PM, Stephen Warren wrote:
 From: Stephen Warren swar...@nvidia.com
 
 Not all boards support usb_cable_connected(). CONFIG_USB_CABLE_CHECK is
 used elsewhere to indicate whether a board does support that function.
 Enhance cmd_usb_mass_storage.c to honor that config variable.
 
 Cc: Przemyslaw Marczak p.marc...@samsung.com
 Cc: Lukasz Majewski l.majew...@samsung.com
 Signed-off-by: Stephen Warren swar...@nvidia.com
 ---
  common/cmd_usb_mass_storage.c | 2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/common/cmd_usb_mass_storage.c b/common/cmd_usb_mass_storage.c
 index 5f557d5f857d..2f69a53acc67 100644
 --- a/common/cmd_usb_mass_storage.c
 +++ b/common/cmd_usb_mass_storage.c
 @@ -42,6 +42,7 @@ int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
 
   g_dnl_register(ums);
 
 +#ifdef CONFIG_USB_CABLE_CHECK
   /* Timeout unit: seconds */
   int cable_ready_timeout = UMS_CABLE_READY_TIMEOUT;
 
 @@ -65,6 +66,7 @@ int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
   }
   puts(\r\n);
   }
 +#endif
 
   while (1) {
   usb_gadget_handle_interrupts();

Please look at:
[PATCH v5 03/12] usb: dfu: fix boards wo USB cable detection

Does this work for you instead ?

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

Re: [U-Boot] Getting started with SPL

2014-05-01 Thread Heshsham Abdul Basit

HI Michal.

Thanks for your answers. I have few related questions which I will ask
separately.

Rgrds,

Heshsham

On 30/04/2014, Michal Simek mon...@monstr.eu wrote:
Hi

On 04/30/2014 11:32 AM, Heshsham Abdul Basit wrote:
*HI, *

*OS:* petalinux https://github.com/Xilinx/u-boot-xlnx/tree/master-next

it is not OS - it is just xilinx u-boot repo. And petalinux is using
this repo too.

*Board:* Xilinx z702 evaluation
boardhttp://www.xilinx.com/products/boards-and-kits/EK-Z7-ZC702-G.htm
having
ARM Cortex A9 and FPGA on the zc700 SoC

* Background:* I observed that first message on the console comes after 1
second. It is the message from u-boot. Why this was happening? Because I
had to use a fsbl (first stage boot
loader)http://blog.fakultaet-technik.de/development-with-zynq-part-3-build-boot-files/
for
initialization of hardware. I suspected that it is this fsbl that is
consuming 1 second initializing useless hardware which I will not use at
all. in fact I am not going to use any fpga bitstream also.

In standard flow there is bootrom - fsbl - u-boot.
I have never measured where we are spending time in boot.

So I am trying to boot my Linux image using uboot-SPL
methodhttp://www.denx.de/en/pub/Documents/Presentations/EWC2012_Roeder_Zundel_Fastboot.pdf
bypassing
fsbl.

The main advantage I can get is perhaps fastest possible boot.

yes. But also keep in your mind that depends on which boot device you are
using.
QSPI mode should be the fastest one.

I found
thishttps://github.com/Xilinx/u-boot-xlnx/blob/master/doc/README.SPL
(README.SPL) document
that explains how to work with SPL. However I have following question
w.r.t
to the this passage in the document:

The building of SPL images can be with:
define CONFIG_SPL

Because SPL images normally have a different text base, one has to be
configured by defining CONFIG_SPL_TEXT_BASE. The linker script has to be
defined with CONFIG_SPL_LDSCRIPT.

Questions:

1- In which file I should define #define CONFIG_SPL and
CONFIG_SPL_TEXT_BASE?

Just config file - you can just grep code and you will find out that it is
in include/configs/ folder.

2-Where is the linker script? Do I need to define CONFIG_SPL_LDSCRIPT in
the linker script ?

If you want to use private linker script then yes. There is also generic
one.

Source code of SPL enabled u-boot for xilinx board I am using is
thishttps://github.com/Xilinx/u-boot-xlnx/tree/master-next

yes. I have enabled it by default but for correct function you have to copy
ps7_init.c/h files from your hardware design to be align with your hw
design

Thanks,
Michal

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

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

[U-Boot] [PATCH] cmd_bootm.c: Only say XIP image when load is image_start

2014-05-01 Thread Tom Rini

We say we have an XIP (in this case, image loaded at desired execution
address) when the image header has been offset in the load.  It's
possible that in some cases executing the header is non-fatal but that's
not true in many other cases.

Signed-off-by: Tom Rini tr...@ti.com
---
 common/cmd_bootm.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index c243a5b..e683af3 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -388,7 +388,7 @@ static int bootm_load_os(bootm_headers_t *images, unsigned 
long *load_end,
image_buf = map_sysmem(image_start, image_len);
switch (comp) {
case IH_COMP_NONE:
-   if (load == blob_start || load == image_start) {
+   if (load == image_start) {
printf(   XIP %s ... , type_name);
no_overlap = 1;
} else {
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH 1/8] kmp204x: Add support for the unit LEDs

2014-05-01 Thread Valentin Longchamp

Hi York,

On 04/30/2014 07:04 PM, York Sun wrote:
 On 04/30/2014 06:01 AM, Valentin Longchamp wrote:
 From: Stefan Bigler stefan.big...@keymile.com
 
 snip
 
 diff --git a/board/keymile/kmp204x/qrio.c b/board/keymile/kmp204x/qrio.c
 index 49f9aa2..11949f4 100644
 --- a/board/keymile/kmp204x/qrio.c
 +++ b/board/keymile/kmp204x/qrio.c
 @@ -144,3 +144,17 @@ void qrio_prstcfg(u8 bit, u8 mode)
  
  out_be32(qrio_base + PRSTCFG_OFF, prstcfg);
  }
 +
 +#define CTRLH_OFF   0x02
 +#define CTRLH_WRL_BOOT  0x01
 +#define CTRLH_WRL_UNITRUN   0x02
 +
 +void qrio_set_leds(void)
 +{
 +u8 ctrlh;
 +void __iomem *qrio_base = (void *)CONFIG_SYS_QRIO_BASE;
 
 Please insert a blank line here.

OK, that's correct. Do you want me to resend the whole series or are the first 2
patches with the additional blank line OK ?

 
 +/* set UNIT LED to RED and BOOT LED to ON */
 +ctrlh = in_8(qrio_base + CTRLH_OFF);
 +ctrlh |= (CTRLH_WRL_BOOT | CTRLH_WRL_UNITRUN);
 +out_8(qrio_base + CTRLH_OFF, ctrlh);
 +}



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

Re: [U-Boot] [PATCH 7/8] ums: move all variable declarations to the start of the block

2014-05-01 Thread Marek Vasut

On Wednesday, April 30, 2014 at 11:13:21 PM, Stephen Warren wrote:
 From: Stephen Warren swar...@nvidia.com
 
 It's easier to assign values to the variables inside an if statement body
 if the assignment and declaration are separate.
 
 Cc: Przemyslaw Marczak p.marc...@samsung.com
 Cc: Lukasz Majewski l.majew...@samsung.com
 Signed-off-by: Stephen Warren swar...@nvidia.com
 ---
  common/cmd_usb_mass_storage.c | 24 
  1 file changed, 16 insertions(+), 8 deletions(-)

This doesn't apply on u-boot-usb/master, sorry.

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

Re: [U-Boot] [PATCH 1/3] usb: tegra: fix PHY selection code

2014-05-01 Thread Marek Vasut

On Wednesday, April 30, 2014 at 11:09:55 PM, Stephen Warren wrote:
 From: Stephen Warren swar...@nvidia.com
 
 The TRM for Tegra30 and later all state that USBMODE_CM_HC must be set
 before writing to hostpc1_devlc to select which PHY to use for a USB
 controller. However, neither init_{utmi,ulpi}_usb_controller() do this
 today, so the register writes they perform for PHY selection do not
 work.
 
 For the UTMI case, this was hacked around in commit 7e44d9320ed4 ARM:
 Tegra: USB: EHCI: Add support for Tegra30/Tegra114 by adding code to
 ehci_hcd_init() which sets USBMODE_CM_HC and duplicates the PHY
 selection register write. This code doesn't cover the ULPI case, so I
 wouldn't be surprised if ULPI doesn't work with the current code, unless
 the ordering requirement only ends up being an issue in HW for UTMI not
 ULPI.
 
 This patch fixes init_{utmi,ulpi}_usb_controller() to correctly set
 USBMODE_CM_HC before selecting the PHY. Now that this works, we can
 remove the duplicate UTMI-specific code in ehci_hcd_init(), thus
 simplifying that function.

This doesn't apply on u-boot-usb/master , so I cannot pick this, sorry .

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

Re: [U-Boot] [PATCH 1/8] kmp204x: Add support for the unit LEDs

On 05/01/2014 07:00 AM, Valentin Longchamp wrote:
 Hi York,
 
 On 04/30/2014 07:04 PM, York Sun wrote:
 On 04/30/2014 06:01 AM, Valentin Longchamp wrote:
 From: Stefan Bigler stefan.big...@keymile.com

 snip

 diff --git a/board/keymile/kmp204x/qrio.c b/board/keymile/kmp204x/qrio.c
 index 49f9aa2..11949f4 100644
 --- a/board/keymile/kmp204x/qrio.c
 +++ b/board/keymile/kmp204x/qrio.c
 @@ -144,3 +144,17 @@ void qrio_prstcfg(u8 bit, u8 mode)
  
 out_be32(qrio_base + PRSTCFG_OFF, prstcfg);
  }
 +
 +#define CTRLH_OFF  0x02
 +#define CTRLH_WRL_BOOT 0x01
 +#define CTRLH_WRL_UNITRUN  0x02
 +
 +void qrio_set_leds(void)
 +{
 +   u8 ctrlh;
 +   void __iomem *qrio_base = (void *)CONFIG_SYS_QRIO_BASE;

 Please insert a blank line here.
 
 OK, that's correct. Do you want me to resend the whole series or are the 
 first 2
 patches with the additional blank line OK ?
 

For a simple change like this, you can do either way. Make sure to change the
subject prefix so it doesn't confuse me or anyone.

York


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

Re: [U-Boot] [Patch v3 1/2] common/board_f: Preserve early global data

2014-05-01 Thread Simon Glass

Hi York,

On 30 April 2014 18:01, York Sun york...@freescale.com wrote:
 Some platforms (including mpc85xx, mpc86xx) use global data before calling
 function baord_inti_f(). This data should not be cleared later. Any arch
 which needs to preserve global data should define CONFIG_SYS_EARLY_GD.

 Signed-off-by: York Sun york...@freescale.com
 CC: Scott Wood scottw...@freescale.com
 CC: Simon Glass s...@chromium.org
 ---
 Change log

  v3: Introduce CONFIG_SYS_EARLY_GD instead of using a list
  v2: Instead of adding back gd init for all PPC, preserve gd for mpc85xx and 
 mpc86xx.

  README|3 +++
  arch/powerpc/include/asm/config.h |2 ++
  arch/x86/include/asm/config.h |1 +
  common/board_f.c  |   10 +-
  4 files changed, 11 insertions(+), 5 deletions(-)

 diff --git a/README b/README
 index 12758dc..1a51b11 100644
 --- a/README
 +++ b/README
 @@ -440,6 +440,9 @@ The following options need to be configured:
 supported, core will start to execute uboot when wakes up.

  - Generic CPU options:
 +   CONFIG_SYS_EARLY_GD
 +   Defines global data is used before board_init_f().
 +

This looks like a good solution, but I believe that 'early' is in fact
where we are headed. So perhaps you should create an inverted option
and define it for archs that don't support it?

For what you have, I think CONFIG_SYS_EARLY_GLOBAL_DATA might be more
descriptive. Also I think you should describe the purpose more
precisely here - it's not just the use that you need to discuss.

- The CPU init code must set it up and zero it
- Then board_init_f() doesn't zero it

 CONFIG_SYS_BIG_ENDIAN, CONFIG_SYS_LITTLE_ENDIAN

 Defines the endianess of the CPU. Implementation of those
 diff --git a/arch/powerpc/include/asm/config.h 
 b/arch/powerpc/include/asm/config.h
 index 423a6fb..4b6103b 100644
 --- a/arch/powerpc/include/asm/config.h
 +++ b/arch/powerpc/include/asm/config.h
 @@ -10,11 +10,13 @@
  #ifdef CONFIG_MPC85xx
  #include asm/config_mpc85xx.h
  #define CONFIG_SYS_FSL_DDR
 +#define CONFIG_SYS_EARLY_GD
  #endif

  #ifdef CONFIG_MPC86xx
  #include asm/config_mpc86xx.h
  #define CONFIG_SYS_FSL_DDR
 +#define CONFIG_SYS_EARLY_GD
  #endif

  #ifdef CONFIG_MPC83xx
 diff --git a/arch/x86/include/asm/config.h b/arch/x86/include/asm/config.h
 index f06a15c..940461d 100644
 --- a/arch/x86/include/asm/config.h
 +++ b/arch/x86/include/asm/config.h
 @@ -7,5 +7,6 @@
  #ifndef _ASM_CONFIG_H_
  #define _ASM_CONFIG_H_

 +#define CONFIG_SYS_EARLY_GD
  #define CONFIG_SYS_GENERIC_BOARD
  #endif
 diff --git a/common/board_f.c b/common/board_f.c
 index cbdf06f..0823bed 100644
 --- a/common/board_f.c
 +++ b/common/board_f.c
 @@ -970,20 +970,20 @@ static init_fnc_t init_sequence_f[] = {

  void board_init_f(ulong boot_flags)
  {
 -#ifndef CONFIG_X86
 +   /*
 +* For some archtecture, global data is initialized and used before
 +* calling this function. The data should be preserved.
 +*/
 +#ifndef CONFIG_SYS_EARLY_GD
 gd_t data;

 gd = data;
 -#endif

 /*
  * Clear global data before it is accessed at debug print
  * in initcall_run_list. Otherwise the debug print probably
  * get the wrong vaule of gd-have_console.
  */
 -#if !defined(CONFIG_CPM2)  !defined(CONFIG_MPC512X)  \
 -   !defined(CONFIG_MPC83xx)  !defined(CONFIG_MPC85xx)  \
 -   !defined(CONFIG_MPC86xx)  !defined(CONFIG_X86)
 zero_global_data();
  #endif

As a separate issue/patch, I think this should be defined for ARM also.

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

Re: [U-Boot] [PATCH 1/3] usb: tegra: fix PHY selection code

On 05/01/2014 04:49 AM, Marek Vasut wrote:
 On Wednesday, April 30, 2014 at 11:09:55 PM, Stephen Warren wrote:
 From: Stephen Warren swar...@nvidia.com

 The TRM for Tegra30 and later all state that USBMODE_CM_HC must be set
 before writing to hostpc1_devlc to select which PHY to use for a USB
 controller. However, neither init_{utmi,ulpi}_usb_controller() do this
 today, so the register writes they perform for PHY selection do not
 work.

 For the UTMI case, this was hacked around in commit 7e44d9320ed4 ARM:
 Tegra: USB: EHCI: Add support for Tegra30/Tegra114 by adding code to
 ehci_hcd_init() which sets USBMODE_CM_HC and duplicates the PHY
 selection register write. This code doesn't cover the ULPI case, so I
 wouldn't be surprised if ULPI doesn't work with the current code, unless
 the ordering requirement only ends up being an issue in HW for UTMI not
 ULPI.

 This patch fixes init_{utmi,ulpi}_usb_controller() to correctly set
 USBMODE_CM_HC before selecting the PHY. Now that this works, we can
 remove the duplicate UTMI-specific code in ehci_hcd_init(), thus
 simplifying that function.
 
 This doesn't apply on u-boot-usb/master , so I cannot pick this, sorry .

Ah right. That's because I'm working on top of a merge of
u-boot-arm/master and u-boot/master, and that includes the following
changes to the Tegra USB driver that went in through u-boot-tegra/master
- u-boot-arm/master rather than the USB tree:

8f9fd6caafb8 usb: tegra: combine header file
b1d615f3f102 usb: tegra: fix PHY configuration
b03f4b3742a7 usb: tegra: fix USB2 powerdown for Tegra30 and later

What's the best fix here:

* Wait until the previous patches get into u-boot/master, and
u-boot-usb/master picks them up, and then apply this series.

* Apply this series to u-boot-tegra/master with your ack?

There's little point my rebasing this series on top of
u-boot-usb/master, and applying it right now, since that will just cause
the same conflicts when u-boot-usb/master gets merged into u-boot/master.

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

Re: [U-Boot] [PATCH 7/8] ums: move all variable declarations to the start of the block

On 05/01/2014 04:51 AM, Marek Vasut wrote:
 On Wednesday, April 30, 2014 at 11:13:21 PM, Stephen Warren wrote:
 From: Stephen Warren swar...@nvidia.com

 It's easier to assign values to the variables inside an if statement body
 if the assignment and declaration are separate.

 Cc: Przemyslaw Marczak p.marc...@samsung.com
 Cc: Lukasz Majewski l.majew...@samsung.com
 Signed-off-by: Stephen Warren swar...@nvidia.com
 ---
  common/cmd_usb_mass_storage.c | 24 
  1 file changed, 16 insertions(+), 8 deletions(-)

 This doesn't apply on u-boot-usb/master, sorry.

Is this the first patch in the series which doesn't apply? Did you apply
any of the earlier patches? I guess I'll go try to rebase the series and
find out myself...

This is why we need a uboot-next just like linux-next, and stricter
controls on which git repos take patches that touch subsystem code, to
avoid cross-repo conflicts:-(
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ums: respect CONFIG_USB_CABLE_CHECK

On 04/30/2014 11:21 PM, Marek Vasut wrote:
 On Wednesday, April 30, 2014 at 11:10:35 PM, Stephen Warren wrote:
 From: Stephen Warren swar...@nvidia.com

 Not all boards support usb_cable_connected(). CONFIG_USB_CABLE_CHECK is
 used elsewhere to indicate whether a board does support that function.
 Enhance cmd_usb_mass_storage.c to honor that config variable.
...
 Please look at:
 [PATCH v5 03/12] usb: dfu: fix boards wo USB cable detection
 
 Does this work for you instead ?

Yes, it does. Please consider that patch,
Tested-by: Stephen Warren swar...@nvidia.com

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

Re: [U-Boot] [PATCH 04/11] kconfig: add basic Kconfig files

On Wed, 2014-04-30 at 12:16 -0700, Simon Glass wrote:
 Hi Masahiro,
 
 On 29 April 2014 21:22, Masahiro Yamada yamad...@jp.panasonic.com wrote:
  Hi Simon,
 
   +
   +config SPL_BUILD
   +   bool
   +   depends on BUILD_MODE=SPL || BUILD_MODE=TPL
 
  What is the TPL term for?
 
  Please note that both CONFIG_SPL_BUILD and CONFIG_TPL_BUILD
  must be defined during the build of TPL image.
 
  To sum up in a matrix, the definition of the these macros is like this:
 
  CONFIG_SPL_BUILDCONFIG_TPL_BUILD
  non-SPL build:  undefined  undefined
  SPL build  defined  undefined
  TPL build  defined  defined
 
 
  Maybe do you think it looks weird? ( Me too.)
  But the implementation has been like this
  since TPL infrastructure was introduced by commit 3aa29de.
 
  Defining only CONFIG_TPL_BUILD does not work.
 
 OK, thanks for explaining this. It seems wrong to me, but that should
 be a separate discussion for later and does not affect your series.

TPL is an additional SPL (for three-stage boot).  CONFIG_SPL_BUILD
should be set for both the TPL and for the regular SPL.

-Scott


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

Re: [U-Boot] [PATCH 04/11] kconfig: add basic Kconfig files