[U-Boot] [PATCH] nios2 : convert altera_pio to driver model

2015-09-24 Thread Thomas Chou
Convert altera_pio to driver model.

Signed-off-by: Thomas Chou 
---
 arch/nios2/dts/3c120_devboard.dts  |  38 
 arch/nios2/include/asm/gpio.h  |  80 +---
 board/altera/nios2-generic/nios2-generic.c |   7 -
 configs/nios2-generic_defconfig|   2 +
 drivers/gpio/Kconfig   |   7 +
 drivers/gpio/altera_pio.c  | 316 +++--
 include/configs/nios2-generic.h|  20 --
 7 files changed, 124 insertions(+), 346 deletions(-)

diff --git a/arch/nios2/dts/3c120_devboard.dts 
b/arch/nios2/dts/3c120_devboard.dts
index a35f5fe..f6ac273 100644
--- a/arch/nios2/dts/3c120_devboard.dts
+++ b/arch/nios2/dts/3c120_devboard.dts
@@ -132,6 +132,44 @@
clock-frequency = <6250>;
u-boot,dm-pre-reloc;
};
+
+   user_led_pio_8out: gpio@0x4cc0 {
+   compatible = "altr,pio-1.0";
+   reg = <0x4cc0 0x0010>;
+   resetvalue = <255>;
+   width = <8>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   gpio-bank-name = "led";
+   };
+
+   user_dipsw_pio_8in: gpio@0x4ce0 {
+   compatible = "altr,pio-1.0";
+   reg = <0x4ce0 0x0010>;
+   interrupt-parent = <>;
+   interrupts = <8>;
+   edge_type = <2>;
+   level_trigger = <0>;
+   resetvalue = <0>;
+   width = <8>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   gpio-bank-name = "dipsw";
+   };
+
+   user_pb_pio_4in: gpio@0x4d00 {
+   compatible = "altr,pio-1.0";
+   reg = <0x4d00 0x0010>;
+   interrupt-parent = <>;
+   interrupts = <9>;
+   edge_type = <2>;
+   level_trigger = <0>;
+   resetvalue = <0>;
+   width = <4>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   gpio-bank-name = "pb";
+   };
};
 
cfi_flash_64m: flash@0x0 {
diff --git a/arch/nios2/include/asm/gpio.h b/arch/nios2/include/asm/gpio.h
index 908381f..306ab4c 100644
--- a/arch/nios2/include/asm/gpio.h
+++ b/arch/nios2/include/asm/gpio.h
@@ -1,79 +1 @@
-/*
- * nios2 gpio driver
- *
- * This gpio core is described in http://nioswiki.com/GPIO
- * bit[0] data
- * bit[1] output enable
- *
- * When CONFIG_SYS_GPIO_BASE is not defined, the board may either
- * provide its own driver or the altera_pio driver may be used.
- *
- * Copyright (C) 2010 Thomas Chou 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef _ASM_NIOS2_GPIO_H_
-#define _ASM_NIOS2_GPIO_H_
-
-#ifdef CONFIG_SYS_GPIO_BASE
-#include 
-
-static inline int gpio_request(unsigned gpio, const char *label)
-{
-   return 0;
-}
-
-static inline int gpio_free(unsigned gpio)
-{
-   return 0;
-}
-
-static inline int gpio_direction_input(unsigned gpio)
-{
-   writel(1, CONFIG_SYS_GPIO_BASE + (gpio << 2));
-   return 0;
-}
-
-static inline int gpio_direction_output(unsigned gpio, int value)
-{
-   writel(value ? 3 : 2, CONFIG_SYS_GPIO_BASE + (gpio << 2));
-   return 0;
-}
-
-static inline int gpio_get_value(unsigned gpio)
-{
-   return readl(CONFIG_SYS_GPIO_BASE + (gpio << 2));
-}
-
-static inline void gpio_set_value(unsigned gpio, int value)
-{
-   writel(value ? 3 : 2, CONFIG_SYS_GPIO_BASE + (gpio << 2));
-}
-
-static inline int gpio_is_valid(int number)
-{
-   return ((unsigned)number) < CONFIG_SYS_GPIO_WIDTH;
-}
-#else
-#ifdef CONFIG_ALTERA_PIO
-extern int altera_pio_init(u32 base, u8 width, char iot,
-  u32 rstval, u32 negmask,
-  const char *label);
-
-extern void altera_pio_info(void);
-#define gpio_status() altera_pio_info()
-#endif
-
-extern int gpio_request(unsigned gpio, const char *label);
-extern int gpio_free(unsigned gpio);
-extern int gpio_direction_input(unsigned gpio);
-extern int gpio_direction_output(unsigned gpio, int value);
-extern int gpio_get_value(unsigned gpio);
-extern void gpio_set_value(unsigned gpio, int value);

Re: [U-Boot] SPL boot with NAND on i.MX6 data abort

2015-09-24 Thread Stefano Babic
Hi Markus,

On 23/09/2015 10:02, Markus Stelzhammer wrote:
> Hi all,
> 
> 
> I'm currently working on the port of u-boot for our custom boards.
> Previously we were using u-boot based on v2013.04 without SPL for our
> boards (we have boards with SD also) and this worked for all of our
> devices.
> 
> As we now have new boards with different (bigger) RAM, I decided to use
> the newest bootloader (v2015.10) and enable SPL support.
> This is already working on a board with SD-Card but I'm not getting it
> to work on the boards with NAND.
> 
> When I try to boot, SPL is detecting and loading u-boot but u-boot
> throws a "data abort" during "ubifs mount".

u-boot ist also in NAND ? Then SPL has configured correctly the device
else u-boot was not loaded.

> The strange thing for me is that when I disable SPL, the board will boot
> properly.

You can try to follow the data abort and check which addresses are
involved. We cannot underestimate that the bug is still present in
u-boot, but it appears only together with SPL.

> 
> Could anyone give me a hint how I could trace this error?
> I can also provide logs or code snippets if needed!

Some initialization done previously in u-boot, is done now by SPL -
check your code if there is something missing.

As your board is not mainlined, we cannot help a much with code.

Best regards,
Stefano Babic

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


Re: [U-Boot] [PATCH 00/10] Kconfig and ti omap configs tidy up

2015-09-24 Thread Igor Grinberg
Hi Tom,

On 08/26/15 17:54, Igor Grinberg wrote:
> The patch set is aimed to transferring several config options
> from the old config.h configuration style to the new Kconfig
> framework and also move some of the existing (in Kconfig) ones
> from config.h style to the defconfig style in the ti-omap land.
> 
> It is based on the 7d31c6a (Merge git://git.denx.de/u-boot-pxa) commit
> upstream.
> 
> Igor Grinberg (10):
>   configs: remove remnants of CONFIG_SYS_NAND_QUIET_TEST
>   Kconfig: fix typo in CONFIG_FIT description

Can the above two be applied please?
I'm going to rework the below ones (once I've got some time...),
but above two can be applied.

Thanks!

>   Kconfig: add CONFIG_BOOTDELAY
>   Kconfig: add CONFIG_CMD_BOOTZ
>   ti: omap3: config: remove 1 from boolean define
>   ti: omap/am: move CONFIG_HUSH_PARSER to defconfig
>   ti: omap/am: move CONFIG_CMD_BOOTZ to defconfig
>   ti: omap/am: move CONFIG_CMD_NAND to defconfig
>   ti: omap/am: move CONFIG_CMD_I2C to defconfig
>   ti: omap/am: move CONFIG_BOOTDELAY to defconfig

[...]

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


Re: [U-Boot] [PATCH 05/10] ti: omap3: config: remove 1 from boolean define

2015-09-24 Thread Igor Grinberg
Hi Tom,

On 08/26/15 17:54, Igor Grinberg wrote:
> CONFIG_TWL4030_POWER is a boolean define variable. It is either defined
> or not defined and should not have a value assigned to it.
> Remove the value.
> 
> Signed-off-by: Igor Grinberg 

I think this one can also be applied, no?

> ---
>  include/configs/ti_omap3_common.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/configs/ti_omap3_common.h 
> b/include/configs/ti_omap3_common.h
> index be231a5..e399a87 100644
> --- a/include/configs/ti_omap3_common.h
> +++ b/include/configs/ti_omap3_common.h
> @@ -66,7 +66,7 @@
>  #define CONFIG_SYS_MONITOR_LEN   (256 << 10)
>  
>  /* TWL4030 */
> -#define CONFIG_TWL4030_POWER 1
> +#define CONFIG_TWL4030_POWER
>  
>  /* SPL */
>  #define CONFIG_SPL_TEXT_BASE 0x40200800
> 

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


Re: [U-Boot] [PATCH 04/10] Kconfig: add CONFIG_CMD_BOOTZ

2015-09-24 Thread Igor Grinberg
ping.

On 08/26/15 17:54, Igor Grinberg wrote:
> Add CONFIG_CMD_BOOTZ to the Kconfig.
> Since the CONFIG_CMD_BOOTZ cannot live without the CONFIG_CMD_BOOTM,
> make it select the CONFIG_CMD_BOOTM.
> 
> Signed-off-by: Igor Grinberg 
> Cc: Masahiro Yamada 
> Cc: Simon Glass 
> ---
>  common/Kconfig | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/common/Kconfig b/common/Kconfig
> index ecbf6cb..b7791bd 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -165,6 +165,12 @@ config CMD_BOOTM
>   help
> Boot an application image from the memory.
>  
> +config CMD_BOOTZ
> + bool "bootz"
> + select CMD_BOOTM
> + help
> +   Boot a Linux kernel zImage from the memory.
> +
>  config CMD_GO
>   bool "go"
>   default y
> 

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


Re: [U-Boot] [PATCH v2 1/4] imx: mx7: discard unused global variable

2015-09-24 Thread Stefano Babic
On 15/09/2015 08:05, Peng Fan wrote:
> Discard unused global variable.
> 
> Signed-off-by: Peng Fan 
> Cc: Stefano Babic 
> ---
> 
> Changes V2:
>  none
> 
>  arch/arm/cpu/armv7/mx7/soc.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/mx7/soc.c b/arch/arm/cpu/armv7/mx7/soc.c
> index 8d50149..af16ba7 100644
> --- a/arch/arm/cpu/armv7/mx7/soc.c
> +++ b/arch/arm/cpu/armv7/mx7/soc.c
> @@ -15,8 +15,6 @@
>  #include 
>  #include 
>  
> -struct src *src_reg = (struct src *)SRC_BASE_ADDR;
> -
>  #if defined(CONFIG_IMX_THERMAL)
>  static const struct imx_thermal_plat imx7_thermal_plat = {
>   .regs = (void *)ANATOP_BASE_ADDR,
> 

Whole series:

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic


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


Re: [U-Boot] [PATCH] sunxi: mmc: Fix clk-delay settings

2015-09-24 Thread Ian Campbell
On Wed, 2015-09-23 at 21:59 +0200, Hans de Goede wrote:
> In recent allwinner kernel sources the mmc clk-delay settings have been
> slightly tweaked, and for sun9i they are completely different then what
> we are using.
> 
> This commit brings us in sync with what allwinner does, fixing problems
> accessing sdcards on some A33 devices (and likely others).
> 
> For pre sun9i hardware this makes the following changes:
> -At 400Khz change the sample delay from 7 to 0 (first introduced in A31 sdk)

This one applied to sun9i as well as pre I think?

> -At 50 Mhz change the sample delay from 5 to 4 (first introduced in A23 sdk)

By my reading it also changes oclk from 2 to 1 on 50MHz.

I don't really follow the a/w SDK stuff, is it the case that a given Ann
SDK is tested and supported by Allwinner and used on real devices for
processors Amm < Ann (chronologically, ?

IOW if a change was introduced in the A31 SDK do we then have confidence
that it doesn't break A20 due to Allwinners (and their customer's) use of
the A31 SDK on A20 or are we relying on our own + community testing?

> 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/mmc/sunxi_mmc.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> index 25f18ad..e717c44 100644
> --- a/drivers/mmc/sunxi_mmc.c
> +++ b/drivers/mmc/sunxi_mmc.c
> @@ -120,17 +120,27 @@ static int mmc_set_mod_clk(struct sunxi_mmc_host
> *mmchost, unsigned int hz)
>   /* determine delays */
>   if (hz <= 40) {
>   oclk_dly = 0;
> - sclk_dly = 7;
> + sclk_dly = 0;
>   } else if (hz <= 2500) {
>   oclk_dly = 0;
>   sclk_dly = 5;
> +#ifdef CONFIG_MACH_SUN9I
>   } else if (hz <= 5000) {
> - oclk_dly = 3;
> - sclk_dly = 5;
> + oclk_dly = 5;
> + sclk_dly = 4;
>   } else {
>   /* hz > 5000 */
>   oclk_dly = 2;
>   sclk_dly = 4;
> +#else
> + } else if (hz <= 5000) {
> + oclk_dly = 3;
> + sclk_dly = 4;
> + } else {
> + /* hz > 5000 */
> + oclk_dly = 1;
> + sclk_dly = 4;
> +#endif
>   }
>  
>   writel(CCM_MMC_CTRL_ENABLE | pll |
> CCM_MMC_CTRL_SCLK_DLY(sclk_dly) |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] sunxi: mmc: Fix clk-delay settings

2015-09-24 Thread Hans de Goede

Hi,

On 24-09-15 11:40, Ian Campbell wrote:

On Wed, 2015-09-23 at 21:59 +0200, Hans de Goede wrote:

In recent allwinner kernel sources the mmc clk-delay settings have been
slightly tweaked, and for sun9i they are completely different then what
we are using.

This commit brings us in sync with what allwinner does, fixing problems
accessing sdcards on some A33 devices (and likely others).

For pre sun9i hardware this makes the following changes:
-At 400Khz change the sample delay from 7 to 0 (first introduced in A31 sdk)


This one applied to sun9i as well as pre I think?


-At 50 Mhz change the sample delay from 5 to 4 (first introduced in A23 sdk)


By my reading it also changes oclk from 2 to 1 on 50MHz.


Right, I did not list that as we never do > 50MHz, later on in the code
we've:

cfg->f_max = 5200;

And that 52 is somewhat symbolically there, it is meant for 52MHz sdio
where as mmc / sdcards run at 50MHz max.


I don't really follow the a/w SDK stuff, is it the case that a given Ann
SDK is tested and supported by Allwinner and used on real devices for
processors Amm < Ann (chronologically, ?


Yes and no, Allwinner used to have separate kernel sources for each
die, so one for sun4i, sun5i, sun6i and sun7i.

Recently they have changed to one unified kernel tree though, so all
of sun6i, sun8i and sun9i build from the same kernel tree. Note that
sun7i is missing from the list.


IOW if a change was introduced in the A31 SDK do we then have confidence
that it doesn't break A20 due to Allwinners (and their customer's) use of
the A31 SDK on A20 or are we relying on our own + community testing?


It is safe to assume that the A23 changes do not break on the A31 since
that is using the same kernel sources. The changes may cause issues
on A20 though (A10 / A13 do not use the sample delay bits of the register
AFAICT). So I've run several tests on A20 and things seem to work fine
with the new settings there.

I believe that the mmc controller and the mmc clock bits really are the
same over all of A20 / A23 / A31 / A33, and that these new tweaked values
are better to use everywhere.

Regards,

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


Re: [U-Boot] [PATCH] sunxi: mmc: Fix clk-delay settings

2015-09-24 Thread Hans de Goede

Hi,

On 24-09-15 12:29, Ian Campbell wrote:

On Thu, 2015-09-24 at 12:01 +0200, Hans de Goede wrote:

Hi,

On 24-09-15 11:40, Ian Campbell wrote:

On Wed, 2015-09-23 at 21:59 +0200, Hans de Goede wrote:

In recent allwinner kernel sources the mmc clk-delay settings have
been
slightly tweaked, and for sun9i they are completely different then
what
we are using.

This commit brings us in sync with what allwinner does, fixing
problems
accessing sdcards on some A33 devices (and likely others).

For pre sun9i hardware this makes the following changes:
-At 400Khz change the sample delay from 7 to 0 (first introduced in
A31 sdk)


This one applied to sun9i as well as pre I think?


-At 50 Mhz change the sample delay from 5 to 4 (first introduced in
A23 sdk)


By my reading it also changes oclk from 2 to 1 on 50MHz.


Right, I did not list that as we never do > 50MHz,


But the being changed here does handle that (the else hz > 5000 case)
and that is changing even if we somehow coincidentally arrange that this
code is never used today I think it is worth mentioning so that if it does
become used we have the history of when/why it was changed.


Ok, I'll amend the commit message.


  later on in the code
we've:

cfg->f_max = 5200;

And that 52 is somewhat symbolically there, it is meant for 52MHz sdio
where as mmc / sdcards run at 50MHz max.


Are these timings used for sdio as well then? That seems worth noting.


Yes, but we never use sdio in u-boot, more in general mmc/sdio is
usually used referred to as just mmc (see e.g. the subsystem name, etc.).



I don't really follow the a/w SDK stuff, is it the case that a given
Ann
SDK is tested and supported by Allwinner and used on real devices for
processors Amm < Ann (chronologically, ?


Yes and no, Allwinner used to have separate kernel sources for each
die, so one for sun4i, sun5i, sun6i and sun7i.

Recently they have changed to one unified kernel tree though, so all
of sun6i, sun8i and sun9i build from the same kernel tree. Note that
sun7i is missing from the list.


IOW if a change was introduced in the A31 SDK do we then have
confidence
that it doesn't break A20 due to Allwinners (and their customer's) use
of
the A31 SDK on A20 or are we relying on our own + community testing?


It is safe to assume that the A23 changes do not break on the A31 since
that is using the same kernel sources. The changes may cause issues
on A20 though (A10 / A13 do not use the sample delay bits of the register
AFAICT). So I've run several tests on A20 and things seem to work fine
with the new settings there.


Great.


I believe that the mmc controller and the mmc clock bits really are the
same over all of A20 / A23 / A31 / A33, and that these new tweaked values
are better to use everywhere.

Regards,

Hans



Regards,

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


Re: [U-Boot] [PATCH] imx: boards: Add maintainers info

2015-09-24 Thread Stefano Babic
On 20/09/2015 16:26, Peng Fan wrote:
> Add MAINTAINERS info for mx6slevk_spl, mx6ul_9x9_evk and mx6qpsabreauto.
> 
> Signed-off-by: Peng Fan 
> Cc: Stefano Babic 
> ---


Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic



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


Re: [U-Boot] [PATCH V2] imx-common: consider mux_ctrl_ofs when setting mux_mode

2015-09-24 Thread Stefano Babic
On 23/09/2015 05:13, Peng Fan wrote:
> Some i.MXes use __NA_ or 0 to avoid setting mux_mode, but the following patch
> only take i.MX6/7 into consideration.
> 
> "c3c8a5748897b24f18618047804317167a531dd3 imx-common: fix iomux settings"
> 
> Use is_soc_type(MXC_CPU_MX7) to avoid breaking other i.MXes when
> setting mux_mode.
> 
> In this patch, switch to use "asm/imx-common/sys_proto.h" to avoid
> build break for "is_soc_type" for vf610 and mx25.
> 
> Signed-off-by: Peng Fan 
> Cc: Bhuvanchandra DV 
> Cc: Stefano Babic 
> Cc: Fabio Estevam 
> ---
> 


Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic


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


[U-Boot] [PULL] Please pull u-boot-imx

2015-09-24 Thread Stefano Babic
Hi Tom,

please pull from u-boot-imx, thanks !

  git://www.denx.de/git/u-boot-imx.git master

for you to fetch changes up to f697c2acca9ff02c9b0cf480a4a726ed9626a53a:

  imx: fix coding style (2015-09-24 11:32:38 +0200)


Fabio Estevam (9):
  mx6sabre_common: Add Fastboot support
  mx7dsabresd: Staticize when possible
  mx7dsabreasd: Remove dead code
  mx7dsabresd: Include USB header
  mx7dsabresd: Remove get_board_rev()
  mx7dsabresd: Remove unused config option
  mx6ul_14x14_evk: Remove dead code
  mx6ul_14x14_evk: Staticize when possible
  mx6ul_14x14_evk: Remove get_board_rev()

Heiko Schocher (1):
  imx6, aristaintetos2: add me as maintainer

Otavio Salvador (3):
  cgtqmx6eval: Fit into a single line
  cgtqmx6eval: Add a maintainer entry
  cgtqmx6eval: Add USB Mass Storage support

Peng Fan (12):
  imx-common: fix iomux settings
  imx: wdog: correct wcr register settings
  imx: mx7dsabresd set wdog SRS bit
  imx: mx7: drop select CPU_V7 for board target
  imx: mx7dsabresd: drop SYS_SOC from board Kconfig
  mtd: nand: mxs check maximum ecc that platfrom supports
  imx-common: consider mux_ctrl_ofs when setting mux_mode
  imx: boards: Add maintainers info
  imx: mx7: discard unused global variable
  imx-common: wrap boot_mode_apply with CONFIG_CMD_BMODE
  imx: mx7dsabresd: drop code for CONFIG_CMD_BMODE
  imx: fix coding style

 arch/arm/cpu/armv7/mx7/Kconfig|  1 -
 arch/arm/cpu/armv7/mx7/soc.c  |  4 +---
 arch/arm/imx-common/init.c|  5 +++--
 arch/arm/imx-common/iomux-v3.c|  6 ++
 board/aristainetos/MAINTAINERS|  1 +
 board/congatec/cgtqmx6eval/MAINTAINERS|  4 ++--
 board/congatec/cgtqmx6eval/cgtqmx6eval.c  |  3 +--
 board/freescale/mx6qsabreauto/MAINTAINERS |  2 ++
 board/freescale/mx6slevk/MAINTAINERS  |  2 ++
 board/freescale/mx6ul_14x14_evk/MAINTAINERS   |  1 +
 board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c | 52
++--
 board/freescale/mx7dsabresd/Kconfig   |  3 ---
 board/freescale/mx7dsabresd/mx7dsabresd.c | 74
+-
 drivers/mtd/nand/mxs_nand.c   |  9 -
 drivers/watchdog/imx_watchdog.c   |  3 ++-
 include/configs/cgtqmx6eval.h | 14 ++
 include/configs/mx6sabre_common.h |  6 ++
 include/configs/mx7dsabresd.h |  3 ---
 18 files changed, 60 insertions(+), 133 deletions(-)


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


Re: [U-Boot] buildman toolchains

2015-09-24 Thread Masahiro Yamada
Hi Bin,

2015-09-24 10:53 GMT+09:00 Bin Meng :
> Thanks Simon.
>
> On Tue, Sep 22, 2015 at 10:48 PM, Simon Glass  wrote:
>> +Masahiro,
>>
>> Hi,
>>
>> On 22 September 2015 at 08:01, Tom Rini  wrote:
>>> On Tue, Sep 22, 2015 at 01:12:56PM +0800, Bin Meng wrote:
>>>
 Hi,

 I was using buildman to get toolchains from kernel.org to build U-Boot
 for as many boards as possible. But I still see some boards do not
 build. Are these build failures a known issue? Error log below:

   blackfin:  +   cm-bf561 blackstamp bct-brettl2 cm-bf527 bf506f-ezkit
 ip04 bf527-sdp bf537-minotaur bf609-ezkit bf537-stamp bf527-ezkit-v2
 cm-bf537e tcm-bf518 cm-bf537u bf527-ezkit cm-bf533 pr1 bf533-ezkit
 ibf-dsp561 bf537-pnav bf537-srv1 cm-bf548 bf538f-ezkit bf548-ezkit
 bf525-ucr2 blackvme tcm-bf537 bf533-stamp bf518f-ezbrd
 bf527-ad7160-eval bf526-ezbrd bf561-ezkit br4
aarch64:  +   xilinx_zynqmp_ep hikey
  avr32:  +   atngw100mkii grasshopper atstk1002 atngw100
powerpc:  +   ebony taihu ocotea TQM834x taishan katmai
 sh:  +   sh7753evb rsk7269 rsk7264 shmin ms7720se mpr2 rsk7203
 sh7785lcr_32bit sh7785lcr
arm:  +   openrd_base axm openrd_ultimate zynq_zc70x openrd_client 
 taurus
>>>
>>> I don't do sh but:
>>>   blackfin:  +   bf537-stamp bf527-ezkit-v2 bf527-ezkit bf538f-ezkit 
>>> bf526-ezbrd
>>>aarch64:  +   p2371-2180 xilinx_zynqmp_ep hikey
>>>  avr32:  +   atngw100mkii grasshopper atstk1002 atngw100
>>>powerpc:  +   ebony taihu ocotea taishan katmai
>>>sandbox:  +   sandbox
>>>arm:  +   axm smartweb zynq_zc70x tricorder stm32f429-discovery x600 
>>> tricorder_f
>>> lash taurus
>>>
>>> is my list currently.  This does include warnings (sandbox, hikey) and
>>> some failures to link (ebony, etc).
>>
>> Sorry Bin, I didn't get back to your earlier email on this. I can't
>> build everything at present, but these notes from Masahiro in the
>> moveconfig.py script might be helpful:
>>
>> # Here is the list of cross-tools I use.
>> # Most of them are available at kernel.org
>> # (https://www.kernel.org/pub/tools/crosstool/files/bin/), except the
>> followings:
>> # arc: 
>> https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases
>> # blackfin: http://sourceforge.net/projects/adi-toolchain/files/
>
> So is the kernel.org blackfin unusable for U-Boot build?

IIRC, the kernel.org one could not build some of Bfin boards.



>> # nds32: http://osdk.andestech.com/packages/
>
> Looks like this link is out of date, as there is no prebuilt toolchain
> available for download. Is there any alternative?


Try this:
http://osdk.andestech.com/packages/nds32le-linux-glibc-v1.tgz


It worked for me today.


>> # nios2: https://sourcery.mentor.com/GNUToolchain/subscription42545
>> # sh: http://sourcery.mentor.com/public/gnu_toolchain/sh-linux-gnu
>>

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


Re: [U-Boot] [PATCH] sunxi: mmc: Fix clk-delay settings

2015-09-24 Thread Ian Campbell
On Thu, 2015-09-24 at 12:01 +0200, Hans de Goede wrote:
> Hi,
> 
> On 24-09-15 11:40, Ian Campbell wrote:
> > On Wed, 2015-09-23 at 21:59 +0200, Hans de Goede wrote:
> > > In recent allwinner kernel sources the mmc clk-delay settings have
> > > been
> > > slightly tweaked, and for sun9i they are completely different then
> > > what
> > > we are using.
> > > 
> > > This commit brings us in sync with what allwinner does, fixing
> > > problems
> > > accessing sdcards on some A33 devices (and likely others).
> > > 
> > > For pre sun9i hardware this makes the following changes:
> > > -At 400Khz change the sample delay from 7 to 0 (first introduced in
> > > A31 sdk)
> > 
> > This one applied to sun9i as well as pre I think?
> > 
> > > -At 50 Mhz change the sample delay from 5 to 4 (first introduced in
> > > A23 sdk)
> > 
> > By my reading it also changes oclk from 2 to 1 on 50MHz.
> 
> Right, I did not list that as we never do > 50MHz,

But the being changed here does handle that (the else hz > 5000 case)
and that is changing even if we somehow coincidentally arrange that this
code is never used today I think it is worth mentioning so that if it does
become used we have the history of when/why it was changed.

>  later on in the code
> we've:
> 
>   cfg->f_max = 5200;
> 
> And that 52 is somewhat symbolically there, it is meant for 52MHz sdio
> where as mmc / sdcards run at 50MHz max.

Are these timings used for sdio as well then? That seems worth noting.



> 
> > I don't really follow the a/w SDK stuff, is it the case that a given
> > Ann
> > SDK is tested and supported by Allwinner and used on real devices for
> > processors Amm < Ann (chronologically, ?
> 
> Yes and no, Allwinner used to have separate kernel sources for each
> die, so one for sun4i, sun5i, sun6i and sun7i.
> 
> Recently they have changed to one unified kernel tree though, so all
> of sun6i, sun8i and sun9i build from the same kernel tree. Note that
> sun7i is missing from the list.
> 
> > IOW if a change was introduced in the A31 SDK do we then have
> > confidence
> > that it doesn't break A20 due to Allwinners (and their customer's) use
> > of
> > the A31 SDK on A20 or are we relying on our own + community testing?
> 
> It is safe to assume that the A23 changes do not break on the A31 since
> that is using the same kernel sources. The changes may cause issues
> on A20 though (A10 / A13 do not use the sample delay bits of the register
> AFAICT). So I've run several tests on A20 and things seem to work fine
> with the new settings there.

Great.

> I believe that the mmc controller and the mmc clock bits really are the
> same over all of A20 / A23 / A31 / A33, and that these new tweaked values
> are better to use everywhere.
> 
> Regards,
> 
> Hans
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] nios2: add clear and set bits macros

2015-09-24 Thread Thomas Chou
These macros can be used to clear and set multiple bits
in a register using a single call.

Signed-off-by: Thomas Chou 
---
 arch/nios2/include/asm/io.h | 57 +
 1 file changed, 57 insertions(+)

diff --git a/arch/nios2/include/asm/io.h b/arch/nios2/include/asm/io.h
index b4bd20f..123e885 100644
--- a/arch/nios2/include/asm/io.h
+++ b/arch/nios2/include/asm/io.h
@@ -116,4 +116,61 @@ static inline void outsl (unsigned long port, const void 
*src, unsigned long cou
while (count--) outl (*p++, port);
 }
 
+/*
+ * Clear and set bits in one shot. These macros can be used to clear and
+ * set multiple bits in a register using a single call. These macros can
+ * also be used to set a multiple-bit bit pattern using a mask, by
+ * specifying the mask in the 'clear' parameter and the new bit pattern
+ * in the 'set' parameter.
+ */
+
+#define out_arch(type,endian,a,v)  __raw_write##type(cpu_to_##endian(v),a)
+#define in_arch(type,endian,a) endian##_to_cpu(__raw_read##type(a))
+
+#define out_le64(a,v)  out_arch(q,le64,a,v)
+#define out_le32(a,v)  out_arch(l,le32,a,v)
+#define out_le16(a,v)  out_arch(w,le16,a,v)
+
+#define in_le64(a) in_arch(q,le64,a)
+#define in_le32(a) in_arch(l,le32,a)
+#define in_le16(a) in_arch(w,le16,a)
+
+#define out_be32(a,v)  out_arch(l,be32,a,v)
+#define out_be16(a,v)  out_arch(w,be16,a,v)
+
+#define in_be32(a) in_arch(l,be32,a)
+#define in_be16(a) in_arch(w,be16,a)
+
+#define out_8(a,v) __raw_writeb(v,a)
+#define in_8(a)__raw_readb(a)
+
+#define clrbits(type, addr, clear) \
+   out_##type((addr), in_##type(addr) & ~(clear))
+
+#define setbits(type, addr, set) \
+   out_##type((addr), in_##type(addr) | (set))
+
+#define clrsetbits(type, addr, clear, set) \
+   out_##type((addr), (in_##type(addr) & ~(clear)) | (set))
+
+#define clrbits_be32(addr, clear) clrbits(be32, addr, clear)
+#define setbits_be32(addr, set) setbits(be32, addr, set)
+#define clrsetbits_be32(addr, clear, set) clrsetbits(be32, addr, clear, set)
+
+#define clrbits_le32(addr, clear) clrbits(le32, addr, clear)
+#define setbits_le32(addr, set) setbits(le32, addr, set)
+#define clrsetbits_le32(addr, clear, set) clrsetbits(le32, addr, clear, set)
+
+#define clrbits_be16(addr, clear) clrbits(be16, addr, clear)
+#define setbits_be16(addr, set) setbits(be16, addr, set)
+#define clrsetbits_be16(addr, clear, set) clrsetbits(be16, addr, clear, set)
+
+#define clrbits_le16(addr, clear) clrbits(le16, addr, clear)
+#define setbits_le16(addr, set) setbits(le16, addr, set)
+#define clrsetbits_le16(addr, clear, set) clrsetbits(le16, addr, clear, set)
+
+#define clrbits_8(addr, clear) clrbits(8, addr, clear)
+#define setbits_8(addr, set) setbits(8, addr, set)
+#define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
+
 #endif /* __ASM_NIOS2_IO_H_ */
-- 
2.1.4

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


[U-Boot] SPL boot with NAND on i.MX6 data abort

2015-09-24 Thread Markus Stelzhammer

Hi all,


I'm currently working on the port of u-boot for our custom boards.
Previously we were using u-boot based on v2013.04 without SPL for our 
boards (we have boards with SD also) and this worked for all of our devices.


As we now have new boards with different (bigger) RAM, I decided to use 
the newest bootloader (v2015.10) and enable SPL support.
This is already working on a board with SD-Card but I'm not getting it 
to work on the boards with NAND.


When I try to boot, SPL is detecting and loading u-boot but u-boot 
throws a "data abort" during "ubifs mount".
The strange thing for me is that when I disable SPL, the board will boot 
properly.


Could anyone give me a hint how I could trace this error?
I can also provide logs or code snippets if needed!


Best Regards

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


Re: [U-Boot] [PATCH v7 3/6] spi: cadence_qspi: fix base trigger address & transfer start address

2015-09-24 Thread Wolfgang Denk
Dear Vikas,

In message <1443053976-9112-4-git-send-email-vikas.mano...@st.com> you wrote:
> 
> --- a/drivers/spi/cadence_qspi.c
> +++ b/drivers/spi/cadence_qspi.c
> @@ -290,6 +290,8 @@ static int cadence_spi_ofdata_to_platdata(struct udevice 
> *bus)
>  
>   plat->regbase = (void *)data[0];
>   plat->ahbbase = (void *)data[2];
> + plat->trigger_base = (u32 *)fdtdec_get_addr(blob, node,
> + "cdns,trigger-address");

What happens if fdtdec_get_addr() returns FDT_ADDR_T_NONE?

I think we should implement some error handling here.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"The whole world is about three drinks behind." - Humphrey Bogart
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v7 3/6] spi: cadence_qspi: fix base trigger address & transfer start address

