Re: [U-Boot] [PATCH 4/4] sunxi: fix 64-bit compiler warning for SPL header parsing

[Siarhei Siamashka]

On Mon,  5 Sep 2016 01:32:41 +0100
Andre Przywara  wrote:

> Casting "int"s to pointers is only valid for 32-bit systems.
> Add the appropriate pointer type cast to avoid a compiler warning
> when compiling for AArch64.
> 
> Signed-off-by: Andre Przywara 
> ---
>  board/sunxi/board.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 209fb1c..6281c9d 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -602,7 +602,7 @@ static void parse_spl_header(const uint32_t spl_addr)
>* data is expected in uEnv.txt compatible format, so "env
>* import -t" the string(s) at fel_script_address right away.
>*/
> - himport_r(_htab, (char *)spl->fel_script_address,
> + himport_r(_htab, (char *)(uintptr_t)spl->fel_script_address,
> spl->fel_uEnv_length, '\n', H_NOCLEAR, 0, 0, NULL);
>   return;
>   }

Reviewed-by: Siarhei Siamashka 

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

Re: [U-Boot] [PATCH 2/4] Revert "sunxi: Downclock AHB1 to 100MHz on Allwinner A64"

[Siarhei Siamashka]

On Mon,  5 Sep 2016 01:32:39 +0100
Andre Przywara  wrote:

> Now that we don't use SRAM C for the SPL stack anymore, there is no
> need to clock down AHB1 to 100 MHz.

It's just another way to say it, but we are not clocking the AHB1
down, but rather keeping it at a failsafe default. If I understand it
correctly, reclocking the AHB1 to 200 MHz early in the SPL code is
not really necessary for the v2016.09 release and does not fix anything.

Moreover this revert affects USB FEL boot, which currently uses 8K
of SRAM C as a backup storage. Yes, we can also move the FEL backup
storage to SRAM A2, but the real question is whether we really want
to have it this way in the long run.

Is it really needed to reclock AHB1 early in the SPL? Can't ATF or
U-Boot proper do this a bit later? Also it's best to unmap the SRAM C
from the CPU address space at the same time as the AHB1 is reclocked
to 200 MHz. So that nobody can accidentally access it. There is a
special "bootmode" bit, which configures the SRAM C mapping:

https://irclog.whitequark.org/linux-sunxi/2016-06-29#16863309;

Writing 0x to 0x01c4 hides the SRAM C from the CPU. And
writing 0x0100 there enables it again. Some SRAM C experiments
can be done with the sunxi-fel tool:

$ sunxi-fel hex 0x18000 64
00018000: 32 a6 21 9a da f7 16 d7 7c 59 e9 b3 db a2 5f 9e  2.!.|Y_.
00018010: d2 0c 54 b8 79 7e 7a ff 7f 0d b5 e7 96 27 34 c8  ..T.y~z..'4.
00018020: c7 d1 66 f8 4b dc a6 cb d5 ba e3 ce 26 18 49 c4  ..f.K...&.I.
00018030: 4f f6 3f a9 56 f7 92 d4 50 b6 7f e6 73 e8 e5 69  O.?.V...P...s..i

$ sunxi-fel fill 0x18000 64 0xCC && sunxi-fel hex 0x18000 64
00018000: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  
00018010: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  
00018020: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  
00018030: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  

$ sunxi-fel writel 0x01c4 0x && sunxi-fel hex 0x18000 64
00018000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
00018010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
00018020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
00018030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  

$ sunxi-fel writel 0x01c4 0x0100 && sunxi-fel hex 0x18000 64
00018000: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  
00018010: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  
00018020: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  
00018030: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  

The commands above first show the uninitialized garbage in the SRAM C,
then initialize it to 0xCC, then disable the SRAM C access from the
CPU (it is then read as all zeros), then enable it back (it is read
as 0xCC again).

> Keeping it at the recommended 200 MHz allows faster peripherals.

I usually prefer to see some performance numbers in such commit
messages ;) Not that I doubt that something becomes faster, but it
is always interesting to know how big is the real practical effect.

> This reverts commit 5bc88cc2be3a962005b6e5768e06ca8f6ffcb88d.
> 
> Signed-off-by: Andre Przywara 

We are not fixing any bugs with this revert. Or do we?

