[U-Boot] Please pull u-boot-x86

2017-02-20 Thread Bin Meng
Hi Tom,

The following changes since commit 66c246cce7c66019a93ff7105157c3e2126dd277:

  ARM: DRA7xx: Fix memory allocation overflow (2017-02-17 17:24:35 -0500)

are available in the git repository at:

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

for you to fetch changes up to 308c75e08deac2933fbc63a1e9521343e710279c:

  x86: Intel MID platforms has no microcode update (2017-02-21 15:10:56 +0800)


Andy Shevchenko (2):
  x86: Introduce INTEL_MID quirk option
  x86: Intel MID platforms has no microcode update

J. Tang (1):
  x86: Force 32-bit jumps in interrupt handlers

Vincent Tinelli (1):
  x86: zImage: add Intel MID platforms support

 arch/x86/Kconfig  | 14 ++
 arch/x86/cpu/i386/interrupt.c |  2 +-
 arch/x86/cpu/mp_init.c|  3 ++-
 arch/x86/lib/zimage.c |  4 
 4 files changed, 21 insertions(+), 2 deletions(-)

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


[U-Boot] [PATCH v2 2/2] board: ge: bx50v3: apply the proper register setting to fix the voltage peak issue

2017-02-20 Thread Ken Lin
Apply the proper setting for the reserved bits in SetDes Test and System Mode 
Control register
to avoid the voltage peak issue while we do the IEEE PHY comformance test

Signed-off-by: Ken Lin 
---
Changes from v1
- New commit message

 board/ge/bx50v3/bx50v3.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
index 80b4ba1b8b..0acf655c0e 100644
--- a/board/ge/bx50v3/bx50v3.c
+++ b/board/ge/bx50v3/bx50v3.c
@@ -307,7 +307,8 @@ static int mx6_rgmii_rework(struct phy_device *phydev)
/* set debug port address: SerDes Test and System Mode Control */
phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05);
/* enable rgmii tx clock delay */
-   phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x100);
+   /* set the reserved bits to avoid board specific voltage peak issue*/
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x3D47);
 
return 0;
 }
-- 
2.11.0

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


[U-Boot] [PATCH v2 1/2] board: ge: bx50v3: fix AR8033 reset timing issue

2017-02-20 Thread Ken Lin
Add the delay (10ms) to ensure the clock is stable and to meet the 
clock-to-reset(1ms) requirement recommended in the AR8033 datasheet

Signed-off-by: Ken Lin 
---
Changes from v1
- Fix the missing Signed-off-by issue

 board/ge/bx50v3/bx50v3.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
index 2fc1144cda..80b4ba1b8b 100644
--- a/board/ge/bx50v3/bx50v3.c
+++ b/board/ge/bx50v3/bx50v3.c
@@ -103,8 +103,9 @@ static void setup_iomux_enet(void)
 
/* Reset AR8033 PHY */
gpio_direction_output(IMX_GPIO_NR(1, 28), 0);
-   udelay(500);
+   mdelay(10);
gpio_set_value(IMX_GPIO_NR(1, 28), 1);
+   mdelay(1);
 }
 
 static iomux_v3_cfg_t const usdhc2_pads[] = {
-- 
2.11.0

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


[U-Boot] saveenv not working with CONFIG_ENV_IS_IN_UBI

2017-02-20 Thread Richard Cagley
I am unable to have my uboot environment variable persist when using saveenv.

I have these configs set
#define MTDIDS_DEFAULT "nand0=xilinx_nand"
#define MTDPARTS_DEFAULT \
"mtdparts=xilinx_nand:" \
"8M(boot)ro," \
"16M(env-boot)," \
"20M(itb)," \
"-(root)"
#define CONFIG_ENV_IS_IN_UBI
#define CONFIG_ENV_UBI_PART "env-boot"
#define CONFIG_ENV_UBI_VOLUME "u-boot-env1"
#define CONFIG_ENV_UBI_VOLUME_REDUND "u-boot-env2"

Once in u-boot I do something along these lines:
mtdparts default
nand erase.part env-boot
ubi part env-boot
ubi create u-boot-env1 0x2 dynamic
ubi create u-boot-env2 0x2 dynamic
setenv foo 1
saveenv
saveenv
reset
printenv foo
## Error: "foo" not defined

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


[U-Boot] TODO list for u-boot

2017-02-20 Thread Sebastian Panceac
Hi everyone,

I was looking through the TO DO list of u-boot, because I want to
contribute to the project.

This list here seems to be outdated http://www.denx.de/wiki/U-Boot/Tasks.
For example I checked the "Set Environment to Default Values" task from the
list, and it's seems to be implemented now.
The "Group Environment Variables" TODO doesn't seem to be implemented.
Is this feature still wanted?

Is there any updated list of TODOs?

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


Re: [U-Boot] [PATCH v2 2/3] x86: zImage: add Intel MID platforms support

2017-02-20 Thread Bin Meng
On Fri, Feb 17, 2017 at 9:48 PM, Andy Shevchenko
 wrote:
> From: Vincent Tinelli 
>
> Intel MID platform boards have special treatment, such as boot parameter
> setting.
>
> Assign hardware_subarch accordingly if CONFIG_INTEL_MID is set.
>
> Reviewed-by: Bin Meng 
> Reviewed-by: Simon Glass 
> Signed-off-by: Vincent Tinelli 
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/lib/zimage.c | 4 
>  1 file changed, 4 insertions(+)
>

applied to u-boot-x86, thanks!
___
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: Intel MID platforms has no microcode update

2017-02-20 Thread Bin Meng
On Fri, Feb 17, 2017 at 9:49 PM, Andy Shevchenko
 wrote:
> There is no microcode update available for SoCs used on Intel MID
> platforms.
>
> Use conditional to bypass it.
>
> Reviewed-by: Simon Glass 
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/cpu/mp_init.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/cpu/mp_init.c b/arch/x86/cpu/mp_init.c
> index 988073cc79..4e2f000f75 100644
> --- a/arch/x86/cpu/mp_init.c
> +++ b/arch/x86/cpu/mp_init.c
> @@ -248,7 +248,7 @@ static int load_sipi_vector(atomic_t **ap_countp, int 
> num_cpus)
> if (!stack)
> return -ENOMEM;
> params->stack_top = (u32)(stack + size);
> -#if !defined(CONFIG_QEMU) && !defined(CONFIG_HAVE_FSP)
> +#if !defined(CONFIG_QEMU) && !defined(CONFIG_HAVE_FSP) && 
> !defined(CONFIG_INTEL_MID)

Fixed the "line over 80 characters" warning, and

> params->microcode_ptr = ucode_base;
> debug("Microcode at %x\n", params->microcode_ptr);
>  #endif
> --

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


Re: [U-Boot] [PATCH 07/14] net: core: Inform the user of the device MAC address

2017-02-20 Thread Olliver Schinagl

Hey Joe,

On 02-02-17 18:52, Joe Hershberger wrote:

Hi Olliver,

On Fri, Dec 2, 2016 at 4:08 AM, Olliver Schinagl  wrote:

Hey Joe,



On 30-11-16 20:29, Joe Hershberger wrote:


On Fri, Nov 25, 2016 at 9:30 AM, Olliver Schinagl 
wrote:


In certain conditions we currently print the MAC address. For example a
warning when a random mac address is in use or a missmatch between HW
and ENV.

If all things went well however (but even if there is a miss-match) we
do not inform the user what the final MAC address of the device is.

Lets print the final MAC address of the device with which it has been
setup.

Signed-off-by: Olliver Schinagl 
---
  net/eth-uclass.c | 9 ++---
  net/eth_legacy.c | 3 +++
  2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index aca3f6d..5c888b8 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -413,11 +413,12 @@ int eth_initialize(void)
 }

 bootstage_mark(BOOTSTAGE_ID_NET_ETH_INIT);
+   putc('\n');
 do {
-   if (num_devices)
-   printf(", ");
+   struct eth_pdata *pdata = dev->platdata;

-   printf("eth%d: %s", dev->seq, dev->name);
+   printf("eth%d:  %s [%pM]\n", dev->seq, dev->name,
+pdata->enetaddr);

 if (ethprime && dev == prime_dev)
 printf(" [PRIME]");
@@ -522,6 +523,8 @@ static int eth_post_probe(struct udevice *dev)
  #endif
 }

+   printf("%s ", dev->name);
+


Why this?

Can you send to the list what an example output looks like?



Absolutly. Right now I have this, with the v2 work I'm doing to print the
mac source.


Was there a v2?
I think so, I will go over my mailbox and my local commits to double 
check and send the v2 (or v3) if I missed it.



Net:   ethernet@01c5 
eth0:  ethernet@01c5 [cc:bd:d3:00:01:c6] (EEPROM)
eth1:  [] ()


If there is an error or warning from the net layer (during probe, during
init etc)
we get something like

Net:   CRC error on MAC address from EEPROM on device: ethernet@01c5
 on device: 
eth0:  ethernet@01c5 [02:4b:04:42:12:31] (driver)

(where driver is the read_rom_hwaddr hook a driver supplies).

I did not go over all error messages to print it as pretty. So in that case
it will be
Net:   Some error. ethernet@01c5

Olliver



Thanks,
-Joe


 return 0;
  }

diff --git a/net/eth_legacy.c b/net/eth_legacy.c
index 2b2c2de..bf4de37 100644
--- a/net/eth_legacy.c
+++ b/net/eth_legacy.c
@@ -178,6 +178,9 @@ int eth_write_hwaddr(struct eth_device *dev, const
char *base_name,
dev->name);
 }

+   printf("%s (eth%d) has MAC address: %pM\n",
+  dev->name, eth_number, dev->enetaddr);
+
 return ret;
  }

--
2.10.2

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




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


Re: [U-Boot] [PATCH v2 1/3] x86: Introduce INTEL_MID quirk option

2017-02-20 Thread Bin Meng
On Sat, Feb 18, 2017 at 12:21 PM, Bin Meng  wrote:
> Hi Andy,
>
> On Fri, Feb 17, 2017 at 9:48 PM, Andy Shevchenko
>  wrote:
>> Intel Mobile Internet Device (MID) platforms have special treatment in
>> some cases, such as CPU enumeration or boot parameters configuration.
>>
>> Besides that several drivers are specifically developed for the IP
>> blocks found on Intel MID platforms. Those drivers will be dependent to
>> this option.
>>
>> Here we introduce specific quirk option for such cases.
>>
>> It is supposed to be selected by Intel MID platform boards, for example,
>> Intel Edison.
>>
>> Reviewed-by: Simon Glass 
>> Signed-off-by: Andy Shevchenko 
>> ---
>>  arch/x86/Kconfig | 14 ++
>>  1 file changed, 14 insertions(+)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 5f9597b230..7abbfd8223 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -80,6 +80,20 @@ config VENDOR_INTEL
>>
>>  endchoice
>>
>> +# subarchitectures-specific options below
>> +config INTEL_MID
>> +   bool "Intel MID platform support"
>> +   ---help---
>
> nits: help to keep consistency in this file
>
>> + Select to build a kernel capable of supporting Intel MID
>
> kernel -> U-Boot
>
>> + (Mobile Internet Device) platform systems which do not have
>> + the PCI legacy interfaces.
>> +
>> + If you are building for a PC class system say N here.
>> +
>> + Intel MID platforms are based on an Intel processor and
>> + chipset which consume less power than most of the x86
>> + derivatives.
>> +
>>  # board-specific options below
>>  source "board/advantech/Kconfig"
>>  source "board/congatec/Kconfig"
>> --
>
> Reviewed-by: Bin Meng 
>
> I can fix these when applying.

Fixed these, and

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


Re: [U-Boot] [PATCH] x86: Force 32-bit jumps in interrupt handlers

2017-02-20 Thread Bin Meng
On Fri, Feb 10, 2017 at 11:46 AM, Bin Meng  wrote:
> On Fri, Feb 10, 2017 at 10:54 AM, J. Tang  wrote:
>> Depending upon the compiler used, IRQ entries could vary in sizes. With
>> GCC 5.x, the code generator will use short jumps for some IRQ entries
>> but near jumps for others. For example, GCC 5.4.0 generates the
>> following:
>>
>> $ objdump -d interrupt.o
>> 
>> 0207 :
>> 207:   6a 12   push   $0x12
>> 209:   eb 85   jmp190 
>>
>> 020b :
>> 20b:   6a 13   push   $0x13
>> 20d:   eb 81   jmp190 
>>
>> 020f :
>> 20f:   6a 14   push   $0x14
>> 211:   e9 7a ff ff ff  jmp190 
>>
>> 0216 :
>> 216:   6a 15   push   $0x15
>> 218:   e9 73 ff ff ff  jmp190 
>>
>> This causes a problem in cpu_init_interrupts(), because the IDT setup
>> assumed same sizes for all IRQ entries. GCC 4.x always generated 32-bit
>> jumps, so this previously was not a problem.
>>
>> The fix is to force 32-bit near jumps for all entries within the
>> inline assembly. This works for GCC 5.x, and 4.x was already using
>> that form of jumping.
>>
>> Signed-off-by: Jason Tang 
>> ---
>>  arch/x86/cpu/i386/interrupt.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>
> Reviewed-by: Bin Meng 

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


[U-Boot] [PATCH v4 2/3] ARM: AM43xx: Enable DM_I2C/SPI/ETH

2017-02-20 Thread Lokesh Vutla
Enable DM_I2C/SPI/ETH for all AM43XX based boards.
Enable it using imply keyword so that a user can
disable this when not needed.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-omap2/am33xx/Kconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-omap2/am33xx/Kconfig 
b/arch/arm/mach-omap2/am33xx/Kconfig
index 5b5d3f8cec..64f688de2a 100644
--- a/arch/arm/mach-omap2/am33xx/Kconfig
+++ b/arch/arm/mach-omap2/am33xx/Kconfig
@@ -114,6 +114,11 @@ config TARGET_AM43XX_EVM
bool "Support am43xx_evm"
select BOARD_LATE_INIT
select TI_I2C_BOARD_DETECT
+   imply DM_I2C
+   imply DM_SPI_FLASH
+   imply SPI_FLASH_BAR
+   imply DM_ETH
+   imply DM_SPI
help
  This option specifies support for the AM43xx
  GP and HS EVM development platforms.The AM437x
-- 
2.11.0

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


[U-Boot] [PATCH v4 1/3] ARM: dts: am43xx: Add u-boot specific dtsi

2017-02-20 Thread Lokesh Vutla
Add u-boot specific dtsi for am43xx-gp-evm so
that it will be used for SPL.

Reviewed-by: Tom Rini 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/dts/am437x-gp-evm-u-boot.dtsi | 38 ++
 1 file changed, 38 insertions(+)
 create mode 100644 arch/arm/dts/am437x-gp-evm-u-boot.dtsi

diff --git a/arch/arm/dts/am437x-gp-evm-u-boot.dtsi 
b/arch/arm/dts/am437x-gp-evm-u-boot.dtsi
new file mode 100644
index 00..885a9a92db
--- /dev/null
+++ b/arch/arm/dts/am437x-gp-evm-u-boot.dtsi
@@ -0,0 +1,38 @@
+/*
+ * Copyright (C) 2017 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ * Based on "dra7.dtsi"
+ */
+
+/{
+   ocp {
+   u-boot,dm-pre-reloc;
+   };
+};
+
+&uart0 {
+   u-boot,dm-pre-reloc;
+};
+
+&mmc1 {
+   u-boot,dm-pre-reloc;
+};
+
+&mac {
+   u-boot,dm-pre-reloc;
+};
+
+&davinci_mdio {
+   u-boot,dm-pre-reloc;
+};
+
+&cpsw_emac0 {
+   u-boot,dm-pre-reloc;
+};
+
+&phy_sel {
+   u-boot,dm-pre-reloc;
+};
-- 
2.11.0

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


[U-Boot] [PATCH v4 3/3] configs: am43xx_evm: Enable SPL_DM

2017-02-20 Thread Lokesh Vutla
Enable SPL_DM on all AM43xx based platforms

Reviewed-by: Tom Rini 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/Kconfig  | 6 ++
 configs/am43xx_evm_defconfig  | 2 +-
 configs/am43xx_evm_ethboot_defconfig  | 1 +
 configs/am43xx_evm_usbhost_boot_defconfig | 2 +-
 configs/am43xx_hs_evm_defconfig   | 2 +-
 include/configs/am43xx_evm.h  | 7 ++-
 6 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e84b74efb6..ceec643bc3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -583,6 +583,12 @@ config OMAP54XX
 config AM43XX
bool "AM43XX SoC"
select ARCH_OMAP2
+   imply SPL_SYS_MALLOC_SIMPLE
+   imply SPL_SEPARATE_BSS
+   imply SPL_OF_CONTROL
+   imply SPL_DM
+   imply SPL_DM_SEQ_ALIAS
+   imply SPL_OF_TRANSLATE
help
  Support for AM43xx SOC from Texas Instruments.
  The AM43xx high performance SOC features a Cortex-A9
diff --git a/configs/am43xx_evm_defconfig b/configs/am43xx_evm_defconfig
index 6fb2053f33..a04ba1dddb 100644
--- a/configs/am43xx_evm_defconfig
+++ b/configs/am43xx_evm_defconfig
@@ -1,5 +1,6 @@
 CONFIG_ARM=y
 CONFIG_AM43XX=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TARGET_AM43XX_EVM=y
 CONFIG_SPL_STACK_R_ADDR=0x8200
 CONFIG_SPL_YMODEM_SUPPORT=y
@@ -73,4 +74,3 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0403
 CONFIG_G_DNL_PRODUCT_NUM=0xbd00
-CONFIG_SPL_OF_LIBFDT=y
diff --git a/configs/am43xx_evm_ethboot_defconfig 
b/configs/am43xx_evm_ethboot_defconfig
index f395b6d097..66fbcd0310 100644
--- a/configs/am43xx_evm_ethboot_defconfig
+++ b/configs/am43xx_evm_ethboot_defconfig
@@ -6,6 +6,7 @@ CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND"
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
 CONFIG_SPL=y
+# CONFIG_SPL_SYS_MALLOC_SIMPLE is not set
 CONFIG_SPL_ETH_SUPPORT=y
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_NET_SUPPORT=y
diff --git a/configs/am43xx_evm_usbhost_boot_defconfig 
b/configs/am43xx_evm_usbhost_boot_defconfig
index 5775ab16dd..65824cea0e 100644
--- a/configs/am43xx_evm_usbhost_boot_defconfig
+++ b/configs/am43xx_evm_usbhost_boot_defconfig
@@ -1,5 +1,6 @@
 CONFIG_ARM=y
 CONFIG_AM43XX=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TARGET_AM43XX_EVM=y
 CONFIG_ISW_ENTRY_ADDR=0x40300350
 CONFIG_SPL_STACK_R_ADDR=0x8200
@@ -71,4 +72,3 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0403
 CONFIG_G_DNL_PRODUCT_NUM=0xbd00
-CONFIG_SPL_OF_LIBFDT=y
diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
index 6bcbfd77ed..61e2d58fc9 100644
--- a/configs/am43xx_hs_evm_defconfig
+++ b/configs/am43xx_hs_evm_defconfig
@@ -1,5 +1,6 @@
 CONFIG_ARM=y
 CONFIG_AM43XX=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TI_SECURE_DEVICE=y
 CONFIG_TARGET_AM43XX_EVM=y
 CONFIG_ISW_ENTRY_ADDR=0x403018e0
@@ -82,4 +83,3 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0403
 CONFIG_G_DNL_PRODUCT_NUM=0xbd00
-CONFIG_SPL_OF_LIBFDT=y
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index 1d622eff2f..ec99958fcd 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -18,9 +18,9 @@
 
 /* NS16550 Configuration */
 #define CONFIG_SYS_NS16550_CLK 4800
-#if defined(CONFIG_SPL_BUILD) || !defined(CONFIG_DM_SERIAL)
+#if !defined(CONFIG_SPL_DM) || !defined(CONFIG_DM_SERIAL)
+#define CONFIG_SYS_NS16550_REG_SIZE(-4)
 #define CONFIG_SYS_NS16550_SERIAL
-#define CONFIG_SYS_NS16550_REG_SIZE(-4)
 #endif
 
 /* I2C Configuration */
@@ -111,9 +111,6 @@
  * DM support in SPL
  */
 #ifdef CONFIG_SPL_BUILD
-#undef CONFIG_DM_MMC
-#undef CONFIG_DM_SPI
-#undef CONFIG_DM_SPI_FLASH
 #undef CONFIG_TIMER
 #endif
 
-- 
2.11.0

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


[U-Boot] [PATCH v4 0/3] ARM: AM43xx: Enable SPL_DM

2017-02-20 Thread Lokesh Vutla
Enable SPL_DM on all AM4xx based boards.

This series depends on:
- DRA7 SPL_DM series[1]
- http://patchwork.ozlabs.org/patch/727106/

[1] https://www.mail-archive.com/u-boot@lists.denx.de/msg238751.html

Changes sine v3:
- Use imply keyword for enabling various DM_* configs

Changes since v2:
- Adapted to use 'imply' in Kconfig

Changes since v1:
- Fixed build error with non-SPL_DM defconfigs
- Increased SYS_MALLOC_F_LEN


Lokesh Vutla (3):
  ARM: dts: am43xx: Add u-boot specific dtsi
  ARM: AM43xx: Enable DM_I2C/SPI/ETH
  configs: am43xx_evm: Enable SPL_DM

 arch/arm/Kconfig  |  6 +
 arch/arm/dts/am437x-gp-evm-u-boot.dtsi| 38 +++
 arch/arm/mach-omap2/am33xx/Kconfig|  5 
 configs/am43xx_evm_defconfig  |  2 +-
 configs/am43xx_evm_ethboot_defconfig  |  1 +
 configs/am43xx_evm_usbhost_boot_defconfig |  2 +-
 configs/am43xx_hs_evm_defconfig   |  2 +-
 include/configs/am43xx_evm.h  |  7 ++
 8 files changed, 55 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/dts/am437x-gp-evm-u-boot.dtsi

-- 
2.11.0

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


[U-Boot] [PATCH] ARM: uniphier: enable CONFIG_CMD_CONFIG

2017-02-20 Thread Masahiro Yamada
This command is useful to see which config options are enabled on
the running U-Boot image.

Signed-off-by: Masahiro Yamada 
---

 configs/uniphier_ld11_defconfig  | 1 +
 configs/uniphier_ld20_defconfig  | 1 +
 configs/uniphier_ld4_sld8_defconfig  | 1 +
 configs/uniphier_pro4_defconfig  | 1 +
 configs/uniphier_pxs2_ld6b_defconfig | 1 +
 configs/uniphier_sld3_defconfig  | 1 +
 configs/uniphier_v8_defconfig| 1 +
 7 files changed, 7 insertions(+)

diff --git a/configs/uniphier_ld11_defconfig b/configs/uniphier_ld11_defconfig
index a0aa87b..e5cfab6 100644
--- a/configs/uniphier_ld11_defconfig
+++ b/configs/uniphier_ld11_defconfig
@@ -10,6 +10,7 @@ CONFIG_DEFAULT_DEVICE_TREE="uniphier-ld11-ref"
 CONFIG_SPL=y
 CONFIG_SPL_NOR_SUPPORT=y
 CONFIG_HUSH_PARSER=y
+CONFIG_CMD_CONFIG=y
 # CONFIG_CMD_XIMG is not set
 # CONFIG_CMD_ENV_EXISTS is not set
 CONFIG_CMD_GPT=y
diff --git a/configs/uniphier_ld20_defconfig b/configs/uniphier_ld20_defconfig
index 7e3ff5c..6251359 100644
--- a/configs/uniphier_ld20_defconfig
+++ b/configs/uniphier_ld20_defconfig
@@ -10,6 +10,7 @@ CONFIG_DEFAULT_DEVICE_TREE="uniphier-ld20-ref"
 CONFIG_SPL=y
 CONFIG_SPL_NOR_SUPPORT=y
 CONFIG_HUSH_PARSER=y
+CONFIG_CMD_CONFIG=y
 # CONFIG_CMD_XIMG is not set
 # CONFIG_CMD_ENV_EXISTS is not set
 CONFIG_CMD_GPT=y
diff --git a/configs/uniphier_ld4_sld8_defconfig 
b/configs/uniphier_ld4_sld8_defconfig
index 44cf4e5..68bca19 100644
--- a/configs/uniphier_ld4_sld8_defconfig
+++ b/configs/uniphier_ld4_sld8_defconfig
@@ -12,6 +12,7 @@ CONFIG_DEFAULT_DEVICE_TREE="uniphier-ld4-ref"
 CONFIG_SPL=y
 CONFIG_SPL_NOR_SUPPORT=y
 CONFIG_HUSH_PARSER=y
+CONFIG_CMD_CONFIG=y
 CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_XIMG is not set
 # CONFIG_CMD_ENV_EXISTS is not set
diff --git a/configs/uniphier_pro4_defconfig b/configs/uniphier_pro4_defconfig
index 30be50f..fc72889 100644
--- a/configs/uniphier_pro4_defconfig
+++ b/configs/uniphier_pro4_defconfig
@@ -11,6 +11,7 @@ CONFIG_DEFAULT_DEVICE_TREE="uniphier-pro4-ref"
 CONFIG_SPL=y
 CONFIG_SPL_NOR_SUPPORT=y
 CONFIG_HUSH_PARSER=y
+CONFIG_CMD_CONFIG=y
 CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_XIMG is not set
 # CONFIG_CMD_ENV_EXISTS is not set
diff --git a/configs/uniphier_pxs2_ld6b_defconfig 
b/configs/uniphier_pxs2_ld6b_defconfig
index 00db8b0..7a358e3 100644
--- a/configs/uniphier_pxs2_ld6b_defconfig
+++ b/configs/uniphier_pxs2_ld6b_defconfig
@@ -12,6 +12,7 @@ CONFIG_DEFAULT_DEVICE_TREE="uniphier-pxs2-vodka"
 CONFIG_SPL=y
 CONFIG_SPL_NOR_SUPPORT=y
 CONFIG_HUSH_PARSER=y
+CONFIG_CMD_CONFIG=y
 CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_XIMG is not set
 # CONFIG_CMD_ENV_EXISTS is not set
diff --git a/configs/uniphier_sld3_defconfig b/configs/uniphier_sld3_defconfig
index 0be715f..ef5d1e4 100644
--- a/configs/uniphier_sld3_defconfig
+++ b/configs/uniphier_sld3_defconfig
@@ -12,6 +12,7 @@ CONFIG_DEFAULT_DEVICE_TREE="uniphier-sld3-ref"
 CONFIG_SPL=y
 CONFIG_SPL_NOR_SUPPORT=y
 CONFIG_HUSH_PARSER=y
+CONFIG_CMD_CONFIG=y
 CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_XIMG is not set
 # CONFIG_CMD_ENV_EXISTS is not set
diff --git a/configs/uniphier_v8_defconfig b/configs/uniphier_v8_defconfig
index cb972b2..85f8da5 100644
--- a/configs/uniphier_v8_defconfig
+++ b/configs/uniphier_v8_defconfig
@@ -7,6 +7,7 @@ CONFIG_SYS_TEXT_BASE=0x8400
 CONFIG_DEFAULT_DEVICE_TREE="uniphier-ld20-ref"
 # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
 CONFIG_HUSH_PARSER=y
+CONFIG_CMD_CONFIG=y
 # CONFIG_CMD_XIMG is not set
 # CONFIG_CMD_ENV_EXISTS is not set
 CONFIG_CMD_GPT=y
-- 
2.7.4

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


Re: [U-Boot] [PATCH v4 0/16] sunxi: Add support for the CHIP Pro

2017-02-20 Thread Jagan Teki
On Mon, Jan 23, 2017 at 7:16 PM, Maxime Ripard
 wrote:
> The CHIP Pro is a SoM made by NextThing Co, and that embeds a GR8 SIP, an
> AXP209 PMIC, a WiFi BT chip and a 512MB SLC NAND.
>
> Since the first Allwinner device coming whit an SLC NAND that doesn't have
> the shortcomings (and breakages) the MLC NAND has, we can finally enable
> the NAND support on a board by default.
>
> This is the occasion to introduce a bunch of additions needed imo to be
> able to come up with a sane NAND support for our users.
>
> The biggest pain point is that the BROM uses a different ECC and randomizer
> configuration than for the rest of the NAND. In order to lessen the number
> of bitflips, you also need to pad with random data the SPL image.
>
> Since it's quite tedious to do right (and most users won't be able to
> figure it out) and since if it is not done right, it will eventually turn
> into an unusable system (which is bad UX), we think that the best solution
> is to generate an SPL image that already embeds all this. We'll possible
> have to do the same thing for the U-Boot image (at least for the random
> padding) on MLC NANDs.
>
> The only drawback from that is that you need to flash it raw, instead of
> using the usual nand write, but it's just a different command, nothing
> major anyway.
>
> In order to flash it, from a device switched in FEL, on your host:
> sunxi-fel spl spl/sunxi-spl.bin
> sunxi-fel write 0x4a00 u-boot-dtb.bin
> sunxi-fel write 0x4300 spl/sunxi-spl-with-ecc.bin
> sunxi-fel exe 0x4a00
>
> And on the board, once u-boot is running (assuming the NAND is already
> erased):
>
> nand write.raw.noverify 0x4300 0 40
> nand write.raw.noverify 0x4300 0x40 40
>
> nand write 0x4a00 0x80 0xc
>
> I also encountered some weird bug in the private libgcc that prevents
> U-Boot from loading. Disabling CONFIG_USE_PRIVATE_LIBGCC fixes that.
>
> Let me know what you think,
> Maxime
>
> Changes from v3:
>   - Bring new Kconfig patches from Boris
>   - Do not define Kconfig defaults in our board Kconfig but directly in the
> option declaration
>   - Sync the DT with the kernel
>   - Fixed build breakages
>
> Changes from v2:
>   - Move CMD_NAND and CMD_UBI default to cmd/Kconfig
>   - Define the env Kconfig options only for ARCH_SUNXI to avoid build
> breakages
>   - Define CMD_MTDPARTS only for ARCH_SUNXI
>
> Changes from v1:
>   - Allowed to build lib/bch.c for the host, and used that in the image
> builder
>   - Fixed a bug in the NAND driver
>   - Wrote a documentation on how to flash a NAND image on an Allwinner
> board
>   - Fixed a few compilation breakages and issues
>   - Moved U-boot offset out of the config header and into Kconfig
>   - Moved the environment into UBI
>   - Moved the environment selection to Kconfig
>   - Moved the CMD_MTDPARTS options to Kconfig
>   - Provide MTDIDS_DEFAULT and MTDPARTS_DEFAULT options through Kconfig
>   - Added the tags from everyone
>
> Boris Brezillon (3):
>   mtd: ubi: Select RBTREE option from MTD_UBI Kconfig entry
>   cmd: Expose a Kconfig option to enable UBIFS commands
>   cmd: nand: Expose optional suboptions in Kconfig
>
> Hans de Goede (1):
>   sunxi: Enable UBI and NAND support
>
> Maxime Ripard (12):
>   nand: sunxi: Fix modulo by zero error
>   bch: Allow to build for the host
>   tools: sunxi: Add spl image builder
>   common: Move environment choice to Kconfig
>   cmd: Add Kconfig option for CMD_MTDPARTS and related options
>   mtd: sunxi: Select the U-Boot location config option
>   mtd: sunxi: Change U-Boot offset
>   sunxi: Add the default mtdids and mtdparts to our env
>   nand: sunxi: Add options for the SPL NAND configuration
>   scripts: sunxi: Build an raw SPL image
>   sunxi: Sync GR8 DTS and AXP209 with the kernel
>   sunxi: Add support for the CHIP Pro

Reviewed-by: Jagan Teki 

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


Re: [U-Boot] [PATCH v1 1/2] sun8i: define CONFIG_PHY_GIGE for EMAC

2017-02-20 Thread Chen-Yu Tsai
On Sat, Feb 18, 2017 at 1:47 AM, Philipp Tomsich
 wrote:
> From: Klaus Goger 
>
> CONFIG_PHY_GIGE needs to be defined for miiphy_speed to report correct speed.
>
> Signed-off-by: Klaus Goger 
> Signed-off-by: Philipp Tomsich 

Reviewed-by: Chen-Yu Tsai 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v1 1/2] sunxi: sun50i/a64: enabled GPIO via sunxi_gpio.c

2017-02-20 Thread Chen-Yu Tsai
On Sat, Feb 18, 2017 at 1:50 AM, Philipp Tomsich
 wrote:

Some description would be nice, such as:

The A64 has the standard Allwinner pin controller with pin banks B ~ L.

