date:20150526

Hi Fabio,

On 27/05/2015 04:22, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> Commit 8183058188cd2d942 ("imx6: centralise common boot options in
> mx6_common.h") broke boot on mx6sl and mx6sx by assuming that all mx6
> SoCs use the same LOADADDR/SYS_TEXT_BASE range, which is not correct.
> 
> DDR on mx6sx/mx6sl starts at 0x8000.
> 
> Adjust LOADADDR/SYS_TEXT_BASE to the proper values for mx6sx/mx6sl,
> so that these SoCs can boot again.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  include/configs/mx6_common.h | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h
> index 233c6d2..bd16ec2 100644
> --- a/include/configs/mx6_common.h
> +++ b/include/configs/mx6_common.h
> @@ -53,10 +53,15 @@
>  #define CONFIG_REVISION_TAG
>  
>  /* Boot options */
> +#if (defined(CONFIG_MX6SX) || defined(CONFIG_MX6SL))
> +#define CONFIG_LOADADDR  0x8200
> +#define CONFIG_SYS_TEXT_BASE 0x8780
> +#else
>  #define CONFIG_LOADADDR  0x1200
> +#define CONFIG_SYS_TEXT_BASE 0x1780
> +#endif
>  #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR
>  #ifndef CONFIG_SYS_TEXT_BASE
> -#define CONFIG_SYS_TEXT_BASE 0x1780
>  #endif
>  #ifndef CONFIG_BOOTDELAY
>  #define CONFIG_BOOTDELAY 3
> 

Acked-by: Stefano Babic 

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 0/10 v3] i.MX6: move duplicated options to mx6_common to standardise mx6 config

Hi Fabio,

On 27/05/2015 04:08, Fabio Estevam wrote:
> On Tue, May 26, 2015 at 10:45 PM, Fabio Estevam  wrote:
>> On Tue, May 26, 2015 at 11:06 AM, Stefano Babic  wrote:
>>> Hi Peter, Heiko,
>>>
>>> On 26/05/2015 15:23, Peter Robinson wrote:

 Please do, getting them applied so we can move forward would be great.

>>>
>>> Ok, all boards compile fine now - I have pushed all changes.
>>
>> I noticed that this series broke warp board and the board does not boot 
>> anymore.
>>
>> Reverting this series I am able to boot it again.
> 
> Ok, so the problem is commit 8183058188c ("imx6: centralise common
> boot options in mx6_common.h"), as it changes all mx6 SoCs to use
> CONFIG_LOADADDR=0x1200, but this is not correct for mx6sx and
> mx6sl that should use 0x8200 instead.
> 

urgh...thanks to have solved this, I will pick up your patches soon.

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 05/20] armv8/ls2085a: call ft_pcie_setup() to change dts status

2015-05-26 Thread Lian M . H .

Hi York,

1. board/freescale/ls2085a/ls2085a.c is for board ls2085a_emu like ls2085aqds.c 
not SoC file.
But I am not sure whether  emulator board should call this function.
2. ft_pcie_setup(blob, bd) should be changed to ft_pci_setup(blob, bd)
ft_pci_setup is the common function name defined in common.h

Thanks,
Minghuan

> -Original Message-
> From: Sun York-R58495
> Sent: Tuesday, May 26, 2015 11:54 PM
> To: Kushwaha Prabhakar-B32579; u-boot@lists.denx.de
> Cc: Lian Minghuan-B31939
> Subject: Re: [PATCH 05/20] armv8/ls2085a: call ft_pcie_setup() to change dts
> status
> 
> Prabhakar and Minghuan,
> 
> On 05/18/2015 12:08 AM, Prabhakar Kushwaha wrote:
> > From: Minghuan Lian 
> >
> >  1. The patch call ft_pcie_setup() to disable PCIe dts node if
> > corresponding PCIe controller is disabled according to RCW.
> >  2. Fix LS2085a PCIe compatible
> >
> > Signed-off-by: Minghuan Lian 
> > Signed-off-by: Prabhakar Kushwaha 
> > ---
> >  board/freescale/ls2085a/ls2085a.c   | 4 
> >  board/freescale/ls2085aqds/ls2085aqds.c | 4 
> > board/freescale/ls2085ardb/ls2085ardb.c | 4 
> >  include/configs/ls2085a_common.h| 3 ++-
> >  4 files changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/board/freescale/ls2085a/ls2085a.c
> > b/board/freescale/ls2085a/ls2085a.c
> > index dd0acf2..afb99d1 100644
> > --- a/board/freescale/ls2085a/ls2085a.c
> > +++ b/board/freescale/ls2085a/ls2085a.c
> > @@ -142,6 +142,10 @@ int ft_board_setup(void *blob, bd_t *bd)
> > fsl_mc_ldpaa_exit(bd);
> >  #endif
> >
> > +#ifdef CONFIG_PCI
> > +   ft_pcie_setup(blob, bd);
> > +#endif
> > +
> 
> Shouldn't this function be called from SoC function? It is not a board-
> dependent setup, but rather depending on RCW which is an SoC feature.
> 
> York

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

[U-Boot] [PATCH v2 2/2] kbuild: create symbolic link only for ARM, SPARC, PowerPC, x86

The symbolic link to SoC/CPU specific header directory is created
during the build, while it is only necessary for ARM, SPARC, x86,
and some CPUs of PowerPC.  For the other architectures, it just
results in a broken symbolic link.

Introduce CONFIG_CREATE_ARCH_SYMLINK to not create unneeded symbolic
links.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Use 'ifdef CONFIG_CREATE_ARCH_SYMLINK' for readability

 arch/Kconfig  | 6 ++
 arch/powerpc/Kconfig  | 3 +++
 scripts/Makefile.autoconf | 2 ++
 3 files changed, 11 insertions(+)

diff --git a/arch/Kconfig b/arch/Kconfig
index 200588a..c495267 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1,3 +1,6 @@
+config CREATE_ARCH_SYMLINK
+   bool
+
 config HAVE_GENERIC_BOARD
bool
 
@@ -18,6 +21,7 @@ config ARC
 
 config ARM
bool "ARM architecture"
+   select CREATE_ARCH_SYMLINK
select HAVE_PRIVATE_LIBGCC
select HAVE_GENERIC_BOARD
select SUPPORT_OF_CONTROL
@@ -83,9 +87,11 @@ config SH
 
 config SPARC
bool "SPARC architecture"
+   select CREATE_ARCH_SYMLINK
 
 config X86
bool "x86 architecture"
+   select CREATE_ARCH_SYMLINK
select HAVE_PRIVATE_LIBGCC
select HAVE_GENERIC_BOARD
select SYS_GENERIC_BOARD
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 3b3f446..18451d3 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -22,9 +22,11 @@ config MPC8260
 
 config MPC83xx
bool "MPC83xx"
+   select CREATE_ARCH_SYMLINK
 
 config MPC85xx
bool "MPC85xx"
+   select CREATE_ARCH_SYMLINK
 
 config MPC86xx
bool "MPC86xx"
@@ -34,6 +36,7 @@ config 8xx
 
 config 4xx
bool "PPC4xx"
+   select CREATE_ARCH_SYMLINK
 
 endchoice
 
diff --git a/scripts/Makefile.autoconf b/scripts/Makefile.autoconf
index f054081..7387654 100644
--- a/scripts/Makefile.autoconf
+++ b/scripts/Makefile.autoconf
@@ -106,6 +106,7 @@ include/config.h: scripts/Makefile.autoconf create_symlink 
FORCE
 # Otherwise, create a symbolic link to arch/$(ARCH)/include/asm/arch-$(SOC).
 PHONY += create_symlink
 create_symlink:
+ifdef CONFIG_CREATE_ARCH_SYMLINK
 ifneq ($(KBUILD_SRC),)
$(Q)mkdir -p include/asm
$(Q)if [ -d $(KBUILD_SRC)/arch/$(ARCH)/mach-$(SOC)/include/mach ]; then 
\
@@ -122,6 +123,7 @@ else
fi; \
ln -fsn $$dest arch/$(ARCH)/include/asm/arch
 endif
+endif
 
 PHONY += FORCE
 FORCE:
-- 
1.9.1

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

[U-Boot] [PATCH v2 0/2] kbuild: create a symbolic link only when necessary

1/2: refactors a little because NDS32 actually need not the symbolic link
2/2: introduce a new config to avoid broken symbolic links.


Changes in v2:
  - Use 'ifdef CONFIG_CREATE_ARCH_SYMLINK' for readability

Masahiro Yamada (2):
  nds32: include  instead of 
  kbuild: create symbolic link only for ARM, SPARC, PowerPC, x86

 arch/Kconfig | 6 ++
 arch/powerpc/Kconfig | 3 +++
 include/configs/adp-ag101.h  | 2 +-
 include/configs/adp-ag101p.h | 2 +-
 include/configs/adp-ag102.h  | 2 +-
 scripts/Makefile.autoconf| 2 ++
 6 files changed, 14 insertions(+), 3 deletions(-)

-- 
1.9.1

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

[U-Boot] [PATCH v2 1/2] nds32: include instead of

There are only two SoC-specific headers for this architecture:
 - arch/nds32/include/asm/arch-ag101/ag101.h
 - arch/nds32/include/asm/arch-ag102/ag102.h

Those two have different file names, so there is no advantage to
include them via symbolic linked directory.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 include/configs/adp-ag101.h  | 2 +-
 include/configs/adp-ag101p.h | 2 +-
 include/configs/adp-ag102.h  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/adp-ag101.h b/include/configs/adp-ag101.h
index e318c75..f70ee10 100644
--- a/include/configs/adp-ag101.h
+++ b/include/configs/adp-ag101.h
@@ -9,7 +9,7 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#include 
+#include 
 
 /*
  * CPU and Board Configuration Options
diff --git a/include/configs/adp-ag101p.h b/include/configs/adp-ag101p.h
index 24904b0..60a5038 100644
--- a/include/configs/adp-ag101p.h
+++ b/include/configs/adp-ag101p.h
@@ -9,7 +9,7 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#include 
+#include 
 
 /*
  * CPU and Board Configuration Options
diff --git a/include/configs/adp-ag102.h b/include/configs/adp-ag102.h
index 39f7a3c..ffd5d33 100644
--- a/include/configs/adp-ag102.h
+++ b/include/configs/adp-ag102.h
@@ -8,7 +8,7 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#include 
+#include 
 
 /*
  * CPU and Board Configuration Options
-- 
1.9.1

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

[U-Boot] [PATCH] net: designware: fix driver name

It is working, but not nice...

Signed-off-by: Masahiro Yamada 
---

 drivers/net/designware.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index ae51cf3..bfce218 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -605,7 +605,7 @@ static const struct udevice_id designware_eth_ids[] = {
{ }
 };
 
-U_BOOT_DRIVER(eth_sandbox) = {
+U_BOOT_DRIVER(eth_designware) = {
.name   = "eth_designware",
.id = UCLASS_ETH,
.of_match = designware_eth_ids,
-- 
1.9.1

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

[U-Boot] [PATCH v2 5/7] ARM: UniPhier: set MACH_PH1_PRO4 as default SoC

One disadvantage of commit a26cd04920dc (arch: Make board selection
choices optional) is that Kconfig could create such an insane
.config file that no board is selected.

As PH1-Pro4 is the main stream of UniPhier SoC family, rip off the
"optional" again in favor of PH1-Pro4 as the default SoC.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Newly added

 arch/arm/mach-uniphier/Kconfig | 2 +-
 configs/ph1_pro4_defconfig | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-uniphier/Kconfig b/arch/arm/mach-uniphier/Kconfig
index 2d27c49..cba83d6 100644
--- a/arch/arm/mach-uniphier/Kconfig
+++ b/arch/arm/mach-uniphier/Kconfig
@@ -9,7 +9,7 @@ config UNIPHIER_SMP
 
 choice
prompt "UniPhier SoC select"
-   optional
+   default MACH_PH1_PRO4
 
 config MACH_PH1_PRO4
bool "PH1-Pro4"
diff --git a/configs/ph1_pro4_defconfig b/configs/ph1_pro4_defconfig
index cc3a9a4..65ff3e0 100644
--- a/configs/ph1_pro4_defconfig
+++ b/configs/ph1_pro4_defconfig
@@ -1,7 +1,6 @@
 CONFIG_ARM=y
 CONFIG_ARCH_UNIPHIER=y
 CONFIG_SPL_DM=y
-CONFIG_MACH_PH1_PRO4=y
 CONFIG_PFC_MICRO_SUPPORT_CARD=y
 CONFIG_SYS_TEXT_BASE=0x8400
 CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-pro4-ref"
-- 
1.9.1

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

[U-Boot] [PATCH v2 6/7] ARM: UniPhier: enable CONFIG_NET_RANDOM_ETHADDR

Since commit 92ac52082140 (net: Remove all references to
CONFIG_ETHADDR and friends), the ethernet device on UniPhier boards
is not working because of the incorrect (all-zero) MAC address.

Enable CONFIG_NET_RANDOM_ETHADDR to generate the random one.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Newly added

 configs/ph1_ld4_defconfig  | 2 ++
 configs/ph1_pro4_defconfig | 2 ++
 configs/ph1_sld8_defconfig | 2 ++
 3 files changed, 6 insertions(+)

diff --git a/configs/ph1_ld4_defconfig b/configs/ph1_ld4_defconfig
index 45d484e..82ce8c7 100644
--- a/configs/ph1_ld4_defconfig
+++ b/configs/ph1_ld4_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_UNIPHIER=y
 CONFIG_SPL_DM=y
 CONFIG_MACH_PH1_LD4=y
 CONFIG_PFC_MICRO_SUPPORT_CARD=y
+CONFIG_NET=y
 CONFIG_SYS_TEXT_BASE=0x8400
 CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-ld4-ref"
 CONFIG_FIT=y
@@ -31,6 +32,7 @@ CONFIG_CMD_TFTPPUT=y
 CONFIG_CMD_NFS=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_TIME=y
+CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_NAND_DENALI=y
 CONFIG_SYS_NAND_DENALI_64BIT=y
 CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8
diff --git a/configs/ph1_pro4_defconfig b/configs/ph1_pro4_defconfig
index 65ff3e0..671d9cc 100644
--- a/configs/ph1_pro4_defconfig
+++ b/configs/ph1_pro4_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_UNIPHIER=y
 CONFIG_SPL_DM=y
 CONFIG_PFC_MICRO_SUPPORT_CARD=y
+CONFIG_NET=y
 CONFIG_SYS_TEXT_BASE=0x8400
 CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-pro4-ref"
 CONFIG_FIT=y
@@ -30,6 +31,7 @@ CONFIG_CMD_TFTPPUT=y
 CONFIG_CMD_NFS=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_TIME=y
+CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_NAND_DENALI=y
 CONFIG_SYS_NAND_DENALI_64BIT=y
 CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8
diff --git a/configs/ph1_sld8_defconfig b/configs/ph1_sld8_defconfig
index fc79866..3e763dc 100644
--- a/configs/ph1_sld8_defconfig
+++ b/configs/ph1_sld8_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_UNIPHIER=y
 CONFIG_SPL_DM=y
 CONFIG_MACH_PH1_SLD8=y
 CONFIG_PFC_MICRO_SUPPORT_CARD=y
+CONFIG_NET=y
 CONFIG_SYS_TEXT_BASE=0x8400
 CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-sld8-ref"
 CONFIG_FIT=y
@@ -31,6 +32,7 @@ CONFIG_CMD_TFTPPUT=y
 CONFIG_CMD_NFS=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_TIME=y
+CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_NAND_DENALI=y
 CONFIG_SYS_NAND_DENALI_64BIT=y
 CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8
-- 
1.9.1

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

[U-Boot] [PATCH v2 7/7] ARM: UniPhier: update DDR PHY register map for PH1-Pro5

PH1-Pro5 includes a newer version of DDR PHY IP.  Some registers
have been added to the reserved areas.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 arch/arm/mach-uniphier/include/mach/ddrphy-regs.h | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-uniphier/include/mach/ddrphy-regs.h 
b/arch/arm/mach-uniphier/include/mach/ddrphy-regs.h
index 6b7d600..df7d815 100644
--- a/arch/arm/mach-uniphier/include/mach/ddrphy-regs.h
+++ b/arch/arm/mach-uniphier/include/mach/ddrphy-regs.h
@@ -1,8 +1,9 @@
 /*
  * UniPhier DDR PHY registers
  *
- * Copyright (C) 2014 Panasonic Corporation
- *   Author: Masahiro Yamada 
+ * Copyright (C) 2014-2015 Panasonic Corporation
+ * Copyright (C) 2015  Socionext Inc.
+ *   Author: Masahiro Yamada 
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
@@ -37,7 +38,10 @@ struct ddrphy {
u32 dtar[4];/* Data Training Address Register */
u32 dtdr[2];/* Data Training Data Register */
u32 dtedr[2];   /* Data Training Eye Data Register */
-   u32 rsv0[13];   /* Reserved */
+   u32 pgcr2;  /* PHY General Configuration Register 2 */
+   u32 rsv0[8];/* Reserved */
+   u32 rdimmgcr[2];/* RDIMM General Configuration Register */
+   u32 rdimmcr0[2];/* RDIMM Control Register */
u32 dcuar;  /* DCU Address Register */
u32 dcudr;  /* DCU Data Register */
u32 dcurr;  /* DCU Run Register */
@@ -70,7 +74,8 @@ struct ddrphy {
u32 lcdlr[3];   /* Local Calibrated Delay Line Register */
u32 mdlr;   /* Master Delay Line Register */
u32 gtr;/* General Timing Register */
-   u32 rsv[3]; /* Reserved */
+   u32 gsr2;   /* General Status Register 2 */
+   u32 rsv[2]; /* Reserved */
} dx[9];
 };
 
-- 
1.9.1

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

[U-Boot] [PATCH v2 0/7] UniPhier updates for v2015.07-rc2


Masahiro Yamada (7):
  ARM: UniPhier: use 32 bit register access for debug UART setting
  ARM: UniPhier: remove unnecessary cache coherency code
  ARM: UniPhier: remove meaningless CONFIG_SPL_BUILD ifdefs
  ARM: UniPhier: move CONFIG_SYS_TEXT_BASE to Kconfig
  ARM: UniPhier: set MACH_PH1_PRO4 as default SoC
  ARM: UniPhier: enable CONFIG_NET_RANDOM_ETHADDR
  ARM: UniPhier: update DDR PHY register map for PH1-Pro5

 Kconfig   |  2 +-
 arch/arm/mach-uniphier/Kconfig|  2 +-
 arch/arm/mach-uniphier/ddrphy_training.c  |  9 +++--
 arch/arm/mach-uniphier/include/mach/ddrphy-regs.h | 13 +
 arch/arm/mach-uniphier/include/mach/debug-uart.S  |  9 +
 arch/arm/mach-uniphier/lowlevel_init.S| 20 
 configs/ph1_ld4_defconfig |  3 +++
 configs/ph1_pro4_defconfig|  4 +++-
 configs/ph1_sld8_defconfig|  3 +++
 include/configs/uniphier.h|  2 --
 10 files changed, 28 insertions(+), 39 deletions(-)

-- 
1.9.1

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

[U-Boot] [PATCH v2 2/7] ARM: UniPhier: remove unnecessary cache coherency code

Cache coherency for SMP is cared by Linux.  In U-Boot, the secondary
CPU(s) are just sleeping.  Nothing in memory is shared with the
primary CPU.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 arch/arm/mach-uniphier/lowlevel_init.S | 20 
 1 file changed, 20 deletions(-)

diff --git a/arch/arm/mach-uniphier/lowlevel_init.S 
b/arch/arm/mach-uniphier/lowlevel_init.S
index 825b160..aaea7bf 100644
--- a/arch/arm/mach-uniphier/lowlevel_init.S
+++ b/arch/arm/mach-uniphier/lowlevel_init.S
@@ -67,20 +67,6 @@ secondary_startup:
 *  jump to Linux
 *  kick secondaries   ---(sev)--->jump to Linux
 */
-   /*
-* ACTLR (Auxiliary Control Register) for Cortex-A9
-* bit[9]  Parity on
-* bit[8]  Alloc in one way
-* bit[7]  EXCL (Exclusive cache bit)
-* bit[6]  SMP
-* bit[3]  Write full line of zeros mode
-* bit[2]  L1 prefetch enable
-* bit[1]  L2 prefetch enable
-* bit[0]  FW (Cache and TLB maintenance broadcast)
-*/
-   mrc p15, 0, r0, c1, c0, 1   @ ACTLR (Auxiliary Control Register)
-   orr r0, r0, #0x41   @ enable SMP, FW bit
-   mcr p15, 0, r0, c1, c0, 1
 