> ---
>  arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h 
> b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> index be9fcfd..f7e93b0 100644
> --- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> @@ -230,12 +230,7 @@ struct sunxi_ccm_reg {
>  #define CCM_PLL5_TUN_INIT_FREQ(x)(((x) & 0x7f) << 16)
>  #define CCM_PLL5_TUN_INIT_FREQ_MASK  CCM_PLL5_TUN_INIT_FREQ(0x7f)
>  
> -#if defined(CONFIG_MACH_SUN50I)
> -/* AHB1=100MHz failsafe setup from the FEL mode, usable with PMIC defaults */
> -#define AHB1_ABP1_DIV_DEFAULT0x3190 /* 
> AHB1=PLL6/6,APB1=AHB1/2 */
> -#else
>  #define AHB1_ABP1_DIV_DEFAULT0x3180 /* 
> AHB1=PLL6/3,APB1=AHB1/2 */
> -#endif
>  
>  #define AXI_GATE_OFFSET_DRAM 0
>  

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

Re: [U-Boot] [PATCH 1/4] Revert "sunxi: Move the SPL stack top to 0x1A000 on Allwinner A64/A80"

[Siarhei Siamashka]

On Mon,  5 Sep 2016 01:32:38 +0100
Andre Przywara  wrote:

> This commit moved the SPL stack into SRAM C, which worked when the SPL
> set the AHB1 clock down to 100 MHz to cope with the flaky SRAM C access
> from the CPU.
> However booting with boot0 (and thus not using SPL at all) we still run
> with a 200 MHz AHB1, so any access to SRAM C is prone to fail.
> Since this commit does _not_ only affect the SPL code, but also the
> U-Boot proper, we fail when booting with boot0.

Yes, it unfortunately affected both the SPL and the U-Boot
proper because currently both CONFIG_SPL_STACK and
CONFIG_SYS_INIT_SP_ADDR defines affect the SPL stack
location and in practice this only works in a predictable
way if they are set to the same value. I have sent a patch
to address this problem (but the fix may be unsafe for
v2016.09 because many ARM platforms are affected):

https://patchwork.ozlabs.org/patch/665608/

After this problem is resolved, the CONFIG_SYS_INIT_SP_ADDR
define can be decoupled from CONFIG_SPL_STACK and configured to
even use the DRAM instead of thrashing some part of the scarce
SRAM space (which may be already occupied by the OpenRISC
firmware and/or the ATF at the time when the U-Boot proper is
starting).

> As the introduction of tiny-printf reduced the size of the SPL, we
> can afford to have the SPL stack in SRAM A1.

We still need to check how much space is really available. The FIT
support is rather heavyweight and we may want to enable some other
features too.
 
> This reverts commit 1a83fb4a17d959d7b037999ab7ed7e62429abe34
> and fixes booting the Pine64 when using boot0.
>
> Signed-off-by: Andre Przywara 

But as discussed earlier, reverting this patch is a reasonable
solution for v2016.09, so it is

Reviewed-by: Siarhei Siamashka 

> ---
>  include/configs/sunxi-common.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index f64edd4..708ab17 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -99,7 +99,7 @@
>   * the 1 actually activates the mapping of the first 32 KiB to 0x.
>   */
>  #define CONFIG_SYS_INIT_RAM_ADDR 0x1
> -#define CONFIG_SYS_INIT_RAM_SIZE 0xA000  /* 40 KiB */
> +#define CONFIG_SYS_INIT_RAM_SIZE 0x08000 /* FIXME: 40 KiB ? */
>  #else
>  #define CONFIG_SYS_INIT_RAM_ADDR 0x0
>  #define CONFIG_SYS_INIT_RAM_SIZE 0x8000  /* 32 KiB */
> @@ -220,7 +220,8 @@
>  #define CONFIG_SPL_PAD_TO32768   /* decimal for 'dd' */
>  
>  #if defined(CONFIG_MACH_SUN9I) || defined(CONFIG_MACH_SUN50I)
> -#define LOW_LEVEL_SRAM_STACK 0x0001A000
> +/* FIXME: 40 KiB instead of 32 KiB ? */
> +#define LOW_LEVEL_SRAM_STACK 0x00018000
>  #define CONFIG_SPL_STACK LOW_LEVEL_SRAM_STACK
>  #else
>  /* end of 32 KiB in sram */



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

[U-Boot] [PATCH] ARM: Respect CONFIG_SPL_STACK define in lowlevel_init.S

[Siarhei Siamashka]

The SPL and U-Boot proper may use different initial stack
locations, which are configured via CONFIG_SPL_STACK and
CONFIG_SYS_INIT_SP_ADDR defines. The lowlevel_init.S
code needs to handle this in the same way as crt0.S

Without this fix, setting the U-Boot stack location to some
place, which is not safely accessible by the SPL (such as
the DRAM), causes a very early SPL deadlock.

Signed-off-by: Siarhei Siamashka 
---
 arch/arm/cpu/armv7/lowlevel_init.S | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/cpu/armv7/lowlevel_init.S 
b/arch/arm/cpu/armv7/lowlevel_init.S
index 1872c57..658934d 100644
--- a/arch/arm/cpu/armv7/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/lowlevel_init.S
@@ -19,7 +19,11 @@ ENTRY(lowlevel_init)
/*
 * Setup a temporary stack. Global data is not available yet.
 */
+#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK)
+   ldr sp, =CONFIG_SPL_STACK
+#else
ldr sp, =CONFIG_SYS_INIT_SP_ADDR
+#endif
bic sp, sp, #7 /* 8-byte alignment for ABI compliance */
 #ifdef CONFIG_SPL_DM
mov r9, #0
-- 
2.7.3

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

[U-Boot] [PATCH 2/2] pbl: use "wait" command instead of "flush" command

[Zhao Qiang]

FLUSH command is restricted to CCSR space. So use WAIT
command in case of non-CCSR board.

Signed-off-by: Zhao Qiang 
---
 board/freescale/t208xqds/t208x_pbi.cfg | 3 +--
 board/freescale/t208xrdb/t2080_pbi.cfg | 3 +--
 board/freescale/t4qds/t4_pbi.cfg   | 3 +--
 board/freescale/t4rdb/t4_pbi.cfg   | 3 +--
 tools/pblimage.c   | 2 +-
 5 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/board/freescale/t208xqds/t208x_pbi.cfg 
b/board/freescale/t208xqds/t208x_pbi.cfg
index e200d92..43be8a8 100644
--- a/board/freescale/t208xqds/t208x_pbi.cfg
+++ b/board/freescale/t208xqds/t208x_pbi.cfg
@@ -37,5 +37,4 @@
 0914 ff00
 0918 8100
 #Flush PBL data
-09138000 
-091380c0 
+091380c0 0010
diff --git a/board/freescale/t208xrdb/t2080_pbi.cfg 
b/board/freescale/t208xrdb/t2080_pbi.cfg
index e200d92..43be8a8 100644
--- a/board/freescale/t208xrdb/t2080_pbi.cfg
+++ b/board/freescale/t208xrdb/t2080_pbi.cfg
@@ -37,5 +37,4 @@
 0914 ff00
 0918 8100
 #Flush PBL data
-09138000 
-091380c0 
+091380c0 0010
diff --git a/board/freescale/t4qds/t4_pbi.cfg b/board/freescale/t4qds/t4_pbi.cfg
index 6126266..8d46003 100644
--- a/board/freescale/t4qds/t4_pbi.cfg
+++ b/board/freescale/t4qds/t4_pbi.cfg
@@ -18,5 +18,4 @@
 0914 ff00
 0918 8100
 #Flush PBL data
-09138000 
-091380c0 
+091380c0 0010
diff --git a/board/freescale/t4rdb/t4_pbi.cfg b/board/freescale/t4rdb/t4_pbi.cfg
index e7bb673..0b326fa 100644
--- a/board/freescale/t4rdb/t4_pbi.cfg
+++ b/board/freescale/t4rdb/t4_pbi.cfg
@@ -24,5 +24,4 @@
 0914 ff00
 0918 8100
 #Flush PBL data
-09138000 
-091380c0 
+091380c0 0010
diff --git a/tools/pblimage.c b/tools/pblimage.c
index d74fde9..16d94c98 100644
--- a/tools/pblimage.c
+++ b/tools/pblimage.c
@@ -297,7 +297,7 @@ int pblimage_check_params(struct image_tool_params *params)
pbi_crc_cmd1 = 0x13;
pbi_crc_cmd2 = 0x80;
pbl_cmd_initaddr = 0x8200;
-   pbl_end_cmd[0] = 0x09138000;
+   pbl_end_cmd[0] = 0x091380c0;
pbl_end_cmd[1] = 0x;
pbl_end_cmd[2] = 0x091380c0;
pbl_end_cmd[3] = 0x;
-- 
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 1/2] Txxx/RCW: Split unified RCW to RCWs for sd, spi and nand.

[Zhao Qiang]

T series boards use unified RCW for sd, api and nand boot.
Now split txxx_rcw.cfg to txxx_sd_rcw.cfg, txxx_spi_rcw.cfg
and txxx_nand_rcw.cfg for SPI/NAND/SD boot.