> X-AffectedPlatforms: A64-uQ7
> Signed-off-by: Philipp Tomsich 
> ---
>  drivers/gpio/sunxi_gpio.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
> index 8d2bb18..68dd9fe 100644
> --- a/drivers/gpio/sunxi_gpio.c
> +++ b/drivers/gpio/sunxi_gpio.c
> @@ -344,20 +344,26 @@ static const struct sunxi_gpio_soc_data soc_data_l_3 = {
>  static const struct udevice_id sunxi_gpio_ids[] = {
> ID("allwinner,sun4i-a10-pinctrl",   a_all),
> ID("allwinner,sun5i-a10s-pinctrl",  a_all),
> ID("allwinner,sun5i-a13-pinctrl",   a_all),
> ID("allwinner,sun6i-a31-pinctrl",   a_all),
> ID("allwinner,sun6i-a31s-pinctrl",  a_all),
> ID("allwinner,sun7i-a20-pinctrl",   a_all),
> ID("allwinner,sun8i-a23-pinctrl",   a_all),
> ID("allwinner,sun8i-a33-pinctrl",   a_all),
> ID("allwinner,sun8i-a83t-pinctrl",  a_all),
> ID("allwinner,sun8i-h3-pinctrl",a_all),
> ID("allwinner,sun9i-a80-pinctrl",   a_all),
> +   /* This is not strictly correct for the A64, as it is missing
> +* bank 'A'. Yet, the register layout in the pinctrl block is
> +* backward compatible and any accesses to the registers that
> +* normally control bank 'A' will have no adverse effect.
> +*/

This is true for all the tablet oriented SoCs (Ax3) in the list.

> +   ID("allwinner,sun50i-a64-pinctrl",  a_all),
> ID("allwinner,sun6i-a31-r-pinctrl", l_2),
> ID("allwinner,sun8i-a23-r-pinctrl", l_1),
> ID("allwinner,sun8i-a83t-r-pinctrl",l_1),
> ID("allwinner,sun8i-h3-r-pinctrl",  l_1),
> ID("allwinner,sun9i-a80-r-pinctrl", l_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 v1 02/11] sunxi: add pinctrl (UCLASS_PINCTRL) support for sunxi and tie back into GPIO

2017-02-20 Thread Chen-Yu Tsai
On Sat, Feb 18, 2017 at 1:52 AM, Philipp Tomsich
 wrote:
> This change adds a full device-model pinctrl driver for sunxi (tested with
> sun50iw1p1) based on the support available in Linux.
>
> Details are:
>  * implements a driver for pinctrl devices and assigns sun50i-a64-pinctrl
>and sun50i-a64-r-pinctrl to it
>  * defines and implements a binding for sunxi-style GPIO banks (to make it
>easier to describe controllers like the A64 which may not start at 'A')
>and provide the necessary translation mechanisms:
>- As all our gpio-reference point back to either <&pio ..> or <&r_pio ..>
>  the device framework will try to access a UCLASS_GPIO device bound to
>  the same node id as the pinctrl device to perform it's of_xlate lookup.
>  For this, we provide a 'gpiobridge' driver (which needs to access the
>  platdata of the pinctrl device) and which can then map accesses to an
>  actual GPIO bank device.
>- For the individual GPIO banks, we use a new driver (which shares most
>  of its ops with the existing sunxi_gpio driver, except probe and bind)
>  and provides configuration without any platdata structure.

Why is the new binding and driver necessary? The existing driver in U-boot is
already DM enabled and properly xlates GPIO phandles to its child GPIO banks.
I specifically fixed this in commit 4694dc56e974 ("sunxi: gpio: Add .xlate
function for gpio phandle resolution").

You are also not using the new gpiobank nodes anywhere in your dts changes.

>  * lifts and reuses the pinctrl-sunxi.h and pinctrl-sun50i-a64.c files from
>Linux (thanks to Maxime and Andre) and adds a pinctrl-sun50i-a64-r.c (to
>be picked up for inclusion into Linux again)
>
> The active DM tree at runtime (with this enabled) should look similar to
> the following:
>
>  pinctrl [ + ]|   |-- pinctrl@1c20800
>  gpio[ + ]|   |   |-- gpiob@24
>  gpio[ + ]|   |   |-- gpioc@48
>  gpio[ + ]|   |   |-- gpiod@6c
>  gpio[ + ]|   |   |-- gpioe@90
>  gpio[ + ]|   |   |-- gpiof@b4
>  gpio[ + ]|   |   |-- gpiog@d8
>  gpio[ + ]|   |   |-- gpioh@fc
>  pinconfig   [ + ]|   |   |-- uart0_pins_a
>  pinconfig   [   ]|   |   |-- uart0_pins_b
>  pinconfig   [   ]|   |   |-- uart1_2pins
>  pinconfig   [   ]|   |   |-- uart1_4pins
>  pinconfig   [   ]|   |   |-- uart2_2pins
>  pinconfig   [   ]|   |   |-- uart2_4
>  pinconfig   [   ]|   |   |-- uart3
>  pinconfig   [   ]|   |   |-- uart3_2
>  pinconfig   [   ]|   |   |-- uart3_4
>  pinconfig   [   ]|   |   |-- uart4_2
>  pinconfig   [   ]|   |   |-- uart4_4
>  pinconfig   [ + ]|   |   |-- mmc0
>  pinconfig   [ + ]|   |   |-- mmc0_cd_pin
>  pinconfig   [   ]|   |   |-- mmc1
>  pinconfig   [   ]|   |   |-- mmc2
>  pinconfig   [ + ]|   |   |-- mmc2_8bit
>  pinconfig   [   ]|   |   |-- i2c0_pins
>  pinconfig   [   ]|   |   |-- i2c1_pins
>  pinconfig   [   ]|   |   |-- i2c2_pins
>  pinconfig   [   ]|   |   |-- rmii_pins
>  pinconfig   [ + ]|   |   |-- rgmii_pins
>  pinconfig   [ + ]|   |   |-- spi0_pins
>  pinconfig   [   ]|   |   |-- spi1_pins
>  pinconfig   [ + ]|   |   |-- led_pins_sdio
>  pinconfig   [ + ]|   |   |-- ethphy_reset_pin
>  gpio[ + ]|   |   `-- gpiobridge
>  pinctrl [ + ]|   |-- pinctrl@01f02c00
>  gpio[ + ]|   |   |-- gpiol@0
>  pinconfig   [ + ]|   |   |-- led_pins_power
>  gpio[ + ]|   |   `-- gpiobridge
>
> Signed-off-by: Philipp Tomsich 
> ---
>  .../pinctrl/allwinner,pinctrl.txt  | 130 +
>  drivers/gpio/sunxi_gpio.c  |  97 +++-
>  drivers/pinctrl/Kconfig|  10 +
>  drivers/pinctrl/Makefile   |   2 +
>  drivers/pinctrl/sunxi/Makefile |  10 +
>  drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c   |  92 
>  drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c | 577 
> +
>  drivers/pinctrl/sunxi/pinctrl-sunxi.c  | 326 
>  drivers/pinctrl/sunxi/pinctrl-sunxi.h  | 311 +++
>  9 files changed, 1553 insertions(+), 2 deletions(-)
>  create mode 100644 doc/device-tree-bindings/pinctrl/allwinner,pinctrl.txt
>  create mode 100644 drivers/pinctrl/sunxi/Makefile
>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c
>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c
>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-sunxi.c
>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-sunxi.h
>
> diff --git a/doc/device-tree-bindings/pinctrl/allwinner,pinctrl.txt 
> b/doc/device-tree-bindings/pinctrl/allwinner,pinctrl.txt
> new file mode 100644
> index 000..e536ea3
> --- /

[U-Boot] [PATCHv2 1/2] pci: layerscape: add LS2088A series SoC pcie support

2017-02-20 Thread Zhiqiang Hou
From: Hou Zhiqiang 

The LS2088A series SoCs has different physical memory map address and
CCSR registers address against LS2080A series SoCs.

Signed-off-by: Hou Zhiqiang 
---
V2:
 - Moved the fix of PF control registers address to probe func.

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 46 +
 drivers/pci/pcie_layerscape.c   | 36 ++
 drivers/pci/pcie_layerscape.h   |  8 ++
 3 files changed, 90 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 335f225..6afb40f 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -89,6 +89,49 @@ static inline void early_mmu_setup(void)
set_sctlr(get_sctlr() | CR_M);
 }
 
+static void fix_final_mmu_map(void)
+{
+#ifdef CONFIG_LS2080A
+   unsigned int i;
+   u32 svr, ver;
+   struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
+
+   svr = gur_in32(&gur->svr);
+   ver = SVR_SOC_VER(svr);
+
+   /* Fix PCIE base and size for LS2088A */
+   if ((ver == SVR_LS2088A) || (ver == SVR_LS2084A) ||
+   (ver == SVR_LS2048A) || (ver == SVR_LS2044A)) {
+   for (i = 0; i < ARRAY_SIZE(final_map); i++) {
+   switch (final_map[i].phys) {
+   case CONFIG_SYS_PCIE1_PHYS_ADDR:
+   final_map[i].phys = 0x20ULL;
+   final_map[i].virt = 0x20ULL;
+   final_map[i].size = 0x8ULL;
+   break;
+   case CONFIG_SYS_PCIE2_PHYS_ADDR:
+   final_map[i].phys = 0x28ULL;
+   final_map[i].virt = 0x28ULL;
+   final_map[i].size = 0x8ULL;
+   break;
+   case CONFIG_SYS_PCIE3_PHYS_ADDR:
+   final_map[i].phys = 0x30ULL;
+   final_map[i].virt = 0x30ULL;
+   final_map[i].size = 0x8ULL;
+   break;
+   case CONFIG_SYS_PCIE4_PHYS_ADDR:
+   final_map[i].phys = 0x38ULL;
+   final_map[i].virt = 0x38ULL;
+   final_map[i].size = 0x8ULL;
+   break;
+   default:
+   break;
+   }
+   }
+   }
+#endif
+}
+
 /*
  * The final tables look similar to early tables, but different in detail.
  * These tables are in DRAM. Sub tables are added to enable cache for
@@ -105,6 +148,9 @@ static inline void final_mmu_setup(void)
int index;
 #endif
 
+   /* fix the final_map before filling in the block entries */
+   fix_final_mmu_map();
+
mem_map = final_map;
 
 #ifdef CONFIG_SYS_MEM_RESERVE_SECURE
diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 90b9fe2..f468437 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -50,6 +50,7 @@ static int ls_pcie_ltssm(struct ls_pcie *pcie)
 {
u32 state;
uint svr;
+   u32 off = 0;
 
svr = get_svr();
if (((svr >> SVR_VAR_PER_SHIFT) & SVR_LS102XA_MASK) == SVR_LS102XA) {
@@ -167,6 +168,27 @@ static void ls_pcie_setup_atu(struct ls_pcie *pcie)
pci_get_regions(pcie->bus, &io, &mem, &pref);
idx = PCIE_ATU_REGION_INDEX1 + 1;
 
+   /* Fix the pcie memory map for LS2088A series SoCs */
+   svr = (svr >> SVR_VAR_PER_SHIFT) & 0xFE;
+   if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
+   svr == SVR_LS2048A || svr == SVR_LS2044A) {
+   if (io)
+   io->phys_start = (io->phys_start &
+(PCIE_PHYS_SIZE - 1)) +
+LS2088A_PCIE1_PHYS_ADDR +
+LS2088A_PCIE_PHYS_SIZE * pcie->idx;
+   if (mem)
+   mem->phys_start = (mem->phys_start &
+(PCIE_PHYS_SIZE - 1)) +
+LS2088A_PCIE1_PHYS_ADDR +
+LS2088A_PCIE_PHYS_SIZE * pcie->idx;
+   if (pref)
+   pref->phys_start = (pref->phys_start &
+(PCIE_PHYS_SIZE - 1)) +
+LS2088A_PCIE1_PHYS_ADDR +
+LS2088A_PCIE_PHYS_SIZE * pcie->idx;
+   }
+
if (io)
/* ATU : OUTBOUND : IO */
ls_pcie_atu_outbound_set(pcie, idx++,
@@ -442,6 +464,7 @@ static int ls_pcie_probe(struct udevice *dev)
u8 he

[U-Boot] [PATCHv2 2/2] pci: layerscape: Add support ls2088a kernel DT node fixup

2017-02-20 Thread Zhiqiang Hou
From: Hou Zhiqiang 

There isn't LS2088A DT file, actually it reuse LS2080A DT file
under u-boot, while under kernel there are DT files for LS2080A
and LS2088A respectively with different PCIe node compatible
string.

Signed-off-by: Hou Zhiqiang 
---
V2:
 - no change

 drivers/pci/pcie_layerscape_fixup.c | 35 ---
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/pcie_layerscape_fixup.c 
b/drivers/pci/pcie_layerscape_fixup.c
index 19ede2f..64e461e 100644
--- a/drivers/pci/pcie_layerscape_fixup.c
+++ b/drivers/pci/pcie_layerscape_fixup.c
@@ -72,19 +72,26 @@ static void fdt_pcie_set_msi_map_entry(void *blob, struct 
ls_pcie *pcie,
u32 *prop;
u32 phandle;
int nodeoffset;
+   uint svr;
+   char *compat = NULL;
 
/* find pci controller node */
nodeoffset = fdt_node_offset_by_compat_reg(blob, "fsl,ls-pcie",
   pcie->dbi_res.start);
if (nodeoffset < 0) {
 #ifdef CONFIG_FSL_PCIE_COMPAT /* Compatible with older version of dts node */
-   nodeoffset = fdt_node_offset_by_compat_reg(blob,
-   CONFIG_FSL_PCIE_COMPAT, pcie->dbi_res.start);
+   svr = (get_svr() >> SVR_VAR_PER_SHIFT) & 0xFE;
+   if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
+   svr == SVR_LS2048A || svr == SVR_LS2044A)
+   compat = "fsl,ls2088a-pcie";
+   else
+   compat = CONFIG_FSL_PCIE_COMPAT;
+   if (compat)
+   nodeoffset = fdt_node_offset_by_compat_reg(blob,
+   compat, pcie->dbi_res.start);
+#endif
if (nodeoffset < 0)
return;
-#else
-   return;
-#endif
}
 
/* get phandle to MSI controller */
@@ -146,19 +153,25 @@ static void fdt_fixup_pcie(void *blob)
 static void ft_pcie_ls_setup(void *blob, struct ls_pcie *pcie)
 {
int off;
+   uint svr;
+   char *compat = NULL;
 
off = fdt_node_offset_by_compat_reg(blob, "fsl,ls-pcie",
pcie->dbi_res.start);
if (off < 0) {
 #ifdef CONFIG_FSL_PCIE_COMPAT /* Compatible with older version of dts node */
-   off = fdt_node_offset_by_compat_reg(blob,
-   CONFIG_FSL_PCIE_COMPAT,
-   pcie->dbi_res.start);
+   svr = (get_svr() >> SVR_VAR_PER_SHIFT) & 0xFE;
+   if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
+   svr == SVR_LS2048A || svr == SVR_LS2044A)
+   compat = "fsl,ls2088a-pcie";
+   else
+   compat = CONFIG_FSL_PCIE_COMPAT;
+   if (compat)
+   off = fdt_node_offset_by_compat_reg(blob,
+   compat, pcie->dbi_res.start);
+#endif
if (off < 0)
return;
-#else
-   return;
-#endif
}
 
if (pcie->enabled)
-- 
2.1.0.27.g96db324

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


Re: [U-Boot] [PATCH v3 2/2] mmc: tangier: Add Intel Tangier eMMC/SDHCI driver

2017-02-20 Thread Bin Meng
On Mon, Feb 20, 2017 at 7:24 PM, Andy Shevchenko
 wrote:
> From: Felipe Balbi 
>
> This patch adds Intel Tangier eMMC/SDHCI driver.
>
> Intel Tangier SoC contains a hybrid of PCI and non-PCI devices. SDHCI
> controller is one of the devices which are *not* on a PCI and, hence,
> cannot be enumerated by standard PCI means. This driver, allows for
> SDHCI controller on Tangier SoC to work in U-Boot.
>
> Signed-off-by: Vincent Tinelli 
> Signed-off-by: Felipe Balbi 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/mmc/Kconfig | 14 
>  drivers/mmc/Makefile|  1 +
>  drivers/mmc/tangier_sdhci.c | 81 
> +
>  3 files changed, 96 insertions(+)
>  create mode 100644 drivers/mmc/tangier_sdhci.c
>

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


[U-Boot] [PATCH v1 1/2] dts: lynx: add sun50i-a64-lynx.dts for the A64-uQ7

2017-02-20 Thread Philipp Tomsich
---
 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/sun50i-a64-lynx.dts | 247 +++
 2 files changed, 248 insertions(+)
 create mode 100644 arch/arm/dts/sun50i-a64-lynx.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index da99eb4..5520529 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -297,6 +297,7 @@ dtb-$(CONFIG_MACH_SUN8I_H3) += \
sun8i-h3-orangepi-plus2e.dtb \
sun8i-h3-nanopi-neo.dtb
 dtb-$(CONFIG_MACH_SUN50I) += \
+   sun50i-a64-lynx.dtb \
sun50i-a64-pine64-plus.dtb \
sun50i-a64-pine64.dtb
 dtb-$(CONFIG_MACH_SUN9I) += \
diff --git a/arch/arm/dts/sun50i-a64-lynx.dts b/arch/arm/dts/sun50i-a64-lynx.dts
new file mode 100644
index 000..f968c5f
--- /dev/null
+++ b/arch/arm/dts/sun50i-a64-lynx.dts
@@ -0,0 +1,247 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ * Copyright (c) 2016-2017, Theobroma Systems Design und Consulting GmbH
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+#include 
+
+/ {
+   model = "Theobroma Systems A64-uQ7 (Lynx)";
+   compatible = "tsd,lynx", "allwinner,sun50i-a64";
+
+   aliases {
+   serial0 = &uart0;
+   ethernet0 = &emac;
+   spi0 = &spi0;
+   spi1 = &spi1;
+   };
+
+   soc {
+   reg_vcc3v3: vcc3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   /* There is a model with 2GB of DRAM, but U-Boot fixes this for us. */
+   memory: memory@4000 {
+   reg = <0x4000 0x4000>;
+   };
+
+   config {
+   u-boot,boot-led = "lynx:orange:power";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <&led_pins_power>, <&led_pins_sdio>;
+
+   sdio {
+   label = "lynx:blue:sdio";
+   gpios = <&pio 7 10 GPIO_ACTIVE_HIGH>;
+   };
+
+   power {
+   label = "lynx:orange:power";
+   gpios = <&pio 9 11 GPIO_ACTIVE_HIGH>;
+   };
+   };
+};
+
+&pio {
+   led_pins_sdio: led_pins_sdio {
+   allwinner,pins = "PH10";
+   allwinner,function = "gpio_out";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
+   ethphy_reset_pin: ethphy_reset_pin {
+   allwinner,pins = "PD24";
+   allwinner,function = "gpio_out";
+   drive-strength = < 20 >;
+   bias-disable;
+   };
+
+   spi1_cs_pins: spi1_cs_pins {
+   allwinner,pins = "PD4";
+   allwinner,function = "gpio_out";
+   drive-st

[U-Boot] [PATCH v1 2/2] lynx_defconfig: add defconfig for A64-uQ7 module

2017-02-20 Thread Philipp Tomsich
Signed-off-by: Philipp Tomsich 
---
 arch/arm/dts/sun50i-a64-lynx.dts |  2 +-
 configs/lynx_defconfig   | 84 
 2 files changed, 85 insertions(+), 1 deletion(-)
 create mode 100644 configs/lynx_defconfig

diff --git a/arch/arm/dts/sun50i-a64-lynx.dts b/arch/arm/dts/sun50i-a64-lynx.dts
index f968c5f..bc642b9 100644
--- a/arch/arm/dts/sun50i-a64-lynx.dts
+++ b/arch/arm/dts/sun50i-a64-lynx.dts
@@ -91,7 +91,7 @@
 
power {
label = "lynx:orange:power";
-   gpios = <&pio 9 11 GPIO_ACTIVE_HIGH>;
+   gpios = <&r_pio 0 11 GPIO_ACTIVE_HIGH>;
};
};
 };
diff --git a/configs/lynx_defconfig b/configs/lynx_defconfig
new file mode 100644
index 000..7b773f1
--- /dev/null
+++ b/configs/lynx_defconfig
@@ -0,0 +1,84 @@
+CONFIG_ARM=y
+CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_MACH_SUN50I=y
+CONFIG_PINCTRL=y
+CONFIG_SUNXI_PINCTRL=y
+CONFIG_CLK=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_SUNXI=y
+CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-lynx"
+CONFIG_OF_LIST="sun50i-a64-lynx"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_CONSOLE_MUX=y
+CONFIG_SPL=y
+CONFIG_FIT=y
+CONFIG_SPL_FIT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_OF_LIBFDT=y
+# CONFIG_SPL_LIBDISK_SUPPORT is not set
+# CONFIG_SPL_POWER_SUPPORT is not set
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FPGA is not set
+CONFIG_SUN8I_EMAC=y
+CONFIG_USB_EHCI_HCD=y
+
+CONFIG_CMD_MMC=y
+CONFIG_DM_MMC=y
+CONFIG_DM_MMC_OPS=y
+# CONFIG_BLK is not set
+CONFIG_MMC_SUNXI_SLOT_EXTRA=2
+
+CONFIG_LED=y
+CONFIG_LED_GPIO=y
+
+CONFIG_CMD_I2C=y
+CONFIG_I2C0_ENABLE=y
+CONFIG_I2C1_ENABLE=y
+CONFIG_I2C2_ENABLE=y
+CONFIG_R_I2C_ENABLE=y
+
+CONFIG_DM_SPI=y
+CONFIG_SUNXI_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_FLASH=y
+
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SF_DEFAULT_BUS=0
+CONFIG_SF_DEFAULT_CS=0
+CONFIG_SF_DEFAULT_SPEED=1600
+CONFIG_SF_DEFAULT_MODE=0
+
+# Support for running the dual-role controller in device-mode
+CONFIG_USB_MUSB_GADGET=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_USB0_ID_DET="PG4"
+CONFIG_USB0_VBUS_DET="PG8"
+CONFIG_USB0_VBUS_PIN="PH11"
+
+CONFIG_G_DNL_MANUFACTURER="Theobroma Systems"
+CONFIG_G_DNL_VENDOR_NUM=0x18D1
+CONFIG_G_DNL_PRODUCT_NUM=0x4EE0
+
+# Support for USB mass storage emulation ('ums' command)
+CONFIG_CMD_USB_MASS_STORAGE=y
+
+#
+# Fastboot support
+#
+CONFIG_FASTBOOT=y
+CONFIG_USB_FUNCTION_FASTBOOT=y
+CONFIG_CMD_FASTBOOT=y
+CONFIG_ANDROID_BOOT_IMAGE=y
+CONFIG_FASTBOOT_BUF_ADDR=0x4200
+CONFIG_FASTBOOT_BUF_SIZE=0x800
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=1
+CONFIG_FASTBOOT_GPT_NAME="gpt"
+CONFIG_FASTBOOT_MBR_NAME="mbr"
-- 
1.9.1

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


[U-Boot] [PATCH v1 0/2] Add support for the A64-uQ7 modules

2017-02-20 Thread Philipp Tomsich
This changeset adds support for the A64-uQ7 modules from Theobroma
Systems, which is based on Allwinner's A64 (sun50iw1p1).

It depends on the device-model support for the sunxi subarchitecture
and the DM-based, dual-IO capable SPI driver which we submitted over
the last couple of days.

Given that these other patches are unmerged, this will (at this stage)
mainly serve as a reference point to better point these other
patchsets into perspective.


Philipp Tomsich (2):
  dts: lynx: add sun50i-a64-lynx.dts for the A64-uQ7
  lynx_defconfig: add defconfig for A64-uQ7 module

 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/sun50i-a64-lynx.dts | 247 +++
 configs/lynx_defconfig   |  84 +
 3 files changed, 332 insertions(+)
 create mode 100644 arch/arm/dts/sun50i-a64-lynx.dts
 create mode 100644 configs/lynx_defconfig

-- 
1.9.1

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


[U-Boot] [PATCH v1] DM-aware SPI driver for Allwinner SoCs

2017-02-20 Thread Philipp Tomsich
Note that this changesetdepends on the change-set for moving sunxi to
full device-model support (i.e. reset and clocking), which I sent out
last Friday...

This adds a rewrite of the SPI driver we had in use for the A31-uQ7
(sun6i), A80-Q7 (sun9i) and A64-uQ7 (sun50i) boards, which includes
support for:
 * cs-gpios (i.e. GPIOs as additional chip-selects)
 * clocking, reset and pinctrl based on the device-model
 * dual-IO data receive for controllers that support it (sun50i)

The key difference to the earlier incarnation that we provided as part
of our BSP is the removal of the legacy reset and clocking code and
added resilience to configuration errors (i.e. timeouts for the inner
loops) and converstion to the device-model. This was possible due to a
non-device-model driver now being present for use with in the SPL.

This has been verified against the A64-uQ7 with data rates up to
100MHz and dual-IO ("Fast Read Dual Output" opcode) from the on-board
SPI-NOR flash.


Philipp Tomsich (1):
  spi: sunxi_spi: Add DM SPI driver for A31/A80/A64

 drivers/spi/Kconfig |  14 ++
 drivers/spi/Makefile|   1 +
 drivers/spi/sunxi_spi.c | 571 
 3 files changed, 586 insertions(+)
 create mode 100644 drivers/spi/sunxi_spi.c

-- 
1.9.1

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


[U-Boot] [PATCH v1] spi: sunxi_spi: Add DM SPI driver for A31/A80/A64

2017-02-20 Thread Philipp Tomsich
This adds a rewrite of the SPI driver we had in use for the A31-uQ7
(sun6i), A80-Q7 (sun9i) and A64-uQ7 (sun50i) boards, which includes
support for:
 * cs-gpios (i.e. GPIOs as additional chip-selects)
 * clocking, reset and pinctrl based on the device-model
 * dual-IO data receive for controllers that support it (sun50i)

The key difference to the earlier incarnation that we provided as part
of our BSP is the removal of the legacy reset and clocking code and
added resilience to configuration errors (i.e. timeouts for the inner
loops) and converstion to the device-model. This was possible due to a
non-device-model driver now being present for use with in the SPL.

This has been verified against the A64-uQ7 with data rates up to
100MHz and dual-IO ("Fast Read Dual Output" opcode) from the on-board
SPI-NOR flash.

Signed-off-by: Philipp Tomsich 
---
 drivers/spi/Kconfig |  14 ++
 drivers/spi/Makefile|   1 +
 drivers/spi/sunxi_spi.c | 571 
 3 files changed, 586 insertions(+)
 create mode 100644 drivers/spi/sunxi_spi.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index f3f7dbe..64b6430 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -132,6 +132,20 @@ config STM32_QSPI
  used to access the SPI NOR flash chips on platforms embedding
  this ST IP core.
 
+config SUNXI_SPI
+   bool "Allwinner (sunxi) SPI driver"
+   help
+ Enable the SPI driver for Allwinner SoCs.
+
+ This driver can be used to access the SPI NOR flash on for
+ communciation with SPI peripherals platforms embedding the
+ Allwinner SoC.  This driver supports the device-model (only)
+ and has support for GPIOs as additional chip-selects.
+
+ For recent platforms (e.g. sun50i), dual-IO receive mode is
+ also supported, when configured for a SPI-NOR flash in the
+ device tree.
+
 config TEGRA114_SPI
bool "nVidia Tegra114 SPI driver"
help
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index fa9a1d2..aab31b4 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_OMAP3_SPI) += omap3_spi.o
 obj-$(CONFIG_PIC32_SPI) += pic32_spi.o
 obj-$(CONFIG_ROCKCHIP_SPI) += rk_spi.o
 obj-$(CONFIG_SANDBOX_SPI) += sandbox_spi.o
+obj-$(CONFIG_SUNXI_SPI) += sunxi_spi.o
 obj-$(CONFIG_SH_SPI) += sh_spi.o
 obj-$(CONFIG_SH_QSPI) += sh_qspi.o
 obj-$(CONFIG_STM32_QSPI) += stm32_qspi.o
diff --git a/drivers/spi/sunxi_spi.c b/drivers/spi/sunxi_spi.c
new file mode 100644
index 000..cd2cb1d
--- /dev/null
+++ b/drivers/spi/sunxi_spi.c
@@ -0,0 +1,571 @@
+/*
+ * SPI driver for Allwinner sunxi SoCs
+ *
+ * Copyright (C) 2015-2017 Theobroma Systems Design und Consulting GmbH
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include 
+#ifdef CONFIG_DM_GPIO
+#include 
+#endif
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* The SPI flash opcode for a FAST READ DUAL OUTPUT operation. */
+#define CMD_READ_DUAL_OUTPUT_FAST 0x3b
+
+struct sunxi_spi_platdata {
+   void *base;
+   unsigned int max_hz;
+
+   struct reset_ctl reset_ctl;
+   struct clk ahb_clk_gate;
+   struct clk spi_clk;
+
+   /* We could do with a single delay counter, but it won't do harm
+  to have two, as the same is the case for most other driver. */
+   uint deactivate_delay_us;   /* Delay to wait after deactivate */
+   uint activate_delay_us; /* Delay to wait after activate */
+
+#if defined(CONFIG_DM_GPIO)
+   int cs_gpios_num;
+   struct gpio_desc *cs_gpios;
+#endif
+};
+
+struct sunxi_spi_driverdata {
+   unsigned int  fifo_depth;
+};
+
+enum {
+   NONE = 0,
+   OPC_READ_DUAL_CMD,
+};
+
+struct sunxi_spi_privdata {
+   int  transaction_type;
+   ulong last_transaction_us;  /* Time of last transaction end */
+   unsigned int hz_requested;  /* last requested bitrate */
+   unsigned int hz_actual; /* currently set bitrate */
+};
+
+struct sunxi_spi_reg {
+   u8  _rsvd[0x4];
+   u32 GCR;   /* SPI Global Control register */
+   u32 TCR;   /* SPI Transfer Control register */
+   u8  _rsvd1[0x4];
+   u32 IER;   /* SPI Interrupt Control register */
+   u32 ISR;   /* SPI Interrupt Status register */
+   u32 FCR;   /* SPI FIFO Control register */
+   u32 FSR;   /* SPI FIFO Status register */
+   u32 WCR;   /* SPI Wait Clock Counter register */
+   u32 CCR;   /* SPI Clock Rate Control register */
+   u8  _rsvd2[0x8];
+   u32 MBC;   /* SPI Burst Counter register */
+   u32 MTC;   /* SPI Transmit Counter register

Re: [U-Boot] [PATCH 1/2] common: image: update boot_get_fpga to support arbitrary fpga image

2017-02-20 Thread Marek Vasut
On 02/20/2017 06:35 PM, Moritz Fischer wrote:
> Hi all,
> 
> On Mon, Feb 20, 2017 at 6:59 AM, Michal Simek  wrote:
> 
>> Definitely I am open to improve this subsystem to make it more flexible.
> 
> Over at linux-fpga ([1]) we're currently discussing the idea of coming
> up with a header
> format (vendor neutral) that we stitch onto the fpga image to allow the 
> fpga-mgr
> to derive certain features of the image from the image itself (i.e. is
> the image encrypted,
> compressed, ...).

Can you CC me on that discussion ? I think it'd be for the best to use
DT for the header format, it's documented and vendor-neutral already.

> We're trying to come up with an extensible format that would allow us
> to add stuff like
> encryption keys etc.

Nothing like a NIH format :)

> Cheers,
> 
> Moritz
> 
> 
> [1] https://patchwork.kernel.org/patch/9574399/
> 


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


Re: [U-Boot] socfpga qspi issues on SoCKit devkit

2017-02-20 Thread Marek Vasut
On 02/20/2017 05:53 PM, Rush, Jason A. wrote:
> Marek Vasut wrote:
>> On 02/20/2017 05:25 AM, Vignesh R wrote:
>>> + Marek
>>
>> Thanks, +CC Dinh and Ley
>>
>>> On Friday 17 February 2017 05:02 AM, Rush, Jason A. wrote:
 The QSPI NOR interface on the Altera Cyclone V SoCKit devkit (Rev B) 
 appears
 to be broken in the current release.  I've tracked it down to working in 
 the
 v2016.07 release, but broken in the the v2016.09 release.  With the help 
 of git
 bisect, I tracked down the commit that breaks the QSPI to the following:

   commit dac3bf20fb2c9b03476be0d73db620f62ab3cee1
   Author: Vignesh R 
   Date:   Wed Jul 6 10:20:55 2016 +0530

   spi: cadence_qspi_apb: Support 32 bit AHB address

   AHB address can be as long as 32 bit, hence remove the
   CQSPI_REG_INDIRECTRDSTARTADDR mask. Since AHB address is passed from 
 DT
   and read as u32 value, it anyway does not make sense to mask upper 
 bits.

   Signed-off-by: Vignesh R 
   Tested-by: Marek Vasut 
   Acked-by: Marek Vasut 
   Reviewed-by: Jagan Teki 

 When I try and read anything from the QSPI on the
 dac3bf20fb2c9b03476be0d73db620f62ab3cee1 commit I get a "data abort" and 
 the
 CPU resets.  Example output below is from a clean build of U-Boot 
 configured
 with socfpga_sockit_defconfig:

  => sf probe
   SF: Detected N25Q1024 with page size 256 Bytes, erase size 64 KiB, total 
 128 MiB
   => sf read 0x200 0x5 0x5000
   device 0 offset 0x5, size 0x5000
   data abort
   pc : [<3ff7a9bc>]  lr : [<3ff98359>]
   reloc pc : [<010249fc>]lr : [<01042399>]
   sp : 3bf4fde8  ip : 3ff7a371 fp : 0002
   r10:   r9 : 3bf54ee8 r8 : 3bf55530
   r7 : 270d  r6 : 0200 r5 : 5000  r4 : 3bf55530
   r3 : 0004  r2 :  r1 : 0200  r0 : ffa0
   Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
   Resetting CPU ...

 When I run the same commands with the previous commit in the git log
 (fdf02a36c52cb96717b64113775c4251ecd49596) I get the following output:

   => sf probe
   SF: Detected N25Q1024 with page size 256 Bytes, erase size 64 KiB, total 
 128 MiB
   => sf read 0x200 0x5 0x5000
   device 0 offset 0x5, size 0x5000
   SF: 20480 bytes @ 0x5 Read: OK
   =>

 I've done some investigation, and previously the ahbbase was masked so the 
 value
 0xFFA0_ results in 0x0 when writing the CQSPI_REG_INDIRECTTRIGGER 
 register.
 I assume the above commit works on some boards, but it appears to break the
 socfpga arch.

 Is there someone that could help investigate or confirm this?
>>>
>>> I am looking at cyclone5_handbook.pdf [1] and it says indaddrtrig
>>> field is 32 bit wide. So, I wonder why masking is needed. If you
>>> specify ahbbase as  0xFFA0_ in DT(reg property) then the
>>> expectation is
>>> 0xFFA0_ gets written to indaddrtrig reg. It looks like the trigger
>>> address is 0x0 and not 0xFFA0_, therefore you may have to update
>>> reg property in DT to reflect the same.
>>>
>>> [1]https://www.altera.com/en_US/pdfs/literature/hb/cyclone-v/cyclone5_
>>> handbook.pdf
>>>
> 
> I agree, according to the handbook the indaddrtrig register is 32-bits wide, 
> but
> writing the value 0xFFA0_ to indaddrtrig causes the above data abort.  It
> looks like a similar issue has been discussed before:
> http://lists.denx.de/pipermail/u-boot/2015-August/224649.html
> 
> In that proposed patch, it looks like the address to use for the indaddrtrig 
> reg
> was being separated from the ahbbase and the Altera SoC needed a value of
> 0x_.  I'm not very familiar with the Cadence device on the Altera SoC,
> but it looks like it needs a different value than the ahbbase written to the
> indaddrtrig reg.
> 
> I noticed the Cadence QSPI driver in the Linux tree has a separate
> trigger_address that is loaded from the DT, and the socfpga.dtsi sets the
> trigger_address to 0x_.

So let's just adopt the Linux bindings and get this fixed. Can you send
a patch ? Thanks

btw where did this 0xffa0_ come from, Dinh ?


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


[U-Boot] [PATCH v6 3/3] odroid-c2: enable new Meson GX MMC driver in board defconfig

2017-02-20 Thread Heiner Kallweit
Enable new Meson GX MMC driver in Odroid C2 defconfig.

Signed-off-by: Heiner Kallweit 
---
v6:
- no changes
---
 configs/odroid-c2_defconfig | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig
index 62b7627..6de712a 100644
--- a/configs/odroid-c2_defconfig
+++ b/configs/odroid-c2_defconfig
@@ -3,7 +3,9 @@ CONFIG_ARCH_MESON=y
 CONFIG_MESON_GXBB=y
 CONFIG_TARGET_ODROID_C2=y
 CONFIG_IDENT_STRING=" odroid-c2"
-# CONFIG_MMC is not set
+CONFIG_MMC=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_MESON_GX=y
 CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-odroidc2"
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
@@ -14,6 +16,7 @@ CONFIG_HUSH_PARSER=y
 # CONFIG_CMD_LOADS is not set
 # CONFIG_CMD_FPGA is not set
 # CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_MMC=y
 CONFIG_DOS_PARTITION=y
 CONFIG_ISO_PARTITION=y
 CONFIG_EFI_PARTITION=y
-- 
2.11.1


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


[U-Boot] [PATCH v6 2/3] mmc: meson: add MMC driver for Meson GX (S905)

2017-02-20 Thread Heiner Kallweit
From: Carlo Caione 
This driver implements MMC support on Meson GX (S905) based systems.
It's based on Carlo Caione's work, changes:
- BLK support added
- general refactoring

Signed-off-by: Carlo Caione 
Signed-off-by: Andreas Färber 
Signed-off-by: Heiner Kallweit 
---
v6:
- remove DM_MMC_OPS from Kconfig dependencies
- address two minor review comments of Jaehoon
---
 arch/arm/include/asm/arch-meson/sd_emmc.h |  89 +
 drivers/mmc/Kconfig   |   6 +
 drivers/mmc/Makefile  |   1 +
 drivers/mmc/meson_gx_mmc.c| 291 ++
 4 files changed, 387 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-meson/sd_emmc.h
 create mode 100644 drivers/mmc/meson_gx_mmc.c

diff --git a/arch/arm/include/asm/arch-meson/sd_emmc.h 
b/arch/arm/include/asm/arch-meson/sd_emmc.h
new file mode 100644
index 000..a09e034
--- /dev/null
+++ b/arch/arm/include/asm/arch-meson/sd_emmc.h
@@ -0,0 +1,89 @@
+/*
+ * (C) Copyright 2016 Carlo Caione 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __SD_EMMC_H__
+#define __SD_EMMC_H__
+
+#include 
+
+#define SDIO_PORT_A0
+#define SDIO_PORT_B1
+#define SDIO_PORT_C2
+
+#define SD_EMMC_CLKSRC_24M 2400/* 24 MHz */
+#define SD_EMMC_CLKSRC_DIV210  /* 1 GHz */
+
+#define MESON_SD_EMMC_CLOCK0x00
+#define   CLK_MAX_DIV  63
+#define   CLK_SRC_24M  (0 << 6)
+#define   CLK_SRC_DIV2 (1 << 6)
+#define   CLK_CO_PHASE_000 (0 << 8)
+#define   CLK_CO_PHASE_090 (1 << 8)
+#define   CLK_CO_PHASE_180 (2 << 8)
+#define   CLK_CO_PHASE_270 (3 << 8)
+#define   CLK_TX_PHASE_000 (0 << 10)
+#define   CLK_TX_PHASE_090 (1 << 10)
+#define   CLK_TX_PHASE_180 (2 << 10)
+#define   CLK_TX_PHASE_270 (3 << 10)
+#define   CLK_ALWAYS_ONBIT(24)
+
+#define MESON_SD_EMMC_CFG  0x44
+#define   CFG_BUS_WIDTH_MASK   GENMASK(1, 0)
+#define   CFG_BUS_WIDTH_1  0
+#define   CFG_BUS_WIDTH_4  1
+#define   CFG_BUS_WIDTH_8  2
+#define   CFG_BL_LEN_MASK  GENMASK(7, 4)
+#define   CFG_BL_LEN_SHIFT 4
+#define   CFG_BL_LEN_512   (9 << 4)
+#define   CFG_RESP_TIMEOUT_MASKGENMASK(11, 8)
+#define   CFG_RESP_TIMEOUT_256 (8 << 8)
+#define   CFG_RC_CC_MASK   GENMASK(15, 12)
+#define   CFG_RC_CC_16 (4 << 12)
+#define   CFG_SDCLK_ALWAYS_ON  BIT(18)
+#define   CFG_AUTO_CLK BIT(23)
+
+#define MESON_SD_EMMC_STATUS   0x48
+#define   STATUS_MASK  GENMASK(15, 0)
+#define   STATUS_ERR_MASK  GENMASK(12, 0)
+#define   STATUS_RXD_ERR_MASK  GENMASK(7, 0)
+#define   STATUS_TXD_ERR   BIT(8)
+#define   STATUS_DESC_ERR  BIT(9)
+#define   STATUS_RESP_ERR  BIT(10)
+#define   STATUS_RESP_TIMEOUT  BIT(11)
+#define   STATUS_DESC_TIMEOUT  BIT(12)
+#define   STATUS_END_OF_CHAIN  BIT(13)
+
+#define MESON_SD_EMMC_IRQ_EN   0x4c
+
+#define MESON_SD_EMMC_CMD_CFG  0x50
+#define   CMD_CFG_LENGTH_MASK  GENMASK(8, 0)
+#define   CMD_CFG_BLOCK_MODE   BIT(9)
+#define   CMD_CFG_R1B  BIT(10)
+#define   CMD_CFG_END_OF_CHAIN BIT(11)
+#define   CMD_CFG_TIMEOUT_4S   (12 << 12)
+#define   CMD_CFG_NO_RESP  BIT(16)
+#define   CMD_CFG_DATA_IO  BIT(18)
+#define   CMD_CFG_DATA_WR  BIT(19)
+#define   CMD_CFG_RESP_NOCRC   BIT(20)
+#define   CMD_CFG_RESP_128 BIT(21)
+#define   CMD_CFG_CMD_INDEX_SHIFT  24
+#define   CMD_CFG_OWNERBIT(31)
+
+#define MESON_SD_EMMC_CMD_ARG  0x54
+#define MESON_SD_EMMC_CMD_DAT  0x58
+#define MESON_SD_EMMC_CMD_RSP  0x5c
+#define MESON_SD_EMMC_CMD_RSP1 0x60
+#define MESON_SD_EMMC_CMD_RSP2 0x64
+#define MESON_SD_EMMC_CMD_RSP3 0x68
+
+struct meson_mmc_platdata {
+   struct mmc_config cfg;
+   struct mmc mmc;
+   void *regbase;
+   void *w_buf;
+};
+
+#endif
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 01d1dbf..aedd7a7 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -105,6 +105,12 @@ config MMC_DW_SOCFPGA
  Synopsys DesignWare Memory Card Interface driver. Select this option
  for platforms based on Altera SOCFPGA.
 
+config MMC_MESON_GX
+   bool "Meson GX EMMC controller support"
+   depends on DM_MMC && BLK && ARCH_MESON
+   help
+Support for EMMC host controller on Meson GX ARM SoCs platform (S905)
+
 config MMC_MXC
bool "Freescale i.MX21/27/31 or MPC512x Multimedia Card support"
help
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefil

[U-Boot] [PATCH v6 1/3] arm: dts: update Meson GXBB / Odroid-C2 DT with latest Linux version

2017-02-20 Thread Heiner Kallweit
As a prerequisite for adding a Meson GX MMC driver update the
Meson GXBB / Odroid-C2 device tree in Uboot with the latest
version from Linux.

Signed-off-by: Neil Armstrong 
Signed-off-by: Carlo Caione 
Signed-off-by: Andreas Färber 
Signed-off-by: Heiner Kallweit 
---
v4:
- Added SoB of original authors
v5:
- no changes
v6:
- changed prefix in subject
---
 arch/arm/dts/meson-gx.dtsi  | 447 
 arch/arm/dts/meson-gxbb-odroidc2.dts| 147 ++-
 arch/arm/dts/meson-gxbb.dtsi| 718 
 include/dt-bindings/clock/gxbb-aoclkc.h |  66 +++
 include/dt-bindings/clock/gxbb-clkc.h   |  34 ++
 include/dt-bindings/reset/gxbb-aoclkc.h |  66 +++
 6 files changed, 1203 insertions(+), 275 deletions(-)
 create mode 100644 arch/arm/dts/meson-gx.dtsi
 create mode 100644 include/dt-bindings/clock/gxbb-aoclkc.h
 create mode 100644 include/dt-bindings/clock/gxbb-clkc.h
 create mode 100644 include/dt-bindings/reset/gxbb-aoclkc.h

diff --git a/arch/arm/dts/meson-gx.dtsi b/arch/arm/dts/meson-gx.dtsi
new file mode 100644
index 000..c129100
--- /dev/null
+++ b/arch/arm/dts/meson-gx.dtsi
@@ -0,0 +1,447 @@
+/*
+ * Copyright (c) 2016 Andreas Färber
+ *
+ * Copyright (c) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ *
+ * Copyright (c) 2016 Endless Computers, Inc.
+ * Author: Carlo Caione 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+
+/ {
+   interrupt-parent = <&gic>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   /* 16 MiB reserved for Hardware ROM Firmware */
+   hwrom_reserved: hwrom@0 {
+   reg = <0x0 0x0 0x0 0x100>;
+   no-map;
+   };
+
+   /* 2 MiB reserved for ARM Trusted Firmware (BL31) */
+   secmon_reserved: secmon@1000 {
+   reg = <0x0 0x1000 0x0 0x20>;
+   no-map;
+   };
+   };
+
+   cpus {
+   #address-cells = <0x2>;
+   #size-cells = <0x0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   next-level-cache = <&l2>;
+   clocks = <&scpi_dvfs 0>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x1>;
+   enable-method = "psci";
+   next-level-cache = <&l2>;
+   clocks = <&scpi_dvfs 0>;
+   };
+
+   cpu2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8"

[U-Boot] [PATCH] binman: Explicitly request python2 instead of python from env

2017-02-20 Thread Paul Kocialkowski
We now live in a world where python cannot be assumed to be python2.
As a matter of fact, it is no longer the default for python on many
GNU/Linux distributions.

Running binman with python3 fails, so explicitly request python2 from
env in the shebang for running it.

Signed-off-by: Paul Kocialkowski 
---
 tools/binman/binman.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/binman/binman.py b/tools/binman/binman.py
index 4cc431fbbe..25a01d9adb 100755
--- a/tools/binman/binman.py
+++ b/tools/binman/binman.py
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python2
 
 # Copyright (c) 2016 Google, Inc
 # Written by Simon Glass 
-- 
2.11.1

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


Re: [U-Boot] [PATCH 1/2] common: image: update boot_get_fpga to support arbitrary fpga image

2017-02-20 Thread Moritz Fischer
Hi all,

On Mon, Feb 20, 2017 at 6:59 AM, Michal Simek  wrote:

> Definitely I am open to improve this subsystem to make it more flexible.

Over at linux-fpga ([1]) we're currently discussing the idea of coming
up with a header
format (vendor neutral) that we stitch onto the fpga image to allow the fpga-mgr
to derive certain features of the image from the image itself (i.e. is
the image encrypted,
compressed, ...).

We're trying to come up with an extensible format that would allow us
to add stuff like
encryption keys etc.

Cheers,

Moritz


[1] https://patchwork.kernel.org/patch/9574399/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 1/3] arm: ls1043ardb: Add SD secure boot target

2017-02-20 Thread Ruchika Gupta
- Add SD secure boot target for ls1043ardb.
- Implement board specific spl_board_init() to setup CAAM stream ID and
  corresponding stream ID in SMMU.
- Change the u-boot size defined by a macro for copying the main U-Boot by SPL
  to also include the u-boot Secure Boot header size as header is appended to
  u-boot image. So header will also be copied from SD to DDR.
- CONFIG_MAX_SPL_SIZE is limited to 90K.SPL is copied to OCRAM (128K) where 32K
  are reserved for use by boot ROM and 6K for secure boto header
- Error messages during SPL boot are limited to error code numbers instead of 
strings
  to reduce the size of SPL image

Signed-off-by: Vinitha Pillai-B57223 
Signed-off-by: Sumit Garg 
Signed-off-by: Ruchika Gupta 
---
The patchset is dependent on the following patches:
 https://patchwork.ozlabs.org/patch/717614/
 http://patchwork.ozlabs.org/patch/724332/
 http://patchwork.ozlabs.org/patch/729932/
 http://patchwork.ozlabs.org/patch/729980/

 arch/arm/include/asm/fsl_secure_boot.h  |  9 +++-
 board/freescale/common/fsl_validate.c   |  4 ++
 board/freescale/ls1043ardb/ls1043ardb.c | 19 +
 configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig | 57 +
 include/configs/ls1043a_common.h| 16 ++-
 5 files changed, 101 insertions(+), 4 deletions(-)
 create mode 100644 configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig

diff --git a/arch/arm/include/asm/fsl_secure_boot.h 
b/arch/arm/include/asm/fsl_secure_boot.h
index 8d9de45..a1474eb 100644
--- a/arch/arm/include/asm/fsl_secure_boot.h
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -32,10 +32,11 @@
 #define CONFIG_SPL_UBOOT_KEY_HASH  NULL
 #endif /* ifdef CONFIG_SPL_BUILD */
 
+#define CONFIG_KEY_REVOCATION
+
 #ifndef CONFIG_SPL_BUILD
 #define CONFIG_CMD_BLOB
 #define CONFIG_CMD_HASH
-#define CONFIG_KEY_REVOCATION
 #ifndef CONFIG_SYS_RAMBOOT
 /* The key used for verification of next level images
  * is picked up from an Extension Table which has
@@ -91,7 +92,11 @@
 /* For SD boot address and size are assigned in terms of sector
  * offset and no. of sectors respectively.
  */
-#define CONFIG_BS_HDR_ADDR_DEVICE  0x0900
+#if defined(CONFIG_LS1043A)
+#define CONFIG_BS_HDR_ADDR_DEVICE  0x0920
+#else
+#define CONFIG_BS_HDR_ADDR_DEVICE   0x0900
+#endif
 #define CONFIG_BS_ADDR_DEVICE  0x0940
 #define CONFIG_BS_HDR_SIZE 0x0010
 #define CONFIG_BS_SIZE 0x0008
diff --git a/board/freescale/common/fsl_validate.c 
b/board/freescale/common/fsl_validate.c
index 2b723a4..235c6ab 100644
--- a/board/freescale/common/fsl_validate.c
+++ b/board/freescale/common/fsl_validate.c
@@ -356,6 +356,7 @@ static void fsl_secboot_bootscript_parse_failure(void)
  */
 void fsl_secboot_handle_error(int error)
 {
+#ifndef CONFIG_SPL_BUILD
const struct fsl_secboot_errcode *e;
 
for (e = fsl_secboot_errcodes; e->errcode != ERROR_ESBC_CLIENT_MAX;
@@ -363,6 +364,9 @@ void fsl_secboot_handle_error(int error)
if (e->errcode == error)
printf("ERROR :: %x :: %s\n", error, e->name);
}
+#else
+   printf("ERROR :: %x\n", error);
+#endif
 
/* If Boot Mode is secure, transition the SNVS state and issue
 * reset based on type of failure and ITS setting.
diff --git a/board/freescale/ls1043ardb/ls1043ardb.c 
b/board/freescale/ls1043ardb/ls1043ardb.c
index 5a76742..0b3840d 100644
--- a/board/freescale/ls1043ardb/ls1043ardb.c
+++ b/board/freescale/ls1043ardb/ls1043ardb.c
@@ -43,6 +43,25 @@ int board_early_init_f(void)
return 0;
 }
 
+#if defined(CONFIG_SPL_BUILD)
+void spl_board_init(void)
+{
+#ifdef CONFIG_SECURE_BOOT
+   /*
+* In case of Secure Boot, the IBR configures the SMMU
+* to allow only Secure transactions.
+* SMMU must be reset in bypass mode.
+* Set the ClientPD bit and Clear the USFCFG Bit
+   */
+   u32 val;
+   val = (in_le32(SMMU_SCR0) | SCR0_CLIENTPD_MASK) & ~(SCR0_USFCFG_MASK);
+   out_le32(SMMU_SCR0, val);
+   val = (in_le32(SMMU_NSCR0) | SCR0_CLIENTPD_MASK) & ~(SCR0_USFCFG_MASK);
+   out_le32(SMMU_NSCR0, val);
+#endif
+}
+#endif
+
 #ifndef CONFIG_SPL_BUILD
 
 int checkboard(void)
diff --git a/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig 
b/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig
new file mode 100644
index 000..3f35d64
--- /dev/null
+++ b/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig
@@ -0,0 +1,57 @@
+CONFIG_ARM=y
+CONFIG_TARGET_LS1043ARDB=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SPL_MMC_SUPPORT=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_ENV_SUPPORT=y
+CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_SPL_WATCHDOG_SUPPORT=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1043a-rdb"
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,SD_BOOT"
+CONFIG_SECURE_BOOT=y
+CONFIG_SD_BOOT=y
+CONFIG_BOOTDELAY=10
+CONFIG_SPL=y

[U-Boot] [PATCH 3/3] arm: ls1046ardb: Add SD secure boot target

2017-02-20 Thread Ruchika Gupta
- Add SD secure boot target for ls1046ardb.
- Implement board specific spl_board_init() to setup CAAM stream ID and
  corresponding stream ID in SMMU.
- Change the u-boot size defined by a macro for copying the main U-Boot by SPL
  to also include the u-boot Secure Boot header size as header is appended to
  u-boot image. So header will also be copied from SD to DDR.
- CONFIG_MAX_SPL_SIZE is limited to 90K.SPL is copied to OCRAM (128K) where 32K
  are reserved for use by boot ROM and 6K for the header

Signed-off-by: Vinitha Pillai-B57223 
Signed-off-by: Sumit Garg 
Signed-off-by: Ruchika Gupta 
---
The patchset is dependent on the following patches:
 https://patchwork.ozlabs.org/patch/717614/
 http://patchwork.ozlabs.org/patch/724332/
 http://patchwork.ozlabs.org/patch/729932/
 http://patchwork.ozlabs.org/patch/729980/

 arch/arm/include/asm/fsl_secure_boot.h  |  2 +-
 board/freescale/ls1046ardb/ls1046ardb.c | 19 +++
 configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig | 45 +
 include/configs/ls1046a_common.h| 17 --
 include/configs/ls1046ardb.h|  1 -
 5 files changed, 79 insertions(+), 5 deletions(-)
 create mode 100644 configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig

diff --git a/arch/arm/include/asm/fsl_secure_boot.h 
b/arch/arm/include/asm/fsl_secure_boot.h
index 2f719c0..f612088 100644
--- a/arch/arm/include/asm/fsl_secure_boot.h
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -92,7 +92,7 @@
 /* For SD boot address and size are assigned in terms of sector
  * offset and no. of sectors respectively.
  */
-#if defined(CONFIG_LS1043A)
+#if defined(CONFIG_LS1043A) || defined(CONFIG_LS1046A)
 #define CONFIG_BS_HDR_ADDR_DEVICE  0x0920
 #else
 #define CONFIG_BS_HDR_ADDR_DEVICE   0x0900
diff --git a/board/freescale/ls1046ardb/ls1046ardb.c 
b/board/freescale/ls1046ardb/ls1046ardb.c
index bb03479..0087c73 100644
--- a/board/freescale/ls1046ardb/ls1046ardb.c
+++ b/board/freescale/ls1046ardb/ls1046ardb.c
@@ -38,6 +38,25 @@ int board_early_init_f(void)
return 0;
 }
 
+#if defined(CONFIG_SPL_BUILD)
+void spl_board_init(void)
+{
+#ifdef CONFIG_SECURE_BOOT
+   /*
+* In case of Secure Boot, the IBR configures the SMMU
+* to allow only Secure transactions.
+* SMMU must be reset in bypass mode.
+* Set the ClientPD bit and Clear the USFCFG Bit
+   */
+   u32 val;
+   val = (in_le32(SMMU_SCR0) | SCR0_CLIENTPD_MASK) & ~(SCR0_USFCFG_MASK);
+   out_le32(SMMU_SCR0, val);
+   val = (in_le32(SMMU_NSCR0) | SCR0_CLIENTPD_MASK) & ~(SCR0_USFCFG_MASK);
+   out_le32(SMMU_NSCR0, val);
+#endif
+}
+#endif
+
 #ifndef CONFIG_SPL_BUILD
 int checkboard(void)
 {
diff --git a/configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig 
b/configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig
new file mode 100644
index 000..a41ec80
--- /dev/null
+++ b/configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig
@@ -0,0 +1,45 @@
+CONFIG_ARM=y
+CONFIG_TARGET_LS1046ARDB=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1046a-rdb"
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL"
+CONFIG_SECURE_BOOT=y
+CONFIG_SD_BOOT=y
+CONFIG_BOOTDELAY=10
+CONFIG_SPL=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x110
+CONFIG_HUSH_PARSER=y
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_FAT=y
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPI_FLASH=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_SYS_NS16550=y
+CONFIG_DM_SPI=y
+CONFIG_FSL_QSPI=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_RSA=y
+CONFIG_SPL_RSA=y
+CONFIG_SPL_CRYPTO_SUPPORT=y
+CONFIG_SPL_HASH_SUPPORT=y
diff --git a/include/configs/ls1046a_common.h b/include/configs/ls1046a_common.h
index c884b95..241e679 100644
--- a/include/configs/ls1046a_common.h
+++ b/include/configs/ls1046a_common.h
@@ -13,7 +13,6 @@
 #define CONFIG_GICV2
 
 #include 
-
 /* Link Definitions */
 #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_FSL_OCRAM_BASE + 
0xfff0)
 
@@ -68,7 +67,19 @@
 #define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SPL_BSS_START_ADDR + \
CONFIG_SPL_BSS_MAX_SIZE)
 #define CONFIG_SYS_SPL_MALLOC_SIZE 0x10
-#define CONFIG_SYS_MONITOR_LEN 0xa
+
+#ifdef CONFIG_SECURE_BOOT
+#define CONFIG_U_BOOT_HDR_SIZE (16 << 10)
+/*
+ * HDR would be appended at end of image and copied to DDR along
+ * with U-Boot image. Here u-boot max. size is 512K. So if binary
+ * size increases then increase this size in case of secure boot as
+ * it uses raw u-boot image instead of fit image.
+ */
+#define CONFIG_SYS_MONITOR_LEN

Re: [U-Boot] socfpga qspi issues on SoCKit devkit

2017-02-20 Thread Rush, Jason A.
Marek Vasut wrote:
> On 02/20/2017 05:25 AM, Vignesh R wrote:
>> + Marek
>
> Thanks, +CC Dinh and Ley
>
>> On Friday 17 February 2017 05:02 AM, Rush, Jason A. wrote:
>>> The QSPI NOR interface on the Altera Cyclone V SoCKit devkit (Rev B) appears
>>> to be broken in the current release.  I've tracked it down to working in the
>>> v2016.07 release, but broken in the the v2016.09 release.  With the help of 
>>> git
>>> bisect, I tracked down the commit that breaks the QSPI to the following:
>>>
>>>   commit dac3bf20fb2c9b03476be0d73db620f62ab3cee1
>>>   Author: Vignesh R 
>>>   Date:   Wed Jul 6 10:20:55 2016 +0530
>>>
>>>   spi: cadence_qspi_apb: Support 32 bit AHB address
>>>
>>>   AHB address can be as long as 32 bit, hence remove the
>>>   CQSPI_REG_INDIRECTRDSTARTADDR mask. Since AHB address is passed from 
>>> DT
>>>   and read as u32 value, it anyway does not make sense to mask upper 
>>> bits.
>>>
>>>   Signed-off-by: Vignesh R 
>>>   Tested-by: Marek Vasut 
>>>   Acked-by: Marek Vasut 
>>>   Reviewed-by: Jagan Teki 
>>>
>>> When I try and read anything from the QSPI on the
>>> dac3bf20fb2c9b03476be0d73db620f62ab3cee1 commit I get a "data abort" and the
>>> CPU resets.  Example output below is from a clean build of U-Boot configured
>>> with socfpga_sockit_defconfig:
>>>
>>>  => sf probe
>>>   SF: Detected N25Q1024 with page size 256 Bytes, erase size 64 KiB, total 
>>> 128 MiB
>>>   => sf read 0x200 0x5 0x5000
>>>   device 0 offset 0x5, size 0x5000
>>>   data abort
>>>   pc : [<3ff7a9bc>]  lr : [<3ff98359>]
>>>   reloc pc : [<010249fc>]lr : [<01042399>]
>>>   sp : 3bf4fde8  ip : 3ff7a371 fp : 0002
>>>   r10:   r9 : 3bf54ee8 r8 : 3bf55530
>>>   r7 : 270d  r6 : 0200 r5 : 5000  r4 : 3bf55530
>>>   r3 : 0004  r2 :  r1 : 0200  r0 : ffa0
>>>   Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
>>>   Resetting CPU ...
>>>
>>> When I run the same commands with the previous commit in the git log
>>> (fdf02a36c52cb96717b64113775c4251ecd49596) I get the following output:
>>>
>>>   => sf probe
>>>   SF: Detected N25Q1024 with page size 256 Bytes, erase size 64 KiB, total 
>>> 128 MiB
>>>   => sf read 0x200 0x5 0x5000
>>>   device 0 offset 0x5, size 0x5000
>>>   SF: 20480 bytes @ 0x5 Read: OK
>>>   =>
>>>
>>> I've done some investigation, and previously the ahbbase was masked so the 
>>> value
>>> 0xFFA0_ results in 0x0 when writing the CQSPI_REG_INDIRECTTRIGGER 
>>> register.
>>> I assume the above commit works on some boards, but it appears to break the
>>> socfpga arch.
>>>
>>> Is there someone that could help investigate or confirm this?
>>
>> I am looking at cyclone5_handbook.pdf [1] and it says indaddrtrig
>> field is 32 bit wide. So, I wonder why masking is needed. If you
>> specify ahbbase as  0xFFA0_ in DT(reg property) then the
>> expectation is
>> 0xFFA0_ gets written to indaddrtrig reg. It looks like the trigger
>> address is 0x0 and not 0xFFA0_, therefore you may have to update
>> reg property in DT to reflect the same.
>>
>> [1]https://www.altera.com/en_US/pdfs/literature/hb/cyclone-v/cyclone5_
>> handbook.pdf
>>

I agree, according to the handbook the indaddrtrig register is 32-bits wide, but
writing the value 0xFFA0_ to indaddrtrig causes the above data abort.  It
looks like a similar issue has been discussed before:
http://lists.denx.de/pipermail/u-boot/2015-August/224649.html

In that proposed patch, it looks like the address to use for the indaddrtrig reg
was being separated from the ahbbase and the Altera SoC needed a value of
0x_.  I'm not very familiar with the Cadence device on the Altera SoC,
but it looks like it needs a different value than the ahbbase written to the
indaddrtrig reg.

I noticed the Cadence QSPI driver in the Linux tree has a separate
trigger_address that is loaded from the DT, and the socfpga.dtsi sets the
trigger_address to 0x_.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 2/3] arm: ls1043ardb: Add NAND secure boot target

2017-02-20 Thread Ruchika Gupta
Add NAND secure boot target for ls1043ardb.

- Change the u-boot size defined by a macro for copying the main
  U-Boot by SPL to also include the u-boot Secure Boot header size as
  header is appended to u-boot image. So header will also be copied from SD to 
DDR.
- MACRO for CONFIG_BOOTSCRIPT_COPY_RAM is enabled to copy Bootscript from NAND 
to
  DDR. Offsets for Bootscript on NAND and DDR have been also defined.

Signed-off-by: Vinitha Pillai-B57223 
Signed-off-by: Sumit Garg 
Signed-off-by: Ruchika Gupta 
---
The patchset is dependent on the following patches:
 https://patchwork.ozlabs.org/patch/717614/
 http://patchwork.ozlabs.org/patch/724332/
 http://patchwork.ozlabs.org/patch/729932/
 http://patchwork.ozlabs.org/patch/729980/

 arch/arm/include/asm/fsl_secure_boot.h|  7 +++-
 board/freescale/ls1043ardb/ls1043ardb.c   |  1 +
 configs/ls1043ardb_nand_SECURE_BOOT_defconfig | 57 +++
 include/config_fsl_chain_trust.h  |  9 +++--
 include/configs/ls1043a_common.h  | 18 -
 include/configs/ls1043ardb.h  |  2 +-
 6 files changed, 87 insertions(+), 7 deletions(-)
 create mode 100644 configs/ls1043ardb_nand_SECURE_BOOT_defconfig

diff --git a/arch/arm/include/asm/fsl_secure_boot.h 
b/arch/arm/include/asm/fsl_secure_boot.h
index a1474eb..2f719c0 100644
--- a/arch/arm/include/asm/fsl_secure_boot.h
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -74,7 +74,7 @@
 /* Copying Bootscript and Header to DDR from NOR for LS2 and for rest, from
  * Non-XIP Memory (Nand/SD)*/
 #if defined(CONFIG_SYS_RAMBOOT) || defined(CONFIG_FSL_LSCH3) || \
-   defined(CONFIG_SD_BOOT)
+   defined(CONFIG_SD_BOOT) || defined(CONFIG_NAND_BOOT)
 #define CONFIG_BOOTSCRIPT_COPY_RAM
 #endif
 /* The address needs to be modified according to NOR, NAND, SD and
@@ -100,6 +100,11 @@
 #define CONFIG_BS_ADDR_DEVICE  0x0940
 #define CONFIG_BS_HDR_SIZE 0x0010
 #define CONFIG_BS_SIZE 0x0008
+#elif defined(CONFIG_NAND_BOOT)
+#define CONFIG_BS_HDR_ADDR_DEVICE  0x0080
+#define CONFIG_BS_ADDR_DEVICE  0x00802000
+#define CONFIG_BS_HDR_SIZE 0x2000
+#define CONFIG_BS_SIZE 0x1000
 #else
 #define CONFIG_BS_HDR_ADDR_DEVICE  0x600a
 #define CONFIG_BS_ADDR_DEVICE  0x6006
diff --git a/board/freescale/ls1043ardb/ls1043ardb.c 
b/board/freescale/ls1043ardb/ls1043ardb.c
index 0b3840d..62ab749 100644
--- a/board/freescale/ls1043ardb/ls1043ardb.c
+++ b/board/freescale/ls1043ardb/ls1043ardb.c
@@ -58,6 +58,7 @@ void spl_board_init(void)
out_le32(SMMU_SCR0, val);
val = (in_le32(SMMU_NSCR0) | SCR0_CLIENTPD_MASK) & ~(SCR0_USFCFG_MASK);
out_le32(SMMU_NSCR0, val);
+   printf("Completed spl_board_init\n");
 #endif
 }
 #endif
diff --git a/configs/ls1043ardb_nand_SECURE_BOOT_defconfig 
b/configs/ls1043ardb_nand_SECURE_BOOT_defconfig
new file mode 100644
index 000..66c89fa
--- /dev/null
+++ b/configs/ls1043ardb_nand_SECURE_BOOT_defconfig
@@ -0,0 +1,57 @@
+CONFIG_ARM=y
+CONFIG_TARGET_LS1043ARDB=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SPL_NAND_SUPPORT=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_ENV_SUPPORT=y
+CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_SPL_WATCHDOG_SUPPORT=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1043a-rdb"
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,NAND_BOOT"
+CONFIG_NAND_BOOT=y
+CONFIG_SECURE_BOOT=y
+CONFIG_BOOTDELAY=10
+CONFIG_SPL=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0xf0
+CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_PXE=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_FAT=y
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_MTD_NOR_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_SYS_NS16550=y
+CONFIG_DM_SPI=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_STORAGE=y
+CONFIG_RSA=y
+CONFIG_SPL_RSA=y
+CONFIG_SPL_CRYPTO_SUPPORT=y
+CONFIG_SPL_HASH_SUPPORT=y
diff --git a/include/config_fsl_chain_trust.h b/include/config_fsl_chain_trust.h
index eb45e98..40d323e 100644
--- a/include/config_fsl_chain_trust.h
+++ b/include/config_fsl_chain_trust.h
@@ -81,17 +81,18 @@
"setenv bs_size " __stringify(CONFIG_BS_SIZE)";"
 
 /* For secure boot flow, default environment used will be used */
-#if defined(CONFIG_SYS_RAMBOOT)
-#if defined(CONFIG_RAMBOOT_NAND)
+#if defined(CONFIG_SYS_RAMBOOT) || defined(CONFIG_NAND_BOOT) || \
+   defined(CONFIG_SD_BOOT)
+#if defined(CONFIG_RAMBOOT_NAND) || defined(CONFIG_NAND_BOOT)
 #define C

[U-Boot] [PATCH 0/3] SECURE Boot targets for NAND and SD on LS1043, LS1046

2017-02-20 Thread Ruchika Gupta
Ruchika Gupta (3):
  arm: ls1043ardb: Add SD secure boot target
  arm: ls1043ardb: Add NAND secure boot target
  arm: ls1046ardb: Add SD secure boot target

 arch/arm/include/asm/fsl_secure_boot.h  | 16 +--
 board/freescale/common/fsl_validate.c   |  4 ++
 board/freescale/ls1043ardb/ls1043ardb.c | 20 +
 board/freescale/ls1046ardb/ls1046ardb.c | 19 +
 configs/ls1043ardb_nand_SECURE_BOOT_defconfig   | 57 +
 configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig | 57 +
 configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig | 45 +++
 include/config_fsl_chain_trust.h|  9 ++--
 include/configs/ls1043a_common.h| 34 +--
 include/configs/ls1043ardb.h|  2 +-
 include/configs/ls1046a_common.h| 17 ++--
 include/configs/ls1046ardb.h|  1 -
 12 files changed, 266 insertions(+), 15 deletions(-)
 create mode 100644 configs/ls1043ardb_nand_SECURE_BOOT_defconfig
 create mode 100644 configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig
 create mode 100644 configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig

-- 
The patchset is dependent on the following patches:
 https://patchwork.ozlabs.org/patch/717614/
 http://patchwork.ozlabs.org/patch/724332/
 http://patchwork.ozlabs.org/patch/729932/
 http://patchwork.ozlabs.org/patch/729980/

1.9.1

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


Re: [U-Boot] [PATCH v3 1/2] common: image: update boot_get_fpga to support arbitrary fpga image

2017-02-20 Thread Dalon Westergreen
On Mon, 2017-02-20 at 16:16 +0100, Michal Simek wrote:
> On 20.2.2017 15:56, Dalon Westergreen wrote:
> > 
> > The implementation of boot_get_fpga only supported one fpga family.
> > This modification allows for any of the fpga devices supported by
> > fpga_load to be used.
> > 
> > Signed-off-by: Dalon Westergreen 
> > 
> > --
> > Changes in v3:
> >  - Fix typos/caps in comments
> > Changes in v2:
> >  - Add fitimage support for fpga-devnum and fpga-partial-image
> >  - Use above in boot_get_fpga
> >  - for xilinx fpgas double check using image size to determine
> >    if image is a partial image
> > ---
> >  common/image-fit.c | 51 +++
> >  common/image.c | 51 ---
> >  include/image.h|  5 +
> >  3 files changed, 88 insertions(+), 19 deletions(-)
> > 
> > diff --git a/common/image-fit.c b/common/image-fit.c
> > index 109ecfa..eb0c633 100644
> > --- a/common/image-fit.c
> > +++ b/common/image-fit.c
> > @@ -916,6 +916,57 @@ ulong fit_get_end(const void *fit)
> >  }
> >  
> >  /**
> > + * fit_image_fpga_get_devnum - get fpga devnum
> > + * @fit: pointer to the FIT format image header
> > + * @noffset: fpga node offset
> > + * @devnum: pointer to an int, will hold fpga devnum
> > + *
> > + * fit_image_fpga_get_devnum() finds the fpga devnum for which the fpga
> > data is
> > + * intended.  If the property is not found, we default to 0.
> > + *
> > + * returns:
> > + * 0, on devnum not found
> > + * value, on devnum found
> > + */
> > +int fit_image_fpga_get_devnum(const void *fit, int noffset, int *devnum)
> > +{
> > +   int len;
> > +   int *value;
> > +
> > +   value = (int *)fdt_getprop(fit, noffset, FIT_FPGA_DEVNUM_PROP,
> > &len);
> > +   if (value == NULL || len != sizeof(int))
> > +   *devnum = 0;
> > +   else
> > +   *devnum = *value;
> > +
> > +   return 0;
> > +}
> > +
> > +/**
> > + * fit_image_fpga_is_partial - is partial fpga
> 
> bitstream.

will do.

> > 
> > + * @fit: pointer to the FIT format image header
> > + * @noffset: fpga node offset
> > + *
> > + * fit_image_fpga_is_partial() checks if the fpga node sets the property
> > + * indicating the data represents a partial fpga image.
> > + *
> > + * returns:
> > + * 0, on devnum not found
> > + * value, on devnum found
> > + */
> > +int fit_image_fpga_is_partial(const void *fit, int noffset)
> > +{
> > +   int len;
> > +   int *value;
> > +
> > +   value = (int *)fdt_getprop(fit, noffset, FIT_FPGA_PARTIAL_PROP,
> > &len);
> > +   if ((value == NULL || len != sizeof(int)) || (value == 0))
> > +   return 0;
> > +   else
> > +   return 1;
> > +}
> > +
> > +/**
> >   * fit_set_timestamp - set node timestamp property
> >   * @fit: pointer to the FIT format image header
> >   * @noffset: node offset
> > diff --git a/common/image.c b/common/image.c
> > index 0f88984..6480b0a 100644
> > --- a/common/image.c
> > +++ b/common/image.c
> > @@ -1306,7 +1306,7 @@ int boot_get_setup(bootm_headers_t *images, uint8_t
> > arch,
> >  }
> >  
> >  #if IMAGE_ENABLE_FIT
> > -#if defined(CONFIG_FPGA) && defined(CONFIG_FPGA_XILINX)
> > +#if defined(CONFIG_FPGA)
> >  int boot_get_fpga(int argc, char * const argv[], bootm_headers_t *images,
> >       uint8_t arch, const ulong *ld_start, ulong * const
> > ld_len)
> >  {
> > @@ -1316,9 +1316,10 @@ int boot_get_fpga(int argc, char * const argv[],
> > bootm_headers_t *images,
> >     int fit_img_result;
> >     const char *uname, *name;
> >     int err;
> > -   int devnum = 0; /* TODO support multi fpga platforms */
> > -   const fpga_desc * const desc = fpga_get_desc(devnum);
> > -   xilinx_desc *desc_xilinx = desc->devdesc;
> > +   int devnum;
> > +   const fpga_desc *desc;
> > +   xilinx_desc *desc_xilinx;
> > +   bitstream_type bstype = BIT_FULL;
> >  
> >     /* Check to see if the images struct has a FIT configuration */
> >     if (!genimg_has_config(images)) {
> > @@ -1365,26 +1366,38 @@ int boot_get_fpga(int argc, char * const argv[],
> > bootm_headers_t *images,
> >     return fit_img_result;
> >     }
> >  
> > -   if (img_len >= desc_xilinx->size) {
> > -   name = "full";
> > -   err = fpga_loadbitstream(devnum, (char *)img_data,
> > -    img_len, BIT_FULL);
> > -   if (err)
> > -   err = fpga_load(devnum, (const void
> > *)img_data,
> > -   img_len, BIT_FULL);
> > -   } else {
> > -   name = "partial";
> > -   err = fpga_loadbitstream(devnum, (char *)img_data,
> > -    img_len, BIT_PARTIAL);
> > -   if (err)
> > -   err = fpga_load(devnum, (const void
> > *)img_data,
> > -   img_len, BIT_PARTIAL);
> > +

Re: [U-Boot] [PATCH v3 1/2] common: image: update boot_get_fpga to support arbitrary fpga image

2017-02-20 Thread Michal Simek
On 20.2.2017 15:56, Dalon Westergreen wrote:
> The implementation of boot_get_fpga only supported one fpga family.
> This modification allows for any of the fpga devices supported by
> fpga_load to be used.
> 
> Signed-off-by: Dalon Westergreen 
> 
> --
> Changes in v3:
>  - Fix typos/caps in comments
> Changes in v2:
>  - Add fitimage support for fpga-devnum and fpga-partial-image
>  - Use above in boot_get_fpga
>  - for xilinx fpgas double check using image size to determine
>if image is a partial image
> ---
>  common/image-fit.c | 51 +++
>  common/image.c | 51 ---
>  include/image.h|  5 +
>  3 files changed, 88 insertions(+), 19 deletions(-)
> 
> diff --git a/common/image-fit.c b/common/image-fit.c
> index 109ecfa..eb0c633 100644
> --- a/common/image-fit.c
> +++ b/common/image-fit.c
> @@ -916,6 +916,57 @@ ulong fit_get_end(const void *fit)
>  }
>  
>  /**
> + * fit_image_fpga_get_devnum - get fpga devnum
> + * @fit: pointer to the FIT format image header
> + * @noffset: fpga node offset
> + * @devnum: pointer to an int, will hold fpga devnum
> + *
> + * fit_image_fpga_get_devnum() finds the fpga devnum for which the fpga data 
> is
> + * intended.  If the property is not found, we default to 0.
> + *
> + * returns:
> + * 0, on devnum not found
> + * value, on devnum found
> + */
> +int fit_image_fpga_get_devnum(const void *fit, int noffset, int *devnum)
> +{
> + int len;
> + int *value;
> +
> + value = (int *)fdt_getprop(fit, noffset, FIT_FPGA_DEVNUM_PROP, &len);
> + if (value == NULL || len != sizeof(int))
> + *devnum = 0;
> + else
> + *devnum = *value;
> +
> + return 0;
> +}
> +
> +/**
> + * fit_image_fpga_is_partial - is partial fpga

bitstream.

> + * @fit: pointer to the FIT format image header
> + * @noffset: fpga node offset
> + *
> + * fit_image_fpga_is_partial() checks if the fpga node sets the property
> + * indicating the data represents a partial fpga image.
> + *
> + * returns:
> + * 0, on devnum not found
> + * value, on devnum found
> + */
> +int fit_image_fpga_is_partial(const void *fit, int noffset)
> +{
> + int len;
> + int *value;
> +
> + value = (int *)fdt_getprop(fit, noffset, FIT_FPGA_PARTIAL_PROP, &len);
> + if ((value == NULL || len != sizeof(int)) || (value == 0))
> + return 0;
> + else
> + return 1;
> +}
> +
> +/**
>   * fit_set_timestamp - set node timestamp property
>   * @fit: pointer to the FIT format image header
>   * @noffset: node offset
> diff --git a/common/image.c b/common/image.c
> index 0f88984..6480b0a 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -1306,7 +1306,7 @@ int boot_get_setup(bootm_headers_t *images, uint8_t 
> arch,
>  }
>  
>  #if IMAGE_ENABLE_FIT
> -#if defined(CONFIG_FPGA) && defined(CONFIG_FPGA_XILINX)
> +#if defined(CONFIG_FPGA)
>  int boot_get_fpga(int argc, char * const argv[], bootm_headers_t *images,
> uint8_t arch, const ulong *ld_start, ulong * const ld_len)
>  {
> @@ -1316,9 +1316,10 @@ int boot_get_fpga(int argc, char * const argv[], 
> bootm_headers_t *images,
>   int fit_img_result;
>   const char *uname, *name;
>   int err;
> - int devnum = 0; /* TODO support multi fpga platforms */
> - const fpga_desc * const desc = fpga_get_desc(devnum);
> - xilinx_desc *desc_xilinx = desc->devdesc;
> + int devnum;
> + const fpga_desc *desc;
> + xilinx_desc *desc_xilinx;
> + bitstream_type bstype = BIT_FULL;
>  
>   /* Check to see if the images struct has a FIT configuration */
>   if (!genimg_has_config(images)) {
> @@ -1365,26 +1366,38 @@ int boot_get_fpga(int argc, char * const argv[], 
> bootm_headers_t *images,
>   return fit_img_result;
>   }
>  
> - if (img_len >= desc_xilinx->size) {
> - name = "full";
> - err = fpga_loadbitstream(devnum, (char *)img_data,
> -  img_len, BIT_FULL);
> - if (err)
> - err = fpga_load(devnum, (const void *)img_data,
> - img_len, BIT_FULL);
> - } else {
> - name = "partial";
> - err = fpga_loadbitstream(devnum, (char *)img_data,
> -  img_len, BIT_PARTIAL);
> - if (err)
> - err = fpga_load(devnum, (const void *)img_data,
> - img_len, BIT_PARTIAL);
> + /* Get FPGA device number, defaults to 0 */
> + fit_image_fpga_get_devnum(buf, conf_noffset, &devnum);
> +
> + /* Check bitstream type */
> + if (fit_image_fpga_is_partial(buf, conf_noffset))
> + bstype = BIT_PAR

Re: [U-Boot] ZYNQ direct MAC connection

2017-02-20 Thread Hannes Schmelzer



On 13.02.2017 23:03, Moritz Fischer wrote:

Hi Hannes,

Hi Moritz,


On Mon, Feb 13, 2017 at 4:56 AM, Hannes Schmelzer
 wrote:

Hello,

did anybody setup successfully setup a direct MAC connection using RGMII
with a zynq ?
For example to a switch.

The zynq_gem driver wants to probe for phy by itself.
I already made a connection with very bad hacks in various files.

In linux such things are working with "fixed-link". Also the i.mx6 FEC
driver (not using DM) can operate in direct-connection mode.

For linux I have a patch that I've meant to submit since quite a while that
makes fixed-link work for the cadence gem. Maybe you can use that as a
starting point. It definitely does work.

I'll submit the linux one eventually, feel free to comment or improve.



many thanks for this.
Looks good - i'll try it on linux later.

For now i have to bring this stuff up in vxWorks first.

For U-Boot i have some bad hack running, as told.
I will start a implementation for "fixed-link" resp. "fixed-phy" in 
u-boot. Maybe i can provide some patch for RFC during next week.


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


Re: [U-Boot] [PATCH 1/2] common: image: update boot_get_fpga to support arbitrary fpga image

2017-02-20 Thread Michal Simek
On 20.2.2017 15:30, Dalon Westergreen wrote:
> On Mon, 2017-02-20 at 10:22 +0100, Michal Simek wrote:
>> On 19.2.2017 21:58, Dalon Westergreen wrote:
>>>
>>> On Sun, 2017-02-19 at 21:49 +0100, Marek Vasut wrote:

 On 02/19/2017 09:43 PM, Dalon Westergreen wrote:
>
>
> On Sun, 2017-02-19 at 21:07 +0100, Marek Vasut wrote:
>>
>>
>> On 02/19/2017 08:49 PM, Dalon Westergreen wrote:
>>>
>>>
>>>
>>> The implementation of boot_get_fpga only supported one fpga family.
>>> This modification allows for any of the fpga devices supported by
>>> fpga_load to be used.
>>>
>>> Signed-off-by: Dalon Westergreen 
>>
>> +CC Xilinx friends :)
>>
>>>
>>>
>>>
>>> ---
>>>  common/image.c | 37 ++---
>>>  1 file changed, 22 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/common/image.c b/common/image.c
>>> index 0f88984..792d371 100644
>>> --- a/common/image.c
>>> +++ b/common/image.c
>>> @@ -1306,7 +1306,7 @@ int boot_get_setup(bootm_headers_t *images,
>>> uint8_t
>>> arch,
>>>  }
>>>  
>>>  #if IMAGE_ENABLE_FIT
>>> -#if defined(CONFIG_FPGA) && defined(CONFIG_FPGA_XILINX)
>>> +#if defined(CONFIG_FPGA)
>>>  int boot_get_fpga(int argc, char * const argv[], bootm_headers_t
>>> *images,
>>>   uint8_t arch, const ulong *ld_start, ulong *
>>> const
>>> ld_len)
>>>  {
>>> @@ -1318,7 +1318,8 @@ int boot_get_fpga(int argc, char * const
>>> argv[],
>>> bootm_headers_t *images,
>>> int err;
>>> int devnum = 0; /* TODO support multi fpga platforms */
>>> const fpga_desc * const desc = fpga_get_desc(devnum);
>>> -   xilinx_desc *desc_xilinx = desc->devdesc;
>>> +   xilinx_desc *desc_xilinx;
>>> +   bitstream_type bstype;
>>>  
>>> /* Check to see if the images struct has a FIT
>>> configuration */
>>> if (!genimg_has_config(images)) {
>>> @@ -1365,22 +1366,28 @@ int boot_get_fpga(int argc, char * const
>>> argv[],
>>> bootm_headers_t *images,
>>> return fit_img_result;
>>> }
>>>  
>>> -   if (img_len >= desc_xilinx->size) {
>>> +   switch (desc->devtype) {
>>
>> Do we need the switch statement at all ? We can have full
>> configuration
>> as a default mode of operation and have something like
>>
>> if (xilinx) {
>>  if (partial reconfiguration) {
>>   do_special_setup();
>>  }
>> }
>
> I only did the switch stuff b/c i envisioned a need for partial image
> support for socfpga.

 That'd be seriously cool :)

>
>
> That said, i would suggest, as you mention, moving
> this to platform specific code and perhaps an indication of the image
> type
> in the fitimage.

 driver-specific code . It doesn't need to know the imagetype, just that
 the blob that you passed in is a partial-reconfiguration blob. I never
 really worked with P/R though, do you need some other metadata for that
 or is it contained in that P/R bitstream blob already ?
>>>
>>> as far as i understand it, it is all in the blob.  All that is needed is
>>> knowing
>>> whether the blob is a full or partial image.  X seems to just use the image
>>> size
>>> to determine this, but that means having a table of all devices and their
>>> respective full image size.  seems simpler to just specify the image type is
>>> partial or not in the fitimage.
>>
>> We did that for zynq when we did that for the first time. But not for
>> zynqmp. Zynq is maybe still using it but it shouldn't now. It is not
>> 100% reliable way. Definitely having DT property is the best option
>> because you can add sort of "nop" which extend bitstream size and does
>> nothing which breaks that checking.
>>
>> For full u-boot there is loadb, loadbp, load and loadp to distinguish it.
> 
> That brings up an interesting point, right now the fpga_loadbitstream doesn't
> follow the same method as fpga_load for allowing multiple FPGA types to be
> supported simultaneously.  Would it not be prudent to move in that direction?
> I believe only xilinx implements this right now.

loadbitstream is there for a long time which is in general just header
bitstream header parser written in pretty bad way.
Right now we are adding support for encrypted and authenticated images
and for that we are adding fpga loads command where you specify by flag
if you want to pass encrypted or authenticated image and keys.

There is also loadmk which should be improved a lot exactly by what you
are trying to do. It means we should wrap bitstreams with flags which
says what it is inside.
On the other hand having separate commands it is easy for testing.

Definitely I am open to improve this subsystem to make it more flexible.

Th

[U-Boot] [PATCH v3 1/2] common: image: update boot_get_fpga to support arbitrary fpga image

2017-02-20 Thread Dalon Westergreen
The implementation of boot_get_fpga only supported one fpga family.
This modification allows for any of the fpga devices supported by
fpga_load to be used.

Signed-off-by: Dalon Westergreen 

--
Changes in v3:
 - Fix typos/caps in comments
Changes in v2:
 - Add fitimage support for fpga-devnum and fpga-partial-image
 - Use above in boot_get_fpga
 - for xilinx fpgas double check using image size to determine
   if image is a partial image
---
 common/image-fit.c | 51 +++
 common/image.c | 51 ---
 include/image.h|  5 +
 3 files changed, 88 insertions(+), 19 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index 109ecfa..eb0c633 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -916,6 +916,57 @@ ulong fit_get_end(const void *fit)
 }
 
 /**
+ * fit_image_fpga_get_devnum - get fpga devnum
+ * @fit: pointer to the FIT format image header
+ * @noffset: fpga node offset
+ * @devnum: pointer to an int, will hold fpga devnum
+ *
+ * fit_image_fpga_get_devnum() finds the fpga devnum for which the fpga data is
+ * intended.  If the property is not found, we default to 0.
+ *
+ * returns:
+ * 0, on devnum not found
+ * value, on devnum found
+ */
+int fit_image_fpga_get_devnum(const void *fit, int noffset, int *devnum)
+{
+   int len;
+   int *value;
+
+   value = (int *)fdt_getprop(fit, noffset, FIT_FPGA_DEVNUM_PROP, &len);
+   if (value == NULL || len != sizeof(int))
+   *devnum = 0;
+   else
+   *devnum = *value;
+
+   return 0;
+}
+
+/**
+ * fit_image_fpga_is_partial - is partial fpga
+ * @fit: pointer to the FIT format image header
+ * @noffset: fpga node offset
+ *
+ * fit_image_fpga_is_partial() checks if the fpga node sets the property
+ * indicating the data represents a partial fpga image.
+ *
+ * returns:
+ * 0, on devnum not found
+ * value, on devnum found
+ */
+int fit_image_fpga_is_partial(const void *fit, int noffset)
+{
+   int len;
+   int *value;
+
+   value = (int *)fdt_getprop(fit, noffset, FIT_FPGA_PARTIAL_PROP, &len);
+   if ((value == NULL || len != sizeof(int)) || (value == 0))
+   return 0;
+   else
+   return 1;
+}
+
+/**
  * fit_set_timestamp - set node timestamp property
  * @fit: pointer to the FIT format image header
  * @noffset: node offset
diff --git a/common/image.c b/common/image.c
index 0f88984..6480b0a 100644
--- a/common/image.c
+++ b/common/image.c
@@ -1306,7 +1306,7 @@ int boot_get_setup(bootm_headers_t *images, uint8_t arch,
 }
 
 #if IMAGE_ENABLE_FIT
-#if defined(CONFIG_FPGA) && defined(CONFIG_FPGA_XILINX)
+#if defined(CONFIG_FPGA)
 int boot_get_fpga(int argc, char * const argv[], bootm_headers_t *images,
  uint8_t arch, const ulong *ld_start, ulong * const ld_len)
 {
@@ -1316,9 +1316,10 @@ int boot_get_fpga(int argc, char * const argv[], 
bootm_headers_t *images,
int fit_img_result;
const char *uname, *name;
int err;
-   int devnum = 0; /* TODO support multi fpga platforms */
-   const fpga_desc * const desc = fpga_get_desc(devnum);
-   xilinx_desc *desc_xilinx = desc->devdesc;
+   int devnum;
+   const fpga_desc *desc;
+   xilinx_desc *desc_xilinx;
+   bitstream_type bstype = BIT_FULL;
 
/* Check to see if the images struct has a FIT configuration */
if (!genimg_has_config(images)) {
@@ -1365,26 +1366,38 @@ int boot_get_fpga(int argc, char * const argv[], 
bootm_headers_t *images,
return fit_img_result;
}
 
-   if (img_len >= desc_xilinx->size) {
-   name = "full";
-   err = fpga_loadbitstream(devnum, (char *)img_data,
-img_len, BIT_FULL);
-   if (err)
-   err = fpga_load(devnum, (const void *)img_data,
-   img_len, BIT_FULL);
-   } else {
-   name = "partial";
-   err = fpga_loadbitstream(devnum, (char *)img_data,
-img_len, BIT_PARTIAL);
-   if (err)
-   err = fpga_load(devnum, (const void *)img_data,
-   img_len, BIT_PARTIAL);
+   /* Get FPGA device number, defaults to 0 */
+   fit_image_fpga_get_devnum(buf, conf_noffset, &devnum);
+
+   /* Check bitstream type */
+   if (fit_image_fpga_is_partial(buf, conf_noffset))
+   bstype = BIT_PARTIAL;
+
+   /* Legacy support detecting partial config files for Xilinx */
+   desc = fpga_get_desc(devnum);
+   if (desc->devtype == fpga_xilinx) {
+   desc_xilinx = desc->devdesc

[U-Boot] [PATCH v3 2/2] common: bootm: add support for arbitrary fgpa configuration

2017-02-20 Thread Dalon Westergreen
This adds support for fpga configuration data in fitimages for
any fpga device supported by fpga_load.  At this point fitimages
only support configuration of fpga images for fpga devnum 0.

Signed-off-by: Dalon Westergreen 
---
 common/bootm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/bootm.c b/common/bootm.c
index b2c0912..4a4b47c 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -248,7 +248,7 @@ int bootm_find_images(int flag, int argc, char * const 
argv[])
 #endif
 
 #if IMAGE_ENABLE_FIT
-#if defined(CONFIG_FPGA) && defined(CONFIG_FPGA_XILINX)
+#if defined(CONFIG_FPGA)
/* find bitstreams */
ret = boot_get_fpga(argc, argv, &images, IH_ARCH_DEFAULT,
NULL, NULL);
-- 
2.7.4

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


[U-Boot] [PATCH v3 0/2] common: fitimage support for arbitrary fpga type

2017-02-20 Thread Dalon Westergreen
The intent of these patches is to modify existing fitimage support for
fpga configuration to allow configuration of any fpga type supported
by the fpga_load command.
 
In the fpga node, two additional optional parameters are used to indicate
the fpga device number (for systems with multiple fpgas) and whether the fpga
image is a full or partial image.
 
fpga-devnum: FPGA device number, defaults to 0
fpga-partial-image: 0 = full, other = partial, defaults to full

Changes in v3:
 - Fix typos and caps in comments 
Changes in v2:
 - Add support for devnum and partial
 - for backward compatibility, do check of image size for xilinx to determine
   if the image is a partial image

Dalon Westergreen (2):
  common: image: update boot_get_fpga to support arbitrary fpga image
  common: bootm: add support for arbitrary fgpa configuration

 common/bootm.c |  2 +-
 common/image-fit.c | 51 +++
 common/image.c | 51 ---
 include/image.h|  5 +
 4 files changed, 89 insertions(+), 20 deletions(-)

-- 
2.7.4

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


Re: [U-Boot] [PATCH v2 1/2] common: image: update boot_get_fpga to support arbitrary fpga image

2017-02-20 Thread Marek Vasut
On 02/20/2017 03:42 PM, Dalon Westergreen wrote:
> On Mon, 2017-02-20 at 09:14 +0100, Marek Vasut wrote:
>> On 02/20/2017 04:35 AM, Dalon Westergreen wrote:
>>>
>>> The implementation of boot_get_fpga only supported one fpga family.
>>> This modification allows for any of the fpga devices supported by
>>> fpga_load to be used.
>>>
>>> Signed-off-by: Dalon Westergreen 
>>
>> IMO looks OK, minor nits below
>>
>>>
>>> --
>>> Changes in v2:
>>>  - Add fitimage support for fpga-devnum and fpga-partial-image
>>>  - Use above in boot_get_fpga
>>>  - for xilinx fpgas double check using image size to determine
>>>if image is a partial image
>>> ---
>>>  common/image-fit.c | 51 +++
>>>  common/image.c | 51 ---
>>>  include/image.h|  5 +
>>>  3 files changed, 88 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/common/image-fit.c b/common/image-fit.c
>>> index 109ecfa..eb0c633 100644
>>> --- a/common/image-fit.c
>>> +++ b/common/image-fit.c
>>> @@ -916,6 +916,57 @@ ulong fit_get_end(const void *fit)
>>>  }
>>>  
>>>  
> [...]
>>>
>>> +   fit_image_fpga_get_devnum(buf, conf_noffset, &devnum);
>>> +
>>> +   /* check bitstream type */
>>
>> At least start the sentence with capital letter please.
>>
>>>
>>> +   if (fit_image_fpga_is_partial(buf, conf_noffset))
>>> +   bstype = BIT_PARTIAL;
>>
>> Are there any chances there will be something else besides full and
>> partial in the future ?
> 
> It's plausible but i think not a likely use case here. In Arria10 there is the
> periphery/core image that configures just the io or fpga core.  I believe,
> though, that this is just a special case of a partial image and is treated the
> same.

IOCSR ? Hmmm, it'd be great if we could get a real pinmux driver for
socfpga ;-) But that's totally out of context of this discussion ...

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


[U-Boot] [PATCH 2/3] sunxi: Convert CONFIG_SUNXI_EMAC to Kconfig

2017-02-20 Thread Tom Rini
Migrate this option to Kconfig.

Signed-off-by: Tom Rini 
---
 configs/A10-OLinuXino-Lime_defconfig | 3 ++-
 configs/A10s-OLinuXino-M_defconfig   | 2 +-
 configs/Cubieboard_defconfig | 3 ++-
 configs/Linksprite_pcDuino_defconfig | 2 +-
 configs/Marsboard_A10_defconfig  | 2 +-
 configs/Mele_A1000_defconfig | 3 ++-
 configs/ba10_tv_box_defconfig| 2 +-
 configs/jesurun_q5_defconfig | 3 ++-
 drivers/net/Kconfig  | 7 +++
 include/configs/sunxi-common.h   | 1 -
 10 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/configs/A10-OLinuXino-Lime_defconfig 
b/configs/A10-OLinuXino-Lime_defconfig
index 9368c6d..6acdb4a 100644
--- a/configs/A10-OLinuXino-Lime_defconfig
+++ b/configs/A10-OLinuXino-Lime_defconfig
@@ -9,7 +9,7 @@ CONFIG_MMC0_CD_PIN="PH1"
 CONFIG_DEFAULT_DEVICE_TREE="sun4i-a10-olinuxino-lime"
 CONFIG_AHCI=y
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SYS_EXTRA_OPTIONS="SUNXI_EMAC,SATAPWR=SUNXI_GPC(3)"
+CONFIG_SYS_EXTRA_OPTIONS="SATAPWR=SUNXI_GPC(3)"
 CONFIG_SPL=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
@@ -17,6 +17,7 @@ CONFIG_SPL=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_ISO_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_SUNXI_EMAC=y
 CONFIG_AXP_ALDO3_VOLT=2800
 CONFIG_AXP_ALDO4_VOLT=2800
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/A10s-OLinuXino-M_defconfig 
b/configs/A10s-OLinuXino-M_defconfig
index 6adb5bc..f0e199d 100644
--- a/configs/A10s-OLinuXino-M_defconfig
+++ b/configs/A10s-OLinuXino-M_defconfig
@@ -9,7 +9,6 @@ CONFIG_MMC_SUNXI_SLOT_EXTRA=1
 CONFIG_USB1_VBUS_PIN="PB10"
 CONFIG_DEFAULT_DEVICE_TREE="sun5i-a10s-olinuxino-micro"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SYS_EXTRA_OPTIONS="SUNXI_EMAC"
 CONFIG_SPL=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
@@ -17,5 +16,6 @@ CONFIG_SPL=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_ISO_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_SUNXI_EMAC=y
 CONFIG_AXP152_POWER=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/Cubieboard_defconfig b/configs/Cubieboard_defconfig
index 0389d4c..ef9d9ec 100644
--- a/configs/Cubieboard_defconfig
+++ b/configs/Cubieboard_defconfig
@@ -7,7 +7,7 @@ CONFIG_MMC0_CD_PIN="PH1"
 CONFIG_DEFAULT_DEVICE_TREE="sun4i-a10-cubieboard"
 CONFIG_AHCI=y
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SYS_EXTRA_OPTIONS="SUNXI_EMAC,SATAPWR=SUNXI_GPB(8)"
+CONFIG_SYS_EXTRA_OPTIONS="SATAPWR=SUNXI_GPB(8)"
 CONFIG_SPL=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
@@ -15,4 +15,5 @@ CONFIG_SPL=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_ISO_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_SUNXI_EMAC=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/Linksprite_pcDuino_defconfig 
b/configs/Linksprite_pcDuino_defconfig
index 8b310fa..ccd7411 100644
--- a/configs/Linksprite_pcDuino_defconfig
+++ b/configs/Linksprite_pcDuino_defconfig
@@ -6,7 +6,6 @@ CONFIG_USB1_VBUS_PIN=""
 CONFIG_USB2_VBUS_PIN=""
 CONFIG_DEFAULT_DEVICE_TREE="sun4i-a10-pcduino"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SYS_EXTRA_OPTIONS="SUNXI_EMAC"
 CONFIG_SPL=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
@@ -14,4 +13,5 @@ CONFIG_SPL=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_ISO_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_SUNXI_EMAC=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/Marsboard_A10_defconfig b/configs/Marsboard_A10_defconfig
index 34e78f1..4deff86 100644
--- a/configs/Marsboard_A10_defconfig
+++ b/configs/Marsboard_A10_defconfig
@@ -4,7 +4,6 @@ CONFIG_MACH_SUN4I=y
 CONFIG_DEFAULT_DEVICE_TREE="sun4i-a10-marsboard"
 CONFIG_AHCI=y
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SYS_EXTRA_OPTIONS="SUNXI_EMAC"
 CONFIG_SPL=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
@@ -12,5 +11,6 @@ CONFIG_SPL=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_ISO_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_SUNXI_EMAC=y
 CONFIG_SUNXI_NO_PMIC=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/Mele_A1000_defconfig b/configs/Mele_A1000_defconfig
index 5047ba4..6d97764 100644
--- a/configs/Mele_A1000_defconfig
+++ b/configs/Mele_A1000_defconfig
@@ -7,7 +7,7 @@ CONFIG_VIDEO_COMPOSITE=y
 CONFIG_DEFAULT_DEVICE_TREE="sun4i-a10-a1000"
 CONFIG_AHCI=y
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SYS_EXTRA_OPTIONS="SUNXI_EMAC,MACPWR=SUNXI_GPH(15)"
+CONFIG_SYS_EXTRA_OPTIONS="MACPWR=SUNXI_GPH(15)"
 CONFIG_SPL=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
@@ -15,4 +15,5 @@ CONFIG_SPL=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_ISO_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_SUNXI_EMAC=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/ba10_tv_box_defconfig b/configs/ba10_tv_box_defconfig
index c9a9e8e..82d457e 100644
--- a/configs/ba10_tv_box_defconfig
+++ b/configs/ba10_tv_box_defconfig
@@ -9,7 +9,6 @@ C

Re: [U-Boot] [PATCH v2 1/2] common: image: update boot_get_fpga to support arbitrary fpga image

2017-02-20 Thread Dalon Westergreen
On Mon, 2017-02-20 at 09:14 +0100, Marek Vasut wrote:
> On 02/20/2017 04:35 AM, Dalon Westergreen wrote:
> > 
> > The implementation of boot_get_fpga only supported one fpga family.
> > This modification allows for any of the fpga devices supported by
> > fpga_load to be used.
> > 
> > Signed-off-by: Dalon Westergreen 
> 
> IMO looks OK, minor nits below
> 
> > 
> > --
> > Changes in v2:
> >  - Add fitimage support for fpga-devnum and fpga-partial-image
> >  - Use above in boot_get_fpga
> >  - for xilinx fpgas double check using image size to determine
> >    if image is a partial image
> > ---
> >  common/image-fit.c | 51 +++
> >  common/image.c | 51 ---
> >  include/image.h|  5 +
> >  3 files changed, 88 insertions(+), 19 deletions(-)
> > 
> > diff --git a/common/image-fit.c b/common/image-fit.c
> > index 109ecfa..eb0c633 100644
> > --- a/common/image-fit.c
> > +++ b/common/image-fit.c
> > @@ -916,6 +916,57 @@ ulong fit_get_end(const void *fit)
> >  }
> >  
> > 
[...]
> > 
> > +   fit_image_fpga_get_devnum(buf, conf_noffset, &devnum);
> > +
> > +   /* check bitstream type */
> 
> At least start the sentence with capital letter please.
> 
> > 
> > +   if (fit_image_fpga_is_partial(buf, conf_noffset))
> > +   bstype = BIT_PARTIAL;
> 
> Are there any chances there will be something else besides full and
> partial in the future ?

It's plausible but i think not a likely use case here. In Arria10 there is the
periphery/core image that configures just the io or fpga core.  I believe,
though, that this is just a special case of a partial image and is treated the
same.

--dalon

> 
> > 
> > +   /* legacy support detecting partial config files for xilinx
> > */
> 
> DTTO, start with caps.
> 
> > 
> > +   desc = fpga_get_desc(devnum);
> > +   if (desc->devtype == fpga_xilinx) {
> > +   desc_xilinx = desc->devdesc;
> > +   if (img_len < desc_xilinx->size)
> > +   bstype = BIT_PARTIAL;
> >     }
> >  
> > +   /* Try bitstream format first */
> > +   err = fpga_loadbitstream(devnum, (char *)img_data,
> > +    img_len, bstype);
> > +   if (err)
> > +   err = fpga_load(devnum, (const void *)img_data,
> > +   img_len, bstype);
> > +
> >     if (err)
> >     return err;
> >  
> > -   printf("   Programming %s bitstream... OK\n", name);
> > +   if (bstype == BIT_PARTIAL)
> > +   name = "partial";
> > +   else
> > +   name = "full";
> > +
> > +   printf("   Programming %s bitstream into fpga %d... OK\n",
> > +      name, devnum);
> >     break;
> >     default:
> >     printf("The given image format is not supported
> > (corrupt?)\n");
> > diff --git a/include/image.h b/include/image.h
> > index 1e686b7..75d2afc 100644
> > --- a/include/image.h
> > +++ b/include/image.h
> > @@ -876,6 +876,8 @@ int bootz_setup(ulong image, ulong *start, ulong *end);
> >  #define FIT_COMP_PROP  "compression"
> >  #define FIT_ENTRY_PROP "entry"
> >  #define FIT_LOAD_PROP  "load"
> > +#define FIT_FPGA_DEVNUM_PROP   "fpga-devnum"
> > +#define FIT_FPGA_PARTIAL_PROP  "fpga-partial-image"
> >  
> >  /* configuration node */
> >  #define FIT_KERNEL_PROP"kernel"
> > @@ -955,6 +957,9 @@ int fit_image_hash_get_value(const void *fit, int
> > noffset, uint8_t **value,
> >  
> >  int fit_set_timestamp(void *fit, int noffset, time_t timestamp);
> >  
> > +int fit_image_fpga_get_devnum(const void *fit, int noffset, int *devnum);
> > +int fit_image_fpga_is_partial(const void *fit, int noffset);
> > +
> >  /**
> >   * fit_add_verification_data() - add verification data to FIT image nodes
> >   *
> > 
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3] arm: socfpga: fix issue with warm reset when CSEL is 0

2017-02-20 Thread Marek Vasut
On 02/20/2017 03:35 PM, Dalon Westergreen wrote:
> On Mon, 2017-02-20 at 15:24 +0100, Marek Vasut wrote:
>> On 02/20/2017 03:21 PM, Dalon Westergreen wrote:
>>>
>>> On Mon, 2017-02-20 at 15:14 +0100, Marek Vasut wrote:

 On 02/20/2017 03:10 PM, Dalon Westergreen wrote:
>
>
> On Mon, 2017-02-20 at 10:07 +0100, Marek Vasut wrote:
>>
>>
>> On 02/18/2017 02:34 AM, Dalon Westergreen wrote:
>>>
>>>
>>>
>>> When CSEL=0x0 the socfpga bootrom does not touch the clock
>>> configuration for the device.  This can lead to a boot failure
>>> on warm resets. This patch disables warm resets when CSEL=0.
>>> This results in the clock and pll configurations being reset
>>> on any reset issued when CSEL=0.
>>>
>>> Signed-off-by: Dalon Westergreen 
>>
>> What about my suggestion for V2 about just loading function pointer
>> into
>> the reset jump address register ?
>
> Frankly, i really dont like relying on the existence of a snippet of
> code in
> the
> onchip ram being untouched to ensure a reboot/reset will occur for this
> csel=0
> case.  i am certain this case is rarely used, and confident that it isnt
> being
> used while trying to preserve sdram contents.

 Well, you already rely on such snippet, it's SPL. If you corrupt SPL and
 do warm reset, your system hangs, I had that multiple times :)
>>>
>>> True.  I would argue to just use cold resets but i think arria 10 has more
>>> use
>>> for the warm reset case.
>>
>> OK
>>
>>>

>
>
> the downside is that the scorecard is reset every boot. so the bootrom
> will
> retry all the spl images again resulting in possibly longer boot times.

 Is that significant ?
>>>
>>> The watchdog timeout is on the order of 1.5 seconds.  That would be for each
>>> failed spl.
>>
>> Hm, OK. But then your system is kinda broken, so you should expect this
>> I guess.
> 
> My thought exactly...  I would like to see if Chin Liang or Dinh have any
> comments?

Agreed, this needs more input

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


[U-Boot] [PATCH 1/3] drivers/net/Kconfig: Correct use of apostrophe

2017-02-20 Thread Tom Rini
Signed-off-by: Tom Rini 
---
 drivers/net/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 078d5a8..70e3661 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -168,7 +168,7 @@ config SUN8I_EMAC
 help
   This driver supports the  Allwinner based SUN8I/SUN50I Ethernet MAC.
  It can be found in H3/A64/A83T based SoCs and compatible with both
- External and Internal PHY's.
+ External and Internal PHYs.
 
 config XILINX_AXIEMAC
depends on DM_ETH && (MICROBLAZE || ARCH_ZYNQ || ARCH_ZYNQMP)
-- 
2.1.4

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


[U-Boot] [PATCH 3/3] sunxi: Convert SUNXI_GMAC to Kconfig

2017-02-20 Thread Tom Rini
Migrate this option to Kconfig.

Signed-off-by: Tom Rini 
---
 configs/A20-OLinuXino-Lime2_defconfig  | 3 ++-
 configs/A20-OLinuXino-Lime_defconfig   | 3 ++-
 configs/A20-OLinuXino_MICRO_defconfig  | 3 ++-
 configs/A20-Olimex-SOM-EVB_defconfig   | 3 ++-
 configs/Bananapi_defconfig | 3 ++-
 configs/Bananapro_defconfig| 3 ++-
 configs/CSQ_CS908_defconfig| 2 +-
 configs/Colombus_defconfig | 3 ++-
 configs/Cubieboard2_defconfig  | 3 ++-
 configs/Cubietruck_defconfig   | 3 ++-
 configs/Hummingbird_A31_defconfig  | 3 ++-
 configs/Itead_Ibox_A20_defconfig   | 3 ++-
 configs/Lamobo_R1_defconfig| 3 ++-
 configs/Linksprite_pcDuino3_Nano_defconfig | 3 ++-
 configs/Linksprite_pcDuino3_defconfig  | 3 ++-
 configs/Mele_A1000G_quad_defconfig | 2 +-
 configs/Mele_I7_defconfig  | 2 +-
 configs/Mele_M3_defconfig  | 2 +-
 configs/Mele_M5_defconfig  | 2 +-
 configs/Mele_M9_defconfig  | 2 +-
 configs/Orangepi_defconfig | 3 ++-
 configs/Orangepi_mini_defconfig| 3 ++-
 configs/Sinlinx_SinA31s_defconfig  | 2 +-
 configs/Sinovoip_BPI_M2_defconfig  | 3 ++-
 configs/Wits_Pro_A20_DKT_defconfig | 3 ++-
 configs/i12-tvbox_defconfig| 3 ++-
 configs/icnova-a20-swac_defconfig  | 3 ++-
 configs/mixtile_loftq_defconfig| 3 ++-
 drivers/net/Kconfig| 7 +++
 29 files changed, 56 insertions(+), 28 deletions(-)

diff --git a/configs/A20-OLinuXino-Lime2_defconfig 
b/configs/A20-OLinuXino-Lime2_defconfig
index e9d7350..9b40c42 100644
--- a/configs/A20-OLinuXino-Lime2_defconfig
+++ b/configs/A20-OLinuXino-Lime2_defconfig
@@ -9,7 +9,7 @@ CONFIG_USB0_VBUS_DET="PH5"
 CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olinuxino-lime2"
 CONFIG_AHCI=y
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,SATAPWR=SUNXI_GPC(3)"
+CONFIG_SYS_EXTRA_OPTIONS="RGMII,SATAPWR=SUNXI_GPC(3)"
 CONFIG_SPL=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
@@ -21,6 +21,7 @@ CONFIG_CMD_USB_MASS_STORAGE=y
 # CONFIG_SPL_PARTITION_UUIDS is not set
 CONFIG_DFU_RAM=y
 CONFIG_ETH_DESIGNWARE=y
+CONFIG_SUNXI_GMAC=y
 CONFIG_AXP_ALDO3_VOLT=2800
 CONFIG_AXP_ALDO4_VOLT=2800
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/A20-OLinuXino-Lime_defconfig 
b/configs/A20-OLinuXino-Lime_defconfig
index dea2e6b..4229811 100644
--- a/configs/A20-OLinuXino-Lime_defconfig
+++ b/configs/A20-OLinuXino-Lime_defconfig
@@ -7,7 +7,7 @@ CONFIG_MMC0_CD_PIN="PH1"
 CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olinuxino-lime"
 CONFIG_AHCI=y
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,SATAPWR=SUNXI_GPC(3)"
+CONFIG_SYS_EXTRA_OPTIONS="SATAPWR=SUNXI_GPC(3)"
 CONFIG_SPL=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
@@ -16,6 +16,7 @@ CONFIG_SPL=y
 # CONFIG_SPL_ISO_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_ETH_DESIGNWARE=y
+CONFIG_SUNXI_GMAC=y
 CONFIG_AXP_ALDO3_VOLT=2800
 CONFIG_AXP_ALDO4_VOLT=2800
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/A20-OLinuXino_MICRO_defconfig 
b/configs/A20-OLinuXino_MICRO_defconfig
index 703aee1..2c83e08 100644
--- a/configs/A20-OLinuXino_MICRO_defconfig
+++ b/configs/A20-OLinuXino_MICRO_defconfig
@@ -10,7 +10,7 @@ CONFIG_VIDEO_VGA=y
 CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olinuxino-micro"
 CONFIG_AHCI=y
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,SATAPWR=SUNXI_GPB(8)"
+CONFIG_SYS_EXTRA_OPTIONS="SATAPWR=SUNXI_GPB(8)"
 CONFIG_SPL=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
@@ -19,6 +19,7 @@ CONFIG_SPL=y
 # CONFIG_SPL_ISO_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_ETH_DESIGNWARE=y
+CONFIG_SUNXI_GMAC=y
 CONFIG_AXP_ALDO3_VOLT=2800
 CONFIG_AXP_ALDO4_VOLT=2800
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/A20-Olimex-SOM-EVB_defconfig 
b/configs/A20-Olimex-SOM-EVB_defconfig
index a631815..f3ba2f1 100644
--- a/configs/A20-Olimex-SOM-EVB_defconfig
+++ b/configs/A20-Olimex-SOM-EVB_defconfig
@@ -12,7 +12,7 @@ CONFIG_USB0_VBUS_DET="PH5"
 CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olimex-som-evb"
 CONFIG_AHCI=y
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,SATAPWR=SUNXI_GPC(3)"
+CONFIG_SYS_EXTRA_OPTIONS="RGMII,SATAPWR=SUNXI_GPC(3)"
 CONFIG_SPL=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
@@ -21,6 +21,7 @@ CONFIG_SPL=y
 # CONFIG_SPL_ISO_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_ETH_DESIGNWARE=y
+CONFIG_SUNXI_GMAC=y
 CONFIG_AXP_ALDO3_VOLT=2800
 CONFIG_AXP_ALDO4_VOLT=2800
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/Bananapi_defconfig b/configs/Bananapi_defconfig
index 8fccea8..e2672e7 100644
--- a/configs/Bananapi_defconfig
+++ b/configs/Bananapi_defconfig
@@ -8,7 +8,7 @@ CONFIG_GMAC_TX_DELAY=3
 CONFIG_DEFAULT_

Re: [U-Boot] [PATCH v3] arm: socfpga: fix issue with warm reset when CSEL is 0

2017-02-20 Thread Dalon Westergreen
On Mon, 2017-02-20 at 15:24 +0100, Marek Vasut wrote:
> On 02/20/2017 03:21 PM, Dalon Westergreen wrote:
> > 
> > On Mon, 2017-02-20 at 15:14 +0100, Marek Vasut wrote:
> > > 
> > > On 02/20/2017 03:10 PM, Dalon Westergreen wrote:
> > > > 
> > > > 
> > > > On Mon, 2017-02-20 at 10:07 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 02/18/2017 02:34 AM, Dalon Westergreen wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > When CSEL=0x0 the socfpga bootrom does not touch the clock
> > > > > > configuration for the device.  This can lead to a boot failure
> > > > > > on warm resets. This patch disables warm resets when CSEL=0.
> > > > > > This results in the clock and pll configurations being reset
> > > > > > on any reset issued when CSEL=0.
> > > > > > 
> > > > > > Signed-off-by: Dalon Westergreen 
> > > > > 
> > > > > What about my suggestion for V2 about just loading function pointer
> > > > > into
> > > > > the reset jump address register ?
> > > > 
> > > > Frankly, i really dont like relying on the existence of a snippet of
> > > > code in
> > > > the
> > > > onchip ram being untouched to ensure a reboot/reset will occur for this
> > > > csel=0
> > > > case.  i am certain this case is rarely used, and confident that it isnt
> > > > being
> > > > used while trying to preserve sdram contents.
> > > 
> > > Well, you already rely on such snippet, it's SPL. If you corrupt SPL and
> > > do warm reset, your system hangs, I had that multiple times :)
> > 
> > True.  I would argue to just use cold resets but i think arria 10 has more
> > use
> > for the warm reset case.
> 
> OK
> 
> > 
> > > 
> > > > 
> > > > 
> > > > the downside is that the scorecard is reset every boot. so the bootrom
> > > > will
> > > > retry all the spl images again resulting in possibly longer boot times.
> > > 
> > > Is that significant ?
> > 
> > The watchdog timeout is on the order of 1.5 seconds.  That would be for each
> > failed spl.
> 
> Hm, OK. But then your system is kinda broken, so you should expect this
> I guess.

My thought exactly...  I would like to see if Chin Liang or Dinh have any
comments?

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


Re: [U-Boot] Enable AXI bridges

2017-02-20 Thread Dalon Westergreen
On Sun, 2017-02-19 at 10:03 +0200, Hossameldin Eassa wrote:
> when i run the following command from u-boot console
> 
> run bridge_enable_handoff;
> 
> 
> i have the following error
> 
> Error: "bridge_enable_handoff" not defined

In mainline uboot just do

bridge enable

or 

bridge disable

at least for the cyclone v / arria v

--dalon

> I need help to enable AXI bridge from u-boot
> 
> Beast Regards
> Hossameldin
> 
> 
>   Sent with Mailtrack
>  ail.com&idSignature=22>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] common: image: update boot_get_fpga to support arbitrary fpga image

2017-02-20 Thread Dalon Westergreen
On Mon, 2017-02-20 at 10:22 +0100, Michal Simek wrote:
> On 19.2.2017 21:58, Dalon Westergreen wrote:
> > 
> > On Sun, 2017-02-19 at 21:49 +0100, Marek Vasut wrote:
> > > 
> > > On 02/19/2017 09:43 PM, Dalon Westergreen wrote:
> > > > 
> > > > 
> > > > On Sun, 2017-02-19 at 21:07 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 02/19/2017 08:49 PM, Dalon Westergreen wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > The implementation of boot_get_fpga only supported one fpga family.
> > > > > > This modification allows for any of the fpga devices supported by
> > > > > > fpga_load to be used.
> > > > > > 
> > > > > > Signed-off-by: Dalon Westergreen 
> > > > > 
> > > > > +CC Xilinx friends :)
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ---
> > > > > >  common/image.c | 37 ++---
> > > > > >  1 file changed, 22 insertions(+), 15 deletions(-)
> > > > > > 
> > > > > > diff --git a/common/image.c b/common/image.c
> > > > > > index 0f88984..792d371 100644
> > > > > > --- a/common/image.c
> > > > > > +++ b/common/image.c
> > > > > > @@ -1306,7 +1306,7 @@ int boot_get_setup(bootm_headers_t *images,
> > > > > > uint8_t
> > > > > > arch,
> > > > > >  }
> > > > > >  
> > > > > >  #if IMAGE_ENABLE_FIT
> > > > > > -#if defined(CONFIG_FPGA) && defined(CONFIG_FPGA_XILINX)
> > > > > > +#if defined(CONFIG_FPGA)
> > > > > >  int boot_get_fpga(int argc, char * const argv[], bootm_headers_t
> > > > > > *images,
> > > > > >       uint8_t arch, const ulong *ld_start, ulong *
> > > > > > const
> > > > > > ld_len)
> > > > > >  {
> > > > > > @@ -1318,7 +1318,8 @@ int boot_get_fpga(int argc, char * const
> > > > > > argv[],
> > > > > > bootm_headers_t *images,
> > > > > >     int err;
> > > > > >     int devnum = 0; /* TODO support multi fpga platforms */
> > > > > >     const fpga_desc * const desc = fpga_get_desc(devnum);
> > > > > > -   xilinx_desc *desc_xilinx = desc->devdesc;
> > > > > > +   xilinx_desc *desc_xilinx;
> > > > > > +   bitstream_type bstype;
> > > > > >  
> > > > > >     /* Check to see if the images struct has a FIT
> > > > > > configuration */
> > > > > >     if (!genimg_has_config(images)) {
> > > > > > @@ -1365,22 +1366,28 @@ int boot_get_fpga(int argc, char * const
> > > > > > argv[],
> > > > > > bootm_headers_t *images,
> > > > > >     return fit_img_result;
> > > > > >     }
> > > > > >  
> > > > > > -   if (img_len >= desc_xilinx->size) {
> > > > > > +   switch (desc->devtype) {
> > > > > 
> > > > > Do we need the switch statement at all ? We can have full
> > > > > configuration
> > > > > as a default mode of operation and have something like
> > > > > 
> > > > > if (xilinx) {
> > > > >  if (partial reconfiguration) {
> > > > >   do_special_setup();
> > > > >  }
> > > > > }
> > > > 
> > > > I only did the switch stuff b/c i envisioned a need for partial image
> > > > support for socfpga.
> > > 
> > > That'd be seriously cool :)
> > > 
> > > > 
> > > > 
> > > > That said, i would suggest, as you mention, moving
> > > > this to platform specific code and perhaps an indication of the image
> > > > type
> > > > in the fitimage.
> > > 
> > > driver-specific code . It doesn't need to know the imagetype, just that
> > > the blob that you passed in is a partial-reconfiguration blob. I never
> > > really worked with P/R though, do you need some other metadata for that
> > > or is it contained in that P/R bitstream blob already ?
> > 
> > as far as i understand it, it is all in the blob.  All that is needed is
> > knowing
> > whether the blob is a full or partial image.  X seems to just use the image
> > size
> > to determine this, but that means having a table of all devices and their
> > respective full image size.  seems simpler to just specify the image type is
> > partial or not in the fitimage.
> 
> We did that for zynq when we did that for the first time. But not for
> zynqmp. Zynq is maybe still using it but it shouldn't now. It is not
> 100% reliable way. Definitely having DT property is the best option
> because you can add sort of "nop" which extend bitstream size and does
> nothing which breaks that checking.
> 
> For full u-boot there is loadb, loadbp, load and loadp to distinguish it.

That brings up an interesting point, right now the fpga_loadbitstream doesn't
follow the same method as fpga_load for allowing multiple FPGA types to be
supported simultaneously.  Would it not be prudent to move in that direction?
I believe only xilinx implements this right now.

--dalon

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


Re: [U-Boot] [PATCH 1/2] common: image: update boot_get_fpga to support arbitrary fpga image

2017-02-20 Thread Dalon Westergreen
On Mon, 2017-02-20 at 10:24 +0100, Michal Simek wrote:
> On 19.2.2017 22:26, Marek Vasut wrote:
> > 
> > On 02/19/2017 10:21 PM, Dalon Westergreen wrote:
> > > 
> > > On Sun, 2017-02-19 at 22:12 +0100, Marek Vasut wrote:
> > > > 
> > > > On 02/19/2017 09:58 PM, Dalon Westergreen wrote:
> > > > > 
> > > > > 
> > > > > On Sun, 2017-02-19 at 21:49 +0100, Marek Vasut wrote:
> > > > > > 
> > > > > > 
> > > > > > On 02/19/2017 09:43 PM, Dalon Westergreen wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On Sun, 2017-02-19 at 21:07 +0100, Marek Vasut wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On 02/19/2017 08:49 PM, Dalon Westergreen wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > The implementation of boot_get_fpga only supported one fpga
> > > > > > > > > family.
> > > > > > > > > This modification allows for any of the fpga devices supported
> > > > > > > > > by
> > > > > > > > > fpga_load to be used.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Dalon Westergreen 
> > > > > > > > 
> > > > > > > > +CC Xilinx friends :)
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ---
> > > > > > > > >  common/image.c | 37 ++---
> > > > > > > > >  1 file changed, 22 insertions(+), 15 deletions(-)
> > > > > > > > > 
> > > > > > > > > diff --git a/common/image.c b/common/image.c
> > > > > > > > > index 0f88984..792d371 100644
> > > > > > > > > --- a/common/image.c
> > > > > > > > > +++ b/common/image.c
> > > > > > > > > @@ -1306,7 +1306,7 @@ int boot_get_setup(bootm_headers_t
> > > > > > > > > *images,
> > > > > > > > > uint8_t
> > > > > > > > > arch,
> > > > > > > > >  }
> > > > > > > > >  
> > > > > > > > >  #if IMAGE_ENABLE_FIT
> > > > > > > > > -#if defined(CONFIG_FPGA) && defined(CONFIG_FPGA_XILINX)
> > > > > > > > > +#if defined(CONFIG_FPGA)
> > > > > > > > >  int boot_get_fpga(int argc, char * const argv[],
> > > > > > > > > bootm_headers_t
> > > > > > > > > *images,
> > > > > > > > >     uint8_t arch, const ulong *ld_start, ulong
> > > > > > > > > *
> > > > > > > > > const
> > > > > > > > > ld_len)
> > > > > > > > >  {
> > > > > > > > > @@ -1318,7 +1318,8 @@ int boot_get_fpga(int argc, char * const
> > > > > > > > > argv[],
> > > > > > > > > bootm_headers_t *images,
> > > > > > > > >   int err;
> > > > > > > > >   int devnum = 0; /* TODO support multi fpga platforms
> > > > > > > > > */
> > > > > > > > >   const fpga_desc * const desc = fpga_get_desc(devnum);
> > > > > > > > > - xilinx_desc *desc_xilinx = desc->devdesc;
> > > > > > > > > + xilinx_desc *desc_xilinx;
> > > > > > > > > + bitstream_type bstype;
> > > > > > > > >  
> > > > > > > > >   /* Check to see if the images struct has a FIT
> > > > > > > > > configuration */
> > > > > > > > >   if (!genimg_has_config(images)) {
> > > > > > > > > @@ -1365,22 +1366,28 @@ int boot_get_fpga(int argc, char *
> > > > > > > > > const
> > > > > > > > > argv[],
> > > > > > > > > bootm_headers_t *images,
> > > > > > > > >   return fit_img_result;
> > > > > > > > >   }
> > > > > > > > >  
> > > > > > > > > - if (img_len >= desc_xilinx->size) {
> > > > > > > > > + switch (desc->devtype) {
> > > > > > > > 
> > > > > > > > Do we need the switch statement at all ? We can have full
> > > > > > > > configuration
> > > > > > > > as a default mode of operation and have something like
> > > > > > > > 
> > > > > > > > if (xilinx) {
> > > > > > > >  if (partial reconfiguration) {
> > > > > > > >   do_special_setup();
> > > > > > > >  }
> > > > > > > > }
> > > > > > > 
> > > > > > > I only did the switch stuff b/c i envisioned a need for partial
> > > > > > > image
> > > > > > > support for socfpga.
> > > > > > 
> > > > > > That'd be seriously cool :)
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > That said, i would suggest, as you mention, moving
> > > > > > > this to platform specific code and perhaps an indication of the
> > > > > > > image
> > > > > > > type
> > > > > > > in the fitimage.
> > > > > > 
> > > > > > driver-specific code . It doesn't need to know the imagetype, just
> > > > > > that
> > > > > > the blob that you passed in is a partial-reconfiguration blob. I
> > > > > > never
> > > > > > really worked with P/R though, do you need some other metadata for
> > > > > > that
> > > > > > or is it contained in that P/R bitstream blob already ?
> > > > > 
> > > > > as far as i understand it, it is all in the blob.  All that is needed
> > > > > is
> > > > > knowing
> > > > > whether the blob is a full or partial image.  X seems to just use the
> > > > > image
> > > > > size
> > > > > to determine this, but that means having a table of all devices and
> > > > > their
> > > > > respective full image size.  seems simpler to just specify the image
> > > > > type is

Re: [U-Boot] [PATCH v3] arm: socfpga: fix issue with warm reset when CSEL is 0

2017-02-20 Thread Marek Vasut
On 02/20/2017 03:21 PM, Dalon Westergreen wrote:
> On Mon, 2017-02-20 at 15:14 +0100, Marek Vasut wrote:
>> On 02/20/2017 03:10 PM, Dalon Westergreen wrote:
>>>
>>> On Mon, 2017-02-20 at 10:07 +0100, Marek Vasut wrote:

 On 02/18/2017 02:34 AM, Dalon Westergreen wrote:
>
>
> When CSEL=0x0 the socfpga bootrom does not touch the clock
> configuration for the device.  This can lead to a boot failure
> on warm resets. This patch disables warm resets when CSEL=0.
> This results in the clock and pll configurations being reset
> on any reset issued when CSEL=0.
>
> Signed-off-by: Dalon Westergreen 

 What about my suggestion for V2 about just loading function pointer into
 the reset jump address register ?
>>>
>>> Frankly, i really dont like relying on the existence of a snippet of code in
>>> the
>>> onchip ram being untouched to ensure a reboot/reset will occur for this
>>> csel=0
>>> case.  i am certain this case is rarely used, and confident that it isnt
>>> being
>>> used while trying to preserve sdram contents.
>>
>> Well, you already rely on such snippet, it's SPL. If you corrupt SPL and
>> do warm reset, your system hangs, I had that multiple times :)
> 
> True.  I would argue to just use cold resets but i think arria 10 has more use
> for the warm reset case.

OK

>>>
>>> the downside is that the scorecard is reset every boot. so the bootrom will
>>> retry all the spl images again resulting in possibly longer boot times.
>>
>> Is that significant ?
> 
> The watchdog timeout is on the order of 1.5 seconds.  That would be for each
> failed spl.

Hm, OK. But then your system is kinda broken, so you should expect this
I guess.

[...]

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


Re: [U-Boot] [PATCH v3] arm: socfpga: fix issue with warm reset when CSEL is 0

2017-02-20 Thread Dalon Westergreen
On Mon, 2017-02-20 at 15:14 +0100, Marek Vasut wrote:
> On 02/20/2017 03:10 PM, Dalon Westergreen wrote:
> > 
> > On Mon, 2017-02-20 at 10:07 +0100, Marek Vasut wrote:
> > > 
> > > On 02/18/2017 02:34 AM, Dalon Westergreen wrote:
> > > > 
> > > > 
> > > > When CSEL=0x0 the socfpga bootrom does not touch the clock
> > > > configuration for the device.  This can lead to a boot failure
> > > > on warm resets. This patch disables warm resets when CSEL=0.
> > > > This results in the clock and pll configurations being reset
> > > > on any reset issued when CSEL=0.
> > > > 
> > > > Signed-off-by: Dalon Westergreen 
> > > 
> > > What about my suggestion for V2 about just loading function pointer into
> > > the reset jump address register ?
> > 
> > Frankly, i really dont like relying on the existence of a snippet of code in
> > the
> > onchip ram being untouched to ensure a reboot/reset will occur for this
> > csel=0
> > case.  i am certain this case is rarely used, and confident that it isnt
> > being
> > used while trying to preserve sdram contents.
> 
> Well, you already rely on such snippet, it's SPL. If you corrupt SPL and
> do warm reset, your system hangs, I had that multiple times :)

True.  I would argue to just use cold resets but i think arria 10 has more use
for the warm reset case.

> > 
> > the downside is that the scorecard is reset every boot. so the bootrom will
> > retry all the spl images again resulting in possibly longer boot times.
> 
> Is that significant ?

The watchdog timeout is on the order of 1.5 seconds.  That would be for each
failed spl.

> > 
> > The
> > other is that things like sdram content preservation is not likely to work
> > or
> > the csel=0 case (but as i mentioned, i dont see this used often in cyclone5,
> > and never have i seen it when csel=0).
> 
> OK, I didn't see this requirement yet.
> 
> > 
> > > 
> > > btw --- missing before the changelog, without it the changelog will land
> > > in git history.
> > 
> > Thanks
> > 
> > > 
> > > > 
> > > > 
> > > > Changes in v3:
> > > >  - Change implementation to rely on cold reset for CSEL=0. Which
> > > >    is a much simpler approach to dealing with this special case
> > > >    during boot.
> > > > Changes in v2:
> > > >  - Fix checkpatch issues predominently due to whitespace issues
> > > > ---
> > > >  arch/arm/mach-socfpga/include/mach/system_manager.h |  3 +++
> > > >  arch/arm/mach-socfpga/misc.c| 13 -
> > > >  2 files changed, 15 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/arch/arm/mach-socfpga/include/mach/system_manager.h
> > > > b/arch/arm/mach-socfpga/include/mach/system_manager.h
> > > > index c45edea..c9c0b33 100644
> > > > --- a/arch/arm/mach-socfpga/include/mach/system_manager.h
> > > > +++ b/arch/arm/mach-socfpga/include/mach/system_manager.h
> > > > @@ -137,6 +137,9 @@ struct socfpga_system_manager {
> > > >  
> > > >  #define SYSMGR_SDMMC_DRVSEL_SHIFT  0
> > > >  
> > > > +#define SYSMGR_BOOTINFO_CSEL_MASK  0x18
> > > > +#define SYSMGR_BOOTINFO_CSEL_LSB   3
> > > > +
> > > >  /* EMAC Group Bit definitions */
> > > >  #define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII   0x0
> > > >  #define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RGMII  0x1
> > > > diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
> > > > index dd6b53b..9792138 100644
> > > > --- a/arch/arm/mach-socfpga/misc.c
> > > > +++ b/arch/arm/mach-socfpga/misc.c
> > > > @@ -356,6 +356,7 @@ static uint32_t iswgrp_handoff[8];
> > > >  int arch_early_init_r(void)
> > > >  {
> > > >     int i;
> > > > +   unsigned int csel;
> > > >  
> > > >     /*
> > > >      * Write magic value into magic register to unlock support for
> > > > @@ -363,8 +364,18 @@ int arch_early_init_r(void)
> > > >      * value to be written into the register by the bootloader, so
> > > >      * to support that old code, we write it here instead of in the
> > > >      * reset_cpu() function just before resetting the CPU.
> > > > +    *
> > > > +    * For CSEL = 0 we do not want to enable warm resets to ensure
> > > > that
> > > > +    * on reset the clocks and plls are reset to their default
> > > > states
> > > > as
> > > > +    * the bootrom, for CSEL=0, leaves the clocks untouched.  If
> > > > the
> > > > clocks
> > > > +    * and plls are not reset, the bootrom will fail to load the
> > > > spl
> > > > image.
> > > >      */
> > > > -   writel(0xae9efebc, &sysmgr_regs->romcodegrp_warmramgrp_enable);
> > > > +
> > > > +   csel = (readl(&sysmgr_regs->bootinfo) &
> > > > SYSMGR_BOOTINFO_CSEL_MASK)
> > > > > 
> > > > > > 
> > > > > > 
> > > > +   SYSMGR_BOOTINFO_CSEL_LSB;
> > > > +
> > > > +   if (csel)
> > > > +   writel(0xae9efebc, &sysmgr_regs-
> > > > > 
> > > > > romcodegrp_warmramgrp_enable);
> > > >  
> > > >     for (i = 0; i < 8; i++) /* Cache initial SW setting regs
> > > > */
> > > >     

Re: [U-Boot] [PATCH v2] arm: socfpga: fix issue with warm reset when CSEL is 0

2017-02-20 Thread Marek Vasut
On 02/20/2017 03:07 PM, Dalon Westergreen wrote:
[...]
>>> Okay, after much discussion and debate with a colleague..\
>>>
>>> Warm reset is preferred as the bootrom keeps a score card to determine
>>> whether an spl image in the boot media failed or not.  If it failed,
>>> on a warm reset it will not retry the failed image.
>>
>> So what will it do ? Try a valid image from another slot at offset
>> +n*64kiB ?
> 
> Yes.  Or when the scorecard indicates 4 failures it will just stop.

I see.

>>>
>>> The other reason warm resets are preferred is for preservation of the
>>> dram contents.  On a warm reset it is possible to skip io configuration
>>> and dram calibration so that the contents can be saved.
>>
>> That's a good point.
>>
>> But here's a counterargument, what if you upgrade U-Boot ? Warm reset
>> will use the old SPL and the system will likely hang upon reboot ;-)
>>
>>>

 How do you point bootrom to run that snippet instead of whatever is in
 the OCRAM ?

>>>
>>> This code here
>>>

  > > > > > > + writel(ramboot_addr,
  > > > > > > +   &sysmgr_regs-
  > > > > > > >romcodegrp_warmramgrp_execution);
>>
>> Can't you just feed a function pointer pointing into some function which
>> is part of the SPL into that register then ? I think that'd do the same
>> trick, no ?
> 
> Yes, you could, but the idea of putting the code at the end of memory is to
> allow the onchip ram to be used for other things.

Well if you corrupt SPL and do a warm-reset, your system won't boot. We
had that already (and that's another +1 for just doing cold reset, always).

>>>
>>> writes the address to jump to on warm reset.  The register value
>>> is preserved through a warm reset.
>>
>> That's neat, I didn't know that.
>>
>>>


>>>
>>> All that said, i frankly do not believe for the CSEL=0 case
>>> there is any merit to doing the above.  Although it "preserves"
>>> the behaviour as compared to other CSEL values, i think a much
>>> simpler method is to, for the CSEL=0 case, just issue a cold reset.
>>>
>>> As in this case we are touching the clocks, i am not sure the
>>> use cases for a warm reset even hold (sdram preservation, etc).
>>> So i agree with you, and suggest only enabling the warm reset
>>> for cases where CSEL != 0.
>>>
>>> Unless there are objections, I will do just that and resubmit a
>>> patch. (which should now be just a few lines of code)
>>
>> See above, if this actually fixes issue, let's get it in. But in a
>> civilized fashion, no random ad-hoc asm if possible please :)
> 
> In v3 i just used the simpler method of not allowing warm resets for
> csel=0. This is far cleaner, and likely more reliable.

Hm, OK, it's fine either way for me.

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


Re: [U-Boot] [PATCH v3] arm: socfpga: fix issue with warm reset when CSEL is 0

2017-02-20 Thread Marek Vasut
On 02/20/2017 03:10 PM, Dalon Westergreen wrote:
> On Mon, 2017-02-20 at 10:07 +0100, Marek Vasut wrote:
>> On 02/18/2017 02:34 AM, Dalon Westergreen wrote:
>>>
>>> When CSEL=0x0 the socfpga bootrom does not touch the clock
>>> configuration for the device.  This can lead to a boot failure
>>> on warm resets. This patch disables warm resets when CSEL=0.
>>> This results in the clock and pll configurations being reset
>>> on any reset issued when CSEL=0.
>>>
>>> Signed-off-by: Dalon Westergreen 
>>
>> What about my suggestion for V2 about just loading function pointer into
>> the reset jump address register ?
> 
> Frankly, i really dont like relying on the existence of a snippet of code in 
> the
> onchip ram being untouched to ensure a reboot/reset will occur for this csel=0
> case.  i am certain this case is rarely used, and confident that it isnt being
> used while trying to preserve sdram contents.

Well, you already rely on such snippet, it's SPL. If you corrupt SPL and
do warm reset, your system hangs, I had that multiple times :)

> the downside is that the scorecard is reset every boot. so the bootrom will
> retry all the spl images again resulting in possibly longer boot times.

Is that significant ?

> The
> other is that things like sdram content preservation is not likely to work or
> the csel=0 case (but as i mentioned, i dont see this used often in cyclone5,
> and never have i seen it when csel=0).

OK, I didn't see this requirement yet.

>> btw --- missing before the changelog, without it the changelog will land
>> in git history.
> 
> Thanks
> 
>>>
>>> Changes in v3:
>>>  - Change implementation to rely on cold reset for CSEL=0. Which
>>>is a much simpler approach to dealing with this special case
>>>during boot.
>>> Changes in v2:
>>>  - Fix checkpatch issues predominently due to whitespace issues
>>> ---
>>>  arch/arm/mach-socfpga/include/mach/system_manager.h |  3 +++
>>>  arch/arm/mach-socfpga/misc.c| 13 -
>>>  2 files changed, 15 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/mach-socfpga/include/mach/system_manager.h
>>> b/arch/arm/mach-socfpga/include/mach/system_manager.h
>>> index c45edea..c9c0b33 100644
>>> --- a/arch/arm/mach-socfpga/include/mach/system_manager.h
>>> +++ b/arch/arm/mach-socfpga/include/mach/system_manager.h
>>> @@ -137,6 +137,9 @@ struct socfpga_system_manager {
>>>  
>>>  #define SYSMGR_SDMMC_DRVSEL_SHIFT  0
>>>  
>>> +#define SYSMGR_BOOTINFO_CSEL_MASK  0x18
>>> +#define SYSMGR_BOOTINFO_CSEL_LSB   3
>>> +
>>>  /* EMAC Group Bit definitions */
>>>  #define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII   0x0
>>>  #define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RGMII  0x1
>>> diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
>>> index dd6b53b..9792138 100644
>>> --- a/arch/arm/mach-socfpga/misc.c
>>> +++ b/arch/arm/mach-socfpga/misc.c
>>> @@ -356,6 +356,7 @@ static uint32_t iswgrp_handoff[8];
>>>  int arch_early_init_r(void)
>>>  {
>>> int i;
>>> +   unsigned int csel;
>>>  
>>> /*
>>>  * Write magic value into magic register to unlock support for
>>> @@ -363,8 +364,18 @@ int arch_early_init_r(void)
>>>  * value to be written into the register by the bootloader, so
>>>  * to support that old code, we write it here instead of in the
>>>  * reset_cpu() function just before resetting the CPU.
>>> +*
>>> +* For CSEL = 0 we do not want to enable warm resets to ensure that
>>> +* on reset the clocks and plls are reset to their default states
>>> as
>>> +* the bootrom, for CSEL=0, leaves the clocks untouched.  If the
>>> clocks
>>> +* and plls are not reset, the bootrom will fail to load the spl
>>> image.
>>>  */
>>> -   writel(0xae9efebc, &sysmgr_regs->romcodegrp_warmramgrp_enable);
>>> +
>>> +   csel = (readl(&sysmgr_regs->bootinfo) & SYSMGR_BOOTINFO_CSEL_MASK)
>
>>> +   SYSMGR_BOOTINFO_CSEL_LSB;
>>> +
>>> +   if (csel)
>>> +   writel(0xae9efebc, &sysmgr_regs-
 romcodegrp_warmramgrp_enable);
>>>  
>>> for (i = 0; i < 8; i++) /* Cache initial SW setting regs */
>>> iswgrp_handoff[i] = readl(&sysmgr_regs->iswgrp_handoff[i]);
>>>
>>
>>


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


Re: [U-Boot] [PATCH v3] arm: socfpga: fix issue with warm reset when CSEL is 0

2017-02-20 Thread Dalon Westergreen
On Mon, 2017-02-20 at 10:07 +0100, Marek Vasut wrote:
> On 02/18/2017 02:34 AM, Dalon Westergreen wrote:
> > 
> > When CSEL=0x0 the socfpga bootrom does not touch the clock
> > configuration for the device.  This can lead to a boot failure
> > on warm resets. This patch disables warm resets when CSEL=0.
> > This results in the clock and pll configurations being reset
> > on any reset issued when CSEL=0.
> > 
> > Signed-off-by: Dalon Westergreen 
> 
> What about my suggestion for V2 about just loading function pointer into
> the reset jump address register ?

Frankly, i really dont like relying on the existence of a snippet of code in the
onchip ram being untouched to ensure a reboot/reset will occur for this csel=0
case.  i am certain this case is rarely used, and confident that it isnt being
used while trying to preserve sdram contents.

the downside is that the scorecard is reset every boot. so the bootrom will
retry all the spl images again resulting in possibly longer boot times.  The
other is that things like sdram content preservation is not likely to work or
the csel=0 case (but as i mentioned, i dont see this used often in cyclone5,
and never have i seen it when csel=0).

> btw --- missing before the changelog, without it the changelog will land
> in git history.

Thanks

> > 
> > Changes in v3:
> >  - Change implementation to rely on cold reset for CSEL=0. Which
> >    is a much simpler approach to dealing with this special case
> >    during boot.
> > Changes in v2:
> >  - Fix checkpatch issues predominently due to whitespace issues
> > ---
> >  arch/arm/mach-socfpga/include/mach/system_manager.h |  3 +++
> >  arch/arm/mach-socfpga/misc.c| 13 -
> >  2 files changed, 15 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/mach-socfpga/include/mach/system_manager.h
> > b/arch/arm/mach-socfpga/include/mach/system_manager.h
> > index c45edea..c9c0b33 100644
> > --- a/arch/arm/mach-socfpga/include/mach/system_manager.h
> > +++ b/arch/arm/mach-socfpga/include/mach/system_manager.h
> > @@ -137,6 +137,9 @@ struct socfpga_system_manager {
> >  
> >  #define SYSMGR_SDMMC_DRVSEL_SHIFT  0
> >  
> > +#define SYSMGR_BOOTINFO_CSEL_MASK  0x18
> > +#define SYSMGR_BOOTINFO_CSEL_LSB   3
> > +
> >  /* EMAC Group Bit definitions */
> >  #define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII   0x0
> >  #define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RGMII  0x1
> > diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
> > index dd6b53b..9792138 100644
> > --- a/arch/arm/mach-socfpga/misc.c
> > +++ b/arch/arm/mach-socfpga/misc.c
> > @@ -356,6 +356,7 @@ static uint32_t iswgrp_handoff[8];
> >  int arch_early_init_r(void)
> >  {
> >     int i;
> > +   unsigned int csel;
> >  
> >     /*
> >      * Write magic value into magic register to unlock support for
> > @@ -363,8 +364,18 @@ int arch_early_init_r(void)
> >      * value to be written into the register by the bootloader, so
> >      * to support that old code, we write it here instead of in the
> >      * reset_cpu() function just before resetting the CPU.
> > +    *
> > +    * For CSEL = 0 we do not want to enable warm resets to ensure that
> > +    * on reset the clocks and plls are reset to their default states
> > as
> > +    * the bootrom, for CSEL=0, leaves the clocks untouched.  If the
> > clocks
> > +    * and plls are not reset, the bootrom will fail to load the spl
> > image.
> >      */
> > -   writel(0xae9efebc, &sysmgr_regs->romcodegrp_warmramgrp_enable);
> > +
> > +   csel = (readl(&sysmgr_regs->bootinfo) & SYSMGR_BOOTINFO_CSEL_MASK)
> > >>
> > +   SYSMGR_BOOTINFO_CSEL_LSB;
> > +
> > +   if (csel)
> > +   writel(0xae9efebc, &sysmgr_regs-
> > >romcodegrp_warmramgrp_enable);
> >  
> >     for (i = 0; i < 8; i++) /* Cache initial SW setting regs */
> >     iswgrp_handoff[i] = readl(&sysmgr_regs->iswgrp_handoff[i]);
> > 
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] arm: socfpga: fix issue with warm reset when CSEL is 0

2017-02-20 Thread Dalon Westergreen
On Sun, 2017-02-19 at 22:31 +0100, Marek Vasut wrote:
> On 02/18/2017 12:24 AM, Dalon Westergreen wrote:
> > 
> > On Fri, 2017-02-17 at 22:16 +0100, Marek Vasut wrote:
> > > 
> > > On 02/17/2017 07:05 PM, Dalon Westergreen wrote:
> > > > 
> > > > 
> > > > On Wed, 2017-02-15 at 18:53 -0800, Dalon Westergreen wrote:
> > > > > 
> > > > > 
> > > > > On Wed, 2017-02-15 at 23:20 +0100, Marek Vasut wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On 02/15/2017 10:48 PM, Dalon Westergreen wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On Wed, 2017-02-15 at 22:15 +0100, Marek Vasut wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On 02/14/2017 07:28 PM, Dalon Westergreen wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > When CSEL=0x0 the socfpga bootrom does not touch the clock
> > > > > > > > > configuration for the device.  This can lead to a boot failure
> > > > > > > > > on warm resets.  To address this, the bootrom is configured to
> > > > > > > > > run a bit of code in the last 4KB of onchip ram on a warm
> > > > > > > > > reset.
> > > > > > > > > This code puts the PLLs in bypass, disables the bootrom
> > > > > > > > > configuration
> > > > > > > > > to run the code snippet, and issues a warm reset to run the
> > > > > > > > > bootrom.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Dalon Westergreen 
> > > > > > > > > 
> > > > > > > > > --
> > > > > > > > > Changes in V2:
> > > > > > > > >  - Fix checkpatch issues predominently due to whitespace
> > > > > > > > > issues
> > > > > > > > > ---
> > > > > > > > >  arch/arm/mach-socfpga/Makefile |  2 +-
> > > > > > > > >  arch/arm/mach-socfpga/include/mach/clock_manager.h | 26
> > > > > > > > > +++-
> > > > > > > > >  arch/arm/mach-socfpga/include/mach/reset_manager.h |  4 ++
> > > > > > > > >  .../arm/mach-socfpga/include/mach/system_manager.h |  7 ++-
> > > > > > > > >  arch/arm/mach-socfpga/misc.c   | 27
> > > > > > > > > 
> > > > > > > > >  arch/arm/mach-socfpga/reset_clock_manager.S| 71
> > > > > > > > > ++
> > > > > > > > >  6 files changed, 134 insertions(+), 3 deletions(-)
> > > > > > > > >  create mode 100644 arch/arm/mach-
> > > > > > > > > socfpga/reset_clock_manager.S
> > > > > > > > > 
> > > > > > > > > diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-
> > > > > > > > > socfpga/Makefile
> > > > > > > > > index 809cd47..6876ccf 100644
> > > > > > > > > --- a/arch/arm/mach-socfpga/Makefile
> > > > > > > > > +++ b/arch/arm/mach-socfpga/Makefile
> > > > > > > > > @@ -8,7 +8,7 @@
> > > > > > > > >  #
> > > > > > > > >  
> > > > > > > > >  obj-y+= misc.o timer.o reset_manager.o
> > > > > > > > > system_manager.o
> > > > > > > > > clock_manager.o \
> > > > > > > > > -    fpga_manager.o board.o
> > > > > > > > > +    fpga_manager.o board.o reset_clock_manager.o
> > > > > > > > >  
> > > > > > > > >  obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
> > > > > > > > >  
> > > > > > > > > diff --git a/arch/arm/mach-
> > > > > > > > > socfpga/include/mach/clock_manager.h
> > > > > > > > > b/arch/arm/mach-socfpga/include/mach/clock_manager.h
> > > > > > > > > index 803c926..78f63a4 100644
> > > > > > > > > --- a/arch/arm/mach-socfpga/include/mach/clock_manager.h
> > > > > > > > > +++ b/arch/arm/mach-socfpga/include/mach/clock_manager.h
> > > > > > > > > @@ -19,9 +19,12 @@ const unsigned int cm_get_osc_clk_hz(const
> > > > > > > > > int
> > > > > > > > > osc);
> > > > > > > > >  const unsigned int cm_get_f2s_per_ref_clk_hz(void);
> > > > > > > > >  const unsigned int cm_get_f2s_sdr_ref_clk_hz(void);
> > > > > > > > >  
> > > > > > > > > +/* Onchip RAM functions for CSEL=0 */
> > > > > > > > > +void reset_clock_manager(void);
> > > > > > > > > +extern unsigned reset_clock_manager_size;
> > > > > > > > > +
> > > > > > > > >  /* Clock configuration accessors */
> > > > > > > > >  const struct cm_config * const cm_get_default_config(void);
> > > > > > > > > -#endif
> > > > > > > > >  
> > > > > > > > >  struct cm_config {
> > > > > > > > >   /* main group */
> > > > > > > > > @@ -127,6 +130,19 @@ struct socfpga_clock_manager {
> > > > > > > > >   struct socfpga_clock_manager_altera altera;
> > > > > > > > >   u32 _pad_0xe8_0x200[70];
> > > > > > > > >  };
> > > > > > > > > +#endif
> > > > > > > > > +
> > > > > > > > > +#define CLKMGR_CTRL_ADDRESS 0x0
> > > > > > > > 
> > > > > > > > Is this the same as struct socfpga_clock_manager {} ?
> > > > > > > > Why ?
> > > > > > > It is, just defining offsets to use in the assembly calls
> > > > > > 
> > > > > > The asm is IMO not needed
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > >

[U-Boot] [PATCH] ls1046ardb: SPL size reduction in case of non-xip boot

2017-02-20 Thread Sumit Garg
Using changes in this patch we were able to reduce approx 4k
size of u-boot-spl.bin image. Following is breif description of
changes to reduce SPL size:
1. Changes in board/freescale/ls1046ardb/Makefile to remove
   compilation of eth.c and cpld.c in case of SPL build.
2. Changes in board/freescale/ls1046ardb/ls1046ardb.c to keep
   only ddr_init and board_early_init_f funcations in case of SPL
   build.
3. Changes in ls1046a_common.h & ls1046ardb.h to remove driver
   specific macros due to which static data was being compiled in
   case of SPL build.
4. Disable MMC driver from bieng compiled in case of SPL NAND
   build and NAND driver from bieng compiled in case of SPL MMC build.

Signed-off-by: Vinitha Pillai-B57223 
Signed-off-by: Sumit Garg 
---
 board/freescale/ls1046ardb/Makefile |  4 +++-
 board/freescale/ls1046ardb/ls1046ardb.c | 30 --
 include/configs/ls1046a_common.h| 12 ++--
 include/configs/ls1046ardb.h|  7 ++-
 4 files changed, 35 insertions(+), 18 deletions(-)

diff --git a/board/freescale/ls1046ardb/Makefile 
b/board/freescale/ls1046ardb/Makefile
index 348eb76..b92ed0b 100644
--- a/board/freescale/ls1046ardb/Makefile
+++ b/board/freescale/ls1046ardb/Makefile
@@ -4,7 +4,9 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-y += cpld.o
 obj-y += ddr.o
 obj-y += ls1046ardb.o
+ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_SYS_DPAA_FMAN) += eth.o
+obj-y += cpld.o
+endif
diff --git a/board/freescale/ls1046ardb/ls1046ardb.c 
b/board/freescale/ls1046ardb/ls1046ardb.c
index 33a58cf..bb03479 100644
--- a/board/freescale/ls1046ardb/ls1046ardb.c
+++ b/board/freescale/ls1046ardb/ls1046ardb.c
@@ -24,6 +24,21 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+int dram_init(void)
+{
+   gd->ram_size = initdram(0);
+
+   return 0;
+}
+
+int board_early_init_f(void)
+{
+   fsl_lsch2_early_init_f();
+
+   return 0;
+}
+
+#ifndef CONFIG_SPL_BUILD
 int checkboard(void)
 {
static const char *freq[2] = {"100.00MHZ", "156.25MHZ"};
@@ -56,20 +71,6 @@ int checkboard(void)
return 0;
 }
 
-int dram_init(void)
-{
-   gd->ram_size = initdram(0);
-
-   return 0;
-}
-
-int board_early_init_f(void)
-{
-   fsl_lsch2_early_init_f();
-
-   return 0;
-}
-
 int board_init(void)
 {
struct ccsr_scfg *scfg = (struct ccsr_scfg *)CONFIG_SYS_FSL_SCFG_ADDR;
@@ -168,3 +169,4 @@ int ft_board_setup(void *blob, bd_t *bd)
 
return 0;
 }
+#endif
diff --git a/include/configs/ls1046a_common.h b/include/configs/ls1046a_common.h
index be65e4f..c884b95 100644
--- a/include/configs/ls1046a_common.h
+++ b/include/configs/ls1046a_common.h
@@ -109,24 +109,28 @@
 #define CONFIG_SYS_I2C_MXC_I2C3
 #define CONFIG_SYS_I2C_MXC_I2C4
 
+#ifndef CONFIG_SPL_BUILD
 /* Command line configuration */
 #define CONFIG_CMD_ENV
+#endif
 
+#if !(defined(CONFIG_SPL_BUILD) && defined(CONFIG_NAND_BOOT))
 /* MMC */
 #ifdef CONFIG_MMC
 #define CONFIG_FSL_ESDHC
 #define CONFIG_SYS_FSL_MMC_HAS_CAPBLT_VS33
 #endif
+#endif
 
 #define CONFIG_FSL_CAAM/* Enable SEC/CAAM */
 
+#ifndef CONFIG_SPL_BUILD
 #define CONFIG_SYS_DPAA_QBMAN  /* Support Q/Bman */
-
 /* FMan ucode */
 #define CONFIG_SYS_DPAA_FMAN
 #ifdef CONFIG_SYS_DPAA_FMAN
 #define CONFIG_SYS_FM_MURAM_SIZE   0x6
-
+#endif
 #ifdef CONFIG_SD_BOOT
 /*
  * PBL SD boot image should stored at 0x1000(8 blocks), the size of the image 
is
@@ -159,6 +163,7 @@
 #define CONFIG_HWCONFIG
 #define HWCONFIG_BUFFER_SIZE   128
 
+#ifndef CONFIG_SPL_BUILD
 /* Initial environment variables */
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"hwconfig=fsl_ddr:bank_intlv=auto\0"\
@@ -176,13 +181,16 @@
 #define CONFIG_BOOTARGS"console=ttyS0,115200 
root=/dev/ram0 " \
"earlycon=uart8250,mmio,0x21c0500 " \
MTDPARTS_DEFAULT
+#endif
 /* Monitor Command Prompt */
 #define CONFIG_SYS_CBSIZE  512 /* Console I/O Buffer Size */
 #define CONFIG_SYS_PBSIZE  (CONFIG_SYS_CBSIZE + \
sizeof(CONFIG_SYS_PROMPT) + 16)
 #define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE /* Boot args buffer */
 #define CONFIG_SYS_LONGHELP
+#ifndef CONFIG_SPL_BUILD
 #define CONFIG_CMDLINE_EDITING 1
+#endif
 #define CONFIG_AUTO_COMPLETE
 #define CONFIG_SYS_MAXARGS 64  /* max command args */
 
diff --git a/include/configs/ls1046ardb.h b/include/configs/ls1046ardb.h
index a96aa65..9bc4cbc 100644
--- a/include/configs/ls1046ardb.h
+++ b/include/configs/ls1046ardb.h
@@ -49,13 +49,14 @@
 #endif
 #endif
 
+#if !(defined(CONFIG_SPL_BUILD) && defined(CONFIG_SD_BOOT))
 /* IFC */
 #define CONFIG_FSL_IFC
-
 /*
  * NAND Flash Definitions
  */
 #define CONFIG_NAND_FSL_IFC
+#endif
 
 #define CONFIG_SYS_NAND_BASE   0x7e80
 #define CONFIG_SYS_NAND_BASE_PHYS  CONFIG_SYS_NAND_BASE
@@ -156,10 +157,12 @@
 #define CONFIG_POWER

Re: [U-Boot] [PATCH v3 1/3] ARM: dts: am43xx: Add u-boot specific dtsi

2017-02-20 Thread Tom Rini
On Mon, Feb 20, 2017 at 11:05:31AM +0530, Lokesh Vutla wrote:

> Add u-boot specific dtsi for am43xx-gp-evm so
> that it will be used for SPL.
> 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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


Re: [U-Boot] [PATCH v3 3/3] configs: am43xx_evm: Enable SPL_DM

2017-02-20 Thread Tom Rini
On Mon, Feb 20, 2017 at 11:05:33AM +0530, Lokesh Vutla wrote:

> Enable SPL_DM on all AM43xx based platforms
> 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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


Re: [U-Boot] [PATCH v3 2/3] config: am43xx_usbhost_boot: sync with am43xx_evm

2017-02-20 Thread Tom Rini
On Mon, Feb 20, 2017 at 11:05:32AM +0530, Lokesh Vutla wrote:

> am43xx_evm defconfig has been modified without making changes
> in am43xx_usbhost_boot defconfig. Synce here.
> 
> Signed-off-by: Lokesh Vutla 
> ---
>  configs/am43xx_evm_usbhost_boot_defconfig | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/configs/am43xx_evm_usbhost_boot_defconfig 
> b/configs/am43xx_evm_usbhost_boot_defconfig
> index 5775ab16dd..e22bc7fbdb 100644
> --- a/configs/am43xx_evm_usbhost_boot_defconfig
> +++ b/configs/am43xx_evm_usbhost_boot_defconfig
> @@ -48,13 +48,18 @@ CONFIG_DFU_MMC=y
>  CONFIG_DFU_RAM=y
>  CONFIG_DFU_SF=y
>  CONFIG_DM_GPIO=y
> +CONFIG_DM_I2C=y
>  CONFIG_DM_MMC=y
>  # CONFIG_DM_MMC_OPS is not set
>  CONFIG_MMC_OMAP_HS=y
> +CONFIG_DM_SPI_FLASH=y
>  CONFIG_SPI_FLASH=y
> +CONFIG_SPI_FLASH_BAR=y
>  CONFIG_SPI_FLASH_MACRONIX=y
> +CONFIG_DM_ETH=y
>  CONFIG_DM_SERIAL=y
>  CONFIG_SYS_NS16550=y
> +CONFIG_DM_SPI=y
>  CONFIG_TI_QSPI=y
>  CONFIG_TIMER=y
>  CONFIG_OMAP_TIMER=y

I like 3/3.  But instead of 2/3 here we should be moving I2C/SPI/ETH/etc
stuff over to imply (at the board level) as that still allows the user
to turn things off in their .config file, unlike a select.  Thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH 7/7] ti: wdt: Enable OMAP watchdog in u-boot's board_f.c

2017-02-20 Thread Tom Rini
On Mon, Feb 20, 2017 at 08:35:05AM +0100, Lukasz Majewski wrote:
> Hi Tom,
> 
> > On Sun, Feb 19, 2017 at 11:24:42PM +0100, Lukasz Majewski wrote:
> > > The init_func_watchdog_init called in u-boot's board_f.c's
> > > init_sequence is responsible for enabling WDT in u-boot and notify
> > > user about it.
> > > 
> > > Several other architectures have adopted it for this purpose.
> > > This code does the same with OMAP watchdog.
> > > 
> > > Signed-off-by: Lukasz Majewski 
> > > ---
> > >  common/board_f.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/common/board_f.c b/common/board_f.c
> > > index ae6cd85..5dd56a4 100644
> > > --- a/common/board_f.c
> > > +++ b/common/board_f.c
> > > @@ -120,7 +120,7 @@ static int init_func_watchdog_init(void)
> > >   defined(CONFIG_M68K) || defined(CONFIG_MICROBLAZE) || \
> > >   defined(CONFIG_SH) || defined(CONFIG_AT91SAM9_WATCHDOG) ||
> > > \ defined(CONFIG_DESIGNWARE_WATCHDOG) || \
> > > - defined(CONFIG_IMX_WATCHDOG))
> > > + defined(CONFIG_IMX_WATCHDOG) ||
> > > defined(CONFIG_OMAP_WATCHDOG))
> > 
> > Please introduce a new symbol here with a reasonable name and select
> > it on the various platforms, then make OMAP also select it.  Thanks!
> 
> Something similar to CONFIG_SPL_HW_WATCHDOG bu for u-boot?
> 
> That would be something like CONFIG_HW_WATCHDOG_INIT ...

CONFIG_HW_WATCHDOG_INIT sounds good, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH v3 1/7] arm: dra7xx: move CONFIG_DRA7XX to Kconfig

2017-02-20 Thread Tom Rini
On Mon, Feb 20, 2017 at 09:18:47AM +0200, Uri Mashiach wrote:
> 
> 
> On 02/19/2017 05:15 PM, Tom Rini wrote:
> >On Sun, Feb 19, 2017 at 03:27:13PM +0200, Uri Mashiach wrote:
> >
> >>The symbol CONFIG_DRA7XX is needed for Kconfig conditions.
> >>
> >>Cc: Lokesh Vutla 
> >>Signed-off-by: Uri Mashiach 
> >>---
> >>V3 -> V2: new commit
> >>
> >> board/compulab/cl-som-am57x/Kconfig | 4 
> >> board/ti/am57xx/Kconfig | 4 
> >> board/ti/dra7xx/Kconfig | 4 
> >> include/configs/am57xx_evm.h| 2 --
> >> include/configs/cl-som-am57x.h  | 2 --
> >> include/configs/dra7xx_evm.h| 2 --
> >> scripts/config_whitelist.txt| 1 -
> >> 7 files changed, 12 insertions(+), 7 deletions(-)
> >
> >We need to introduce the symbol in arch/arm/mach-omap2/omap5/Kconfig and
> >then select it under the appropriate boards.  Thanks!
> 
> Maybe instead of selecting it under the appropriate board it can be
> defaulted to yes in the board's Kconfig?

No.  The correct thing is to select it (if it's not something that can
be opted out of, for example what type of SoC this is) or imply'd if
it's something that really should be enabled, but the user can opt out
of.  Doing a default yes in the board Kconfig was a stop-gap until
'imply' came around.  Thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH v3 2/7] arm: usb: dra7xx: xHCI registers based on USB port index

2017-02-20 Thread Roger Quadros
Hi,

On 19/02/17 18:26, Igor Grinberg wrote:
> Hi guys,
> 
> On 02/19/17 17:15, Tom Rini wrote:
>> On Sun, Feb 19, 2017 at 04:13:02PM +0100, Marek Vasut wrote:
>>> On 02/19/2017 03:55 PM, Uri Mashiach wrote:


 On 02/19/2017 04:27 PM, Marek Vasut wrote:
> On 02/19/2017 02:27 PM, Uri Mashiach wrote:
>> Modify the determination of the base address of xHCI registers of DRA7XX
>> targets.
>> Before the commit: by the target.
>> After the commit: by the USB port index.
>>
>> Cc: Lokesh Vutla 
>> Cc: Marek Vasut 
>> Signed-off-by: Uri Mashiach 
>> ---
>> V1 -> V2: Replace the commit "fix XHCI registers base address".
>> V2 -> V3: Replace the commit "reintroduce the CONFIG_AM57XX symbol"
>>
>>  configs/dra7xx_evm_defconfig|  1 +
>>  configs/dra7xx_hs_evm_defconfig |  1 +
>>  drivers/usb/host/Kconfig| 16 
>>  include/linux/usb/xhci-omap.h   |  6 --
>>  4 files changed, 22 insertions(+), 2 deletions(-)
>>
>> diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig
>> index 26b26cc..1f47f92 100644

 [...]

>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>> index 5129a57..440fbcf 100644
>> --- a/drivers/usb/host/Kconfig
>> +++ b/drivers/usb/host/Kconfig
>> @@ -43,6 +43,22 @@ config USB_XHCI_ZYNQMP
>>  help
>>Enables support for the on-chip xHCI controller on Xilinx
>> ZynqMP SoCs.
>>
>> +choice
>> +prompt "DRA7XX xHCI USB index select"
>> +depends on DRA7XX
>> +
>> +config USB_XHCI_DRA7XX_INDEX0
>> +bool "USB0"
>> +help
>> +  DRA7XX xHCI USB0.
>> +
>> +config USB_XHCI_DRA7XX_INDEX1
>> +bool "USB1"
>> +help
>> +  DRA7XX xHCI USB1.
>
> What is this all about ? Shouldn't this come from DT ? And what if I
> want to use both XHCI ? This looks totally bogus ...
> 
> Right, both XHCIs cannot be used with current driver and we do not have
> the time to fix it by our own... may be TI has?

This is still a work in progress for us
http://lists.denx.de/pipermail/u-boot/2016-January/239931.html

> Remember, you've accepted the driver and following patches, right?
> 
> Regarding DT, do we have a DT as a requirement to run USB in U-Boot?
> I don't remember this happening and I think it shouldn't be a requirement.
> 
>

 The support for both XHCI is currently missing.
 This could be a temporary solution until the DT solution.
 The current situation is worse - selecting USB0 or USB1 based on the
 target.
>>>
>>> So we're replacing it with equally bad solution ?
> 
> I don't think equally applies here...
> This IS an improvement. Of course it is not like you would want it to be,
> but still it is from a platform POV.
> 
>>> Hmmm , no.
>>> The MW will open mid-march, there's about a month to fix this,
>>> so please do.
>>
>> Do note that the relevant driver here is not yet using DM_USB.
> 
> Yes, the driver should be fixed some day. We would really like to take
> this task, but unfortunately, we cannot, at least not right now.
> But we do need that USB working on our board and not only on TI EVMs...
> 
> Tom,
> Should we fall back to v1 and have a worse solution for the base addresses?
> 

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


[U-Boot] [PATCH] ls1043ardb: SPL size reduction in case of non-xip boot

2017-02-20 Thread Sumit Garg
Using changes in this patch we were able to reduce approx 10k
size of u-boot-spl.bin image. Following is breif description of
changes to reduce SPL size:
1. Changes in board/freescale/ls1043ardb/Makefile to remove
   compilation of eth.c and cpld.c in case of SPL build.
2. Changes in board/freescale/ls1043ardb/ls1043ardb.c to keep
   only ddr_init and board_early_init_f funcations in case of SPL
   build.
3. Changes in ls1043a_common.h & ls1043ardb.h to remove driver
   specific macros due to which static data was being compiled in
   case of SPL build.
4. Disable MMC driver from bieng compiled in case of SPL NAND
   build and NAND driver from bieng compiled in case of SPL MMC build.
5. Remove I2C driver support from SPL in case of LS1043ARDB.

Signed-off-by: Vinitha Pillai-B57223 
Signed-off-by: Sumit Garg 
---
 board/freescale/ls1043ardb/Makefile |  4 +++-
 board/freescale/ls1043ardb/ls1043ardb.c | 32 ++--
 configs/ls1043ardb_sdcard_defconfig |  1 -
 include/configs/ls1043a_common.h| 14 --
 include/configs/ls1043ardb.h|  6 ++
 5 files changed, 39 insertions(+), 18 deletions(-)

diff --git a/board/freescale/ls1043ardb/Makefile 
b/board/freescale/ls1043ardb/Makefile
index 5fe1cc9..2a4452e 100644
--- a/board/freescale/ls1043ardb/Makefile
+++ b/board/freescale/ls1043ardb/Makefile
@@ -4,7 +4,9 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-y += cpld.o
 obj-y += ddr.o
 obj-y += ls1043ardb.o
+ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_SYS_DPAA_FMAN) += eth.o
+obj-y += cpld.o
+endif
diff --git a/board/freescale/ls1043ardb/ls1043ardb.c 
b/board/freescale/ls1043ardb/ls1043ardb.c
index e213128..5a76742 100644
--- a/board/freescale/ls1043ardb/ls1043ardb.c
+++ b/board/freescale/ls1043ardb/ls1043ardb.c
@@ -29,6 +29,22 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+int dram_init(void)
+{
+   gd->ram_size = initdram(0);
+
+   return 0;
+}
+
+int board_early_init_f(void)
+{
+   fsl_lsch2_early_init_f();
+
+   return 0;
+}
+
+#ifndef CONFIG_SPL_BUILD
+
 int checkboard(void)
 {
static const char *freq[2] = {"100.00MHZ", "156.25MHZ"};
@@ -67,20 +83,6 @@ int checkboard(void)
return 0;
 }
 
-int dram_init(void)
-{
-   gd->ram_size = initdram(0);
-
-   return 0;
-}
-
-int board_early_init_f(void)
-{
-   fsl_lsch2_early_init_f();
-
-   return 0;
-}
-
 int board_init(void)
 {
struct ccsr_scfg *scfg = (struct ccsr_scfg *)CONFIG_SYS_FSL_SCFG_ADDR;
@@ -222,3 +224,5 @@ u16 flash_read16(void *addr)
 
return (((val) >> 8) & 0x00ff) | (((val) << 8) & 0xff00);
 }
+
+#endif
diff --git a/configs/ls1043ardb_sdcard_defconfig 
b/configs/ls1043ardb_sdcard_defconfig
index 3df426d..e3d328b 100644
--- a/configs/ls1043ardb_sdcard_defconfig
+++ b/configs/ls1043ardb_sdcard_defconfig
@@ -2,7 +2,6 @@ CONFIG_ARM=y
 CONFIG_TARGET_LS1043ARDB=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
-CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_SPL_ENV_SUPPORT=y
diff --git a/include/configs/ls1043a_common.h b/include/configs/ls1043a_common.h
index c4b05e0..e8ba031 100644
--- a/include/configs/ls1043a_common.h
+++ b/include/configs/ls1043a_common.h
@@ -82,6 +82,7 @@
 #define CONFIG_SYS_MONITOR_LEN 0xa
 #endif
 
+#if !(defined(CONFIG_SPL_BUILD) && defined(CONFIG_SD_BOOT))
 /* IFC */
 #if !defined(CONFIG_QSPI_BOOT) && !defined(CONFIG_SD_BOOT_QSPI)
 #define CONFIG_FSL_IFC
@@ -103,6 +104,7 @@
 #define CONFIG_FLASH_SHOW_PROGRESS 45  /* count down from 45/5: 9..1 */
 #endif
 #endif
+#endif
 
 /* I2C */
 #define CONFIG_SYS_I2C
@@ -112,6 +114,7 @@
 #define CONFIG_SYS_I2C_MXC_I2C3
 #define CONFIG_SYS_I2C_MXC_I2C4
 
+#ifndef CONFIG_SPL_BUILD
 /* PCIe */
 #define CONFIG_PCIE1   /* PCIE controller 1 */
 #define CONFIG_PCIE2   /* PCIE controller 2 */
@@ -125,13 +128,19 @@
 
 /* Command line configuration */
 #define CONFIG_CMD_ENV
+#endif
 
+#if !(defined(CONFIG_SPL_BUILD) && defined(CONFIG_NAND_BOOT))
 /*  MMC  */
 #ifdef CONFIG_MMC
 #define CONFIG_FSL_ESDHC
 #define CONFIG_SYS_FSL_MMC_HAS_CAPBLT_VS33
 #endif
+#endif
+
+#define CONFIG_FSL_CAAM/* Enable SEC/CAAM */
 
+#ifndef CONFIG_SPL_BUILD
 /*  DSPI  */
 #define CONFIG_FSL_DSPI
 #ifdef CONFIG_FSL_DSPI
@@ -145,8 +154,6 @@
 #endif
 #endif
 
-#define CONFIG_FSL_CAAM/* Enable SEC/CAAM */
-
 /* FMan ucode */
 #define CONFIG_SYS_DPAA_FMAN
 #ifdef CONFIG_SYS_DPAA_FMAN
@@ -179,6 +186,7 @@
 #define CONFIG_SYS_QE_FMAN_FW_LENGTH   0x1
 #define CONFIG_SYS_FDT_PAD (0x3000 + CONFIG_SYS_QE_FMAN_FW_LENGTH)
 #endif
+#endif
 
 /* Miscellaneous configurable options */
 #define CONFIG_SYS_LOAD_ADDR   (CONFIG_SYS_DDR_SDRAM_BASE + 0x1000)
@@ -186,6 +194,7 @@
 #define CONFIG_HWCONFIG
 #define HWCONFIG_BUFFER_SIZE   128
 
+#ifndef CONFIG_SPL_BUILD
 #if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_SD_BOOT_QSPI)
 #define MTDPARTS_DEFAULT "mtdparts=spi0.0:1m(

[U-Boot] Enable AXI bridges

2017-02-20 Thread Hossameldin Eassa
when i run the following command from u-boot console

run bridge_enable_handoff;


i have the following error

Error: "bridge_enable_handoff" not defined


I need help to enable AXI bridge from u-boot

Beast Regards
Hossameldin


  Sent with Mailtrack

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


[U-Boot] [PATCH v3 1/2] mmc: pci: Add CONFIG_MMC_PCI

2017-02-20 Thread Andy Shevchenko
From: Felipe Balbi 

We don't want pci_mmc to compile every time x86 compiles, only when
there's a platform that needs it. For that reason, we're adding a new
CONFIG_MMC_PCI which platforms can choose to enable.

Suggested-by: Jaehoon Chung 
Reviewed-by: Bin Meng 
Signed-off-by: Felipe Balbi 
Signed-off-by: Andy Shevchenko 
---
 configs/bayleybay_defconfig | 1 +
 configs/conga-qeval20-qa3-e3845-internal-uart_defconfig | 1 +
 configs/conga-qeval20-qa3-e3845_defconfig   | 1 +
 configs/crownbay_defconfig  | 1 +
 configs/dfi-bt700-q7x-151_defconfig | 1 +
 configs/galileo_defconfig   | 1 +
 configs/minnowmax_defconfig | 1 +
 configs/theadorable-x86-dfi-bt700_defconfig | 1 +
 drivers/mmc/Kconfig | 8 
 drivers/mmc/Makefile| 2 +-
 10 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/configs/bayleybay_defconfig b/configs/bayleybay_defconfig
index c6aa24f9be..d2f9f24a19 100644
--- a/configs/bayleybay_defconfig
+++ b/configs/bayleybay_defconfig
@@ -48,6 +48,7 @@ CONFIG_REGMAP=y
 CONFIG_SYSCON=y
 CONFIG_CPU=y
 CONFIG_MMC=y
+CONFIG_MMC_PCI=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_SDMA=y
 CONFIG_SPI_FLASH=y
diff --git a/configs/conga-qeval20-qa3-e3845-internal-uart_defconfig 
b/configs/conga-qeval20-qa3-e3845-internal-uart_defconfig
index 890d28ce69..d96bfcbe14 100644
--- a/configs/conga-qeval20-qa3-e3845-internal-uart_defconfig
+++ b/configs/conga-qeval20-qa3-e3845-internal-uart_defconfig
@@ -50,6 +50,7 @@ CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_INTEL=y
 CONFIG_WINBOND_W83627=y
 CONFIG_MMC=y
+CONFIG_MMC_PCI=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_SDMA=y
 CONFIG_SPI_FLASH=y
diff --git a/configs/conga-qeval20-qa3-e3845_defconfig 
b/configs/conga-qeval20-qa3-e3845_defconfig
index 6e4cd843d9..1642bf2926 100644
--- a/configs/conga-qeval20-qa3-e3845_defconfig
+++ b/configs/conga-qeval20-qa3-e3845_defconfig
@@ -49,6 +49,7 @@ CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_INTEL=y
 CONFIG_WINBOND_W83627=y
 CONFIG_MMC=y
+CONFIG_MMC_PCI=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_SDMA=y
 CONFIG_SPI_FLASH=y
diff --git a/configs/crownbay_defconfig b/configs/crownbay_defconfig
index 13a00c2a17..4a88f5f3c5 100644
--- a/configs/crownbay_defconfig
+++ b/configs/crownbay_defconfig
@@ -37,6 +37,7 @@ CONFIG_REGMAP=y
 CONFIG_SYSCON=y
 CONFIG_CPU=y
 CONFIG_MMC=y
+CONFIG_MMC_PCI=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_SDMA=y
 CONFIG_SPI_FLASH=y
diff --git a/configs/dfi-bt700-q7x-151_defconfig 
b/configs/dfi-bt700-q7x-151_defconfig
index ce447f540a..d5bd66f83c 100644
--- a/configs/dfi-bt700-q7x-151_defconfig
+++ b/configs/dfi-bt700-q7x-151_defconfig
@@ -47,6 +47,7 @@ CONFIG_CPU=y
 CONFIG_DM_I2C=y
 CONFIG_NUVOTON_NCT6102D=y
 CONFIG_MMC=y
+CONFIG_MMC_PCI=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_SDMA=y
 CONFIG_SPI_FLASH=y
diff --git a/configs/galileo_defconfig b/configs/galileo_defconfig
index 570f9ea810..f60abc3422 100644
--- a/configs/galileo_defconfig
+++ b/configs/galileo_defconfig
@@ -42,6 +42,7 @@ CONFIG_REGMAP=y
 CONFIG_SYSCON=y
 CONFIG_CPU=y
 CONFIG_MMC=y
+CONFIG_MMC_PCI=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_SDMA=y
 CONFIG_SPI_FLASH=y
diff --git a/configs/minnowmax_defconfig b/configs/minnowmax_defconfig
index 5f61f2a19c..8dac1d72fb 100644
--- a/configs/minnowmax_defconfig
+++ b/configs/minnowmax_defconfig
@@ -47,6 +47,7 @@ CONFIG_REGMAP=y
 CONFIG_SYSCON=y
 CONFIG_CPU=y
 CONFIG_MMC=y
+CONFIG_MMC_PCI=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_SDMA=y
 CONFIG_SPI_FLASH=y
diff --git a/configs/theadorable-x86-dfi-bt700_defconfig 
b/configs/theadorable-x86-dfi-bt700_defconfig
index cde33bbfe1..1703cee841 100644
--- a/configs/theadorable-x86-dfi-bt700_defconfig
+++ b/configs/theadorable-x86-dfi-bt700_defconfig
@@ -47,6 +47,7 @@ CONFIG_CPU=y
 CONFIG_DM_I2C=y
 CONFIG_NUVOTON_NCT6102D=y
 CONFIG_MMC=y
+CONFIG_MMC_PCI=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_SDMA=y
 CONFIG_SPI_FLASH=y
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 01d1dbfb1b..af8436f337 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -122,6 +122,14 @@ config MMC_MXS
 
  If unsure, say N.
 
+config MMC_PCI
+   bool "Support for MMC controllers on PCI"
+   help
+ This selects PCI-based MMC controllers.
+ If you have an MMC controller on a PCI bus, say Y here.
+
+ If unsure, say N.
+
 config MMC_OMAP_HS
bool "TI OMAP High Speed Multimedia Card Interface support"
help
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 8e922db3f1..9fccac8ead 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -34,7 +34,7 @@ obj-$(CONFIG_MVEBU_MMC) += mvebu_mmc.o
 obj-$(CONFIG_MMC_OMAP_HS)  += omap_hsmmc.o
 obj-$(CONFIG_MMC_MXC)  += mxcmmc.o
 obj-$(CONFIG_MMC_MXS)  += mxsmmc.o
-obj-$(CONFIG_X86) += pci_mmc.o
+obj-$(CONFIG_MMC_PCI)  

[U-Boot] [PATCH v3 2/2] mmc: tangier: Add Intel Tangier eMMC/SDHCI driver

2017-02-20 Thread Andy Shevchenko
From: Felipe Balbi 

This patch adds Intel Tangier eMMC/SDHCI driver.

Intel Tangier SoC contains a hybrid of PCI and non-PCI devices. SDHCI
controller is one of the devices which are *not* on a PCI and, hence,
cannot be enumerated by standard PCI means. This driver, allows for
SDHCI controller on Tangier SoC to work in U-Boot.

Signed-off-by: Vincent Tinelli 
Signed-off-by: Felipe Balbi 
Signed-off-by: Andy Shevchenko 
---
 drivers/mmc/Kconfig | 14 
 drivers/mmc/Makefile|  1 +
 drivers/mmc/tangier_sdhci.c | 81 +
 3 files changed, 96 insertions(+)
 create mode 100644 drivers/mmc/tangier_sdhci.c

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index af8436f337..7238aade42 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -318,6 +318,20 @@ config MMC_SDHCI_XENON
 
  If unsure, say N.
 
+config MMC_SDHCI_TANGIER
+   bool "Tangier SDHCI controller support"
+   depends on DM_MMC && BLK
+   depends on MMC_SDHCI
+   help
+ This selects support for SDHCI controller on Tanginer
+ SoC. Note that this controller does not sit on PCI bus and,
+ hence, cannot be enumerated by standard PCI means.
+
+ If you're using an Intel Tangier SoC (available on Intel
+ Edison board), say Y here.
+
+ If unsure, say N.
+
 config MMC_SDHCI_TEGRA
bool "SDHCI platform support for the Tegra SD/MMC Controller"
depends on TEGRA
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 9fccac8ead..b210d2c3b3 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_MMC_SDHCI_PIC32) += pic32_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_ROCKCHIP)   += rockchip_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_S5P)+= s5p_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_SPEAR)  += spear_sdhci.o
+obj-$(CONFIG_MMC_SDHCI_TANGIER)+= tangier_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_TEGRA)  += tegra_mmc.o
 obj-$(CONFIG_MMC_SDHCI_XENON)  += xenon_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_ZYNQ)   += zynq_sdhci.o
diff --git a/drivers/mmc/tangier_sdhci.c b/drivers/mmc/tangier_sdhci.c
new file mode 100644
index 00..77b18e75f0
--- /dev/null
+++ b/drivers/mmc/tangier_sdhci.c
@@ -0,0 +1,81 @@
+/*
+ * Copyright (c) 2017 Intel Corporation
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SDHCI_TANGIER_FMAX 2
+#define SDHCI_TANGIER_FMIN 40
+
+struct sdhci_tangier_plat {
+   struct mmc_config cfg;
+   struct mmc mmc;
+   void __iomem *ioaddr;
+};
+
+static int sdhci_tangier_bind(struct udevice *dev)
+{
+   struct sdhci_tangier_plat *plat = dev_get_platdata(dev);
+
+   return sdhci_bind(dev, &plat->mmc, &plat->cfg);
+}
+
+static int sdhci_tangier_probe(struct udevice *dev)
+{
+   struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+   struct sdhci_tangier_plat *plat = dev_get_platdata(dev);
+   struct sdhci_host *host = dev_get_priv(dev);
+   fdt_addr_t base;
+   int ret;
+
+   base = dev_get_addr(dev);
+   if (base == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   plat->ioaddr = devm_ioremap(dev, base, SZ_1K);
+   if (!plat->ioaddr)
+   return -ENOMEM;
+
+   host->name = dev->name;
+   host->ioaddr = plat->ioaddr;
+   host->quirks = SDHCI_QUIRK_NO_HISPD_BIT | SDHCI_QUIRK_BROKEN_VOLTAGE |
+  SDHCI_QUIRK_32BIT_DMA_ADDR | SDHCI_QUIRK_WAIT_SEND_CMD;
+
+   /* MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195 */
+   host->voltages = MMC_VDD_165_195;
+
+   ret = sdhci_setup_cfg(&plat->cfg, host, SDHCI_TANGIER_FMAX,
+   SDHCI_TANGIER_FMIN);
+   if (ret)
+   return ret;
+
+   upriv->mmc = &plat->mmc;
+   host->mmc = &plat->mmc;
+   host->mmc->priv = host;
+
+   return sdhci_probe(dev);
+}
+
+static const struct udevice_id sdhci_tangier_match[] = {
+   { .compatible = "intel,sdhci-tangier" },
+   { /* sentinel */ }
+};
+
+U_BOOT_DRIVER(sdhci_tangier) = {
+   .name   = "sdhci-tangier",
+   .id = UCLASS_MMC,
+   .of_match   = sdhci_tangier_match,
+   .bind   = sdhci_tangier_bind,
+   .probe  = sdhci_tangier_probe,
+   .ops= &sdhci_ops,
+   .priv_auto_alloc_size = sizeof(struct sdhci_host),
+   .platdata_auto_alloc_size = sizeof(struct sdhci_tangier_plat),
+};
-- 
2.11.0

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


[U-Boot] Driver-model - Issue with early device_probe

2017-02-20 Thread Suneel Garapati
Hi All,
 Request for help on the below issue.

 Hi Simon,
 As I suppose it is related to driver-model in u-boot.

 One of the boards at Cavium has SPI as PCI device and I am trying to
 enable CONFIG_ENV_IS_IN_SPI_FLASH for this device.

 Below is the sequence which causes crash, due to early of probing for
 all parent and children in PCI node of devicetree. As some drivers,
 like network, have to have eth_initialize called before to have global
 structures initialized.

 1. Init_sequence_r in board_r.c calls initr_env before any other
 framework init is called.
 2. initr_env checks for the device to load environment from, SPI,
 calls env_relocate_spec from env_sf.c
 3. SPI probe is triggered from env_relocate_spec, because of driver
 model framework, this internally triggers device_probe.
 4. device_probe iterates on spi parent, PCI, and its childs and calls
 probe on each of them.
 5. This early probe call may work for some frameowrks but not for all.
 6. Network drivers like thunderx_smi (pci device) probe calls
 mdio_register, internally calls miiphy_get_dev_by_name which tries to
 access list mii_devs, which is uninitialized at this moment and
 crashes.
 7. mii_devs is initialized through mii_phy_init, called from
 initr_net->eth_initialize->eth_common_init.
 8. initr_net is called much later in init_sequence_r.

 There is no CONFIG item to have control on environment storage devices
 like MMC,SPI,NOR flash device probes to be singled out in the
 initr_env initcall.

 Please suggest on how to fix it or workaround. Also, let me know if I
 am missing something obvious here.

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


[U-Boot] [PATCH v5 8/9] STiH410-B2260: Add device tree

2017-02-20 Thread patrice.chotard
From: Patrice Chotard 

This device tree has been extracted from v4.9 kernel

Signed-off-by: Patrice Chotard 
Reviewed-by: Tom Rini 
Reviewed-by: Simon Glass 
---
 arch/arm/dts/Makefile |2 +
 arch/arm/dts/st-pincfg.h  |   71 ++
 arch/arm/dts/stih407-clock.dtsi   |  326 ++
 arch/arm/dts/stih407-family.dtsi  |  977 +++
 arch/arm/dts/stih407-pinctrl.dtsi | 1303 +
 arch/arm/dts/stih410-b2260.dts|  226 
 arch/arm/dts/stih410-clock.dtsi   |  347 ++
 arch/arm/dts/stih410-pinctrl.dtsi |   34 +
 arch/arm/dts/stih410.dtsi |  454 +++
 drivers/mmc/Kconfig   |2 +-
 include/dt-bindings/clock/stih407-clks.h  |   90 ++
 include/dt-bindings/clock/stih410-clks.h  |   25 +
 include/dt-bindings/interrupt-controller/irq-st.h |   30 +
 include/dt-bindings/mfd/st-lpc.h  |   16 +
 include/dt-bindings/reset/stih407-resets.h|   65 +
 15 files changed, 3967 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/st-pincfg.h
 create mode 100644 arch/arm/dts/stih407-clock.dtsi
 create mode 100644 arch/arm/dts/stih407-family.dtsi
 create mode 100644 arch/arm/dts/stih407-pinctrl.dtsi
 create mode 100644 arch/arm/dts/stih410-b2260.dts
 create mode 100644 arch/arm/dts/stih410-clock.dtsi
 create mode 100644 arch/arm/dts/stih410-pinctrl.dtsi
 create mode 100644 arch/arm/dts/stih410.dtsi
 create mode 100644 include/dt-bindings/clock/stih407-clks.h
 create mode 100644 include/dt-bindings/clock/stih410-clks.h
 create mode 100644 include/dt-bindings/interrupt-controller/irq-st.h
 create mode 100644 include/dt-bindings/mfd/st-lpc.h
 create mode 100644 include/dt-bindings/reset/stih407-resets.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index eb68c20..231ebfa 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -339,6 +339,8 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
 
 dtb-$(CONFIG_ARCH_ASPEED) += ast2500-evb.dtb
 
+dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb
+
 targets += $(dtb-y)
 
 # Add any required device tree compiler flags here
diff --git a/arch/arm/dts/st-pincfg.h b/arch/arm/dts/st-pincfg.h
new file mode 100644
index 000..4851c38
--- /dev/null
+++ b/arch/arm/dts/st-pincfg.h
@@ -0,0 +1,71 @@
+#ifndef _ST_PINCFG_H_
+#define _ST_PINCFG_H_
+
+/* Alternate functions */
+#define ALT1   1
+#define ALT2   2
+#define ALT3   3
+#define ALT4   4
+#define ALT5   5
+#define ALT6   6
+#define ALT7   7
+
+/* Output enable */
+#define OE (1 << 27)
+/* Pull Up */
+#define PU (1 << 26)
+/* Open Drain */
+#define OD (1 << 25)
+#define RT (1 << 23)
+#define INVERTCLK  (1 << 22)
+#define CLKNOTDATA (1 << 21)
+#define DOUBLE_EDGE(1 << 20)
+#define CLK_A  (0 << 18)
+#define CLK_B  (1 << 18)
+#define CLK_C  (2 << 18)
+#define CLK_D  (3 << 18)
+
+/* User-frendly defines for Pin Direction */
+   /* oe = 0, pu = 0, od = 0 */
+#define IN (0)
+   /* oe = 0, pu = 1, od = 0 */
+#define IN_PU  (PU)
+   /* oe = 1, pu = 0, od = 0 */
+#define OUT(OE)
+   /* oe = 1, pu = 0, od = 1 */
+#define BIDIR  (OE | OD)
+   /* oe = 1, pu = 1, od = 1 */
+#define BIDIR_PU   (OE | PU | OD)
+
+/* RETIME_TYPE */
+/*
+ * B Mode
+ * Bypass retime with optional delay parameter
+ */
+#define BYPASS (0)
+/*
+ * R0, R1, R0D, R1D modes
+ * single-edge data non inverted clock, retime data with clk
+ */
+#define SE_NICLK_IO(RT)
+/*
+ * RIV0, RIV1, RIV0D, RIV1D modes
+ * single-edge data inverted clock, retime data with clk
+ */
+#define SE_ICLK_IO (RT | INVERTCLK)
+/*
+ * R0E, R1E, R0ED, R1ED modes
+ * double-edge data, retime data with clk
+ */
+#define DE_IO  (RT | DOUBLE_EDGE)
+/*
+ * CIV0, CIV1 modes with inverted clock
+ * Retiming the clk pins will park clock & reduce the noise within the core.
+ */
+#define ICLK   (RT | CLKNOTDATA | INVERTCLK)
+/*
+ * CLK0, CLK1 modes with non-inverted clock
+ * Retiming the clk pins will park clock & reduce the noise within the core.
+ */
+#define NICLK  (RT | CLKNOTDATA)
+#endif /* _ST_PINCFG_H_ */
diff --git a/arch/arm/dts/stih407-clock.dtsi b/arch/arm/dts/stih407-clock.dtsi
new file mode 100644
index 000..13029c0
--- /dev/null
+++ b/arch/arm/dts/stih407-clock.dtsi
@@ -0,0 +1,326 @@
+/*
+ * Copyright (C) 2014 STMicroelectronics R&D Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+/ {
+   clocks {

[U-Boot] [PATCH v2] Add single register pin controller driver

2017-02-20 Thread James Balean
Hi All,

2017-02-10 13:35 GMT+09:00 Masahiro Yamada :
> That's right.
> Then, the "dev" in device_probe() represents
> the peripheral, such as i2c.
> 
> Not a pin-config node, like i2c0_pins.

Masahiro, have a look at the call to set_state_simple from 
pinctrl_select_state_simple (in drivers/pinctrl/pinctrl-uclass.c). It is at 
this point that the pinctrl node becomes the 'dev' parameter, and the former 
'dev' then becomes the second 'periph' parameter.

---
/*
 * For simplicity, assume the first device of PINCTRL uclass
 * is the correct one.  This is most likely OK as there is
 * usually only one pinctrl device on the system.
 */
ret = uclass_get_device(UCLASS_PINCTRL, 0, &pctldev);
if (ret)
return ret;

ops = pinctrl_get_ops(pctldev);
if (!ops->set_state_simple) {
dev_dbg(dev, "set_state_simple op missing\n");
return -ENOSYS;
}

return ops->set_state_simple(pctldev, dev);
---

Reviewed-by: James Balean 

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


[U-Boot] [PATCH v2 2/2] board: ge: bx50v3: apply the proper register setting to fix the voltage peak issue

2017-02-20 Thread Ken Lin
Apply the proper setting for the reserved bits in SetDes Test and System Mode 
Control register
to avoid the voltage peak issue while we do the IEEE PHY comformance test

Signed-off-by: Ken Lin 
---
Changes from v1
- New commit message

 board/ge/bx50v3/bx50v3.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
index 80b4ba1b8b..0acf655c0e 100644
--- a/board/ge/bx50v3/bx50v3.c
+++ b/board/ge/bx50v3/bx50v3.c
@@ -307,7 +307,8 @@ static int mx6_rgmii_rework(struct phy_device *phydev)
/* set debug port address: SerDes Test and System Mode Control */
phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05);
/* enable rgmii tx clock delay */
-   phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x100);
+   /* set the reserved bits to avoid board specific voltage peak issue*/
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x3D47);
 