/* branch by CPU ID */
mrc p15, 0, r0, c0, c0, 5   @ MPIDR (Multiprocessor Affinity 
Register)
@@ -112,12 +98,6 @@ primary_cpu:
str r0, [r1]
ldr r0, [r1]@ make sure str is complete before sev
sev @ kick the secondary CPU
-   mrc p15, 4, r1, c15, c0, 0  @ Configuration Base Address Register
-   bfc r1, #0, #13 @ clear bit 12-0
-   mov r0, #-1
-   str r0, [r1, #SCU_INV_ALL]  @ SCU Invalidate All Register
-   mov r0, #1  @ SCU enable
-   str r0, [r1, #SCU_CTRL] @ SCU Control Register
 #endif
 
bl  setup_init_ram  @ RAM area for temporary stack pointer
-- 
1.9.1

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

[U-Boot] [PATCH v2 3/7] ARM: UniPhier: remove meaningless CONFIG_SPL_BUILD ifdefs

This file is only built for SPL.
These ifdef conditionals are unnecessary because UniPhier platform
now supports UART on SPL.
Show appropriate messages on error.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 arch/arm/mach-uniphier/ddrphy_training.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-uniphier/ddrphy_training.c 
b/arch/arm/mach-uniphier/ddrphy_training.c
index b1d46cf..5f3d591 100644
--- a/arch/arm/mach-uniphier/ddrphy_training.c
+++ b/arch/arm/mach-uniphier/ddrphy_training.c
@@ -1,6 +1,7 @@
 /*
- * Copyright (C) 2011-2014 Panasonic Corporation
- *   Author: Masahiro Yamada 
+ * Copyright (C) 2011-2015 Panasonic Corporation
+ * Copyright (C) 2015  Socionext Inc.
+ *   Author: Masahiro Yamada 
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
@@ -116,10 +117,8 @@ int ddrphy_training(struct ddrphy __iomem *phy)
 
do {
if (--timeout < 0) {
-#ifndef CONFIG_SPL_BUILD
printf("%s: error: timeout during DDR training\n",
__func__);
-#endif
return -1;
}
udelay(1);
@@ -128,10 +127,8 @@ int ddrphy_training(struct ddrphy __iomem *phy)
 
for (i = 0; i < ARRAY_SIZE(init_sequence); i++) {
if (pgsr0 & init_sequence[i].err_flag) {
-#ifndef CONFIG_SPL_BUILD
printf("%s: error: %s failed\n", __func__,
init_sequence[i].description);
-#endif
return -1;
}
}
-- 
1.9.1

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

[U-Boot] [PATCH v2 1/7] ARM: UniPhier: use 32 bit register access for debug UART setting

For the same reason as commit d0c47b3ef7c5 (serial: UniPhier: use
32 bit register access), use "str" instead of "strb" for the LCR
register setting.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 arch/arm/mach-uniphier/include/mach/debug-uart.S | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-uniphier/include/mach/debug-uart.S 
b/arch/arm/mach-uniphier/include/mach/debug-uart.S
index af55fee..9ae2e18 100644
--- a/arch/arm/mach-uniphier/include/mach/debug-uart.S
+++ b/arch/arm/mach-uniphier/include/mach/debug-uart.S
@@ -1,6 +1,7 @@
 /*
- * Copyright (C) 2014 Panasonic Corporation
- *   Author: Masahiro Yamada 
+ * Copyright (C) 2014-2015 Panasonic Corporation
+ * Copyright (C) 2015  Socionext Inc.
+ *   Author: Masahiro Yamada 
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
@@ -17,8 +18,8 @@
 
.macro  init_debug_uart, ra, rb, rc
addruart\ra, \rb, \rc
-   mov \rb, #UART_LCR_WLEN8
-   strb\rb, [\ra, #0x11]
+   mov \rb, #UART_LCR_WLEN8 << 8
+   str \rb, [\ra, #0x10]
ldr \rb, =DIVISOR
str \rb, [\ra, #0x24]
.endm
-- 
1.9.1

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

[U-Boot] [PATCH v2 4/7] ARM: UniPhier: move CONFIG_SYS_TEXT_BASE to Kconfig

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Sort by savedefconfig

 Kconfig| 2 +-
 configs/ph1_ld4_defconfig  | 1 +
 configs/ph1_pro4_defconfig | 1 +
 configs/ph1_sld8_defconfig | 1 +
 include/configs/uniphier.h | 2 --
 5 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/Kconfig b/Kconfig
index 85faff7..15e15af 100644
--- a/Kconfig
+++ b/Kconfig
@@ -178,7 +178,7 @@ config SYS_EXTRA_OPTIONS
  new boards should not use this option.
 
 config SYS_TEXT_BASE
-   depends on SPARC || ARC || X86
+   depends on SPARC || ARC || X86 || ARCH_UNIPHIER
hex "Text Base"
help
  TODO: Move CONFIG_SYS_TEXT_BASE for all the architecture
diff --git a/configs/ph1_ld4_defconfig b/configs/ph1_ld4_defconfig
index 036e2d1..45d484e 100644
--- a/configs/ph1_ld4_defconfig
+++ b/configs/ph1_ld4_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_UNIPHIER=y
 CONFIG_SPL_DM=y
 CONFIG_MACH_PH1_LD4=y
 CONFIG_PFC_MICRO_SUPPORT_CARD=y
+CONFIG_SYS_TEXT_BASE=0x8400
 CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-ld4-ref"
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
diff --git a/configs/ph1_pro4_defconfig b/configs/ph1_pro4_defconfig
index 9a010ee..cc3a9a4 100644
--- a/configs/ph1_pro4_defconfig
+++ b/configs/ph1_pro4_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_UNIPHIER=y
 CONFIG_SPL_DM=y
 CONFIG_MACH_PH1_PRO4=y
 CONFIG_PFC_MICRO_SUPPORT_CARD=y
+CONFIG_SYS_TEXT_BASE=0x8400
 CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-pro4-ref"
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
diff --git a/configs/ph1_sld8_defconfig b/configs/ph1_sld8_defconfig
index 29fe0e8..fc79866 100644
--- a/configs/ph1_sld8_defconfig
+++ b/configs/ph1_sld8_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_UNIPHIER=y
 CONFIG_SPL_DM=y
 CONFIG_MACH_PH1_SLD8=y
 CONFIG_PFC_MICRO_SUPPORT_CARD=y
+CONFIG_SYS_TEXT_BASE=0x8400
 CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-sld8-ref"
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
index 331df62..dd64cdc 100644
--- a/include/configs/uniphier.h
+++ b/include/configs/uniphier.h
@@ -266,8 +266,6 @@
 #define CONFIG_SYS_SDRAM_SIZE  (CONFIG_SDRAM0_SIZE)
 #endif
 
-#define CONFIG_SYS_TEXT_BASE   0x8400
-
 #if defined(CONFIG_MACH_PH1_LD4) || defined(CONFIG_MACH_PH1_SLD8)
 #define CONFIG_SPL_TEXT_BASE   0x0004
 #endif
-- 
1.9.1

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

Re: [U-Boot] [PATCH v2 22/22] x86: Add support for Intel Minnowboard Max

Hi Simon,

On Wed, May 27, 2015 at 5:37 AM, Simon Glass  wrote:
> Hi Andrew,
>
> On 26 May 2015 at 13:52, Andrew Bradford  wrote:
>> Hi Simon and Bin (sorry for bringing this back from the dead),
>>
>> But I have a question about fsp_configs.c down below:
>>
>> On 01/27 22:13, Simon Glass wrote:
>> ->8---
>>> diff --git a/arch/x86/cpu/baytrail/fsp_configs.c 
>>> b/arch/x86/cpu/baytrail/fsp_configs.c
>>> new file mode 100644
>>> index 000..86b6926
>>> --- /dev/null
>>> +++ b/arch/x86/cpu/baytrail/fsp_configs.c
>>> @@ -0,0 +1,156 @@
>>> +/*
>>> + * Copyright (C) 2013, Intel Corporation
>>> + * Copyright (C) 2014, Bin Meng 
>>> + *
>>> + * SPDX-License-Identifier:  Intel
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +/* ALC262 Verb Table - 10EC0262 */
>>> +static const uint32_t verb_table_data13[] = {
>>> + /* Pin Complex (NID 0x11) */
>>> + 0x01171cf0,
>>> + 0x01171d11,
>>> + 0x01171e11,
>>> + 0x01171f41,
>>> + /* Pin Complex (NID 0x12) */
>>> + 0x01271cf0,
>>> + 0x01271d11,
>>> + 0x01271e11,
>>> + 0x01271f41,
>>> + /* Pin Complex (NID 0x14) */
>>> + 0x01471c10,
>>> + 0x01471d40,
>>> + 0x01471e01,
>>> + 0x01471f01,
>>> + /* Pin Complex (NID 0x15) */
>>> + 0x01571cf0,
>>> + 0x01571d11,
>>> + 0x01571e11,
>>> + 0x01571f41,
>>> + /* Pin Complex (NID 0x16) */
>>> + 0x01671cf0,
>>> + 0x01671d11,
>>> + 0x01671e11,
>>> + 0x01671f41,
>>> + /* Pin Complex (NID 0x18) */
>>> + 0x01871c20,
>>> + 0x01871d98,
>>> + 0x01871ea1,
>>> + 0x01871f01,
>>> + /* Pin Complex (NID 0x19) */
>>> + 0x01971c21,
>>> + 0x01971d98,
>>> + 0x01971ea1,
>>> + 0x01971f02,
>>> + /* Pin Complex (NID 0x1A) */
>>> + 0x01a71c2f,
>>> + 0x01a71d30,
>>> + 0x01a71e81,
>>> + 0x01a71f01,
>>> + /* Pin Complex */
>>> + 0x01b71c1f,
>>> + 0x01b71d40,
>>> + 0x01b71e21,
>>> + 0x01b71f02,
>>> + /* Pin Complex */
>>> + 0x01c71cf0,
>>> + 0x01c71d11,
>>> + 0x01c71e11,
>>> + 0x01c71f41,
>>> + /* Pin Complex */
>>> + 0x01d71c01,
>>> + 0x01d71dc6,
>>> + 0x01d71e14,
>>> + 0x01d71f40,
>>> + /* Pin Complex */
>>> + 0x01e71cf0,
>>> + 0x01e71d11,
>>> + 0x01e71e11,
>>> + 0x01e71f41,
>>> + /* Pin Complex */
>>> + 0x01f71cf0,
>>> + 0x01f71d11,
>>> + 0x01f71e11,
>>> + 0x01f71f41,
>>> +};
>>> +
>>> +/*
>>> + * This needs to be in ROM since if we put it in CAR, FSP init loses it 
>>> when
>>> + * it drops CAR.
>>> + *
>>> + * TODO(s...@chromium.org): Move to device tree when FSP allows it
>>> + *
>>> + * VerbTable: (RealTek ALC262)
>>> + * Revision ID = 0xFF, support all steps
>>> + * Codec Verb Table For AZALIA
>>> + * Codec Address: CAd value (0/1/2)
>>> + * Codec Vendor: 0x10EC0262
>>> + */
>>> +static const struct pch_azalia_verb_table azalia_verb_table[] = {
>>> + {
>>> + {
>>> + 0x10ec0262,
>>> + 0x,
>>> + 0xff,
>>> + 0x01,
>>> + 0x000b,
>>> + 0x0002,
>>> + },
>>> + verb_table_data13
>>> + }
>>> +};
>>> +
>>> +const struct pch_azalia_config azalia_config = {
>>> + .pme_enable = 1,
>>> + .docking_supported = 1,
>>> + .docking_attached = 0,
>>> + .hdmi_codec_enable = 1,
>>> + .azalia_v_ci_enable = 1,
>>> + .rsvdbits = 0,
>>> + .azalia_verb_table_num = 1,
>>> + .azalia_verb_table = azalia_verb_table,
>>> + .reset_wait_timer_us = 300
>>> +};
>>> +
>>> +void update_fsp_upd(struct upd_region *fsp_upd)
>>> +{
>>> + struct memory_down_data *mem;
>>> +
>>> + /*
>>> +  * Configure everything here to avoid the poor hard-pressed user
>>> +  * needing to run Intel's binary configuration tool. It may also allow
>>> +  * us to support the 1GB single core variant easily.
>>> +  *
>>> +  * TODO(s...@chromium.org): Move to device tree
>>> +  */
>>> + fsp_upd->mrc_init_tseg_size = 8;
>>> + fsp_upd->mrc_init_mmio_size = 0x800;
>>> + fsp_upd->emmc_boot_mode = 0xff;
>>> + fsp_upd->enable_sdio = 1;
>>> + fsp_upd->enable_sdcard = 1;
>>> + fsp_upd->enable_hsuart0 = 1;
>>> + fsp_upd->azalia_config_ptr = (uint32_t)&azalia_config;
>>> + fsp_upd->enable_i2_c0 = 0;
>>> + fsp_upd->enable_i2_c2 = 0;
>>> + fsp_upd->enable_i2_c3 = 0;
>>> + fsp_upd->enable_i2_c4 = 0;
>>> + fsp_upd->enable_xhci = 0;
>>> + fsp_upd->igd_render_standby = 1;
>>> +
>>> + mem = &fsp_upd->memory_params;
>>> + mem->enable_memory_down = 1;
>>> + mem->dram_speed = 1;
>>> + mem->dimm_width = 1;
>>> + mem->dimm_density = 2;
>>> + mem->dimm_tcl = 0xb;
>>> + mem->dimm_trpt_rcd = 0xb;
>>> + mem->dimm_twr = 0xc;
>>> + mem->dimm_twtr = 6;
>>> + mem->dimm_trrd = 6;
>>> + mem->dimm_trtp = 6;
>>> + mem->dimm_t

Re: [U-Boot] [PATCH 05/20] armv8/ls2085a: call ft_pcie_setup() to change dts status

2015-05-26 Thread Kushwaha Prabhakar


> -Original Message-
> From: Lian Minghuan-B31939
> Sent: Wednesday, May 27, 2015 9:11 AM
> To: Sun York-R58495; Kushwaha Prabhakar-B32579; u-boot@lists.denx.de
> Subject: RE: [PATCH 05/20] armv8/ls2085a: call ft_pcie_setup() to change dts
> status
> 
> Hi York,
> 
> 1. board/freescale/ls2085a/ls2085a.c is for board ls2085a_emu like
> ls2085aqds.c not SoC file.
> But I am not sure whether  emulator board should call this function.
> 2. ft_pcie_setup(blob, bd) should be changed to ft_pci_setup(blob, bd)
> ft_pci_setup is the common function name defined in common.h



> 
> Thanks,
> Minghuan
> 
> > -Original Message-
> > From: Sun York-R58495
> > Sent: Tuesday, May 26, 2015 11:54 PM
> > To: Kushwaha Prabhakar-B32579; u-boot@lists.denx.de
> > Cc: Lian Minghuan-B31939
> > Subject: Re: [PATCH 05/20] armv8/ls2085a: call ft_pcie_setup() to
> > change dts status
> >
> > Prabhakar and Minghuan,
> >
> > On 05/18/2015 12:08 AM, Prabhakar Kushwaha wrote:
> > > From: Minghuan Lian 
> > >
> > >  1. The patch call ft_pcie_setup() to disable PCIe dts node if
> > > corresponding PCIe controller is disabled according to RCW.
> > >  2. Fix LS2085a PCIe compatible
> > >
> > > Signed-off-by: Minghuan Lian 
> > > Signed-off-by: Prabhakar Kushwaha 
> > > ---
> > >  board/freescale/ls2085a/ls2085a.c   | 4 
> > >  board/freescale/ls2085aqds/ls2085aqds.c | 4 
> > > board/freescale/ls2085ardb/ls2085ardb.c | 4 
> > >  include/configs/ls2085a_common.h| 3 ++-
> > >  4 files changed, 14 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/board/freescale/ls2085a/ls2085a.c
> > > b/board/freescale/ls2085a/ls2085a.c
> > > index dd0acf2..afb99d1 100644
> > > --- a/board/freescale/ls2085a/ls2085a.c
> > > +++ b/board/freescale/ls2085a/ls2085a.c
> > > @@ -142,6 +142,10 @@ int ft_board_setup(void *blob, bd_t *bd)
> > >   fsl_mc_ldpaa_exit(bd);
> > >  #endif
> > >
> > > +#ifdef CONFIG_PCI
> > > + ft_pcie_setup(blob, bd);
> > > +#endif
> > > +
> >
> > Shouldn't this function be called from SoC function? It is not a
> > board- dependent setup, but rather depending on RCW which is an SoC
> feature.
> >

There are 2 function and their relationship is like this
ft_pci_setup calling ft_pcie_ls_setup.

ft_pcie_ls_setup  is doing thing related to SoC.   
So I believe ft_pci_setup can be called from board file.  Not sure

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

Re: [U-Boot] [PATCH] x86: baytrail: PCI is not always mapped to end of ram

Hi Andrew,

On Tue, May 26, 2015 at 8:17 PM, Andrew Bradford
 wrote:
> Hi Bin,
>
> On 05/23 23:50, Bin Meng wrote:
>> +Simon.
>>
>> Hi Andrew,
>>
>> On Sat, May 23, 2015 at 3:09 AM,   wrote:
>> > From: Andrew Bradford 
>> >
>> > PCI on Intel Baytrail is mapped to 0x8000, which is not always at
>> > the end of SDRAM, such as when running with 4 GiB of SDRAM.  The PCI bus
>> > memory mapping must stay within low memory and so when running with >
>> > 2 GiB of SDRAM, there is a hole in the SDRAM between 2 GiB and 4 GiB for
>> > memory mapped IO, such as PCI.
>>
>> Are you saying that if we mount 4GB DDR DIMM on the MinnowMax board,
>> the Intel FSP will only put 0~2G as system RAM space, and leave 2G~4G
>> as PCI address and other I/Os?
>
> Yes.  If you mount 4 GiB of SDRAM onto an E3800 processor, then physical
> addresses from 0 to just below 2 GiB will be SDRAM (as per the HOBs) and
> also from 4 GiB to 6 GiB (also verified via the HOBs).  The space from 2
> GiB to 4 GiB will be mapped as various other regions.

Ah, that's exactly the information I want :)

> If you see section 4.1.1.1 (page 71 in the January 2015, Revision 3.6)
> E3800 datasheet, it shows that from 2 GiB to 4 GiB is mapped for PCI,
> Abort Page, Local APIC, and the Boot Vector.  There's a lot of space in
> this area which appears unused, so I'm unsure as to why the area is so
> large.
>
> I have an Intel Valley Island board with E3825 and a 4 GiB SODIMM.  I'm
> working on getting patches ready for this board but found that if I
> enabled all 4 GiB of SDRAM that the PCI bus would not function
> correctly.  With this patch then the PCI bus functions (I'm able to do
> network operations with the RTL8111 Ethernet adapter).
>
>> I see from minnowmax.h, the PCI address starts from 0xd000.
>>
>> #define CONFIG_PCI_MEM_BUS  0xd000
>> #define CONFIG_PCI_MEM_PHYS CONFIG_PCI_MEM_BUS
>> #define CONFIG_PCI_MEM_SIZE 0x1000
>>
>> #define CONFIG_PCI_PREF_BUS 0xc000
>> #define CONFIG_PCI_PREF_PHYSCONFIG_PCI_PREF_BUS
>> #define CONFIG_PCI_PREF_SIZE0x1000
>
> I see that hose->regions+0 is set to CONFIG_PCI_MEM_BUS and
> hose->regions+2 is set to CONFIG_PCI_PREF_BUS.  However I'm modifying
> hose->regions+3.  So the values from minnowmax.h *are* being used.  I'm
> not yet that familiar with PCI configuration, so likely I'm not fully
> understanding how u-boot sets this up.
>

The regions+3 is used by the inbound access, eg: PCI device access to
system memory.

> Possibly my address of 0x8000 is not correct, even though it works
> for me.  But 0x8000 is where it was being placed before, since it
> was going at the end of SDRAM (2GiB on minnowmax).
>

You understanding is correct. We should only open 2GiB inbound memory
window for PCI devices.

> If I artificially limit the amount of SDRAM by setting the fsp
> configuration to memory-down and then setting the DRAM configuration
> values such that I mimmic 1 GiB or 2 GiB of SDRAM, having my patch still
> provides access to the PCI bus, so with my patch there should be no
> adverse affects on E3800 systems that have less than 4 GiB of SDRAM.
> But without my patch, when running with >=4 GiB of SDRAM, PCI accesses
> end up returning "pci_hose_bus_to_phys: invalid physical address"
> errors.
>

Yes, this all makes sense, so

Reviewed-by: Bin Meng 

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

[U-Boot] [PATCH 5/5] warp: Fix the 'saveenv' command

From: Fabio Estevam 

After the mx6 config consolidation, 'save' command is no longer
recognized.

Pass the full command name 'saveenv' instead.

Signed-off-by: Fabio Estevam 
---
 board/warp/README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/warp/README b/board/warp/README
index db3100e..22f9055 100644
--- a/board/warp/README
+++ b/board/warp/README
@@ -34,7 +34,7 @@ Then U-boot should start and its messages will appear in the 
console program.
 Use the default environment variables:
 
 => env default -f -a
-=> save
+=> saveenv
 
 Run the DFU command:
 => dfu 0 mmc 0
-- 
1.9.1

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

[U-Boot] [PATCH 4/5] warp: Add fuse command support

From: Fabio Estevam 

Select the fuse command support.

Signed-off-by: Fabio Estevam 
---
 include/configs/warp.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/configs/warp.h b/include/configs/warp.h
index 5463c40..296ea83 100644
--- a/include/configs/warp.h
+++ b/include/configs/warp.h
@@ -98,6 +98,10 @@
 #define CONFIG_SYS_DFU_DATA_BUF_SIZE SZ_16M
 #define DFU_DEFAULT_POLL_TIMEOUT 300
 
+/* Fuses */
+#define CONFIG_CMD_FUSE
+#define CONFIG_MXC_OCOTP
+
 #define CONFIG_EXTRA_ENV_SETTINGS \
"script=boot.scr\0" \
"image=zImage\0" \
-- 
1.9.1

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

[U-Boot] [PATCH 2/5] warp: Fix CONFIG_SYS_FSL_ESDHC_ADDR

From: Fabio Estevam 

Warp uses eMMC connected to esdhc2 port, so fix 
CONFIG_SYS_FSL_ESDHC_ADDR to reflect that.

Signed-off-by: Fabio Estevam 
---
 include/configs/warp.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/warp.h b/include/configs/warp.h
index f0a912b..a67254e 100644
--- a/include/configs/warp.h
+++ b/include/configs/warp.h
@@ -25,7 +25,7 @@
 #define CONFIG_MXC_UART_BASE   UART1_IPS_BASE_ADDR
 
 /* MMC Configs */
-#define CONFIG_SYS_FSL_ESDHC_ADDR  0
+#define CONFIG_SYS_FSL_ESDHC_ADDR  USDHC2_BASE_ADDR
 #define CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT
 #define CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE
 
-- 
1.9.1

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

[U-Boot] [PATCH 3/5] warp: Enable CONFIG_SUPPORT_EMMC_BOOT

From: Fabio Estevam 

CONFIG_SUPPORT_EMMC_BOOT is important to enable the boot partition via
'mmc partconf 0 1 1 0' command, for example.

Signed-off-by: Fabio Estevam 
---
 include/configs/warp.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/warp.h b/include/configs/warp.h
index a67254e..5463c40 100644
--- a/include/configs/warp.h
+++ b/include/configs/warp.h
@@ -28,6 +28,7 @@
 #define CONFIG_SYS_FSL_ESDHC_ADDR  USDHC2_BASE_ADDR
 #define CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT
 #define CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE
+#define CONFIG_SUPPORT_EMMC_BOOT
 
 /* Command definition */
 #undef CONFIG_CMD_NET
-- 
1.9.1

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

[U-Boot] [PATCH 1/5] warp: Adjust CONFIG_SYS_DFU_DATA_BUF_SIZE

From: Fabio Estevam 

Adjust CONFIG_SYS_DFU_DATA_BUF_SIZE in order to avoid the following error
when running the dfu command:
=> dfu 0 mmc 0  
dfu_get_buf: Could not memalign 0x200 bytes

Signed-off-by: Fabio Estevam 
---
 include/configs/warp.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/warp.h b/include/configs/warp.h
index 2673948..f0a912b 100644
--- a/include/configs/warp.h
+++ b/include/configs/warp.h
@@ -94,7 +94,7 @@
 #define CONFIG_CMD_DFU
 #define CONFIG_DFU_FUNCTION
 #define CONFIG_DFU_MMC
-#define CONFIG_SYS_DFU_DATA_BUF_SIZE SZ_32M
+#define CONFIG_SYS_DFU_DATA_BUF_SIZE SZ_16M
 #define DFU_DEFAULT_POLL_TIMEOUT 300
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
-- 
1.9.1

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

Re: [U-Boot] [PATCH 5/6] x86: qemu: Create i440fx and q35 board configuration and device tree

Hi Simon,

On Wed, May 27, 2015 at 11:59 AM, Simon Glass  wrote:
> Hi Bin,
>
> On 26 May 2015 at 21:55, Bin Meng  wrote:
>> Hi Simon,
>>
>> On Wed, May 27, 2015 at 11:13 AM, Simon Glass  wrote:
>>> Hi Bin,
>>>
>>> On 25 May 2015 at 08:36, Bin Meng  wrote:
 Although the two qemu-x86 targets (i440fx and q35) share a lot in
 common, they still have something that cannot easily handled in one
 place (like different configurations, different properties in the
 device tree). Split to create two dedicated board configuration and
 device tree files and make the i440fx be the default build target.

 Signed-off-by: Bin Meng 
 ---

  arch/x86/dts/Makefile |  3 +-
  arch/x86/dts/qemu-x86_i440fx.dts  | 34 +++
  arch/x86/dts/{qemu-x86.dts => qemu-x86_q35.dts}   |  2 +-
  board/coreboot/coreboot/Kconfig   |  4 +-
  board/emulation/qemu-x86/Kconfig  | 19 +++--
  configs/qemu-x86_defconfig|  1 -
  doc/README.x86| 13 +-
  include/configs/{qemu-x86.h => qemu-x86_i440fx.h} | 20 ++---
  include/configs/qemu-x86_q35.h| 52 
 +++
  9 files changed, 122 insertions(+), 26 deletions(-)
  create mode 100644 arch/x86/dts/qemu-x86_i440fx.dts
  rename arch/x86/dts/{qemu-x86.dts => qemu-x86_q35.dts} (95%)
  rename include/configs/{qemu-x86.h => qemu-x86_i440fx.h} (78%)
  create mode 100644 include/configs/qemu-x86_q35.h
>>>
>>> Do we need a separate config file? It would be good if all the changes
>>> were in the device tree so that we don't need a separate config. Or at
>>> least that the configs are the same except for the device tree.
>>>
>>
>> So far the only difference between two separate config files are the
>> ATA/SATA settings. i440fx has legacy IDE support while q35 has the
>> AHCI support. We can enable them both in just one config files,
>> however turning on legacy IDE support on q35 causes significant boot
>> delay as the legacy IDE driver has some big timeout in probing the
>> attached devices. Do you think this is something we are tolerant of?
>> If yes, I can just do separate device trees.
>
> I think it is OK. But another option would be to add an IDE node to
> the device tree and check it when CONFIG_OF_CONTROL is defined...
>

I feel that we need convert all block drivers to driver model, so that
the driver can probe and initialize IDE/AHCI based on device tree
node. But I guess that's a long term goal?

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

Re: [U-Boot] [PATCH v2 3/3] x86: qemu: Add graphics support

Hi Simon,

On Wed, May 27, 2015 at 11:58 AM, Simon Glass  wrote:
> Hi Bin,
>
> On 11 May 2015 at 10:43, Simon Glass  wrote:
>> On 10 May 2015 at 21:13, Simon Glass  wrote:
>>> On 10 May 2015 at 17:36, Bin Meng  wrote:
 It turns out that QEMU x86 emulated graphic card has a built-in
 option ROM which can be run perfectly with native mode by U-Boot.

 Signed-off-by: Bin Meng 

 ---

 Changes in v2:
 - Drop the patch that tries to clean up the CONFIG_VGA_AS_SINGLE_DEVICE 
 wraps
 - Update README.x86 to mention QEMU version

  arch/x86/cpu/qemu/pci.c| 24 +++-
  configs/qemu-x86_defconfig |  3 +++
  doc/README.x86 |  7 ++-
  include/configs/qemu-x86.h | 10 +++---
  4 files changed, 35 insertions(+), 9 deletions(-)
>>>
>>> Acked-by: Simon Glass 
>>
>> Applied to u-boot-x86, thanks!
>
> I'm see this failure with coreboot-x86. I can't really explain it
> since all seemed well when I applied these patches. Can you please
> take a look? The branch is at u-boot-x86/testing.
>
> +drivers/built-in.o: In function `video_init':
> +build/../drivers/video/cfb_console.c:2139: undefined reference to
> `video_hw_init'
> +make[1]: *** [u-boot] Error 1
>

Yes, I will have a look.

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

Re: [U-Boot] [PATCH v2 3/6] x86: Make QEMU the default vendor

Hi Simon,

On Wed, May 27, 2015 at 11:57 AM, Simon Glass  wrote:
> Hi Bin,
>
> On 8 May 2015 at 14:42, Simon Glass  wrote:
>> On 7 May 2015 at 07:34, Bin Meng  wrote:
>>> Now that we have QEMU support, make it the default vendor in the
>>> 'make menuconfig' screen.
>>>
>>> Signed-off-by: Bin Meng 
>>> Acked-by: Simon Glass 
>>> Tested-by: Simon Glass 
>>> ---
>>>
>>> Changes in v2: None
>>>
>>>  arch/x86/Kconfig | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Applied to u-boot-x86, thanks!
>
> For some reason I am seeing a failure here:
>
> 04: x86: Make QEMU the default vendor
>x86:  +   coreboot-x86
> +
> +Device Tree Source is not correctly specified.
> +Please define 'CONFIG_DEFAULT_DEVICE_TREE'
> +or build with 'DEVICE_TREE=' argument
> +make[2]: *** [arch/x86/dts/unset.dtb] Error 1
> +make[1]: *** [dts/dt.dtb] Error 2
> +make: *** [sub-make] Error 2
>

That's weird. I didn't see such error when building the patchset with buildman.

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

Re: [U-Boot] [PATCH 5/6] x86: qemu: Create i440fx and q35 board configuration and device tree

Hi Bin,

On 26 May 2015 at 21:55, Bin Meng  wrote:
> Hi Simon,
>
> On Wed, May 27, 2015 at 11:13 AM, Simon Glass  wrote:
>> Hi Bin,
>>
>> On 25 May 2015 at 08:36, Bin Meng  wrote:
>>> Although the two qemu-x86 targets (i440fx and q35) share a lot in
>>> common, they still have something that cannot easily handled in one
>>> place (like different configurations, different properties in the
>>> device tree). Split to create two dedicated board configuration and
>>> device tree files and make the i440fx be the default build target.
>>>
>>> Signed-off-by: Bin Meng 
>>> ---
>>>
>>>  arch/x86/dts/Makefile |  3 +-
>>>  arch/x86/dts/qemu-x86_i440fx.dts  | 34 +++
>>>  arch/x86/dts/{qemu-x86.dts => qemu-x86_q35.dts}   |  2 +-
>>>  board/coreboot/coreboot/Kconfig   |  4 +-
>>>  board/emulation/qemu-x86/Kconfig  | 19 +++--
>>>  configs/qemu-x86_defconfig|  1 -
>>>  doc/README.x86| 13 +-
>>>  include/configs/{qemu-x86.h => qemu-x86_i440fx.h} | 20 ++---
>>>  include/configs/qemu-x86_q35.h| 52 
>>> +++
>>>  9 files changed, 122 insertions(+), 26 deletions(-)
>>>  create mode 100644 arch/x86/dts/qemu-x86_i440fx.dts
>>>  rename arch/x86/dts/{qemu-x86.dts => qemu-x86_q35.dts} (95%)
>>>  rename include/configs/{qemu-x86.h => qemu-x86_i440fx.h} (78%)
>>>  create mode 100644 include/configs/qemu-x86_q35.h
>>
>> Do we need a separate config file? It would be good if all the changes
>> were in the device tree so that we don't need a separate config. Or at
>> least that the configs are the same except for the device tree.
>>
>
> So far the only difference between two separate config files are the
> ATA/SATA settings. i440fx has legacy IDE support while q35 has the
> AHCI support. We can enable them both in just one config files,
> however turning on legacy IDE support on q35 causes significant boot
> delay as the legacy IDE driver has some big timeout in probing the
> attached devices. Do you think this is something we are tolerant of?
> If yes, I can just do separate device trees.

I think it is OK. But another option would be to add an IDE node to
the device tree and check it when CONFIG_OF_CONTROL is defined...

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

Re: [U-Boot] [PATCH v2 3/3] x86: qemu: Add graphics support

Hi Bin,

On 11 May 2015 at 10:43, Simon Glass  wrote:
> On 10 May 2015 at 21:13, Simon Glass  wrote:
>> On 10 May 2015 at 17:36, Bin Meng  wrote:
>>> It turns out that QEMU x86 emulated graphic card has a built-in
>>> option ROM which can be run perfectly with native mode by U-Boot.
>>>
>>> Signed-off-by: Bin Meng 
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - Drop the patch that tries to clean up the CONFIG_VGA_AS_SINGLE_DEVICE 
>>> wraps
>>> - Update README.x86 to mention QEMU version
>>>
>>>  arch/x86/cpu/qemu/pci.c| 24 +++-
>>>  configs/qemu-x86_defconfig |  3 +++
>>>  doc/README.x86 |  7 ++-
>>>  include/configs/qemu-x86.h | 10 +++---
>>>  4 files changed, 35 insertions(+), 9 deletions(-)
>>
>> Acked-by: Simon Glass 
>
> Applied to u-boot-x86, thanks!

I'm see this failure with coreboot-x86. I can't really explain it
since all seemed well when I applied these patches. Can you please
take a look? The branch is at u-boot-x86/testing.

+drivers/built-in.o: In function `video_init':
+build/../drivers/video/cfb_console.c:2139: undefined reference to
`video_hw_init'
+make[1]: *** [u-boot] Error 1

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

Re: [U-Boot] [PATCH v2 3/6] x86: Make QEMU the default vendor

Hi Bin,

On 8 May 2015 at 14:42, Simon Glass  wrote:
> On 7 May 2015 at 07:34, Bin Meng  wrote:
>> Now that we have QEMU support, make it the default vendor in the
>> 'make menuconfig' screen.
>>
>> Signed-off-by: Bin Meng 
>> Acked-by: Simon Glass 
>> Tested-by: Simon Glass 
>> ---
>>
>> Changes in v2: None
>>
>>  arch/x86/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Applied to u-boot-x86, thanks!

For some reason I am seeing a failure here:

04: x86: Make QEMU the default vendor
   x86:  +   coreboot-x86
+
+Device Tree Source is not correctly specified.
+Please define 'CONFIG_DEFAULT_DEVICE_TREE'
+or build with 'DEVICE_TREE=' argument
+make[2]: *** [arch/x86/dts/unset.dtb] Error 1
+make[1]: *** [dts/dt.dtb] Error 2
+make: *** [sub-make] Error 2

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

Re: [U-Boot] [PATCH 5/6] x86: qemu: Create i440fx and q35 board configuration and device tree

Hi Simon,

On Wed, May 27, 2015 at 11:13 AM, Simon Glass  wrote:
> Hi Bin,
>
> On 25 May 2015 at 08:36, Bin Meng  wrote:
>> Although the two qemu-x86 targets (i440fx and q35) share a lot in
>> common, they still have something that cannot easily handled in one
>> place (like different configurations, different properties in the
>> device tree). Split to create two dedicated board configuration and
>> device tree files and make the i440fx be the default build target.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  arch/x86/dts/Makefile |  3 +-
>>  arch/x86/dts/qemu-x86_i440fx.dts  | 34 +++
>>  arch/x86/dts/{qemu-x86.dts => qemu-x86_q35.dts}   |  2 +-
>>  board/coreboot/coreboot/Kconfig   |  4 +-
>>  board/emulation/qemu-x86/Kconfig  | 19 +++--
>>  configs/qemu-x86_defconfig|  1 -
>>  doc/README.x86| 13 +-
>>  include/configs/{qemu-x86.h => qemu-x86_i440fx.h} | 20 ++---
>>  include/configs/qemu-x86_q35.h| 52 
>> +++
>>  9 files changed, 122 insertions(+), 26 deletions(-)
>>  create mode 100644 arch/x86/dts/qemu-x86_i440fx.dts
>>  rename arch/x86/dts/{qemu-x86.dts => qemu-x86_q35.dts} (95%)
>>  rename include/configs/{qemu-x86.h => qemu-x86_i440fx.h} (78%)
>>  create mode 100644 include/configs/qemu-x86_q35.h
>
> Do we need a separate config file? It would be good if all the changes
> were in the device tree so that we don't need a separate config. Or at
> least that the configs are the same except for the device tree.
>

So far the only difference between two separate config files are the
ATA/SATA settings. i440fx has legacy IDE support while q35 has the
AHCI support. We can enable them both in just one config files,
however turning on legacy IDE support on q35 causes significant boot
delay as the legacy IDE driver has some big timeout in probing the
attached devices. Do you think this is something we are tolerant of?
If yes, I can just do separate device trees.

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

Re: [U-Boot] [PATCH 3/6] x86: coreboot: Don't write I/O port 0xb2 for QEMU targets

Hi Simon,

On Wed, May 27, 2015 at 11:13 AM, Simon Glass  wrote:
> Hi Bin,
>
> On 25 May 2015 at 08:36, Bin Meng  wrote:
>> Writing 0xcb to I/O port 0xb2 (Advanced Power Management Control) causes
>> U-Boot to hang on QEMU q35 target. Disable the writing for QEMU targets.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  arch/x86/cpu/coreboot/coreboot.c | 4 
>>  1 file changed, 4 deletions(-)
>>
>> diff --git a/arch/x86/cpu/coreboot/coreboot.c 
>> b/arch/x86/cpu/coreboot/coreboot.c
>> index 4cdd0d4..2234cf0 100644
>> --- a/arch/x86/cpu/coreboot/coreboot.c
>> +++ b/arch/x86/cpu/coreboot/coreboot.c
>> @@ -85,10 +85,6 @@ void board_final_cleanup(void)
>> wrmsrl(MTRR_PHYS_MASK_MSR(top_mtrr), 0);
>> mtrr_close(&state);
>> }
>> -
>> -   /* Issue SMI to Coreboot to lock down ME and registers */
>> -   printf("Finalizing Coreboot\n");
>> -   outb(0xcb, 0xb2);
>>  }
>>
>>  void panic_puts(const char *str)
>> --
>> 1.8.2.1
>>
>
> But how does this run with coreboot on platforms that need it? Should
> this be controlled by a device tree settings, perhaps?
>

I am not sure if the lock down should be done by the coreboot in the
first place. IMHO U-Boot as the coreboot payload should not touch such
low-level stuff.

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

Re: [U-Boot] [PATCH 5/6] x86: qemu: Create i440fx and q35 board configuration and device tree

Hi Bin,

On 25 May 2015 at 08:36, Bin Meng  wrote:
> Although the two qemu-x86 targets (i440fx and q35) share a lot in
> common, they still have something that cannot easily handled in one
> place (like different configurations, different properties in the
> device tree). Split to create two dedicated board configuration and
> device tree files and make the i440fx be the default build target.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/dts/Makefile |  3 +-
>  arch/x86/dts/qemu-x86_i440fx.dts  | 34 +++
>  arch/x86/dts/{qemu-x86.dts => qemu-x86_q35.dts}   |  2 +-
>  board/coreboot/coreboot/Kconfig   |  4 +-
>  board/emulation/qemu-x86/Kconfig  | 19 +++--
>  configs/qemu-x86_defconfig|  1 -
>  doc/README.x86| 13 +-
>  include/configs/{qemu-x86.h => qemu-x86_i440fx.h} | 20 ++---
>  include/configs/qemu-x86_q35.h| 52 
> +++
>  9 files changed, 122 insertions(+), 26 deletions(-)
>  create mode 100644 arch/x86/dts/qemu-x86_i440fx.dts
>  rename arch/x86/dts/{qemu-x86.dts => qemu-x86_q35.dts} (95%)
>  rename include/configs/{qemu-x86.h => qemu-x86_i440fx.h} (78%)
>  create mode 100644 include/configs/qemu-x86_q35.h

Do we need a separate config file? It would be good if all the changes
were in the device tree so that we don't need a separate config. Or at
least that the configs are the same except for the device tree.

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

Re: [U-Boot] [PATCH 6/6] x86: qemu: Implement PIRQ routing

On 25 May 2015 at 08:36, Bin Meng  wrote:
> Support QEMU PIRQ routing via device tree on both i440fx and q35
> platforms. With this commit, Linux booting on QEMU from U-Boot
> has working ATA/SATA, USB and ethernet.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/cpu/coreboot/coreboot.c  |  5 +
>  arch/x86/cpu/qemu/qemu.c  |  8 
>  arch/x86/dts/qemu-x86_i440fx.dts  | 16 
>  arch/x86/dts/qemu-x86_q35.dts | 32 
>  configs/qemu-x86_defconfig|  1 +
>  include/configs/qemu-x86_i440fx.h |  1 +
>  include/configs/qemu-x86_q35.h|  1 +
>  7 files changed, 64 insertions(+)

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

Re: [U-Boot] [PATCH 4/6] x86: coreboot: Fix cosmetic issues

On 25 May 2015 at 08:36, Bin Meng  wrote:
> Clean up arch/x86/cpu/coreboot.c to fix several cosmetic issues.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/cpu/coreboot/coreboot.c  | 26 ++
>  arch/x86/include/asm/u-boot-x86.h |  1 -
>  2 files changed, 2 insertions(+), 25 deletions(-)

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

Re: [U-Boot] [PATCH 2/6] x86: qemu: Adjust VGA initialization

On 25 May 2015 at 08:36, Bin Meng  wrote:
> As VGA option rom needs to run at C segment, although QEMU PAM emulation
> seems to only guard E/F segments, for correctness, move VGA initialization
> after PAM decode C/D/E/F segments.
>
> Also since we already tested QEMU targets to differentiate I440FX and Q35
> platforms, change to locate the VGA device via hardcoded b.d.f instead of
> dynamic search for its vendor id & device id pair.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/cpu/qemu/pci.c | 34 
> +++--
>  arch/x86/include/asm/arch-qemu/device.h |  2 ++
>  2 files changed, 17 insertions(+), 19 deletions(-)

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

Re: [U-Boot] [PATCH 1/6] x86: qemu: Enable legacy IDE I/O ports decode

On 25 May 2015 at 08:36, Bin Meng  wrote:
> QEMU always decode legacy IDE I/O ports on PIIX chipset. However Linux 
> ata_piix
> driver does sanity check to see whether legacy ports decode is turned on.
> To make Linux ata_piix driver happy, turn on the decode via IDE_TIMING 
> register.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/cpu/qemu/pci.c | 14 ++
>  arch/x86/include/asm/arch-qemu/device.h | 19 +++
>  arch/x86/include/asm/arch-qemu/qemu.h   |  5 +
>  3 files changed, 38 insertions(+)
>  create mode 100644 arch/x86/include/asm/arch-qemu/device.h

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

Re: [U-Boot] [PATCH 3/6] x86: coreboot: Don't write I/O port 0xb2 for QEMU targets

Hi Bin,

On 25 May 2015 at 08:36, Bin Meng  wrote:
> Writing 0xcb to I/O port 0xb2 (Advanced Power Management Control) causes
> U-Boot to hang on QEMU q35 target. Disable the writing for QEMU targets.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/cpu/coreboot/coreboot.c | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/arch/x86/cpu/coreboot/coreboot.c 
> b/arch/x86/cpu/coreboot/coreboot.c
> index 4cdd0d4..2234cf0 100644
> --- a/arch/x86/cpu/coreboot/coreboot.c
> +++ b/arch/x86/cpu/coreboot/coreboot.c
> @@ -85,10 +85,6 @@ void board_final_cleanup(void)
> wrmsrl(MTRR_PHYS_MASK_MSR(top_mtrr), 0);
> mtrr_close(&state);
> }
> -
> -   /* Issue SMI to Coreboot to lock down ME and registers */
> -   printf("Finalizing Coreboot\n");
> -   outb(0xcb, 0xb2);
>  }
>
>  void panic_puts(const char *str)
> --
> 1.8.2.1
>