Signed-off-by: Zhao Qiang 
---
 .../t102xqds/{t1024_rcw.cfg => t1024_nand_rcw.cfg} |  0
 .../t102xqds/{t1024_rcw.cfg => t1024_sd_rcw.cfg}   |  2 +-
 .../t102xqds/{t1024_rcw.cfg => t1024_spi_rcw.cfg}  |  2 +-
 .../t102xrdb/{t1023_rcw.cfg => t1023_nand_rcw.cfg} |  0
 .../t102xrdb/{t1023_rcw.cfg => t1023_sd_rcw.cfg}   |  2 +-
 .../t102xrdb/{t1023_rcw.cfg => t1023_spi_rcw.cfg}  |  2 +-
 .../t102xrdb/{t1024_rcw.cfg => t1024_nand_rcw.cfg} |  0
 .../t102xrdb/{t1024_rcw.cfg => t1024_sd_rcw.cfg}   |  2 +-
 .../t102xrdb/{t1024_rcw.cfg => t1024_spi_rcw.cfg}  |  2 +-
 .../t104xrdb/{t1040_rcw.cfg => t1040_nand_rcw.cfg} |  0
 .../t104xrdb/{t1040_rcw.cfg => t1040_sd_rcw.cfg}   |  2 +-
 .../t104xrdb/{t1040_rcw.cfg => t1040_spi_rcw.cfg}  |  2 +-
 .../{t1040d4_rcw.cfg => t1040d4_nand_rcw.cfg}  |  0
 .../{t1040d4_rcw.cfg => t1040d4_sd_rcw.cfg}|  2 +-
 .../{t1040d4_rcw.cfg => t1040d4_spi_rcw.cfg}   |  2 +-
 .../t104xrdb/{t1042_rcw.cfg => t1042_nand_rcw.cfg} |  0
 .../{t1042_pi_rcw.cfg => t1042_pi_nand_rcw.cfg}|  0
 .../{t1042_pi_rcw.cfg => t1042_pi_sd_rcw.cfg}  |  2 +-
 .../{t1042_pi_rcw.cfg => t1042_pi_spi_rcw.cfg} |  2 +-
 .../t104xrdb/{t1042_rcw.cfg => t1042_sd_rcw.cfg}   |  2 +-
 .../t104xrdb/{t1042_rcw.cfg => t1042_spi_rcw.cfg}  |  2 +-
 .../{t1042d4_rcw.cfg => t1042d4_nand_rcw.cfg}  |  0
 .../{t1042d4_rcw.cfg => t1042d4_sd_rcw.cfg}|  2 +-
 .../{t1042d4_rcw.cfg => t1042d4_spi_rcw.cfg}   |  2 +-
 .../t208xqds/{t2080_rcw.cfg => t2080_nand_rcw.cfg} |  0
 .../t208xqds/{t2080_rcw.cfg => t2080_sd_rcw.cfg}   |  2 +-
 .../t208xqds/{t2080_rcw.cfg => t2080_spi_rcw.cfg}  |  2 +-
 .../t208xqds/{t2081_rcw.cfg => t2081_nand_rcw.cfg} |  0
 .../t208xqds/{t2081_rcw.cfg => t2081_sd_rcw.cfg}   |  2 +-
 .../t208xqds/{t2081_rcw.cfg => t2081_spi_rcw.cfg}  |  2 +-
 .../t208xrdb/{t2080_rcw.cfg => t2080_nand_rcw.cfg} |  0
 .../t208xrdb/{t2080_rcw.cfg => t2080_sd_rcw.cfg}   |  2 +-
 .../t208xrdb/{t2080_rcw.cfg => t2080_spi_rcw.cfg}  |  2 +-
 .../t4qds/{t4_rcw.cfg => t4_nand_rcw.cfg}  |  2 +-
 .../{t4rdb/t4_rcw.cfg => t4qds/t4_sd_rcw.cfg}  |  6 +-
 include/configs/T102xQDS.h |  4 +-
 include/configs/T102xRDB.h | 20 --
 include/configs/T104xRDB.h | 78 +-
 include/configs/T208xQDS.h | 20 --
 include/configs/T208xRDB.h |  4 +-
 include/configs/T4240QDS.h |  3 +-
 include/configs/T4240RDB.h |  2 +-
 42 files changed, 125 insertions(+), 58 deletions(-)
 copy board/freescale/t102xqds/{t1024_rcw.cfg => t1024_nand_rcw.cfg} (100%)
 copy board/freescale/t102xqds/{t1024_rcw.cfg => t1024_sd_rcw.cfg} (89%)
 rename board/freescale/t102xqds/{t1024_rcw.cfg => t1024_spi_rcw.cfg} (89%)
 copy board/freescale/t102xrdb/{t1023_rcw.cfg => t1023_nand_rcw.cfg} (100%)
 copy board/freescale/t102xrdb/{t1023_rcw.cfg => t1023_sd_rcw.cfg} (87%)
 rename board/freescale/t102xrdb/{t1023_rcw.cfg => t1023_spi_rcw.cfg} (87%)
 copy board/freescale/t102xrdb/{t1024_rcw.cfg => t1024_nand_rcw.cfg} (100%)
 copy board/freescale/t102xrdb/{t1024_rcw.cfg => t1024_sd_rcw.cfg} (87%)
 rename board/freescale/t102xrdb/{t1024_rcw.cfg => t1024_spi_rcw.cfg} (87%)
 copy board/freescale/t104xrdb/{t1040_rcw.cfg => t1040_nand_rcw.cfg} (100%)
 copy board/freescale/t104xrdb/{t1040_rcw.cfg => t1040_sd_rcw.cfg} (83%)
 rename board/freescale/t104xrdb/{t1040_rcw.cfg => t1040_spi_rcw.cfg} (83%)
 copy board/freescale/t104xrdb/{t1040d4_rcw.cfg => t1040d4_nand_rcw.cfg} (100%)
 copy board/freescale/t104xrdb/{t1040d4_rcw.cfg => t1040d4_sd_rcw.cfg} (83%)
 rename board/freescale/t104xrdb/{t1040d4_rcw.cfg => t1040d4_spi_rcw.cfg} (83%)
 copy board/freescale/t104xrdb/{t1042_rcw.cfg => t1042_nand_rcw.cfg} (100%)
 copy board/freescale/t104xrdb/{t1042_pi_rcw.cfg => t1042_pi_nand_rcw.cfg} 
(100%)
 copy board/freescale/t104xrdb/{t1042_pi_rcw.cfg => t1042_pi_sd_rcw.cfg} (83%)
 rename board/freescale/t104xrdb/{t1042_pi_rcw.cfg => t1042_pi_spi_rcw.cfg} 
(83%)
 copy board/freescale/t104xrdb/{t1042_rcw.cfg => t1042_sd_rcw.cfg} (83%)
 rename board/freescale/t104xrdb/{t1042_rcw.cfg => t1042_spi_rcw.cfg} (83%)
 copy board/freescale/t104xrdb/{t1042d4_rcw.cfg => t1042d4_nand_rcw.cfg} (100%)
 copy board/freescale/t104xrdb/{t1042d4_rcw.cfg => t1042d4_sd_rcw.cfg} (83%)
 rename board/freescale/t104xrdb/{t1042d4_rcw.cfg => t1042d4_spi_rcw.cfg} (83%)
 copy board/freescale/t208xqds/{t2080_rcw.cfg => t2080_nand_rcw.cfg} (100%)
 copy board/freescale/t208xqds/{t2080_rcw.cfg => t2080_sd_rcw.cfg} (92%)
 rename board/freescale/t208xqds/{t2080_rcw.cfg => t2080_spi_rcw.cfg} (92%)
 copy board/freescale/t208xqds/{t2081_rcw.cfg => t2081_nand_rcw.cfg} (100%)
 copy board/freescale/t208xqds/{t2081_rcw.cfg => t2081_sd_rcw.cfg} 

Re: [U-Boot] [PATCH v2 01/44] Correct defconfigs using savedefconfig

[Masahiro Yamada]

2016-08-30 9:21 GMT+09:00 Simon Glass :
> Update the defconfig files to match their canonical form, as produced by
> 'make safedefconfig'.
>
> This is the result of running 'tools/moveconfig.py -s' on the tree.
>
> Signed-off-by: Simon Glass 