return 0;
 }
-- 
2.11.0

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


[U-Boot] Veyron-speedy u-boot

2017-02-20 Thread Vagrant Cascadian
> I'm very glad that it's possible to chainload and the output comes out
> on the laptop screen

Really excited to hear about your work on this!

I'd be happy to test it on a veryon-speedy system I have available;
Please feel free to CC me with updates.

live well,
  vagrant


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


[U-Boot] [PATCH] board: ns2: Add support for Broadcom Northstar 2

2017-02-20 Thread Jon Mason
Add support for the Broadcom Northstar2 SoC and SVK (bcm958712k).  The
BCM5871X is a series of quad-core 64-bit 2GHz ARMv8 Cortex-A57
processors targeting a broad range of networking applications.

Signed-off-by: Jon Mason 
---
 arch/arm/Kconfig  |  9 ++
 board/broadcom/bcm958712k/MAINTAINERS |  6 
 board/broadcom/bcmns2/Kconfig | 15 +
 board/broadcom/bcmns2/Makefile|  7 +
 board/broadcom/bcmns2/northstar2.c| 57 +++
 configs/bcm958712k_defconfig  |  9 ++
 include/configs/bcm_northstar2.h  | 55 +
 7 files changed, 158 insertions(+)
 create mode 100644 board/broadcom/bcm958712k/MAINTAINERS
 create mode 100644 board/broadcom/bcmns2/Kconfig
 create mode 100644 board/broadcom/bcmns2/Makefile
 create mode 100644 board/broadcom/bcmns2/northstar2.c
 create mode 100644 configs/bcm958712k_defconfig
 create mode 100644 include/configs/bcm_northstar2.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0229800..6eb125b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -471,6 +471,14 @@ config TARGET_BCMNSP