But how does this run with coreboot on platforms that need it? Should
this be controlled by a device tree settings, perhaps?

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

[U-Boot] [PATCH] kconfiglib: sync with the latest in Kconfiglib project

This commit imports some updates of kconfiglib.py from
https://github.com/ulfalizer/Kconfiglib

 - Warn about and ignore the "allnoconfig_y" Kconfig option
 - Statements in choices inherit menu/if deps
 - Add Symbol.is_allnoconfig_y()
 - Hint that modules are still supported despite warnings.
 - Add warning related to get_defconfig_filename().
 - Fix typo in docs.
 - Allow digits in $-references to symbols.

Signed-off-by: Ulf Magnusson 
Signed-off-by: Philip Craig 
Signed-off-by: Jakub Sitnicki 
Signed-off-by: Masahiro Yamada 
---

 tools/buildman/kconfiglib.py | 42 +++---
 1 file changed, 35 insertions(+), 7 deletions(-)

diff --git a/tools/buildman/kconfiglib.py b/tools/buildman/kconfiglib.py
index 655cf44..c662b64 100644
--- a/tools/buildman/kconfiglib.py
+++ b/tools/buildman/kconfiglib.py
@@ -429,7 +429,15 @@ class Config():
 If the environment variable 'srctree' was set when the Config was
 created, get_defconfig_filename() will first look relative to that
 directory before looking in the current directory; see
-Config.__init__()."""
+Config.__init__().
+
+WARNING: A wart here is that scripts/kconfig/Makefile sometimes uses 
the
+--defconfig= option when calling the C implementation of 
e.g.
+'make defconfig'. This option overrides the 'option defconfig_list'
+symbol, meaning the result from get_defconfig_filename() might not
+match what 'make defconfig' would use. That probably ought to be worked
+around somehow, so that this function always gives the "expected"
+result."""
 
 if self.defconfig_sym is None:
 return None
@@ -506,7 +514,7 @@ class Config():
 For example, if FOO and BAR are tristate symbols at least one of which
 has the value "y", then config.eval("y && (FOO || BAR)") => "y"
 
-This functions always yields a tristate value. To get the value of
+This function always yields a tristate value. To get the value of
 non-bool, non-tristate symbols, use Symbol.get_value().
 
 The result of this function is consistent with how evaluation works for
@@ -1066,7 +1074,7 @@ class Config():
 choice.block = self._parse_block(line_feeder,
  T_ENDCHOICE,
  choice,
- None,
+ deps,
  visible_if_deps)
 
 choice._determine_actual_symbols()
@@ -1326,10 +1334,21 @@ error, and you should e-mail kconfig...@gmail.com.
 elif tokens.check(T_MODULES):
 self._warn("the 'modules' option is not supported. "
"Let me know if this is a problem for you; "
-   "it shouldn't be that hard to implement.",
+   "it shouldn't be that hard to implement. "
+   "(Note that modules are still supported -- "
+   "Kconfiglib just assumes the symbol name "
+   "MODULES.)",
filename,
linenr)
 
+elif tokens.check(T_ALLNOCONFIG_Y):
+if not isinstance(stmt, Symbol):
+_parse_error(line,
+ "the 'allnoconfig_y' option is only valid 
for symbols.",
+ filename,
+ linenr)
+stmt.allnoconfig_y = True
+
 else:
 _parse_error(line, "unrecognized option.", filename, 
linenr)
 
@@ -2023,8 +2042,8 @@ def _make_and(e1, e2):
  T_OPTIONAL, T_PROMPT, T_DEFAULT,
  T_BOOL, T_TRISTATE, T_HEX, T_INT, T_STRING,
  T_DEF_BOOL, T_DEF_TRISTATE,