>
> diff --git a/configs/10m50_defconfig b/configs/10m50_defconfig
> index 15952af..0e3ad96 100644
> --- a/configs/10m50_defconfig
> +++ b/configs/10m50_defconfig
> @@ -1,7 +1,7 @@
>  CONFIG_NIOS2=y
>  CONFIG_SYS_CONFIG_NAME="10m50_devboard"
> -CONFIG_DM_SERIAL=y
>  CONFIG_DM_GPIO=y
> +CONFIG_DM_SERIAL=y
>  CONFIG_DEFAULT_DEVICE_TREE="10m50_devboard"
>  CONFIG_FIT=y
>  CONFIG_OF_BOARD_SETUP=y
> diff --git a/configs/3c120_defconfig b/configs/3c120_defconfig
> index b19c956..0c3fbde 100644
> --- a/configs/3c120_defconfig
> +++ b/configs/3c120_defconfig
> @@ -1,7 +1,7 @@
>  CONFIG_NIOS2=y
>  CONFIG_SYS_CONFIG_NAME="3c120_devboard"
> -CONFIG_DM_SERIAL=y
>  CONFIG_DM_GPIO=y
> +CONFIG_DM_SERIAL=y
>  CONFIG_DEFAULT_DEVICE_TREE="3c120_devboard"
>  CONFIG_FIT=y
>  CONFIG_OF_BOARD_SETUP=y



If the following patch is applied
http://patchwork.ozlabs.org/patch/664076/
the savedefconfig sync will produce completely different
results for these defconfigs.


The "make savedefconfig" sorts CONFIGs
in the order as Kconfig entries are parsed.

In other words, the canonical order changes
every time bare default entries are added/removed
in board/*/Kconfig.


We are just repeating mad churn...

-- 
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 21/44] Convert CONFIG_SPL_GPIO_SUPPORT to Kconfig

[Masahiro Yamada]

2016-09-02 23:35 GMT+09:00 Tom Rini :

>> >> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
>> >> index c25fcf3..d4a5bc9 100644
>> >> --- a/arch/arm/mach-exynos/Kconfig
>> >> +++ b/arch/arm/mach-exynos/Kconfig
>> >> @@ -61,6 +61,9 @@ endif
>> >>
>> >>  if ARCH_EXYNOS5
>> >>
>> >> +config SPL_GPIO_SUPPORT
>> >> +   default y
>> >> +
>> >
>> >
>> > As we discussed before,
>> > we decided to not do this.
>>
>> Tom was keen to avoid changing every defconfig file. It is there
>> another way to express common defaults?
>
> I was thinking in the Kconfig with the entry for SPL_GPIO_SUPPORT, for
> optional stuff and select in the board, etc, Kconfig for non-optional
> stuff.  Now, I realize that optional vs non-optional is more the domain
> of the individual SoC custodians, so we'll have some clean up afterwards
> that isn't on you (well, aside from the SoCs you know like rockchip ;)).

config SPL_GPIO_SUPPORT
   default y

is incorrect because it could violate
the dependency in the proper Kconfig entry in spl/Kconfig.




Basically, we are supposed to use "select FOO" when it is mandatory,
or add CONFIG_FOO=y in a defconfig when the board wants it, but
can still make it optional.


I know our pain comes from that "include" is not supported by Kconfig.

What I can suggest now is:



[1]  Add ARCH_WANT_* to specify a SoC-common default.


   config SPL_GPIO_SUPPORT
bool "GPIO support for SPL"
default  ARCH_WANT_SPL_GPIO_SUPPORT


   config ARCH_WANT_SPL_GPIO_SUPPORT
bool


   config ARCH_EXYNOS5
   select ARCH_WANT_SPL_GPIO_SUPPORT


Linux used to have ARCH_WANT_OPTIONAL_GPIOLIB to do similar things.
(they stopped this way, though)



[2] Support multi boards with one defconfig
(barebox supports multi-platform like Linux does.)


[3] use pre-processor to support #include <...>





BTW, SPL_GPIO_SUPPORT is optional in this case?

U-Boot proper supports a command line interface,
while SPL is usually run in a non-interactive mode.

So, what SPL needs is generally mandatory,
so we can "select" it,  I guess.

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

[U-Boot] [PATCH] rockchip: rk3288: sdram: fix DDR address range

[Ziyuan Xu]

The all current Rockchip SoCs supporting 4GB of ram have problems
accessing the memory region 0xfe00~0xff00. Actually, some IP
controller can't address to, so let's limit the available range.

This patch fixes a bug which found in miniarm-rk3288-4GB board. The
U-Boot was relocated to 0xfef72000, and .bss variants was also
relocated, such as do_fat_read_at_block. Once eMMC controller transfer
data to do_fat_read_at_block via DMA, DMAC can't access more than
0xfe00. So that DMAC didn't work sane.

Signed-off-by: Ziyuan Xu 
---

 arch/arm/mach-rockchip/rk3288/sdram_rk3288.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-rockchip/rk3288/sdram_rk3288.c 
b/arch/arm/mach-rockchip/rk3288/sdram_rk3288.c
index cf9ef2e..8020e9c 100644
--- a/arch/arm/mach-rockchip/rk3288/sdram_rk3288.c
+++ b/arch/arm/mach-rockchip/rk3288/sdram_rk3288.c
@@ -755,10 +755,11 @@ size_t sdram_size_mb(struct rk3288_pmu *pmu)
}
 
/*
-   * we use the 0x~0xfeff space since 0xff00~0x
-   * is SoC register space (i.e. reserved)
+   * we use the 0x~0xfdff space since 0xff00~0x
+   * is SoC register space (i.e. reserved), and 0xfe00~0xfeff is 
+   * inaccessible for some IP controller.
*/
-   size_mb = min(size_mb, 0xff00 >> 20);
+   size_mb = min(size_mb, 0xfe00 >> 20);
 
return size_mb;
 }
-- 
2.9.2


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

[U-Boot] [PATCH 4/4] sunxi: fix 64-bit compiler warning for SPL header parsing

[Andre Przywara]

Casting "int"s to pointers is only valid for 32-bit systems.
Add the appropriate pointer type cast to avoid a compiler warning
when compiling for AArch64.

Signed-off-by: Andre Przywara 
---
 board/sunxi/board.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 209fb1c..6281c9d 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -602,7 +602,7 @@ static void parse_spl_header(const uint32_t spl_addr)
 * data is expected in uEnv.txt compatible format, so "env
 * import -t" the string(s) at fel_script_address right away.
 */
-   himport_r(_htab, (char *)spl->fel_script_address,
+   himport_r(_htab, (char *)(uintptr_t)spl->fel_script_address,
  spl->fel_uEnv_length, '\n', H_NOCLEAR, 0, 0, NULL);
return;
}
-- 
2.8.2

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

[U-Boot] [PATCH 1/4] Revert "sunxi: Move the SPL stack top to 0x1A000 on Allwinner A64/A80"

[Andre Przywara]

This commit moved the SPL stack into SRAM C, which worked when the SPL
set the AHB1 clock down to 100 MHz to cope with the flaky SRAM C access
from the CPU.
However booting with boot0 (and thus not using SPL at all) we still run
with a 200 MHz AHB1, so any access to SRAM C is prone to fail.
Since this commit does _not_ only affect the SPL code, but also the
U-Boot proper, we fail when booting with boot0.

As the introduction of tiny-printf reduced the size of the SPL, we
can afford to have the SPL stack in SRAM A1.

This reverts commit 1a83fb4a17d959d7b037999ab7ed7e62429abe34
and fixes booting the Pine64 when using boot0.