2015-09-24 Thread Wolfgang Denk
Dear Vikas Manocha,

In message <1443053976-9112-4-git-send-email-vikas.mano...@st.com> you wrote:
> This patch is to separate the base trigger from the read/write transfer start
> addresses.
...
> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> index 34a0f46..0d1abc8 100644
> --- a/drivers/spi/cadence_qspi.c
> +++ b/drivers/spi/cadence_qspi.c
> @@ -290,6 +290,8 @@ static int cadence_spi_ofdata_to_platdata(struct udevice 
> *bus)
>  
>   plat->regbase = (void *)data[0];
>   plat->ahbbase = (void *)data[2];

I realize this code is not new, but for the sake of consistency, the
above two regbase and ahbbase should also use fdtdec_get_addr() ...

Can you please fix that [and similar things, in case there any]?

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"He was so narrow minded he could see through  a  keyhole  with  both
eyes ..."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] arm: ls1021atwr: optimize the deep sleep latency

2015-09-24 Thread Tang Yuantian
It will take more than 1s when wake up from deep sleep. Most of the
time is spent on outputing information. This patch reduced the deep
sleep latency by:
1. avoid outputing system informaton
2. remove flush cache after DDR restore
3. skip reloading second stage uboot binary when SD boot

Signed-off-by: Tang Yuantian 
---
 board/freescale/common/arm_sleep.c  |  4 
 board/freescale/ls1021atwr/ls1021atwr.c | 19 +--
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/board/freescale/common/arm_sleep.c 
b/board/freescale/common/arm_sleep.c
index 8e8b7fa..a498c65 100644
--- a/board/freescale/common/arm_sleep.c
+++ b/board/freescale/common/arm_sleep.c
@@ -12,7 +12,6 @@
 #include 
 #endif
 #include 
-#include 
 
 #if defined(CONFIG_LS102XA)
 #include 
@@ -65,8 +64,6 @@ static void dp_ddr_restore(void)
 
for (i = 0; i < DDR_BUFF_LEN / 8; i++)
*dst++ = *src++;
-
-   flush_dcache_all();
 }
 
 static void dp_resume_prepare(void)
@@ -74,7 +71,6 @@ static void dp_resume_prepare(void)
dp_ddr_restore();
board_sleep_prepare();
armv7_init_nonsec();
-   cleanup_before_linux();
 #ifdef CONFIG_U_QE
u_qe_resume();
 #endif
diff --git a/board/freescale/ls1021atwr/ls1021atwr.c 
b/board/freescale/ls1021atwr/ls1021atwr.c
index 228dbf8..236376b 100644
--- a/board/freescale/ls1021atwr/ls1021atwr.c
+++ b/board/freescale/ls1021atwr/ls1021atwr.c
@@ -521,8 +521,10 @@ int board_early_init_f(void)
}
 
 #if defined(CONFIG_DEEP_SLEEP)
-   if (is_warm_boot())
-   fsl_dp_disable_console();
+   if (is_warm_boot()) {
+   timer_init();
+   dram_init();
+   }
 #endif
 
return 0;
@@ -531,6 +533,8 @@ int board_early_init_f(void)
 #ifdef CONFIG_SPL_BUILD
 void board_init_f(ulong dummy)
 {
+   void (*second_uboot)(void);
+
/* Clear the BSS */
memset(__bss_start, 0, __bss_end - __bss_start);
 
@@ -551,6 +555,17 @@ void board_init_f(ulong dummy)
enable_devices_ns_access(_dev[7], 1);
 #endif
 
+   /*
+* if it is woken up from deep sleep, then jump to second
+* stage uboot and continue executing without recopying
+* it from SD since it has already been reserved in memeory
+* in last boot.
+*/
+   if (is_warm_boot()) {
+   second_uboot = (void (*)(void))CONFIG_SYS_TEXT_BASE;
+   second_uboot();
+   }
+
board_init_r(NULL, 0);
 }
 #endif
-- 
2.1.0.27.g96db324

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


[U-Boot] [PATCH 7/8] cmd: bootvx: Pass E820 information to an x86 VxWorks kernel

2015-09-24 Thread Bin Meng
E820 is critical to the kernel as it provides system memory map
information. Pass it to an x86 VxWorks kernel.

Signed-off-by: Bin Meng 
---

 common/cmd_elf.c  | 31 +++
 include/vxworks.h | 29 +
 2 files changed, 60 insertions(+)

diff --git a/common/cmd_elf.c b/common/cmd_elf.c
index f46b9ba..48b70de 100644
--- a/common/cmd_elf.c
+++ b/common/cmd_elf.c
@@ -18,6 +18,10 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_X86
+#include 
+#include 
+#endif
 
 /*
  * A very simple elf loader, assumes the image is valid, returns the
@@ -213,6 +217,10 @@ int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
char *bootline; /* Text of the bootline */
char *tmp; /* Temporary char pointer */
char build_buf[128]; /* Buffer for building the bootline */
+#ifdef CONFIG_X86
+   struct e820info *info;
+   struct e820entry *data;
+#endif
 
/*
 * Check the loadaddr variable.
@@ -339,6 +347,29 @@ int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
   (char *)bootaddr);
}
 
+#ifdef CONFIG_X86
+   /*
+* Since E820 information is critical to the kernel, if we don't
+* specify these in the environments, use a default one.
+*/
+   tmp = getenv("e820data");
+   if (tmp)
+   data = (struct e820entry *)simple_strtoul(tmp, NULL, 16);
+   else
+   data = (struct e820entry *)VXWORKS_E820_DATA_ADDR;
+   tmp = getenv("e820info");
+   if (tmp)
+   info = (struct e820info *)simple_strtoul(tmp, NULL, 16);
+   else
+   info = (struct e820info *)VXWORKS_E820_INFO_ADDR;
+
+   memset(info, 0, sizeof(struct e820info));
+   info->sign = E820_SIGNATURE;
+   info->entries = install_e820_map(E820MAX, data);
+   info->addr = (info->entries - 1) * sizeof(struct e820entry) +
+VXWORKS_E820_DATA_ADDR;
+#endif
+
/*
 * If the data at the load address is an elf image, then
 * treat it like an elf image. Otherwise, assume that it is a
diff --git a/include/vxworks.h b/include/vxworks.h
index 297a70f..f69b008 100644
--- a/include/vxworks.h
+++ b/include/vxworks.h
@@ -8,6 +8,35 @@
 #ifndef _VXWORKS_H_
 #define _VXWORKS_H_
 
+/*
+ * VxWorks x86 E820 related stuff
+ *
+ * VxWorks on x86 gets E820 information from pre-defined address @
+ * 0x4a00 and 0x4000. At 0x4a00 it's an information table defined
+ * by VxWorks and the actual E820 table entries starts from 0x4000.
+ * As defined by the BIOS E820 spec, the maximum number of E820 table
+ * entries is 128 and each entry occupies 20 bytes, so it's 128 * 20
+ * = 2560 (0xa00) bytes in total. That's where VxWorks stores some
+ * information that is retrieved from the BIOS E820 call and saved
+ * later for sanity test during the kernel boot-up.
+ */
+#define VXWORKS_E820_DATA_ADDR 0x4000
+#define VXWORKS_E820_INFO_ADDR 0x4a00
+
+/* E820 info signatiure "SMAP" - System MAP */
+#define E820_SIGNATURE 0x534d4150
+
+struct e820info {
+   u32 sign;   /* "SMAP" signature */
+   u32 x0; /* don't care, used by VxWorks */
+   u32 x1; /* don't care, used by VxWorks */
+   u32 x2; /* don't care, used by VxWorks */
+   u32 addr;   /* last e820 table entry addr */
+   u32 x3; /* don't care, used by VxWorks */
+   u32 entries;/* e820 table entry count */
+   u32 error;  /* must be zero */
+};
+
 int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
 void boot_prep_vxworks(bootm_headers_t *images);
 void boot_jump_vxworks(bootm_headers_t *images);
-- 
1.8.2.1

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


[U-Boot] [PATCH 4/8] cmd: elf: Reorder load_elf_image_phdr() and load_elf_image_shdr()

2015-09-24 Thread Bin Meng
Move load_elf_image_phdr() and load_elf_image_shdr() to the beginning
of the cmd_elf.c so that forward declaration is not needed.

Signed-off-by: Bin Meng 
---

 common/cmd_elf.c | 161 +++
 1 file changed, 79 insertions(+), 82 deletions(-)

diff --git a/common/cmd_elf.c b/common/cmd_elf.c
index c5e4432..62863df 100644
--- a/common/cmd_elf.c
+++ b/common/cmd_elf.c
@@ -19,8 +19,85 @@
 #include 
 #include 
 
-static unsigned long load_elf_image_phdr(unsigned long addr);
-static unsigned long load_elf_image_shdr(unsigned long addr);
+/*
+ * A very simple elf loader, assumes the image is valid, returns the
+ * entry point address.
+ */
+static unsigned long load_elf_image_phdr(unsigned long addr)
+{
+   Elf32_Ehdr *ehdr; /* Elf header structure pointer */
+   Elf32_Phdr *phdr; /* Program header structure pointer */
+   int i;
+
+   ehdr = (Elf32_Ehdr *)addr;
+   phdr = (Elf32_Phdr *)(addr + ehdr->e_phoff);
+
+   /* Load each program header */
+   for (i = 0; i < ehdr->e_phnum; ++i) {
+   void *dst = (void *)(uintptr_t)phdr->p_paddr;
+   void *src = (void *)addr + phdr->p_offset;
+   debug("Loading phdr %i to 0x%p (%i bytes)\n",
+ i, dst, phdr->p_filesz);
+   if (phdr->p_filesz)
+   memcpy(dst, src, phdr->p_filesz);
+   if (phdr->p_filesz != phdr->p_memsz)
+   memset(dst + phdr->p_filesz, 0x00,
+  phdr->p_memsz - phdr->p_filesz);
+   flush_cache((unsigned long)dst, phdr->p_filesz);
+   ++phdr;
+   }
+
+   return ehdr->e_entry;
+}
+
+static unsigned long load_elf_image_shdr(unsigned long addr)
+{
+   Elf32_Ehdr *ehdr; /* Elf header structure pointer */
+   Elf32_Shdr *shdr; /* Section header structure pointer */
+   unsigned char *strtab = 0; /* String table pointer */
+   unsigned char *image; /* Binary image pointer */
+   int i; /* Loop counter */
+
+   ehdr = (Elf32_Ehdr *)addr;
+
+   /* Find the section header string table for output info */
+   shdr = (Elf32_Shdr *)(addr + ehdr->e_shoff +
+(ehdr->e_shstrndx * sizeof(Elf32_Shdr)));
+
+   if (shdr->sh_type == SHT_STRTAB)
+   strtab = (unsigned char *)(addr + shdr->sh_offset);
+
+   /* Load each appropriate section */
+   for (i = 0; i < ehdr->e_shnum; ++i) {
+   shdr = (Elf32_Shdr *)(addr + ehdr->e_shoff +
+(i * sizeof(Elf32_Shdr)));
+
+   if (!(shdr->sh_flags & SHF_ALLOC) ||
+   shdr->sh_addr == 0 || shdr->sh_size == 0) {
+   continue;
+   }
+
+   if (strtab) {
+   debug("%sing %s @ 0x%08lx (%ld bytes)\n",
+ (shdr->sh_type == SHT_NOBITS) ? "Clear" : "Load",
+  [shdr->sh_name],
+  (unsigned long)shdr->sh_addr,
+  (long)shdr->sh_size);
+   }
+
+   if (shdr->sh_type == SHT_NOBITS) {
+   memset((void *)(uintptr_t)shdr->sh_addr, 0,
+  shdr->sh_size);
+   } else {
+   image = (unsigned char *)addr + shdr->sh_offset;
+   memcpy((void *)(uintptr_t)shdr->sh_addr,
+  (const void *)image, shdr->sh_size);
+   }
+   flush_cache(shdr->sh_addr, shdr->sh_size);
+   }
+
+   return ehdr->e_entry;
+}
 
 /* Allow ports to override the default behavior */
 static unsigned long do_bootelf_exec(ulong (*entry)(int, char * const[]),
@@ -253,86 +330,6 @@ int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
return 1;
 }
 
-/*
- * A very simple elf loader, assumes the image is valid, returns the
- * entry point address.
- */
-static unsigned long load_elf_image_phdr(unsigned long addr)
-{
-   Elf32_Ehdr *ehdr; /* Elf header structure pointer */
-   Elf32_Phdr *phdr; /* Program header structure pointer */
-   int i;
-
-   ehdr = (Elf32_Ehdr *)addr;
-   phdr = (Elf32_Phdr *)(addr + ehdr->e_phoff);
-
-   /* Load each program header */
-   for (i = 0; i < ehdr->e_phnum; ++i) {
-   void *dst = (void *)(uintptr_t)phdr->p_paddr;
-   void *src = (void *)addr + phdr->p_offset;
-   debug("Loading phdr %i to 0x%p (%i bytes)\n",
- i, dst, phdr->p_filesz);
-   if (phdr->p_filesz)
-   memcpy(dst, src, phdr->p_filesz);
-   if (phdr->p_filesz != phdr->p_memsz)
-   memset(dst + phdr->p_filesz, 0x00,
-  phdr->p_memsz - phdr->p_filesz);
-   flush_cache((unsigned long)dst, phdr->p_filesz);
-   

[U-Boot] [PATCH 5/8] cmd: bootvx: Pass netmask and gatewayip to VxWorks bootline

2015-09-24 Thread Bin Meng
There are fields in VxWorks bootline for netmask and gatewayip.
We can get these from U-Boot environment variables and pass them
to VxWorks, just like ipaddr and serverip.

Signed-off-by: Bin Meng 
---

 common/cmd_elf.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/common/cmd_elf.c b/common/cmd_elf.c
index 62863df..5a34bde 100644
--- a/common/cmd_elf.c
+++ b/common/cmd_elf.c
@@ -287,13 +287,24 @@ int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, char 
* const argv[])
"%s:file ", CONFIG_SYS_VXWORKS_SERVERNAME);
 
tmp = getenv("ipaddr");
-   if (tmp)
-   sprintf(_buf[strlen(build_buf)], "e=%s ", tmp);
+   if (tmp) {
+   sprintf(_buf[strlen(build_buf)], "e=%s", tmp);
+   tmp = getenv("netmask");
+   if (tmp)
+   sprintf(_buf[strlen(build_buf)],
+   ":%04x ", getenv_ip("netmask").s_addr);
+   else
+   sprintf(_buf[strlen(build_buf)], " ");
+   }
 
tmp = getenv("serverip");
if (tmp)
sprintf(_buf[strlen(build_buf)], "h=%s ", tmp);
 
+   tmp = getenv("gatewayip");
+   if (tmp)
+   sprintf(_buf[strlen(build_buf)], "g=%s ", tmp);
+
tmp = getenv("hostname");
if (tmp)
sprintf(_buf[strlen(build_buf)], "tn=%s ", tmp);
-- 
1.8.2.1

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


[U-Boot] [PATCH 6/8] cmd: bootvx: Always get VxWorks bootline from env

2015-09-24 Thread Bin Meng
So far VxWorks bootline can be contructed from various environment
variables, but when these variables do not exist we get these from
corresponding config macros. This is not helpful as it requires
rebuilding U-Boot, and to make sure these config macros take effect
we should not have these environment variables. This is a little
bit complex and confusing.

Now we change the logic to always contruct the bootline from
environments (the only single source), by adding two new variables
"bootdev" and "othbootargs", and adding some comments about network
related settings mentioning they are optional. The doc about the
bootline handling is also updated.

Signed-off-by: Bin Meng 
---

 README|  12 +-
 common/cmd_elf.c  | 118 +++---
 include/vxworks.h |  22 --
 3 files changed, 70 insertions(+), 82 deletions(-)

diff --git a/README b/README
index a13705a..7ed85d2 100644
--- a/README
+++ b/README
@@ -794,18 +794,10 @@ The following options need to be configured:
 - vxWorks boot parameters:
 
bootvx constructs a valid bootline using the following
-   environments variables: bootfile, ipaddr, serverip, hostname.
+   environments variables: bootdev, bootfile, ipaddr, netmask,
+   serverip, gatewayip, hostname, othbootargs.
It loads the vxWorks image pointed bootfile.
 