- T_SELECT, T_RANGE, T_OPTION, T_ENV,
- T_DEFCONFIG_LIST, T_MODULES, T_VISIBLE) = range(0, 38)
+ T_SELECT, T_RANGE, T_OPTION, T_ALLNOCONFIG_Y, T_ENV,
+ T_DEFCONFIG_LIST, T_MODULES, T_VISIBLE) = range(0, 39)
 
 # Keyword to token map
 keywords = {
@@ -2056,6 +2075,7 @@ keywords = {
 "select" : T_SELECT,
 "range"  : T_RANGE,
 "option" : T_OPTION,
+"allnoconfig_y"  : T_ALLNOCONFIG_Y,
 "env": T_ENV,
 "defconfig_list" : T_DEFCONFIG_LIST,
 "modules": T_MODULES,
@@ -2080,7 +2100,7 @@ set_re   = re.compile(r"CONFIG_(\w+)=(.*)")
 unset_re = re.compile(r"# CONFIG_(\w+) is not set")
 
 # Regular expression for finding $-references to symbols in strings
-sym_ref_re = re.compile(r"\$[A-Za-z_]+")
+sym_ref_re = re.compile(r"\$[A-Za-z0-9_]+")
 
 # Integers representing symbol types
 UNKNOWN, BOOL, TRISTATE, STRING, HEX, INT = range(0, 6)
@@ -2765,6 +2785,11 @@ class Symbol(Item, _HasVisibility)

[U-Boot] [PATCH] mx6_common: Fix LOADADDR and SYS_TEXT_BASE for MX6SL and MX6SX

From: Fabio Estevam 

Commit 8183058188cd2d942 ("imx6: centralise common boot options in
mx6_common.h") broke boot on mx6sl and mx6sx by assuming that all mx6
SoCs use the same LOADADDR/SYS_TEXT_BASE range, which is not correct.

DDR on mx6sx/mx6sl starts at 0x8000.

Adjust LOADADDR/SYS_TEXT_BASE to the proper values for mx6sx/mx6sl,
so that these SoCs can boot again.

Signed-off-by: Fabio Estevam 
---
 include/configs/mx6_common.h | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h
index 233c6d2..bd16ec2 100644
--- a/include/configs/mx6_common.h
+++ b/include/configs/mx6_common.h
@@ -53,10 +53,15 @@
 #define CONFIG_REVISION_TAG
 
 /* Boot options */
+#if (defined(CONFIG_MX6SX) || defined(CONFIG_MX6SL))
+#define CONFIG_LOADADDR0x8200
+#define CONFIG_SYS_TEXT_BASE   0x8780
+#else
 #define CONFIG_LOADADDR0x1200
+#define CONFIG_SYS_TEXT_BASE   0x1780
+#endif
 #define CONFIG_SYS_LOAD_ADDR   CONFIG_LOADADDR
 #ifndef CONFIG_SYS_TEXT_BASE
-#define CONFIG_SYS_TEXT_BASE   0x1780
 #endif
 #ifndef CONFIG_BOOTDELAY
 #define CONFIG_BOOTDELAY   3
-- 
1.9.1

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

Re: [U-Boot] [PATCH 0/10 v3] i.MX6: move duplicated options to mx6_common to standardise mx6 config

On Tue, May 26, 2015 at 10:45 PM, Fabio Estevam  wrote:
> On Tue, May 26, 2015 at 11:06 AM, Stefano Babic  wrote:
>> Hi Peter, Heiko,
>>
>> On 26/05/2015 15:23, Peter Robinson wrote:
>>>
>>> Please do, getting them applied so we can move forward would be great.
>>>
>>
>> Ok, all boards compile fine now - I have pushed all changes.
>
> I noticed that this series broke warp board and the board does not boot 
> anymore.
>
> Reverting this series I am able to boot it again.

Ok, so the problem is commit 8183058188c ("imx6: centralise common
boot options in mx6_common.h"), as it changes all mx6 SoCs to use
CONFIG_LOADADDR=0x1200, but this is not correct for mx6sx and
mx6sl that should use 0x8200 instead.

Regards,

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

Re: [U-Boot] Pull request: u-boot-net.git master

2015-05-26 Thread Tom Rini

On Tue, May 26, 2015 at 12:24:38PM -0500, Joe Hershberger wrote:

> Hi Tom,
> 
> This fixes a few mistakes I made in the rand rework stuff.
> 
> The following changes since commit 980267a1445b7b4d8e8d05ef57799d92ba4a2ee3:
> 
>   Merge git://git.denx.de/u-boot-nand-flash (2015-05-24 21:01:30 -0400)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-net.git master
> 
> for you to fetch changes up to 91fed5574600142f68dac7807bc06173d1f29eb5:
> 
>   blackfin: fix build error on bct-brettl2 board (2015-05-26 12:18:42 -0500)
> 

NAK:
06: Merge branch 'master' of git://git.denx.de/u-boot-net
  blackfin: bct-brettl2 +   bf537-minotaur cm-bf527 ip04 bf537-stamp 
cm-bf537e tcm-bf518 cm-bf537u bf527-ezkit bf537-pnav bf537-srv1 tcm-bf537 
dnp5370 bf518f-ezbrd bf526-ezbrd

All about CONFIG_LIB_RAND being redefined.

-- 
Tom


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

[U-Boot] [PATCH 4/5] ARM: UniPhier: move CONFIG_SYS_TEXT_BASE to Kconfig

Signed-off-by: Masahiro Yamada 
---

 Kconfig| 2 +-
 configs/ph1_ld4_defconfig  | 1 +
 configs/ph1_pro4_defconfig | 1 +
 configs/ph1_sld8_defconfig | 1 +
 include/configs/uniphier.h | 2 --
 5 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/Kconfig b/Kconfig
index 85faff7..15e15af 100644
--- a/Kconfig
+++ b/Kconfig
@@ -178,7 +178,7 @@ config SYS_EXTRA_OPTIONS
  new boards should not use this option.
 
 config SYS_TEXT_BASE
-   depends on SPARC || ARC || X86
+   depends on SPARC || ARC || X86 || ARCH_UNIPHIER
hex "Text Base"
help
  TODO: Move CONFIG_SYS_TEXT_BASE for all the architecture
diff --git a/configs/ph1_ld4_defconfig b/configs/ph1_ld4_defconfig
index 036e2d1..b0e02a9 100644
--- a/configs/ph1_ld4_defconfig
+++ b/configs/ph1_ld4_defconfig
@@ -6,6 +6,7 @@ CONFIG_PFC_MICRO_SUPPORT_CARD=y
 CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-ld4-ref"
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
+CONFIG_SYS_TEXT_BASE=0x8400
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BDI=y
 CONFIG_CMD_CONSOLE=y
diff --git a/configs/ph1_pro4_defconfig b/configs/ph1_pro4_defconfig
index 9a010ee..af25a3c 100644
--- a/configs/ph1_pro4_defconfig
+++ b/configs/ph1_pro4_defconfig
@@ -6,6 +6,7 @@ CONFIG_PFC_MICRO_SUPPORT_CARD=y
 CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-pro4-ref"
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
+CONFIG_SYS_TEXT_BASE=0x8400
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BDI=y
 CONFIG_CMD_CONSOLE=y
diff --git a/configs/ph1_sld8_defconfig b/configs/ph1_sld8_defconfig
index 29fe0e8..9de6b92 100644
--- a/configs/ph1_sld8_defconfig
+++ b/configs/ph1_sld8_defconfig
@@ -6,6 +6,7 @@ CONFIG_PFC_MICRO_SUPPORT_CARD=y
 CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-sld8-ref"
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
+CONFIG_SYS_TEXT_BASE=0x8400
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BDI=y
 CONFIG_CMD_CONSOLE=y
diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
index 331df62..dd64cdc 100644
--- a/include/configs/uniphier.h
+++ b/include/configs/uniphier.h
@@ -266,8 +266,6 @@
 #define CONFIG_SYS_SDRAM_SIZE  (CONFIG_SDRAM0_SIZE)
 #endif
 
-#define CONFIG_SYS_TEXT_BASE   0x8400
-
 #if defined(CONFIG_MACH_PH1_LD4) || defined(CONFIG_MACH_PH1_SLD8)
 #define CONFIG_SPL_TEXT_BASE   0x0004
 #endif
-- 
1.9.1

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

[U-Boot] [PATCH 3/5] ARM: UniPhier: remove meaningless CONFIG_SPL_BUILD ifdefs

This file is only built for SPL.
These ifdef conditionals are unnecessary because UniPhier platform
now supports UART on SPL.
Show appropriate messages on error.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/ddrphy_training.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-uniphier/ddrphy_training.c 
b/arch/arm/mach-uniphier/ddrphy_training.c
index b1d46cf..5f3d591 100644
--- a/arch/arm/mach-uniphier/ddrphy_training.c
+++ b/arch/arm/mach-uniphier/ddrphy_training.c
@@ -1,6 +1,7 @@
 /*
- * Copyright (C) 2011-2014 Panasonic Corporation
- *   Author: Masahiro Yamada 
+ * Copyright (C) 2011-2015 Panasonic Corporation
+ * Copyright (C) 2015  Socionext Inc.
+ *   Author: Masahiro Yamada 
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
@@ -116,10 +117,8 @@ int ddrphy_training(struct ddrphy __iomem *phy)
 
do {
if (--timeout < 0) {
-#ifndef CONFIG_SPL_BUILD
printf("%s: error: timeout during DDR training\n",
__func__);
-#endif
return -1;
}
udelay(1);
@@ -128,10 +127,8 @@ int ddrphy_training(struct ddrphy __iomem *phy)
 
for (i = 0; i < ARRAY_SIZE(init_sequence); i++) {
if (pgsr0 & init_sequence[i].err_flag) {
-#ifndef CONFIG_SPL_BUILD
printf("%s: error: %s failed\n", __func__,
init_sequence[i].description);
-#endif
return -1;
}
}
-- 
1.9.1

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

[U-Boot] [PATCH 0/5] UniPhier updates for v2015.07-rc2




Masahiro Yamada (5):
  ARM: UniPhier: use 32 bit register access for debug UART setting
  ARM: UniPhier: remove unnecessary cache coherency code
  ARM: UniPhier: remove meaningless CONFIG_SPL_BUILD ifdefs
  ARM: UniPhier: move CONFIG_SYS_TEXT_BASE to Kconfig
  ARM: UniPhier: update DDR PHY register map for PH1-Pro5

 Kconfig   |  2 +-
 arch/arm/mach-uniphier/ddrphy_training.c  |  9 +++--
 arch/arm/mach-uniphier/include/mach/ddrphy-regs.h | 13 +
 arch/arm/mach-uniphier/include/mach/debug-uart.S  |  9 +
 arch/arm/mach-uniphier/lowlevel_init.S| 20 
 configs/ph1_ld4_defconfig |  1 +
 configs/ph1_pro4_defconfig|  1 +
 configs/ph1_sld8_defconfig|  1 +
 include/configs/uniphier.h|  2 --
 9 files changed, 21 insertions(+), 37 deletions(-)

-- 
1.9.1

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

[U-Boot] [PATCH 5/5] ARM: UniPhier: update DDR PHY register map for PH1-Pro5

PH1-Pro5 includes a newer version of DDR PHY IP.  Some registers
have been added to the reserved areas.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/include/mach/ddrphy-regs.h | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-uniphier/include/mach/ddrphy-regs.h 
b/arch/arm/mach-uniphier/include/mach/ddrphy-regs.h
index 6b7d600..df7d815 100644
--- a/arch/arm/mach-uniphier/include/mach/ddrphy-regs.h
+++ b/arch/arm/mach-uniphier/include/mach/ddrphy-regs.h
@@ -1,8 +1,9 @@
 /*
  * UniPhier DDR PHY registers
  *
- * Copyright (C) 2014 Panasonic Corporation
- *   Author: Masahiro Yamada 
+ * Copyright (C) 2014-2015 Panasonic Corporation
+ * Copyright (C) 2015  Socionext Inc.
+ *   Author: Masahiro Yamada 
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
@@ -37,7 +38,10 @@ struct ddrphy {
u32 dtar[4];/* Data Training Address Register */
u32 dtdr[2];/* Data Training Data Register */
u32 dtedr[2];   /* Data Training Eye Data Register */
-   u32 rsv0[13];   /* Reserved */
+   u32 pgcr2;  /* PHY General Configuration Register 2 */
+   u32 rsv0[8];/* Reserved */
+   u32 rdimmgcr[2];/* RDIMM General Configuration Register */
+   u32 rdimmcr0[2];/* RDIMM Control Register */
u32 dcuar;  /* DCU Address Register */
u32 dcudr;  /* DCU Data Register */
u32 dcurr;  /* DCU Run Register */
@@ -70,7 +74,8 @@ struct ddrphy {
u32 lcdlr[3];   /* Local Calibrated Delay Line Register */
u32 mdlr;   /* Master Delay Line Register */
u32 gtr;/* General Timing Register */
-   u32 rsv[3]; /* Reserved */
+   u32 gsr2;   /* General Status Register 2 */
+   u32 rsv[2]; /* Reserved */
} dx[9];
 };
 
-- 
1.9.1

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

[U-Boot] [PATCH 1/5] ARM: UniPhier: use 32 bit register access for debug UART setting

For the same reason as commit d0c47b3ef7c5 (serial: UniPhier: use
32 bit register access), use "str" instead of "strb" for the LCR
register setting.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/include/mach/debug-uart.S | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-uniphier/include/mach/debug-uart.S 
b/arch/arm/mach-uniphier/include/mach/debug-uart.S
index af55fee..9ae2e18 100644
--- a/arch/arm/mach-uniphier/include/mach/debug-uart.S
+++ b/arch/arm/mach-uniphier/include/mach/debug-uart.S
@@ -1,6 +1,7 @@
 /*
- * Copyright (C) 2014 Panasonic Corporation
- *   Author: Masahiro Yamada 
+ * Copyright (C) 2014-2015 Panasonic Corporation
+ * Copyright (C) 2015  Socionext Inc.
+ *   Author: Masahiro Yamada 
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
@@ -17,8 +18,8 @@
 
.macro  init_debug_uart, ra, rb, rc
addruart\ra, \rb, \rc
-   mov \rb, #UART_LCR_WLEN8
-   strb\rb, [\ra, #0x11]
+   mov \rb, #UART_LCR_WLEN8 << 8
+   str \rb, [\ra, #0x10]
ldr \rb, =DIVISOR
str \rb, [\ra, #0x24]
.endm
-- 
1.9.1

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

[U-Boot] [PATCH 2/5] ARM: UniPhier: remove unnecessary cache coherency code

Cache coherency for SMP is cared by Linux.  In U-Boot, the secondary
CPU(s) are just sleeping.  Nothing in memory is shared with the
primary CPU.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/lowlevel_init.S | 20 
 1 file changed, 20 deletions(-)

diff --git a/arch/arm/mach-uniphier/lowlevel_init.S 
b/arch/arm/mach-uniphier/lowlevel_init.S
index 825b160..aaea7bf 100644
--- a/arch/arm/mach-uniphier/lowlevel_init.S
+++ b/arch/arm/mach-uniphier/lowlevel_init.S
@@ -67,20 +67,6 @@ secondary_startup:
 *  jump to Linux
 *  kick secondaries   ---(sev)--->jump to Linux
 */
-   /*
-* ACTLR (Auxiliary Control Register) for Cortex-A9
-* bit[9]  Parity on
-* bit[8]  Alloc in one way
-* bit[7]  EXCL (Exclusive cache bit)
-* bit[6]  SMP
-* bit[3]  Write full line of zeros mode
-* bit[2]  L1 prefetch enable
-* bit[1]  L2 prefetch enable
-* bit[0]  FW (Cache and TLB maintenance broadcast)
-*/
-   mrc p15, 0, r0, c1, c0, 1   @ ACTLR (Auxiliary Control Register)
-   orr r0, r0, #0x41   @ enable SMP, FW bit
-   mcr p15, 0, r0, c1, c0, 1
 
/* branch by CPU ID */
mrc p15, 0, r0, c0, c0, 5   @ MPIDR (Multiprocessor Affinity 
Register)
@@ -112,12 +98,6 @@ primary_cpu:
str r0, [r1]
ldr r0, [r1]@ make sure str is complete before sev
sev @ kick the secondary CPU
-   mrc p15, 4, r1, c15, c0, 0  @ Configuration Base Address Register
-   bfc r1, #0, #13 @ clear bit 12-0
-   mov r0, #-1
-   str r0, [r1, #SCU_INV_ALL]  @ SCU Invalidate All Register
-   mov r0, #1  @ SCU enable
-   str r0, [r1, #SCU_CTRL] @ SCU Control Register
 #endif
 
bl  setup_init_ram  @ RAM area for temporary stack pointer
-- 
1.9.1

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

Re: [U-Boot] [PATCH 0/10 v3] i.MX6: move duplicated options to mx6_common to standardise mx6 config

On Tue, May 26, 2015 at 11:06 AM, Stefano Babic  wrote:
> Hi Peter, Heiko,
>
> On 26/05/2015 15:23, Peter Robinson wrote:
>>
>> Please do, getting them applied so we can move forward would be great.
>>
>
> Ok, all boards compile fine now - I have pushed all changes.

I noticed that this series broke warp board and the board does not boot anymore.

Reverting this series I am able to boot it again.

Will investigate more tomorrow.

Regards,

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

Re: [U-Boot] [PATCH v4] tools: moveconfig: a tool to move CONFIGs from headers to defconfigs

Hi Masahiro-san,

On Tue, May 26, 2015 at 6:41 PM, Masahiro Yamada
 wrote:
> 2015-05-20 11:36 GMT+09:00 Masahiro Yamada :
>> This tool was originally written for my local use to ease the task
>> of tons of CONFIG moves, but there have been some requests for
>> mainlining it.
>> So, I have tidied up the code with nicer comments, and here it is.
>>
>> See the comment block of the script for usage.
>>
>> The first draft was
>> http://patchwork.ozlabs.org/patch/430422/
>>
>> Main updates are:
>>   - Adapted to the single .config configuration
>>   - Support colored log
>>   - Support moving multiple options at once
>> (and take configs via input file only)
>>   - Continue even if some boards fail
>> (Idea provided by Joe Hershberger)
>>   - Add more options
>>   - More comments and code cleanups
>>
>> Signed-off-by: Masahiro Yamada 
>> Signed-off-by: Joe Hershberger 
>
>
> Applied to u-boot-uniphier/misc.

I think maybe you missed my comment:

On Fri, May 15, 2015 at 3:44 PM, Joe Hershberger
 wrote:
>
> You should add "moveconfig" to doc/git-mailrc in this patch.

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

[U-Boot] pull request: u-boot-uniphier/misc

Hi Tom,

Here is a new tool that helps us move CONFIG options easily.



The following changes since commit 9bea236b3402a262772b66d055ec6431cbd3ba87:

  Merge branch 'master' of git://www.denx.de/git/u-boot-imx
(2015-05-26 10:38:01 -0400)

are available in the git repository at:


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

for you to fetch changes up to 2e2ce6c0c8d3d0d2a86d2464d201aecd9aef693d:

  moveconfig: Print status about the processed defconfigs (2015-05-27
08:39:16 +0900)


Joe Hershberger (9):
  moveconfig: Always run savedefconfig on the moved config
  moveconfig: Ignore duplicate configs when moving
  moveconfig: Add a parameter to accept a list to build
  moveconfig: Add a switch to only cleanup headers
  moveconfig: Cleanup headers in arch and board
  moveconfig: Output a list of failed boards
  moveconfig: Print a message for missing compiler
  moveconfig: Add a switch to enable printing errors
  moveconfig: Print status about the processed defconfigs

Masahiro Yamada (1):
  tools: moveconfig: a tool to move CONFIGs from headers to defconfigs

 scripts/Makefile.autoconf |   3 +-
 tools/moveconfig.py   | 918
+++
 2 files changed, 920 insertions(+), 1 deletion(-)
 create mode 100755 tools/moveconfig.py


-- 
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 v5 1/9] moveconfig: Always run savedefconfig on the moved config

2015-05-20 3:21 GMT+09:00 Joe Hershberger :
> This will ensure that the order of the defconfig entries will always
> match that of the Kconfig files. After one slightly painful (but
> still early in the process) pass over all boards, this should keep
> the defconfigs clean from here on.
>
> Users must edit the Kconfig first to add the menu entries and then run
> moveconfig.py to update the defconfig files and the include configs.
>
> As such, moveconfig.py cannot compare against the '.config' contents.
>
> Signed-off-by: Joe Hershberger 
> ---
> This is based on https://patchwork.ozlabs.org/patch/472591/
>
> Changes in v5:
> -Removed warning that may never be reached


The series, applied to u-boot-uniphier/misc with my Acked-by.
Thanks!


-- 
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 v4] tools: moveconfig: a tool to move CONFIGs from headers to defconfigs

2015-05-20 11:36 GMT+09:00 Masahiro Yamada :
> This tool was originally written for my local use to ease the task
> of tons of CONFIG moves, but there have been some requests for
> mainlining it.
> So, I have tidied up the code with nicer comments, and here it is.
>
> See the comment block of the script for usage.
>
> The first draft was
> http://patchwork.ozlabs.org/patch/430422/
>
> Main updates are:
>   - Adapted to the single .config configuration
>   - Support colored log
>   - Support moving multiple options at once
> (and take configs via input file only)
>   - Continue even if some boards fail
> (Idea provided by Joe Hershberger)
>   - Add more options
>   - More comments and code cleanups
>
> Signed-off-by: Masahiro Yamada 
> Signed-off-by: Joe Hershberger 


Applied to u-boot-uniphier/misc.

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

Re: [U-Boot] soft-i2c and i2c-gpio issues with at91

Hi Matt,

On 26 May 2015 at 11:23, Matt Wood  wrote:
>
> Thank you Simon.  Getting there, but now I get a data abort and system reset 
> when trying to set the i2c bus.  I need to chase this down, but if you have 
> any suggestions I'd appreciate it.

Suggest putting your reply at the bottom so people on the mailing list
can follow it.

>
> Below is the output of dm tree and dm uclass.
>
> Thanks, Matt.
>
> U-Boot> i2c dev 3
> Setting bus to 3
> data abort
> pc : [<3ff714a0>]  lr : [<3ff7148c>]
> reloc pc : [<26f194a0>]lr : [<26f1948c>]

You can look in System.map to find that reloc pc, or even addr2line if you like.

This will probe your device. So check that your probe() method is
correct. You can post it here if you like.

> sp : 3fb52168  ip : 001f fp : 
> r10: 0003  r9 : 3fb57ee0 r8 : 3ffa5588
> r7 : 3ff92ff4  r6 : 3fb581c8 r5 : 001f  r4 : 
> r3 : 0001  r2 :  r1 : 8000  r0 : ea16
> Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
> Resetting CPU ...
>
> resetting ...
> RomBOOT
>
> U-Boot> dm tree
>  Class   Probed   Name
> 
>  root[ + ]root_driver
>  simple_bus  [   ]|-- ahb
>  simple_bus  [   ]|   `-- apb
>  simple_bus  [   ]|   `-- pinctrl@fc06a000
>  gpio[   ]|   |-- gpio@fc06a000
>  gpio[   ]|   |-- gpio@fc06b000
>  gpio[   ]|   |-- gpio@fc06c000
>  gpio[   ]|   `-- gpio@fc06d000
>  i2c [   ]`-- gpio-i2c@1

Do you have a reg property? It should be the address of this I2C
peripheral in the memory map.

>
> U-Boot> dm uclass
> uclass 0: root
> - * root_driver @ 3fb58028, seq 0, (req -1)
>
> Cannot find uclass for id 1: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 2: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 3: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 4: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 5: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 6: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 7: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 8: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> uclass 9: simple_bus
> -   ahb @ 3fb580a0
> -   apb @ 3fb580f8
> -   pinctrl@fc06a000 @ 3fb58150
>
> uclass 10: gpio
> -   gpio@fc06a000 @ 3fb581c8
> -   gpio@fc06b000 @ 3fb58220
> -   gpio@fc06c000 @ 3fb58278
> -   gpio@fc06d000 @ 3fb582d0
>
> Cannot find uclass for id 11: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 12: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 13: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 14: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 15: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 16: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> uclass 17: i2c
> -   gpio-i2c@1 @ 3fb58348, seq -1, (req 3)
>
> uclass 18: i2c_generic
> Cannot find uclass for id 19: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 20: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 21: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 22: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 23: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 24: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 25: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 26: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 27: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 28: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 29: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 30: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
> Cannot find uclass for id 31: please add the UCLASS_DRIVER() declaration for 
> this UCLASS_... id
>
> On Tue, May 26, 2015 at 10:41 AM, Simon Glass  wrote:
>>
>> Hi Matt,
>>
>> On 26 May 2015 at 08:33, Matt Wood  wrote:
>> > Hi Simon, yes I currently have i2c-gpio enabled.  Below is the

Re: [U-Boot] [PATCH v2] wandboard: Add board revision detection support

On Tue, May 26, 2015 at 3:55 PM, Alexander Holler  wrote:

> Besides that I don't really care what a maintainer said to some previous
> similiar problem. Maintainers are humans too, maybe he just had forgotten
> about the gpio-command.

The gpio command is now available in Stefano's tree after Peter's
config consolidation series has been applied.

Regards,

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

Re: [U-Boot] [PATCH v2 22/22] x86: Add support for Intel Minnowboard Max

Hi Andrew,

On 26 May 2015 at 13:52, Andrew Bradford  wrote:
> Hi Simon and Bin (sorry for bringing this back from the dead),
>
> But I have a question about fsp_configs.c down below:
>
> On 01/27 22:13, Simon Glass wrote:
> ->8---
>> diff --git a/arch/x86/cpu/baytrail/fsp_configs.c 
>> b/arch/x86/cpu/baytrail/fsp_configs.c
>> new file mode 100644
>> index 000..86b6926
>> --- /dev/null
>> +++ b/arch/x86/cpu/baytrail/fsp_configs.c
>> @@ -0,0 +1,156 @@
>> +/*
>> + * Copyright (C) 2013, Intel Corporation
>> + * Copyright (C) 2014, Bin Meng 
>> + *
>> + * SPDX-License-Identifier:  Intel
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* ALC262 Verb Table - 10EC0262 */
>> +static const uint32_t verb_table_data13[] = {
>> + /* Pin Complex (NID 0x11) */
>> + 0x01171cf0,
>> + 0x01171d11,
>> + 0x01171e11,
>> + 0x01171f41,
>> + /* Pin Complex (NID 0x12) */
>> + 0x01271cf0,
>> + 0x01271d11,
>> + 0x01271e11,
>> + 0x01271f41,
>> + /* Pin Complex (NID 0x14) */
>> + 0x01471c10,
>> + 0x01471d40,
>> + 0x01471e01,
>> + 0x01471f01,
>> + /* Pin Complex (NID 0x15) */
>> + 0x01571cf0,
>> + 0x01571d11,
>> + 0x01571e11,
>> + 0x01571f41,
>> + /* Pin Complex (NID 0x16) */
>> + 0x01671cf0,
>> + 0x01671d11,
>> + 0x01671e11,
>> + 0x01671f41,
>> + /* Pin Complex (NID 0x18) */
>> + 0x01871c20,
>> + 0x01871d98,
>> + 0x01871ea1,
>> + 0x01871f01,
>> + /* Pin Complex (NID 0x19) */
>> + 0x01971c21,
>> + 0x01971d98,
>> + 0x01971ea1,
>> + 0x01971f02,
>> + /* Pin Complex (NID 0x1A) */
>> + 0x01a71c2f,
>> + 0x01a71d30,
>> + 0x01a71e81,
>> + 0x01a71f01,
>> + /* Pin Complex */
>> + 0x01b71c1f,
>> + 0x01b71d40,
>> + 0x01b71e21,
>> + 0x01b71f02,
>> + /* Pin Complex */
>> + 0x01c71cf0,
>> + 0x01c71d11,
>> + 0x01c71e11,
>> + 0x01c71f41,
>> + /* Pin Complex */
>> + 0x01d71c01,
>> + 0x01d71dc6,
>> + 0x01d71e14,
>> + 0x01d71f40,
>> + /* Pin Complex */
>> + 0x01e71cf0,
>> + 0x01e71d11,
>> + 0x01e71e11,
>> + 0x01e71f41,
>> + /* Pin Complex */
>> + 0x01f71cf0,
>> + 0x01f71d11,
>> + 0x01f71e11,
>> + 0x01f71f41,
>> +};
>> +
>> +/*
>> + * This needs to be in ROM since if we put it in CAR, FSP init loses it when
>> + * it drops CAR.
>> + *
>> + * TODO(s...@chromium.org): Move to device tree when FSP allows it
>> + *
>> + * VerbTable: (RealTek ALC262)
>> + * Revision ID = 0xFF, support all steps
>> + * Codec Verb Table For AZALIA
>> + * Codec Address: CAd value (0/1/2)
>> + * Codec Vendor: 0x10EC0262
>> + */
>> +static const struct pch_azalia_verb_table azalia_verb_table[] = {
>> + {
>> + {
>> + 0x10ec0262,
>> + 0x,
>> + 0xff,
>> + 0x01,
>> + 0x000b,
>> + 0x0002,
>> + },
>> + verb_table_data13
>> + }
>> +};
>> +
>> +const struct pch_azalia_config azalia_config = {
>> + .pme_enable = 1,
>> + .docking_supported = 1,
>> + .docking_attached = 0,
>> + .hdmi_codec_enable = 1,
>> + .azalia_v_ci_enable = 1,
>> + .rsvdbits = 0,
>> + .azalia_verb_table_num = 1,
>> + .azalia_verb_table = azalia_verb_table,
>> + .reset_wait_timer_us = 300
>> +};
>> +
>> +void update_fsp_upd(struct upd_region *fsp_upd)
>> +{
>> + struct memory_down_data *mem;
>> +
>> + /*
>> +  * Configure everything here to avoid the poor hard-pressed user
>> +  * needing to run Intel's binary configuration tool. It may also allow
>> +  * us to support the 1GB single core variant easily.
>> +  *
>> +  * TODO(s...@chromium.org): Move to device tree
>> +  */
>> + fsp_upd->mrc_init_tseg_size = 8;
>> + fsp_upd->mrc_init_mmio_size = 0x800;
>> + fsp_upd->emmc_boot_mode = 0xff;
>> + fsp_upd->enable_sdio = 1;
>> + fsp_upd->enable_sdcard = 1;
>> + fsp_upd->enable_hsuart0 = 1;
>> + fsp_upd->azalia_config_ptr = (uint32_t)&azalia_config;
>> + fsp_upd->enable_i2_c0 = 0;
>> + fsp_upd->enable_i2_c2 = 0;
>> + fsp_upd->enable_i2_c3 = 0;
>> + fsp_upd->enable_i2_c4 = 0;
>> + fsp_upd->enable_xhci = 0;
>> + fsp_upd->igd_render_standby = 1;
>> +
>> + mem = &fsp_upd->memory_params;
>> + mem->enable_memory_down = 1;
>> + mem->dram_speed = 1;
>> + mem->dimm_width = 1;
>> + mem->dimm_density = 2;
>> + mem->dimm_tcl = 0xb;
>> + mem->dimm_trpt_rcd = 0xb;
>> + mem->dimm_twr = 0xc;
>> + mem->dimm_twtr = 6;
>> + mem->dimm_trrd = 6;
>> + mem->dimm_trtp = 6;
>> + mem->dimm_tfaw = 0x14;
>> +}
>
> I am trying to move this fsp upd to use device tree as I am trying to
> create a patch set to add the Intel Valley Island E38xx board (which
> uses a SODIMM rather than memory down).  In doing so, I've found that
> globa

Re: [U-Boot] [PATCH V4] Add Sunxi NAND support to SPL

2015-05-26 Thread Hans de Goede


Hi,

On 05/26/2015 05:00 PM, Roy Spliet wrote:

V4 slightly clarifies the gating code and is a bit more precise with
definitions for other boards. As far as I'm concerned they can be merged
now.


Thanks, I've pushed this to u-boot-sunxi/next.
I plan to send a pull-req for getting this into
master during one of the coming days.

Regards,

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

Re: [U-Boot] [PATCH v2 1/4] x86: Refactor PIRQ routing support

On 25 May 2015 at 08:35, Bin Meng  wrote:
> PIRQ routing is pretty much common in Intel chipset. It has several
> PIRQ links (normally 8) and corresponding registers (either in PCI
> configuration space or memory-mapped IBASE) to configure the legacy
> 8259 IRQ vector mapping. Refactor current Queensbay PIRQ routing
> support using device tree and move it to a common place, so that we
> can easily add PIRQ routing support on a new platform.
>
> Signed-off-by: Bin Meng 
>
> ---
>
> Changes in v2:
> - Include dt-bindings/interrupt-router/intel-irq.h to avoid duplication
> - Remove board_fill_irq_info() since all routing information is defined in dts
>
>  arch/x86/cpu/Makefile|   2 +-
>  arch/x86/cpu/irq.c   | 213 
>  arch/x86/cpu/queensbay/Makefile  |   2 +-
>  arch/x86/cpu/queensbay/irq.c | 242 
> ---
>  arch/x86/cpu/queensbay/tnc.c |  39 +++-
>  arch/x86/dts/crownbay.dts|  54 +
>  arch/x86/include/asm/arch-queensbay/irq.h|  55 --
>  arch/x86/include/asm/irq.h   |  76 +++
>  include/dt-bindings/interrupt-router/intel-irq.h |  31 +++
>  include/fdtdec.h |   1 +
>  lib/fdtdec.c |   1 +
>  11 files changed, 416 insertions(+), 300 deletions(-)
>  create mode 100644 arch/x86/cpu/irq.c
>  delete mode 100644 arch/x86/cpu/queensbay/irq.c
>  delete mode 100644 arch/x86/include/asm/arch-queensbay/irq.h
>  create mode 100644 arch/x86/include/asm/irq.h
>  create mode 100644 include/dt-bindings/interrupt-router/intel-irq.h
>

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

Re: [U-Boot] Proposal to add NAND-boot support for Sunxi SPL

2015-05-26 Thread Alexander Kaplan

Hi,

I tried both the kernel from
https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-nand-experiment

and u-boot from
https://gitlab.com/turtle-solutions/u-boot/commits/sunxi-nand-wip

I can successfully compile and boot them on my A13-OLinuXino but there is
no NAND available. Neither in kernel log nor in the u-boot output there is
anything mentioned about NAND. I tried to enable all the NAND options,
especially the "Support for NAND on Allwinner SoCs" in nconfig but I'm
afraid I still have not found the right configuration.

Would it be possible to share the build configuration files?

Thanks in advance
Alex

On Tue, May 26, 2015 at 7:52 AM, Hans de Goede  wrote:

> Hi,
>
>
> On 05/26/2015 09:34 AM, Roy Spliet wrote:
>
>> Hello Hans,
>>
>> Re-sent to everybody instead of just you. Reply inline.
>>
>> Op 25-05-15 om 22:39 schreef Hans de Goede:
>>
>>> Hi,
>>>
>>> On 25-05-15 20:35, Hans de Goede wrote:
>>>
 Hi,

 On 22-05-15 09:04, Roy Spliet wrote:

> Hello,
>
> For my set-up I made use of Boris Brezillon's sunxi-nand tree[1], or
> actually I rebased his patches on top of 4.0rc7. This basically adds
> support for NAND-chip partitioning, ECC and randomisation. Docs for the DT
> specification in Documentation/devicetree/bindings/mtd/sunxi-nand.txt , 
> and
> an example can be found in arch/arm/boot/dts/sun7i-a20-cubietruck.dts . 
> [2]
> lists the acceptable configuration options for the boot and boot_rescue
> partitions, make sure to pick one of these (which should be no problem for
> MLC-type nand). The ECC mode for these boot partitions is called
> hw_syndrome.
>
> Assuming you now have a Linux set-up kernel based on this tree with
> NAND support on an MMC, for U-boot what you should currently do is:
> 1) in include/configs/sunxi-common.h, adjust the parameters
> PAGE_SIZE, ECC_STEP, ECC_STRENGTH to match your NAND
> chip and DT configuration.
> 2) Build
> 3) Use your MMC to flash u-boot-sunxi-with-spl.bin onto NAND:
> # flash_erase /dev/mtd0
> # nandwrite -p /dev/mtd0 u-boot-sunxi-with-spl.bin
> 4) Reboot without the MMC card and see U-boot load
>

 Ok, it took me way longer then I wanted (see below) but I've this
 working now. It is cool to see u-boot load from nand :)