Signed-off-by: Andre Przywara 
---
 include/configs/sunxi-common.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index f64edd4..708ab17 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -99,7 +99,7 @@
  * the 1 actually activates the mapping of the first 32 KiB to 0x.
  */
 #define CONFIG_SYS_INIT_RAM_ADDR   0x1
-#define CONFIG_SYS_INIT_RAM_SIZE   0xA000  /* 40 KiB */
+#define CONFIG_SYS_INIT_RAM_SIZE   0x08000 /* FIXME: 40 KiB ? */
 #else
 #define CONFIG_SYS_INIT_RAM_ADDR   0x0
 #define CONFIG_SYS_INIT_RAM_SIZE   0x8000  /* 32 KiB */
@@ -220,7 +220,8 @@
 #define CONFIG_SPL_PAD_TO  32768   /* decimal for 'dd' */
 
 #if defined(CONFIG_MACH_SUN9I) || defined(CONFIG_MACH_SUN50I)
-#define LOW_LEVEL_SRAM_STACK   0x0001A000
+/* FIXME: 40 KiB instead of 32 KiB ? */
+#define LOW_LEVEL_SRAM_STACK   0x00018000
 #define CONFIG_SPL_STACK   LOW_LEVEL_SRAM_STACK
 #else
 /* end of 32 KiB in sram */
-- 
2.8.2

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

[U-Boot] [PATCH 0/4] sunxi: Pine64 fixes

[Andre Przywara]

Some patches to fix the Pine64 support:
The first two patches revert two patches that actually broke booting
Pine64 via the boot0 blob, already in 2016.07.
This has been discussed on IRC before, the commit messages contain
some details on the reasons for the revert. As the intent of those
original fixes was to help the (not yet upstream) SPL support, we don't
loose anything as the Pine64 uses the U-Boot proper only at the moment.

Patch 3/4 removes the usage of a non-existing config symbol.
Patch 4/4 fixes a compiler warning when compiling sunxi's board.c
with a 64-bit compiler.

Please apply for the 2016.09 release to allow booting Pine64s with
a recent U-Boot.

Thanks,
Andre.


Andre Przywara (4):
  Revert "sunxi: Move the SPL stack top to 0x1A000 on Allwinner A64/A80"
  Revert "sunxi: Downclock AHB1 to 100MHz on Allwinner A64"
  sunxi: Kconfig: rename non-existent SUN50I_A64 config symbol
  sunxi: fix 64-bit compiler warning for SPL header parsing

 arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 5 -
 board/sunxi/Kconfig   | 2 +-
 board/sunxi/board.c   | 2 +-
 include/configs/sunxi-common.h| 5 +++--
 4 files changed, 5 insertions(+), 9 deletions(-)

-- 
2.8.2

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

[U-Boot] [PATCH 2/4] Revert "sunxi: Downclock AHB1 to 100MHz on Allwinner A64"

[Andre Przywara]

Now that we don't use SRAM C for the SPL stack anymore, there is no
need to clock down AHB1 to 100 MHz.
Keeping it at the recommended 200 MHz allows faster peripherals.

This reverts commit 5bc88cc2be3a962005b6e5768e06ca8f6ffcb88d.

Signed-off-by: Andre Przywara 
---
 arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h 
b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
index be9fcfd..f7e93b0 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
@@ -230,12 +230,7 @@ struct sunxi_ccm_reg {
 #define CCM_PLL5_TUN_INIT_FREQ(x)  (((x) & 0x7f) << 16)
 #define CCM_PLL5_TUN_INIT_FREQ_MASKCCM_PLL5_TUN_INIT_FREQ(0x7f)
 
-#if defined(CONFIG_MACH_SUN50I)
-/* AHB1=100MHz failsafe setup from the FEL mode, usable with PMIC defaults */
-#define AHB1_ABP1_DIV_DEFAULT  0x3190 /* AHB1=PLL6/6,APB1=AHB1/2 */
-#else
 #define AHB1_ABP1_DIV_DEFAULT  0x3180 /* AHB1=PLL6/3,APB1=AHB1/2 */
-#endif
 
 #define AXI_GATE_OFFSET_DRAM   0
 
-- 
2.8.2

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

[U-Boot] [PATCH 3/4] sunxi: Kconfig: rename non-existent SUN50I_A64 config symbol

[Andre Przywara]

There is no "CONFIG_MACH_SUN50I_A64" in upstream U-Boot, so fix
the name to prevent the option to be enabled.

Signed-off-by: Andre Przywara 
---
 board/sunxi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 1b30669..3ec011a 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -426,7 +426,7 @@ config AXP_GPIO
 
 config VIDEO
bool "Enable graphical uboot console on HDMI, LCD or VGA"
-   depends on !MACH_SUN8I_A83T && !MACH_SUN8I_H3 && !MACH_SUN9I && 
!MACH_SUN50I_A64
+   depends on !MACH_SUN8I_A83T && !MACH_SUN8I_H3 && !MACH_SUN9I && 
!MACH_SUN50I
default y
---help---
Say Y here to add support for using a cfb console on the HDMI, LCD
-- 
2.8.2

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

Re: [U-Boot] [PATCH v2 0/4] Migrate Vybrid USB driver to driver model

[Marek Vasut]

On 09/03/2016 12:53 AM, Simon Glass wrote:
> Hi,
> 
> On 1 September 2016 at 03:49,   wrote:
>> On 16-08-23 15:17:12, Marek Vasut wrote:
>>> On 08/09/2016 08:14 PM, Sanchayan Maity wrote:
 Hello,

 This is the second version of the patchset for migrating Vybrid
 USB driver to driver model.

 Compare to the first version, this version takes care of dr_mode
 property and correctly handles OTG as well when gpio is specified
 for use as ID detection pin. This is an essential requirement for
 OTG as Vybrid USB controller is not a true OTG though it can be
 configured as either host or device. The ID pin which is unique
 for OTG operation is not present on Vybrid.

 The problem with client that I was observing was related to sequence
 numbers. While trying to implement the OTG functionality I observed
 that if during probe of USB0 if it returns ENODEV, the probe of USB1
 provides a sequence number of 0 while we expect 1. The code relies
 on sequence numbers for initialising the appropriate peripherals.
 I use the bind operation to force a sequence number. This also seems
 to solve the problems I was having with USB client and mentioned
 in the previous version of the patchset.

 Host and client functionality are both functional with this patch.
 Patch series is based on top of latest u-boot master at the moment
 of this writing. Tested on Toradex Colibri Vybrid VF61 module.

 Thanks to Lukasz and Stefan for their comments.

 V1 Patches:
 [1].
 https://patchwork.ozlabs.org/patch/655370/
 [2].
 https://patchwork.ozlabs.org/patch/655371/
 [3].
 https://patchwork.ozlabs.org/patch/655372/
 [4].
 https://patchwork.ozlabs.org/patch/655373/

 Sanchayan Maity (4):
   usb: host: ehci-vf: Migrate Vybrid USB to driver model
   ARM: dts: vf: Add device tree node for USB on Vybrid
   ARM: dts: vf-colibri: Enable USB device tree node for Colibri Vybrid
   configs: colibri_vf_defconfig: Enable USB driver model for Colibri Vybrid

  arch/arm/dts/vf-colibri.dtsi |  11 +++
  arch/arm/dts/vf.dtsi |  14 +++
  configs/colibri_vf_defconfig |   1 +
  drivers/usb/host/ehci-vf.c   | 208 
 +--
  4 files changed, 227 insertions(+), 7 deletions(-)

>>>
>>> Looks OK to me, Simon, since this is DM, can you review it ?
>>>
>>
>> Hello Simon,
>>
>> Do you think the patchset is ok?
> 
> Yes I think so.

Applied to u-boot-usb/next .


-- 
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 RFC 5/5] imx: mx6ul: Add initial board support for Engicam GEAM6UL