-   CONFIG_SYS_VXWORKS_BOOT_DEVICE - The vxworks device name
-   CONFIG_SYS_VXWORKS_MAC_PTR - Ethernet 6 byte MA -address
-   CONFIG_SYS_VXWORKS_SERVERNAME - Name of the server
-   CONFIG_SYS_VXWORKS_BOOT_ADDR - Address of boot parameters
-
-   CONFIG_SYS_VXWORKS_ADD_PARAMS
-
-   Add it at the end of the bootline. E.g "u=username pw=secret"
-
Note: If a "bootargs" environment is defined, it will overwride
the defaults discussed just above.
 
diff --git a/common/cmd_elf.c b/common/cmd_elf.c
index 5a34bde..f46b9ba 100644
--- a/common/cmd_elf.c
+++ b/common/cmd_elf.c
@@ -256,67 +256,87 @@ int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, char 
* const argv[])
 
/*
 * Use bootaddr to find the location in memory that VxWorks
-* will look for the bootline string. The default value for
-* PowerPC is LOCAL_MEM_LOCAL_ADRS + BOOT_LINE_OFFSET which
-* defaults to 0x4200.
+* will look for the bootline string. The default value is
+* (LOCAL_MEM_LOCAL_ADRS + BOOT_LINE_OFFSET) as defined by
+* VxWorks BSP. For example, on PowerPC it defaults to 0x4200.
 */
tmp = getenv("bootaddr");
-   if (!tmp)
-   bootaddr = CONFIG_SYS_VXWORKS_BOOT_ADDR;
-   else
+   if (!tmp) {
+   printf("## VxWorks bootline address not specified\n");
+   } else {
bootaddr = simple_strtoul(tmp, NULL, 16);
 
-   /*
-* Check to see if the bootline is defined in the 'bootargs'
-* parameter. If it is not defined, we may be able to
-* construct the info.
-*/
-   bootline = getenv("bootargs");
-   if (bootline) {
-   memcpy((void *)bootaddr, bootline,
-  max(strlen(bootline), (size_t)255));
-   flush_cache(bootaddr, max(strlen(bootline), (size_t)255));
-   } else {
-   sprintf(build_buf, CONFIG_SYS_VXWORKS_BOOT_DEVICE);
-   tmp = getenv("bootfile");
-   if (tmp)
-   sprintf(_buf[strlen(build_buf)],
-   "%s:%s ", CONFIG_SYS_VXWORKS_SERVERNAME, tmp);
-   else
-   sprintf(_buf[strlen(build_buf)],
-   "%s:file ", CONFIG_SYS_VXWORKS_SERVERNAME);
+   /*
+* Check to see if the bootline is defined in the 'bootargs'
+* parameter. If it is not defined, we may be able to
+* construct the info.
+*/
+   bootline = getenv("bootargs");
+   if (bootline) {
+   memcpy((void *)bootaddr, bootline,
+  max(strlen(bootline), (size_t)255));
+   flush_cache(bootaddr, max(strlen(bootline),
+ (size_t)255));
+   } else {
+   tmp = getenv("bootdev");
+   if (tmp)
+   sprintf(build_buf, tmp);
+   else
+   printf("## VxWorks boot device not 
specified\n");
 
-   tmp = getenv("ipaddr");
-   if (tmp) {
-   sprintf(_buf[strlen(build_buf)], "e=%s", tmp);
-   tmp = getenv("netmask");
+   tmp = getenv("bootfile");
if (tmp)

Re: [U-Boot] [PATCH v7 6/6] spi: cadence_qspi: get fifo width from device tree

2015-09-24 Thread Wolfgang Denk
Dear Vikas Manocha,

In message <1443053976-9112-7-git-send-email-vikas.mano...@st.com> you wrote:
> Fifo width could be different on different socs, e.g. stv0991 & altera soc
> have different fifo width.
...
> --- a/drivers/spi/cadence_qspi.c
> +++ b/drivers/spi/cadence_qspi.c
> @@ -312,6 +312,7 @@ static int cadence_spi_ofdata_to_platdata(struct udevice 
> *bus)
>   plat->tchsh_ns = fdtdec_get_int(blob, subnode, "tchsh-ns", 20);
>   plat->tslch_ns = fdtdec_get_int(blob, subnode, "tslch-ns", 20);
>   plat->sram_size = fdtdec_get_int(blob, node, "sram-size", 128);
> + plat->fifo_width = fdtdec_get_int(blob, node, "cdns,fifo-width", 4);

Is using default values (which are known to be wrong on some
platforms) the right approach here?  It means that some systems will
silently misperform when the respective entries in the DT are missing.

Should we not add proper error handling here?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Nobody trips over mountains. It is the small pebble that  causes  you
to  stumble.  Pass all the pebbles in your path and you will find you
have crossed the mountain.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] common: add CMD_GPIO to Kconfig

2015-09-24 Thread Thomas Chou
Add CMD_GPIO to Kconfig.

Signed-off-by: Thomas Chou 
---
 common/Kconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/common/Kconfig b/common/Kconfig
index 2c42b8e..f2034c2 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -344,6 +344,11 @@ config CMD_FPGA
help
  FPGA support.
 
+config CMD_GPIO
+   bool "gpio"
+   help
+ GPIO support.
+
 endmenu
 
 
-- 
2.1.4

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


Re: [U-Boot] [PATCH v6] nios2: convert altera_jtag_uart to driver model

2015-09-24 Thread Thomas Chou



On 09/20/2015 04:36 PM, Thomas Chou wrote:

Convert altera_jtag_uart to driver model.

Signed-off-by: Thomas Chou 
Acked-by: Marek Vasut 
Reviewed-by: Simon Glass 
---
v2
   add ioremap.
   make the change to dts compatible with linux.

v3
   use fdt address translation patch from Stefan Roese.
   fix watchdog and loop as Marek suggested.

v4
   add clear AC flag to probe().
   remove polling loops and watchdog reset because they are
 done in the serial-uclass.c.

v5
   fix coding style as Marek suggested to altera_uart.

v6
   add early debug uart.
   use chosen stdout-path to assign console.
   fix coding style as Simon suggested.

  arch/nios2/dts/3c120_devboard.dts |   2 +
  configs/nios2-generic_defconfig   |   3 +
  drivers/serial/Kconfig|  26 ++
  drivers/serial/altera_jtag_uart.c | 171 +-
  include/configs/nios2-generic.h   |   3 -
  5 files changed, 142 insertions(+), 63 deletions(-)


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


Re: [U-Boot] [PATCH v3] nios2: convert altera_uart to driver model

2015-09-24 Thread Thomas Chou



On 09/20/2015 07:41 PM, Thomas Chou wrote:

Convert altera_uart to driver model.

Signed-off-by: Thomas Chou 
Reviewed-by: Simon Glass 
Acked-by: Marek Vasut 
---
v2
   fix coding style as Marek suggested.

v3
   add early debug uart.
   fix coding style as Simon suggested.

  arch/nios2/dts/3c120_devboard.dts |   1 +
  drivers/serial/Kconfig|  14 +++
  drivers/serial/altera_uart.c  | 198 --
  include/configs/nios2-generic.h   |   9 +-
  4 files changed, 123 insertions(+), 99 deletions(-)


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


Re: [U-Boot] [PATCH v7 2/6] spi: cadence_qspi: fix indirect read/write start address

2015-09-24 Thread Wolfgang Denk
Dear Vikas,

In message <1443053976-9112-3-git-send-email-vikas.mano...@st.com> you wrote:
> Indirect read/write start addresses are flash start addresses for indirect 
> read
> or write transfers. These should be absolute flash addresses instead of
> offsets.
...
>   /* Get address */
>   addr_value = cadence_qspi_apb_cmd2addr([1], addr_bytes);
> - writel(addr_value, plat->regbase + CQSPI_REG_INDIRECTRDSTARTADDR);
> + writel((u32)plat->ahbbase + addr_value,
> +plat->regbase + CQSPI_REG_INDIRECTRDSTARTADDR);
...
>   /* Setup write address. */
>   reg = cadence_qspi_apb_cmd2addr([1], addr_bytes);
> - writel(reg, plat->regbase + CQSPI_REG_INDIRECTWRSTARTADDR);
> + writel((u32)plat->ahbbase + reg,
> +plat->regbase + CQSPI_REG_INDIRECTWRSTARTADDR);

As has been pointed out before, adding type casts to silence compiler
warnings is inherently wrong.  The compiler issues a warning here to
tell you that your code is broken, so you should fix your code and not
silence the warning to paper over it.

Please fix.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Voodoo Programming: Things programmers do that  they  know  shouldn't
work  but they try anyway, and which sometimes actually work, such as
recompiling everything. - Karl Lehenbauer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 1/5] spi: cadence_qspi: Ensure spi_calibration is run when sclk change

2015-09-24 Thread Marek Vasut
On Wednesday, September 23, 2015 at 05:21:51 AM, Chin Liang See wrote:
> Hi,

Hi!

> On Wed, 2015-09-23 at 11:13 +0800, Chin Liang See wrote:
> > From: ma...@denx.de
> > Sent: Thursday, September 10, 2015 7:52 PM
> > To: Chin Liang See
> > Cc: ZY - u-boot; Dinh Nguyen; Dinh Nguyen; ZY - sr; Vikas Manocha;
> > Jagannadh Teki; ZY - pavel Subject: Re: [PATCH v3 1/5] spi:
> > cadence_qspi: Ensure spi_calibration is run when sclk change
> > 
> > On Thursday, September 10, 2015 at 07:01:12 AM, Chin Liang See wrote:
> > > Ensuring spi_calibration is run when there is a change of sclk
> > > frequency. This will ensure the qspi flash access works for high
> > > sclk frequency
> > > 
> > > Signed-off-by: Chin Liang See 
> > > Cc: Dinh Nguyen 
> > > Cc: Dinh Nguyen 
> > > Cc: Marek Vasut 
> > > Cc: Stefan Roese 
> > > Cc: Vikas Manocha 
> > > Cc: Jagannadh Teki 
> > > Cc: Pavel Machek 
> > > Acked-by: Marek Vasut 
> > > Reviewed-by: Jagan Teki 
> > > ---
> > > Changes for v2
> > > - remove frequency set before calibration
> > > - introducing previous_hz to store requested frequency
> > > - prevent calibration run when request same frequency
> > > ---
> > > 
> > >  drivers/spi/cadence_qspi.c |   20 
> > >  drivers/spi/cadence_qspi.h |1 +
> > >  2 files changed, 13 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> > > index 34a0f46..0e7450c 100644
> > > --- a/drivers/spi/cadence_qspi.c
> > > +++ b/drivers/spi/cadence_qspi.c
> > > @@ -37,15 +37,18 @@ static int cadence_spi_write_speed(struct udevice
> > > *bus, uint hz) }
> > > 
> > >  /* Calibration sequence to determine the read data capture delay
> > >  register
> > > 
> > > */ -static int spi_calibration(struct udevice *bus)
> > > +static int spi_calibration(struct udevice *bus, uint hz)
> > > 
> > >  {
> > > 
> > > - struct cadence_spi_platdata *plat = bus->platdata;
> > > 
> > >   struct cadence_spi_priv *priv = dev_get_priv(bus);
> > >   void *base = priv->regbase;
> > >   u8 opcode_rdid = 0x9F;
> > >   unsigned int idcode = 0, temp = 0;
> > >   int err = 0, i, range_lo = -1, range_hi = -1;
> > > 
> > > + /* if calibrated frequency same as reqeusted, skip it */
> > > + if (priv->qspi_calibrated_hz == hz)
> > > + return 0;
> > 
> > Do you need this check ? I think you're doing the same check in
> > cadence_spi_set_speed() down below here, so this is redundant.
> 
> Oh this is checked against calibrated value. It works together with the
> check of previous_hz. This is to cater the incident where the calibrated
> frequency = max frequency when requested frequency exceed the max
> frequency. Some examples as below
> 
> Request 100MHz, Max 50MHz,  run, calibrated 50MHz, previous 100MHz
> Request 100MHz, Max 50MHz, skip, calibrated 50MHz, previous 100MHz
> Request  90MHz, Max 50MHz, skip, calibrated 50MHz, previous  90MHz
> 
> The check here will skip calibration for third incident.
> Hope that explains.

Ah, I see, that makes sense now, thanks!

Wouldn't it thus make more sense to place this check into the
cadence_spi_set_speed() function instead , so that the spi_calibrate()
function only really does calibration , no matter what ?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] arm: socfpga: Enable env support on MCV

2015-09-24 Thread Marek Vasut
On Thursday, September 24, 2015 at 09:12:02 AM, Marek Vasut wrote:
> Enable support for env in eMMC on MCV SoM.
> 
> Signed-off-by: Marek Vasut 

Applied, thanks.

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


Re: [U-Boot] [PATCHv4] arm: socfpga: Enable saveenv for SD/MMC

2015-09-24 Thread Marek Vasut
On Wednesday, September 23, 2015 at 10:38:01 PM, dingu...@opensource.altera.com 
wrote:
> From: Dinh Nguyen 
> 
> Enable the able to save the environment variables when SD/MMC is used.
> 
> Signed-off-by: Dinh Nguyen 

Applied, thanks!

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


Re: [U-Boot] [PATCH] nios2: add clear and set bits macros

2015-09-24 Thread Marek Vasut
On Thursday, September 24, 2015 at 08:47:12 AM, Thomas Chou wrote:
> These macros can be used to clear and set multiple bits
> in a register using a single call.
> 
> Signed-off-by: Thomas Chou 

Looks pretty standard,

Reviewed-by: Marek Vasut 

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


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

2015-09-24 Thread Marek Vasut
Hi, here's an updated one

The following changes since commit 8a5f6129d1450f5ff92a55cfcfd7b96ee019e303:

  pinctrl: move dm_scan_fdt_node() out of pinctrl uclass (2015-09-19 15:42:15 
-0600)

are available in the git repository at:

  git://git.denx.de/u-boot-socfpga.git 

for you to fetch changes up to aad604aef36e90bd42b4ce1969960f3427be4a7a:

  arm: socfpga: Enable env support on MCV (2015-09-24 09:07:58 +0200)


Dinh Nguyen (3):
  arm: socfpga: rename socfpga_cyclone5 and socfpga_arria5 config files
  arm: socfpga: update MAINTAINERS' file for cyclone5_socdk and arria5_socdk
  arm: socfpga: Enable saveenv for SD/MMC

Marek Vasut (1):
  arm: socfpga: Enable env support on MCV

Stefan Roese (1):
  arm: socfpga: Fix cache configuration

 arch/arm/mach-socfpga/Kconfig| 4 ++--
 board/altera/arria5-socdk/MAINTAINERS| 4 ++--
 board/altera/cyclone5-socdk/MAINTAINERS  | 4 ++--
 include/configs/{socfpga_arria5.h => socfpga_arria5_socdk.h} | 4 
 include/configs/socfpga_common.h | 2 --
 include/configs/{socfpga_cyclone5.h => socfpga_cyclone5_socdk.h} | 4 
 include/configs/socfpga_de0_nano_soc.h   | 4 
 include/configs/socfpga_mcvevk.h | 6 ++
 include/configs/socfpga_sockit.h | 4 
 9 files changed, 28 insertions(+), 8 deletions(-)
 rename include/configs/{socfpga_arria5.h => socfpga_arria5_socdk.h} (95%)
 rename include/configs/{socfpga_cyclone5.h => socfpga_cyclone5_socdk.h} (95%)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 3/8] cmd: Clean up cmd_elf a little bit

2015-09-24 Thread Bin Meng
This commit cleans up cmd_elf.c per U-Boot coding convention,
and removes the unnecessary DECLARE_GLOBAL_DATA_PTR and out-of-date
powerpc comments (it actually supports not only powerpc targets).

Signed-off-by: Bin Meng 
---

 common/cmd_elf.c | 171 ---
 1 file changed, 73 insertions(+), 98 deletions(-)

diff --git a/common/cmd_elf.c b/common/cmd_elf.c
index 22475dc..c5e4432 100644
--- a/common/cmd_elf.c
+++ b/common/cmd_elf.c
@@ -14,23 +14,17 @@
  */
 
 #include 
-#include 
 #include 
-#include 
-#include 
 #include 
+#include 
 #include 
 
-#if defined(CONFIG_WALNUT) || defined(CONFIG_SYS_VXWORKS_MAC_PTR)
-DECLARE_GLOBAL_DATA_PTR;
-#endif
-
 static unsigned long load_elf_image_phdr(unsigned long addr);
 static unsigned long load_elf_image_shdr(unsigned long addr);
 
 /* Allow ports to override the default behavior */
 static unsigned long do_bootelf_exec(ulong (*entry)(int, char * const[]),
-  int argc, char * const argv[])
+int argc, char * const argv[])
 {
unsigned long ret;
 
@@ -54,18 +48,16 @@ static unsigned long do_bootelf_exec(ulong (*entry)(int, 
char * const[]),
return ret;
 }
 
-/* ==
+/*
  * Determine if a valid ELF image exists at the given memory location.
- * First looks at the ELF header magic field, the makes sure that it is
- * executable and makes sure that it is for a PowerPC.
- * == */
+ * First look at the ELF header magic field, then make sure that it is
+ * executable.
+ */
 int valid_elf_image(unsigned long addr)
 {
-   Elf32_Ehdr *ehdr;   /* Elf header structure pointer */
-
-   /* -- */
+   Elf32_Ehdr *ehdr; /* Elf header structure pointer */
 
-   ehdr = (Elf32_Ehdr *) addr;
+   ehdr = (Elf32_Ehdr *)addr;
 
if (!IS_ELF(*ehdr)) {
printf("## No elf image at address 0x%08lx\n", addr);
@@ -77,27 +69,17 @@ int valid_elf_image(unsigned long addr)
return 0;
}
 
-#if 0
-   if (ehdr->e_machine != EM_PPC) {
-   printf("## Not a PowerPC elf image at address 0x%08lx\n", addr);
-   return 0;
-   }
-#endif
-
return 1;
 }
 
-/* ==
- * Interpreter command to boot an arbitrary ELF image from memory.
- * == */
+/* Interpreter command to boot an arbitrary ELF image from memory */
 int do_bootelf(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
-   unsigned long addr; /* Address of the ELF image */
-   unsigned long rc;   /* Return value from user code  */
+   unsigned long addr; /* Address of the ELF image */
+   unsigned long rc; /* Return value from user code */
char *sload, *saddr;
const char *ep = getenv("autostart");
 
-   /* -- */
int rcode = 0;
 
sload = saddr = NULL;
@@ -138,28 +120,27 @@ int do_bootelf(cmd_tbl_t *cmdtp, int flag, int argc, char 
* const argv[])
rcode = 1;
 
printf("## Application terminated, rc = 0x%lx\n", rc);
+
return rcode;
 }
 
-/* ==
+/*
  * Interpreter command to boot VxWorks from a memory image.  The image can
  * be either an ELF image or a raw binary.  Will attempt to setup the
  * bootline and other parameters correctly.
- * == */
+ */
 int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
-   unsigned long addr; /* Address of image*/
-   unsigned long bootaddr; /* Address to put the bootline */
-   char *bootline; /* Text of the bootline*/
-   char *tmp;  /* Temporary char pointer  */
-   char build_buf[128];/* Buffer for building the bootline */
-
-   /* ---
-*
+   unsigned long addr; /* Address of image */
+   unsigned long bootaddr; /* Address to put the bootline */
+   char *bootline; /* Text of the bootline */
+   char *tmp; /* Temporary char pointer */
+   char build_buf[128]; /* Buffer for building the bootline */
+
+   /*
 * Check the loadaddr variable.
 * If we don't know where the image is then we're done.
 */
-
if (argc < 2)
addr = load_addr;
else
@@ -167,7 +148,8 @@ int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
 
 #if defined(CONFIG_CMD_NET)
/*
-* Check to 

[U-Boot] [PATCH 0/8] Better support of booting VxWorks via 'bootvx'

2015-09-24 Thread Bin Meng
This series adds better support of booting VxWorks using 'bootvx'.

Tested by booting a VxWorks 6.9.4 kernel on Intel Crown Bay, and
a VxWorks 7 kernel on Intel Galileo.


Bin Meng (8):
  x86: Initialize GDT entry 1 to be the 32-bit CS as well
  cmd: Convert CONFIG_CMD_ELF to Kconfig
  cmd: Clean up cmd_elf a little bit
  cmd: elf: Reorder load_elf_image_phdr() and load_elf_image_shdr()
  cmd: bootvx: Pass netmask and gatewayip to VxWorks bootline
  cmd: bootvx: Always get VxWorks bootline from env
  cmd: bootvx: Pass E820 information to an x86 VxWorks kernel
  doc: Complement document about booting VxWorks

 README  |  12 +-
 arch/x86/cpu/cpu.c  |   7 +-
 common/Kconfig  |   6 +
 common/cmd_elf.c| 404 +---
 configs/A10-OLinuXino-Lime_defconfig|   2 +-
 configs/Bananapi_defconfig  |   2 +-
 configs/Bananapro_defconfig |   2 +-
 configs/Chuwi_V7_CW0825_defconfig   |   2 +-
 configs/M5208EVBE_defconfig |   2 +-
 configs/M52277EVB_defconfig |   2 +-
 configs/M5235EVB_defconfig  |   2 +-
 configs/M5272C3_defconfig   |   2 +-
 configs/M5275EVB_defconfig  |   2 +-
 configs/M5282EVB_defconfig  |   2 +-
 configs/M53017EVB_defconfig |   2 +-
 configs/M5329AFEE_defconfig |   2 +-
 configs/M5329BFEE_defconfig |   2 +-
 configs/M5373EVB_defconfig  |   2 +-
 configs/M54418TWR_defconfig |   2 +-
 configs/M54418TWR_nand_mii_defconfig|   2 +-
 configs/M54418TWR_nand_rmii_defconfig   |   2 +-
 configs/M54418TWR_nand_rmii_lowfreq_defconfig   |   2 +-
 configs/M54418TWR_serial_mii_defconfig  |   2 +-
 configs/M54418TWR_serial_rmii_defconfig |   2 +-
 configs/M54451EVB_defconfig |   2 +-
 configs/M54455EVB_defconfig |   2 +-
 configs/M5475AFE_defconfig  |   2 +-
 configs/M5475BFE_defconfig  |   2 +-
 configs/M5475CFE_defconfig  |   2 +-
 configs/M5475DFE_defconfig  |   2 +-
 configs/M5475EFE_defconfig  |   2 +-
 configs/M5475FFE_defconfig  |   2 +-
 configs/M5475GFE_defconfig  |   2 +-
 configs/M5485AFE_defconfig  |   2 +-
 configs/M5485BFE_defconfig  |   2 +-
 configs/M5485CFE_defconfig  |   2 +-
 configs/M5485DFE_defconfig  |   2 +-
 configs/M5485EFE_defconfig  |   2 +-
 configs/M5485FFE_defconfig  |   2 +-
 configs/M5485GFE_defconfig  |   2 +-
 configs/M5485HFE_defconfig  |   2 +-
 configs/MPC8349ITXGP_defconfig  |   2 +-
 configs/MPC8349ITX_LOWBOOT_defconfig|   2 +-
 configs/MPC8349ITX_defconfig|   2 +-
 configs/MSI_Primo81_defconfig   |   2 +-
 configs/Mini-X_defconfig|   2 +-
 configs/PATI_defconfig  |   2 +-
 configs/UCP1020_defconfig   |   2 +-
 configs/VCMA9_defconfig |   2 +-
 configs/Wexler_TAB7200_defconfig|   2 +-
 configs/ac14xx_defconfig|   2 +-
 configs/alt_defconfig   |   2 +-
 configs/am335x_boneblack_defconfig  |   2 +-
 configs/am335x_gp_evm_defconfig |   1 -
 configs/am335x_sl50_defconfig   |   1 -
 configs/am3517_crane_defconfig  |   2 +-
 configs/am3517_evm_defconfig|   2 +-
 configs/amcore_defconfig|   2 +-
 configs/apalis_t30_defconfig|   4 +-
 configs/apf27_defconfig |   2 +-
 configs/arcangel4-be_defconfig  |   2 +-
 configs/arcangel4_defconfig |   4 +-
 configs/arndale_defconfig   |   4 +-
 configs/astro_mcf5373l_defconfig|   2 +-
 configs/at91rm9200ek_defconfig  |   2 +-
 configs/at91rm9200ek_ram_defconfig  |   2 +-
 configs/at91sam9260ek_dataflash_cs0_defconfig   |   2 +-
 configs/at91sam9260ek_dataflash_cs1_defconfig   |   2 +-
 configs/at91sam9260ek_nandflash_defconfig   |   2 +-
 configs/at91sam9261ek_dataflash_cs0_defconfig   |   2 +-
 configs/at91sam9261ek_dataflash_cs3_defconfig   |   2 +-
 configs/at91sam9261ek_nandflash_defconfig   |   2 +-
 configs/at91sam9263ek_dataflash_cs0_defconfig   |   2 +-
 configs/at91sam9263ek_dataflash_defconfig   |   2 +-
 configs/at91sam9263ek_nandflash_defconfig   |   2 +-
 

[U-Boot] [PATCH 1/8] x86: Initialize GDT entry 1 to be the 32-bit CS as well

2015-09-24 Thread Bin Meng
Some OS (like VxWorks) requires GDT entry 1 to be the 32-bit CS.

Signed-off-by: Bin Meng 
---

 arch/x86/cpu/cpu.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index 1b76ca1..812c5e4 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -142,7 +142,12 @@ void arch_setup_gd(gd_t *new_gd)
 
gdt_addr = new_gd->arch.gdt;
 
-   /* CS: code, read/execute, 4 GB, base 0 */
+   /*
+* CS: code, read/execute, 4 GB, base 0
+*
+* Some OS (like VxWorks) requires GDT entry 1 to be the 32-bit CS
+*/
+   gdt_addr[X86_GDT_ENTRY_UNUSED] = GDT_ENTRY(0xc09b, 0, 0xf);
gdt_addr[X86_GDT_ENTRY_32BIT_CS] = GDT_ENTRY(0xc09b, 0, 0xf);
 
/* DS: data, read/write, 4 GB, base 0 */
-- 
1.8.2.1

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


Re: [U-Boot] [PATCH v7 1/6] spi: cadence_qspi: move trigger base configuration in init

2015-09-24 Thread Wolfgang Denk
Dear Vikas,

In message <1443053976-9112-2-git-send-email-vikas.mano...@st.com> you wrote:
> No need to configure indirect trigger address for every read/write.
...
>   /* Indirect mode configurations */
>   writel((plat->sram_size/2), plat->regbase + CQSPI_REG_SRAMPARTITION);
> + writel((u32)plat->ahbbase & CQSPI_INDIRECTTRIGGER_ADDR_MASK,
> +plat->regbase + CQSPI_REG_INDIRECTTRIGGER);

I did not mention this explicitly, so I do it here:

Please fix this type cast issue globally, in all your patches.
Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Marriage is like a cage; one sees the birds outside desperate to get
in, and those inside desperate to get out."   - Montaigne
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] x86: fsp: Report correct number of E820 table entries