bool "Support bcmnsp"
select CPU_V7
 
+config TARGET_BCMNS2
+   bool "Support Broadcom Northstar2"
+   select ARM64
+   help
+ Support for Broadcom Northstar 2 SoCs.  NS2 is a quad-core 64-bit
+ ARMv8 Cortex-A57 processors targeting a broad range of networking
+ applications
+
 config ARCH_EXYNOS
bool "Samsung EXYNOS"
select DM
@@ -1090,6 +1098,7 @@ source "board/broadcom/bcm23550_w1d/Kconfig"
 source "board/broadcom/bcm28155_ap/Kconfig"
 source "board/broadcom/bcmcygnus/Kconfig"
 source "board/broadcom/bcmnsp/Kconfig"
+source "board/broadcom/bcmns2/Kconfig"
 source "board/cavium/thunderx/Kconfig"
 source "board/cirrus/edb93xx/Kconfig"
 source "board/compulab/cm_t335/Kconfig"
diff --git a/board/broadcom/bcm958712k/MAINTAINERS 
b/board/broadcom/bcm958712k/MAINTAINERS
new file mode 100644
index 000..024fb14
--- /dev/null
+++ b/board/broadcom/bcm958712k/MAINTAINERS
@@ -0,0 +1,6 @@
+BCM958712K BOARD
+M: Jon Mason 
+S: Maintained
+F: board/broadcom/bcmns2/
+F: include/configs/bcm_northstar2.h
+F: configs/bcm958712k_defconfig
diff --git a/board/broadcom/bcmns2/Kconfig b/board/broadcom/bcmns2/Kconfig
new file mode 100644
index 000..3ac6724
--- /dev/null
+++ b/board/broadcom/bcmns2/Kconfig
@@ -0,0 +1,15 @@
+if TARGET_BCMNS2
+
+config SYS_BOARD
+   default "bcmns2"
+
+config SYS_VENDOR
+   default "broadcom"
+
+config SYS_SOC
+   default "ns2"
+
+config SYS_CONFIG_NAME
+   default "bcm_northstar2"
+
+endif
diff --git a/board/broadcom/bcmns2/Makefile b/board/broadcom/bcmns2/Makefile
new file mode 100644
index 000..f6ddd80
--- /dev/null
+++ b/board/broadcom/bcmns2/Makefile
@@ -0,0 +1,7 @@
+#
+# Copyright 2016 Broadcom Ltd.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  := northstar2.o
diff --git a/board/broadcom/bcmns2/northstar2.c 
b/board/broadcom/bcmns2/northstar2.c
new file mode 100644
index 000..fad5ca1
--- /dev/null
+++ b/board/broadcom/bcmns2/northstar2.c
@@ -0,0 +1,57 @@
+/*
+ * (C) Copyright 2016 Broadcom Ltd.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include 
+#include 
+#include 
+
+static struct mm_region ns2_mem_map[] = {
+   {
+   .virt = 0x0UL,
+   .phys = 0x0UL,
+   .size = 0x8000UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+   }, {
+   .virt = 0x8000UL,
+   .phys = 0x8000UL,
+   .size = 0xff8000UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+   }, {
+   /* List terminator */
+   0,
+   }
+};
+
+struct mm_region *mem_map = ns2_mem_map;
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+   return 0;
+}
+
+int dram_init(void)
+{
+   gd->ram_size = PHYS_SDRAM_1_SIZE + PHYS_SDRAM_2_SIZE;
+   return 0;
+}
+
+void dram_init_banksize(void)
+{
+   gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
+   gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
+
+   gd->bd->bi_dram[1].start = CONFIG_SYS_SDRAM_BASE + PHYS_SDRAM_1_SIZE;
+   gd->bd->bi_dram[1].size = PHYS_SDRAM_2_SIZE;
+}
+
+void reset_cpu(ulong addr)
+{
+   psci_system_reset();
+}
diff --git a/configs/bcm958712k_defconfig b/configs/bcm958712k_defconfig
new file mode 100644
index 000..b00d3d6
--- /dev/null
+++ b/configs/bcm958712k_defconfig
@@ -0,0 +1,9 @@
+CONFIG_ARM=y
+CONFIG_TARGET_BCMNS2=y
+CONFIG_IDENT_STRING=" Broadcom Northstar 2"
+CONFIG_BOOTDELAY=30
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SYS_PROMPT="u-boot> "
+# CONFIG_CMD_IMLS is not set
+CONFIG_SYS_NS16550=y
+CONFIG_OF_LIBFDT=y
diff --git a/include/configs/bcm_northstar2.h