[Fabio Estevam]

On Sun, Sep 4, 2016 at 10:32 AM, Jagan Teki  wrote:

> Please do read the thread fully before commenting, I've mentioned the
> state of hardware when I relied to Peng. And also this is an RFC patch
> I'm looking for comments on function like changes whether the flow of
> adding code to existing software is meaningful or not and not intended
> to directly applying these onto ML.

I have already stated my opinion that you should put your board code
into board/engicam.

> But I prefer to maintain the same on board/freescale/imx6ul. Becuase,
> If the most of the code is common to all boards with specific SOC it's
> better to have common code for reusability instead of adding different
> board files with duplicate code. For example please see board/sunxi or
> board/xilinx/zynq where microzed, zed or zynbo not directly
> manufactured from xilinx but they maintained as common.

All the ifdefery inside board/sunxi/board.c is exactly what I would
like to avoid here.

mx6ul is a recent SoC and there is only mx6ul evk and pico mx6ul
boards currently supported in U-Boot.

I don't think this can scale to support all upcoming boards into a
single board/freescale/mx6ul/board.c.

Why is mx6ul special in this case compared to the other mx6 variants?

Will you be able to support all mx6q boards into
board/freescale/mx6q/board.c as well?

I am sure this will be unmaintainable.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH RFC 5/5] imx: mx6ul: Add initial board support for Engicam GEAM6UL

[Jagan Teki]

On Sun, Sep 4, 2016 at 6:56 AM, Fabio Estevam  wrote:
> On Sat, Sep 3, 2016 at 5:22 AM, Jagan Teki  wrote:
>> i.MX6UL GEA M6UL modules are system on module solutions manufactured
>> by Engicam with following characteristics:
>> Processor   NXP i.MX 6UltraLite MCIMX6G2, 528 MHz
>> RAM 128MB, 16-bit DDR3
>> NAND SLC256MB
>> Power supplySingle 5V
>> MAX LCD RES up to WXGA, 1366x768
>>
>> Cc: Stefano Babic 
>> Cc: Peng Fan 
>> Cc: Michael Trimarchi 
>> Signed-off-by: Jagan Teki 
>> ---
>>  arch/arm/cpu/armv7/mx6/Kconfig|  6 ++
>>  board/freescale/mx6ul/Kconfig |  2 +-
>
> This file does not exist.
>
>>  board/freescale/mx6ul/MAINTAINERS |  5 +
>>  board/freescale/mx6ul/board.c |  4 +++-
>
> This file does not exist.
>
>>  configs/mx6ul_geam_kit_defconfig  | 11 +++
>>  include/configs/mx6ul.h   |  1 +
>
> This file does not exist.

These files are the outcomes of previous patches on this series,
please find that.

>
> You should generate a patch against u-boot-imx git tree.

OK, will do that.

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

Re: [U-Boot] [PATCH] treewide: compress lines for immediate return

[Marek Vasut]

On 09/04/2016 01:38 AM, Masahiro Yamada wrote:
> 2016-09-02 23:12 GMT+09:00 Marek Vasut :
>> On 09/02/2016 03:09 PM, Masahiro Yamada wrote:
>>> 2016-09-02 20:58 GMT+09:00 Marek Vasut :
 On 09/02/2016 12:36 PM, Masahiro Yamada wrote:
>   -ret = expression;
>   -if (ret)
>   -return ret;
>   -return 0;
>   +return expression;
>
> Signed-off-by: Masahiro Yamada 
> ---

 The thing I miss in the commit message is -- why is this change
 beneficial/needed ?

>>>
>>> I thought the benefit was apparent.
>>>
>>> Wasn't it to you?
>>
>> Nope, please explain.
>>
> 
> This is a cleanup patch; it removes
> unneeded variable assignments, if conditionals.

This should be in the commit message.

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

Re: [U-Boot] [PATCH 1/5] imx: mx6ul: Refactor common code as mx6ul

[Jagan Teki]

Hi Fabio,

On Sun, Sep 4, 2016 at 7:57 AM, Fabio Estevam  wrote:
> Hi Jagan,
>
> On Sat, Sep 3, 2016 at 5:22 AM, Jagan Teki  wrote:
>> Since most of the board along with the config code used for
>> mx6ul boards are common and for improving code reusability
>> refactor or group code as mx6ul notation. Hence for new board
>> its simply add new defconfig with existing board or related configs.
>>
>> include/configs/mx6ul_14x14_evk.h -> include/configs/mx6ul.h
>> board/freescale/mx6ul_14x14_evk -> board/freescale/mx6ul
>> board/freescale/mx6ul/mx6ul_14x14_evk.c -> board/freescale/mx6ul/board.c
>
> I think this will be hard to maintain. I still prefer each board to be
> added on its own board file/dts.

Initially I started of doing this, but I find most of the redundant
code board as well in configs, its better follow this kind of notation
because most of the remaining soc board files are so mature like this
sunxi, zynq.

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

Re: [U-Boot] [PATCH RFC 5/5] imx: mx6ul: Add initial board support for Engicam GEAM6UL

[Jagan Teki]

Hi Fabio,

On Sun, Sep 4, 2016 at 7:53 AM, Fabio Estevam  wrote:
> Hi Jagan,
>
> On Sat, Sep 3, 2016 at 10:26 PM, Fabio Estevam  wrote:
>
>>>  configs/mx6ul_geam_kit_defconfig  | 11 +++
>>>  include/configs/mx6ul.h   |  1 +
>>
>> This file does not exist.
>
> Ok, I see you introduced these files on previous patches of the series.
>
> I don't think it makes sense to have a global mx6ul.h though.

Please review the respective patches and let me know your comments. I
strongly suspect the global mx6ul.h require as number board with same
soc have different defcoonfigs which is similar to the way common
imx6ul.dtsi with respective board dts files.

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

Re: [U-Boot] [PATCH 1/2] spi: ti_qspi: use 128 bit transfer mode when writing to flash

[Jagan Teki]