2015-09-24 Thread Bin Meng
The logic to calculate the number of E820 table entries is wrong
when walking through the FSP HOB tables. Fix it.

Signed-off-by: Bin Meng 

---
Simon, I think we need get this fix in v2015.10 release.

 arch/x86/lib/fsp/fsp_dram.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/lib/fsp/fsp_dram.c b/arch/x86/lib/fsp/fsp_dram.c
index 28552fa..e51ca96 100644
--- a/arch/x86/lib/fsp/fsp_dram.c
+++ b/arch/x86/lib/fsp/fsp_dram.c
@@ -72,9 +72,10 @@ unsigned install_e820_map(unsigned max_entries, struct 
e820entry *entries)
entries[num_entries].type = E820_RAM;
else if (res_desc->type == RES_MEM_RESERVED)
entries[num_entries].type = E820_RESERVED;
+
+   num_entries++;
}
hdr = get_next_hob(hdr);
-   num_entries++;
}
 
/* Mark PCIe ECAM address range as reserved */
-- 
1.8.2.1

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


[U-Boot] [PATCH 8/8] doc: Complement document about booting VxWorks

2015-09-24 Thread Bin Meng
Current document about how to boot VxWorks is limited.
Add several chapters in README.vxworks to document this.

Signed-off-by: Bin Meng 

---

 doc/README.vxworks | 78 --
 doc/README.x86 |  2 ++
 2 files changed, 72 insertions(+), 8 deletions(-)

diff --git a/doc/README.vxworks b/doc/README.vxworks
index 4cb302e..6614e7a 100644
--- a/doc/README.vxworks
+++ b/doc/README.vxworks
@@ -1,19 +1,81 @@
-From VxWorks 6.9+ (not include 6.9), VxWorks starts adopting device tree as 
its hardware
-decription mechansim (for PowerPC and ARM), thus requiring boot interface 
changes.
+#
+# Copyright (C) 2013, Miao Yan 
+# Copyright (C) 2015, Bin Meng 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+VxWorks Support
+===
+
+This document describes the information about U-Boot loading VxWorks kernel.
+
+Status
+--
+U-Boot supports loading VxWorks kernels via 'bootvx' and 'bootm' commands.
+For booting old kernels (6.9.x) on PowerPC and ARM, and all kernel versions
+on other architectures, 'bootvx' shall be used. For booting VxWorks 7 kernels
+on PowerPC and ARM, 'bootm' shall be used.
+
+64-bit x86 kernel cannot be loaded as of today.
+
+VxWork 7 on PowerPC and ARM
+---
+From VxWorks 7, VxWorks starts adopting device tree as its hardware decription
+mechansim (for PowerPC and ARM), thus requiring boot interface changes.
 This section will describe the new interface.
 
-For PowerPC, the calling convention of the new VxWorks entry point conforms to 
the ePAPR standard,
-which is shown below (see ePAPR for more details):
+For PowerPC, the calling convention of the new VxWorks entry point conforms to
+the ePAPR standard, which is shown below (see ePAPR for more details):
 
-void (*kernel_entry)(fdt_addr,
-  0, 0, EPAPR_MAGIC, boot_IMA, 0, 0)
+void (*kernel_entry)(fdt_addr, 0, 0, EPAPR_MAGIC, boot_IMA, 0, 0)
 
 For ARM, the calling convention is show below:
 
 void (*kernel_entry)(void *fdt_addr)
 
-When booting new VxWorks kernel (uImage format), the parameters passed to 
bootm is like below:
+When booting new VxWorks kernel (uImage format), the parameters passed to bootm
+is like below:
 
 bootm  - 
 
-The do_bootvx command still works as it was for older VxWorks kernels.
+VxWorks bootline
+
+When using 'bootvx', the kernel bootline must be prepared by U-Boot at a
+board-specific address before loading VxWorks. U-Boot supplies its address
+via "bootaddr" environment variable. To check where the bootline should be
+for a specific board, go to the VxWorks BSP for that board, and look for a
+parameter called BOOT_LINE_ADRS. Assign its value to "bootaddr".
+
+If a "bootargs" variable is defined, its content will be copied to the memory
+location pointed by "bootaddr" as the kernel bootline. If "bootargs" is not
+there, command 'bootvx' can construct a valid bootline using the following
+environments variables: bootdev, bootfile, ipaddr, netmask, serverip,
+gatewayip, hostname, othbootargs.
+
+When using 'bootm', just define "bootargs" in the environment and U-Boot will
+handle bootline fix up for the kernel dtb automatically.
+
+Serial console
+--
+It's very common that VxWorks BSPs configure a different baud rate for the
+serial console from what is being used by U-Boot. For example, VxWorks tends
+to use 9600 as the default baud rate on all x86 BSPs while U-Boot uses 115200.
+Please configure both U-Boot and VxWorks to use the same baud rate, or it may
+look like VxWorks hangs somewhere as nothing outputs on the serial console.
+
+x86-specific information
+
+Before loading an x86 kernel, two additional environment variables need to be
+provided. They are "e820data" and "e820info", which represent the address of
+E820 table and E820 information (defined by VxWorks) in system memory.
+
+Check VxWorks kernel configuration to look for BIOS_E820_DATA_START and
+BIOS_E820_INFO_START, and assign their values to "e820data" and "e820info"
+accordingly. If neither of these two are supplied, U-Boot assumes a default
+location at 0x4000 for "e820data" and 0x4a00 for "e820info".
+
+Note since currently U-Boot does not support ACPI yet, VxWorks kernel must
+be configured to use MP table and virtual wire interrupt mode. This requires
+INCLUDE_MPTABLE_BOOT_OP and INCLUDE_VIRTUAL_WIRE_MODE to be included in a
+VxWorks kernel configuration.
diff --git a/doc/README.x86 b/doc/README.x86
index 6cf293b..a4f5321 100644
--- a/doc/README.x86
+++ b/doc/README.x86
@@ -25,6 +25,8 @@ targets and all Intel boards support running U-Boot 'bare 
metal'.
 
 As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit
 Linux kernel as part of a FIT image. It also supports a compressed zImage.
+U-Boot supports loading an x86 VxWorks kernel. Please check README.vxworks
+for more details.
 
 Build Instructions for 

[U-Boot] [PATCH] arm: socfpga: Enable env support on MCV

2015-09-24 Thread Marek Vasut
Enable support for env in eMMC on MCV SoM.

Signed-off-by: Marek Vasut 
---
 include/configs/socfpga_mcvevk.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/configs/socfpga_mcvevk.h b/include/configs/socfpga_mcvevk.h
index ed9b5cc..65816a0 100644
--- a/include/configs/socfpga_mcvevk.h
+++ b/include/configs/socfpga_mcvevk.h
@@ -43,7 +43,11 @@
 #define CONFIG_LOADADDR0x0100
 #define CONFIG_SYS_LOAD_ADDR   CONFIG_LOADADDR
 
-#define CONFIG_ENV_IS_NOWHERE
+/* Environment is in MMC */
+#define CONFIG_ENV_OVERWRITE
+#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_SYS_MMC_ENV_DEV 0   /* device 0 */
+#define CONFIG_ENV_OFFSET  512 /* just after the MBR */
 
 /* USB */
 #ifdef CONFIG_CMD_USB
-- 
2.1.4

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


Re: [U-Boot] Pull request: u-boot-uniphier/master

2015-09-24 Thread Masahiro Yamada
Hi Tom,

If you have not pulled this, let me re-send the 2nd round.
I found a bug to be fixed.