[U-Boot] [PATCH v2 1/2] board: ge: bx50v3: fix AR8033 reset timing issue

2017-02-20 Thread Ken Lin
Add the delay (10ms) to ensure the clock is stable and to meet the 
clock-to-reset(1ms) requirement recommended in the AR8033 datasheet

Signed-off-by: Ken Lin 
---
Changes from v1
- Fix the missing Signed-off-by issue

 board/ge/bx50v3/bx50v3.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
index 2fc1144cda..80b4ba1b8b 100644
--- a/board/ge/bx50v3/bx50v3.c
+++ b/board/ge/bx50v3/bx50v3.c
@@ -103,8 +103,9 @@ static void setup_iomux_enet(void)
 
/* Reset AR8033 PHY */
gpio_direction_output(IMX_GPIO_NR(1, 28), 0);
-   udelay(500);
+   mdelay(10);
gpio_set_value(IMX_GPIO_NR(1, 28), 1);
+   mdelay(1);
 }
 
 static iomux_v3_cfg_t const usdhc2_pads[] = {
-- 
2.11.0

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


Re: [U-Boot] [PATCH v1 1/2] sunxi (sun50i): support i2c on A64 (pin-config, clocking)

2017-02-20 Thread Andre Przywara
Hi,

On 20/02/17 10:21, Dr. Philipp Tomsich wrote:
> 
>> On 20 Feb 2017, at 11:18, Andre Przywara > > wrote:
>>
>>> Our board’s early-stage normally shouldn't need to do anything on
>>> this I2C
>>> bus, but customer boards may come up with a use for it (image this going
>>> towards battery/power managing circuitry on a baseboard).
>>
>> In this case we should definitely remove these three lines.
> 
> I should have said “we don’t do anything with this I2C bus, but it’s
> available
> for customer use via the edge connector and a header on our eval-board”.
> 
> As there’s no way to enable pull-ups via a command in U-Boot, I’d prefer
> to keep these pull ups configured.

So either make this a separate patch or use some other method of
enabling this, but please keep this board specific setting separate from
the SoC enablement.

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


Re: [U-Boot] [PATCH] rockchip: firefly: configs: remove config_spl_of_platdata

2017-02-20 Thread Jacob Chen
Hi,

2017-02-17 4:44 GMT+08:00 Simon Glass :
> Hi,
>
> On 14 February 2017 at 23:41, Jacob Chen  wrote:
>> Hi Kever,
>>
>>
>> Kever Yang wrote on 2017年02月15日 14:13:
>>>
>>> Hi Jacob,
>>>
>>> On 02/15/2017 11:06 AM, Jacob Chen wrote:

 We should remove config_spl_of_platdata to build u-boot-spl-dtb.bin
 rather than u-boot-spl-nodtb.bin
 since we use spl_back_to_brom.
>>>
>>>
>>> Have you try with CONFIG_SPL_OF_PLATDATA on and without SPL_BACK_TO_BROM?
>>>
>>> If this works on firefly, then we can still leave it as an example to show
>>> how both way works.
>>>
>>
>> Firefly had been using CONFIG_SPL_OF_PLATDATA and it works well.
>> Just it will make trouble for other things to generate the u-boot blob,
>> like yocto, sdk build scripts, guides...
>>
>> At first, I also want to keep  CONFIG_SPL_OF_PLATDATA in firefly, but later
>> I find that i have to do a lot of unnecessary work to deal with it,
>> so now I would like one chip use one way to generate the u-boot blob.
>
> How about having a separate board config like firefly-rk3288-dt so
> that we keep the non-of-platdata alive? It only needs a separate
> defconfig, which is pretty esay.
>
> Regards,
> Simon
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot


I send a  patch "rockchip: firefly: configs: add a new config to keep
non-of-platdata" to save old config.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] rockchip: firefly: configs: add a new config to keep non-of-platdata

2017-02-20 Thread Jacob Chen
The firefly config have been changed to use SPL_BACK_TO_BROM, but we also want 
keep
CONFIG_SPL_OF_PLATDATA as an example.

So add this separate defconfig to show how both way works.

Signed-off-by: Jacob Chen 
---

 configs/firefly-nodtb-rk3288_defconfig | 78 ++
 1 file changed, 78 insertions(+)
 create mode 100644 configs/firefly-nodtb-rk3288_defconfig

diff --git a/configs/firefly-nodtb-rk3288_defconfig 
b/configs/firefly-nodtb-rk3288_defconfig
new file mode 100644
index 000..3ed17b4
--- /dev/null
+++ b/configs/firefly-nodtb-rk3288_defconfig
@@ -0,0 +1,78 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_ROCKCHIP_RK3288=y
+CONFIG_TARGET_FIREFLY_RK3288=y
+CONFIG_SPL_STACK_R_ADDR=0x8
+CONFIG_DEFAULT_DEVICE_TREE="rk3288-firefly"
+CONFIG_SILENT_CONSOLE=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BOOTZ=y
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_GPIO=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_PMIC=y
+CONFIG_CMD_REGULATOR=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_SPL_OF_PLATDATA=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
+# CONFIG_SPL_SIMPLE_BUS is not set
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_LED=y
+CONFIG_LED_GPIO=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_DM_ETH=y
+CONFIG_NETDEVICES=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PINCTRL=y
+CONFIG_SPL_PINCTRL=y
+# CONFIG_SPL_PINCTRL_FULL is not set
+CONFIG_ROCKCHIP_RK3288_PINCTRL=y
+CONFIG_DM_PMIC=y
+# CONFIG_SPL_PMIC_CHILDREN is not set
+CONFIG_PMIC_ACT8846=y
+CONFIG_REGULATOR_ACT8846=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_RAM=y
+CONFIG_SPL_RAM=y
+CONFIG_DEBUG_UART=y
+CONFIG_DEBUG_UART_BASE=0xff69
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550=y
+CONFIG_ROCKCHIP_SERIAL=y
+CONFIG_SYSRESET=y
+CONFIG_DM_VIDEO=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_CONSOLE_SCROLL_LINES=10
+CONFIG_USE_TINY_PRINTF=y
+CONFIG_CMD_DHRYSTONE=y
+CONFIG_ERRNO_STR=y
+# CONFIG_SPL_OF_LIBFDT is not set
-- 
1.9.1

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


Re: [U-Boot] [PATCH v1 1/2] sunxi (sun50i): support i2c on A64 (pin-config, clocking)

2017-02-20 Thread Dr. Philipp Tomsich

> On 20 Feb 2017, at 11:18, Andre Przywara  wrote:
> 
>> Our board’s early-stage normally shouldn't need to do anything on this I2C
>> bus, but customer boards may come up with a use for it (image this going
>> towards battery/power managing circuitry on a baseboard).
> 
> In this case we should definitely remove these three lines.

I should have said “we don’t do anything with this I2C bus, but it’s available
for customer use via the edge connector and a header on our eval-board”.

As there’s no way to enable pull-ups via a command in U-Boot, I’d prefer
to keep these pull ups configured.

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


Re: [U-Boot] [PATCH v1 1/2] sunxi (sun50i): support i2c on A64 (pin-config, clocking)

2017-02-20 Thread Andre Przywara
Hi,

On 18/02/17 12:03, Dr. Philipp Tomsich wrote:
> 
>> On 18 Feb 2017, at 02:15, André Przywara > > wrote:
>>
>>> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
>>> index bba9b7c..a47b113 100644
>>> --- a/board/sunxi/board.c
>>> +++ b/board/sunxi/board.c
>>> @@ -485,90 +485,108 @@ int board_mmc_init(bd_t *bis)
>>> void i2c_init_board(void)
>>> {
>>> #ifdef CONFIG_I2C0_ENABLE
>>> #if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN5I) ||
>>> defined(CONFIG_MACH_SUN7I)
>>> sunxi_gpio_set_cfgpin(SUNXI_GPB(0), SUN4I_GPB_TWI0);
>>> sunxi_gpio_set_cfgpin(SUNXI_GPB(1), SUN4I_GPB_TWI0);
>>> clock_twi_onoff(0, 1);
>>> #elif defined(CONFIG_MACH_SUN6I)
>>> sunxi_gpio_set_cfgpin(SUNXI_GPH(14), SUN6I_GPH_TWI0);
>>> sunxi_gpio_set_cfgpin(SUNXI_GPH(15), SUN6I_GPH_TWI0);
>>> clock_twi_onoff(0, 1);
>>> #elif defined(CONFIG_MACH_SUN8I)
>>> sunxi_gpio_set_cfgpin(SUNXI_GPH(2), SUN8I_GPH_TWI0);
>>> sunxi_gpio_set_cfgpin(SUNXI_GPH(3), SUN8I_GPH_TWI0);
>>> clock_twi_onoff(0, 1);
>>> +#elif defined(CONFIG_MACH_SUN50I)
>>> +sunxi_gpio_set_cfgpin(SUNXI_GPH(0), SUN50I_GPH_TWI0);
>>> +sunxi_gpio_set_cfgpin(SUNXI_GPH(1), SUN50I_GPH_TWI0);
>>> +/* The A64-uQ7 doesn't have external pull-ups for I2C[01]. */
>>> +sunxi_gpio_set_pull(SUNXI_GPH(0), SUNXI_GPIO_PULL_UP);
>>> +sunxi_gpio_set_pull(SUNXI_GPH(1), SUNXI_GPIO_PULL_UP);
>>
>> Is this specific to your board?
> 
> No. This is board-specific for any board.
> Every I2C bus will need pull-ups, but it’s not defined where on the bus
> these
> should/will be located.  There’s even a few I2C peripherals that have the
> pull-ups integrated.

I think I got this, but it's just that no other SoC above is doing this,
also your comment hints at this being specific to your board.
So for the sake of a generic A64 I2C support patch, I'd rather remove
those lines from this file for now. You could keep a separate patch that
fixes this for your board build.

> In other words: this was one of many things that triggered me going after
> support DM (and it was the one change that caused me to look at the size
> of the SPL and whether there’s still space available for DM drivers when
> using OF_PLATDATA … but we both know the conclusion).
> 
>> Which isn't officially supported yet?
> 
> I can send patches with the board-specific DTS and defconfig, if that
> helps ;-)

You can of course always do, but to be honest this was more a rhetorical
question. I'd rather avoid putting some board specific code into this
function in this way.
I clearly see where you are going to, but please keep this patch sane.

> Just wanted until we get dual-IO SPI reads validated (and the DM changes
> merged), so it can be a single changeset instead of relying on multiple
> updates to the same files.
> 
> If you think it’s worthwhile to send out a defconfig that doesn’t depend
> on DM together with the DTS (without the gpiobank-entries), let me know.

I don't think it's necessary for now, we have enough stuff on our plate
already ;-)
All of those patches seem to work toward a saner board specific
configuration, so you could post your defconfig & DT at the end to
motivate these changes.