On Thu, Sep 1, 2016 at 1:24 PM, Vignesh R  wrote:
> TI QSPI has four 32 bit data registers which can be used to transfer 16
> bytes of data at once. The register group QSPI_SPI_DATA_REG_3,
> QSPI_SPI_DATA_REG_2, QSPI_SPI_DATA_REG_1 and QSPI_SPI_DATA_REG is
> treated as a single 128-bit word for shifting data in and out. The bit
> at QSPI_SPI_DATA_REG_3[31] position is the first bit to be shifted out
> in case of 128 bit transfer mode. Therefore the first byte to be written
> to flash should be at QSPI_SPI_DATA_REG_3[31-25] position.
> Instead of writing 1 byte at a time when interacting with SPI NOR flash,
> make use of all the four registers so that 16 bytes can be transferred
> in one go.
>
> With this patch, the flash write speed increases from ~250KBs/ to
> ~650KB/s on DRA74 EVM.
>
> Signed-off-by: Vignesh R 
> ---
>  drivers/spi/ti_qspi.c | 37 +++--
>  1 file changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
> index bb72cb03ec24..fe2a280cc7ae 100644
> --- a/drivers/spi/ti_qspi.c
> +++ b/drivers/spi/ti_qspi.c
> @@ -23,6 +23,8 @@ DECLARE_GLOBAL_DATA_PTR;
>  #define QSPI_TIMEOUT200
>  #define QSPI_FCLK  19200
>  #define QSPI_DRA7XX_FCLK7680
> +#define QSPI_WLEN_MAX_BITS 128
> +#define QSPI_WLEN_MAX_BYTES(QSPI_WLEN_MAX_BITS >> 3)
>  /* clock control */
>  #define QSPI_CLK_EN BIT(31)
>  #define QSPI_CLK_DIV_MAX0x
> @@ -230,13 +232,33 @@ static int __ti_qspi_xfer(struct ti_qspi_priv *priv, 
> unsigned int bitlen,
>  #ifdef CONFIG_AM43XX
> udelay(100);
>  #endif
> -   while (words--) {
> +   while (words) {
> +   u8 xfer_len = 0;
> +
> if (txp) {
> -   debug("tx cmd %08x dc %08x data %02x\n",
> - priv->cmd | QSPI_WR_SNGL, priv->dc, *txp);
> -   writel(*txp++, >base->data);
> -   writel(priv->cmd | QSPI_WR_SNGL,
> -  >base->cmd);
> +   u32 cmd = priv->cmd;

Don't we require cmd mask for WLEN_MAX_BITS?

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

Re: [U-Boot] [PATCH 2/2] spi: ti_qspi: Remove unnecessary udelay for AM437x

[Jagan Teki]

On Fri, Sep 2, 2016 at 8:24 PM, Tom Rini  wrote:
> On Thu, Sep 01, 2016 at 01:24:40PM +0530, Vignesh R wrote:
>
>> This udelay() was added as an HACK and is no longer required. All
>> read/write/erase operations work fine even without this delay. Hence,
>> remove the udelay() call.
>>
>> Tested read/write/erase operation on AM437x SK. Also tested QSPI Boot.
>>
>> Signed-off-by: Vignesh R 
>
> Reviewed-by: Tom Rini 

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] spi: zynq: Use variable to remove u32 to u64 conversions

[Jagan Teki]

On Thu, Sep 1, 2016 at 7:38 PM, Michal Simek  wrote:
> Current code generates warning when it is compiled for arm64:
> Warnings:
> In file included from drivers/spi/zynq_spi.c:14:0:
> drivers/spi/zynq_spi.c: In function ‘zynq_spi_init_hw’:
> drivers/spi/zynq_spi.c:95:9: warning: large integer implicitly truncated
> to unsigned type [-Woverflow]
>   writel(~ZYNQ_SPI_ENR_SPI_EN_MASK, >enr);
>  ^
> ./arch/arm/include/asm/io.h:146:34: note: in definition of macro
> ‘writel’
>  #define writel(v,c) ({ u32 __v = v; __iowmb(); __arch_putl(__v,c); __v;
> })
>   ^
> drivers/spi/zynq_spi.c: In function ‘zynq_spi_release_bus’:
> drivers/spi/zynq_spi.c:177:9: warning: large integer implicitly
> truncated to unsigned type [-Woverflow]
>   writel(~ZYNQ_SPI_ENR_SPI_EN_MASK, >enr);
>  ^
> ./arch/arm/include/asm/io.h:146:34: note: in definition of macro
> ‘writel’
>  #define writel(v,c) ({ u32 __v = v; __iowmb(); __arch_putl(__v,c); __v;
> })
>   ^
> This patch is using one variable to do conversion via u32 variable.
>
> Signed-off-by: Michal Simek 

Reviewed-by: Jagan Teki 


thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH RFC 5/5] imx: mx6ul: Add initial board support for Engicam GEAM6UL

[Jagan Teki]

Hi Fabio,

+ Tom (looking for any suggestions for not maintaining separate board
files if the board code is sharing different boards with same SOC)

On Sun, Sep 4, 2016 at 6:38 PM, Fabio Estevam  wrote:
> Hi Jagan,
>
> On Sat, Sep 3, 2016 at 5:22 AM, Jagan Teki  wrote:
>>
>> diff --git a/board/freescale/mx6ul/Kconfig b/board/freescale/mx6ul/Kconfig
>> index f97b905..d902cd0 100644
>> --- a/board/freescale/mx6ul/Kconfig
>> +++ b/board/freescale/mx6ul/Kconfig
>
> At least for i.MX we follow the convention:
> board/vendor/vendorboardname, so under board/freescale directory we
> would expect boards manufactured by FSL/NXP only.

Please see below for this.

>
>> @@ -1,4 +1,4 @@
>> -if TARGET_MX6UL_14X14_EVK || TARGET_MX6UL_9X9_EVK
>> +if TARGET_MX6UL_14X14_EVK || TARGET_MX6UL_9X9_EVK || TARGET_MX6UL_GEAM_KIT
>>
>>  config SYS_BOARD
>> default "mx6ul"
>> diff --git a/board/freescale/mx6ul/MAINTAINERS 
>> b/board/freescale/mx6ul/MAINTAINERS
>> index 20caeee..3265858 100644
>> --- a/board/freescale/mx6ul/MAINTAINERS
>> +++ b/board/freescale/mx6ul/MAINTAINERS
>> @@ -5,3 +5,8 @@ F:  board/freescale/mx6ul/
>
> It would be better if you were listed as the maintainer of the Engicam
> mx6ul board.
>
> How can I person that does not have the hardware nor it is familiar
> with it, be the maintainer of such platform?

Please do read the thread fully before commenting, I've mentioned the
state of hardware when I relied to Peng. And also this is an RFC patch
I'm looking for comments on function like changes whether the flow of
adding code to existing software is meaningful or not and not intended
to directly applying these onto ML.

>
>> --- a/board/freescale/mx6ul/board.c
>> +++ b/board/freescale/mx6ul/board.c
>> @@ -693,8 +693,10 @@ int checkboard(void)
>>  {
>> if (is_mx6ul_9x9_evk())
>> puts("Board: MX6UL 9x9 EVK\n");
>> -   else
>> +   else if (is_mx6ul_14x14_evk())
>> puts("Board: MX6UL 14x14 EVK\n");
>> +   else
>> +   puts("Board: MX6UL GEA KIT\n");
>>
>> return 0;
>
> If I want to change board.c to improve/fix the code for mx6ulevk there
> is risk that such change could break mx6ulgea support.
>
> I prefer that you place the new board at board/engicam/mx6ulgea, or something.

But I prefer to maintain the same on board/freescale/imx6ul. Becuase,
If the most of the code is common to all boards with specific SOC it's
better to have common code for reusability instead of adding different
board files with duplicate code. For example please see board/sunxi or
board/xilinx/zynq where microzed, zed or zynbo not directly
manufactured from xilinx but they maintained as common.

>
>
>> --- a/include/configs/mx6ul.h
>> +++ b/include/configs/mx6ul.h
>> @@ -14,6 +14,7 @@
>>  #include 
>>
>>  #define is_mx6ul_9x9_evk() CONFIG_IS_ENABLED(TARGET_MX6UL_9X9_EVK)
>> +#define is_mx6ul_14x14_evk()   CONFIG_IS_ENABLED(TARGET_MX6UL_14x14_EVK)
>
> This seems to be an unrelated change.

OK, will fix.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH RFC 5/5] imx: mx6ul: Add initial board support for Engicam GEAM6UL