>
> That should be all.
>
> @Alex: To answer your question specifically: It's likely that the
> parameters in sunxi-common.h mentioned above might not match your 
> NAND-chip
> configuration in the Linux kernel. I can't tell you precisely how to fetch
> these details from the 3.4 kernel, sorry. I recall Daniel using 24-bit
> strength ECC with otherwise equal parameters, but perhaps he can help you
> with this better than I can.
>

 Alex, could it be that you are writing the nand using
 a (rebased) version of bbrezillon's sunxi-nand-next branch ?

 I started with that too because it is much newer and contains
 various bug fixes, but it seems that it also contains a new
 bug causing it to write the NAND in such a way that the BROM
 and u-boot SPL code will not read it.

 I've just pushed a rebased version of the sunxi-nand branch of
 Boris here:

 https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-nand-experiment

 And that works for me, where as before I got the exact same errors
 trying to fel load a nand enabled spl.

 I'm working on merging over all the changes from the sunxi-nand-next
 branch onto my working sunxi-nand-experiment branch 1 by 1 until
 I find the one which causes the breakage...

>>>
>>> Ok, so quick update the breakage was caused by this commit:
>>>
>>>
>>> https://github.com/bbrezillon/linux-sunxi/commit/7f7324bc6170a45742352070fb45170779a3611c
>>>
>>> When it was rebased someone (Boris I guess) forgot to remove the
>>> "chip->read_buf(mtd, NULL, ecc->size);" line at line 1075 (after the
>>> patch) and
>>> likewise the "chip->write_buf(mtd, buf + (i * ecc->size), ecc->size);"
>>> line at
>>> line 1161. With these 2 lines removed the sunxi-nand-next branch from
>>> Boris,
>>> rebased on 4.1-rc1 can write the nand boot parts and the brom / spl can
>>> load
>>> the spl / resp. u-boot.bin from there (on a cubieboard2).
>>>
>> You're right... I did spot this, but assumed this was my own mistake in
>> merging these patches with our 4.0RC7 tree. Sorry, could have saved you
>> some trouble if I were sharper.
>>
>>>
>>> I've also tried to get this code running on a cubieboard (non 2 so A10
>>> rather then
>>> A20), the SPL loads fine there (indicating that the kernel bits work),
>>> but then
>>> I get:
>>>
>>> U-Boot SPL 2015.07-rc1-00287-g050de86-dirty (May 25 2015 - 22:28:19)
>>> DRAM: 1024 MiB
>>> CPU: 100800Hz, AXI/AHB/APB: 3/2/2
>>> Nand initialised
>>> NAND timeout reading data
>>> NAND timeout reading data
>>> NAND timeout reading data
>>> NAND timeo

Re: [U-Boot] [PATCH] mx6: invalidate D-cache only when booting from USB

2015-05-26 Thread Vincent

Stefano wrote:
> Please help me to find the use case. I searched in all i.MX6 boards in
> mainline, but none of them is setting CONFIG_SKIP_LOWLEVEL_INIT. Can you
> tell me on which board there is this issue ?

Hi Stefano,

Thank you for taking the time to look at this proposed patch.

You are right, this is a "non standard" use case. What I am trying to do
is to boot u-boot with u-boot on i.MX6Q Sabre SD :)

Here are more details on what I would like to do:

1. Boot "old" u-boot from SD card.
2. "old" u-boot loads "new" u-boot from network with 'dhcp' command.
3. "old" u-boot boots "new" u-boot with 'go' command.

This is not so easy to achieve, it seems. I learned that in this
peculiar use case it is necessary to set CONFIG_SKIP_LOWLEVEL_INIT when
building the "new" u-boot, as hinted by the README.

Also I found out that the call to invalidate_dcache_all() would prevent
the boot for the aforementioned use case. "protecting" the call (as done
in Freescale u-boot) "repairs" my use case, and I verified that it does
not alter the boot through USB.

(boot from USB detection code)
> This looks like a hack. I understand this can work in your case, but can
> we set as general case ? You check power for PHY0, but what about if a
> board is using PHY1 ?
> Anyway, is it not possible to get the boot storage from the SRC ?

You are right, the detection code is not perfect. This is the one I
borrowed from Freescale u-boot, though, so it is reasonably tested "in
the field".

About the phy0/phy1 distinction, I think we can boot only from OTG PHY0
so no worry.

About the SRC; I am not sure you can get the desired information from
there, as booting from USB is a ROM "fallback".

(adding a condition to cache invalidation)
> I cannot understand well this. The correct implementation seems correct
> to me. And if you have issues booting with USB, why are you changing the
> behavior in all other cases *except* booting from USB, where you rely on
> the current implementation invalidating the cache ?

In my case, it is NOT booting with USB rather, it is booting from
another u-boot. I discovered that invalidating the caches in this case
breaks the boot.

The current implementation invalidates the cache in all cases for i.MX6,
as it believes it is always booting from the ROM.

As the comments hint that invalidating the caches is necessary only when
booting from USB (from ROM), I tried to restrict a bit more the
invalidation to this "boot from USB" case. The detection is not perfect,
but it is enough to repair my use case, at least.

Best regards,

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

Re: [U-Boot] Proposal to add NAND-boot support for Sunxi SPL

2015-05-26 Thread Daniel Kochmański

Hello Alexander,

you have to put correct nand configuration in devicetree in
arch/arm/boot/dts/sun5i-a13-olinuxino.dts of your board. For comparision
you may check sun7i-a20-cubieboard2.dts which has appropriate
definitions. sunxi-nand-wip branch works on a20.

Good luck!
Daniel

Alexander Kaplan writes:

> Hi,
>
> I tried both the kernel from
> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-nand-experiment
>
> and u-boot from
> https://gitlab.com/turtle-solutions/u-boot/commits/sunxi-nand-wip
>
> I can successfully compile and boot them on my A13-OLinuXino but there is
> no NAND available. Neither in kernel log nor in the u-boot output there is
> anything mentioned about NAND. I tried to enable all the NAND options,
> especially the "Support for NAND on Allwinner SoCs" in nconfig but I'm
> afraid I still have not found the right configuration.
>
> Would it be possible to share the build configuration files?
>
> Thanks in advance
> Alex
>
> On Tue, May 26, 2015 at 7:52 AM, Hans de Goede  wrote:
>
>> Hi,
>>
>>
>> On 05/26/2015 09:34 AM, Roy Spliet wrote:
>>
>>> Hello Hans,
>>>
>>> Re-sent to everybody instead of just you. Reply inline.
>>>
>>> Op 25-05-15 om 22:39 schreef Hans de Goede:
>>>
 Hi,

 On 25-05-15 20:35, Hans de Goede wrote:

> Hi,
>
> On 22-05-15 09:04, Roy Spliet wrote:
>
>> Hello,
>>
>> For my set-up I made use of Boris Brezillon's sunxi-nand tree[1], or
>> actually I rebased his patches on top of 4.0rc7. This basically adds
>> support for NAND-chip partitioning, ECC and randomisation. Docs for the 
>> DT
>> specification in Documentation/devicetree/bindings/mtd/sunxi-nand.txt , 
>> and
>> an example can be found in arch/arm/boot/dts/sun7i-a20-cubietruck.dts . 
>> [2]
>> lists the acceptable configuration options for the boot and boot_rescue
>> partitions, make sure to pick one of these (which should be no problem 
>> for
>> MLC-type nand). The ECC mode for these boot partitions is called
>> hw_syndrome.
>>
>> Assuming you now have a Linux set-up kernel based on this tree with
>> NAND support on an MMC, for U-boot what you should currently do is:
>> 1) in include/configs/sunxi-common.h, adjust the parameters
>> PAGE_SIZE, ECC_STEP, ECC_STRENGTH to match your NAND
>> chip and DT configuration.
>> 2) Build
>> 3) Use your MMC to flash u-boot-sunxi-with-spl.bin onto NAND:
>> # flash_erase /dev/mtd0
>> # nandwrite -p /dev/mtd0 u-boot-sunxi-with-spl.bin
>> 4) Reboot without the MMC card and see U-boot load
>>
>
> Ok, it took me way longer then I wanted (see below) but I've this
> working now. It is cool to see u-boot load from nand :)
>
>>
>> That should be all.
>>
>> @Alex: To answer your question specifically: It's likely that the
>> parameters in sunxi-common.h mentioned above might not match your 
>> NAND-chip
>> configuration in the Linux kernel. I can't tell you precisely how to 
>> fetch
>> these details from the 3.4 kernel, sorry. I recall Daniel using 24-bit
>> strength ECC with otherwise equal parameters, but perhaps he can help you
>> with this better than I can.
>>
>
> Alex, could it be that you are writing the nand using
> a (rebased) version of bbrezillon's sunxi-nand-next branch ?
>
> I started with that too because it is much newer and contains
> various bug fixes, but it seems that it also contains a new
> bug causing it to write the NAND in such a way that the BROM
> and u-boot SPL code will not read it.
>
> I've just pushed a rebased version of the sunxi-nand branch of
> Boris here:
>
> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-nand-experiment
>
> And that works for me, where as before I got the exact same errors
> trying to fel load a nand enabled spl.
>
> I'm working on merging over all the changes from the sunxi-nand-next
> branch onto my working sunxi-nand-experiment branch 1 by 1 until
> I find the one which causes the breakage...
>

 Ok, so quick update the breakage was caused by this commit:


 https://github.com/bbrezillon/linux-sunxi/commit/7f7324bc6170a45742352070fb45170779a3611c

 When it was rebased someone (Boris I guess) forgot to remove the
 "chip->read_buf(mtd, NULL, ecc->size);" line at line 1075 (after the
 patch) and
 likewise the "chip->write_buf(mtd, buf + (i * ecc->size), ecc->size);"
 line at
 line 1161. With these 2 lines removed the sunxi-nand-next branch from
 Boris,
 rebased on 4.1-rc1 can write the nand boot parts and the brom / spl can
 load
 the spl / resp. u-boot.bin from there (on a cubieboard2).

>>> You're right... I did spot this, but assumed this was my own mistake in
>>> merging these patches with our 4.0RC7 tree. Sorry, could have saved you
>>> some trouble if I were sh

Re: [U-Boot] [PATCH v2 22/22] x86: Add support for Intel Minnowboard Max

2015-05-26 Thread Andrew Bradford

Hi Simon and Bin (sorry for bringing this back from the dead),

But I have a question about fsp_configs.c down below:

On 01/27 22:13, Simon Glass wrote:
->8---
> diff --git a/arch/x86/cpu/baytrail/fsp_configs.c 
> b/arch/x86/cpu/baytrail/fsp_configs.c
> new file mode 100644
> index 000..86b6926
> --- /dev/null
> +++ b/arch/x86/cpu/baytrail/fsp_configs.c
> @@ -0,0 +1,156 @@
> +/*
> + * Copyright (C) 2013, Intel Corporation
> + * Copyright (C) 2014, Bin Meng 
> + *
> + * SPDX-License-Identifier:  Intel
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +/* ALC262 Verb Table - 10EC0262 */
> +static const uint32_t verb_table_data13[] = {
> + /* Pin Complex (NID 0x11) */
> + 0x01171cf0,
> + 0x01171d11,
> + 0x01171e11,
> + 0x01171f41,
> + /* Pin Complex (NID 0x12) */
> + 0x01271cf0,
> + 0x01271d11,
> + 0x01271e11,
> + 0x01271f41,
> + /* Pin Complex (NID 0x14) */
> + 0x01471c10,
> + 0x01471d40,
> + 0x01471e01,
> + 0x01471f01,
> + /* Pin Complex (NID 0x15) */
> + 0x01571cf0,
> + 0x01571d11,
> + 0x01571e11,
> + 0x01571f41,
> + /* Pin Complex (NID 0x16) */
> + 0x01671cf0,
> + 0x01671d11,
> + 0x01671e11,
> + 0x01671f41,
> + /* Pin Complex (NID 0x18) */
> + 0x01871c20,
> + 0x01871d98,
> + 0x01871ea1,
> + 0x01871f01,
> + /* Pin Complex (NID 0x19) */
> + 0x01971c21,
> + 0x01971d98,
> + 0x01971ea1,
> + 0x01971f02,
> + /* Pin Complex (NID 0x1A) */
> + 0x01a71c2f,
> + 0x01a71d30,
> + 0x01a71e81,
> + 0x01a71f01,
> + /* Pin Complex */
> + 0x01b71c1f,
> + 0x01b71d40,
> + 0x01b71e21,
> + 0x01b71f02,
> + /* Pin Complex */
> + 0x01c71cf0,
> + 0x01c71d11,
> + 0x01c71e11,
> + 0x01c71f41,
> + /* Pin Complex */
> + 0x01d71c01,
> + 0x01d71dc6,
> + 0x01d71e14,
> + 0x01d71f40,
> + /* Pin Complex */
> + 0x01e71cf0,
> + 0x01e71d11,
> + 0x01e71e11,
> + 0x01e71f41,
> + /* Pin Complex */
> + 0x01f71cf0,
> + 0x01f71d11,
> + 0x01f71e11,
> + 0x01f71f41,
> +};
> +
> +/*
> + * This needs to be in ROM since if we put it in CAR, FSP init loses it when
> + * it drops CAR.
> + *
> + * TODO(s...@chromium.org): Move to device tree when FSP allows it
> + *
> + * VerbTable: (RealTek ALC262)
> + * Revision ID = 0xFF, support all steps
> + * Codec Verb Table For AZALIA
> + * Codec Address: CAd value (0/1/2)
> + * Codec Vendor: 0x10EC0262
> + */
> +static const struct pch_azalia_verb_table azalia_verb_table[] = {
> + {
> + {
> + 0x10ec0262,
> + 0x,
> + 0xff,
> + 0x01,
> + 0x000b,
> + 0x0002,
> + },
> + verb_table_data13
> + }
> +};
> +
> +const struct pch_azalia_config azalia_config = {
> + .pme_enable = 1,
> + .docking_supported = 1,
> + .docking_attached = 0,
> + .hdmi_codec_enable = 1,
> + .azalia_v_ci_enable = 1,
> + .rsvdbits = 0,
> + .azalia_verb_table_num = 1,
> + .azalia_verb_table = azalia_verb_table,
> + .reset_wait_timer_us = 300
> +};
> +
> +void update_fsp_upd(struct upd_region *fsp_upd)
> +{
> + struct memory_down_data *mem;
> +
> + /*
> +  * Configure everything here to avoid the poor hard-pressed user
> +  * needing to run Intel's binary configuration tool. It may also allow
> +  * us to support the 1GB single core variant easily.
> +  *
> +  * TODO(s...@chromium.org): Move to device tree
> +  */
> + fsp_upd->mrc_init_tseg_size = 8;
> + fsp_upd->mrc_init_mmio_size = 0x800;
> + fsp_upd->emmc_boot_mode = 0xff;
> + fsp_upd->enable_sdio = 1;
> + fsp_upd->enable_sdcard = 1;
> + fsp_upd->enable_hsuart0 = 1;
> + fsp_upd->azalia_config_ptr = (uint32_t)&azalia_config;
> + fsp_upd->enable_i2_c0 = 0;
> + fsp_upd->enable_i2_c2 = 0;
> + fsp_upd->enable_i2_c3 = 0;
> + fsp_upd->enable_i2_c4 = 0;
> + fsp_upd->enable_xhci = 0;
> + fsp_upd->igd_render_standby = 1;
> +
> + mem = &fsp_upd->memory_params;
> + mem->enable_memory_down = 1;
> + mem->dram_speed = 1;
> + mem->dimm_width = 1;
> + mem->dimm_density = 2;
> + mem->dimm_tcl = 0xb;
> + mem->dimm_trpt_rcd = 0xb;
> + mem->dimm_twr = 0xc;
> + mem->dimm_twtr = 6;
> + mem->dimm_trrd = 6;
> + mem->dimm_trtp = 6;
> + mem->dimm_tfaw = 0x14;
> +}

I am trying to move this fsp upd to use device tree as I am trying to
create a patch set to add the Intel Valley Island E38xx board (which
uses a SODIMM rather than memory down).  In doing so, I've found that
global data doesn't seem to be available when update_fsp_upd() is called
and generally it seems that gd->fdt_blob is used to get a reference to
the flattened device tree.

I'm not super familiar with device tree, but I was attempting to use
fdtdec_

Re: [U-Boot] [PATCH v2] wandboard: Add board revision detection support

2015-05-26 Thread Alexander Holler


Am 25.05.2015 um 11:41 schrieb Wolfgang Denk:

Dear Fabio,

In message  
you wrote:


"If the gpio command would be enabled, it would even be possible to reset the
BRCM- WLAN and Bluetooth modules by just adding some stuff to uEnv.txt."

This sounds like a real hack for me, sorry.


Consider it as an example for being able to do many different things
that have not even been thought of at the time of implementations. to
try out things.  Maybe we decide later to implement the features a C
code, but for testing or working aound problems is is always nice to
have scripting capabilities.


Exactly. It's just another example besides the possibility to choose the 
correct dtb based on the board revision without modifying u-boot at all 
(if gpio would be enabled). And also the example is a hack, that's the 
stuff which is necessary very often, until someone fixes something in a 
driver (and managed it to get the fix upstream), or even to circumvent 
problems with some HW.


Btw., in regard to the above specific hack, the same problem (failure to 
upload firmware because it's already uploaded) exists for Bluetooth too. 
Personally I've modified (hacked) the wandboard-rfkill-driver a year ago 
to disable the regulator of the brcm-module completely for some 
milliseconds at startup (and when the module is unloaded, to save 
power). But that involves having to manage own patches for the kernel, 
so I might even prefer to use just a hack in uEnv.txt to fix the reset 
problem with the brcm-module.


Besides that I don't really care what a maintainer said to some previous 
similiar problem. Maintainers are humans too, maybe he just had 
forgotten about the gpio-command.


Regards,

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

Re: [U-Boot] [PATCH] net: Fix NET_RANDOM_ETHADDR dependencies

On Mon, May 25, 2015 at 4:37 AM, Michal Simek  wrote:
> NET_RANDOM_ETHADDR depends on lib/rand.c. This patch adds dependency to
> Kconfig to ensure that library is also compiled.
>
> Signed-off-by: Michal Simek 
> ---

Applied to u-boot-net, thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sparc: fix build error on gr_ep2s60 board

On Mon, May 25, 2015 at 8:58 PM, Masahiro Yamada
 wrote:
> Commit 92ac52082140 (net: Remove all references to CONFIG_ETHADDR
> and friends) accidentally dropped #endif.  Since then, gr_ep2s60
> could not build.
>
> scripts/kconfig/conf --silentoldconfig Kconfig
>   CHK include/config.h
>   GEN include/autoconf.mk
> In file included from include/config.h:5:0,
>  from ./include/common.h:18:
> include/configs/gr_ep2s60.h:15:0: error: unterminated #ifndef
>  #ifndef __CONFIG_H__
>  ^
> make[1]: *** [include/autoconf.mk] Error 1
>
> Signed-off-by: Masahiro Yamada 
> ---

Applied to u-boot-net, thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] blackfin: fix build error on bct-brettl2 board

On Mon, May 25, 2015 at 10:42 PM, Masahiro Yamada
 wrote:
> Commit 76ec988b062e (net: Remove all calls to net_random_ethaddr())
> accidentally deleted CONFIG_TARGET_BCT_BRETTL2=y, and since then
> bct-brettl2 would not build.
>
> Since commit a26cd04920dc (arch: Make board selection choices
> optional), Kconfig actually allows such a .config file in which no
> board is selected, but the build never succeeds.
>
> Signed-off-by: Masahiro Yamada 
> ---

Applied to u-boot-net, thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 4/5] imx: ventana: hang if board model could not be determined

If the EEPROM could not be read or is corrupt we always want to hang.
Note that an error message will have been displayed by read_eeprom in this
case.

Signed-off-by: Tim Harvey 
---
 board/gateworks/gw_ventana/gw_ventana_spl.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/board/gateworks/gw_ventana/gw_ventana_spl.c 
b/board/gateworks/gw_ventana/gw_ventana_spl.c
index 9f5d2b1..d4418e5 100644
--- a/board/gateworks/gw_ventana/gw_ventana_spl.c
+++ b/board/gateworks/gw_ventana/gw_ventana_spl.c
@@ -515,10 +515,8 @@ void board_init_f(ulong dummy)
setup_iomux_gpio(board_model, &ventana_info);
 
/* provide some some default: 32bit 128MB */
-   if (GW_UNKNOWN == board_model) {
-   ventana_info.sdram_width = 2;
-   ventana_info.sdram_size = 3;
-   }
+   if (GW_UNKNOWN == board_model)
+   hang();
 
/* configure MMDC for SDRAM width/size and per-model calibration */
spl_dram_init(8 << ventana_info.sdram_width,
-- 
1.9.1

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

[U-Boot] [PATCH 5/5] imx: ventana: skip mtdparts fixup if no flash

This avoids an error message on NAND-less boards.

Signed-off-by: Tim Harvey 
---
 board/gateworks/gw_ventana/gw_ventana.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/board/gateworks/gw_ventana/gw_ventana.c 
b/board/gateworks/gw_ventana/gw_ventana.c
index 221069f..3b7c82b 100644
--- a/board/gateworks/gw_ventana/gw_ventana.c
+++ b/board/gateworks/gw_ventana/gw_ventana.c
@@ -811,9 +811,11 @@ int ft_board_setup(void *blob, bd_t *bd)
return 0;
}
 
-   /* Update partition nodes using info from mtdparts env var */
-   puts("   Updating MTD partitions...\n");
-   fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes));
+   if (test_bit(EECONFIG_NAND, info->config)) {
+   /* Update partition nodes using info from mtdparts env var */
+   puts("   Updating MTD partitions...\n");
+   fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes));
+   }
 
/* Update display timings from display env var */
if (display) {
-- 
1.9.1

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

[U-Boot] [PATCH 3/5] imx: ventana: make fdt_file1 and fdt_file2 automatic and non-overridable

The fdt_file1 and fdt_file2 vars provide fallbacks for the fdt file loading
script. There is no need to allow the user to override these as if they
want to specify the fdt, they should do so in the first attempt which is
the fdt_file var.

Signed-off-by: Tim Harvey 
---
 board/gateworks/gw_ventana/gw_ventana.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/board/gateworks/gw_ventana/gw_ventana.c 
b/board/gateworks/gw_ventana/gw_ventana.c
index e3737d1..221069f 100644
--- a/board/gateworks/gw_ventana/gw_ventana.c
+++ b/board/gateworks/gw_ventana/gw_ventana.c
@@ -695,18 +695,14 @@ int misc_init_r(void)
*p++ = 0;
 
setenv("model_base", str);
-   if (!getenv("fdt_file1")) {
-   sprintf(fdt, "%s-%s.dtb", cputype, str);
-   setenv("fdt_file1", fdt);
-   }
+   sprintf(fdt, "%s-%s.dtb", cputype, str);
+   setenv("fdt_file1", fdt);
if (board_type != GW551x && board_type != GW552x)
str[4] = 'x';
str[5] = 'x';
str[6] = 0;
-   if (!getenv("fdt_file2")) {
-   sprintf(fdt, "%s-%s.dtb", cputype, str);
-   setenv("fdt_file2", fdt);
-   }
+   sprintf(fdt, "%s-%s.dtb", cputype, str);
+   setenv("fdt_file2", fdt);
}
 
/* initialize env from EEPROM */
-- 
1.9.1

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

[U-Boot] [PATCH 1/5] imx: ventana: various board-specific GPIO config updates

- Added iomux for CAN_STBY and RS484_TEN (GW52xx/GW53xx/GW54xx/GW551x)
- Moved iomux of USBHUB_RST# out of board_ehci_hcd_init so that it is
  done regardless of USB being initialized in bootloader
- Added usb_sel iomux/hwconfig for GW552x
- Fixed mezzanine DIO for GW54xx
- Fixed PANLEDR# for GW54xx
- Fixed dio iomux/hwconfig for GW552x
- Fixed dio iomux for GW551x
- removed redundant #define

Signed-off-by: Tim Harvey 
---
 board/gateworks/gw_ventana/common.c | 56 +++--
 board/gateworks/gw_ventana/common.h |  6 +---
 board/gateworks/gw_ventana/gw_ventana.c | 14 -
 3 files changed, 46 insertions(+), 30 deletions(-)