>> And having a DM conversion would make this easily fixable via DT, I guess?
> 
> Yes. But that will still leave the SPL/TPL discussion for another day,
> as the SPL still depends on these programmatic settings.
> 
> Our board’s early-stage normally shouldn't need to do anything on this I2C
> bus, but customer boards may come up with a use for it (image this going
> towards battery/power managing circuitry on a baseboard).

In this case we should definitely remove these three lines.

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


Re: [U-Boot] U-boot FIT Signature

2017-02-20 Thread Markus Valentin
Hi,

On Fri, 2017-02-17 at 13:55 -0800, Rick Altherr wrote:
> How would you verify that the public key hasn't been tampered with?
> 
> On Fri, Feb 17, 2017 at 12:37 AM, Maria Sepulveda 
> wrote:
> 
> > 
> > Good morning,
> > 
> > I am working with FIT image in U-Boot 2013.07. I have configured the image
> > verification with signed image and kernel boots fine so, I would like to
> > know if I can store my public key in an external device (like crypto-memory
> > or an i2c device) because I am storing the key in DBT with the
> > CONFIG_OF_CONTROL configuration.
Imho is perfectly fine to store the public key in the u-boot.dtb for most
needs(specially for using it with fit-images). Do you have a specific reason
for wanting to store it elsewhere?
> >  The aim of this is that U-Boot should check the i2c address of my
> > external device, read the public key and verify the signed image later.
> > I work with am335x board and Kernel 3.14.
As Rick suggests you should verify your public key with a checksum which is
somehow protected from being tampered. In the most cases there is some OTP-
Fuse-Register that can do the job.