2015-09-23 23:32 GMT+09:00 Masahiro Yamada :
> Hi Tom,
>
>
> Here is a pretty big series for UniPhier SoC changes.
>
> pinctrl drivers, various fixes, refactoring, new SoC/board support, etc.
>
>
> The following changes since commit 8a5f6129d1450f5ff92a55cfcfd7b96ee019e303:
>
>   pinctrl: move dm_scan_fdt_node() out of pinctrl uclass (2015-09-19
> 15:42:15 -0600)
>
> are available in the git repository at:
>
>   git://git.denx.de/u-boot-uniphier.git master
>
> for you to fetch changes up to 7c040c9a6099ec83706fd8658eeb3e61f31ff431:
>
>   ARM: uniphier: fix init page table for ProXstream2/PH1-LD6b USB boot
> (2015-09-23 23:21:33 +0900)
>
> 
> Masahiro Yamada (32):
>   pinctrl: uniphier: add UniPhier pinctrl core support
>   pinctrl: uniphier: add UniPhier PH1-LD4 pinctrl driver
>   pinctrl: uniphier: add UniPhier PH1-Pro4 pinctrl driver
>   pinctrl: uniphier: add UniPhier PH1-sLD8 pinctrl driver
>   pinctrl: uniphier: add UniPhier PH1-Pro5 pinctrl driver
>   pinctrl: uniphier: add UniPhier ProXstream2 pinctrl driver
>   pinctrl: uniphier: add UniPhier PH1-LD6b pinctrl driver
>   ARM: uniphier: enable simple-bus driver for SPL
>   ARM: uniphier: increase CONFIG_SYS_MALLOC_F_LEN to bind all nodes
>   ARM: dts: uniphier: prepare device trees to use pinctrl in SPL
>   ARM: uniphier: enable PINCTRL and SPL_PINCTRL
>   ARM: uniphier: drop ad-hoc early pin-muxing settings
>   ARM: uniphier: drop ad-hoc input enable settings
>   ARM: uniphier: drop DCC micro support card support
>   ARM: uniphier: enable setexpr command
>   ARM: uniphier: change the external bus address mapping
>   ARM: uniphier: remove ifdef CONFIG_{SOC} conditionals from sg-regs.h
>   ARM: uniphier: parse device tree to determine DRAM base and size
>   ARM: uniphier: remove unused header file
>   ARM: uniphier: remove useless wrapper functions
>   ARM: uniphier: refactor LED function
>   ARM: uniphier: move CONFIG_SUPPORT_CARD_* macros to local file
>   ARM: uniphier: allow to disable CONFIG_MICRO_SUPPORT_CARD
>   ARM: uniphier: rename CONFIG_MACH_* to CONFIG_ARCH_UNIPHIER_*
>   ARM: uniphier: delete unneeded input enable for low-level debug
>   ARM: uniphier: fix glitch signal problem for low-level debug
>   ARM: uniphier: unify low-level debug init code
>   ARM: uniphier: remove kernel parameter settings from environment
>   ARM: uniphier: allow to enable multiple SoCs
>   ARM: uniphier: add PH1-Pro5 support
>   ARM: uniphier: add ProXstream2 and PH1-LD6b support
>   ARM: uniphier: fix init page table for ProXstream2/PH1-LD6b USB boot
>
>  arch/arm/dts/Makefile  |   5 +-
>  arch/arm/dts/uniphier-ph1-ld4-ref.dts  |  16 ++-
>  arch/arm/dts/uniphier-ph1-ld6b-ref.dts |  17 ++-
>  arch/arm/dts/uniphier-ph1-pro4-ref.dts |  16 ++-
>  arch/arm/dts/uniphier-ph1-pro5-4kbox.dts   |
> 64 +++
>  arch/arm/dts/uniphier-ph1-sld8-ref.dts |  16 ++-
>  arch/arm/dts/uniphier-proxstream2-gentil.dts   |
> 62 ++
>  arch/arm/dts/uniphier-proxstream2-vodka.dts|
> 62 ++
>  arch/arm/mach-uniphier/Kconfig |
> 95 +++
>  arch/arm/mach-uniphier/Makefile|  21 ++--
>  arch/arm/mach-uniphier/bcu/Makefile|   3 +
>  arch/arm/mach-uniphier/{ph1-ld4/bcu_init.c => bcu/bcu-ph1-ld4.c}   |   8 +-
>  arch/arm/mach-uniphier/{ph1-sld3/bcu_init.c => bcu/bcu-ph1-sld3.c} |   8 +-
>  arch/arm/mach-uniphier/board_common.c  |  23 +---
>  arch/arm/mach-uniphier/board_early_init_f.c|
> 73 +---
>  arch/arm/mach-uniphier/board_early_init_r.c|   7 +-
>  arch/arm/mach-uniphier/boards.c|
> 130 +
>  arch/arm/mach-uniphier/boot-mode/Makefile  |   9 ++
>  .../{ph1-pro4/boot-mode.c => boot-mode/boot-mode-ph1-ld4.c}|  21 +++-
>  arch/arm/mach-uniphier/boot-mode/boot-mode-ph1-pro5.c  |
> 75 
>  .../{ph1-sld3/boot-mode.c => boot-mode/boot-mode-ph1-sld3.c}   |  23 ++--
>  arch/arm/mach-uniphier/boot-mode/boot-mode-proxstream2.c   |
> 75 
>  arch/arm/mach-uniphier/boot-mode/boot-mode.c   |
> 45 
>  arch/arm/mach-uniphier/clk/Makefile|   7 ++
>  .../arm/mach-uniphier/{ph1-ld4/clkrst_init.c => clk/clk-ph1-ld4.c} |   3 +-
>  .../mach-uniphier/{ph1-pro4/clkrst_init.c 

Re: [U-Boot] [PATCH 4/4] exynos: fix and cleanup do_sdhci_init()

2015-09-24 Thread Lukasz Majewski
Hi Tobias,

> Hello,
> 
> 
> Minkyu Kang wrote:
> > On 23/09/15 18:59, Jaehoon Chung wrote:
> >> Hi,
> >>
> >> On 09/23/2015 06:48 PM, Lukasz Majewski wrote:
> >>> Hi Lukasz,
> >>>
>  Hi Tobias,
> 
> > The CD check is currently inverted. dm_gpio_get_value() returns
> > one when a card is detected. All other values (zero when there
> > is no card, or negative values for the internal errors) indicate
> > failure.
> >
> > Signed-off-by: Tobias Jakobi 
> > ---
> >  drivers/mmc/s5p_sdhci.c | 20 +++-
> >  1 file changed, 11 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/mmc/s5p_sdhci.c b/drivers/mmc/s5p_sdhci.c
> > index 6be3609..bc04370 100644
> > --- a/drivers/mmc/s5p_sdhci.c
> > +++ b/drivers/mmc/s5p_sdhci.c
> > @@ -102,29 +102,31 @@ struct sdhci_host
> > sdhci_host[SDHCI_MAX_HOSTS]; 
> >  static int do_sdhci_init(struct sdhci_host *host)
> >  {
> > -   int dev_id, flag;
> > -   int err = 0;
> > +   int dev_id, flag, ret;
> >  
> > flag = host->bus_width == 8 ? PINMUX_FLAG_8BIT_MODE :
> > PINMUX_FLAG_NONE; dev_id = host->index + PERIPH_ID_SDMMC0;
> >  
> > if (dm_gpio_is_valid(>pwr_gpio)) {
> > dm_gpio_set_value(>pwr_gpio, 1);
> > -   err = exynos_pinmux_config(dev_id, flag);
> > -   if (err) {
> > +   ret = exynos_pinmux_config(dev_id, flag);
> > +   if (ret) {
> > debug("MMC not configured\n");
> > -   return err;
> > +   return ret;
> > }
> > }
> >  
> > if (dm_gpio_is_valid(>cd_gpio)) {
> > -   if (dm_gpio_get_value(>cd_gpio))
> > +   ret = dm_gpio_get_value(>cd_gpio);
> > +   if (ret != 1) {
> > +   debug("No card detected (%d)\n", ret);
> > return -ENODEV;
> > +   }
> >  
> > -   err = exynos_pinmux_config(dev_id, flag);
> > -   if (err) {
> > +   ret = exynos_pinmux_config(dev_id, flag);
> > +   if (ret) {
> > printf("external SD not configured\n");
> > -   return err;
> > +   return ret;
> > }
> > }
> >  
> 
>  Reviewed-by: Lukasz Majewski 
> 
> >>>
> >>> Sorry, I was too fast. I've read the whole thread and I can
> >>> confirm that your change would break Trats board.
> >>> ry
> >>> I hope that we will come up with proper solution.
> >>
> >> We can use the "cd-inverted" property like linux-kernel.
> >> Then i think that all board based on exynos4412 can cover.
> >> how about?
> I don't think this is going to work. I asked someone else to check
> current upstream u-boot on his Odroid-U3 and he has confirmed that it
> boots fine from SD card.

Have you tried the newest mainline? I'm struggling to debrick my Trats
board after some eMMC early misconfiguration.

For now I can confirm that it works with v2015.07.


> 
> So this seems to be a X2 specific thing. However the 'cd-inverted'
> property is present in exynos4412-odroid-common.dtsi, so it applies to
> both U3 and X2 in the kernel.
> 
> So either the kernel is wrong here, or this is board difference which
> can't be derived from 'cd-inverted'.
> 
> With best wishes,
> Tobias
> 
> 
> 
> 
> 
> >>
> > 
> > I agree :)
> > 
> > Thanks,
> > Minkyu Kang.
> > 
> 



-- 
Best regards,

Lukasz Majewski

Samsung R Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] sunxi: mmc: Fix clk-delay settings

2015-09-24 Thread Ian Campbell
On Thu, 2015-09-24 at 13:59 +0200, Hans de Goede wrote:
> Hi,
> 
> On 24-09-15 12:29, Ian Campbell wrote:
> > On Thu, 2015-09-24 at 12:01 +0200, Hans de Goede wrote:
> > > Hi,
> > > 
> > > On 24-09-15 11:40, Ian Campbell wrote:
> > > > On Wed, 2015-09-23 at 21:59 +0200, Hans de Goede wrote:
> > > > > In recent allwinner kernel sources the mmc clk-delay settings
> > > > > have
> > > > > been
> > > > > slightly tweaked, and for sun9i they are completely different
> > > > > then
> > > > > what
> > > > > we are using.
> > > > > 
> > > > > This commit brings us in sync with what allwinner does, fixing
> > > > > problems
> > > > > accessing sdcards on some A33 devices (and likely others).
> > > > > 
> > > > > For pre sun9i hardware this makes the following changes:
> > > > > -At 400Khz change the sample delay from 7 to 0 (first introduced
> > > > > in
> > > > > A31 sdk)
> > > > 
> > > > This one applied to sun9i as well as pre I think?
> > > > 
> > > > > -At 50 Mhz change the sample delay from 5 to 4 (first introduced
> > > > > in
> > > > > A23 sdk)
> > > > 
> > > > By my reading it also changes oclk from 2 to 1 on 50MHz.
> > > 
> > > Right, I did not list that as we never do > 50MHz,
> > 
> > But the being changed here does handle that (the else hz > 5000
> > case)
> > and that is changing even if we somehow coincidentally arrange that
> > this
> > code is never used today I think it is worth mentioning so that if it
> > does
> > become used we have the history of when/why it was changed.
> 
> Ok, I'll amend the commit message.

Thanks.

> > >   later on in the code
> > > we've:
> > > 
> > >   cfg->f_max = 5200;
> > > 
> > > And that 52 is somewhat symbolically there, it is meant for 52MHz
> > > sdio
> > > where as mmc / sdcards run at 50MHz max.
> > 
> > Are these timings used for sdio as well then? That seems worth noting.
> 
> Yes, but we never use sdio in u-boot, more in general mmc/sdio is
> usually used referred to as just mmc (see e.g. the subsystem name, etc.).

Right, which makes it all the more likely that one day this code might be
used for sdio too I think.

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


Re: [U-Boot] [PATCH 4/4] exynos: fix and cleanup do_sdhci_init()

2015-09-24 Thread Tobias Jakobi
Hello,


Minkyu Kang wrote:
> On 23/09/15 18:59, Jaehoon Chung wrote:
>> Hi,
>>
>> On 09/23/2015 06:48 PM, Lukasz Majewski wrote:
>>> Hi Lukasz,
>>>
 Hi Tobias,

> The CD check is currently inverted. dm_gpio_get_value() returns
> one when a card is detected. All other values (zero when there
> is no card, or negative values for the internal errors) indicate
> failure.
>
> Signed-off-by: Tobias Jakobi 
> ---
>  drivers/mmc/s5p_sdhci.c | 20 +++-
>  1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/mmc/s5p_sdhci.c b/drivers/mmc/s5p_sdhci.c
> index 6be3609..bc04370 100644
> --- a/drivers/mmc/s5p_sdhci.c
> +++ b/drivers/mmc/s5p_sdhci.c
> @@ -102,29 +102,31 @@ struct sdhci_host sdhci_host[SDHCI_MAX_HOSTS];
>  
>  static int do_sdhci_init(struct sdhci_host *host)
>  {
> - int dev_id, flag;
> - int err = 0;
> + int dev_id, flag, ret;
>  
>   flag = host->bus_width == 8 ? PINMUX_FLAG_8BIT_MODE :
> PINMUX_FLAG_NONE; dev_id = host->index + PERIPH_ID_SDMMC0;
>  
>   if (dm_gpio_is_valid(>pwr_gpio)) {
>   dm_gpio_set_value(>pwr_gpio, 1);
> - err = exynos_pinmux_config(dev_id, flag);
> - if (err) {
> + ret = exynos_pinmux_config(dev_id, flag);
> + if (ret) {
>   debug("MMC not configured\n");
> - return err;
> + return ret;
>   }
>   }
>  
>   if (dm_gpio_is_valid(>cd_gpio)) {
> - if (dm_gpio_get_value(>cd_gpio))
> + ret = dm_gpio_get_value(>cd_gpio);
> + if (ret != 1) {
> + debug("No card detected (%d)\n", ret);
>   return -ENODEV;
> + }
>  
> - err = exynos_pinmux_config(dev_id, flag);
> - if (err) {
> + ret = exynos_pinmux_config(dev_id, flag);
> + if (ret) {
>   printf("external SD not configured\n");
> - return err;
> + return ret;
>   }
>   }
>  

 Reviewed-by: Lukasz Majewski 

>>>
>>> Sorry, I was too fast. I've read the whole thread and I can confirm
>>> that your change would break Trats board.
>>> ry
>>> I hope that we will come up with proper solution.
>>
>> We can use the "cd-inverted" property like linux-kernel.
>> Then i think that all board based on exynos4412 can cover.
>> how about?
I don't think this is going to work. I asked someone else to check
current upstream u-boot on his Odroid-U3 and he has confirmed that it
boots fine from SD card.

So this seems to be a X2 specific thing. However the 'cd-inverted'
property is present in exynos4412-odroid-common.dtsi, so it applies to
both U3 and X2 in the kernel.

So either the kernel is wrong here, or this is board difference which
can't be derived from 'cd-inverted'.

With best wishes,
Tobias





>>
> 
> I agree :)
> 
> Thanks,
> Minkyu Kang.
> 

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


[U-Boot] [PATCH] armv8: ls2085ardb: enable CONFIG_PHY_AQUANTIA

2015-09-24 Thread shh.xie
From: Shaohui Xie 

To support on board Aquantia's PHY AQR405.

Signed-off-by: Shaohui Xie 
---
 include/configs/ls2085ardb.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/ls2085ardb.h b/include/configs/ls2085ardb.h
index c1c1572..ec9297d 100644
--- a/include/configs/ls2085ardb.h
+++ b/include/configs/ls2085ardb.h
@@ -335,6 +335,7 @@ unsigned long get_board_sys_clk(void);
 /* MAC/PHY configuration */
 #ifdef CONFIG_FSL_MC_ENET
 #define CONFIG_PHYLIB_10G
+#define CONFIG_PHY_AQUANTIA
 #define CONFIG_PHY_CORTINA
 #define CONFIG_PHYLIB
 #defineCONFIG_SYS_CORTINA_FW_IN_NOR
-- 
2.1.0.27.g96db324

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


Re: [U-Boot] Pull request: u-boot-uniphier/master

2015-09-24 Thread Tom Rini
On Thu, Sep 24, 2015 at 09:17:59PM +0900, Masahiro Yamada wrote:

> Hi Tom,
> 
> If you have not pulled this, let me re-send the 2nd round.
> I found a bug to be fixed.

OK, I'll make sure to grab the next version, thanks!

> 
> 
> 2015-09-23 23:32 GMT+09:00 Masahiro Yamada :
> > Hi Tom,
> >
> >
> > Here is a pretty big series for UniPhier SoC changes.
> >
> > pinctrl drivers, various fixes, refactoring, new SoC/board support, etc.
> >
> >
> > The following changes since commit 8a5f6129d1450f5ff92a55cfcfd7b96ee019e303:
> >
> >   pinctrl: move dm_scan_fdt_node() out of pinctrl uclass (2015-09-19
> > 15:42:15 -0600)
> >
> > are available in the git repository at:
> >
> >   git://git.denx.de/u-boot-uniphier.git master
> >
> > for you to fetch changes up to 7c040c9a6099ec83706fd8658eeb3e61f31ff431:
> >
> >   ARM: uniphier: fix init page table for ProXstream2/PH1-LD6b USB boot
> > (2015-09-23 23:21:33 +0900)
> >
> > 
> > Masahiro Yamada (32):
> >   pinctrl: uniphier: add UniPhier pinctrl core support
> >   pinctrl: uniphier: add UniPhier PH1-LD4 pinctrl driver
> >   pinctrl: uniphier: add UniPhier PH1-Pro4 pinctrl driver
> >   pinctrl: uniphier: add UniPhier PH1-sLD8 pinctrl driver
> >   pinctrl: uniphier: add UniPhier PH1-Pro5 pinctrl driver
> >   pinctrl: uniphier: add UniPhier ProXstream2 pinctrl driver
> >   pinctrl: uniphier: add UniPhier PH1-LD6b pinctrl driver
> >   ARM: uniphier: enable simple-bus driver for SPL
> >   ARM: uniphier: increase CONFIG_SYS_MALLOC_F_LEN to bind all nodes
> >   ARM: dts: uniphier: prepare device trees to use pinctrl in SPL
> >   ARM: uniphier: enable PINCTRL and SPL_PINCTRL
> >   ARM: uniphier: drop ad-hoc early pin-muxing settings
> >   ARM: uniphier: drop ad-hoc input enable settings
> >   ARM: uniphier: drop DCC micro support card support
> >   ARM: uniphier: enable setexpr command
> >   ARM: uniphier: change the external bus address mapping
> >   ARM: uniphier: remove ifdef CONFIG_{SOC} conditionals from sg-regs.h
> >   ARM: uniphier: parse device tree to determine DRAM base and size
> >   ARM: uniphier: remove unused header file
> >   ARM: uniphier: remove useless wrapper functions
> >   ARM: uniphier: refactor LED function
> >   ARM: uniphier: move CONFIG_SUPPORT_CARD_* macros to local file
> >   ARM: uniphier: allow to disable CONFIG_MICRO_SUPPORT_CARD
> >   ARM: uniphier: rename CONFIG_MACH_* to CONFIG_ARCH_UNIPHIER_*
> >   ARM: uniphier: delete unneeded input enable for low-level debug
> >   ARM: uniphier: fix glitch signal problem for low-level debug
> >   ARM: uniphier: unify low-level debug init code
> >   ARM: uniphier: remove kernel parameter settings from environment
> >   ARM: uniphier: allow to enable multiple SoCs
> >   ARM: uniphier: add PH1-Pro5 support
> >   ARM: uniphier: add ProXstream2 and PH1-LD6b support
> >   ARM: uniphier: fix init page table for ProXstream2/PH1-LD6b USB boot
> >
> >  arch/arm/dts/Makefile  |   5 +-
> >  arch/arm/dts/uniphier-ph1-ld4-ref.dts  |  16 
> > ++-
> >  arch/arm/dts/uniphier-ph1-ld6b-ref.dts |  17 
> > ++-
> >  arch/arm/dts/uniphier-ph1-pro4-ref.dts |  16 
> > ++-
> >  arch/arm/dts/uniphier-ph1-pro5-4kbox.dts   |
> > 64 +++
> >  arch/arm/dts/uniphier-ph1-sld8-ref.dts |  16 
> > ++-
> >  arch/arm/dts/uniphier-proxstream2-gentil.dts   |
> > 62 ++
> >  arch/arm/dts/uniphier-proxstream2-vodka.dts|
> > 62 ++
> >  arch/arm/mach-uniphier/Kconfig |
> > 95 +++
> >  arch/arm/mach-uniphier/Makefile|  21 
> > ++--
> >  arch/arm/mach-uniphier/bcu/Makefile|   3 +
> >  arch/arm/mach-uniphier/{ph1-ld4/bcu_init.c => bcu/bcu-ph1-ld4.c}   |   8 +-
> >  arch/arm/mach-uniphier/{ph1-sld3/bcu_init.c => bcu/bcu-ph1-sld3.c} |   8 +-
> >  arch/arm/mach-uniphier/board_common.c  |  23 
> > +---
> >  arch/arm/mach-uniphier/board_early_init_f.c|
> > 73 +---
> >  arch/arm/mach-uniphier/board_early_init_r.c|   7 +-
> >  arch/arm/mach-uniphier/boards.c|
> > 130 +
> >  arch/arm/mach-uniphier/boot-mode/Makefile  |   9 ++
> >  .../{ph1-pro4/boot-mode.c => boot-mode/boot-mode-ph1-ld4.c}|  21 
> > +++-
> >  arch/arm/mach-uniphier/boot-mode/boot-mode-ph1-pro5.c  |
> > 75 
> >  .../{ph1-sld3/boot-mode.c => boot-mode/boot-mode-ph1-sld3.c}   |  23 
> > ++--
> >  

Re: [U-Boot] [PATCH 4/4] exynos: fix and cleanup do_sdhci_init()

2015-09-24 Thread Przemyslaw Marczak

Hello Tobias,

On 09/21/2015 01:54 AM, Tobias Jakobi wrote:

The CD check is currently inverted. dm_gpio_get_value() returns
one when a card is detected. All other values (zero when there
is no card, or negative values for the internal errors) indicate
failure.



If you want revert the GPIO state, please modify the phandle in 
device-tree and then in the code.



Signed-off-by: Tobias Jakobi 
---
  drivers/mmc/s5p_sdhci.c | 20 +++-
  1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/s5p_sdhci.c b/drivers/mmc/s5p_sdhci.c
index 6be3609..bc04370 100644
--- a/drivers/mmc/s5p_sdhci.c
+++ b/drivers/mmc/s5p_sdhci.c
@@ -102,29 +102,31 @@ struct sdhci_host sdhci_host[SDHCI_MAX_HOSTS];

  static int do_sdhci_init(struct sdhci_host *host)
  {
-   int dev_id, flag;
-   int err = 0;
+   int dev_id, flag, ret;

flag = host->bus_width == 8 ? PINMUX_FLAG_8BIT_MODE : PINMUX_FLAG_NONE;
dev_id = host->index + PERIPH_ID_SDMMC0;

if (dm_gpio_is_valid(>pwr_gpio)) {
dm_gpio_set_value(>pwr_gpio, 1);
-   err = exynos_pinmux_config(dev_id, flag);
-   if (err) {
+   ret = exynos_pinmux_config(dev_id, flag);
+   if (ret) {
debug("MMC not configured\n");
-   return err;
+   return ret;
}
}

if (dm_gpio_is_valid(>cd_gpio)) {
-   if (dm_gpio_get_value(>cd_gpio))


Please don't revert this GPIO. This part of code was correct.
There is another source of broken SD card detect. It's about device-tree 
parsing. I will send a patches today.



+   ret = dm_gpio_get_value(>cd_gpio);
+   if (ret != 1) {
+   debug("No card detected (%d)\n", ret);
return -ENODEV;
+   }

-   err = exynos_pinmux_config(dev_id, flag);
-   if (err) {
+   ret = exynos_pinmux_config(dev_id, flag);
+   if (ret) {
printf("external SD not configured\n");
-   return err;
+   return ret;
}
}




Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 0/4] Fix operation on Odroid devices

2015-09-24 Thread Przemyslaw Marczak

Hello Tobias,

On 09/21/2015 01:18 AM, Tobias Jakobi wrote:

Hello,

currently operation on Exynos4412-based Odroid devices is broken.

The bootloader stops with this message:
Card did not respond to voltage select!
*** Warning - MMC init failed, using default environment

This series fixes error handling in the s5p sdhci driver
and the cause of the issue, which is an inverted card
detection check.

Thanks goes to Marek Vasut and Sjoerd Simons who helped
me on IRC to get this triaged.

With best wishes,
Tobias

Tobias Jakobi (4):
   exynos: Properly initialize host_caps in s5p_sdhci_core_init()
   exynos: Fix passing of errors in exynos_mmc_init()
   exynos: be more verbose in process_nodes()
   exynos: fix and cleanup do_sdhci_init()

  drivers/mmc/s5p_sdhci.c | 39 +++
  1 file changed, 23 insertions(+), 16 deletions(-)



NAK for the series, since the real problem is in device tree parsing, 
not in s5p_sdhci.c. I will send patches in a moment.


Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2] sunxi: mmc: Fix clk-delay settings

2015-09-24 Thread Hans de Goede
In recent allwinner kernel sources the mmc/sdio clk-delay settings have
been slightly tweaked, and for sun9i they are completely different then
what we are using.

This commit brings us in sync with what allwinner does, fixing problems
accessing sdcards on some A33 devices (and likely others).

For pre sun9i hardware this makes the following changes:
-At 400Khz change the sample delay from 7 to 0 (first introduced in A31 sdk)
-At 50 Mhz change the sample delay from 5 to 4 (first introduced in A23 sdk)
-Above 50 MHz change the out delay from 2 to 1 (first introduced in A20 sdk)

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Improved commit message
---
 drivers/mmc/sunxi_mmc.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 25f18ad..e717c44 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -120,17 +120,27 @@ static int mmc_set_mod_clk(struct sunxi_mmc_host 
*mmchost, unsigned int hz)
/* determine delays */
if (hz <= 40) {
oclk_dly = 0;
-   sclk_dly = 7;
+   sclk_dly = 0;
} else if (hz <= 2500) {
oclk_dly = 0;
sclk_dly = 5;
+#ifdef CONFIG_MACH_SUN9I
} else if (hz <= 5000) {
-   oclk_dly = 3;
-   sclk_dly = 5;
+   oclk_dly = 5;
+   sclk_dly = 4;
} else {
/* hz > 5000 */
oclk_dly = 2;
sclk_dly = 4;
+#else
+   } else if (hz <= 5000) {
+   oclk_dly = 3;
+   sclk_dly = 4;
+   } else {
+   /* hz > 5000 */
+   oclk_dly = 1;
+   sclk_dly = 4;
+#endif
}
 
writel(CCM_MMC_CTRL_ENABLE | pll | CCM_MMC_CTRL_SCLK_DLY(sclk_dly) |
-- 
2.5.0

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


Re: [U-Boot] SPL boot with NAND on i.MX6 data abort

2015-09-24 Thread Markus Stelzhammer

Hi Stefano,


Today I grabbed a different Hardware with a bigger NAND chip (512 
instead of 256MB).
At this hardware, SPL is not able to jump to U-Boot. So currently I 
assume that I might have some problems when flashing.


Would you be so kind to review my header file if I miss something or if 
there is something completely wrong?! (I attached it)

The commands I use to flash are the following:

> ./kobs-ng init -v -x SPL
> nandwrite --start=0x11000 --pad /dev/mtd0 u-boot.uim (I also 
tried to flash u-boot.bin and u-boot.imx)


The output I get at boot are the following, but then it stucks.
...
>>spl:board_init_r()
using memory 0x1830-0x1b50 for malloc()
spl_init()
boot device - 4
spl: nand - using hw ecc
NAND : 0x01:0xdc erasesize=1 (>>0)
writesize=-1 (>>0)
oobsize=65535
chipsize=1095216660225
Not support the NAND chips whose oob size is larger then 1024 bytes!
1044479 MiB
nand_spl_load_image offset:0x00011000 len:64 page:69632
mkimage signature not found - ih_magic = 0
nand_spl_load_image offset:0x00011000 len:409600 page:69632
Jumping to U-Boot
loaded - jumping to U-Boot...image entry point: 0x1780


On 09/24/2015 11:25 AM, Stefano Babic wrote:

Hi Markus,

On 23/09/2015 10:02, Markus Stelzhammer wrote:

Hi all,


I'm currently working on the port of u-boot for our custom boards.
Previously we were using u-boot based on v2013.04 without SPL for our
boards (we have boards with SD also) and this worked for all of our
devices.

As we now have new boards with different (bigger) RAM, I decided to use
the newest bootloader (v2015.10) and enable SPL support.
This is already working on a board with SD-Card but I'm not getting it
to work on the boards with NAND.

When I try to boot, SPL is detecting and loading u-boot but u-boot
throws a "data abort" during "ubifs mount".

u-boot ist also in NAND ? Then SPL has configured correctly the device
else u-boot was not loaded.


The strange thing for me is that when I disable SPL, the board will boot
properly.

You can try to follow the data abort and check which addresses are
involved. We cannot underestimate that the bug is still present in
u-boot, but it appears only together with SPL.


Could anyone give me a hint how I could trace this error?
I can also provide logs or code snippets if needed!

Some initialization done previously in u-boot, is done now by SPL -
check your code if there is something missing.

As your board is not mainlined, we cannot help a much with code.

Best regards,
Stefano Babic



Best regards,
Markus
/*
 * Copyright (C) 2013 Freescale Semiconductor, Inc.
 *
 * Configuration settings for the Wandboard.
 *
 * SPDX-License-Identifier:	GPL-2.0+
 */

#ifndef __CONFIG_H
#define __CONFIG_H

#define DEBUG
#define CONFIG_MX6DL

#include "mx6_common.h"
#define CONFIG_SPL_LIBCOMMON_SUPPORT
#define CONFIG_SPL_MMC_SUPPORT
#define CONFIG_SPL_PAD_TO		0x11000
#include "imx6_spl.h"

#define CONFIG_SPL_EXT_SUPPORT
#if 1
#define CONFIG_SPL_DISABLE_OF_CONTROL
#define CONFIG_SPL_DMA_SUPPORT
#define CONFIG_SPL_NAND_SUPPORT
/* Location in NAND to read U-Boot from */
#define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_PAD_TO/*(69 * SZ_1M)*/
#endif

/* Size of malloc() pool */
#define CONFIG_SYS_MALLOC_LEN		(30 * SZ_1M)

#define CONFIG_BOARD_EARLY_INIT_F
#define CONFIG_BOARD_LATE_INIT

#define CONFIG_MXC_UART
#define CONFIG_MXC_UART_BASE		UART2_BASE
#define CONFIG_CONSOLE_DEV			"ttymxc1"

/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
#define CONFIG_CONS_INDEX   1
#define CONFIG_BAUDRATE 115200

/* Command definition */
#define CONFIG_CMD_BMODE

#if 0
#define CONFIG_SYS_MEMTEST_START	0x1000
#define CONFIG_SYS_MEMTEST_END		(CONFIG_SYS_MEMTEST_START + 500 * SZ_1M)
#endif

#define CONFIG_CMD_MEMINFO

/* I2C Configs */
#define CONFIG_CMD_I2C
#define CONFIG_SYS_I2C
#define CONFIG_SYS_I2C_MXC
#define CONFIG_SYS_I2C_MXC_I2C3		/* enable I2C bus 3 */
#define CONFIG_SYS_I2C_SPEED		10
#define CONFIG_SYS_I2C_EEPROM_ADDR  0x50
#define CONFIG_SYS_I2C_EEPROM_ADDR_LEN  2

/* NAND support */
#if 1
#define CONFIG_CMD_TIME
#endif
#define CONFIG_CMD_NAND
#define CONFIG_CMD_NAND_TRIMFFS
#ifdef CONFIG_CMD_NAND
	#define CONFIG_NAND_MXS
	#define CONFIG_SYS_MAX_NAND_DEVICE  1
	#define CONFIG_SYS_NAND_BASE0x4000
	#define CONFIG_SYS_NAND_5_ADDR_CYCLE
	#define CONFIG_SYS_NAND_ONFI_DETECTION

	/* DMA stuff, needed for GPMI/MXS NAND support */
	#define CONFIG_APBH_DMA
	#define CONFIG_APBH_DMA_BURST
	#define CONFIG_APBH_DMA_BURST8
#endif

/* MTD stuff */
#define CONFIG_MTD_DEVICE
#define CONFIG_MTD_PARTITIONS
#define CONFIG_CMD_MTDPARTS /* Enable MTD parts commands */
#define MTDIDS_DEFAULT  "nand0=gpmi-nand"
#define MTDPARTS_DEFAULT"mtdparts=gpmi-nand:15m(uboot),1m(sram),-(ubisystem)"
/* UBIFS stuff */
#define CONFIG_CMD_UBI  /* UBI commands */
#define CONFIG_CMD_UBIFS/* UBIFS commands */
#define CONFIG_RBTREE
#define CONFIG_LZO 

[U-Boot] [PATCH 0/3] Fix fdt 'reg' parsing and unbreak Odroid U3

2015-09-24 Thread Przemyslaw Marczak
Booting of Odroid U3 with SD card, ends with error:

MMC:   EXYNOS DWMMC: 0
Card did not respond to voltage select!
*** Warning - MMC init failed, using default environment

Generally this was broken, because of wrong addresses assigned to GPIOs.

The source of the problem was in rework of lib/fdtdec.c, after which
function fdtdec_get_addr() doesn't work as previous and function
dev_get_addr() doesn't works as expected.

The code after rework in lib/fdtdec.c assume, that #size-cells property,
should be always greater or equal to 1. This was wrong, because it can be 0.

In case of debugging the issue I found, that mmc clock was computed wrong,
for Exynos4, because of function get_mmc_clk(), which always return -1 for
this SoC.

Tested on: Odroid U3 and Odroid XU3.

Przemyslaw Marczak (3):
  fix: fdtdec: allow parse 'reg' property with zero value in
'#size-cells'
  fix: s5p_gpio: call: dev_get_addr() instead of fdtdec_get_addr()
  fix: mach-exynos: clock: restore calling dead exynos4_get_mmc_clk()

 arch/arm/mach-exynos/clock.c | 10 --
 drivers/gpio/s5p_gpio.c  | 18 +++---
 lib/fdtdec.c |  2 +-
 3 files changed, 16 insertions(+), 14 deletions(-)

-- 
1.9.1

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


[U-Boot] [PATCH 2/3] fix: s5p_gpio: call: dev_get_addr() instead of fdtdec_get_addr()

2015-09-24 Thread Przemyslaw Marczak
After rework in lib/fdtdec.c, the function fdtdec_get_addr()
doesn't work for nodes with #size-cells property, set to 0.

To get GPIO's 'reg' property, the code should use one of:
fdtdec_get_addr_size_auto_no/parent() function.

Fortunately dm core provides a function to get the property.

This commit reworks function gpio_exynos_bind(), to properly
use dev_get_addr() for GPIO device.

This prevents setting a wrong base register for Exynos GPIOs.

Signed-off-by: Przemyslaw Marczak 
---
 drivers/gpio/s5p_gpio.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpio/s5p_gpio.c b/drivers/gpio/s5p_gpio.c
index 17fcfbf..0f22b23 100644
--- a/drivers/gpio/s5p_gpio.c
+++ b/drivers/gpio/s5p_gpio.c
@@ -341,18 +341,22 @@ static int gpio_exynos_bind(struct udevice *parent)
plat = calloc(1, sizeof(*plat));
if (!plat)
return -ENOMEM;
-   reg = fdtdec_get_addr(blob, node, "reg");
-   if (reg != FDT_ADDR_T_NONE)
-   bank = (struct s5p_gpio_bank *)((ulong)base + reg);
-   plat->bank = bank;
-   plat->bank_name = fdt_get_name(blob, node, NULL);
-   debug("dev at %p: %s\n", bank, plat->bank_name);
 
+   plat->bank_name = fdt_get_name(blob, node, NULL);
ret = device_bind(parent, parent->driver,
-   plat->bank_name, plat, -1, );
+ plat->bank_name, plat, -1, );
if (ret)
return ret;
+
dev->of_offset = node;
+
+   reg = dev_get_addr(dev);
+   if (reg != FDT_ADDR_T_NONE)
+   bank = (struct s5p_gpio_bank *)((ulong)base + reg);
+
+   plat->bank = bank;
+
+   debug("dev at %p: %s\n", bank, plat->bank_name);
}
 
return 0;
-- 
1.9.1

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


[U-Boot] [PATCH 3/3] fix: mach-exynos: clock: restore calling dead exynos4_get_mmc_clk()

2015-09-24 Thread Przemyslaw Marczak
After rework of code by commit:

commit d95279685bb9690a6973226a3bd8a3bae65c2ad7
Author: Akshay Saraswat 
Date:   Wed Feb 4 16:00:03 2015 +0530

function get_mmc_clk() always returns -1 for Exynos 4.

This was caused by omitting, that SDHCI driver for Exynos 4,
calls get_mmc_clk(), with mmc device number as argument,
instead of pinmux peripheral id, like DW MMC driver for Exynos 5.

By this commit, the code directly calls a proper function
to get mmc clock for Exynos 4, without checking the peripheral id.

Signed-off-by: Przemyslaw Marczak 
---
 arch/arm/mach-exynos/clock.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-exynos/clock.c b/arch/arm/mach-exynos/clock.c
index 1c6baa1..18eadf5 100644
--- a/arch/arm/mach-exynos/clock.c
+++ b/arch/arm/mach-exynos/clock.c
@@ -1661,6 +1661,9 @@ unsigned long get_mmc_clk(int dev_index)
 {
enum periph_id id;
 
+   if (cpu_is_exynos4())
+   return exynos4_get_mmc_clk(dev_index);
+
switch (dev_index) {
case 0:
id = PERIPH_ID_SDMMC0;
@@ -1679,12 +1682,7 @@ unsigned long get_mmc_clk(int dev_index)
return -1;
}
 
-   if (cpu_is_exynos5())
-   return clock_get_periph_rate(id);
-   else if (cpu_is_exynos4())
-   return exynos4_get_mmc_clk(dev_index);
-
-   return 0;
+   return clock_get_periph_rate(id);
 }
 
 void set_mmc_clk(int dev_index, unsigned int div)
-- 
1.9.1

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


Re: [U-Boot] [PATCH] ARM: dts: uniphier: use SPDX-License-Identifier

2015-09-24 Thread Masahiro Yamada
2015-09-25 0:16 GMT+09:00 Masahiro Yamada :
> Signed-off-by: Masahiro Yamada 
> ---
>
> This patch is trivial, so I will apply it to u-boot-uniphier/master soon.


Applied to u-boot-uniphier/master.




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


Re: [U-Boot] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH

2015-09-24 Thread Vagrant Cascadian
On 2015-07-26, Paul Kocialkowski wrote:
> In order to achieve reproducible builds in U-Boot, timestamps that are defined
> at build-time have to be somewhat eliminated. The SOURCE_DATE_EPOCH 
> environment
> variable allows setting a fixed value for those timestamps.
...
> However, some other devices might need some more tweaks, especially regarding
> the image generation tools.

With this patch, there is still variation based on timezone in any of
the u-boot.img and u-boot-sunxi-with-spl.bin produced in the Debian
packages:

  https://reproducible.debian.net/rb-pkg/unstable/armhf/u-boot.html

The good news is that all the u-boot.bin targets are produced
reproducibly, so here's to progress!


I think the use of "time = mktime(time_universal);" is where the problem
lies:

> diff --git a/tools/default_image.c b/tools/default_image.c
> index cf5c0d4..18940af 100644
> --- a/tools/default_image.c
> +++ b/tools/default_image.c
> @@ -96,9 +99,25 @@ static void image_set_header(void *ptr, struct stat *sbuf, 
> int ifd,
>   sizeof(image_header_t)),
>   sbuf->st_size - sizeof(image_header_t));
>  
> + source_date_epoch = getenv("SOURCE_DATE_EPOCH");
> + if (source_date_epoch != NULL) {
> + time = (time_t) strtol(source_date_epoch, NULL, 10);
> +
> + time_universal = gmtime();
> + if (time_universal == NULL) {
> + fprintf(stderr, "%s: SOURCE_DATE_EPOCH is not valid\n",
> + __func__);
> + time = 0;
> + } else {
> + time = mktime(time_universal);
> + }
> + } else {
> + time = sbuf->st_mtime;
> + }
> +
>   /* Build new header */
>   image_set_magic(hdr, IH_MAGIC);
> - image_set_time(hdr, sbuf->st_mtime);
> + image_set_time(hdr, time);
>   image_set_size(hdr, sbuf->st_size - sizeof(image_header_t));
>   image_set_load(hdr, params->addr);
>   image_set_ep(hdr, params->ep);
> -- 
> 1.9.1

According to the mktime manpage:

   The  mktime()  function converts a broken-down time structure,
   expressed as local time, to calendar time representation.  

So my interpetation is that it's taking the UTC time and converts it
into local time using the configured timezone... not sure what would be
a viable alternative to mktime.

Running with the TZ=UTC environment variable exported works around the
problem; not sure if it would be appropriate to always run with TZ=UTC
when SOURCE_DATE_EPOCH is set...


live well,
  vagrant


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 v2] sunxi: mmc: Fix clk-delay settings

2015-09-24 Thread Ian Campbell
On Thu, 2015-09-24 at 16:31 +0200, Hans de Goede wrote:
> In recent allwinner kernel sources the mmc/sdio clk-delay settings have
> been slightly tweaked, and for sun9i they are completely different then
> what we are using.
> 
> This commit brings us in sync with what allwinner does, fixing problems
> accessing sdcards on some A33 devices (and likely others).
> 
> For pre sun9i hardware this makes the following changes:
> -At 400Khz change the sample delay from 7 to 0 (first introduced in A31
> sdk)
> -At 50 Mhz change the sample delay from 5 to 4 (first introduced in A23
> sdk)
> -Above 50 MHz change the out delay from 2 to 1 (first introduced in A20
> sdk)
> 
> Signed-off-by: Hans de Goede 

Acked-by: Ian Campbell 

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


[U-Boot] [PATCH] sunxi: Add generic defconfigs for A33 Q8 tablets with 1024x600 / 800x480 LCD

2015-09-24 Thread Hans de Goede
The 7" Q8 tablet enclosure is used for a ton of slightly different cheap
chinese tablets. There are some differences in which accelerometer /
wifi is used, but other then that these are all the same from a u-boot /
kernel pov.

When we get to adding accelerometer support the plan is to add some kind
of autodetection and mangle the dt accordingly (likely using the new quirks
mechanism).

For now this is a non issue as we do not yet have accelerometer
support, and in the future, some sort of auto-detect is the way to go
as we cannot expect users to exactly know what is inside their tablet.

The dts[i] files this commit adds are indentical to the ones submitted
to the upstream kernel.

Signed-off-by: Hans de Goede 
---
 arch/arm/dts/Makefile|  1 +
 arch/arm/dts/sun8i-a33-q8-tablet.dts | 65 
 arch/arm/dts/sun8i-q8-common.dtsi| 84 
 board/sunxi/MAINTAINERS  |  2 +
 configs/q8_a33_tablet_1024x600_defconfig | 24 +
 configs/q8_a33_tablet_800x480_defconfig  | 24 +
 6 files changed, 200 insertions(+)
 create mode 100644 arch/arm/dts/sun8i-a33-q8-tablet.dts
 create mode 100644 arch/arm/dts/sun8i-q8-common.dtsi
 create mode 100644 configs/q8_a33_tablet_1024x600_defconfig
 create mode 100644 configs/q8_a33_tablet_800x480_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 09abc26..1dd5d5d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -156,6 +156,7 @@ dtb-$(CONFIG_MACH_SUN8I_A33) += \
sun8i-a33-et-q8-v1.6.dtb \
sun8i-a33-ga10h-v1.1.dtb \
sun8i-a33-ippo-q8h-v1.2.dtb \
+   sun8i-a33-q8-tablet.dtb \
sun8i-a33-sinlinx-sina33.dtb
 dtb-$(CONFIG_MACH_SUN9I) += \
sun9i-a80-optimus.dtb \
diff --git a/arch/arm/dts/sun8i-a33-q8-tablet.dts 
b/arch/arm/dts/sun8i-a33-q8-tablet.dts
new file mode 100644
index 000..44b3229
--- /dev/null
+++ b/arch/arm/dts/sun8i-a33-q8-tablet.dts
@@ -0,0 +1,65 @@
+/*
+ * Copyright 2015 Hans de Goede 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-a33.dtsi"
+#include "sun8i-q8-common.dtsi"
+
+/ {
+   model = "Q8 A33 Tablet";
+   compatible = "allwinner,q8-a33", "allwinner,sun8i-a33";
+};
+
+/*
+ * FIXME for now we only support host mode and rely on u-boot to have
+ * turned on Vbus which is controlled by the axp223 pmic on the board.
+ *
+ * Once we have axp223 support we should switch to fully supporting otg.
+ */
+_otg {
+   dr_mode = "host";
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/dts/sun8i-q8-common.dtsi 
b/arch/arm/dts/sun8i-q8-common.dtsi
new file mode 100644
index 000..07cd268
--- /dev/null
+++ b/arch/arm/dts/sun8i-q8-common.dtsi
@@ -0,0 +1,84 @@
+/*
+ * Copyright 2015 Hans de Goede 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only 

Re: [U-Boot] SPL boot with NAND on i.MX6 data abort

2015-09-24 Thread Heiko Schocher

Hello Markus,

Am 24.09.2015 um 17:03 schrieb Markus Stelzhammer:

Hi Stefano,


Today I grabbed a different Hardware with a bigger NAND chip (512 instead of 
256MB).
At this hardware, SPL is not able to jump to U-Boot. So currently I assume that 
I might have some
problems when flashing.

Would you be so kind to review my header file if I miss something or if there 
is something
completely wrong?! (I attached it)
The commands I use to flash are the following:

 > ./kobs-ng init -v -x SPL
 > nandwrite --start=0x11000 --pad /dev/mtd0 u-boot.uim (I also tried 
to flash u-boot.bin
and u-boot.imx)

The output I get at boot are the following, but then it stucks.
...
 >>spl:board_init_r()
using memory 0x1830-0x1b50 for malloc()
spl_init()
boot device - 4
spl: nand - using hw ecc
NAND : 0x01:0xdc erasesize=1 (>>0)


From here the values seems bogus to me ... erasesize 1 ?


writesize=-1 (>>0)


negative writesize?


oobsize=65535
chipsize=1095216660225


Such a big chip?


Not support the NAND chips whose oob size is larger then 1024 bytes!
1044479 MiB


Wow ...

I think you have problems with detecting the NAND, maybe
wrong bus timings?

bye,
Heiko


nand_spl_load_image offset:0x00011000 len:64 page:69632
mkimage signature not found - ih_magic = 0
nand_spl_load_image offset:0x00011000 len:409600 page:69632
Jumping to U-Boot
loaded - jumping to U-Boot...image entry point: 0x1780


On 09/24/2015 11:25 AM, Stefano Babic wrote:

Hi Markus,

On 23/09/2015 10:02, Markus Stelzhammer wrote:

Hi all,


I'm currently working on the port of u-boot for our custom boards.
Previously we were using u-boot based on v2013.04 without SPL for our
boards (we have boards with SD also) and this worked for all of our
devices.

As we now have new boards with different (bigger) RAM, I decided to use
the newest bootloader (v2015.10) and enable SPL support.
This is already working on a board with SD-Card but I'm not getting it
to work on the boards with NAND.

When I try to boot, SPL is detecting and loading u-boot but u-boot
throws a "data abort" during "ubifs mount".

u-boot ist also in NAND ? Then SPL has configured correctly the device
else u-boot was not loaded.


The strange thing for me is that when I disable SPL, the board will boot
properly.

You can try to follow the data abort and check which addresses are
involved. We cannot underestimate that the bug is still present in
u-boot, but it appears only together with SPL.


Could anyone give me a hint how I could trace this error?
I can also provide logs or code snippets if needed!

Some initialization done previously in u-boot, is done now by SPL -
check your code if there is something missing.

As your board is not mainlined, we cannot help a much with code.

Best regards,
Stefano Babic



Best regards,
Markus


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



--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
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


[U-Boot] [PATCH] ARM: dts: uniphier: use SPDX-License-Identifier

2015-09-24 Thread Masahiro Yamada
Signed-off-by: Masahiro Yamada 
---

This patch is trivial, so I will apply it to u-boot-uniphier/master soon.

 arch/arm/dts/uniphier-pinctrl.dtsi | 38 +-
 1 file changed, 1 insertion(+), 37 deletions(-)

diff --git a/arch/arm/dts/uniphier-pinctrl.dtsi 
b/arch/arm/dts/uniphier-pinctrl.dtsi
index f67445f..b584213 100644
--- a/arch/arm/dts/uniphier-pinctrl.dtsi
+++ b/arch/arm/dts/uniphier-pinctrl.dtsi
@@ -3,43 +3,7 @@
  *
  * Copyright (C) 2015 Masahiro Yamada 
  *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- *  a) This file 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.
- *
- * This file is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * Or, alternatively,
- *
- *  b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
+ * SPDX-License-Identifier:GPL-2.0+X11
  */
 
  {
-- 
1.9.1

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


[U-Boot] [PATCH 1/3] fix: fdtdec: allow parse 'reg' property with zero value in '#size-cells'

2015-09-24 Thread Przemyslaw Marczak
After rework of lib/fdtdec.c by commit:

commit 02464e386bb5f0a022c121f95ae75cf583759d95
Author: Stephen Warren 
Date:   Thu Aug 6 15:31:02 2015 -0600

the function fdtdec_get_addr() doesn't work as previous,
because the implementation assumes that properties '#address-cells'
and '#size-cells' are equal to 1, which can be not true sometimes.

The new API introduced fdtdec_get_addr_size_auto_parent() for the 'reg'
property parsing, but the implementation assumes, that #size-cells
can't be less than 1.

This causes that the following children's 'reg' property can't be reached:

parent@0x0 {
 #address-cells = <1>;
 #size-cells = <0>;
 children@0x100 {
 reg = < 0x100 >;
 };
};

Change the condition value from '1' to '0', which allows parsing property
with at least zero #size-cells, fixes the issue.

Now, fdtdec_get_addr_size_auto_parent() works properly.

Signed-off-by: Przemyslaw Marczak 
---
 lib/fdtdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 9f0b65d..9cf57b9 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -149,7 +149,7 @@ fdt_addr_t fdtdec_get_addr_size_auto_parent(const void 
*blob, int parent,
}
 
ns = fdt_size_cells(blob, parent);
-   if (ns < 1) {
+   if (ns < 0) {
debug("(bad #size-cells)\n");
return FDT_ADDR_T_NONE;
}
-- 
1.9.1

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


Re: [U-Boot] SPL boot with NAND on i.MX6 data abort

2015-09-24 Thread Stefano Babic
Hi Markus,

On 24/09/2015 17:03, Markus Stelzhammer wrote:
> Hi Stefano,
> 
> 
> Today I grabbed a different Hardware with a bigger NAND chip (512
> instead of 256MB).
> At this hardware, SPL is not able to jump to U-Boot. So currently I
> assume that I might have some problems when flashing.
> 

If you are not flashing correctly, SPL does not run. It looks like that
your board boots (SPL runs).

> Would you be so kind to review my header file if I miss something or if
> there is something completely wrong?! (I attached it)
> The commands I use to flash are the following:
> 
>> ./kobs-ng init -v -x SPL
>> nandwrite --start=0x11000 --pad /dev/mtd0 u-boot.uim
> (I also tried to flash u-boot.bin and u-boot.imx)
> 
> The output I get at boot are the following, but then it stucks.
> ...
>>>spl:board_init_r()
> using memory 0x1830-0x1b50 for malloc()
> spl_init()
> boot device - 4
> spl: nand - using hw ecc
> NAND : 0x01:0xdc erasesize=1 (>>0)

erasesize = 1 ??

> writesize=-1 (>>0)
> oobsize=65535
> chipsize=1095216660225
> Not support the NAND chips whose oob size is larger then 1024 bytes!
> 1044479 MiB

This larger NAND cannot be recognized correctly - it is not a problem by
flashing.

You have to investigate why this NAND (even if ONFI) is not recognized,
but it is a different problem as the one you reported previously.

Best regards,
Stefano Babic


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


Re: [U-Boot] [PATCH] sunxi: Add generic defconfigs for A33 Q8 tablets with 1024x600 / 800x480 LCD

2015-09-24 Thread Ian Campbell
On Thu, 2015-09-24 at 17:24 +0200, Hans de Goede wrote:
> The 7" Q8 tablet enclosure is used for a ton of slightly different cheap
> chinese tablets. There are some differences in which accelerometer /
> wifi is used, but other then that these are all the same from a u-boot /
> kernel pov.
> 
> When we get to adding accelerometer support the plan is to add some kind
> of autodetection and mangle the dt accordingly (likely using the new
> quirks
> mechanism).
> 
> For now this is a non issue as we do not yet have accelerometer
> support, and in the future, some sort of auto-detect is the way to go
> as we cannot expect users to exactly know what is inside their tablet.
> 
> The dts[i] files this commit adds are indentical to the ones submitted

"identical"

> to the upstream kernel.
> 
> Signed-off-by: Hans de Goede 

Acked-by: Ian Campbell 

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


[U-Boot] pull request: u-boot-uniphier/master (2nd round)

2015-09-24 Thread Masahiro Yamada
Hi Tom,

Here is a pretty big series for UniPhier SoC changes.
pinctrl drivers, various fixes, refactoring, new SoC/board support, etc.


Diff from the previous one:
  - fix memory over-run bug in a command to display boot-mode
  - sort pin-groups alphabetically in pinctrl drivers
  - Add one more patch to convert a license block to SPDX



The following changes since commit 8a5f6129d1450f5ff92a55cfcfd7b96ee019e303:

  pinctrl: move dm_scan_fdt_node() out of pinctrl uclass (2015-09-19
15:42:15 -0600)

are available in the git repository at:

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

for you to fetch changes up to a4bb44b027705f8c05fc525180cabaa3769247bb:

  ARM: dts: uniphier: use SPDX-License-Identifier (2015-09-25 01:01:37 +0900)


Masahiro Yamada (33):
  pinctrl: uniphier: add UniPhier pinctrl core support
  pinctrl: uniphier: add UniPhier PH1-LD4 pinctrl driver
  pinctrl: uniphier: add UniPhier PH1-Pro4 pinctrl driver
  pinctrl: uniphier: add UniPhier PH1-sLD8 pinctrl driver
  pinctrl: uniphier: add UniPhier PH1-Pro5 pinctrl driver
  pinctrl: uniphier: add UniPhier ProXstream2 pinctrl driver
  pinctrl: uniphier: add UniPhier PH1-LD6b pinctrl driver
  ARM: uniphier: enable simple-bus driver for SPL
  ARM: uniphier: increase CONFIG_SYS_MALLOC_F_LEN to bind all nodes
  ARM: dts: uniphier: prepare device trees to use pinctrl in SPL
  ARM: uniphier: enable PINCTRL and SPL_PINCTRL
  ARM: uniphier: drop ad-hoc early pin-muxing settings
  ARM: uniphier: drop ad-hoc input enable settings
  ARM: uniphier: drop DCC micro support card support
  ARM: uniphier: enable setexpr command
  ARM: uniphier: change the external bus address mapping
  ARM: uniphier: remove ifdef CONFIG_{SOC} conditionals from sg-regs.h
  ARM: uniphier: parse device tree to determine DRAM base and size
  ARM: uniphier: remove unused header file
  ARM: uniphier: remove useless wrapper functions
  ARM: uniphier: refactor LED function
  ARM: uniphier: move CONFIG_SUPPORT_CARD_* macros to local file
  ARM: uniphier: allow to disable CONFIG_MICRO_SUPPORT_CARD
  ARM: uniphier: rename CONFIG_MACH_* to CONFIG_ARCH_UNIPHIER_*
  ARM: uniphier: delete unneeded input enable for low-level debug
  ARM: uniphier: fix glitch signal problem for low-level debug
  ARM: uniphier: unify low-level debug init code
  ARM: uniphier: remove kernel parameter settings from environment
  ARM: uniphier: allow to enable multiple SoCs
  ARM: uniphier: add PH1-Pro5 support
  ARM: uniphier: add ProXstream2 and PH1-LD6b support
  ARM: uniphier: fix init page table for ProXstream2/PH1-LD6b USB boot
  ARM: dts: uniphier: use SPDX-License-Identifier

 arch/arm/dts/Makefile
   |   5 +-
 arch/arm/dts/uniphier-ph1-ld4-ref.dts
   |  16 ++-
 arch/arm/dts/uniphier-ph1-ld6b-ref.dts
   |  17 ++-
 arch/arm/dts/uniphier-ph1-pro4-ref.dts
   |  16 ++-
 arch/arm/dts/uniphier-ph1-pro5-4kbox.dts
   |  64 
 arch/arm/dts/uniphier-ph1-sld8-ref.dts
   |  16 ++-
 arch/arm/dts/uniphier-pinctrl.dtsi
   |  38 +--
 arch/arm/dts/uniphier-proxstream2-gentil.dts
   |  62 +++
 arch/arm/dts/uniphier-proxstream2-vodka.dts
   |  62 +++
 arch/arm/mach-uniphier/Kconfig
   |  95 -
 arch/arm/mach-uniphier/Makefile
   |  21 ++--
 arch/arm/mach-uniphier/bcu/Makefile
   |   3 +
 arch/arm/mach-uniphier/{ph1-ld4/bcu_init.c => bcu/bcu-ph1-ld4.c}
   |   8 +-
 arch/arm/mach-uniphier/{ph1-sld3/bcu_init.c => bcu/bcu-ph1-sld3.c}
   |   8 +-
 arch/arm/mach-uniphier/board_common.c
   |  23 +---
 arch/arm/mach-uniphier/board_early_init_f.c
   |  73 ++---
 arch/arm/mach-uniphier/board_early_init_r.c
   |   7 +-
 arch/arm/mach-uniphier/boards.c
   | 130 +++
 arch/arm/mach-uniphier/boot-mode/Makefile
   |   9 ++
 .../{ph1-pro4/boot-mode.c => boot-mode/boot-mode-ph1-ld4.c}
   |  21 ++--
 arch/arm/mach-uniphier/boot-mode/boot-mode-ph1-pro5.c
   |  75 +
 .../{ph1-sld3/boot-mode.c => boot-mode/boot-mode-ph1-sld3.c}
   |  23 ++--
 arch/arm/mach-uniphier/boot-mode/boot-mode-proxstream2.c
   |  75 +
 arch/arm/mach-uniphier/boot-mode/boot-mode.c
   |  45 
 arch/arm/mach-uniphier/clk/Makefile
   |   7 ++
 arch/arm/mach-uniphier/{ph1-ld4/clkrst_init.c => clk/clk-ph1-ld4.c}
   |   3 +-
 arch/arm/mach-uniphier/{ph1-pro4/clkrst_init.c => clk/clk-ph1-pro4.c}
   |   3 +-
 arch/arm/mach-uniphier/clk/clk-ph1-pro5.c
   |  44 
 arch/arm/mach-uniphier/clk/clk-proxstream2.c
   |  50 +
 arch/arm/mach-uniphier/cmd_pinmon.c
   |  43 ++--
 arch/arm/mach-uniphier/ddrphy/Makefile
   |   3 +
 .../arm/mach-uniphier/{ph1-ld4/ddrphy_init.c =>
ddrphy/ddrphy-ph1-ld4.c} |   4 +-
 .../mach-uniphier/{ph1-pro4/ddrphy_init.c =>
ddrphy/ddrphy-ph1-pro4.c}   |   4 +-
 .../mach-uniphier/{ph1-sld8/ddrphy_init.c =>
ddrphy/ddrphy-ph1-sld8.c}   |   4 

Re: [U-Boot] [PATCH 00/11] vexpress64 FVP and Juno configuration updates

2015-09-24 Thread Linus Walleij
On Wed, Sep 23, 2015 at 10:25 AM, Ryan Harkin  wrote:

> This patch series updates the default configuration of the vexpress64 FVP
> and Juno platforms to allow it to work on a variety of setups without
> modification by the user.
>
> [PATCH 01/11] vexpress64: fix checkpatch warnings
> [PATCH 02/11] vexpress64: Kconfig: tidy up
> [PATCH 03/11] Kconfig: add CONFIG_SYS_BOOTM_LEN
> [PATCH 04/11] vexpress64: Kconfig: add CONFIG_SYS_BOOTM_LEN
> [PATCH 05/11] vexpress64: fvp dram: add DRAM configuration
> [PATCH 06/11] vexpress64: juno: add androidboot.hardware=juno
> [PATCH 07/11] common/armflash: add command to check if image exists
> [PATCH 08/11] common/armflash: load_image returns success or failure
> [PATCH 09/11] vexpress64: juno: add optional initrd
> [PATCH 10/11] vexpress64: juno: add alternate kernel and device tree
> [PATCH 11/11] vexpress64: juno: use /dev/sda2

I've reviewed all these off Ryan's GIT tree and they carry my Reviewed-by
so please merge.

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


Re: [U-Boot] [PATCHv3] arm: socfpga: Enable saveenv for SD/MMC

2015-09-24 Thread Pavel Machek
Hi!

> From: Dinh Nguyen 
> 
> Enable the able to save the environment variables when SD/MMC is used.
> 
> Signed-off-by: Dinh Nguyen 
> ---
> v3: Only define ENV_IS_NOWHERE if env is not in MMC, NAND, FAT, and SPI_FLASH
> v2: Move this option to be on a per-board basis
> Add config for socfpga_cyclone5 and socfpga_arria5
> ---
>  include/configs/socfpga_arria5_socdk.h   | 4 
>  include/configs/socfpga_common.h | 5 +
>  include/configs/socfpga_cyclone5_socdk.h | 4 
>  include/configs/socfpga_de0_nano_soc.h   | 4 
>  include/configs/socfpga_sockit.h | 4 
>  5 files changed, 21 insertions(+)
> 
> diff --git a/include/configs/socfpga_arria5_socdk.h 
> b/include/configs/socfpga_arria5_socdk.h
> index 3193684..b75b0a2 100644
> --- a/include/configs/socfpga_arria5_socdk.h
> +++ b/include/configs/socfpga_arria5_socdk.h
> @@ -59,6 +59,10 @@
>  
>  #endif
>  
> +#define CONFIG_ENV_IS_IN_MMC
> +#define CONFIG_SYS_MMC_ENV_DEV   0   /* device 0 */
> +#define CONFIG_ENV_OFFSET512 /* just after the MBR */
> +
>  /* USB */
>  #ifdef CONFIG_CMD_USB
>  #define CONFIG_USB_DWC2_REG_ADDR SOCFPGA_USB1_ADDRESS
> diff --git a/include/configs/socfpga_common.h 
> b/include/configs/socfpga_common.h
> index a2811ba..b3fba5b 100644
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -281,7 +281,12 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
>  #define CONFIG_SYS_CONSOLE_IS_IN_ENV
>  #define CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE
>  #define CONFIG_SYS_CONSOLE_ENV_OVERWRITE
> +#if !defined CONFIG_ENV_IS_IN_MMC && \
> +!defined CONFIG_ENV_IS_IN_NAND && \
> +!defined CONFIG_ENV_IS_IN_FAT && \
> +!defined CONFIG_ENV_IS_IN_SPI_FLASH
>  #define CONFIG_ENV_IS_NOWHERE
> +#endif
>  #define CONFIG_ENV_SIZE  4096
>


Actually... if we decided that position of u-boot environment is
board-specific, size should be board-specific, too.

But it might be better to just define

#define ENV_IN_MMC_SECTOR_1

in each board, and have the common code in socfpga_common.h... so that
we can change environment size for all boards using "after mmc"
layout, for example.

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


Re: [U-Boot] [PATCH] nios2 : convert altera_pio to driver model

2015-09-24 Thread Marek Vasut
On Thursday, September 24, 2015 at 11:15:05 AM, Thomas Chou wrote:
> Convert altera_pio to driver model.
> 
> Signed-off-by: Thomas Chou 

Hi,

now this is quite a nice patch :-)

> ---
>  arch/nios2/dts/3c120_devboard.dts  |  38 
>  arch/nios2/include/asm/gpio.h  |  80 +---
>  board/altera/nios2-generic/nios2-generic.c |   7 -
>  configs/nios2-generic_defconfig|   2 +
>  drivers/gpio/Kconfig   |   7 +
>  drivers/gpio/altera_pio.c  | 316
> +++-- include/configs/nios2-generic.h|
>  20 --
>  7 files changed, 124 insertions(+), 346 deletions(-)
> 

[...]

> +static int altera_pio_get_value(struct udevice *dev, unsigned pin)
>  {
> - int i;
> - int j;
> - int gidx;
> - u32 mask;
> + struct altera_pio_platdata *plat = dev_get_platdata(dev);
> + struct altera_pio_regs *const regs = plat->regs;
> 
> - for (i = 0; i < pio_num; ++i) {
> - printf("Altera PIO % 2d, @0x%08x, "
> - "width: %u, label: %s\n",
> -i, pios[i].base, pios[i].width, pios[i].label);
> - gidx = pios[i].gidx;
> - for (j = gidx; j < (gidx + pios[i].width); ++j) {
> - mask = 1 << (j - gidx);
> - printf("\tGPIO % 4d: %s %s [%c] %s\n",
> - gpios[j].num,
> - gpios[j].pio->sh_dir & mask ? "out" : " in",
> - gpio_get_value(gpios[j].num) ? "set" : "clr",
> - altera_pio_is_gidx_used(j) ? 'x' : ' ',
> - gpios[j].reqlabel);
> - }
> - }
> + return !!(readl(>data) & (1 << pin));

You can drop the double negation here, the API design is done such that
0 is log. low and non-zero is log. high .

[...]

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


Re: [U-Boot] [PATCH 2/3] fix: s5p_gpio: call: dev_get_addr() instead of fdtdec_get_addr()

2015-09-24 Thread Stephen Warren

On 09/24/2015 09:29 AM, Przemyslaw Marczak wrote:

After rework in lib/fdtdec.c, the function fdtdec_get_addr()
doesn't work for nodes with #size-cells property, set to 0.

To get GPIO's 'reg' property, the code should use one of:
fdtdec_get_addr_size_auto_no/parent() function.

Fortunately dm core provides a function to get the property.

This commit reworks function gpio_exynos_bind(), to properly
use dev_get_addr() for GPIO device.

This prevents setting a wrong base register for Exynos GPIOs.


Migrating everything to dev_get_addr() is the correct long-term fix, so 
this patch,


Acked-by: Stephen Warren 

... although I'd have liked to see a smaller diff that didn't both 
re-order all the code /and/ call a different function, but I suppose 
that's not possible given the need to pass the device object to 
dev_get_addr(). You could have used fdtdec_get_addr_size_auto_parent() 
directly.



I think it'd be good to fix fdtdec_get_addr_size() to have the same 
semantics that it previously did. There might be other code in U-Boot 
that's affected by the same issue, and fixing fdtdec_get_addr_size() 
would make sure that all got fixed too. Are you willing to send that 
patch too?


Essentially, fdtdec_get_addr_size() used to assume:

#address-cells == sizeof(fdt_addr_t)
if sizep == NULL:
#size-cells == 0
else:
#size-cells == sizeof(fdt_addr_t)

However, it now assumes:

#address-cells == sizeof(fdt_addr_t)
#size-cells == sizeof(fdt_addr_t)

Let's just add that condition back by doing something like the following 
in fdtdec_get_addr_size():


u32 ns;

if (sizep)
ns = sizeof(fdt_size_t) / sizeof(fdt32_t);
else
ns = 0;

... and replacing the ns parameter that's passed to 
fdtdec_get_addr_size_fixed() with that variable, rather than hard-coding it.

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


Re: [U-Boot] [PATCHv3] arm: socfpga: Enable saveenv for SD/MMC

2015-09-24 Thread Marek Vasut
On Thursday, September 24, 2015 at 07:47:46 PM, Pavel Machek wrote:
> Hi!
> 
> > From: Dinh Nguyen 
> > 
> > Enable the able to save the environment variables when SD/MMC is used.
> > 
> > Signed-off-by: Dinh Nguyen 
> > ---
> > v3: Only define ENV_IS_NOWHERE if env is not in MMC, NAND, FAT, and
> > SPI_FLASH v2: Move this option to be on a per-board basis
> > 
> > Add config for socfpga_cyclone5 and socfpga_arria5
> > 
> > ---
> > 
> >  include/configs/socfpga_arria5_socdk.h   | 4 
> >  include/configs/socfpga_common.h | 5 +
> >  include/configs/socfpga_cyclone5_socdk.h | 4 
> >  include/configs/socfpga_de0_nano_soc.h   | 4 
> >  include/configs/socfpga_sockit.h | 4 
> >  5 files changed, 21 insertions(+)
> > 
> > diff --git a/include/configs/socfpga_arria5_socdk.h
> > b/include/configs/socfpga_arria5_socdk.h index 3193684..b75b0a2 100644
> > --- a/include/configs/socfpga_arria5_socdk.h
> > +++ b/include/configs/socfpga_arria5_socdk.h
> > @@ -59,6 +59,10 @@
> > 
> >  #endif
> > 
> > +#define CONFIG_ENV_IS_IN_MMC
> > +#define CONFIG_SYS_MMC_ENV_DEV 0   /* device 0 */
> > +#define CONFIG_ENV_OFFSET  512 /* just after the MBR */
> > +
> > 
> >  /* USB */
> >  #ifdef CONFIG_CMD_USB
> >  #define CONFIG_USB_DWC2_REG_ADDR   SOCFPGA_USB1_ADDRESS
> > 
> > diff --git a/include/configs/socfpga_common.h
> > b/include/configs/socfpga_common.h index a2811ba..b3fba5b 100644
> > --- a/include/configs/socfpga_common.h
> > +++ b/include/configs/socfpga_common.h
> > @@ -281,7 +281,12 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
> > 
> >  #define CONFIG_SYS_CONSOLE_IS_IN_ENV
> >  #define CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE
> >  #define CONFIG_SYS_CONSOLE_ENV_OVERWRITE
> > 
> > +#if !defined CONFIG_ENV_IS_IN_MMC && \
> > +!defined CONFIG_ENV_IS_IN_NAND && \
> > +!defined CONFIG_ENV_IS_IN_FAT && \
> > +!defined CONFIG_ENV_IS_IN_SPI_FLASH
> > 
> >  #define CONFIG_ENV_IS_NOWHERE
> > 
> > +#endif
> > 
> >  #define CONFIG_ENV_SIZE4096
> 
> Actually... if we decided that position of u-boot environment is
> board-specific, size should be board-specific, too.
> 
> But it might be better to just define
> 
> #define ENV_IN_MMC_SECTOR_1
> 
> in each board, and have the common code in socfpga_common.h... so that
> we can change environment size for all boards using "after mmc"
> layout, for example.
> 
> Ouch and 4K is way too small.

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


Re: [U-Boot] [PATCH v7 1/6] spi: cadence_qspi: move trigger base configuration in init

2015-09-24 Thread Jagan Teki
Hi Wolfgang,

On 25 September 2015 at 00:26, Wolfgang Denk  wrote:
> Dear Vikas,
>
> In message <9026814fbf99304f9fa3ac3fb72f3e2f04bff85...@safex1mail4.st.com> 
> you wrote:
>>
>> > CQSPI_INDIRECTTRIGGER_ADDR_MASK,
>> > > +plat->regbase + CQSPI_REG_INDIRECTTRIGGER);
>> >
>> > I did not mention this explicitly, so I do it here:
>> >
>> > Please fix this type cast issue globally, in all your patches.
>>
>> I agree it should be done but this patchset is not introducing the
>> typecasting, it only moves the statement to another logical location.
>> e.g. the above code is not new, it was just moved from other location
>> to init function.
>
> I am fully aware of that.  But I feel if we touch a piece of code, and
> notice it has issues, we should fix these while we are at it.
> Otherwise there is always the risk that we add more and more such bad
> code, and/or forget about cleaning up later.
>
>> This fix to remove typecasting from all variables (triggerbase,
>> flashbase,regbase) is a significant change in many routines in terms
>> of parameters passing/handling & deserve separate patch/set.
>
> Hm... this makes me wander about the overall code quality.  I have to
> admit that I don't have any in-depth understanding of this specific
> driver, but it looks well, let's state it looks pretty much
> dfferent from the corresponding Linux kernel driver code.  Which does
> not have such issues.  So if you say it would take _significant_
> efforts to clean up this implementation  I'm asking myuself how much
> more (or less?) effort would it take to adapt the Linux driver for
> U-Boot instead?  Having a common driver code base has been very
> beneficial in a number of other areas, too...
>
>> I am ready to send a separate patch/set for the same later. Please
>> let me know if you agree.
>
> If we follow strict rules, such a cleanup patch should go in first.

Looks like driver code itself has some issues and Vikas made changes
wrt to existing code, cleaning up existing driver and then make Vikas
changes might be reasonable and time consuming task.

What if we move Vikas changes now for this release as he stated in
previous mail "about sending patches later". My idea is someone is
trying to clean it up existing code then give him a chance to move his
code as well because he sent couple times.

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


Re: [U-Boot] [PATCH v7 1/6] spi: cadence_qspi: move trigger base configuration in init

2015-09-24 Thread Wolfgang Denk
Dear Vikas,

In message <9026814fbf99304f9fa3ac3fb72f3e2f04bff85...@safex1mail4.st.com> you 
wrote:
>
> > CQSPI_INDIRECTTRIGGER_ADDR_MASK,
> > > +plat->regbase + CQSPI_REG_INDIRECTTRIGGER);
> > 
> > I did not mention this explicitly, so I do it here:
> > 
> > Please fix this type cast issue globally, in all your patches.
>
> I agree it should be done but this patchset is not introducing the
> typecasting, it only moves the statement to another logical location.
> e.g. the above code is not new, it was just moved from other location
> to init function.

I am fully aware of that.  But I feel if we touch a piece of code, and
notice it has issues, we should fix these while we are at it.
Otherwise there is always the risk that we add more and more such bad
code, and/or forget about cleaning up later.

> This fix to remove typecasting from all variables (triggerbase,
> flashbase,regbase) is a significant change in many routines in terms
> of parameters passing/handling & deserve separate patch/set.

Hm... this makes me wander about the overall code quality.  I have to
admit that I don't have any in-depth understanding of this specific
driver, but it looks well, let's state it looks pretty much
dfferent from the corresponding Linux kernel driver code.  Which does
not have such issues.  So if you say it would take _significant_
efforts to clean up this implementation  I'm asking myuself how much
more (or less?) effort would it take to adapt the Linux driver for
U-Boot instead?  Having a common driver code base has been very
beneficial in a number of other areas, too...

> I am ready to send a separate patch/set for the same later. Please
> let me know if you agree.

If we follow strict rules, such a cleanup patch should go in first.

Thanks.

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It seems intuitively obvious to me, which  means  that  it  might  be
wrong. -- Chris Torek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v7 1/6] spi: cadence_qspi: move trigger base configuration in init

2015-09-24 Thread Vikas MANOCHA
Thanks Wolfgang,

> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de]
> Sent: Thursday, September 24, 2015 12:22 AM
> To: Vikas MANOCHA
> Cc: u-boot@lists.denx.de; s...@denx.de; grmo...@opensource.altera.com;
> jt...@openedev.com; ma...@denx.de
> Subject: Re: [U-Boot] [PATCH v7 1/6] spi: cadence_qspi: move trigger base
> configuration in init
> 
> Dear Vikas,
> 
> In message <1443053976-9112-2-git-send-email-vikas.mano...@st.com>
> you wrote:
> > No need to configure indirect trigger address for every read/write.
> ...
> > /* Indirect mode configurations */
> > writel((plat->sram_size/2), plat->regbase +
> > CQSPI_REG_SRAMPARTITION);
> > +   writel((u32)plat->ahbbase &
> CQSPI_INDIRECTTRIGGER_ADDR_MASK,
> > +  plat->regbase + CQSPI_REG_INDIRECTTRIGGER);
> 
> I did not mention this explicitly, so I do it here:
> 
> Please fix this type cast issue globally, in all your patches.

I agree it should be done but this patchset is not introducing the typecasting, 
it only moves the statement to another logical location.
e.g. the above code is not new, it was just moved from other location to init 
function.

This fix to remove typecasting from all variables (triggerbase, 
flashbase,regbase) is a significant change in many routines in terms of 
parameters passing/handling & deserve separate patch/set.
I am ready to send a separate patch/set for the same later.  Please let me know 
if you agree.

Rgds,
Vikas

> Thanks.
> 
> Best regards,
> 
> Wolfgang Denk
> 
> --
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> "Marriage is like a cage; one sees the birds outside desperate to get
> in, and those inside desperate to get out."   - Montaigne
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


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

2015-09-24 Thread Tom Rini
On Thu, Sep 24, 2015 at 10:27:50AM +0200, Marek Vasut wrote:

> Hi, here's an updated one
> 
> The following changes since commit 8a5f6129d1450f5ff92a55cfcfd7b96ee019e303:
> 
>   pinctrl: move dm_scan_fdt_node() out of pinctrl uclass (2015-09-19 15:42:15 
> -0600)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-socfpga.git 
> 
> for you to fetch changes up to aad604aef36e90bd42b4ce1969960f3427be4a7a:
> 
>   arm: socfpga: Enable env support on MCV (2015-09-24 09:07:58 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] Please pull fsl-qoriq master

2015-09-24 Thread Tom Rini
On Tue, Sep 22, 2015 at 08:01:36AM -0700, York Sun wrote:

> Tom,
> 
> The following changes since commit 1fb8d7933924aa5deb7e722d64c1d9fc7f0b2b82:
> 
>   Merge git://git.denx.de/u-boot-x86 (2015-09-17 17:00:08 -0400)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-fsl-qoriq.git master
> 
> for you to fetch changes up to a857d5f835c53f7b66de61b19120ea1188e94999:
> 
>   drivers/net/vsc9953: Add GPL-2.0+ SPDX-License-Identifier (2015-09-21 
> 08:29:48
> -0700)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH v2 2/8] ARM: hikey: Add ATF makefile referenced by README