diff --git a/board/gateworks/gw_ventana/common.c 
b/board/gateworks/gw_ventana/common.c
index 5fa5d6a..d406c83 100644
--- a/board/gateworks/gw_ventana/common.c
+++ b/board/gateworks/gw_ventana/common.c
@@ -191,7 +191,8 @@ static iomux_v3_cfg_t const gw52xx_gpio_pads[] = {
IOMUX_PADS(PAD_EIM_A19__GPIO2_IO19 | DIO_PAD_CFG),
/* IOEXP_IRQ# */
IOMUX_PADS(PAD_EIM_A20__GPIO2_IO18 | MUX_PAD_CTRL(IRQ_PAD_CTRL)),
-
+   /* CAN_STBY */
+   IOMUX_PADS(PAD_GPIO_9__GPIO1_IO09 | DIO_PAD_CFG),
/* MX6_LOCLED# */
IOMUX_PADS(PAD_KEY_ROW4__GPIO4_IO15 | DIO_PAD_CFG),
/* GPS_SHDN */
@@ -204,11 +205,17 @@ static iomux_v3_cfg_t const gw52xx_gpio_pads[] = {
IOMUX_PADS(PAD_ENET_TXD1__GPIO1_IO29 | DIO_PAD_CFG),
/* PCI_RST# (GW522x) */
IOMUX_PADS(PAD_EIM_D23__GPIO3_IO23 | DIO_PAD_CFG),
+   /* RS485_EN */
+   IOMUX_PADS(PAD_SD3_DAT4__GPIO7_IO01 | DIO_PAD_CFG),
/* PCIESKT_WDIS# */
IOMUX_PADS(PAD_GPIO_17__GPIO7_IO12 | DIO_PAD_CFG),
 };
 
 static iomux_v3_cfg_t const gw53xx_gpio_pads[] = {
+   /* CAN_STBY */
+   IOMUX_PADS(PAD_GPIO_2__GPIO1_IO02 | DIO_PAD_CFG),
+   /* USB_HUBRST# */
+   IOMUX_PADS(PAD_GPIO_9__GPIO1_IO09 | DIO_PAD_CFG),
/* PANLEDG# */
IOMUX_PADS(PAD_KEY_COL0__GPIO4_IO06 | DIO_PAD_CFG),
/* PANLEDR# */
@@ -227,36 +234,46 @@ static iomux_v3_cfg_t const gw53xx_gpio_pads[] = {
IOMUX_PADS(PAD_EIM_D31__GPIO3_IO31 | DIO_PAD_CFG),
/* PCI_RST# */
IOMUX_PADS(PAD_ENET_TXD1__GPIO1_IO29 | DIO_PAD_CFG),
+   /* RS485_EN */
+   IOMUX_PADS(PAD_SD3_DAT4__GPIO7_IO01 | DIO_PAD_CFG),
/* PCIESKT_WDIS# */
IOMUX_PADS(PAD_GPIO_17__GPIO7_IO12 | DIO_PAD_CFG),
 };
 
 static iomux_v3_cfg_t const gw54xx_gpio_pads[] = {
+   /* CAN_STBY */
+   IOMUX_PADS(PAD_GPIO_2__GPIO1_IO02 | DIO_PAD_CFG),
/* PANLEDG# */
IOMUX_PADS(PAD_KEY_COL0__GPIO4_IO06 | DIO_PAD_CFG),
/* PANLEDR# */
-   IOMUX_PADS(PAD_KEY_COL2__GPIO4_IO10 | DIO_PAD_CFG),
+   IOMUX_PADS(PAD_KEY_ROW0__GPIO4_IO07 | DIO_PAD_CFG),
/* MX6_LOCLED# */
IOMUX_PADS(PAD_KEY_ROW4__GPIO4_IO15 | DIO_PAD_CFG),
+   /* USB_HUBRST# */
+   IOMUX_PADS(PAD_SD1_DAT0__GPIO1_IO16 | DIO_PAD_CFG),
/* MIPI_DIO */
IOMUX_PADS(PAD_SD1_DAT3__GPIO1_IO21 | DIO_PAD_CFG),
/* RS485_EN */
IOMUX_PADS(PAD_EIM_D24__GPIO3_IO24 | DIO_PAD_CFG),
/* IOEXP_PWREN# */
-   IOMUX_PADS(PAD_KEY_ROW0__GPIO4_IO07 | DIO_PAD_CFG),
+   IOMUX_PADS(PAD_EIM_A19__GPIO2_IO19 | DIO_PAD_CFG),
/* IOEXP_IRQ# */
-   IOMUX_PADS(PAD_KEY_ROW1__GPIO4_IO09 | MUX_PAD_CTRL(IRQ_PAD_CTRL)),
+   IOMUX_PADS(PAD_EIM_A20__GPIO2_IO18 | MUX_PAD_CTRL(IRQ_PAD_CTRL)),
/* DIOI2C_DIS# */
IOMUX_PADS(PAD_GPIO_19__GPIO4_IO05 | DIO_PAD_CFG),
/* PCI_RST# */
IOMUX_PADS(PAD_ENET_TXD1__GPIO1_IO29 | DIO_PAD_CFG),
/* VID_EN */
IOMUX_PADS(PAD_EIM_D31__GPIO3_IO31 | DIO_PAD_CFG),
+   /* RS485_EN */
+   IOMUX_PADS(PAD_SD3_DAT4__GPIO7_IO01 | DIO_PAD_CFG),
/* PCIESKT_WDIS# */
IOMUX_PADS(PAD_DISP0_DAT23__GPIO5_IO17 | DIO_PAD_CFG),
 };
 
 static iomux_v3_cfg_t const gw551x_gpio_pads[] = {
+   /* CAN_STBY */
+   IOMUX_PADS(PAD_GPIO_9__GPIO1_IO09 | DIO_PAD_CFG),
/* PANLED# */
IOMUX_PADS(PAD_KEY_ROW0__GPIO4_IO07 | DIO_PAD_CFG),
/* PCI_RST# */
@@ -266,6 +283,10 @@ static iomux_v3_cfg_t const gw551x_gpio_pads[] = {
 };
 
 static iomux_v3_cfg_t const gw552x_gpio_pads[] = {
+   /* USBOTG_SEL */
+   IOMUX_PADS(PAD_GPIO_7__GPIO1_IO07 | DIO_PAD_CFG),
+   /* USB_HUBRST# */
+   IOMUX_PADS(PAD_GPIO_9__GPIO1_IO09 | DIO_PAD_CFG),
/* PANLEDG# */
IOMUX_PADS(PAD_KEY_COL0__GPIO4_IO06 | DIO_PAD_CFG),
/* PANLEDR# */
@@ -522,12 +543,6 @@ struct ventana gpio_cfg[GW_UNKNOWN] = {
.num_pads = ARRAY_SIZE(gw551x_gpio_pads)/2,
.dio_cfg = {
{
-   { IOMUX_PADS(PAD_SD1_DAT0__GPIO1_IO16) },
-   IMX_GPIO_NR(1, 16),
-   { 0, 0 },
-   0
-   },
-   {
{ IOMUX_PADS(PAD_SD1_DAT2__GPIO1_IO19) },

[U-Boot] [PATCH 2/5] imx: ventana: make model env var automatic and non-overridable

We want to model env var to always reflect what was in the EEPROM. There
is no point in allowing a user to override this.

Signed-off-by: Tim Harvey 
---
 board/gateworks/gw_ventana/gw_ventana.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/board/gateworks/gw_ventana/gw_ventana.c 
b/board/gateworks/gw_ventana/gw_ventana.c
index ae3cc84..e3737d1 100644
--- a/board/gateworks/gw_ventana/gw_ventana.c
+++ b/board/gateworks/gw_ventana/gw_ventana.c
@@ -685,8 +685,7 @@ int misc_init_r(void)
memset(str, 0, sizeof(str));
for (i = 0; i < (sizeof(str)-1) && info->model[i]; i++)
str[i] = tolower(info->model[i]);
-   if (!getenv("model"))
-   setenv("model", str);
+   setenv("model", str);
if (!getenv("fdt_file")) {
sprintf(fdt, "%s-%s.dtb", cputype, str);
setenv("fdt_file", fdt);
@@ -827,10 +826,6 @@ int ft_board_setup(void *blob, bd_t *bd)
printf("   Set display timings for %s...\n", display);
}
 
-   if (!model) {
-   puts("invalid board info: Leaving FDT fully enabled\n");
-   return 0;
-   }
printf("   Adjusting FDT per EEPROM for %s...\n", model);
 
/* board serial number */
-- 
1.9.1

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

[U-Boot] [PATCH 0/5] imx: ventana: various cleanups

Here is another series of unrelated minor fixues and cleanups for Ventana

Tim Harvey (5):
  imx: ventana: various board-specific GPIO config updates
  imx: ventana: make model env var automatic and non-overridable
  imx: ventana: make fdt_file1 and fdt_file2 automatic and
non-overridable
  imx: ventana: hang if board model could not be determined
  imx: ventana: skip mtdparts fixup if no flash

 board/gateworks/gw_ventana/common.c | 56 -
 board/gateworks/gw_ventana/common.h |  6 +---
 board/gateworks/gw_ventana/gw_ventana.c | 41 +
 board/gateworks/gw_ventana/gw_ventana_spl.c |  6 ++--
 4 files changed, 58 insertions(+), 51 deletions(-)

-- 
1.9.1

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

[U-Boot] [PATCH] imx: drop warning: unused variable 'max_freq'

max_freq in print_cpuinfo is used only with
imx6.

Signed-off-by: Stefano Babic 
---
 arch/arm/imx-common/cpu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
index 275befd..a78e0ed 100644
--- a/arch/arm/imx-common/cpu.c
+++ b/arch/arm/imx-common/cpu.c
@@ -145,11 +145,12 @@ const char *get_imx_type(u32 imxtype)
 
 int print_cpuinfo(void)
 {
-   u32 cpurev, max_freq;
+   u32 cpurev;
 
 #if defined(CONFIG_MX6) && defined(CONFIG_IMX6_THERMAL)
struct udevice *thermal_dev;
int cpu_tmp, minc, maxc, ret;
+   u32 max_freq;
 #endif
 
cpurev = get_cpu_rev();
-- 
1.9.1

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

Re: [U-Boot] [GIT PULL] Zynq changes

2015-05-26 Thread Tom Rini

On Mon, May 25, 2015 at 11:17:07AM +0200, Michal Simek wrote:

> Hi Tom,
> 
> here are 3 pending patches which were sent in merge window.
> 
> Thanks,
> Michal
> 
> The following changes since commit a84988c76d1dbca2dbe870d6b4f0ad398f287f85:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-fsl-qoriq
> (2015-05-22 17:23:15 -0400)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-microblaze.git zynq
> 
> for you to fetch changes up to 95b237ecbced8ca120c37cc284c4b2feeec8ed57:
> 
>   ARM: zynq: add default ps7_init_gpl.c/h for Zed, MicroZed, ZC70x
> (2015-05-25 10:52:36 +0200)
> 

Note:
+(zynq_zc70x) ../board/xilinx/zynq/Makefile:43: CONFIG_TARGET_ZYNQ_ZC70X is 
deprecated.
+(zynq_zc70x) ../board/xilinx/zynq/Makefile:44: Enable CONFIG_TARGET_ZYNQ_ZC702 
or CONFIG_TARGET_ZYNQ_706 instead.
+(zynq_zc70x) ../board/xilinx/zynq/Makefile:45: "make zynq_zc70x_defconfig" is 
also deprecated.
+(zynq_zc70x) ../board/xilinx/zynq/Makefile:46: Use "make zynq_zc702_defconfig" 
or "make zynq_zc706_defconfig".

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] Please pull u-boot-imx

2015-05-26 Thread Tom Rini

On Tue, May 26, 2015 at 04:18:13PM +0200, Stefano Babic wrote:

> Hi Tom,
> 
> please pull from u-boot-imx, thanks !
> 
> 
> The following changes since commit af1db4a39034ae15a91f0dae7da9548f0501febf:
> 
>   imx: ventana: use stack relocation (2015-05-15 19:25:07 +0200)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git master
> 
> for you to fetch changes up to 1022b85cb0e143b4f3a8e6c7d9258d516920d464:
> 
>   mx6: standardise CONFIG_CMD_CACHE (2015-05-26 15:58:57 +0200)
> 

Note:
w+(mx53ard,mx51evk,m53evk,mx51_efikamx,usbarmory,vision2,ima3-mx53,mx51_efikasb,mx53smd,mx53evk)
 ../arch/arm/imx-common/cpu.c: In function 'print_cpuinfo':
w+(mx53ard,mx51evk,m53evk,mx51_efikamx,usbarmory,vision2,ima3-mx53,mx51_efikasb,mx53smd,mx53evk)
 ../arch/arm/imx-common/cpu.c:148:14: warning: unused variable 'max_freq' 
[-Wunused-variable]

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

[U-Boot] Pull request: u-boot-net.git master

Hi Tom,

This fixes a few mistakes I made in the rand rework stuff.

The following changes since commit 980267a1445b7b4d8e8d05ef57799d92ba4a2ee3:

  Merge git://git.denx.de/u-boot-nand-flash (2015-05-24 21:01:30 -0400)

are available in the git repository at:


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

for you to fetch changes up to 91fed5574600142f68dac7807bc06173d1f29eb5:

  blackfin: fix build error on bct-brettl2 board (2015-05-26 12:18:42 -0500)


Joe Hershberger (1):
  net: Fix a warning added by 76ec988

Masahiro Yamada (2):
  sparc: fix build error on gr_ep2s60 board
  blackfin: fix build error on bct-brettl2 board

Michal Simek (1):
  net: Fix NET_RANDOM_ETHADDR dependencies

 board/buffalo/lsxl/lsxl.c | 2 --
 configs/bct-brettl2_defconfig | 1 +
 include/configs/gr_ep2s60.h   | 1 +
 lib/Kconfig   | 3 +++
 net/Kconfig   | 1 +
 5 files changed, 6 insertions(+), 2 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] soft-i2c and i2c-gpio issues with at91

2015-05-26 Thread Matt Wood

Thank you Simon.  Getting there, but now I get a data abort and system
reset when trying to set the i2c bus.  I need to chase this down, but if
you have any suggestions I'd appreciate it.

Below is the output of dm tree and dm uclass.

Thanks, Matt.

U-Boot> i2c dev 3
Setting bus to 3
data abort
pc : [<3ff714a0>]  lr : [<3ff7148c>]
reloc pc : [<26f194a0>]lr : [<26f1948c>]
sp : 3fb52168  ip : 001f fp : 
r10: 0003  r9 : 3fb57ee0 r8 : 3ffa5588
r7 : 3ff92ff4  r6 : 3fb581c8 r5 : 001f  r4 : 
r3 : 0001  r2 :  r1 : 8000  r0 : ea16
Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...
RomBOOT

U-Boot> dm tree
 Class   Probed   Name

 root[ + ]root_driver
 simple_bus  [   ]|-- ahb
 simple_bus  [   ]|   `-- apb
 simple_bus  [   ]|   `-- pinctrl@fc06a000
 gpio[   ]|   |-- gpio@fc06a000
 gpio[   ]|   |-- gpio@fc06b000
 gpio[   ]|   |-- gpio@fc06c000
 gpio[   ]|   `-- gpio@fc06d000
 i2c [   ]`-- gpio-i2c@1

U-Boot> dm uclass
uclass 0: root
- * root_driver @ 3fb58028, seq 0, (req -1)

Cannot find uclass for id 1: please add the UCLASS_DRIVER() declaration for
this UCLASS_... id
Cannot find uclass for id 2: please add the UCLASS_DRIVER() declaration for
this UCLASS_... id
Cannot find uclass for id 3: please add the UCLASS_DRIVER() declaration for
this UCLASS_... id
Cannot find uclass for id 4: please add the UCLASS_DRIVER() declaration for
this UCLASS_... id
Cannot find uclass for id 5: please add the UCLASS_DRIVER() declaration for
this UCLASS_... id
Cannot find uclass for id 6: please add the UCLASS_DRIVER() declaration for
this UCLASS_... id
Cannot find uclass for id 7: please add the UCLASS_DRIVER() declaration for
this UCLASS_... id
Cannot find uclass for id 8: please add the UCLASS_DRIVER() declaration for
this UCLASS_... id
uclass 9: simple_bus
-   ahb @ 3fb580a0
-   apb @ 3fb580f8
-   pinctrl@fc06a000 @ 3fb58150

uclass 10: gpio
-   gpio@fc06a000 @ 3fb581c8
-   gpio@fc06b000 @ 3fb58220
-   gpio@fc06c000 @ 3fb58278
-   gpio@fc06d000 @ 3fb582d0

Cannot find uclass for id 11: please add the UCLASS_DRIVER() declaration
for this UCLASS_... id
Cannot find uclass for id 12: please add the UCLASS_DRIVER() declaration
for this UCLASS_... id
Cannot find uclass for id 13: please add the UCLASS_DRIVER() declaration
for this UCLASS_... id
Cannot find uclass for id 14: please add the UCLASS_DRIVER() declaration
for this UCLASS_... id
Cannot find uclass for id 15: please add the UCLASS_DRIVER() declaration
for this UCLASS_... id
Cannot find uclass for id 16: please add the UCLASS_DRIVER() declaration
for this UCLASS_... id
uclass 17: i2c
-   gpio-i2c@1 @ 3fb58348, seq -1, (req 3)

uclass 18: i2c_generic
Cannot find uclass for id 19: please add the UCLASS_DRIVER() declaration
for this UCLASS_... id
Cannot find uclass for id 20: please add the UCLASS_DRIVER() declaration
for this UCLASS_... id
Cannot find uclass for id 21: please add the UCLASS_DRIVER() declaration
for this UCLASS_... id
Cannot find uclass for id 22: please add the UCLASS_DRIVER() declaration
for this UCLASS_... id
Cannot find uclass for id 23: please add the UCLASS_DRIVER() declaration
for this UCLASS_... id
Cannot find uclass for id 24: please add the UCLASS_DRIVER() declaration
for this UCLASS_... id
Cannot find uclass for id 25: please add the UCLASS_DRIVER() declaration
for this UCLASS_... id
Cannot find uclass for id 26: please add the UCLASS_DRIVER() declaration
for this UCLASS_... id
Cannot find uclass for id 27: please add the UCLASS_DRIVER() declaration
for this UCLASS_... id
Cannot find uclass for id 28: please add the UCLASS_DRIVER() declaration
for this UCLASS_... id
Cannot find uclass for id 29: please add the UCLASS_DRIVER() declaration
for this UCLASS_... id
Cannot find uclass for id 30: please add the UCLASS_DRIVER() declaration
for this UCLASS_... id
Cannot find uclass for id 31: please add the UCLASS_DRIVER() declaration
for this UCLASS_... id

On Tue, May 26, 2015 at 10:41 AM, Simon Glass  wrote:

> Hi Matt,
>
> On 26 May 2015 at 08:33, Matt Wood  wrote:
> > Hi Simon, yes I currently have i2c-gpio enabled.  Below is the output of
> > both commands.  Looks like the GPIO driver is not setup as you suspected.
> > However I'm confused on what specifically is needed to enable it.  Are
> you
> > talking about a DT entry?  In looking at other DTS files I did not see
> > anything in particular that called out GPIO.  Can you point me to what
> I'm
> > missing?
>
> Looking at the kernel device tree files it looks like the GPIO node is
> hidden inside ahb/apb/pinctrl. Since they are all compatible with
> 'simple-bus' it should still work.
>
> But you will need to create an of_match entry in at91_gpio.c. See
> s5p_gpio.c for an example. You should add the compatible ID referenced
> in the pioA nod

Re: [U-Boot] [PATCH] blackfin: fix build error on bct-brettl2 board

Hi Masahiro-san,

On Mon, May 25, 2015 at 10:42 PM, Masahiro Yamada
 wrote:
> Commit 76ec988b062e (net: Remove all calls to net_random_ethaddr())
> accidentally deleted CONFIG_TARGET_BCT_BRETTL2=y, and since then
> bct-brettl2 would not build.
>
> Since commit a26cd04920dc (arch: Make board selection choices
> optional), Kconfig actually allows such a .config file in which no
> board is selected, but the build never succeeds.
>
> Signed-off-by: Masahiro Yamada 
> ---

Acked-by: Joe Hershberger 

This too.

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

Re: [U-Boot] [PATCH] sparc: fix build error on gr_ep2s60 board

Hi Masahiro-san,

On Mon, May 25, 2015 at 8:58 PM, Masahiro Yamada
 wrote:
> Commit 92ac52082140 (net: Remove all references to CONFIG_ETHADDR
> and friends) accidentally dropped #endif.  Since then, gr_ep2s60
> could not build.
>
> scripts/kconfig/conf --silentoldconfig Kconfig
>   CHK include/config.h
>   GEN include/autoconf.mk
> In file included from include/config.h:5:0,
>  from ./include/common.h:18:
> include/configs/gr_ep2s60.h:15:0: error: unterminated #ifndef
>  #ifndef __CONFIG_H__
>  ^
> make[1]: *** [include/autoconf.mk] Error 1
>
> Signed-off-by: Masahiro Yamada 
> ---

Sorry about that.

I'll pull it in today.

Acked-by: Joe Hershberger 

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

Re: [U-Boot] [PATCH] mx6: invalidate D-cache only when booting from USB

Hi Vincent,

On 26/05/2015 17:16, Vincent wrote:
> Stefano wrote:
>> Please help me to find the use case. I searched in all i.MX6 boards in
>> mainline, but none of them is setting CONFIG_SKIP_LOWLEVEL_INIT. Can you
>> tell me on which board there is this issue ?
> 
> Hi Stefano,
> 
> Thank you for taking the time to look at this proposed patch.
> 
> You are right, this is a "non standard" use case. What I am trying to do
> is to boot u-boot with u-boot on i.MX6Q Sabre SD :)

ok - so there is a chain of u-boot, and the last one loads and starts
the kernel.

> 
> Here are more details on what I would like to do:
> 
> 1. Boot "old" u-boot from SD card.
> 2. "old" u-boot loads "new" u-boot from network with 'dhcp' command.
> 3. "old" u-boot boots "new" u-boot with 'go' command.

ok, understood what you are doing.

> This is not so easy to achieve, it seems. I learned that in this
> peculiar use case it is necessary to set CONFIG_SKIP_LOWLEVEL_INIT when
> building the "new" u-boot, as hinted by the README.

This use case can happen and I had in the past, but I confess with other
SOCs. It can be requested if U-Boot in field is outdated and a new
U-Boot is required, but updating U-Boot is dangerous, and a chain of
multiple (two) U-Boot is chosen.

Anyway, to reach the goal, you have to check the initialization
routines. CONFIG_SKIP_LOWLEVEL_INIT should ensure that the DDR
controller is not initialized twice. On imx, I guess you will have a
u-boot.imx on the board, while the "new" u-boot is in "bin" format. In
fact, you do not nned the DCD table that is parsed and applied only by
the SOC's Boot ROM.

> 
> Also I found out that the call to invalidate_dcache_all() would prevent
> the boot for the aforementioned use case. "protecting" the call (as done
> in Freescale u-boot) "repairs" my use case, and I verified that it does
> not alter the boot through USB.

Before booting the kernel, U-Boot calls "cleanup_before_linux()" to let
the SOC in a well knon state. Cache are disable at this point, and this
let the kernel doing evething with the hardware.
However, when you load U-Boot as different image, this cleanup is not
called at all. Maybe it works in your case if cleanup is called even by
loading your second u-boot and not only by starting Linux.

> 
> (boot from USB detection code)
>> This looks like a hack. I understand this can work in your case, but can
>> we set as general case ? You check power for PHY0, but what about if a
>> board is using PHY1 ?
>> Anyway, is it not possible to get the boot storage from the SRC ?
> 
> You are right, the detection code is not perfect. This is the one I
> borrowed from Freescale u-boot, though, so it is reasonably tested "in
> the field".

This cannot be generalized - maybe it does not work on all boards, even
if in your case it does the job.

> 
> About the phy0/phy1 distinction, I think we can boot only from OTG PHY0
> so no worry.
> 
> About the SRC; I am not sure you can get the desired information from
> there, as booting from USB is a ROM "fallback".
> 
> (adding a condition to cache invalidation)
>> I cannot understand well this. The correct implementation seems correct
>> to me. And if you have issues booting with USB, why are you changing the
>> behavior in all other cases *except* booting from USB, where you rely on
>> the current implementation invalidating the cache ?
> 
> In my case, it is NOT booting with USB rather, it is booting from
> another u-boot. I discovered that invalidating the caches in this case
> breaks the boot.

It should not be. And the second U-Boot should not be started with
enabled cache, as it is done now.

> 
> The current implementation invalidates the cache in all cases for i.MX6,
> as it believes it is always booting from the ROM.
> 
> As the comments hint that invalidating the caches is necessary only when
> booting from USB (from ROM), I tried to restrict a bit more the
> invalidation to this "boot from USB" case. The detection is not perfect,
> but it is enough to repair my use case, at least.
> 

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 4/4] sandbox: dts: Add the real-time-clock test nodes back in

On 22 May 2015 at 18:11, Joe Hershberger  wrote:
> On Fri, May 22, 2015 at 4:42 PM, Simon Glass  wrote:
>> These were lost when the PMIC series was applied. Add them back so that the
>> tests pass again.
>>
>> Reported-by: Joe Hershberger 
>> Signed-off-by: Simon Glass 
>> ---
>
> Acked-by: Joe Hershberger 

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

Re: [U-Boot] [PATCH] sandbox: Compile test device tree when CONFIG_UT_DM is defined

On 25 May 2015 at 11:00, Joe Hershberger  wrote:
> Hi Simon,
>
> On Sat, May 23, 2015 at 12:59 PM, Simon Glass  wrote:
>> A conflict between the PMIC and unit test work means that the sandbox test
>> device tree file is no-longer built. Fix this.
>>
>> Signed-off-by: Simon Glass 
>> ---
>
> Acked-by: Joe Hershberger 
>
> Thanks,
> -Joe

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

Re: [U-Boot] [PATCH 3/4] sandbox: dts: Sort the sandbox.dts file

On 22 May 2015 at 18:14, Joe Hershberger  wrote:
> On Fri, May 22, 2015 at 4:42 PM, Simon Glass  wrote:
>> Sort this by node name for easier browsing.
>>
>> Signed-off-by: Simon Glass 
>> ---
>
> Acked-by: Joe Hershberger 

Acked-by: Joe Hershberger 

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

Re: [U-Boot] [PATCH 1/4] dm: Sort the uclass IDs after the tegra/PMIC addition

On 22 May 2015 at 18:12, Joe Hershberger  wrote:
> On Fri, May 22, 2015 at 4:42 PM, Simon Glass  wrote:
>> Tidy up the sort order again.
>>
>> Signed-off-by: Simon Glass 
>> Reported-by: Joe Hershberger 
>> ---
>
> Acked-by: Joe Hershberger 

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

Re: [U-Boot] [PATCH 2/4] sandbox: dts: Sort the test.dts file a little

On 22 May 2015 at 18:13, Joe Hershberger  wrote:
> On Fri, May 22, 2015 at 4:42 PM, Simon Glass  wrote:
>> There are some core test nodes near the beginning of the file which should
>> be grouped together. But for other nodes, let's sort them.
>>
>> Signed-off-by: Simon Glass 
>> ---
>
> Acked-by: Joe Hershberger 

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

Re: [U-Boot] [PATCH 19/20] armv8/fsl-lsch3: Support 256M mem split for MC & dbg-srvr



On 05/18/2015 12:16 AM, Prabhakar Kushwaha wrote:
> From: Stuart Yoder 
> 
> The agreed split of the top of memory is 256M for debug server and 256M
> for MC. This patch implements the split.
> 
> In addition, the MC mem must be 512MB aligned, so the amount of memory
> to hide must be 512MB to achieve that alignment.
> 
> Signed-off-by: Stuart Yoder 
> Signed-off-by: Prabhakar Kushwaha 
> ---



> diff --git a/include/configs/ls2085a_common.h 
> b/include/configs/ls2085a_common.h
> index a33b8a9..c895291 100644
> --- a/include/configs/ls2085a_common.h
> +++ b/include/configs/ls2085a_common.h
> @@ -163,21 +163,36 @@ unsigned long long get_qixis_addr(void);
>  #define CONFIG_SYS_NAND_BASE_PHYS0x3000
>  
>  /* Debug Server firmware */
> -#define CONFIG_SYS_DEBUG_SERVER_DRAM_BLOCK_MIN_SIZE  (512UL * 1024 * 1024)
>  /* 2 sec timeout */
>  #define CONFIG_SYS_DEBUG_SERVER_TIMEOUT  (2 * 1000 * 
> 1000)
>  
>  /* MC firmware */
>  #define CONFIG_FSL_MC_ENET
> -#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE (512UL * 1024 * 1024)
>  /* TODO Actual DPL max length needs to be confirmed with the MC FW team */
>  #define CONFIG_SYS_LS_MC_DPC_MAX_LENGTH  0x2
>  #define CONFIG_SYS_LS_MC_DRAM_DPC_OFFSET0x00F0
>  #define CONFIG_SYS_LS_MC_DPL_MAX_LENGTH  0x2
>  #define CONFIG_SYS_LS_MC_DRAM_DPL_OFFSET0x00F2
>  
> -/* Carve out a DDR region which will not be used by u-boot/Linux */
> +/*
> + * Carve out a DDR region which will not be used by u-boot/Linux
> + *
> + * The default end-of-memory partitioning looks like this:
> + *
> + *   +---+ <-- top/end of memory
> + *   |256MB  |  debug server
> + *   +---+
> + *   |256MB  |  MC
> + *   +---+
> + *   | ...   |
> + *

I suggest to put this into a README file, together with the hiding memory 
mechanism.

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

Re: [U-Boot] [PATCH 17/20] driver/fsl_debug_server: Fix the DDR hide logic for LS2085a



On 05/18/2015 12:16 AM, Prabhakar Kushwaha wrote:
> From: Bhupesh Sharma 
> 
> This patch fixes the DDR hide logic for LS2085a, correcting the way
> the Debug Server FW and MC FW images are placed on the top of system
> DDR and how the rest of the system DDR space is made visibile to Linux.
> 
> Signed-off-by: Bhupesh Sharma 
> Signed-off-by: Prabhakar Kushwaha 
> ---

It would be nice to add some description in SoC README file.

York

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

Re: [U-Boot] [PATCH 08/20] armv8/ls2085a: Increase the supported kernel size



On 05/18/2015 12:13 AM, Prabhakar Kushwaha wrote:
> From: Bhupesh Sharma 
> 
> Increases the kernel size supported for LS2085A platforms:-
>  - Update environment variables
>  - Add ramdisk_size in bootargs env variable
>  - Define  CONFIG_SYS_BOOTM_LEN to 64MB
> 
> Signed-off-by: Bhupesh Sharma 
> Signed-off-by: Prabhakar Kushwaha 
> ---
>  include/configs/ls2085a_common.h | 9 ++---
>  include/configs/ls2085aqds.h | 2 +-
>  include/configs/ls2085ardb.h | 2 +-
>  3 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/include/configs/ls2085a_common.h 
> b/include/configs/ls2085a_common.h
> index 749c58d..a33b8a9 100644
> --- a/include/configs/ls2085a_common.h
> +++ b/include/configs/ls2085a_common.h
> @@ -248,13 +248,13 @@ unsigned long long get_qixis_addr(void);
>   "initrd_high=0x\0"  \
>   "kernel_start=0x58120\0"\
>   "kernel_load=0xa000\0"  \
> - "kernel_size=0x100\0"   \
> + "kernel_size=0x200\0"   \
>   "console=ttyAMA0,38400n8\0"

For my understanding, can you please explain how "kernel_size" variable is used?

York

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

Re: [U-Boot] [PATCH 07/20] armv8/ls2085rdb: Update PCA9547PW slave address



On 05/18/2015 12:08 AM, Prabhakar Kushwaha wrote:
> Primary Mux on I2C1 controller has slave address as 0x75.
> So update it's address.

s/it's/its

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

Re: [U-Boot] [PATCH 05/20] armv8/ls2085a: call ft_pcie_setup() to change dts status

Prabhakar and Minghuan,

On 05/18/2015 12:08 AM, Prabhakar Kushwaha wrote:
> From: Minghuan Lian 
> 
>  1. The patch call ft_pcie_setup() to disable PCIe dts node if
> corresponding PCIe controller is disabled according to RCW.
>  2. Fix LS2085a PCIe compatible
> 
> Signed-off-by: Minghuan Lian 
> Signed-off-by: Prabhakar Kushwaha 
> ---
>  board/freescale/ls2085a/ls2085a.c   | 4 
>  board/freescale/ls2085aqds/ls2085aqds.c | 4 
>  board/freescale/ls2085ardb/ls2085ardb.c | 4 
>  include/configs/ls2085a_common.h| 3 ++-
>  4 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/board/freescale/ls2085a/ls2085a.c 
> b/board/freescale/ls2085a/ls2085a.c
> index dd0acf2..afb99d1 100644
> --- a/board/freescale/ls2085a/ls2085a.c
> +++ b/board/freescale/ls2085a/ls2085a.c
> @@ -142,6 +142,10 @@ int ft_board_setup(void *blob, bd_t *bd)
>   fsl_mc_ldpaa_exit(bd);
>  #endif
>  
> +#ifdef CONFIG_PCI
> + ft_pcie_setup(blob, bd);
> +#endif
> +

Shouldn't this function be called from SoC function? It is not a board-dependent
setup, but rather depending on RCW which is an SoC feature.

York

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

Re: [U-Boot] [PATCH 04/20] armv8/ls2085aqds: Add support of 0x49 in ethernet

Prabhakar,


On 05/18/2015 12:08 AM, Prabhakar Kushwaha wrote:
> Add support of 0x49 SerDes protocol for ls2085aqds platform
> 

I would change the subject to "Add support of SerDes protocol 0x49". If you
want, you can put in commit message to explain what 0x49 does. Unless one is
familiar with SerDes protocols, it wouldn't be easy to link 0x49 to Ethernet.

York

> Signed-off-by: Prabhakar Kushwaha 
> ---
>  board/freescale/ls2085aqds/eth.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/board/freescale/ls2085aqds/eth.c 
> b/board/freescale/ls2085aqds/eth.c
> index 5ba4770..f32ace2 100644
> --- a/board/freescale/ls2085aqds/eth.c
> +++ b/board/freescale/ls2085aqds/eth.c
> @@ -210,6 +210,7 @@ static void initialize_dpmac_to_slot(void)
>   switch (serdes2_prtcl) {
>   case 0x07:
>   case 0x08:
> + case 0x49:
>   printf("qds: WRIOP: Supported SerDes Protocol 0x%02x\n",
>  serdes2_prtcl);
>   lane_to_slot_fsm2[0] = EMI1_SLOT4;
> @@ -247,6 +248,7 @@ void ls2085a_handle_phy_interface_sgmii(int dpmac_id)
>   switch (serdes2_prtcl) {
>   case 0x07:
>   case 0x08:
> + case 0x49:
>   lane = serdes_get_first_lane(FSL_SRDS_2, SGMII9 +
>   (dpmac_id - 9));
>   slot = lane_to_slot_fsm2[lane];
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fdt: Documentation for a few support functions aside their prototypes

Hi Paul,

On 24 May 2015 at 04:01, Paul Kocialkowski  wrote:
> This instroduces comments that explain the purpose, parameters and return 
> codes
> of a few fdt support functions, that are used to fill the fdt.

introduces

>
> Signed-off-by: Paul Kocialkowski 
> ---
>  include/fdt_support.h | 26 ++
>  1 file changed, 26 insertions(+)

Thanks for the patch.

Acked-by: Simon Glass 

>
> diff --git a/include/fdt_support.h b/include/fdt_support.h
> index 56185c9..0edc4fa 100644
> --- a/include/fdt_support.h
> +++ b/include/fdt_support.h
> @@ -16,9 +16,35 @@ u32 fdt_getprop_u32_default_node(const void *fdt, int off, 
> int cell,
> const char *prop, const u32 dflt);
>  u32 fdt_getprop_u32_default(const void *fdt, const char *path,
> const char *prop, const u32 dflt);
> +
> +/**
> + * Add data to the root of the FDT before booting the OS.
> + *
> + * See doc/device-tree-bindings/root.txt
> + *
> + * @param fdt  FDT address in memory
> + * @return 0 if ok, or -FDT_ERR_... on error
> + */
>  int fdt_root(void *fdt);
> +
> +/**
> + * Add chosen data the FDT before booting the OS.
> + *
> + * In particular, this adds the kernel command line (bootargs) to the FDT.
> + *
> + * @param fdt  FDT address in memory
> + * @return 0 if ok, or -FDT_ERR_... on error
> + */
>  int fdt_chosen(void *fdt);
> +
> +/**
> + * Add initrd information to the FDT before booting the OS.
> + *
> + * @param fdt  FDT address in memory
> + * @return 0 if ok, or -FDT_ERR_... on error
> + */
>  int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end);
> +
>  void do_fixup_by_path(void *fdt, const char *path, const char *prop,
>   const void *val, int len, int create);
>  void do_fixup_by_path_u32(void *fdt, const char *path, const char *prop,
> --
> 1.9.1
>

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

[U-Boot] [PATCH V4 3/4] sunxi: Match sun4i, sun6i, sun9i CCI definitions for NAND and DMA

V4:
- Match clock_sun9i too
- Make sure definitions for DMA gate bits are available across boards

Signed-off-by: Roy Spliet 
---
 arch/arm/include/asm/arch-sunxi/clock_sun4i.h | 4 ++--
 arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 3 +++
 arch/arm/include/asm/arch-sunxi/clock_sun9i.h | 6 +-
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun4i.h 
b/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
index c28ee05..e40d368 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
@@ -39,7 +39,7 @@ struct sunxi_ccm_reg {
u32 apb0_gate;  /* 0x68 apb0 module clock gating */
u32 apb1_gate;  /* 0x6c apb1 module clock gating */
u8 res4[0x10];
-   u32 nand_sclk_cfg;  /* 0x80 nand sub clock control */
+   u32 nand0_clk_cfg;  /* 0x80 nand sub clock control */
u32 ms_sclk_cfg;/* 0x84 memory stick sub clock control */
u32 sd0_clk_cfg;/* 0x88 sd0 clock control */
u32 sd1_clk_cfg;/* 0x8c sd1 clock control */
@@ -177,7 +177,7 @@ struct sunxi_ccm_reg {
 #define AHB_GATE_OFFSET_ACE16
 #define AHB_GATE_OFFSET_DLL15
 #define AHB_GATE_OFFSET_SDRAM  14
-#define AHB_GATE_OFFSET_NAND   13
+#define AHB_GATE_OFFSET_NAND0  13
 #define AHB_GATE_OFFSET_MS 12
 #define AHB_GATE_OFFSET_MMC3   11
 #define AHB_GATE_OFFSET_MMC2   10
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h 
b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
index 04c6d58..7ba818f 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
@@ -215,11 +215,14 @@ struct sunxi_ccm_reg {
 #define AHB_GATE_OFFSET_USB0   24
 #define AHB_GATE_OFFSET_MCTL   14
 #define AHB_GATE_OFFSET_GMAC   17
+#define AHB_GATE_OFFSET_NAND0  13
+#define AHB_GATE_OFFSET_NAND1  12
 #define AHB_GATE_OFFSET_MMC3   11
 #define AHB_GATE_OFFSET_MMC2   10
 #define AHB_GATE_OFFSET_MMC1   9
 #define AHB_GATE_OFFSET_MMC0   8
 #define AHB_GATE_OFFSET_MMC(n) (AHB_GATE_OFFSET_MMC0 + (n))
+#define AHB_GATE_OFFSET_DMA6
 #define AHB_GATE_OFFSET_SS 5
 
 /* ahb_gate1 offsets */
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun9i.h 
b/arch/arm/include/asm/arch-sunxi/clock_sun9i.h
index c506b0a..a61934f 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun9i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun9i.h
@@ -42,7 +42,7 @@ struct sunxi_ccm_reg {
u32 clk_output_b;   /* 0x184 clk_output_a */
u8 reserved5[0x278];/* 0x188 */
 
-   u32 nand0_clk_cfg0; /* 0x400 nand0 clock configuration0 */
+   u32 nand0_clk_cfg;  /* 0x400 nand0 clock configuration0 */
u32 nand0_clk_cfg1; /* 0x404 nand1 clock configuration */
u8 reserved6[0x08]; /* 0x408 */
u32 sd0_clk_cfg;/* 0x410 sd0 clock configuration */
@@ -113,8 +113,12 @@ struct sunxi_ccm_reg {
 
 /* ahb_gate0 fields */
 /* On sun9i all sdc-s share their ahb gate, so ignore (x) */
+#define AHB_GATE_OFFSET_NAND0  13
 #define AHB_GATE_OFFSET_MMC(x) 8
 
+/* ahb gate1 field */
+#define AHB_GATE_OFFSET_DMA24
+
 /* apb1_gate fields */
 #define APB1_GATE_UART_SHIFT   16
 #define APB1_GATE_UART_MASK(0xff << APB1_GATE_UART_SHIFT)
-- 
2.1.0


-- 


IMAGINE IT >> MAKE IT

Meet us online at Twitter , Facebook 
, Google+ 

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

[U-Boot] [PATCH V4 4/4] sunxi/nand: Add support for booting from internal NAND memory

From: Daniel Kochmański 

V2:
- Rename config option
- Move to separate driver
- fix DMA directly into RAM
- Many readability upgrades
- Drop R32 and W32 macros in favour of readl/writel respectively
- Use standard port controller methods for pinctl
- Make many NAND options semi-configurable

V3:
- Use proper structs and definitions for DMA and NAND
- Fix bug wrt. page size selection
- Add time-out to waits

V4:
- nand_init(): enable DMA

Signed-off-by: Roy Spliet 
---
 arch/arm/cpu/armv7/sunxi/board.c   |  12 +-
 arch/arm/include/asm/arch-sunxi/gpio.h |   2 +
 arch/arm/include/asm/arch-sunxi/nand.h |  67 
 board/sunxi/Kconfig|  12 ++
 board/sunxi/board.c|  16 ++
 drivers/mtd/nand/Makefile  |   1 +
 drivers/mtd/nand/sunxi_nand_spl.c  | 273 +
 include/configs/sun4i.h|   1 +
 include/configs/sun5i.h|   3 +
 include/configs/sun7i.h|   2 +
 include/configs/sun8i.h|   6 +
 include/configs/sunxi-common.h |  20 +++
 12 files changed, 413 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-sunxi/nand.h
 create mode 100644 drivers/mtd/nand/sunxi_nand_spl.c

diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index 6718ae2..70f413f 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -111,8 +111,10 @@ void s_init(void)
 #ifdef CONFIG_SPL_BUILD
 /* The sunxi internal brom will try to loader external bootloader
  * from mmc0, nand flash, mmc2.
- * Unfortunately we can't check how SPL was loaded so assume
- * it's always the first SD/MMC controller
+ *
+ * Unfortunately we can't check how SPL was loaded so assume it's
+ * always the first SD/MMC controller, unless it was explicitly
+ * stated that SPL is on nand flash.
  */
 u32 spl_boot_device(void)
 {
@@ -122,6 +124,12 @@ u32 spl_boot_device(void)
 * enabled build. It has many restrictions and can only boot over USB.
 */
return BOOT_DEVICE_BOARD;
+#elif defined(CONFIG_SPL_NAND_SUPPORT)
+   /*
+* This is compile time configuration informing SPL, that it
+* was loaded from nand flash.
+*/
+   return BOOT_DEVICE_NAND;
 #else
/*
 * When booting from the SD card, the "eGON.BT0" signature is expected
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h 
b/arch/arm/include/asm/arch-sunxi/gpio.h
index 59d8210..2b49616 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -156,6 +156,8 @@ enum sunxi_gpio_number {
 #define SUN4I_GPB_UART02
 #define SUN5I_GPB_UART02
 
+#define SUNXI_GPC_NAND 2
+
 #define SUNXI_GPC_SDC2 3
 #define SUN6I_GPC_SDC3 4
 
diff --git a/arch/arm/include/asm/arch-sunxi/nand.h 
b/arch/arm/include/asm/arch-sunxi/nand.h
new file mode 100644
index 000..22844d8
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/nand.h
@@ -0,0 +1,67 @@
+/*
+ * (C) Copyright 2015 Roy Spliet 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _SUNXI_NAND_H
+#define _SUNXI_NAND_H
+
+#include 
+
+struct sunxi_nand
+{
+   u32 ctl;/* 0x000 Configure and control */
+   u32 st; /* 0x004 Status information */
+   u32 intr;   /* 0x008 Interrupt control */
+   u32 timing_ctl; /* 0x00C Timing control */
+   u32 timing_cfg; /* 0x010 Timing configure */
+   u32 addr_low;   /* 0x014 Low word address */
+   u32 addr_high;  /* 0x018 High word address */
+   u32 block_num;  /* 0x01C Data block number */
+   u32 data_cnt;   /* 0x020 Data counter for transfer */
+   u32 cmd;/* 0x024 NDFC commands */
+   u32 rcmd_set;   /* 0x028 Read command set for vendor NAND mem */
+   u32 wcmd_set;   /* 0x02C Write command set */
+   u32 io_data;/* 0x030 IO data */
+   u32 ecc_ctl;/* 0x034 ECC configure and control */
+   u32 ecc_st; /* 0x038 ECC status and operation info */
+   u32 efr;/* 0x03C Enhanced feature */
+   u32 err_cnt0;   /* 0x040 Corrected error bit counter 0 */
+   u32 err_cnt1;   /* 0x044 Corrected error bit counter 1 */
+   u32 user_data[16];  /* 0x050[16] User data field */
+   u32 efnand_st;  /* 0x090 EFNAND status */
+   u32 res0[3];
+   u32 spare_area; /* 0x0A0 Spare area configure */
+   u32 pat_id; /* 0x0A4 Pattern ID register */
+   u32 rdata_sta_ctl;  /* 0x0A8 Read data status control */
+   u32 rdata_sta_0;/* 0x0AC Read data status 0 */
+   u32 rdata_sta_1;/* 0x0B0 Read data status 1 */
+   u32 res1[3];
+   u32 mdma_addr;  /* 0x0C0 MBUS DMA Address */
+   u32 mdma_cnt;   /* 0x

[U-Boot] [PATCH V4 1/4] sunxi/nand: change BLOCK_SIZE in mksunxiboot to match NAND block size

From: Daniel Kochmański 

This change is necessary to calculate correct checksum for NAND
boot. Works both for MMC and NAND. Without it BROM rejects boot image
as invalid (bad checksum). (Changes block size from 0x200 to 0x2000).

V2: Document decision in source too

Signed-off-by: Daniel Kochmański 
Signed-off-by: Roy Spliet 
Cc: Ian Campbell 
Cc: Hans De Goede 
Reviewed-by: Hans de Goede 
---
 tools/mksunxiboot.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c
index 0035f6e..3361251 100644
--- a/tools/mksunxiboot.c
+++ b/tools/mksunxiboot.c
@@ -65,7 +65,13 @@ int gen_check_sum(struct boot_file_head *head_p)
 
 #define SUN4I_SRAM_SIZE 0x7600 /* 0x7748+ is used by BROM */
 #define SRAM_LOAD_MAX_SIZE (SUN4I_SRAM_SIZE - sizeof(struct boot_file_head))
-#define BLOCK_SIZE 512
+
+/*
+ * BROM (at least on A10 and A20) requires NAND-images to be explicitly aligned
+ * to a multiple of 8K, and rejects the image otherwise. MMC-images are fine
+ * with 512B blocks. To cater for both, align to the largest of the two.
+ */
+#define BLOCK_SIZE 0x2000
 
 struct boot_img {
struct boot_file_head header;
-- 
2.1.0


-- 


IMAGINE IT >> MAKE IT

Meet us online at Twitter , Facebook 
, Google+ 

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

[U-Boot] [PATCH V4 2/4] sunxi: Add DMA definitions

Signed-off-by: Roy Spliet 
---
 arch/arm/include/asm/arch-sunxi/dma.h   | 16 +++
 arch/arm/include/asm/arch-sunxi/dma_sun4i.h | 68 +
 2 files changed, 84 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-sunxi/dma.h
 create mode 100644 arch/arm/include/asm/arch-sunxi/dma_sun4i.h

diff --git a/arch/arm/include/asm/arch-sunxi/dma.h 
b/arch/arm/include/asm/arch-sunxi/dma.h
new file mode 100644
index 000..e288f36
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/dma.h
@@ -0,0 +1,16 @@
+/*
+ * (C) Copyright 2015 Roy Spliet 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _SUNXI_DMA_H
+#define _SUNXI_DMA_H
+
+#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN7I)
+#include 
+#else
+#error "DMA definition not available for this architecture"
+#endif
+
+#endif /* _SUNXI_DMA_H */
diff --git a/arch/arm/include/asm/arch-sunxi/dma_sun4i.h 
b/arch/arm/include/asm/arch-sunxi/dma_sun4i.h
new file mode 100644
index 000..778a04b
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/dma_sun4i.h
@@ -0,0 +1,68 @@
+/*
+ * (C) Copyright 2015 Roy Spliet 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _SUNXI_DMA_SUN4I_H
+#define _SUNXI_DMA_SUN4I_H
+
+struct sunxi_dma_cfg
+{
+   u32 ctl;/* 0x00 Control */
+   u32 src_addr;   /* 0x04 Source address */
+   u32 dst_addr;   /* 0x08 Destination address */
+   u32 bc; /* 0x0C Byte counter */
+   u32 res0[2];
+   u32 ddma_para;  /* 0x18 extra parameter (dedicated DMA only) */
+   u32 res1;
+};
+
+struct sunxi_dma
+{
+   u32 irq_en; /* 0x000 IRQ enable */
+   u32 irq_pend;   /* 0x004 IRQ pending */
+   u32 auto_gate;  /* 0x008 auto gating */
+   u32 res0[61];
+   struct sunxi_dma_cfg ndma[8];   /* 0x100 Normal DMA */
+   u32 res1[64];
+   struct sunxi_dma_cfg ddma[8];   /* 0x300 Dedicated DMA */
+};
+
+enum ddma_drq_type {
+   DDMA_DST_DRQ_SRAM = 0,
+   DDMA_SRC_DRQ_SRAM = 0,
+   DDMA_DST_DRQ_SDRAM = 1,
+   DDMA_SRC_DRQ_SDRAM = 1,
+   DDMA_DST_DRQ_PATA = 2,
+   DDMA_SRC_DRQ_PATA = 2,
+   DDMA_DST_DRQ_NAND = 3,
+   DDMA_SRC_DRQ_NAND = 3,
+   DDMA_DST_DRQ_USB0 = 4,
+   DDMA_SRC_DRQ_USB0 = 4,
+   DDMA_DST_DRQ_ETHERNET_MAC_TX = 6,
+   DDMA_SRC_DRQ_ETHERNET_MAC_RX = 7,
+   DDMA_DST_DRQ_SPI1_TX = 8,
+   DDMA_SRC_DRQ_SPI1_RX = 9,
+   DDMA_DST_DRQ_SECURITY_SYS_TX = 10,
+   DDMA_SRC_DRQ_SECURITY_SYS_RX = 11,
+   DDMA_DST_DRQ_TCON0 = 14,
+   DDMA_DST_DRQ_TCON1 = 15,
+   DDMA_DST_DRQ_MSC = 23,
+   DDMA_SRC_DRQ_MSC = 23,
+   DDMA_DST_DRQ_SPI0_TX = 26,
+   DDMA_SRC_DRQ_SPI0_RX = 27,
+   DDMA_DST_DRQ_SPI2_TX = 28,
+   DDMA_SRC_DRQ_SPI2_RX = 29,
+   DDMA_DST_DRQ_SPI3_TX = 30,
+   DDMA_SRC_DRQ_SPI3_RX = 31,
+};
+
+#define SUNXI_DMA_CTL_SRC_DRQ(a)   ((a) & 0x1f)
+#define SUNXI_DMA_CTL_MODE_IO  (1 << 5)
+#define SUNXI_DMA_CTL_SRC_DATA_WIDTH_32(2 << 9)
+#define SUNXI_DMA_CTL_DST_DRQ(a)   (((a) & 0x1f) << 16)
+#define SUNXI_DMA_CTL_DST_DATA_WIDTH_32(2 << 25)
+#define SUNXI_DMA_CTL_TRIGGER  (1 << 31)
+
+#endif /* _SUNXI_DMA_SUN4I_H */
-- 
2.1.0


-- 


IMAGINE IT >> MAKE IT

Meet us online at Twitter , Facebook 
, Google+ 

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

[U-Boot] [PATCH V4] Add Sunxi NAND support to SPL

V4 slightly clarifies the gating code and is a bit more precise with
definitions for other boards. As far as I'm concerned they can be merged
now.
Happy testing,

Roy


-- 


IMAGINE IT >> MAKE IT

Meet us online at Twitter , Facebook 
, Google+ 

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

Re: [U-Boot] Proposal to add NAND-boot support for Sunxi SPL

2015-05-26 Thread Hans de Goede

Hi,

On 05/26/2015 09:34 AM, Roy Spliet wrote:

Hello Hans,

Re-sent to everybody instead of just you. Reply inline.

Op 25-05-15 om 22:39 schreef Hans de Goede:

Hi,

On 25-05-15 20:35, Hans de Goede wrote:

Hi,

On 22-05-15 09:04, Roy Spliet wrote:

Hello,

For my set-up I made use of Boris Brezillon's sunxi-nand tree[1], or actually I
rebased his patches on top of 4.0rc7. This basically adds support for NAND-chip
partitioning, ECC and randomisation. Docs for the DT specification in
Documentation/devicetree/bindings/mtd/sunxi-nand.txt , and an example can be
found in arch/arm/boot/dts/sun7i-a20-cubietruck.dts . [2] lists the acceptable
configuration options for the boot and boot_rescue partitions, make sure to
pick one of these (which should be no problem for MLC-type nand). The ECC mode
for these boot partitions is called hw_syndrome.

Assuming you now have a Linux set-up kernel based on this tree with NAND
support on an MMC, for U-boot what you should currently do is:
1) in include/configs/sunxi-common.h, adjust the parameters
PAGE_SIZE, ECC_STEP, ECC_STRENGTH to match your NAND chip
and DT configuration.
2) Build
3) Use your MMC to flash u-boot-sunxi-with-spl.bin onto NAND:
# flash_erase /dev/mtd0
# nandwrite -p /dev/mtd0 u-boot-sunxi-with-spl.bin
4) Reboot without the MMC card and see U-boot load

Ok, it took me way longer then I wanted (see below) but I've this
working now. It is cool to see u-boot load from nand :)

That should be all.

@Alex: To answer your question specifically: It's likely that the parameters in
sunxi-common.h mentioned above might not match your NAND-chip configuration in
the Linux kernel. I can't tell you precisely how to fetch these details from
the 3.4 kernel, sorry. I recall Daniel using 24-bit strength ECC with otherwise
equal parameters, but perhaps he can help you with this better than I can.

Alex, could it be that you are writing the nand using
a (rebased) version of bbrezillon's sunxi-nand-next branch ?

I started with that too because it is much newer and contains
various bug fixes, but it seems that it also contains a new
bug causing it to write the NAND in such a way that the BROM
and u-boot SPL code will not read it.

I've just pushed a rebased version of the sunxi-nand branch of
Boris here:

https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-nand-experiment

And that works for me, where as before I got the exact same errors
trying to fel load a nand enabled spl.

I'm working on merging over all the changes from the sunxi-nand-next
branch onto my working sunxi-nand-experiment branch 1 by 1 until
I find the one which causes the breakage...

Ok, so quick update the breakage was caused by this commit:

https://github.com/bbrezillon/linux-sunxi/commit/7f7324bc6170a45742352070fb45170779a3611c

When it was rebased someone (Boris I guess) forgot to remove the
"chip->read_buf(mtd, NULL, ecc->size);" line at line 1075 (after the patch) and
likewise the "chip->write_buf(mtd, buf + (i * ecc->size), ecc->size);" line at
line 1161. With these 2 lines removed the sunxi-nand-next branch from Boris,
rebased on 4.1-rc1 can write the nand boot parts and the brom / spl can load
the spl / resp. u-boot.bin from there (on a cubieboard2).

You're right... I did spot this, but assumed this was my own mistake in merging
these patches with our 4.0RC7 tree. Sorry, could have saved you some trouble if
I were sharper.

I've also tried to get this code running on a cubieboard (non 2 so A10 rather
then
A20), the SPL loads fine there (indicating that the kernel bits work), but then
I get:

U-Boot SPL 2015.07-rc1-00287-g050de86-dirty (May 25 2015 - 22:28:19)
DRAM: 1024 MiB
CPU: 100800Hz, AXI/AHB/APB: 3/2/2
Nand initialised
NAND timeout reading data
NAND timeout reading data
NAND timeout reading data
NAND timeout reading data
NAND timeout reading data
NAND timeout reading data
...

Thanks for testing this. I don't own an A10 myself, so I haven't observed this
behaviour.
First thing I would verify personally is whether all the clocks are properly configured.
Could you make U-boot print &ccm->ahb_gate0 and &ccm->nand0_clk_cfg? For the
first, bits 6 (DMA) and 13 (NAND) must be set, the second must have bit 31 set, bits 24 and
25 cleared (and otherwise, the accompanying PLL must be configured too... probably easier to
use the OSC24M), and the divide ratios set to 0 (although a small divider, like 1, shouldn't
be a problem either).
I am assuming these values should be correct, but only because BROM initialised
part of it. I am aware of the fact that the SPL driver doesn't control the DMA
gating reg and the NAND post-dividers. It might be a good idea to do so for as
long as we don't have a full DMA driver, so I'll patch that up today.

I've just tried the prelimary v4 of your patch-set from:
https://gitlab.com/turtle-solutions/u-boot/commits/sunxi-nand-wip

And the changes you've made fix these errors on the A10, good job.

Regards,

Hans
___

Re: [U-Boot] soft-i2c and i2c-gpio issues with at91