best regards

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


Re: [U-Boot] [PATCH v2 2/2] mmc: tangier: Add Intel Tangier eMMC/SDHCI driver

2017-02-20 Thread Andy Shevchenko
On Sat, Feb 18, 2017 at 6:34 AM, Bin Meng  wrote:
> Hi Andy,
>
> On Fri, Feb 17, 2017 at 9:02 PM, Andy Shevchenko
>  wrote:
>> From: Felipe Balbi 
>>
>> This patch adds Intel Tangier eMMC/SDHCI driver.
>
> So this eMMC/SDHC controller is not on PCI bus, correct?

Yes and no.

It's so called "fake PCI". Intel MID have couple of real PCI devices
and many "fake" ones.
They have (semi-)complaint programming interface, but do not fully
follow PCI spec.

To implement it as a PCI controller we need a PCI bus quirk. I dunno
if on this stage it makes sense for U-Boot.

Our goal is to have minimum support of Intel Edison board in U-Boot
upstream from which we (or anybody else) might continue to enhance.

> If so, can
> you add more comments to the commit message?

I would add something as per this discussion.

>
>>
>> Signed-off-by: Vincent Tinelli 
>> Signed-off-by: Felipe Balbi 
>> Signed-off-by: Andy Shevchenko 
>> ---
>>  drivers/mmc/Kconfig |  5 
>>  drivers/mmc/Makefile|  1 +
>>  drivers/mmc/tangier_sdhci.c | 72 
>> +
>>  3 files changed, 78 insertions(+)
>>  create mode 100644 drivers/mmc/tangier_sdhci.c
>>
>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
>> index af8436f337..e060547b1d 100644
>> --- a/drivers/mmc/Kconfig
>> +++ b/drivers/mmc/Kconfig
>> @@ -318,6 +318,11 @@ config MMC_SDHCI_XENON
>>
>>   If unsure, say N.
>>
>> +config MMC_SDHCI_TANGIER
>> +   bool "Tangier SDHCI controller support"
>> +   depends on DM_MMC && BLK
>> +   depends on MMC_SDHCI
>
> Please add a "help" here, like mentioning it's not on PCI bus (if I am 
> correct)?
>
>> +
>>  config MMC_SDHCI_TEGRA
>> bool "SDHCI platform support for the Tegra SD/MMC Controller"
>> depends on TEGRA
>> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
>> index 9fccac8ead..b210d2c3b3 100644
>> --- a/drivers/mmc/Makefile
>> +++ b/drivers/mmc/Makefile
>> @@ -61,6 +61,7 @@ obj-$(CONFIG_MMC_SDHCI_PIC32) += pic32_sdhci.o
>>  obj-$(CONFIG_MMC_SDHCI_ROCKCHIP)   += rockchip_sdhci.o
>>  obj-$(CONFIG_MMC_SDHCI_S5P)+= s5p_sdhci.o
>>  obj-$(CONFIG_MMC_SDHCI_SPEAR)  += spear_sdhci.o
>> +obj-$(CONFIG_MMC_SDHCI_TANGIER)+= tangier_sdhci.o
>>  obj-$(CONFIG_MMC_SDHCI_TEGRA)  += tegra_mmc.o
>>  obj-$(CONFIG_MMC_SDHCI_XENON)  += xenon_sdhci.o
>>  obj-$(CONFIG_MMC_SDHCI_ZYNQ)   += zynq_sdhci.o
>> diff --git a/drivers/mmc/tangier_sdhci.c b/drivers/mmc/tangier_sdhci.c
>> new file mode 100644
>> index 00..5ab2afa8b5
>> --- /dev/null
>> +++ b/drivers/mmc/tangier_sdhci.c
>> @@ -0,0 +1,72 @@
>

> Please add a file header with author and license information here.

I will ask Felipe.

>> +   ret = sdhci_setup_cfg(&plat->cfg, host, 2, 40);
>
> Can we use some defines for 2 and 40?

Ditto.

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


Re: [U-Boot] [PATCH 1/2] common: image: update boot_get_fpga to support arbitrary fpga image

2017-02-20 Thread Michal Simek
On 19.2.2017 21:58, Dalon Westergreen wrote:
> On Sun, 2017-02-19 at 21:49 +0100, Marek Vasut wrote:
>> On 02/19/2017 09:43 PM, Dalon Westergreen wrote:
>>>
>>> On Sun, 2017-02-19 at 21:07 +0100, Marek Vasut wrote:

 On 02/19/2017 08:49 PM, Dalon Westergreen wrote:
>
>
> The implementation of boot_get_fpga only supported one fpga family.
> This modification allows for any of the fpga devices supported by
> fpga_load to be used.
>
> Signed-off-by: Dalon Westergreen 

 +CC Xilinx friends :)