2015-09-24 Thread Tom Rini
On Thu, Sep 10, 2015 at 09:55:12PM +0100, Peter Griffin wrote:

> Rather than relying on an external URL in the README
> include the Makefile in the hikey directory.
> 
> Signed-off-by: Peter Griffin 
> ---
>  board/hisilicon/hikey/build-tf.mak | 42 
> ++
>  1 file changed, 42 insertions(+)
>  create mode 100644 board/hisilicon/hikey/build-tf.mak
> 
> diff --git a/board/hisilicon/hikey/build-tf.mak 
> b/board/hisilicon/hikey/build-tf.mak
> new file mode 100644
> index 000..cebb34b
> --- /dev/null
> +++ b/board/hisilicon/hikey/build-tf.mak
> @@ -0,0 +1,42 @@
> +CROSS_COMPILE:= aarch64-linux-gnu-
> +output_dir   := $(PWD)/../bin
> +makejobs := $(shell grep '^processor' /proc/cpuinfo | sort -u | wc -l)
> +makethreads  := $(shell dc -e "$(makejobs) 1 + p")
> +make_options := GCC49_AARCH64_PREFIX=$CROSS_COMPILE \
> + -j$(makethreads) -l$(makejobs)
> +
> +BL30_HIKEY   := $(output_dir)/mcuimage.bin
> +BL33_HIKEY   := $(output_dir)/u-boot-hikey.bin
> +
> +.PHONY: help
> +help:
> + @echo "  Common Makefile  "
> + @echo "example:"
> + @echo "make -f build-tf.mak build"
> +
> +.PHONY: have-crosscompiler
> +have-crosscompiler:
> + @echo -n "Check that $(CROSS_COMPILE)gcc is available..."
> + @which $(CROSS_COMPILE)gcc > /dev/null ; \
> + if [ ! $$? -eq 0 ] ; then \
> +echo "ERROR: cross-compiler $(CROSS_COMPILE)gcc not in PATH=$$PATH!" 
> ; \
> +echo "ABORTING." ; \
> +exit 1 ; \
> + else \
> +echo "OK" ;\
> + fi
> +
> +build: have-crosscompiler FORCE
> + @echo "Build TF for Hikey..."
> + rm -rf build/
> + CROSS_COMPILE=$(CROSS_COMPILE) \
> + make all fip \
> + BL30=$(BL30_HIKEY) \
> + BL33=$(BL33_HIKEY) \
> + DEBUG=1 \
> + PLAT=hikey
> + @echo "Copy resulting binaries..."
> + cp build/hikey/debug/bl1.bin $(output_dir)/bl1-hikey.bin
> + cp build/hikey/debug/fip.bin $(output_dir)/fip-hikey.bin
> +
> +FORCE:

For the record, I'm not super happy about including makefiles/scripts
for other projects.  This seems complex enough that we need to handle
the case for now at least, so, yeah, OK, we'll do it like this for now.

-- 
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 v7 1/6] spi: cadence_qspi: move trigger base configuration in init

2015-09-24 Thread Wolfgang Denk
Dear Jagan,

In message 

Re: [U-Boot] [PATCH v5 0/3] add pinctrl driver framework

2015-09-24 Thread Linus Walleij
On Wed, Aug 26, 2015 at 8:44 PM, Masahiro Yamada
 wrote:

> I am trying my best to have this subsystem as DT-compatible with Linux
> as possible, also saving memory foot print as a boot loader.
>
> It would be very appreciated if Linus Walleij, the maintainer of
> pinctrl subsystem in Linux, would check this series if he could find
> some time.

Unfortunately I am short on time for doing U-Boot reviews too ...
Massive mail backlog.

Is this code already merged?

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


Re: [U-Boot] [PATCH v5 0/3] add pinctrl driver framework

2015-09-24 Thread Masahiro Yamada
Hi, Linus,


2015-09-25 7:31 GMT+09:00 Linus Walleij :
> On Wed, Aug 26, 2015 at 8:44 PM, Masahiro Yamada
>  wrote:
>
>> I am trying my best to have this subsystem as DT-compatible with Linux
>> as possible, also saving memory foot print as a boot loader.
>>
>> It would be very appreciated if Linus Walleij, the maintainer of
>> pinctrl subsystem in Linux, would check this series if he could find
>> some time.
>
> Unfortunately I am short on time for doing U-Boot reviews too ...
> Massive mail backlog.
>
> Is this code already merged?
>

Yes, it it in the mainline now.


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


Re: [U-Boot] [Patch v2 08/16] net/fm: fix compile warnings for 64-bit platform

2015-09-24 Thread Hou Zhiqiang