[Michael Trimarchi]

Hi Fabio

On Sun, Sep 4, 2016 at 3:08 PM, Fabio Estevam  wrote:
> Hi Jagan,
>
> On Sat, Sep 3, 2016 at 5:22 AM, Jagan Teki  wrote:
>>
>> diff --git a/board/freescale/mx6ul/Kconfig b/board/freescale/mx6ul/Kconfig
>> index f97b905..d902cd0 100644
>> --- a/board/freescale/mx6ul/Kconfig
>> +++ b/board/freescale/mx6ul/Kconfig
>
> At least for i.MX we follow the convention:
> board/vendor/vendorboardname, so under board/freescale directory we
> would expect boards manufactured by FSL/NXP only.
>
>> @@ -1,4 +1,4 @@
>> -if TARGET_MX6UL_14X14_EVK || TARGET_MX6UL_9X9_EVK
>> +if TARGET_MX6UL_14X14_EVK || TARGET_MX6UL_9X9_EVK || TARGET_MX6UL_GEAM_KIT
>>
>>  config SYS_BOARD
>> default "mx6ul"
>> diff --git a/board/freescale/mx6ul/MAINTAINERS 
>> b/board/freescale/mx6ul/MAINTAINERS
>> index 20caeee..3265858 100644
>> --- a/board/freescale/mx6ul/MAINTAINERS
>> +++ b/board/freescale/mx6ul/MAINTAINERS
>> @@ -5,3 +5,8 @@ F:  board/freescale/mx6ul/
>
> It would be better if you were listed as the maintainer of the Engicam
> mx6ul board.
>
> How can I person that does not have the hardware nor it is familiar
> with it, be the maintainer of such platform?
>

Hardware is on the way ;).

Michael

>> --- a/board/freescale/mx6ul/board.c
>> +++ b/board/freescale/mx6ul/board.c
>> @@ -693,8 +693,10 @@ int checkboard(void)
>>  {
>> if (is_mx6ul_9x9_evk())
>> puts("Board: MX6UL 9x9 EVK\n");
>> -   else
>> +   else if (is_mx6ul_14x14_evk())
>> puts("Board: MX6UL 14x14 EVK\n");
>> +   else
>> +   puts("Board: MX6UL GEA KIT\n");
>>
>> return 0;
>
> If I want to change board.c to improve/fix the code for mx6ulevk there
> is risk that such change could break mx6ulgea support.
>
> I prefer that you place the new board at board/engicam/mx6ulgea, or something.
>
>
>> --- a/include/configs/mx6ul.h
>> +++ b/include/configs/mx6ul.h
>> @@ -14,6 +14,7 @@
>>  #include 
>>
>>  #define is_mx6ul_9x9_evk() CONFIG_IS_ENABLED(TARGET_MX6UL_9X9_EVK)
>> +#define is_mx6ul_14x14_evk()   CONFIG_IS_ENABLED(TARGET_MX6UL_14x14_EVK)
>
> This seems to be an unrelated change.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH RFC 5/5] imx: mx6ul: Add initial board support for Engicam GEAM6UL

[Fabio Estevam]

Hi Jagan,

On Sat, Sep 3, 2016 at 5:22 AM, Jagan Teki  wrote:
>
> diff --git a/board/freescale/mx6ul/Kconfig b/board/freescale/mx6ul/Kconfig
> index f97b905..d902cd0 100644
> --- a/board/freescale/mx6ul/Kconfig
> +++ b/board/freescale/mx6ul/Kconfig

At least for i.MX we follow the convention:
board/vendor/vendorboardname, so under board/freescale directory we
would expect boards manufactured by FSL/NXP only.

> @@ -1,4 +1,4 @@
> -if TARGET_MX6UL_14X14_EVK || TARGET_MX6UL_9X9_EVK
> +if TARGET_MX6UL_14X14_EVK || TARGET_MX6UL_9X9_EVK || TARGET_MX6UL_GEAM_KIT
>
>  config SYS_BOARD
> default "mx6ul"
> diff --git a/board/freescale/mx6ul/MAINTAINERS 
> b/board/freescale/mx6ul/MAINTAINERS
> index 20caeee..3265858 100644
> --- a/board/freescale/mx6ul/MAINTAINERS
> +++ b/board/freescale/mx6ul/MAINTAINERS
> @@ -5,3 +5,8 @@ F:  board/freescale/mx6ul/

It would be better if you were listed as the maintainer of the Engicam
mx6ul board.

How can I person that does not have the hardware nor it is familiar
with it, be the maintainer of such platform?

> --- a/board/freescale/mx6ul/board.c
> +++ b/board/freescale/mx6ul/board.c
> @@ -693,8 +693,10 @@ int checkboard(void)
>  {
> if (is_mx6ul_9x9_evk())
> puts("Board: MX6UL 9x9 EVK\n");
> -   else
> +   else if (is_mx6ul_14x14_evk())
> puts("Board: MX6UL 14x14 EVK\n");
> +   else
> +   puts("Board: MX6UL GEA KIT\n");
>
> return 0;

If I want to change board.c to improve/fix the code for mx6ulevk there
is risk that such change could break mx6ulgea support.

I prefer that you place the new board at board/engicam/mx6ulgea, or something.


> --- a/include/configs/mx6ul.h
> +++ b/include/configs/mx6ul.h
> @@ -14,6 +14,7 @@
>  #include 
>
>  #define is_mx6ul_9x9_evk() CONFIG_IS_ENABLED(TARGET_MX6UL_9X9_EVK)
> +#define is_mx6ul_14x14_evk()   CONFIG_IS_ENABLED(TARGET_MX6UL_14x14_EVK)

This seems to be an unrelated change.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Building u-boot.imx and SPL simultaneously

[Stefano Babic]

Hi Otavio,

On 03/09/2016 22:27, Otavio Salvador wrote:
> On Sat, Sep 3, 2016 at 6:40 AM, Stefano Babic  wrote:
>> On 03/09/2016 01:15, Petr Kulhavy wrote:
>>> You are saying that in order to cover my use case(s) I need two
>>> defconfigs. Well, ok...
>>> But how do I integrate this into Buildroot? For the sake of
>>> maintainability, simplification, reducing chance for an error during
>>> build I want to have one Buildroot defconfig, run one build command and
>>> get all the necessary images.
>>> How do I do that with two U-boot defconfigs?
>>
>> I am noit a Buildroot expert, someone else can better point you in the
>> right direction. I will expect that you need a second target. If I had
>> to do thuis in Yoct, I will tend to add a new recipe to build .imx variant.
> 
> On OpenEmbedded-based systems, as is the case of Yocto Project, we
> introduced the UBOOT_CONFIG mechanism for this. So for example in:
> 
> https://github.com/Freescale/meta-fsl-arm/blob/master/conf/machine/imx6slevk.conf#L15
> 
> The UBOOT_CONFIG is changed, in local.conf for a machine, to:
> 
> UBOOT_CONFIG = "spinor sd"
> 
> Both as build.
> 

Thanks for the hint - this is an elegant solution for Yocto.

Best regards,
Stefano

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