>
>
> ---
>  common/image.c | 37 ++---
>  1 file changed, 22 insertions(+), 15 deletions(-)
>
> diff --git a/common/image.c b/common/image.c
> index 0f88984..792d371 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -1306,7 +1306,7 @@ int boot_get_setup(bootm_headers_t *images,
> uint8_t
> arch,
>  }
>  
>  #if IMAGE_ENABLE_FIT
> -#if defined(CONFIG_FPGA) && defined(CONFIG_FPGA_XILINX)
> +#if defined(CONFIG_FPGA)
>  int boot_get_fpga(int argc, char * const argv[], bootm_headers_t
> *images,
> uint8_t arch, const ulong *ld_start, ulong * const
> ld_len)
>  {
> @@ -1318,7 +1318,8 @@ int boot_get_fpga(int argc, char * const argv[],
> bootm_headers_t *images,
>   int err;
>   int devnum = 0; /* TODO support multi fpga platforms */
>   const fpga_desc * const desc = fpga_get_desc(devnum);
> - xilinx_desc *desc_xilinx = desc->devdesc;
> + xilinx_desc *desc_xilinx;
> + bitstream_type bstype;
>  
>   /* Check to see if the images struct has a FIT configuration */
>   if (!genimg_has_config(images)) {
> @@ -1365,22 +1366,28 @@ int boot_get_fpga(int argc, char * const argv[],
> bootm_headers_t *images,
>   return fit_img_result;
>   }
>  
> - if (img_len >= desc_xilinx->size) {
> + switch (desc->devtype) {

 Do we need the switch statement at all ? We can have full configuration
 as a default mode of operation and have something like

 if (xilinx) {
  if (partial reconfiguration) {
   do_special_setup();
  }
 }
>>>
>>> I only did the switch stuff b/c i envisioned a need for partial image
>>> support for socfpga.
>>
>> That'd be seriously cool :)
>>
>>>
>>> That said, i would suggest, as you mention, moving
>>> this to platform specific code and perhaps an indication of the image type
>>> in the fitimage.
>>
>> driver-specific code . It doesn't need to know the imagetype, just that
>> the blob that you passed in is a partial-reconfiguration blob. I never
>> really worked with P/R though, do you need some other metadata for that
>> or is it contained in that P/R bitstream blob already ?
> 
> as far as i understand it, it is all in the blob.  All that is needed is 
> knowing
> whether the blob is a full or partial image.  X seems to just use the image 
> size
> to determine this, but that means having a table of all devices and their
> respective full image size.  seems simpler to just specify the image type is
> partial or not in the fitimage.

We did that for zynq when we did that for the first time. But not for
zynqmp. Zynq is maybe still using it but it shouldn't now. It is not
100% reliable way. Definitely having DT property is the best option
because you can add sort of "nop" which extend bitstream size and does
nothing which breaks that checking.

For full u-boot there is loadb, loadbp, load and loadp to distinguish it.

Thanks,
Michal

Thanks,
Michal

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


[U-Boot] [PATCH v5 9/9] board: Add STMicroelectronics STiH410-B2260 support

2017-02-20 Thread patrice.chotard
From: Patrice Chotard 

This is a 96Board compliant board based on STiH410 SoC:
  - 1GB DDR
  - On-Board USB combo WiFi/Bluetooth RTL8723BU
with PCB soldered antenna
  - Ethernet 1000-BaseT
  - SATA
  - HDMI
  - 2 x USB2.0 type A
  - 1 x USB2.0 type micro-AB
  - SD card slot
  - High speed connector (SD/I2C/USB interfaces)
  - Low speed connector (UART/I2C/GPIO/SPI/PCM interfaces)

Signed-off-by: Patrice Chotard 
Reviewed-by: Tom Rini 
Reviewed-by: Simon Glass 
---

v5:  _ migrate board description from patch 1 to 9

 arch/arm/mach-sti/Kconfig  | 25 
 board/st/stih410-b2260/Kconfig | 19 
 board/st/stih410-b2260/MAINTAINERS |  7 +
 board/st/stih410-b2260/Makefile|  8 +
 board/st/stih410-b2260/board.c | 28 ++
 configs/stih410-b2260_defconfig| 26 +
 include/configs/stih410-b2260.h| 60 ++
 7 files changed, 173 insertions(+)
 create mode 100644 board/st/stih410-b2260/Kconfig
 create mode 100644 board/st/stih410-b2260/MAINTAINERS
 create mode 100644 board/st/stih410-b2260/Makefile
 create mode 100644 board/st/stih410-b2260/board.c
 create mode 100644 configs/stih410-b2260_defconfig
 create mode 100644 include/configs/stih410-b2260.h

diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig
index 87c04b2..67a3b24 100644
--- a/arch/arm/mach-sti/Kconfig
+++ b/arch/arm/mach-sti/Kconfig
@@ -3,4 +3,29 @@ if ARCH_STI
 config SYS_SOC
default "stih410"
 
+choice
+   prompt "STiH410 board select"
+
+config TARGET_STIH410_B2260
+   bool "96Boards STiH410-B2260"
+   help
+ Support for 96Board STiH410-B2260 based on STMicrolectronics
+ STiH410 soc. This board complies with 96Board Open Platform
+ Specifications. Features:
+ - 1GB DDR
+ - On-Board USB combo WiFi/Bluetooth RTL8723BU
+   with PCB soldered antenna
+ - Ethernet 1000-BaseT
+ - Sata
+ - HDMI
+ - 2 x USB2 type A
+ - micro USB2 type AB
+ - SD card slot
+ - High speed connector (SD/I2C/USB interfaces)
+ - Slow speed connector (UART/I2C/GPIO/SPI/PCM interfaces)
+
+endchoice
+
+source "board/st/stih410-b2260/Kconfig"
+
 endif
diff --git a/board/st/stih410-b2260/Kconfig b/board/st/stih410-b2260/Kconfig
new file mode 100644
index 000..590add0
--- /dev/null
+++ b/board/st/stih410-b2260/Kconfig
@@ -0,0 +1,19 @@
+if TARGET_STIH410_B2260
+
+config SYS_BOARD
+   string
+   default "stih410-b2260"
+
+config SYS_VENDOR
+   string
+   default "st"
+
+config SYS_SOC
+   string
+   default "stih410"
+
+config SYS_CONFIG_NAME
+   string
+   default "stih410-b2260"
+
+endif
diff --git a/board/st/stih410-b2260/MAINTAINERS 
b/board/st/stih410-b2260/MAINTAINERS
new file mode 100644
index 000..4f557ac
--- /dev/null
+++ b/board/st/stih410-b2260/MAINTAINERS
@@ -0,0 +1,7 @@
+STIH410-B2260 BOARD
+M: Patrice Chotard 
+S: Maintained
+F: board/st/stih410-b2260/
+F: include/configs/stih410-b2260.h
+F: configs/stih410-b2260_defconfig
+F: arch/arm/dts/stih*
diff --git a/board/st/stih410-b2260/Makefile b/board/st/stih410-b2260/Makefile
new file mode 100644
index 000..68a7903
--- /dev/null
+++ b/board/st/stih410-b2260/Makefile
@@ -0,0 +1,8 @@
+#
+# (C) Copyright 2017
+# Patrice Chotard, 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  = board.o
diff --git a/board/st/stih410-b2260/board.c b/board/st/stih410-b2260/board.c
new file mode 100644
index 000..0c06bca
--- /dev/null
+++ b/board/st/stih410-b2260/board.c
@@ -0,0 +1,28 @@
+/*
+ * Board init file for STiH410-B2260
+ *
+ * (C) Copyright 2017 Patrice Chotard 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int dram_init(void)
+{
+   gd->ram_size = PHYS_SDRAM_1_SIZE;
+   return 0;
+}
+
+void dram_init_banksize(void)
+{
+   gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
+   gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
+}
+
+int board_init(void)
+{
+   return 0;
+}
diff --git a/configs/stih410-b2260_defconfig b/configs/stih410-b2260_defconfig
new file mode 100644
index 000..4e6942f
--- /dev/null
+++ b/configs/stih410-b2260_defconfig
@@ -0,0 +1,26 @@
+CONFIG_ARM=y
+CONFIG_ARCH_STI=y
+CONFIG_IDENT_STRING="STMicroelectronics STiH410-B2260"
+CONFIG_DEFAULT_DEVICE_TREE="stih410-b2260"
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SYS_PROMPT="stih410-b2260 => "
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_TIMER=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_OF_CONTROL=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_STI=y
+CONFIG_PINCTRL=y
+CONFIG_STI_ASC_SERIAL=y
+CONFIG_SYSRESET=y
+CONFIG_TIMER=y
+CONFIG_SPL_OF_LIBFDT=y
diff --git a/include/configs/stih410-b2260.h b/include/configs/stih410-b2260.h
new fil

[U-Boot] [PATCH v5 6/9] STiH410: Add STi SDHCI driver

2017-02-20 Thread patrice.chotard
From: Patrice Chotard 

Add SDHCI host controller found on STMicroelectronics SoCs

On some ST SoCs, i.e. STiH407/STiH410, the MMC devices can live
inside a dedicated flashSS sub-system that provides an extend subset
of registers that can be used to configure the Arasan MMC/SD Host
Controller.

This means, that the SDHCI Arasan Controller can be configured to be
eMMC4.5 or 4.3 spec compliant.

W/o these settings the SDHCI will configure and use the MMC/SD
controller with limited features e.g. PIO mode, no DMA, no HS etc.

Signed-off-by: Patrice Chotard 
Reviewed-by: Simon Glass 
Reviewed-by: Jaehoon Chung 
---
 arch/arm/Kconfig  |   2 +
 arch/arm/include/asm/arch-stih410/sdhci.h |  68 ++
 drivers/mmc/Kconfig   |   7 ++
 drivers/mmc/Makefile  |   1 +
 drivers/mmc/sti_sdhci.c   | 141 ++
 5 files changed, 219 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-stih410/sdhci.h
 create mode 100644 drivers/mmc/sti_sdhci.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b91a5b7..477f36b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -987,6 +987,8 @@ config ARCH_STI
select CPU_V7
select DM
select DM_SERIAL
+   select BLK
+   select DM_MMC
help
  Support for STMicroelectronics STiH407/10 SoC family.
  This SoC is used on Linaro 96Board STiH410-B2260
diff --git a/arch/arm/include/asm/arch-stih410/sdhci.h 
b/arch/arm/include/asm/arch-stih410/sdhci.h
new file mode 100644
index 000..8cd77fc
--- /dev/null
+++ b/arch/arm/include/asm/arch-stih410/sdhci.h
@@ -0,0 +1,68 @@
+/*
+ * (C) Copyright 2017 Patrice Chotard 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __STI_SDHCI_H__
+#define __STI_SDHCI_H__
+
+#define FLASHSS_MMC_CORE_CONFIG_1  0x400
+#define FLASHSS_MMC_CORECFG_TIMEOUT_CLK_UNIT_MHZ   BIT(24)
+#define FLASHSS_MMC_CORECFG_TIMEOUT_CLK_FREQ_MIN   BIT(12)
+
+#define STI_FLASHSS_MMC_CORE_CONFIG_1  \
+   (FLASHSS_MMC_CORECFG_TIMEOUT_CLK_UNIT_MHZ   | \
+FLASHSS_MMC_CORECFG_TIMEOUT_CLK_FREQ_MIN)
+
+#define FLASHSS_MMC_CORE_CONFIG_2  0x404
+#define FLASHSS_MMC_CORECFG_HIGH_SPEED BIT(28)
+#define FLASHSS_MMC_CORECFG_8BIT_EMMC  BIT(20)
+#define MAX_BLK_LENGTH_1024BIT(16)
+#define BASE_CLK_FREQ_200  0xc8
+
+#define STI_FLASHSS_MMC_CORE_CONFIG2   \
+   (FLASHSS_MMC_CORECFG_HIGH_SPEED | \
+FLASHSS_MMC_CORECFG_8BIT_EMMC  | \
+MAX_BLK_LENGTH_1024| \
+BASE_CLK_FREQ_200 << 0)
+
+#define STI_FLASHSS_SDCARD_CORE_CONFIG2\
+   (FLASHSS_MMC_CORECFG_HIGH_SPEED | \
+MAX_BLK_LENGTH_1024| \
+BASE_CLK_FREQ_200)
+
+#define FLASHSS_MMC_CORE_CONFIG_3  0x408
+#define FLASHSS_MMC_CORECFG_SLOT_TYPE_EMMC BIT(28)
+#define FLASHSS_MMC_CORECFG_ASYNCH_INTR_SUPPORTBIT(20)
+#define FLASHSS_MMC_CORECFG_3P3_VOLT   BIT(8)
+#define FLASHSS_MMC_CORECFG_SUSP_RES_SUPPORT   BIT(4)
+#define FLASHSS_MMC_CORECFG_SDMA   BIT(0)
+
+#define STI_FLASHSS_MMC_CORE_CONFIG3   \
+(FLASHSS_MMC_CORECFG_SLOT_TYPE_EMMC| \
+FLASHSS_MMC_CORECFG_ASYNCH_INTR_SUPPORT| \
+FLASHSS_MMC_CORECFG_3P3_VOLT   | \
+FLASHSS_MMC_CORECFG_SUSP_RES_SUPPORT   | \
+FLASHSS_MMC_CORECFG_SDMA)
+
+#define STI_FLASHSS_SDCARD_CORE_CONFIG3\
+(FLASHSS_MMC_CORECFG_ASYNCH_INTR_SUPPORT   | \
+FLASHSS_MMC_CORECFG_3P3_VOLT   | \
+FLASHSS_MMC_CORECFG_SUSP_RES_SUPPORT   | \
+FLASHSS_MMC_CORECFG_SDMA)
+
+#define FLASHSS_MMC_CORE_CONFIG_4  0x40c
+#define FLASHSS_MMC_CORECFG_D_DRIVER_SUPPORT   BIT(20)
+#define FLASHSS_MMC_CORECFG_C_DRIVER_SUPPORT   BIT(16)
+#define FLASHSS_MMC_CORECFG_A_DRIVER_SUPPORT   BIT(12)
+
+#define STI_FLASHSS_MMC_CORE_CONFIG4   \
+   (FLASHSS_MMC_CORECFG_D_DRIVER_SUPPORT   | \
+FLASHSS_MMC_CORECFG_C_DRIVER_SUPPORT   | \
+FLASHSS_MMC_CORECFG_A_DRIVER_SUPPORT)
+
+#define ST_MMC_CCONFIG_REG_5   0x210
+#define SYSCONF_MMC1_ENABLE_BIT3
+
+#endif /* _STI_SDHCI_H_ */
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 01d1dbf..ea5ea08 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -299,6 +299,13 @@ config MMC_SDHCI_SPEAR
 
  If unsure, say N.
 
+config MMC_SDHCI_STI
+   bool "SDHCI support for STMicroelectronics SoC"
+   depends on MMC_SDHCI
+   help
+ This selects the Secure Digital Host Controller Interface (SDHCI)
+ on STMicroelectronics STiH

[U-Boot] [PATCH v5 0/9] Add STMicroelectronics STiH410-B2260 board

2017-02-20 Thread patrice.chotard
From: Patrice Chotard 

v5: _ Add Simon Glass's reviewed-by
_ move board Kconfig description from patch 1 to 9

v4: _ fix STi serial driver to be fully DT compliant
_ remove arch/arm/include/asm/arch-stih410/sti.h and
  include/dm/platform_data/serial_sti_asc.h which became useless
_ board file cleanup
_ fix some nits in sti_sdhci.c
_ rebased on top of v2017.03-rc2

v3: _ add reviewed-by
_ add top level MAINTAINERS entry and in the board MAINTAINERS
_ use the fallback table from include/config_fallbacks.h
_ minor update in sti_sdhci.c
_ reorder patches with functionnal board and defconfig in last
_ remove arch/arm/mach-sti/cpu.c and replace it by a sysreset DM driver
_ remove arch/arm/mach-sti/timer.c by a timer DM driver
_ remove useless arch/arm/include/asm/arch-stih410/syscfg.h
_ remove useless arch/arm/include/asm/arch-stih410/gpio.h and update 
  arch/arm/include/asm/gpio.h for ARCH_STI in patch 5

v2: _ fix remarks from Jaechon Chung on SDHCI patch
_ fix remarks from Antonio Borneo on board patch
_ replace some macro by U-boot generic's one
_ add missing maintainers in recipients

Patrice Chotard (9):
  arm: Add support for STMicroelectronics STiH410 soc
  STiH410: Add STi timer driver
  STiH410: Add STi sysreset driver
  STiH410: Add STi serial driver
  gpio: do not include  for ARCH_STI
  STiH410: Add STi SDHCI driver
  STiH410: Add STi pinctrl driver
  STiH410-B2260: Add device tree
  board: Add STMicroelectronics STiH410-B2260 support
Patrice Chotard (9):
  arm: Add support for STMicroelectronics STiH410 soc
  STiH410: Add STi timer driver
  STiH410: Add STi sysreset driver
  STiH410: Add STi serial driver
  gpio: do not include  for ARCH_STI
  STiH410: Add STi SDHCI driver
  STiH410: Add STi pinctrl driver
  STiH410-B2260: Add device tree
  board: Add STMicroelectronics STiH410-B2260 support

 MAINTAINERS   |6 +
 arch/arm/Kconfig  |   13 +
 arch/arm/dts/Makefile |2 +
 arch/arm/dts/st-pincfg.h  |   71 ++
 arch/arm/dts/stih407-clock.dtsi   |  326 ++
 arch/arm/dts/stih407-family.dtsi  |  977 +++
 arch/arm/dts/stih407-pinctrl.dtsi | 1303 +
 arch/arm/dts/stih410-b2260.dts|  226 
 arch/arm/dts/stih410-clock.dtsi   |  347 ++
 arch/arm/dts/stih410-pinctrl.dtsi |   34 +
 arch/arm/dts/stih410.dtsi |  454 +++
 arch/arm/include/asm/arch-stih410/sdhci.h |   68 ++
 arch/arm/include/asm/gpio.h   |2 +-
 arch/arm/mach-sti/Kconfig |   31 +
 board/st/stih410-b2260/Kconfig|   19 +
 board/st/stih410-b2260/MAINTAINERS|7 +
 board/st/stih410-b2260/Makefile   |8 +
 board/st/stih410-b2260/board.c|   28 +
 configs/stih410-b2260_defconfig   |   26 +
 drivers/mmc/Kconfig   |7 +
 drivers/mmc/Makefile  |1 +
 drivers/mmc/sti_sdhci.c   |  141 +++
 drivers/pinctrl/Kconfig   |   10 +
 drivers/pinctrl/Makefile  |1 +
 drivers/pinctrl/pinctrl-sti.c |  320 +
 drivers/serial/Kconfig|8 +
 drivers/serial/Makefile   |1 +
 drivers/serial/serial_sti_asc.c   |  211 
 drivers/sysreset/Makefile |1 +
 drivers/sysreset/sysreset_sti.c   |   82 ++
 drivers/timer/Kconfig |7 +
 drivers/timer/Makefile|1 +
 drivers/timer/sti-timer.c |   78 ++
 include/configs/stih410-b2260.h   |   60 +
 include/dt-bindings/clock/stih407-clks.h  |   90 ++
 include/dt-bindings/clock/stih410-clks.h  |   25 +
 include/dt-bindings/interrupt-controller/irq-st.h |   30 +
 include/dt-bindings/mfd/st-lpc.h  |   16 +
 include/dt-bindings/reset/stih407-resets.h|   65 +
 39 files changed, 5102 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/st-pincfg.h
 create mode 100644 arch/arm/dts/stih407-clock.dtsi
 create mode 100644 arch/arm/dts/stih407-family.dtsi
 create mode 100644 arch/arm/dts/stih407-pinctrl.dtsi
 create mode 100644 arch/arm/dts/stih410-b2260.dts
 create mode 100644 arch/arm/dts/stih410-clock.dtsi
 create mode 100644 arch/arm/dts/stih410-pinctrl.dtsi
 create mode 100644 arch/arm/dts/stih410.dtsi
 create mode 100644 arch/arm/include/asm/arch-stih410/sdhci.h
 create mode 100644 arch/arm/mach-sti/Kconfig
 create mode 100644 board/st/stih410-b2260/Kconfig
 create mode 100644 board/st/stih410-b2260/MAINTAINERS
 create mo

[U-Boot] [PATCH v5 7/9] STiH410: Add STi pinctrl driver

2017-02-20 Thread patrice.chotard
From: Patrice Chotard 

Add STMicroelectronics STiH410 pinctrl driver

Signed-off-by: Patrice Chotard 
Reviewed-by: Tom Rini 
Reviewed-by: Simon Glass 
---
 drivers/pinctrl/Kconfig   |  10 ++
 drivers/pinctrl/Makefile  |   1 +
 drivers/pinctrl/pinctrl-sti.c | 320 ++
 3 files changed, 331 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-sti.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index efcb4c0..0c832e1 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -175,6 +175,16 @@ config PIC32_PINCTRL
  by a device tree node which contains both GPIO defintion and pin 
control
  functions.
 
+config PINCTRL_STI
+   bool "STMicroelectronics STi pin-control and pin-mux driver"
+   depends on DM && ARCH_STI
+   default y
+   help
+ Support pin multiplexing control on STMicrolectronics STi SoCs.
+ The driver is controlled by a device tree node which contains both
+ the GPIO definitions and pin control functions for each available 
multiplex
+ function.
+
 endif
 
 source "drivers/pinctrl/meson/Kconfig"
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 512112a..a2f8101 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_PIC32_PINCTRL)   += pinctrl_pic32.o
 obj-$(CONFIG_PINCTRL_EXYNOS)   += exynos/
 obj-$(CONFIG_PINCTRL_MESON)+= meson/
 obj-$(CONFIG_PINCTRL_MVEBU)+= mvebu/
+obj-$(CONFIG_PINCTRL_STI)  += pinctrl-sti.o
diff --git a/drivers/pinctrl/pinctrl-sti.c b/drivers/pinctrl/pinctrl-sti.c
new file mode 100644
index 000..6ee7fa7
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-sti.c
@@ -0,0 +1,320 @@
+/*
+ * Pinctrl driver for STMicroelectronics STi SoCs
+ *
+ *  Copyright (c) 2017
+ *  Patrice Chotard 
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define MAX_STI_PINCONF_ENTRIES7
+/* Output enable */
+#define OE (1 << 27)
+/* Pull Up */
+#define PU (1 << 26)
+/* Open Drain */
+#define OD (1 << 25)
+
+/* User-frendly defines for Pin Direction */
+   /* oe = 0, pu = 0, od = 0 */
+#define IN (0)
+   /* oe = 0, pu = 1, od = 0 */
+#define IN_PU  (PU)
+   /* oe = 1, pu = 0, od = 0 */
+#define OUT(OE)
+   /* oe = 1, pu = 1, od = 0 */
+#define OUT_PU (OE | PU)
+   /* oe = 1, pu = 0, od = 1 */
+#define BIDIR  (OE | OD)
+   /* oe = 1, pu = 1, od = 1 */
+#define BIDIR_PU   (OE | PU | OD)
+
+struct sti_pinctrl_platdata {
+   struct regmap *regmap;
+};
+
+struct sti_pin_desc {
+   unsigned char bank;
+   unsigned char pin;
+   unsigned char alt;
+   int dir;
+};
+
+/*
+ * PIO alternative Function selector
+ */
+void sti_alternate_select(struct udevice *dev, struct sti_pin_desc *pin_desc)
+{
+   struct sti_pinctrl_platdata *plat = dev_get_platdata(dev);
+   unsigned long sysconf, *sysconfreg;
+   int alt = pin_desc->alt;
+   int bank = pin_desc->bank;
+   int pin = pin_desc->pin;
+
+   sysconfreg = (unsigned long *)plat->regmap->base;
+
+   switch (bank) {
+   case 0 ... 5:   /* in "SBC Bank" */
+   sysconfreg += bank;
+   break;
+   case 10 ... 20: /* in "FRONT Bank" */
+   sysconfreg += bank - 10;
+   break;
+   case 30 ... 35: /* in "REAR Bank" */
+   sysconfreg += bank - 30;
+   break;
+   case 40 ... 42: /* in "FLASH Bank" */
+   sysconfreg += bank - 40;
+   break;
+   default:
+   BUG();
+   return;
+   }
+
+   sysconf = readl(sysconfreg);
+   bitfield_replace(sysconf, pin * 4, 3, alt);
+   writel(sysconf, sysconfreg);
+}
+
+/* pin configuration */
+void sti_pin_configure(struct udevice *dev, struct sti_pin_desc *pin_desc)
+{
+   struct sti_pinctrl_platdata *plat = dev_get_platdata(dev);
+   int bit;
+   int oe = 0, pu = 0, od = 0;
+   unsigned long *sysconfreg;
+   int bank = pin_desc->bank;
+
+   sysconfreg = (unsigned long *)plat->regmap->base + 40;
+
+   /*
+* NOTE: The PIO configuration for the PIO pins in the
+* "FLASH Bank" are different from all the other banks!
+* Specifically, the output-enable pin control register
+* (SYS_CFG_3040) and the pull-up pin control register
+* (SYS_CFG_3050), are both classed as being "reserved".
+* Hence, we do not write to these registers to configure
+* the OE and PU features for PIOs in this bank. However,
+* the open-drain pin control register (SYS_CFG_3060)
+

[U-Boot] [PATCH v5 5/9] gpio: do not include for ARCH_STI

2017-02-20 Thread patrice.chotard
From: Patrice Chotard 

As no gpio.h is defined in arch/arm/include/asm/arch-stih410,
to avoid compilation failure, do not include asm/arch/gpio.h.

This is needed for example when including sdhci.h, which include
asm/gpio.h>.

Signed-off-by: Patrice Chotard 
Reviewed-by: Simon Glass 
---
 arch/arm/include/asm/gpio.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
index fe4419c..1c5e873 100644
--- a/arch/arm/include/asm/gpio.h
+++ b/arch/arm/include/asm/gpio.h
@@ -1,4 +1,4 @@
-#ifndef CONFIG_ARCH_UNIPHIER
+#if !defined(CONFIG_ARCH_UNIPHIER) && !defined(CONFIG_ARCH_STI)
 #include 
 #endif
 #include 
-- 
1.9.1

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


[U-Boot] [PATCH v5 3/9] STiH410: Add STi sysreset driver

2017-02-20 Thread patrice.chotard
From: Patrice Chotard 

Signed-off-by: Patrice Chotard 
Reviewed-by: Simon Glass 
---
 drivers/sysreset/Makefile   |  1 +
 drivers/sysreset/sysreset_sti.c | 82 +
 2 files changed, 83 insertions(+)
 create mode 100644 drivers/sysreset/sysreset_sti.c

diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index 37638a8..21bcc21 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -13,5 +13,6 @@ obj-$(CONFIG_ROCKCHIP_RK3288) += sysreset_rk3288.o
 obj-$(CONFIG_ROCKCHIP_RK3399) += sysreset_rk3399.o
 obj-$(CONFIG_SANDBOX) += sysreset_sandbox.o
 obj-$(CONFIG_ARCH_SNAPDRAGON) += sysreset_snapdragon.o
+obj-$(CONFIG_ARCH_STI) += sysreset_sti.o
 obj-$(CONFIG_TARGET_XTFPGA) += sysreset_xtfpga.o
 obj-$(CONFIG_ARCH_ASPEED) += sysreset_ast.o
diff --git a/drivers/sysreset/sysreset_sti.c b/drivers/sysreset/sysreset_sti.c
new file mode 100644
index 000..9b58aa8
--- /dev/null
+++ b/drivers/sysreset/sysreset_sti.c
@@ -0,0 +1,82 @@
+/*
+ * (C) Copyright 2017 Patrice Chotard 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct sti_sysreset_priv {
+   phys_addr_t base;
+};
+
+static int sti_sysreset_request(struct udevice *dev, enum sysreset_t type)
+{
+   struct sti_sysreset_priv *priv = dev_get_priv(dev);
+
+   generic_clear_bit(0, (void __iomem *)priv->base);
+
+   return -EINPROGRESS;
+}
+
+static int sti_sysreset_probe(struct udevice *dev)
+{
+   struct sti_sysreset_priv *priv = dev_get_priv(dev);
+   struct udevice *syscon;
+   struct regmap *regmap;
+   struct fdtdec_phandle_args syscfg_phandle;
+   int ret;
+
+   /* get corresponding syscon phandle */
+   ret = fdtdec_parse_phandle_with_args(gd->fdt_blob, dev_of_offset(dev),
+"st,syscfg", NULL, 0, 0,
+&syscfg_phandle);
+   if (ret < 0) {
+   error("Can't get syscfg phandle: %d\n", ret);
+   return ret;
+   }
+
+   ret = uclass_get_device_by_of_offset(UCLASS_SYSCON,
+syscfg_phandle.node,
+&syscon);
+   if (ret) {
+   error("%s: uclass_get_device_by_of_offset failed: %d\n",
+ __func__, ret);
+   return ret;
+   }
+
+   regmap = syscon_get_regmap(syscon);
+   if (!regmap) {
+   error("unable to get regmap for %s\n", syscon->name);
+   return -ENODEV;
+   }
+
+   priv->base = regmap->base;
+
+   return 0;
+}
+
+static struct sysreset_ops sti_sysreset = {
+   .request= sti_sysreset_request,
+};
+
+static const struct udevice_id sti_sysreset_ids[] = {
+   { .compatible = "st,stih407-restart" },
+   { }
+};
+
+U_BOOT_DRIVER(sysreset_sti) = {
+   .name = "sysreset_sti",
+   .id = UCLASS_SYSRESET,
+   .ops = &sti_sysreset,
+   .probe = sti_sysreset_probe,
+   .of_match = sti_sysreset_ids,
+   .priv_auto_alloc_size = sizeof(struct sti_sysreset_priv),
+};
-- 
1.9.1

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


[U-Boot] [PATCH v5 2/9] STiH410: Add STi timer driver

2017-02-20 Thread patrice.chotard
From: Patrice Chotard 

Add ARM global timer based timer

Signed-off-by: Patrice Chotard 
Reviewed-by: Simon Glass 
---
 drivers/timer/Kconfig |  7 +
 drivers/timer/Makefile|  1 +
 drivers/timer/sti-timer.c | 78 +++
 3 files changed, 86 insertions(+)
 create mode 100644 drivers/timer/sti-timer.c

diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index cd38a6d..72c1416 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -58,4 +58,11 @@ config AST_TIMER
  This is mostly because they all share several registers which
  makes it difficult to completely separate them.
 
+config STI_TIMER
+   bool "STi timer support"
+   depends on TIMER
+   default y if ARCH_STI
+   help
+ Select this to enable a timer for STi devices.
+
 endmenu
diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
index a4b1a48..ae94be8 100644
--- a/drivers/timer/Makefile
+++ b/drivers/timer/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_SANDBOX_TIMER)   += sandbox_timer.o
 obj-$(CONFIG_X86_TSC_TIMER)+= tsc_timer.o
 obj-$(CONFIG_OMAP_TIMER)   += omap-timer.o
 obj-$(CONFIG_AST_TIMER)+= ast_timer.o
+obj-$(CONFIG_STI_TIMER)+= sti-timer.o
diff --git a/drivers/timer/sti-timer.c b/drivers/timer/sti-timer.c
new file mode 100644
index 000..e1419c4
--- /dev/null
+++ b/drivers/timer/sti-timer.c
@@ -0,0 +1,78 @@
+/*
+ * (C) Copyright 2017 Patrice Chotard 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct sti_timer_priv {
+   struct globaltimer *global_timer;
+};
+
+static int sti_timer_get_count(struct udevice *dev, u64 *count)
+{
+   struct sti_timer_priv *priv = dev_get_priv(dev);
+   struct globaltimer *global_timer = priv->global_timer;
+   u32 low, high;
+   u64 timer;
+   u32 old = readl(&global_timer->cnt_h);
+
+   while (1) {
+   low = readl(&global_timer->cnt_l);
+   high = readl(&global_timer->cnt_h);
+   if (old == high)
+   break;
+   else
+   old = high;
+   }
+   timer = high;
+   *count = (u64)((timer << 32) | low);
+
+   return 0;
+}
+
+static int sti_timer_probe(struct udevice *dev)
+{
+   struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+   struct sti_timer_priv *priv = dev_get_priv(dev);
+   fdt_addr_t addr;
+
+   uc_priv->clock_rate = CONFIG_SYS_HZ_CLOCK;
+
+   /* get arm global timer base address */
+   addr = fdtdec_get_addr(gd->fdt_blob, dev_of_offset(dev), "reg");
+   priv->global_timer = (struct globaltimer *)addr;
+
+   /* init timer */
+   writel(0x01, &priv->global_timer->ctl);
+
+   return 0;
+}
+
+static const struct timer_ops sti_timer_ops = {
+   .get_count = sti_timer_get_count,
+};
+
+static const struct udevice_id sti_timer_ids[] = {
+   { .compatible = "arm,cortex-a9-global-timer" },
+   {}
+};
+
+U_BOOT_DRIVER(sti_timer) = {
+   .name = "sti_timer",
+   .id = UCLASS_TIMER,
+   .of_match = sti_timer_ids,
+   .priv_auto_alloc_size = sizeof(struct sti_timer_priv),
+   .probe = sti_timer_probe,
+   .ops = &sti_timer_ops,
+   .flags = DM_FLAG_PRE_RELOC,
+};
-- 
1.9.1

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


[U-Boot] [PATCH v5 1/9] arm: Add support for STMicroelectronics STiH410 soc

2017-02-20 Thread patrice.chotard
From: Patrice Chotard 

The STiH410 is an advanced multi-HD AVC processor with 3D
graphics acceleration and 1.5-GHz ARM Cortex-A9 SMP CPU
part of the STiH407 family.

It has wide connectivity including USB 3.0, PCI-e, SATA
and gigabit ethernet.

Signed-off-by: Patrice Chotard 
---

v5:  _ migrate board description from patch 1 to 9

 MAINTAINERS   | 6 ++
 arch/arm/Kconfig  | 9 +
 arch/arm/mach-sti/Kconfig | 6 ++
 3 files changed, 21 insertions(+)
 create mode 100644 arch/arm/mach-sti/Kconfig

diff --git a/MAINTAINERS b/MAINTAINERS
index eaa2c3b..19c0eed 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -165,6 +165,12 @@ S: Maintained
 F: arch/arm/cpu/armv7/stv0991/
 F: arch/arm/include/asm/arch-stv0991/
 
+ARM STI
+M: Patrice Chotard 
+S: Maintained
+F: arch/arm/mach-sti/
+F: arch/arm/include/asm/arch-sti*/
+
 ARM SUNXI
 M: Jagan Teki 
 M: Maxime Ripard 
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0229800..4aa5eb9 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -982,6 +982,13 @@ config STM32
select DM
select DM_SERIAL
 
+config ARCH_STI
+   bool "Support STMicrolectronics SoCs"
+   select CPU_V7
+   help
+ Support for STMicroelectronics STiH407/10 SoC family.
+ This SoC is used on Linaro 96Board STiH410-B2260
+
 config ARCH_ROCKCHIP
bool "Support Rockchip SoCs"
select OF_CONTROL
@@ -1060,6 +1067,8 @@ source "arch/arm/mach-snapdragon/Kconfig"
 
 source "arch/arm/mach-socfpga/Kconfig"
 
+source "arch/arm/mach-sti/Kconfig"
+
 source "arch/arm/mach-stm32/Kconfig"
 
 source "arch/arm/mach-tegra/Kconfig"
diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig
new file mode 100644
index 000..87c04b2
--- /dev/null
+++ b/arch/arm/mach-sti/Kconfig
@@ -0,0 +1,6 @@
+if ARCH_STI
+
+config SYS_SOC
+   default "stih410"
+
+endif
-- 
1.9.1

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


[U-Boot] [PATCH v5 4/9] STiH410: Add STi serial driver

2017-02-20 Thread patrice.chotard
From: Patrice Chotard 

This patch adds support to ASC (asynchronous serial controller)
driver, which is basically a standard serial driver. This IP
is common across other STMicroelectronics SoCs

Signed-off-by: Patrice Chotard 
Reviewed-by: Simon Glass 
---
 arch/arm/Kconfig|   2 +
 drivers/serial/Kconfig  |   8 ++
 drivers/serial/Makefile |   1 +
 drivers/serial/serial_sti_asc.c | 211 
 4 files changed, 222 insertions(+)
 create mode 100644 drivers/serial/serial_sti_asc.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4aa5eb9..b91a5b7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -985,6 +985,8 @@ config STM32
 config ARCH_STI
bool "Support STMicrolectronics SoCs"
select CPU_V7
+   select DM
+   select DM_SERIAL
help
  Support for STMicroelectronics STiH407/10 SoC family.
  This SoC is used on Linaro 96Board STiH410-B2260
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index b11f3ff..7cb0eaa 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -413,4 +413,12 @@ config PXA_SERIAL
  If you have a machine based on a Marvell XScale PXA2xx CPU you
  can enable its onboard serial ports by enabling this option.
 
+config STI_ASC_SERIAL
+   bool "STMicroelectronics on-chip UART"
+   depends on DM_SERIAL && ARCH_STI
+   help
+ Select this to enable Asynchronous Serial Controller available
+ on STiH410 SoC. This is a basic implementation,  it supports
+ following baudrate 9600, 19200, 38400, 57600 and 115200.
+
 endmenu
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 8430668..84a22ce 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_FSL_LINFLEXUART) += serial_linflexuart.o
 obj-$(CONFIG_ARC_SERIAL) += serial_arc.o
 obj-$(CONFIG_UNIPHIER_SERIAL) += serial_uniphier.o
 obj-$(CONFIG_STM32_SERIAL) += serial_stm32.o
+obj-$(CONFIG_STI_ASC_SERIAL) += serial_sti_asc.o
 obj-$(CONFIG_PIC32_SERIAL) += serial_pic32.o
 obj-$(CONFIG_STM32X7_SERIAL) += serial_stm32x7.o
 obj-$(CONFIG_BCM283X_MU_SERIAL) += serial_bcm283x_mu.o
diff --git a/drivers/serial/serial_sti_asc.c b/drivers/serial/serial_sti_asc.c
new file mode 100644
index 000..ce26c94
--- /dev/null
+++ b/drivers/serial/serial_sti_asc.c
@@ -0,0 +1,211 @@
+/*
+ * Support for Serial I/O using STMicroelectronics' on-chip ASC.
+ *
+ *  Copyright (c) 2017
+ *  Patrice Chotard 
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define BAUDMODE   0x1000
+#define RXENABLE   0x0100
+#define RUN0x0080
+#define MODE   0x0001
+#define MODE_8BIT  0x0001
+#define STOP_1BIT  0x0008
+#define PARITYODD  0x0020
+
+#define STA_TF BIT(9)
+#define STA_RBFBIT(0)
+
+struct sti_asc_uart {
+   u32 baudrate;
+   u32 txbuf;
+   u32 rxbuf;
+   u32 control;
+   u32 inten;
+   u32 status;
+   u32 guardtime;
+   u32 timeout;
+   u32 txreset;
+   u32 rxreset;
+};
+
+struct sti_asc_serial {
+   /* address of registers in physical memory */
+   struct sti_asc_uart *regs;
+};
+
+/* Values for the BAUDRATE Register */
+#define PCLK   (200ul * 100ul)
+#define BAUDRATE_VAL_M0(bps)   (PCLK / (16 * (bps)))
+#define BAUDRATE_VAL_M1(bps)   ((bps * (1 << 14)) + (1<<13)) / (PCLK/(1 << 6))
+
+/*
+ * MODE 0
+ *   ICCLK
+ * ASCBaudRate =   
+ *   baudrate * 16
+ *
+ * MODE 1
+ *   baudrate * 16 * 2^16
+ * ASCBaudRate =   
+ *  ICCLK
+ *
+ * NOTE:
+ * Mode 1 should be used for baudrates of 19200, and above, as it
+ * has a lower deviation error than Mode 0 for higher frequencies.
+ * Mode 0 should be used for all baudrates below 19200.
+ */
+
+static int sti_asc_pending(struct udevice *dev, bool input)
+{
+   struct sti_asc_serial *priv = dev_get_priv(dev);
+   struct sti_asc_uart *const uart = priv->regs;
+   unsigned long status;
+
+   status = readl(&uart->status);
+   if (input)
+   return status & STA_RBF;
+   else
+   return status & STA_TF;
+}
+
+static int _sti_asc_serial_setbrg(struct sti_asc_uart *uart, int baudrate)
+{
+   unsigned long val;
+   int t, mode = 1;
+
+   switch (baudrate) {
+   case 9600:
+   t = BAUDRATE_VAL_M0(9600);
+   mode = 0;
+   break;
+   case 19200:
+   t = BAUDRATE_VAL_M1(19200);
+   break;
+   case 38400:
+   t = BAUDRATE_VAL_M1(38400);
+   break;
+   case 57600:
+   t = BAUDRATE_VAL_M1(57600);
+   break;
+   default:
+   debug("ASC: unsupported baud rate: %d, using 1152

Re: [U-Boot] [PATCH 1/2] common: image: update boot_get_fpga to support arbitrary fpga image

2017-02-20 Thread Michal Simek
On 19.2.2017 22:26, Marek Vasut wrote:
> On 02/19/2017 10:21 PM, Dalon Westergreen wrote:
>> On Sun, 2017-02-19 at 22:12 +0100, Marek Vasut wrote:
>>> On 02/19/2017 09:58 PM, Dalon Westergreen wrote:

 On Sun, 2017-02-19 at 21:49 +0100, Marek Vasut wrote:
>
> On 02/19/2017 09:43 PM, Dalon Westergreen wrote:
>>
>>
>> On Sun, 2017-02-19 at 21:07 +0100, Marek Vasut wrote:
>>>
>>>
>>> On 02/19/2017 08:49 PM, Dalon Westergreen wrote:



 The implementation of boot_get_fpga only supported one fpga family.
 This modification allows for any of the fpga devices supported by
 fpga_load to be used.

 Signed-off-by: Dalon Westergreen 
>>>
>>> +CC Xilinx friends :)
>>>



 ---
  common/image.c | 37 ++---
  1 file changed, 22 insertions(+), 15 deletions(-)

 diff --git a/common/image.c b/common/image.c
 index 0f88984..792d371 100644
 --- a/common/image.c
 +++ b/common/image.c
 @@ -1306,7 +1306,7 @@ int boot_get_setup(bootm_headers_t *images,
 uint8_t
 arch,
  }
  
  #if IMAGE_ENABLE_FIT
 -#if defined(CONFIG_FPGA) && defined(CONFIG_FPGA_XILINX)
 +#if defined(CONFIG_FPGA)
  int boot_get_fpga(int argc, char * const argv[], bootm_headers_t
 *images,
  uint8_t arch, const ulong *ld_start, ulong *
 const
 ld_len)
  {
 @@ -1318,7 +1318,8 @@ int boot_get_fpga(int argc, char * const
 argv[],
 bootm_headers_t *images,
int err;
int devnum = 0; /* TODO support multi fpga platforms */
const fpga_desc * const desc = fpga_get_desc(devnum);
 -  xilinx_desc *desc_xilinx = desc->devdesc;
 +  xilinx_desc *desc_xilinx;
 +  bitstream_type bstype;
  
/* Check to see if the images struct has a FIT
 configuration */
if (!genimg_has_config(images)) {
 @@ -1365,22 +1366,28 @@ int boot_get_fpga(int argc, char * const
 argv[],
 bootm_headers_t *images,
return fit_img_result;
}
  
 -  if (img_len >= desc_xilinx->size) {
 +  switch (desc->devtype) {
>>>
>>> Do we need the switch statement at all ? We can have full
>>> configuration
>>> as a default mode of operation and have something like
>>>
>>> if (xilinx) {
>>>  if (partial reconfiguration) {
>>>   do_special_setup();
>>>  }
>>> }
>>
>> I only did the switch stuff b/c i envisioned a need for partial image
>> support for socfpga.
>
> That'd be seriously cool :)
>
>>
>>
>> That said, i would suggest, as you mention, moving
>> this to platform specific code and perhaps an indication of the image
>> type
>> in the fitimage.
>
> driver-specific code . It doesn't need to know the imagetype, just that
> the blob that you passed in is a partial-reconfiguration blob. I never
> really worked with P/R though, do you need some other metadata for that
> or is it contained in that P/R bitstream blob already ?

 as far as i understand it, it is all in the blob.  All that is needed is
 knowing
 whether the blob is a full or partial image.  X seems to just use the image
 size
 to determine this, but that means having a table of all devices and their
 respective full image size.  seems simpler to just specify the image type 
 is
 partial or not in the fitimage.
>>>
>>> Can't you extract that info from the RBF though ? But then again,
>>> extending the fitImage format for this would be fine IMO.
>>>
>>> btw is spelling the X in it's entirety somehow forbidden in A ? :-)
>>
>> Ah, but you forget, we are now I... :)
> 
> So it's now A+I ... 愛 [1] ? :-)
> [1] http://jisho.org/search/%E6%84%9B
> 
> Looking forward to V2 of this , we seem to have some good stuff coming up.

I can only have some thoughts about it but if you work for I you should
use that I email. The same in A case and I do something for X that's why
I use X email.

Thanks,
Michal

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


Re: [U-Boot] [PATCH v1] env_mmc: configure environment offsets via device tree

2017-02-20 Thread Dr. Philipp Tomsich

> On 20 Feb 2017, at 08:22, Igor Grinberg  wrote:
> 
>>> That sounds too odd...
>>> DT's purpose is to describe the h/w... and that does not look so...
>>> We also, have a dt file name in the environment, so this creates will create
>>> a chicken and an egg problem…
>> 
>> I don’t really follow… as far as I knew the DT name would have to come
>> from some other source anyway, as the device containing the env might
>> only be described through the device tree (e.g. mmc0).
> 
> Why? U-Boot can live pretty well w/o DT.

If U-Boot runs without DT, then nothing will/should change about how the setting
is retrieved from CONFIG_ENV_OFFSET.

The platform that motivated this change is ARCH_SUNXI, which does not use
per-board defines but aims to have one generic bootloader per-SoC.

>>> I really don't think we should go that direction. DT is not meant to provide
>>> a solution to all your problems...
>> 
>> I don’t see how this is different from other entries in chosen and config as
>> of today:
>>  common/autoboot.c allows an override through /config/bootdelay
>>  common/board_r.c uses /config/load-environment
>>  common/cli.c can pull in /config/bootcmd
>>  drivers/serial/serial-uclass.c uses /chosen/stdout-path
>> 
>> In fact, it is the absence of this mechanism that is causing problems today:
>> CONFIG_ENV_OFFSET is not configurable through Kconfig, so we would
>> need board-specific defines (e.g. CONFIG_SUNXI_BOARD_LYNX) and
>> matching #ifdef primitives in a shared header (sunxi-common.h in our case).
> 
> Right. Exactly, I think we should move the CONFIG_ENV_OFFSET to Kconfig.
> And that will solve the problem.

Doing this would still get into the way of architectures that want to build a 
single
‘universal’ bootloader for their SoC: the ENV_OFFSET may not be the same
across all board and vendor configurations. This can easily be handled with the
(optional) prop in the DT, but not with the compile-time ENV_OFFSET.

If we decide to this, I’d at least like to introduce the function call to (the 
weak
function) mmc_get_env_addr(…), so we can override this in the board code.

>> So putting this in the DT is the best (and least intrusive) option available.
> 
> Ok. I see your point now. Yet I think we should keep the DT to its purpose - 
> which
> is to describe the h/w (and not the s/w placement layout).
> 
> 
> -- 
> Regards,
> Igor.

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


Re: [U-Boot] x86: SecureBoot: Bay Trail

2017-02-20 Thread Markus Valentin
Hi,

On Fri, 2017-02-17 at 19:58 +0800, Bin Meng wrote:
> On Fri, Feb 17, 2017 at 5:26 PM, Markus Valentin  wrote:
> > 
> > Hi,
> > 
> > i'm implementing Secure Boot with U-Boot on a Intel Atom E3800 Series (Bay
> > Trail) based Plattform.
> > 
> > I did manage to get the first boot stage (Initial Boot Block) verified by
> > the
> > Trusted Execution Engine, next i need to verify the "ramstage" as they call
> > it.
> 
> How did you implement the first boot stage? Is it U-Boot SPL?
No, i'm not using SPL, but maybe i should?

Currently i follow the instructions from document #558081 "Enabling Secure Boot
with Intel FSP and coreboot" for Intel ® Atom TM Processor E3800 Product
Family".
There they state that i should extract a IBB(Initial Boot Block) which is the
last 127Kib from the u-boot.rom/coreboot.rom file. IBB plus a secure boot
"manifest" is the 1st stage that gets properly authenticated, copied to ram
 and executed(128Kib).
> 
> > 
> > 
> > Intel provides a manual on how to enable Secure Boot with coreboot in this
> > manual they extract the "ramstage" from the coreboot.rom file via cbfs.
> > 
> 
> Which manual is this?
#558081 "Enabling Secure Boot with Intel FSP and coreboot" for Intel ® Atom TM
Processor E3800 Product Family"
> 
> > 
> > How can i get the equivalent for the coreboot-ramstage from U-Boot?
> > 
> 
> My understanding is that since you already managed to have the
> hardware (TXE) successfully verify the first boot stage, the next step
> is all yours, which means you don't need anything like
> coreboot-ramstage. You can implement whatever loading/authenticating
> mechanism you put in the first boot stage to boot the 2nd stage.
Thats a good point, thanks. I already implemented verification in U-Boot for
verification of the fit-image public-key, so i could easily adopt it. 

best regards

Markus


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


  1   2   3   4   >