> -Original Message-
> From: Wood Scott-B07421
> Sent: 2015年9月18日 2:14
> To: Gong Qianyu-B52263
> Cc: u-boot@lists.denx.de; Hu Mingkai-B21284; Sun York-R58495; Hou
> Zhiqiang-B48286; Song Wenbin-B53747; Xie Shaohui-B21989; Wood Scott-
> B07421
> Subject: Re: [Patch v2 08/16] net/fm: fix compile warnings for 64-bit
> platform
> 
> On Thu, 2015-09-17 at 15:06 +0800, Gong Qianyu wrote:
> > This patch fixes such compile warnings:
> >
> > drivers/net/fm/eth.c: In function 'fm_eth_recv':
> > drivers/net/fm/eth.c:549:11: warning: cast to pointer from integer of
> > different size [-Wint-to-pointer-cast]
> >   data = (u8 *)in_be32(>buf_ptr_lo);
> > drivers/net/fm/fm.c: In function 'fm_muram_alloc':
> > drivers/net/fm/fm.c:52:9: warning: cast to pointer from integer of
> > different size [-Wint-to-pointer-cast]
> >   memset((void *)ret, 0, size);
> > drivers/net/fm/fm.c: In function 'fm_init_muram':
> > drivers/net/fm/fm.c:59:13: warning: cast from pointer to integer of
> > different size [-Wpointer-to-int-cast]
> >   u32 base = (u32)reg;
> >
> > Just make the cast explicit for them.
> >
> > Signed-off-by: Gong Qianyu 
> > ---
> >  drivers/net/fm/eth.c | 31 ---
> > drivers/net/fm/fm.c  |  4 ++--
> >  2 files changed, 18 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c index
> > 12eb9b8..6ef0afb 100644
> > --- a/drivers/net/fm/eth.c
> > +++ b/drivers/net/fm/eth.c
> > @@ -120,12 +120,12 @@ static int tgec_is_fibre(struct eth_device *dev)
> >
> >  static u16 muram_readw(u16 *addr)
> >  {
> > - u32 base = (u32)addr & ~0x3;
> > + ulong base = (ulong)addr & ~0x3;
> 
> This will still truncate the address at 32 bits.  It needs to be ~0x3UL.
> 
> 
> >   u32 val32 = in_be32((u32 *)base);
> >   int byte_pos;
> >   u16 ret;
> >
> > - byte_pos = (u32)addr & 0x3;
> > + byte_pos = (ulong)addr & 0x3;
> >   if (byte_pos)
> >   ret = (u16)(val32 & 0x);
> >   else
> > @@ -136,12 +136,12 @@ static u16 muram_readw(u16 *addr)
> >
> >  static void muram_writew(u16 *addr, u16 val)  {
> > - u32 base = (u32)addr & ~0x3;
> > + ulong base = (ulong)addr & ~0x3;
> >   u32 org32 = in_be32((u32 *)base);
> >   u32 val32;
> >   int byte_pos;
> >
> > - byte_pos = (u32)addr & 0x3;
> > + byte_pos = (ulong)addr & 0x3;
> >   if (byte_pos)
> >   val32 = (org32 & 0x) | val;
> >   else
> > @@ -217,12 +217,12 @@ static int fm_eth_rx_port_parameter_init(struct
> > fm_eth *fm_eth)
> >   int i;
> >
> >   /* alloc global parameter ram at MURAM */
> > - pram = (struct fm_port_global_pram *)fm_muram_alloc(fm_eth-
> >fm_index,
> > - FM_PRAM_SIZE, FM_PRAM_ALIGN);
> > + pram = (struct fm_port_global_pram *)(ulong)fm_muram_alloc(
> > + fm_eth->fm_index, FM_PRAM_SIZE, FM_PRAM_ALIGN);
> 
> Make fm_muram_alloc() return a pointer instead.  If muram were >= 4 GiB
> the above would fail.
> 
 
The muram is a region included in CCSR.
So does we take muram >= 4GiB into account make sense?

> >   fm_eth->rx_pram = pram;
> >
> >   /* parameter page offset to MURAM */
> > - pram_page_offset = (u32)pram - fm_muram_base(fm_eth->fm_index);
> > + pram_page_offset = (u32)(ulong)pram -
> > + fm_muram_base(fm_eth->fm_index);
> 
> Get rid of the u32 cast -- again, if the muram base were above >= 4 GiB
> this would fail because you're dropping the high bits before the
> subtraction rather than after.
> 
> >
> >   /* enable global mode- snooping data buffers and BDs */
> >   out_be32(>mode, PRAM_MODE_GLOBAL); @@ -258,7 +258,8 @@
> > static int fm_eth_rx_port_parameter_init(struct fm_eth
> > *fm_eth)
> >   muram_writew(>status, RxBD_EMPTY);
> >   muram_writew(>len, 0);
> >   muram_writew(>buf_ptr_hi, 0);
> > - out_be32(>buf_ptr_lo, (u32)rx_buf_pool + i *
> MAX_RXBUF_LEN);
> > + out_be32(>buf_ptr_lo, (u32)(ulong)rx_buf_pool +
> > + i *
> > + MAX_RXBUF_LEN);
> >   rxbd++;
> 
> Use virt_to_phys() and lower_32_bits().  Is there a "hi" register to
> handle the upper 32 bits?
> 
> Likewise elsewhere.  Don't just apply the minimum bandage to get rid of
> the warning.  Make the code actually be 64-bit clean.
> 

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


Re: [U-Boot] [PATCH v5 0/3] add pinctrl driver framework

2015-09-24 Thread Masahiro Yamada
Hi Linus,


2015-09-25 7:31 GMT+09:00 Linus Walleij :
> On Wed, Aug 26, 2015 at 8:44 PM, Masahiro Yamada
>  wrote:
>
>> I am trying my best to have this subsystem as DT-compatible with Linux
>> as possible, also saving memory foot print as a boot loader.
>>
>> It would be very appreciated if Linus Walleij, the maintainer of
>> pinctrl subsystem in Linux, would check this series if he could find
>> some time.
>
> Unfortunately I am short on time for doing U-Boot reviews too ...
> Massive mail backlog.
>
> Is this code already merged?


If you find something is going wrong, please let us know
(or send patches).
There are not many pinctrl drivers yet, we can change the course.




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


Re: [U-Boot] [PATCH 1/3] fix: fdtdec: allow parse 'reg' property with zero value in '#size-cells'

2015-09-24 Thread Stephen Warren

On 09/24/2015 09:29 AM, Przemyslaw Marczak wrote:

After rework of lib/fdtdec.c by commit:

commit 02464e386bb5f0a022c121f95ae75cf583759d95
Author: Stephen Warren 
Date:   Thu Aug 6 15:31:02 2015 -0600


That'd usually be abbreviated as:

Commit 02464e386bb5 "fdt: add new fdt address parsing functions".

Of course, if you want to shame me that's justified too:-) Tracking down 
regressions sucks:-(



the function fdtdec_get_addr() doesn't work as previous,
because the implementation assumes that properties '#address-cells'
and '#size-cells' are equal to 1, which can be not true sometimes.


"are equal to" should be "is at least"; the purpose of that rework was 
to support values greater than one.



The new API introduced fdtdec_get_addr_size_auto_parent() for the 'reg'
property parsing, but the implementation assumes, that #size-cells
can't be less than 1.

This causes that the following children's 'reg' property can't be reached:

parent@0x0 {
  #address-cells = <1>;
  #size-cells = <0>;
  children@0x100 {
  reg = < 0x100 >;
  };
};

Change the condition value from '1' to '0', which allows parsing property
with at least zero #size-cells, fixes the issue.

Now, fdtdec_get_addr_size_auto_parent() works properly.


Sorry about that. This patch,

Acked-by: Stephen Warren 

(but not tested, but since this allows a previously failing case, it's 
hard to see how this patch could cause any problems.)

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


Re: [U-Boot] [PATCH] sunxi: Add generic defconfigs for A33 Q8 tablets with 1024x600 / 800x480 LCD

2015-09-24 Thread Chen-Yu Tsai
On Thu, Sep 24, 2015 at 11:24 PM, Hans de Goede  wrote:
> The 7" Q8 tablet enclosure is used for a ton of slightly different cheap
> chinese tablets. There are some differences in which accelerometer /
> wifi is used, but other then that these are all the same from a u-boot /
> kernel pov.
>
> When we get to adding accelerometer support the plan is to add some kind
> of autodetection and mangle the dt accordingly (likely using the new quirks
> mechanism).
>
> For now this is a non issue as we do not yet have accelerometer
> support, and in the future, some sort of auto-detect is the way to go
> as we cannot expect users to exactly know what is inside their tablet.
>
> The dts[i] files this commit adds are indentical to the ones submitted
> to the upstream kernel.
>
> Signed-off-by: Hans de Goede 
> ---
>  arch/arm/dts/Makefile|  1 +
>  arch/arm/dts/sun8i-a33-q8-tablet.dts | 65 
>  arch/arm/dts/sun8i-q8-common.dtsi| 84 
> 
>  board/sunxi/MAINTAINERS  |  2 +
>  configs/q8_a33_tablet_1024x600_defconfig | 24 +
>  configs/q8_a33_tablet_800x480_defconfig  | 24 +
>  6 files changed, 200 insertions(+)
>  create mode 100644 arch/arm/dts/sun8i-a33-q8-tablet.dts
>  create mode 100644 arch/arm/dts/sun8i-q8-common.dtsi
>  create mode 100644 configs/q8_a33_tablet_1024x600_defconfig
>  create mode 100644 configs/q8_a33_tablet_800x480_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 09abc26..1dd5d5d 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -156,6 +156,7 @@ dtb-$(CONFIG_MACH_SUN8I_A33) += \
> sun8i-a33-et-q8-v1.6.dtb \
> sun8i-a33-ga10h-v1.1.dtb \
> sun8i-a33-ippo-q8h-v1.2.dtb \
> +   sun8i-a33-q8-tablet.dtb \
> sun8i-a33-sinlinx-sina33.dtb
>  dtb-$(CONFIG_MACH_SUN9I) += \
> sun9i-a80-optimus.dtb \
> diff --git a/arch/arm/dts/sun8i-a33-q8-tablet.dts 
> b/arch/arm/dts/sun8i-a33-q8-tablet.dts
> new file mode 100644
> index 000..44b3229
> --- /dev/null
> +++ b/arch/arm/dts/sun8i-a33-q8-tablet.dts
> @@ -0,0 +1,65 @@
> +/*
> + * Copyright 2015 Hans de Goede 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file 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.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun8i-a33.dtsi"
> +#include "sun8i-q8-common.dtsi"
> +
> +/ {
> +   model = "Q8 A33 Tablet";
> +   compatible = "allwinner,q8-a33", "allwinner,sun8i-a33";
> +};
> +
> +/*
> + * FIXME for now we only support host mode and rely on u-boot to have
> + * turned on Vbus which is controlled by the axp223 pmic on the board.
> + *
> + * Once we have axp223 support we should switch to fully supporting otg.
> + */
> +_otg {
> +   dr_mode = "host";
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +};
> diff --git a/arch/arm/dts/sun8i-q8-common.dtsi 
> b/arch/arm/dts/sun8i-q8-common.dtsi
> new file mode 100644
> index 

Re: [U-Boot] [Patch v2 08/16] net/fm: fix compile warnings for 64-bit platform

2015-09-24 Thread Hou Zhiqiang


> -Original Message-
> From: Wood Scott-B07421
> Sent: 2015年9月25日 10:34
> To: Hou Zhiqiang-B48286
> Cc: Gong Qianyu-B52263; u-boot@lists.denx.de; Hu Mingkai-B21284; Sun
> York-R58495; Song Wenbin-B53747; Xie Shaohui-B21989
> Subject: Re: [Patch v2 08/16] net/fm: fix compile warnings for 64-bit
> platform
> 
> On Thu, 2015-09-24 at 21:22 -0500, Hou Zhiqiang-B48286 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: 2015年9月18日 2:14
> > > To: Gong Qianyu-B52263
> > > Cc: u-boot@lists.denx.de; Hu Mingkai-B21284; Sun York-R58495; Hou
> > > Zhiqiang-B48286; Song Wenbin-B53747; Xie Shaohui-B21989; Wood Scott-
> > > B07421
> > > Subject: Re: [Patch v2 08/16] net/fm: fix compile warnings for
> > > 64-bit platform
> > >
> > > On Thu, 2015-09-17 at 15:06 +0800, Gong Qianyu wrote:
> > > > This patch fixes such compile warnings:
> > > >
> > > > drivers/net/fm/eth.c: In function 'fm_eth_recv':
> > > > drivers/net/fm/eth.c:549:11: warning: cast to pointer from integer
> > > > of different size [-Wint-to-pointer-cast]
> > > >   data = (u8 *)in_be32(>buf_ptr_lo);
> > > > drivers/net/fm/fm.c: In function 'fm_muram_alloc':
> > > > drivers/net/fm/fm.c:52:9: warning: cast to pointer from integer of
> > > > different size [-Wint-to-pointer-cast]
> > > >   memset((void *)ret, 0, size);
> > > > drivers/net/fm/fm.c: In function 'fm_init_muram':
> > > > drivers/net/fm/fm.c:59:13: warning: cast from pointer to integer
> > > > of different size [-Wpointer-to-int-cast]
> > > >   u32 base = (u32)reg;
> > > >
> > > > Just make the cast explicit for them.
> > > >
> > > > Signed-off-by: Gong Qianyu 
> > > > ---
> > > >  drivers/net/fm/eth.c | 31 ---
> > > > drivers/net/fm/fm.c  |  4 ++--
> > > >  2 files changed, 18 insertions(+), 17 deletions(-)
> > > >
> > > > diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c index
> > > > 12eb9b8..6ef0afb 100644
> > > > --- a/drivers/net/fm/eth.c
> > > > +++ b/drivers/net/fm/eth.c
> > > > @@ -120,12 +120,12 @@ static int tgec_is_fibre(struct eth_device
> > > > *dev)
> > > >
> > > >  static u16 muram_readw(u16 *addr)  {
> > > > - u32 base = (u32)addr & ~0x3;
> > > > + ulong base = (ulong)addr & ~0x3;
> > >
> > > This will still truncate the address at 32 bits.  It needs to be
> ~0x3UL.
> > >
> > >
> > > >   u32 val32 = in_be32((u32 *)base);
> > > >   int byte_pos;
> > > >   u16 ret;
> > > >
> > > > - byte_pos = (u32)addr & 0x3;
> > > > + byte_pos = (ulong)addr & 0x3;
> > > >   if (byte_pos)
> > > >   ret = (u16)(val32 & 0x);
> > > >   else
> > > > @@ -136,12 +136,12 @@ static u16 muram_readw(u16 *addr)
> > > >
> > > >  static void muram_writew(u16 *addr, u16 val)  {
> > > > - u32 base = (u32)addr & ~0x3;
> > > > + ulong base = (ulong)addr & ~0x3;
> > > >   u32 org32 = in_be32((u32 *)base);
> > > >   u32 val32;
> > > >   int byte_pos;
> > > >
> > > > - byte_pos = (u32)addr & 0x3;
> > > > + byte_pos = (ulong)addr & 0x3;
> > > >   if (byte_pos)
> > > >   val32 = (org32 & 0x) | val;
> > > >   else
> > > > @@ -217,12 +217,12 @@ static int
> > > > fm_eth_rx_port_parameter_init(struct
> > > > fm_eth *fm_eth)
> > > >   int i;
> > > >
> > > >   /* alloc global parameter ram at MURAM */
> > > > - pram = (struct fm_port_global_pram *)fm_muram_alloc(fm_eth-
> > > > fm_index,
> > > > - FM_PRAM_SIZE, FM_PRAM_ALIGN);
> > > > + pram = (struct fm_port_global_pram *)(ulong)fm_muram_alloc(
> > > > + fm_eth->fm_index, FM_PRAM_SIZE,
> > > > + FM_PRAM_ALIGN);
> > >
> > > Make fm_muram_alloc() return a pointer instead.  If muram were >= 4
> > > GiB the above would fail.
> > >
> >
> > The muram is a region included in CCSR.
> > So does we take muram >= 4GiB into account make sense?
> 
> The fact that currently, we run U-Boot as 32-bit on platforms where CCSR
> is
> >= 4GiB is not a good excuse to be sloppy with types.
> 

ok.

Thanks,
Zhiqiang


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


Re: [U-Boot] [PATCH 08/18] sandbox: Use the reset driver to handle reset

2015-09-24 Thread Stephen Warren
On 08/10/2015 09:44 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On 10 August 2015 at 21:35, Stephen Warren  wrote:
>> On 07/17/2015 05:58 PM, Simon Glass wrote:
>>> On 6 July 2015 at 12:54, Simon Glass  wrote:
 Move sandbox over to use the reset uclass for reset, instead of a direct
 call to do_reset(). This allows us to add tests.

 Signed-off-by: Simon Glass 
 ---

  arch/sandbox/cpu/cpu.c| 9 +
  arch/sandbox/dts/test.dts | 8 
  arch/sandbox/include/asm/u-boot-sandbox.h | 3 +++
  configs/sandbox_defconfig | 1 +
  4 files changed, 13 insertions(+), 8 deletions(-)
>>>
>>> Applied to u-boot-dm.
>>
>> This patch causes the reset command to stop working in sandbox. It now
>> prints:
>>
>> => reset
>> Reset not supported on this platform
>> ### ERROR ### Please RESET the board ###
>>
>> Among other things, this causes ./test/fs/fs-test.sh to hang without any
>> particular indication why. (In that test, running under expect/pyexpect
>> might be nicer, so the user could see progress; the error above doesn't
>> even show up in the test log files).
> 
> Yes I noticed the reset problem recently but haven't got back to it
> yet sorry. Ctrl-C works if you are at the command line, but will not
> fix the test.
> 
> One problem is that sandbox.dts needs a reset node, one of the ones
> from test.dts. Then at least 'u-boot -D' will work.
> 
> The other is that we need a U_BOOT_DEVICE() declaration for the reset
> controller. This is how drivers/serial/sandbox.c gets around this
> problem.
> 
> It would be good if we could run all the tests easily. At present it
> involves lots of steps and the method used to run each is different.

Any update on this? I had forgotten about this issue and just debugged
the exact same problem again. Unfortunately, reverting this commit seems
to make U-Boot hang() at early init time now, so I can't work around the
issue either (unless I made a mistake implementing the revert; I'll try
again).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 08/18] sandbox: Use the reset driver to handle reset

2015-09-24 Thread Stephen Warren
On 09/24/2015 11:13 PM, Stephen Warren wrote:
> On 08/10/2015 09:44 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On 10 August 2015 at 21:35, Stephen Warren  wrote:
>>> On 07/17/2015 05:58 PM, Simon Glass wrote:
 On 6 July 2015 at 12:54, Simon Glass  wrote:
> Move sandbox over to use the reset uclass for reset, instead of a direct
> call to do_reset(). This allows us to add tests.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/sandbox/cpu/cpu.c| 9 +
>  arch/sandbox/dts/test.dts | 8 
>  arch/sandbox/include/asm/u-boot-sandbox.h | 3 +++
>  configs/sandbox_defconfig | 1 +
>  4 files changed, 13 insertions(+), 8 deletions(-)

 Applied to u-boot-dm.
>>>
>>> This patch causes the reset command to stop working in sandbox. It now
>>> prints:
>>>
>>> => reset
>>> Reset not supported on this platform
>>> ### ERROR ### Please RESET the board ###
>>>
>>> Among other things, this causes ./test/fs/fs-test.sh to hang without any
>>> particular indication why. (In that test, running under expect/pyexpect
>>> might be nicer, so the user could see progress; the error above doesn't
>>> even show up in the test log files).
>>
>> Yes I noticed the reset problem recently but haven't got back to it
>> yet sorry. Ctrl-C works if you are at the command line, but will not
>> fix the test.
>>
>> One problem is that sandbox.dts needs a reset node, one of the ones
>> from test.dts. Then at least 'u-boot -D' will work.
>>
>> The other is that we need a U_BOOT_DEVICE() declaration for the reset
>> controller. This is how drivers/serial/sandbox.c gets around this
>> problem.
>>
>> It would be good if we could run all the tests easily. At present it
>> involves lots of steps and the method used to run each is different.
> 
> Any update on this? I had forgotten about this issue and just debugged
> the exact same problem again. Unfortunately, reverting this commit seems
> to make U-Boot hang() at early init time now, so I can't work around the
> issue either (unless I made a mistake implementing the revert; I'll try
> again).

The following hack makes reset work again. This sounds like something
other than the issues you mentioned above?

> https://github.com/swarren/u-boot/commit/2e41c317516e414326620374725a25b7b531d2e2

> diff --git a/drivers/misc/reset_sandbox.c b/drivers/misc/reset_sandbox.c
> index 917121bc5e80..0208e11dbf3a 100644
> --- a/drivers/misc/reset_sandbox.c
> +++ b/drivers/misc/reset_sandbox.c
> @@ -40,8 +40,10 @@ static int sandbox_reset_request(struct udevice *dev, enum 
> reset_t type)
>  * (see the U_BOOT_DEVICE() declaration below) should not do anything.
>  * If we are that device, return an error.
>  */
> +#if 0
> if (gd->fdt_blob && dev->of_offset == -1)
> return -ENODEV;
> +#endif
>  
> switch (type) {
> case RESET_COLD:

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


Re: [U-Boot] [PATCH v2 5/5] cgtqmx6eval: Protect the manufacturing information in SPI NOR

2015-09-24 Thread Jagan Teki
On 23 September 2015 at 22:51, Otavio Salvador
 wrote:
> On Wed, Sep 23, 2015 at 2:15 PM, Jagan Teki  wrote:
>> On 23 September 2015 at 22:21, Otavio Salvador
>>  wrote:
>>> Hello Jagan,
>>>
>>> On Wed, Sep 23, 2015 at 12:56 PM, Jagan Teki  wrote:
 All looks fine as per your patches, but probing flash from board files
 isn't a good approach if one more board add similar  approach.

 I have an idea similar to "cfi_flash" approach.

 "sf protect on off len" then based on the offset and len write the
 protected bits and skips the sectors which are protected by showing
 warning say "protected sectors will not be erased!" [1]

 Use the Linux approach[2] for more information, let me know for any more 
 inputs.

 [1] http://www.denx.de/wiki/view/DULG/UBootCmdGroupFlash#Section_5.9.3.4.
 [2] 
 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/mtd/devices/m25p80.c?id=972e1b7b450a93589b2a4c709e68f68da059aa5c
>>>
>>> I think this is a good option however, can we include this one for
>>> this release and we can improve it for next?
>>
>> Do you have any defined schedule on coming release about this feature,
>> because right now sf has lot of pending items to tune - I'm unable add
>> again this on TODO list that become big task in future.
>>
>> If you have any time, please start the suggested approach I would help
>> at any moment.
>
> We are adding support for a number of different SoM part numbers from
> Congatec and the SPI protection is required for we be able to merge
> the SPL and 2015.10 to be usable for them.
>
> I can commit to work in this feature for 2016.01.

Sorry, I understand your concern - but it's very difficult for me to
maintain the drop_code (which should again removed later). Why can't
you just add code as per my suggestion.. just a basic support as you
aware probably will move the same in coming release if all set,
because extending functionality is better approach rather than add it
remove the same.

Thanks for your commitment, let me know if you need any more help.

thanks!
-- 
Jagan | openedev.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PULL] Please pull u-boot-imx

2015-09-24 Thread Tom Rini
On Thu, Sep 24, 2015 at 11:45:59AM +0200, Stefano Babic wrote:

> Hi Tom,
> 
> please pull from u-boot-imx, thanks !
> 
>   git://www.denx.de/git/u-boot-imx.git master
> 
> for you to fetch changes up to f697c2acca9ff02c9b0cf480a4a726ed9626a53a:
> 
>   imx: fix coding style (2015-09-24 11:32:38 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] pull request: u-boot-uniphier/master (2nd round)

2015-09-24 Thread Tom Rini
On Fri, Sep 25, 2015 at 01:10:42AM +0900, Masahiro Yamada wrote:

> Hi Tom,
> 
> Here is a pretty big series for UniPhier SoC changes.
> pinctrl drivers, various fixes, refactoring, new SoC/board support, etc.
> 
> 
> Diff from the previous one:
>   - fix memory over-run bug in a command to display boot-mode
>   - sort pin-groups alphabetically in pinctrl drivers
>   - Add one more patch to convert a license block to SPDX
> 
> 
> 
> The following changes since commit 8a5f6129d1450f5ff92a55cfcfd7b96ee019e303:
> 
>   pinctrl: move dm_scan_fdt_node() out of pinctrl uclass (2015-09-19
> 15:42:15 -0600)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-uniphier.git master
> 
> for you to fetch changes up to a4bb44b027705f8c05fc525180cabaa3769247bb:
> 
>   ARM: dts: uniphier: use SPDX-License-Identifier (2015-09-25 01:01:37 +0900)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH 5/8] cmd: bootvx: Pass netmask and gatewayip to VxWorks bootline

2015-09-24 Thread Bin Meng
On Thu, Sep 24, 2015 at 5:21 PM, Bin Meng  wrote:
> There are fields in VxWorks bootline for netmask and gatewayip.
> We can get these from U-Boot environment variables and pass them
> to VxWorks, just like ipaddr and serverip.
>
> Signed-off-by: Bin Meng 
> ---
>
>  common/cmd_elf.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/common/cmd_elf.c b/common/cmd_elf.c
> index 62863df..5a34bde 100644
> --- a/common/cmd_elf.c
> +++ b/common/cmd_elf.c
> @@ -287,13 +287,24 @@ int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, 
> char * const argv[])
> "%s:file ", CONFIG_SYS_VXWORKS_SERVERNAME);
>
> tmp = getenv("ipaddr");
> -   if (tmp)
> -   sprintf(_buf[strlen(build_buf)], "e=%s ", tmp);
> +   if (tmp) {
> +   sprintf(_buf[strlen(build_buf)], "e=%s", tmp);
> +   tmp = getenv("netmask");
> +   if (tmp)
> +   sprintf(_buf[strlen(build_buf)],
> +   ":%04x ", 
> getenv_ip("netmask").s_addr);

There is an endian issue here for little endian targets. Also the %04x
is wrong, should be %08x. This will be fixed in v2.

> +   else
> +   sprintf(_buf[strlen(build_buf)], " ");
> +   }
>
> tmp = getenv("serverip");
> if (tmp)
> sprintf(_buf[strlen(build_buf)], "h=%s ", tmp);
>
> +   tmp = getenv("gatewayip");
> +   if (tmp)
> +   sprintf(_buf[strlen(build_buf)], "g=%s ", tmp);
> +
> tmp = getenv("hostname");
> if (tmp)
> sprintf(_buf[strlen(build_buf)], "tn=%s ", tmp);
> --

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


Re: [U-Boot] [Patch v2 08/16] net/fm: fix compile warnings for 64-bit platform

2015-09-24 Thread Scott Wood
On Thu, 2015-09-24 at 21:22 -0500, Hou Zhiqiang-B48286 wrote:
> 
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: 2015年9月18日 2:14
> > To: Gong Qianyu-B52263
> > Cc: u-boot@lists.denx.de; Hu Mingkai-B21284; Sun York-R58495; Hou
> > Zhiqiang-B48286; Song Wenbin-B53747; Xie Shaohui-B21989; Wood Scott-
> > B07421
> > Subject: Re: [Patch v2 08/16] net/fm: fix compile warnings for 64-bit
> > platform
> > 
> > On Thu, 2015-09-17 at 15:06 +0800, Gong Qianyu wrote:
> > > This patch fixes such compile warnings:
> > > 
> > > drivers/net/fm/eth.c: In function 'fm_eth_recv':
> > > drivers/net/fm/eth.c:549:11: warning: cast to pointer from integer of
> > > different size [-Wint-to-pointer-cast]
> > >   data = (u8 *)in_be32(>buf_ptr_lo);
> > > drivers/net/fm/fm.c: In function 'fm_muram_alloc':
> > > drivers/net/fm/fm.c:52:9: warning: cast to pointer from integer of
> > > different size [-Wint-to-pointer-cast]
> > >   memset((void *)ret, 0, size);
> > > drivers/net/fm/fm.c: In function 'fm_init_muram':
> > > drivers/net/fm/fm.c:59:13: warning: cast from pointer to integer of
> > > different size [-Wpointer-to-int-cast]
> > >   u32 base = (u32)reg;
> > > 
> > > Just make the cast explicit for them.
> > > 
> > > Signed-off-by: Gong Qianyu 
> > > ---
> > >  drivers/net/fm/eth.c | 31 ---
> > > drivers/net/fm/fm.c  |  4 ++--
> > >  2 files changed, 18 insertions(+), 17 deletions(-)
> > > 
> > > diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c index
> > > 12eb9b8..6ef0afb 100644
> > > --- a/drivers/net/fm/eth.c
> > > +++ b/drivers/net/fm/eth.c
> > > @@ -120,12 +120,12 @@ static int tgec_is_fibre(struct eth_device *dev)
> > > 
> > >  static u16 muram_readw(u16 *addr)
> > >  {
> > > - u32 base = (u32)addr & ~0x3;
> > > + ulong base = (ulong)addr & ~0x3;
> > 
> > This will still truncate the address at 32 bits.  It needs to be ~0x3UL.
> > 
> > 
> > >   u32 val32 = in_be32((u32 *)base);
> > >   int byte_pos;
> > >   u16 ret;
> > > 
> > > - byte_pos = (u32)addr & 0x3;
> > > + byte_pos = (ulong)addr & 0x3;
> > >   if (byte_pos)
> > >   ret = (u16)(val32 & 0x);
> > >   else
> > > @@ -136,12 +136,12 @@ static u16 muram_readw(u16 *addr)
> > > 
> > >  static void muram_writew(u16 *addr, u16 val)  {
> > > - u32 base = (u32)addr & ~0x3;
> > > + ulong base = (ulong)addr & ~0x3;
> > >   u32 org32 = in_be32((u32 *)base);
> > >   u32 val32;
> > >   int byte_pos;
> > > 
> > > - byte_pos = (u32)addr & 0x3;
> > > + byte_pos = (ulong)addr & 0x3;
> > >   if (byte_pos)
> > >   val32 = (org32 & 0x) | val;
> > >   else
> > > @@ -217,12 +217,12 @@ static int fm_eth_rx_port_parameter_init(struct
> > > fm_eth *fm_eth)
> > >   int i;
> > > 
> > >   /* alloc global parameter ram at MURAM */
> > > - pram = (struct fm_port_global_pram *)fm_muram_alloc(fm_eth-
> > > fm_index,
> > > - FM_PRAM_SIZE, FM_PRAM_ALIGN);
> > > + pram = (struct fm_port_global_pram *)(ulong)fm_muram_alloc(
> > > + fm_eth->fm_index, FM_PRAM_SIZE, FM_PRAM_ALIGN);
> > 
> > Make fm_muram_alloc() return a pointer instead.  If muram were >= 4 GiB
> > the above would fail.
> > 
>  
> The muram is a region included in CCSR.
> So does we take muram >= 4GiB into account make sense?

The fact that currently, we run U-Boot as 32-bit on platforms where CCSR is 
>= 4GiB is not a good excuse to be sloppy with types.

-Scott

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


Re: [U-Boot] [PATCH 0/3] Fix fdt 'reg' parsing and unbreak Odroid U3

2015-09-24 Thread Jaehoon Chung
Hi, Przemyslaw.

On 09/25/2015 12:29 AM, Przemyslaw Marczak wrote:
> Booting of Odroid U3 with SD card, ends with error:
> 
> MMC:   EXYNOS DWMMC: 0
> Card did not respond to voltage select!
> *** Warning - MMC init failed, using default environment
> 
> Generally this was broken, because of wrong addresses assigned to GPIOs.

Great! I will check this patch-set..But it seems to look good to me. :)

Best Regards,
Jaehoon Chung

> 
> The source of the problem was in rework of lib/fdtdec.c, after which
> function fdtdec_get_addr() doesn't work as previous and function
> dev_get_addr() doesn't works as expected.
> 
> The code after rework in lib/fdtdec.c assume, that #size-cells property,
> should be always greater or equal to 1. This was wrong, because it can be 0.
> 
> In case of debugging the issue I found, that mmc clock was computed wrong,
> for Exynos4, because of function get_mmc_clk(), which always return -1 for
> this SoC.
> 
> Tested on: Odroid U3 and Odroid XU3.
> 
> Przemyslaw Marczak (3):
>   fix: fdtdec: allow parse 'reg' property with zero value in
> '#size-cells'
>   fix: s5p_gpio: call: dev_get_addr() instead of fdtdec_get_addr()
>   fix: mach-exynos: clock: restore calling dead exynos4_get_mmc_clk()
> 
>  arch/arm/mach-exynos/clock.c | 10 --
>  drivers/gpio/s5p_gpio.c  | 18 +++---
>  lib/fdtdec.c |  2 +-
>  3 files changed, 16 insertions(+), 14 deletions(-)
> 

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