Re: [U-Boot] [linux-sunxi] [PATCH v2 6/6] sunxi: store DRAM size in SPL header

[Icenowy Zheng]

于 2018年10月26日 GMT+08:00 下午1:54:44, Jagan Teki  写到:
>On Thu, Oct 25, 2018 at 2:53 PM Icenowy Zheng  wrote:
>>
>> From: Andre Przywara 
>>
>> At the moment we rely on the infamous get_ram_size() function to
>learn
>> the actual DRAM size in U-Boot proper. This function has two issues:
>> 1) It only works if the DRAM size is a power of two. We start to see
>> boards which have 3GB of (usable) DRAM, so this does not fit anymore.
>> 2) As U-Boot has no notion of reserved memory so far, it will happily
>> ride through the DRAM, possibly stepping on secure-only memory. This
>> could be a region of DRAM reserved for OP-TEE or some other secure
>> payload, for instance. It will most likely crash in that case.
>>
>> As the SPL DRAM init routine has very accurate knowledge of the
>actual
>> DRAM size, lets propagate this wisdom to U-Boot proper.
>> We re-purpose a currently reserved word in our SPL header for that.
>> The SPL itself stores the detected DRAM size there, and bumps the SPL
>> header version number in that case. U-Boot proper checks for a valid
>> SPL header and a high enough version number, then uses the DRAM size
>> from there. If the SPL header field is not sufficient, we fall back
>to
>> the old DRAM scanning routine.
>>
>> Part of the DRAM might be present and probed by SPL, but not
>accessible
>> by the CPU. They're restricted in the main U-Boot binary, when
>accessing
>> the DRAM size from SPL header.
>>
>> Signed-off-by: Andre Przywara 
>> Signed-off-by: Icenowy Zheng 
>> ---
>> Changes in v2:
>> - Restrict the DRAM size to the accessible range.
>>
>>  arch/arm/include/asm/arch-sunxi/spl.h |  3 ++-
>>  board/sunxi/board.c   | 28
>++-
>>  2 files changed, 29 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/arch-sunxi/spl.h
>b/arch/arm/include/asm/arch-sunxi/spl.h
>> index 014184b638..4baba38b00 100644
>> --- a/arch/arm/include/asm/arch-sunxi/spl.h
>> +++ b/arch/arm/include/asm/arch-sunxi/spl.h
>> @@ -19,6 +19,7 @@
>>
>>  #define SPL_ENV_HEADER_VERSION SPL_VERSION(0, 1)
>>  #define SPL_DT_HEADER_VERSION  SPL_VERSION(0, 2)
>> +#define SPL_DRAM_HEADER_VERSIONSPL_VERSION(0, 3)
>>
>>  #define SPL_ADDR   CONFIG_SUNXI_SRAM_ADDRESS
>>
>> @@ -70,7 +71,7 @@ struct boot_file_head {
>>  * to the users.
>>  */
>> uint32_t dt_name_offset;/* since v0.2, set by
>mksunxiboot */
>> -   uint32_t reserved1;
>> +   uint32_t dram_size; /* in MiB, since v0.3, set by
>SPL */
>> uint32_t boot_media;/* written here by the boot
>ROM */
>> /* A padding area (may be used for storing text strings) */
>> uint32_t string_pool[13];   /* since v0.2, filled by
>mksunxiboot */
>> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
>> index bdec82b065..65ae0c4219 100644
>> --- a/board/sunxi/board.c
>> +++ b/board/sunxi/board.c
>> @@ -281,7 +281,16 @@ static struct boot_file_head *
>get_spl_header(uint8_t req_version)
>>
>>  int dram_init(void)
>>  {
>> -   gd->ram_size = get_ram_size((long *)PHYS_SDRAM_0,
>PHYS_SDRAM_0_SIZE);
>> +   struct boot_file_head *spl =
>get_spl_header(SPL_DRAM_HEADER_VERSION);
>> +
>> +   if (spl == INVALID_SPL_HEADER)
>> +   gd->ram_size = get_ram_size((long *)PHYS_SDRAM_0,
>> +   PHYS_SDRAM_0_SIZE);
>> +   else
>> +   gd->ram_size = (phys_addr_t)spl->dram_size << 20;
>
>How about checking SPL_DRAM_HEADER_VERSION in valid header case?

get_spl_header() does the version check.

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

Re: [U-Boot] [linux-sunxi] [PATCH v2 1/6] sunxi: disable Pine A64 model detection code on other boards

[Jagan Teki]

On Thu, Oct 25, 2018 at 2:53 PM Icenowy Zheng  wrote:
>
> The Pine A64 Plus/non-Plus model detection code is now built on all
> 64-bit ARM SoCs, even if the code cannot be triggered when H5/H6 is in
> use.
>
> Disable them when the board is Pine A64 by adding a Kconfig option that
> is only selected on Pine A64.
>
> On GCC 7.3.1 this makes the size of the function reduces 184 bytes, and
> saves a 104 byte strstr() function, then makes SPL on H6 succeed to
> build.
>
> Signed-off-by: Icenowy Zheng 
> ---

Reviewed-by: Jagan Teki 

Applied to u-boot-sunxi/master
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] [PATCH v2 6/6] sunxi: store DRAM size in SPL header

[Jagan Teki]

On Thu, Oct 25, 2018 at 2:53 PM Icenowy Zheng  wrote:
>
> From: Andre Przywara 
>
> At the moment we rely on the infamous get_ram_size() function to learn
> the actual DRAM size in U-Boot proper. This function has two issues:
> 1) It only works if the DRAM size is a power of two. We start to see
> boards which have 3GB of (usable) DRAM, so this does not fit anymore.
> 2) As U-Boot has no notion of reserved memory so far, it will happily
> ride through the DRAM, possibly stepping on secure-only memory. This
> could be a region of DRAM reserved for OP-TEE or some other secure
> payload, for instance. It will most likely crash in that case.
>
> As the SPL DRAM init routine has very accurate knowledge of the actual
> DRAM size, lets propagate this wisdom to U-Boot proper.
> We re-purpose a currently reserved word in our SPL header for that.
> The SPL itself stores the detected DRAM size there, and bumps the SPL
> header version number in that case. U-Boot proper checks for a valid
> SPL header and a high enough version number, then uses the DRAM size
> from there. If the SPL header field is not sufficient, we fall back to
> the old DRAM scanning routine.
>
> Part of the DRAM might be present and probed by SPL, but not accessible
> by the CPU. They're restricted in the main U-Boot binary, when accessing
> the DRAM size from SPL header.
>
> Signed-off-by: Andre Przywara 
> Signed-off-by: Icenowy Zheng 
> ---
> Changes in v2:
> - Restrict the DRAM size to the accessible range.
>
>  arch/arm/include/asm/arch-sunxi/spl.h |  3 ++-
>  board/sunxi/board.c   | 28 ++-
>  2 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/spl.h 
> b/arch/arm/include/asm/arch-sunxi/spl.h
> index 014184b638..4baba38b00 100644
> --- a/arch/arm/include/asm/arch-sunxi/spl.h
> +++ b/arch/arm/include/asm/arch-sunxi/spl.h
> @@ -19,6 +19,7 @@
>
>  #define SPL_ENV_HEADER_VERSION SPL_VERSION(0, 1)
>  #define SPL_DT_HEADER_VERSION  SPL_VERSION(0, 2)
> +#define SPL_DRAM_HEADER_VERSIONSPL_VERSION(0, 3)
>
>  #define SPL_ADDR   CONFIG_SUNXI_SRAM_ADDRESS
>
> @@ -70,7 +71,7 @@ struct boot_file_head {
>  * to the users.
>  */
> uint32_t dt_name_offset;/* since v0.2, set by mksunxiboot */
> -   uint32_t reserved1;
> +   uint32_t dram_size; /* in MiB, since v0.3, set by SPL */
> uint32_t boot_media;/* written here by the boot ROM */
> /* A padding area (may be used for storing text strings) */
> uint32_t string_pool[13];   /* since v0.2, filled by mksunxiboot 
> */
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index bdec82b065..65ae0c4219 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -281,7 +281,16 @@ static struct boot_file_head * get_spl_header(uint8_t 
> req_version)
>
>  int dram_init(void)
>  {
> -   gd->ram_size = get_ram_size((long *)PHYS_SDRAM_0, PHYS_SDRAM_0_SIZE);
> +   struct boot_file_head *spl = get_spl_header(SPL_DRAM_HEADER_VERSION);
> +
> +   if (spl == INVALID_SPL_HEADER)
> +   gd->ram_size = get_ram_size((long *)PHYS_SDRAM_0,
> +   PHYS_SDRAM_0_SIZE);
> +   else
> +   gd->ram_size = (phys_addr_t)spl->dram_size << 20;

How about checking SPL_DRAM_HEADER_VERSION in valid header case?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 4/7] driver: net: ti: cpsw: update to use SPDX identifier

[Grygorii Strashko]

Update to use SPDX license identifier.

Signed-off-by: Grygorii Strashko 
---
 drivers/net/ti/cpsw.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ti/cpsw.c b/drivers/net/ti/cpsw.c
index 8e2a48c..fe43d14 100644
--- a/drivers/net/ti/cpsw.c
+++ b/drivers/net/ti/cpsw.c
@@ -1,16 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0+
 /*
  * CPSW Ethernet Switch Driver
  *
- * Copyright (C) 2010 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 as
- * published by the Free Software Foundation version 2.
- *
- * This program is distributed "as is" WITHOUT ANY WARRANTY of any
- * kind, whether express or implied; without even the implied warranty
- * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
+ * Copyright (C) 2010-2018 Texas Instruments Incorporated - http://www.ti.com/
  */
 
 #include 
-- 
2.10.5

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

[U-Boot] [PATCH 3/7] drivers: net: keystone_net: drop non dm code

[Grygorii Strashko]

Networking support for all TI K2 boards converted to use DM model and
CONFIG_DM_ETH enabled in all corresponding defconfig files, hence drop
unused non DM K2 networking code.

Signed-off-by: Grygorii Strashko 
---
 arch/arm/include/asm/ti-common/keystone_net.h |  14 --
 board/ti/ks2_evm/board.c  |  53 -
 board/ti/ks2_evm/board.h  |   3 -
 board/ti/ks2_evm/board_k2e.c  |  74 ---
 board/ti/ks2_evm/board_k2g.c  |  18 --
 board/ti/ks2_evm/board_k2hk.c |  42 
 board/ti/ks2_evm/board_k2l.c  |  42 
 drivers/net/ti/keystone_net.c | 287 +-
 8 files changed, 1 insertion(+), 532 deletions(-)

diff --git a/arch/arm/include/asm/ti-common/keystone_net.h 
b/arch/arm/include/asm/ti-common/keystone_net.h
index f89e043..bef1867 100644
--- a/arch/arm/include/asm/ti-common/keystone_net.h
+++ b/arch/arm/include/asm/ti-common/keystone_net.h
@@ -242,18 +242,4 @@ struct mdio_regs {
u32 userphysel1;
 };
 
-struct eth_priv_t {
-   char int_name[32];
-   int rx_flow;
-   int phy_addr;
-   int slave_port;
-   int sgmii_link_type;
-   phy_interface_t phy_if;
-   struct phy_device *phy_dev;
-};
-
-int keystone2_emac_initialize(struct eth_priv_t *eth_priv);
-void sgmii_serdes_setup_156p25mhz(void);
-void sgmii_serdes_shutdown(void);
-
 #endif  /* _KEYSTONE_NET_H_ */
diff --git a/board/ti/ks2_evm/board.c b/board/ti/ks2_evm/board.c
index d81c8e6..72709c0 100644
--- a/board/ti/ks2_evm/board.c
+++ b/board/ti/ks2_evm/board.c
@@ -66,59 +66,6 @@ int board_init(void)
return 0;
 }
 
-#ifdef CONFIG_DRIVER_TI_KEYSTONE_NET
-#ifndef CONFIG_DM_ETH
-int get_eth_env_param(char *env_name)
-{
-   char *env;
-   int res = -1;
-
-   env = env_get(env_name);
-   if (env)
-   res = simple_strtol(env, NULL, 0);
-
-   return res;
-}
-
-int board_eth_init(bd_t *bis)
-{
-   int j;
-   int res;
-   int port_num;
-   char link_type_name[32];
-
-   if (cpu_is_k2g())
-   writel(KS2_ETHERNET_RGMII, KS2_ETHERNET_CFG);
-
-   /* By default, select PA PLL clock as PA clock source */
-#ifndef CONFIG_SOC_K2G
-   if (psc_enable_module(KS2_LPSC_PA))
-   return -1;
-#endif
-   if (psc_enable_module(KS2_LPSC_CPGMAC))
-   return -1;
-   if (psc_enable_module(KS2_LPSC_CRYPTO))
-   return -1;
-
-   if (cpu_is_k2e() || cpu_is_k2l())
-   pll_pa_clk_sel();
-
-   port_num = get_num_eth_ports();
-
-   for (j = 0; j < port_num; j++) {
-   sprintf(link_type_name, "sgmii%d_link_type", j);
-   res = get_eth_env_param(link_type_name);
-   if (res >= 0)
-   eth_priv_cfg[j].sgmii_link_type = res;
-
-   keystone2_emac_initialize(_priv_cfg[j]);
-   }
-
-   return 0;
-}
-#endif
-#endif
-
 #ifdef CONFIG_SPL_BUILD
 void spl_board_init(void)
 {
diff --git a/board/ti/ks2_evm/board.h b/board/ti/ks2_evm/board.h
index 250b649..d0cfbf5 100644
--- a/board/ti/ks2_evm/board.h
+++ b/board/ti/ks2_evm/board.h
@@ -12,8 +12,6 @@
 #include 
 #include "../common/board_detect.h"
 
-extern struct eth_priv_t eth_priv_cfg[];
-
 #if defined(CONFIG_TI_I2C_BOARD_DETECT)
 static inline int board_is_k2g_gp(void)
 {
@@ -38,7 +36,6 @@ static inline int board_is_k2g_ice(void)
 }
 #endif
 
-int get_num_eth_ports(void);
 void spl_init_keystone_plls(void);
 
 #endif
diff --git a/board/ti/ks2_evm/board_k2e.c b/board/ti/ks2_evm/board_k2e.c
index f86a836..ecd4a42 100644
--- a/board/ti/ks2_evm/board_k2e.c
+++ b/board/ti/ks2_evm/board_k2e.c
@@ -89,80 +89,6 @@ struct pll_init_data *get_pll_init_data(int pll)
return data;
 }
 
-#ifdef CONFIG_DRIVER_TI_KEYSTONE_NET
-struct eth_priv_t eth_priv_cfg[] = {
-   {
-   .int_name= "K2E_EMAC0",
-   .rx_flow = 0,
-   .phy_addr= 0,
-   .slave_port  = 1,
-   .sgmii_link_type = SGMII_LINK_MAC_PHY,
-   .phy_if  = PHY_INTERFACE_MODE_SGMII,
-   },
-   {
-   .int_name= "K2E_EMAC1",
-   .rx_flow = 8,
-   .phy_addr= 1,
-   .slave_port  = 2,
-   .sgmii_link_type = SGMII_LINK_MAC_PHY,
-   .phy_if  = PHY_INTERFACE_MODE_SGMII,
-   },
-   {
-   .int_name= "K2E_EMAC2",
-   .rx_flow = 16,
-   .phy_addr= 2,
-   .slave_port  = 3,
-   .sgmii_link_type = SGMII_LINK_MAC_MAC_FORCED,
-   .phy_if  = PHY_INTERFACE_MODE_SGMII,
-   },
-   {
-   .int_name= "K2E_EMAC3",
-   .rx_flow = 24,
-   .phy_addr= 3,
-   .slave_port  = 4,
-   .sgmii_link_type = 

[U-Boot] [PATCH 0/7] driver: net: ti: clean up and code optimization

[Grygorii Strashko]

This series contains set of code clean up and optimizations for TI networking 
drivers.
Patch 1 - Adds drivers/net/ti/ folder and moves all TI's networking code
 in this folder.
Patches 2,3 - keystone2 clean up
Patch 5 - introduces common TI MDIO support library as existing TI SoCs network
 HW IPs have similar MDIO implementation.
Patches 6-7 - conversation of TI CPSW and keystone_net drivers to use common
 TI MDIO support library

tested dhcp and kernel boot on:
- k2e/g/hk/l evms 
- am437x-gpevm and AM5748 IDK

TODO: TODO: As per code and documentation davinci_emac.c seems also can be
re-worked to use common TI MDIO support library and network PHYs framework.
Unfortunately, I have no HW to work with.

Grygorii Strashko (7):
  driver: net: consolidate ti's code in separate folder
  configs: net: convert DRIVER_TI_KEYSTONE_NET kconfig
  drivers: net: keystone_net: drop non dm code
  driver: net: ti: cpsw: update to use SPDX identifier
  driver: net: ti: introduce common mdio support library
  driver: net: ti: cpsw: switch to use common mdio lib
  driver: net: ti: keystone_net: switch to use common mdio lib

 arch/arm/include/asm/ti-common/keystone_net.h |  27 --
 arch/arm/mach-davinci/dp83848.c   |   2 +-
 arch/arm/mach-davinci/et1011c.c   |   2 +-
 arch/arm/mach-davinci/ksz8873.c   |   2 +-
 arch/arm/mach-davinci/lxt972.c|   2 +-
 board/ti/ks2_evm/board.c  |  53 
 board/ti/ks2_evm/board.h  |   3 -
 board/ti/ks2_evm/board_k2e.c  |  74 -
 board/ti/ks2_evm/board_k2g.c  |  18 --
 board/ti/ks2_evm/board_k2hk.c |  42 ---
 board/ti/ks2_evm/board_k2l.c  |  42 ---
 configs/k2e_evm_defconfig |   1 +
 configs/k2e_hs_evm_defconfig  |   1 +
 configs/k2g_evm_defconfig |   1 +
 configs/k2g_hs_evm_defconfig  |   1 +
 configs/k2hk_evm_defconfig|   1 +
 configs/k2hk_hs_evm_defconfig |   1 +
 configs/k2l_evm_defconfig |   1 +
 configs/k2l_hs_evm_defconfig  |   1 +
 drivers/net/Kconfig   |  13 +-
 drivers/net/Makefile  |   4 +-
 drivers/net/ti/Kconfig|  20 ++
 drivers/net/ti/Makefile   |   7 +
 drivers/net/{ => ti}/cpsw-common.c|   0
 drivers/net/{ => ti}/cpsw.c   | 146 +-
 drivers/net/ti/cpsw_mdio.c| 205 +
 drivers/net/ti/cpsw_mdio.h|  18 ++
 drivers/net/{ => ti}/davinci_emac.c   |   0
 drivers/net/{ => ti}/davinci_emac.h   |   0
 drivers/net/{ => ti}/keystone_net.c   | 401 +-
 include/configs/ti_armv7_keystone2.h  |   1 -
 31 files changed, 288 insertions(+), 802 deletions(-)
 create mode 100644 drivers/net/ti/Kconfig
 create mode 100644 drivers/net/ti/Makefile
 rename drivers/net/{ => ti}/cpsw-common.c (100%)
 rename drivers/net/{ => ti}/cpsw.c (90%)
 create mode 100644 drivers/net/ti/cpsw_mdio.c
 create mode 100644 drivers/net/ti/cpsw_mdio.h
 rename drivers/net/{ => ti}/davinci_emac.c (100%)
 rename drivers/net/{ => ti}/davinci_emac.h (100%)
 rename drivers/net/{ => ti}/keystone_net.c (68%)

-- 
2.10.5

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

[U-Boot] [PATCH 7/7] driver: net: ti: keystone_net: switch to use common mdio lib

[Grygorii Strashko]

Update TI Keystone 2 driver to re-use common mdio lib.

Signed-off-by: Grygorii Strashko 
---
 arch/arm/include/asm/ti-common/keystone_net.h |  13 ---
 drivers/net/ti/Makefile   |   2 +-
 drivers/net/ti/keystone_net.c | 118 --
 3 files changed, 18 insertions(+), 115 deletions(-)

diff --git a/arch/arm/include/asm/ti-common/keystone_net.h 
b/arch/arm/include/asm/ti-common/keystone_net.h
index bef1867..bba1048 100644
--- a/arch/arm/include/asm/ti-common/keystone_net.h
+++ b/arch/arm/include/asm/ti-common/keystone_net.h
@@ -57,19 +57,6 @@
 /* MDIO clock output frequency */
 #define EMAC_MDIO_CLOCK_FREQ   250 /* 2.5 MHz */
 
-/* MII Status Register */
-#define MII_STATUS_REG 1
-#define MII_STATUS_LINK_MASK   0x4
-
-#define MDIO_CONTROL_IDLE  0x8000
-#define MDIO_CONTROL_ENABLE0x4000
-#define MDIO_CONTROL_FAULT_ENABLE  0x4
-#define MDIO_CONTROL_FAULT 0x8
-#define MDIO_USERACCESS0_GO0x8000
-#define MDIO_USERACCESS0_WRITE_READ0x0
-#define MDIO_USERACCESS0_WRITE_WRITE   0x4000
-#define MDIO_USERACCESS0_ACK   0x2000
-
 #define EMAC_MACCONTROL_MIIEN_ENABLE   0x20
 #define EMAC_MACCONTROL_FULLDUPLEX_ENABLE  0x1
 #define EMAC_MACCONTROL_GIGABIT_ENABLE BIT(7)
diff --git a/drivers/net/ti/Makefile b/drivers/net/ti/Makefile
index d2b6f20..ee3e4eb 100644
--- a/drivers/net/ti/Makefile
+++ b/drivers/net/ti/Makefile
@@ -4,4 +4,4 @@
 
 obj-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o cpsw-common.o cpsw_mdio.o
 obj-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o
-obj-$(CONFIG_DRIVER_TI_KEYSTONE_NET) += keystone_net.o
+obj-$(CONFIG_DRIVER_TI_KEYSTONE_NET) += keystone_net.o cpsw_mdio.o
diff --git a/drivers/net/ti/keystone_net.c b/drivers/net/ti/keystone_net.c
index 5550572..a3ba91c 100644
--- a/drivers/net/ti/keystone_net.c
+++ b/drivers/net/ti/keystone_net.c
@@ -22,6 +22,8 @@
 #include 
 #include 
 
+#include "cpsw_mdio.h"
+
 DECLARE_GLOBAL_DATA_PTR;
 
 #ifdef KEYSTONE2_EMAC_GIG_ENABLE
@@ -97,93 +99,20 @@ struct ks2_eth_priv {
boolhas_mdio;
 };
 
-/* MDIO */
-
-static int keystone2_mdio_reset(struct mii_dev *bus)
-{
-   u_int32_t clkdiv;
-   struct mdio_regs *adap_mdio = bus->priv;
-
-   clkdiv = (EMAC_MDIO_BUS_FREQ / EMAC_MDIO_CLOCK_FREQ) - 1;
-
-   writel((clkdiv & 0x) | MDIO_CONTROL_ENABLE |
-  MDIO_CONTROL_FAULT | MDIO_CONTROL_FAULT_ENABLE,
-  _mdio->control);
-
-   while (readl(_mdio->control) & MDIO_CONTROL_IDLE)
-   ;
-
-   return 0;
-}
-
-/**
- * keystone2_mdio_read - read a PHY register via MDIO interface.
- * Blocks until operation is complete.
- */
-static int keystone2_mdio_read(struct mii_dev *bus,
-  int addr, int devad, int reg)
-{
-   int tmp;
-   struct mdio_regs *adap_mdio = bus->priv;
-
-   while (readl(_mdio->useraccess0) & MDIO_USERACCESS0_GO)
-   ;
-
-   writel(MDIO_USERACCESS0_GO | MDIO_USERACCESS0_WRITE_READ |
-  ((reg & 0x1f) << 21) | ((addr & 0x1f) << 16),
-  _mdio->useraccess0);
-
-   /* Wait for command to complete */
-   while ((tmp = readl(_mdio->useraccess0)) & MDIO_USERACCESS0_GO)
-   ;
-
-   if (tmp & MDIO_USERACCESS0_ACK)
-   return tmp & 0x;
-
-   return -1;
-}
-
-/**
- * keystone2_mdio_write - write to a PHY register via MDIO interface.
- * Blocks until operation is complete.
- */
-static int keystone2_mdio_write(struct mii_dev *bus,
-   int addr, int devad, int reg, u16 val)
-{
-   struct mdio_regs *adap_mdio = bus->priv;
-
-   while (readl(_mdio->useraccess0) & MDIO_USERACCESS0_GO)
-   ;
-
-   writel(MDIO_USERACCESS0_GO | MDIO_USERACCESS0_WRITE_WRITE |
-  ((reg & 0x1f) << 21) | ((addr & 0x1f) << 16) |
-  (val & 0x), _mdio->useraccess0);
-
-   /* Wait for command to complete */
-   while (readl(_mdio->useraccess0) & MDIO_USERACCESS0_GO)
-   ;
-
-   return 0;
-}
-
 static void  __attribute__((unused))
keystone2_eth_gigabit_enable(struct udevice *dev)
 {
struct ks2_eth_priv *priv = dev_get_priv(dev);
-   u_int16_t data;
-
-   if (priv->has_mdio) {
-   data = keystone2_mdio_read(priv->mdio_bus, priv->phy_addr,
-  MDIO_DEVAD_NONE, 0);
-   /* speed selection MSB */
-   if (!(data & (1 << 6)))
-   return;
-   }
 
/*
 * Check if link detected is giga-bit
 * If Gigabit mode detected, enable gigbit in MAC
 */
+   if (priv->has_mdio) {
+   if (priv->phydev->speed != 1000)
+   return;
+   }
+
writel(readl(DEVICE_EMACSL_BASE(priv->slave_port - 1) +
 CPGMACSL_REG_CTL) |

[U-Boot] [PATCH 2/7] configs: net: convert DRIVER_TI_KEYSTONE_NET kconfig

[Grygorii Strashko]

Convert DRIVER_TI_KEYSTONE_NET to Kconfig.

Signed-off-by: Grygorii Strashko 
---
 configs/k2e_evm_defconfig| 1 +
 configs/k2e_hs_evm_defconfig | 1 +
 configs/k2g_evm_defconfig| 1 +
 configs/k2g_hs_evm_defconfig | 1 +
 configs/k2hk_evm_defconfig   | 1 +
 configs/k2hk_hs_evm_defconfig| 1 +
 configs/k2l_evm_defconfig| 1 +
 configs/k2l_hs_evm_defconfig | 1 +
 drivers/net/ti/Kconfig   | 5 +
 include/configs/ti_armv7_keystone2.h | 1 -
 10 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/configs/k2e_evm_defconfig b/configs/k2e_evm_defconfig
index d744cb1..67b1f30 100644
--- a/configs/k2e_evm_defconfig
+++ b/configs/k2e_evm_defconfig
@@ -56,3 +56,4 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_DRIVER_TI_KEYSTONE_NET=y
diff --git a/configs/k2e_hs_evm_defconfig b/configs/k2e_hs_evm_defconfig
index 87faf3d..1abda84 100644
--- a/configs/k2e_hs_evm_defconfig
+++ b/configs/k2e_hs_evm_defconfig
@@ -49,3 +49,4 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_DRIVER_TI_KEYSTONE_NET=y
diff --git a/configs/k2g_evm_defconfig b/configs/k2g_evm_defconfig
index a96029c..bc4b92b 100644
--- a/configs/k2g_evm_defconfig
+++ b/configs/k2g_evm_defconfig
@@ -60,3 +60,4 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_DRIVER_TI_KEYSTONE_NET=y
diff --git a/configs/k2g_hs_evm_defconfig b/configs/k2g_hs_evm_defconfig
index 9e75500..66d8220 100644
--- a/configs/k2g_hs_evm_defconfig
+++ b/configs/k2g_hs_evm_defconfig
@@ -53,3 +53,4 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_DRIVER_TI_KEYSTONE_NET=y
diff --git a/configs/k2hk_evm_defconfig b/configs/k2hk_evm_defconfig
index 8c7d362..f66d922 100644
--- a/configs/k2hk_evm_defconfig
+++ b/configs/k2hk_evm_defconfig
@@ -56,3 +56,4 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_DRIVER_TI_KEYSTONE_NET=y
diff --git a/configs/k2hk_hs_evm_defconfig b/configs/k2hk_hs_evm_defconfig
index c8f4bbe..dd91a51 100644
--- a/configs/k2hk_hs_evm_defconfig
+++ b/configs/k2hk_hs_evm_defconfig
@@ -49,3 +49,4 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_DRIVER_TI_KEYSTONE_NET=y
diff --git a/configs/k2l_evm_defconfig b/configs/k2l_evm_defconfig
index dd91aa5..4f04caa 100644
--- a/configs/k2l_evm_defconfig
+++ b/configs/k2l_evm_defconfig
@@ -56,3 +56,4 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_DRIVER_TI_KEYSTONE_NET=y
diff --git a/configs/k2l_hs_evm_defconfig b/configs/k2l_hs_evm_defconfig
index ac400e4..9ce23de 100644
--- a/configs/k2l_hs_evm_defconfig
+++ b/configs/k2l_hs_evm_defconfig
@@ -48,3 +48,4 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_DRIVER_TI_KEYSTONE_NET=y
diff --git a/drivers/net/ti/Kconfig b/drivers/net/ti/Kconfig
index 35a6b5d..c38e273 100644
--- a/drivers/net/ti/Kconfig
+++ b/drivers/net/ti/Kconfig
@@ -13,3 +13,8 @@ config DRIVER_TI_EMAC
bool "TI Davinci EMAC"
help
   Support for davinci emac
+
+config DRIVER_TI_KEYSTONE_NET
+   bool "TI Keystone 2 Ethernet"
+   help
+  This driver supports the TI Keystone 2 Ethernet subsystem
\ No newline at end of file
diff --git a/include/configs/ti_armv7_keystone2.h 
b/include/configs/ti_armv7_keystone2.h
index cc823c5..5e504f6 100644
--- a/include/configs/ti_armv7_keystone2.h
+++ b/include/configs/ti_armv7_keystone2.h
@@ -128,7 +128,6 @@
 #define CONFIG_KSNAV_NETCP_PDMA_TX_SND_QUEUE   KS2_NETCP_PDMA_TX_SND_QUEUE
 
 /* Keystone net */
-#define CONFIG_DRIVER_TI_KEYSTONE_NET
 #define CONFIG_KSNET_MAC_ID_BASE   KS2_MAC_ID_BASE_ADDR
 #define CONFIG_KSNET_NETCP_BASEKS2_NETCP_BASE
 #define CONFIG_KSNET_SERDES_SGMII_BASE KS2_SGMII_SERDES_BASE
-- 
2.10.5

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

[U-Boot] [PATCH 1/7] driver: net: consolidate ti's code in separate folder

[Grygorii Strashko]

Add drivers/net/ti/ folder and move all TI's code in this folder for better
maintenance.

Signed-off-by: Grygorii Strashko 
---
 arch/arm/mach-davinci/dp83848.c |  2 +-
 arch/arm/mach-davinci/et1011c.c |  2 +-
 arch/arm/mach-davinci/ksz8873.c |  2 +-
 arch/arm/mach-davinci/lxt972.c  |  2 +-
 drivers/net/Kconfig | 13 +
 drivers/net/Makefile|  4 +---
 drivers/net/ti/Kconfig  | 15 +++
 drivers/net/ti/Makefile |  7 +++
 drivers/net/{ => ti}/cpsw-common.c  |  0
 drivers/net/{ => ti}/cpsw.c |  0
 drivers/net/{ => ti}/davinci_emac.c |  0
 drivers/net/{ => ti}/davinci_emac.h |  0
 drivers/net/{ => ti}/keystone_net.c |  0
 13 files changed, 28 insertions(+), 19 deletions(-)
 create mode 100644 drivers/net/ti/Kconfig
 create mode 100644 drivers/net/ti/Makefile
 rename drivers/net/{ => ti}/cpsw-common.c (100%)
 rename drivers/net/{ => ti}/cpsw.c (100%)
 rename drivers/net/{ => ti}/davinci_emac.c (100%)
 rename drivers/net/{ => ti}/davinci_emac.h (100%)
 rename drivers/net/{ => ti}/keystone_net.c (100%)

diff --git a/arch/arm/mach-davinci/dp83848.c b/arch/arm/mach-davinci/dp83848.c
index 595e3ca..7115d7b 100644
--- a/arch/arm/mach-davinci/dp83848.c
+++ b/arch/arm/mach-davinci/dp83848.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 #include 
-#include "../../../drivers/net/davinci_emac.h"
+#include "../../../drivers/net/ti/davinci_emac.h"
 
 #ifdef CONFIG_DRIVER_TI_EMAC
 
diff --git a/arch/arm/mach-davinci/et1011c.c b/arch/arm/mach-davinci/et1011c.c
index 3d02274..bfb7ff2 100644
--- a/arch/arm/mach-davinci/et1011c.c
+++ b/arch/arm/mach-davinci/et1011c.c
@@ -9,7 +9,7 @@
 #include 
 #include 
 #include 
-#include "../../../drivers/net/davinci_emac.h"
+#include "../../../drivers/net/ti/davinci_emac.h"
 
 #ifdef CONFIG_DRIVER_TI_EMAC
 
diff --git a/arch/arm/mach-davinci/ksz8873.c b/arch/arm/mach-davinci/ksz8873.c
index 899cff0..85b0c26 100644
--- a/arch/arm/mach-davinci/ksz8873.c
+++ b/arch/arm/mach-davinci/ksz8873.c
@@ -19,7 +19,7 @@
 #include 
 #include 
 #include 
-#include "../../../drivers/net/davinci_emac.h"
+#include "../../../drivers/net/ti/davinci_emac.h"
 
 int ksz8873_is_phy_connected(int phy_addr)
 {
diff --git a/arch/arm/mach-davinci/lxt972.c b/arch/arm/mach-davinci/lxt972.c
index 170e4a5..b54f67d 100644
--- a/arch/arm/mach-davinci/lxt972.c
+++ b/arch/arm/mach-davinci/lxt972.c
@@ -13,7 +13,7 @@
 #include 
 #include 
 #include 
-#include "../../../drivers/net/davinci_emac.h"
+#include "../../../drivers/net/ti/davinci_emac.h"
 
 #ifdef CONFIG_DRIVER_TI_EMAC
 
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f1f0e2d..e904c5e 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1,5 +1,6 @@
 source "drivers/net/phy/Kconfig"
 source "drivers/net/pfe_eth/Kconfig"
+source "drivers/net/ti/Kconfig"
 
 config DM_ETH
bool "Enable Driver Model for Ethernet drivers"
@@ -11,13 +12,6 @@ config DM_ETH
  This is currently implemented in net/eth-uclass.c
  Look in include/net.h for details.
 
-config DRIVER_TI_CPSW
-   bool "TI Common Platform Ethernet Switch"
-   select PHYLIB
-   help
- This driver supports the TI three port switch gigabit ethernet
- subsystem found in the TI SoCs.
-
 menuconfig NETDEVICES
bool "Network device support"
depends on NET
@@ -322,11 +316,6 @@ config SH_ETHER
help
  This driver supports the Ethernet for Renesas SH and ARM SoCs.
 
-config DRIVER_TI_EMAC
-   bool "TI Davinci EMAC"
-   help
-  Support for davinci emac
-
 config XILINX_AXIEMAC
depends on DM_ETH && (MICROBLAZE || ARCH_ZYNQ || ARCH_ZYNQMP)
select PHYLIB
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 48a2878..8e33d7a 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -30,7 +30,6 @@ obj-$(CONFIG_FTGMAC100) += ftgmac100.o
 obj-$(CONFIG_FTMAC110) += ftmac110.o
 obj-$(CONFIG_FTMAC100) += ftmac100.o
 obj-$(CONFIG_GMAC_ROCKCHIP) += gmac_rockchip.o
-obj-$(CONFIG_DRIVER_TI_KEYSTONE_NET) += keystone_net.o
 obj-$(CONFIG_KS8851_MLL) += ks8851_mll.o
 obj-$(CONFIG_LAN91C96) += lan91c96.o
 obj-$(CONFIG_LPC32XX_ETH) += lpc32xx_eth.o
@@ -56,9 +55,7 @@ obj-$(CONFIG_SH_ETHER) += sh_eth.o
 obj-$(CONFIG_RENESAS_RAVB) += ravb.o
 obj-$(CONFIG_SMC9) += smc9.o
 obj-$(CONFIG_SMC911X) += smc911x.o
-obj-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o
 obj-$(CONFIG_TSEC_ENET) += tsec.o fsl_mdio.o
-obj-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o cpsw-common.o
 obj-$(CONFIG_FMAN_ENET) += fsl_mdio.o
 obj-$(CONFIG_ULI526X) += uli526x.o
 obj-$(CONFIG_VSC7385_ENET) += vsc7385.o
@@ -73,3 +70,4 @@ obj-$(CONFIG_PIC32_ETH) += pic32_mdio.o pic32_eth.o
 obj-$(CONFIG_DWC_ETH_QOS) += dwc_eth_qos.o
 obj-$(CONFIG_FSL_PFE) += pfe_eth/
 obj-$(CONFIG_SNI_AVE) += sni_ave.o
+obj-y += ti/
diff --git a/drivers/net/ti/Kconfig b/drivers/net/ti/Kconfig
new file mode 100644
index 000..35a6b5d
--- /dev/null
+++ 

[U-Boot] [PATCH 5/7] driver: net: ti: introduce common mdio support library

[Grygorii Strashko]

All existing TI SoCs network HW have similar MDIO implementation, so
introduce common mdio support library which can be reused by TI networking
drivers.

Signed-off-by: Grygorii Strashko 
---
 drivers/net/ti/Makefile|   2 +-
 drivers/net/ti/cpsw_mdio.c | 205 +
 drivers/net/ti/cpsw_mdio.h |  18 
 3 files changed, 224 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/ti/cpsw_mdio.c
 create mode 100644 drivers/net/ti/cpsw_mdio.h

diff --git a/drivers/net/ti/Makefile b/drivers/net/ti/Makefile
index 4ab4a27..d2b6f20 100644
--- a/drivers/net/ti/Makefile
+++ b/drivers/net/ti/Makefile
@@ -2,6 +2,6 @@
 #
 # Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
 
-obj-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o cpsw-common.o
+obj-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o cpsw-common.o cpsw_mdio.o
 obj-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o
 obj-$(CONFIG_DRIVER_TI_KEYSTONE_NET) += keystone_net.o
diff --git a/drivers/net/ti/cpsw_mdio.c b/drivers/net/ti/cpsw_mdio.c
new file mode 100644
index 000..ed9dd27
--- /dev/null
+++ b/drivers/net/ti/cpsw_mdio.c
@@ -0,0 +1,205 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * CPSW MDIO generic driver for TI AMxx/K2x/EMAC devices.
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include 
+#include 
+#include 
+
+struct cpsw_mdio_regs {
+   u32 version;
+   u32 control;
+#define CONTROL_IDLE   BIT(31)
+#define CONTROL_ENABLE BIT(30)
+#define CONTROL_FAULT  BIT(19)
+#define CONTROL_FAULT_ENABLE   BIT(18)
+#define CONTROL_DIV_MASK   GENMASK(15, 0)
+
+   u32 alive;
+   u32 link;
+   u32 linkintraw;
+   u32 linkintmasked;
+   u32 __reserved_0[2];
+   u32 userintraw;
+   u32 userintmasked;
+   u32 userintmaskset;
+   u32 userintmaskclr;
+   u32 __reserved_1[20];
+
+   struct {
+   u32 access;
+   u32 physel;
+#define USERACCESS_GO  BIT(31)
+#define USERACCESS_WRITE   BIT(30)
+#define USERACCESS_ACK BIT(29)
+#define USERACCESS_READ(0)
+#define USERACCESS_PHY_REG_SHIFT   (21)
+#define USERACCESS_PHY_ADDR_SHIFT  (16)
+#define USERACCESS_DATAGENMASK(15, 0)
+   } user[0];
+};
+
+#define CPSW_MDIO_DIV_DEF  0xff
+#define PHY_REG_MASK   0x1f
+#define PHY_ID_MASK0x1f
+
+/*
+ * This timeout definition is a worst-case ultra defensive measure against
+ * unexpected controller lock ups.  Ideally, we should never ever hit this
+ * scenario in practice.
+ */
+#define CPSW_MDIO_TIMEOUT100 /* msecs */
+
+struct cpsw_mdio {
+   struct cpsw_mdio_regs *regs;
+   struct mii_dev *bus;
+   int div;
+};
+
+/* wait until hardware is ready for another user access */
+static inline u32 cpsw_mdio_wait_for_user_access(struct cpsw_mdio *mdio)
+{
+   u32 reg = 0;
+   int timeout = CPSW_MDIO_TIMEOUT;
+
+   while (timeout-- && ((reg = readl(>regs->user[0].access))
+  & USERACCESS_GO))
+   udelay(10);
+
+   if (timeout == -1) {
+   printf("wait_for_user_access Timeout\n");
+   return -ETIMEDOUT;
+   }
+
+   return reg;
+}
+
+static int cpsw_mdio_read(struct mii_dev *bus, int phy_id,
+ int dev_addr, int phy_reg)
+{
+   struct cpsw_mdio *mdio = bus->priv;
+   int data;
+   u32 reg;
+
+   if (phy_reg & ~PHY_REG_MASK || phy_id & ~PHY_ID_MASK)
+   return -EINVAL;
+
+   cpsw_mdio_wait_for_user_access(mdio);
+   reg = (USERACCESS_GO | USERACCESS_READ |
+  (phy_reg << USERACCESS_PHY_REG_SHIFT) |
+  (phy_id << USERACCESS_PHY_ADDR_SHIFT));
+   writel(reg, >regs->user[0].access);
+   reg = cpsw_mdio_wait_for_user_access(mdio);
+
+   data = (reg & USERACCESS_ACK) ? (reg & USERACCESS_DATA) : -1;
+   return data;
+}
+
+static int cpsw_mdio_write(struct mii_dev *bus, int phy_id, int dev_addr,
+  int phy_reg, u16 data)
+{
+   struct cpsw_mdio *mdio = bus->priv;
+   u32 reg;
+
+   if (phy_reg & ~PHY_REG_MASK || phy_id & ~PHY_ID_MASK)
+   return -EINVAL;
+
+   cpsw_mdio_wait_for_user_access(mdio);
+   reg = (USERACCESS_GO | USERACCESS_WRITE |
+  (phy_reg << USERACCESS_PHY_REG_SHIFT) |
+  (phy_id << USERACCESS_PHY_ADDR_SHIFT) |
+  (data & USERACCESS_DATA));
+   writel(reg, >regs->user[0].access);
+   cpsw_mdio_wait_for_user_access(mdio);
+
+   return 0;
+}
+
+u32 cpsw_mdio_get_alive(struct mii_dev *bus)
+{
+   struct cpsw_mdio *mdio = bus->priv;
+   u32 val;
+
+   val = readl(>regs->control);
+   return val & GENMASK(15, 0);
+}
+
+struct mii_dev *cpsw_mdio_init(const char *name, u32 mdio_base,
+  u32 bus_freq, int fck_freq)
+{
+   

[U-Boot] [PATCH 6/7] driver: net: ti: cpsw: switch to use common mdio lib

[Grygorii Strashko]

Update TI CPSW driver to re-use common mdio lib

Signed-off-by: Grygorii Strashko 
---
 drivers/net/ti/cpsw.c | 134 +++---
 1 file changed, 6 insertions(+), 128 deletions(-)

diff --git a/drivers/net/ti/cpsw.c b/drivers/net/ti/cpsw.c
index fe43d14..f5fd02e 100644
--- a/drivers/net/ti/cpsw.c
+++ b/drivers/net/ti/cpsw.c
@@ -21,11 +21,11 @@
 #include 
 #include 
 
+#include "cpsw_mdio.h"
+
 DECLARE_GLOBAL_DATA_PTR;
 
 #define BITMASK(bits)  (BIT(bits) - 1)
-#define PHY_REG_MASK   0x1f
-#define PHY_ID_MASK0x1f
 #define NUM_DESCS  (PKTBUFSRX * 2)
 #define PKT_MIN60
 #define PKT_MAX(1500 + 14 + 4 + 4)
@@ -76,37 +76,8 @@ DECLARE_GLOBAL_DATA_PTR;
  * unexpected controller lock ups.  Ideally, we should never ever hit this
  * scenario in practice.
  */
-#define MDIO_TIMEOUT100 /* msecs */
 #define CPDMA_TIMEOUT  100 /* msecs */
 
-struct cpsw_mdio_regs {
-   u32 version;
-   u32 control;
-#define CONTROL_IDLE   BIT(31)
-#define CONTROL_ENABLE BIT(30)
-
-   u32 alive;
-   u32 link;
-   u32 linkintraw;
-   u32 linkintmasked;
-   u32 __reserved_0[2];
-   u32 userintraw;
-   u32 userintmasked;
-   u32 userintmaskset;
-   u32 userintmaskclr;
-   u32 __reserved_1[20];
-
-   struct {
-   u32 access;
-   u32 physel;
-#define USERACCESS_GO  BIT(31)
-#define USERACCESS_WRITE   BIT(30)
-#define USERACCESS_ACK BIT(29)
-#define USERACCESS_READ(0)
-#define USERACCESS_DATA(0x)
-   } user[0];
-};
-
 struct cpsw_regs {
u32 id_ver;
u32 control;
@@ -484,100 +455,6 @@ static inline void cpsw_ale_port_state(struct cpsw_priv 
*priv, int port,
__raw_writel(tmp, priv->ale_regs + offset);
 }
 
-static struct cpsw_mdio_regs *mdio_regs;
-
-/* wait until hardware is ready for another user access */
-static inline u32 wait_for_user_access(void)
-{
-   u32 reg = 0;
-   int timeout = MDIO_TIMEOUT;
-
-   while (timeout-- &&
-   ((reg = __raw_readl(_regs->user[0].access)) & USERACCESS_GO))
-   udelay(10);
-
-   if (timeout == -1) {
-   printf("wait_for_user_access Timeout\n");
-   return -ETIMEDOUT;
-   }
-   return reg;
-}
-
-/* wait until hardware state machine is idle */
-static inline void wait_for_idle(void)
-{
-   int timeout = MDIO_TIMEOUT;
-
-   while (timeout-- &&
-   ((__raw_readl(_regs->control) & CONTROL_IDLE) == 0))
-   udelay(10);
-
-   if (timeout == -1)
-   printf("wait_for_idle Timeout\n");
-}
-
-static int cpsw_mdio_read(struct mii_dev *bus, int phy_id,
-   int dev_addr, int phy_reg)
-{
-   int data;
-   u32 reg;
-
-   if (phy_reg & ~PHY_REG_MASK || phy_id & ~PHY_ID_MASK)
-   return -EINVAL;
-
-   wait_for_user_access();
-   reg = (USERACCESS_GO | USERACCESS_READ | (phy_reg << 21) |
-  (phy_id << 16));
-   __raw_writel(reg, _regs->user[0].access);
-   reg = wait_for_user_access();
-
-   data = (reg & USERACCESS_ACK) ? (reg & USERACCESS_DATA) : -1;
-   return data;
-}
-
-static int cpsw_mdio_write(struct mii_dev *bus, int phy_id, int dev_addr,
-   int phy_reg, u16 data)
-{
-   u32 reg;
-
-   if (phy_reg & ~PHY_REG_MASK || phy_id & ~PHY_ID_MASK)
-   return -EINVAL;
-
-   wait_for_user_access();
-   reg = (USERACCESS_GO | USERACCESS_WRITE | (phy_reg << 21) |
-  (phy_id << 16) | (data & USERACCESS_DATA));
-   __raw_writel(reg, _regs->user[0].access);
-   wait_for_user_access();
-
-   return 0;
-}
-
-static void cpsw_mdio_init(const char *name, u32 mdio_base, u32 div)
-{
-   struct mii_dev *bus = mdio_alloc();
-
-   mdio_regs = (struct cpsw_mdio_regs *)mdio_base;
-
-   /* set enable and clock divider */
-   __raw_writel(div | CONTROL_ENABLE, _regs->control);
-
-   /*
-* wait for scan logic to settle:
-* the scan time consists of (a) a large fixed component, and (b) a
-* small component that varies with the mii bus frequency.  These
-* were estimated using measurements at 1.1 and 2.2 MHz on tnetv107x
-* silicon.  Since the effect of (b) was found to be largely
-* negligible, we keep things simple here.
-*/
-   udelay(1000);
-
-   bus->read = cpsw_mdio_read;
-   bus->write = cpsw_mdio_write;
-   strcpy(bus->name, name);
-
-   mdio_register(bus);
-}
-
 /* Set a self-clearing bit in a register, and wait for it to clear */
 static inline void setbit_and_wait_for_clear32(void *addr)
 {
@@ -1003,7 +880,7 @@ static int cpsw_phy_init(struct cpsw_priv *priv, struct 

Re: [U-Boot] [PATCH v2 0/6] sunxi: extend SPL header to propagate DRAM size and H6 3GiB DRAM support

[Icenowy Zheng]

于 2018年10月25日 GMT+08:00 下午5:23:01, Icenowy Zheng  写到:
>This series tries to solve three issues we currently have on
>Allwinner boards:
>- The DRAM sizing routine can only cope with power-of-two sized DRAM.
>- The DRAM sizing routine steps through all DRAM, possibly hitting
>secure
>  memory.
>- The SPL header versioning is quite strict and tends to break every
>time
>  we need to update it.
>- On some Allwinner SoCs the maximum supported DRAM size of the DRAM
>  controller is bigger than the accessible DRAM size of the CPU.
>
>So Andre Przywara adapted something along the lines of semantic
>versioning[1], where we can add backwards-compatible changes to the SPL
>header without breaking every tool.
>
>The second patch and the third patches introduces the version schema
>and
>does necessary refactors, then the fourth and the fifth patches prepare
>for 3GiB memory support. The sixth patch finally enables the SPL header
>to store the the DRAM size, and let U-Boot binary check which range is
>accessible when picking the data.
>
>The first patch is a prepare for the other patches, as without it newly
>introduced code will make H6 SPL overflow, which makes the patchset not
>possible to test, as the only available 3GiB DRAM device now is the
>3GiB version of Pine H64 sample.

Jagan, could you have a check on this patchset and apply it?

Thanks!

>
>Andre Przywara (3):
>  sunxi: Extend SPL header versioning
>  sunxi: board.c: refactor SPL header checks
>  sunxi: store DRAM size in SPL header
>
>Icenowy Zheng (3):
>  sunxi: disable Pine A64 model detection code on other boards
>  sunxi: map DRAM part with 3G size
>  sunxi: add Kconfig option for the maximum accessible DRAM
>
> arch/arm/include/asm/arch-sunxi/spl.h | 22 +---
> arch/arm/mach-sunxi/Kconfig   | 18 +++
> arch/arm/mach-sunxi/board.c   |  2 +-
> board/sunxi/board.c   | 74 ++-
> configs/pine64_plus_defconfig |  1 +
> 5 files changed, 97 insertions(+), 20 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] MAINTAINERS: add NXP linux team maillist as i.MX reviewer

[Peng Fan]

Add NXP linux team upstream maillist as reviewer

Signed-off-by: Peng Fan 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index cf8f73f200..b39b6fc739 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -121,6 +121,7 @@ F:  drivers/spi/bcmstb_spi.c
 ARM FREESCALE IMX
 M: Stefano Babic 
 M: Fabio Estevam 
+R: NXP Linux Team 
 S: Maintained
 T: git git://git.denx.de/u-boot-imx.git
 F: arch/arm/cpu/arm1136/mx*/
-- 
2.14.1

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

[U-Boot] [PATCH 3/3] pci: layerscape: Add the dts fixup for EP and RC

[Xiaowei Bao]

Add the dts fixup when PCI controller work diffferent mode.

Signed-off-by: Xiaowei Bao 
---
 drivers/pci/pcie_layerscape_fixup.c |   25 +++--
 1 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pcie_layerscape_fixup.c 
b/drivers/pci/pcie_layerscape_fixup.c
index 1a17bd9..089e031 100644
--- a/drivers/pci/pcie_layerscape_fixup.c
+++ b/drivers/pci/pcie_layerscape_fixup.c
@@ -218,7 +218,7 @@ static void fdt_fixup_pcie(void *blob)
 }
 #endif
 
-static void ft_pcie_ls_setup(void *blob, struct ls_pcie *pcie)
+static void ft_pcie_rc_fix(void *blob, struct ls_pcie *pcie)
 {
int off;
uint svr;
@@ -243,12 +243,33 @@ static void ft_pcie_ls_setup(void *blob, struct ls_pcie 
*pcie)
return;
}
 
-   if (pcie->enabled)
+   if (pcie->enabled && pcie->mode == PCI_HEADER_TYPE_BRIDGE)
+   fdt_set_node_status(blob, off, FDT_STATUS_OKAY, 0);
+   else
+   fdt_set_node_status(blob, off, FDT_STATUS_DISABLED, 0);
+}
+
+static void ft_pcie_ep_fix(void *blob, struct ls_pcie *pcie)
+{
+   int off;
+
+   off = fdt_node_offset_by_compat_reg(blob, "fsl,ls-pcie-ep",
+   pcie->dbi_res.start);
+   if (off < 0)
+   return;
+
+   if (pcie->enabled && pcie->mode == PCI_HEADER_TYPE_NORMAL)
fdt_set_node_status(blob, off, FDT_STATUS_OKAY, 0);
else
fdt_set_node_status(blob, off, FDT_STATUS_DISABLED, 0);
 }
 
+static void ft_pcie_ls_setup(void *blob, struct ls_pcie *pcie)
+{
+   ft_pcie_ep_fix(blob, pcie);
+   ft_pcie_rc_fix(blob, pcie);
+}
+
 /* Fixup Kernel DT for PCIe */
 void ft_pci_setup(void *blob, bd_t *bd)
 {
-- 
1.7.1

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

[U-Boot] [PATCH 1/3] pci: layerscape: Modify the EP and RC mode judge method

[Xiaowei Bao]

Modify the RC and EP mode judge method, save the mode as a variable,
the variable will be used by other function.

Signed-off-by: Xiaowei Bao 
---
 drivers/pci/pcie_layerscape.c |   18 --
 drivers/pci/pcie_layerscape.h |1 +
 2 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 3b7377a..17cba46 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -438,9 +438,7 @@ static int ls_pcie_probe(struct udevice *dev)
struct ls_pcie *pcie = dev_get_priv(dev);
const void *fdt = gd->fdt_blob;
int node = dev_of_offset(dev);
-   u8 header_type;
u16 link_sta;
-   bool ep_mode;
uint svr;
int ret;
fdt_size_t cfg_size;
@@ -524,15 +522,15 @@ static int ls_pcie_probe(struct udevice *dev)
  (unsigned long)pcie->ctrl, (unsigned long)pcie->cfg0,
  pcie->big_endian);
 
-   header_type = readb(pcie->dbi + PCI_HEADER_TYPE);
-   ep_mode = (header_type & 0x7f) == PCI_HEADER_TYPE_NORMAL;
-   printf("PCIe%u: %s %s", pcie->idx, dev->name,
-  ep_mode ? "Endpoint" : "Root Complex");
+   pcie->mode = readb(pcie->dbi + PCI_HEADER_TYPE) & 0x7f;
 
-   if (ep_mode)
-   ls_pcie_setup_ep(pcie);
-   else
-   ls_pcie_setup_ctrl(pcie);
+   if (pcie->mode == PCI_HEADER_TYPE_NORMAL) {
+   printf("PCIe%u: %s %s", pcie->idx, dev->name, "Endpoint");
+   ls_pcie_setup_ep(pcie);
+   } else {
+   printf("PCIe%u: %s %s", pcie->idx, dev->name, "Root Complex");
+   ls_pcie_setup_ctrl(pcie);
+   }
 
if (!ls_pcie_link_up(pcie)) {
/* Let the user know there's no PCIe link */
diff --git a/drivers/pci/pcie_layerscape.h b/drivers/pci/pcie_layerscape.h
index 8770b44..ddfbba6 100644
--- a/drivers/pci/pcie_layerscape.h
+++ b/drivers/pci/pcie_layerscape.h
@@ -144,6 +144,7 @@ struct ls_pcie {
bool big_endian;
bool enabled;
int next_lut_index;
+   int mode;
 };
 
 extern struct list_head ls_pcie_list;
-- 
1.7.1

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

[U-Boot] [PATCH 2/3] pci: layerscape: Do not scan when PEX work in EP mode

[Xiaowei Bao]

Don't scan the bus when the PEX work in EP mode.

Signed-off-by: Xiaowei Bao 
---
 drivers/pci/pcie_layerscape.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 17cba46..db1375a 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -225,6 +225,9 @@ static int ls_pcie_addr_valid(struct ls_pcie *pcie, 
pci_dev_t bdf)
 {
struct udevice *bus = pcie->bus;
 
+   if (pcie->mode == PCI_HEADER_TYPE_NORMAL)
+   return -ENODEV;
+
if (!pcie->enabled)
return -ENXIO;
 
-- 
1.7.1

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

Re: [U-Boot] [PATCH] ARM: dts: fsl-imx8qxp-mek: Move regulator outside "simple-bus"

[Peng Fan]

> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2018年10月26日 8:57
> To: Peng Fan 
> Cc: Stefano Babic ; U-Boot-Denx 
> Subject: Re: [PATCH] ARM: dts: fsl-imx8qxp-mek: Move regulator outside
> "simple-bus"
> 
> Hi Peng,
> 
> On Thu, Oct 25, 2018 at 9:54 PM Peng Fan  wrote:
> 
> > > - regulators {
> >
> > Will it be better to keep regulators node? Currently it only has the
> > usdhc2, but in future, the usb regulator will also be added.
> 
> When USB regulator gets added it will stay below the usdhc2 regulator.
> No problem about this.
> 
> Upstream device tree maintainers do not like this unneeded regulator container
> node, so we should better align with upstream here.

ok for me. Acked-by: Peng Fan 

Thanks,
Peng.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: dts: fsl-imx8qxp-mek: Move regulator outside "simple-bus"

[Fabio Estevam]

Hi Peng,

On Thu, Oct 25, 2018 at 9:54 PM Peng Fan  wrote:

> > - regulators {
>
> Will it be better to keep regulators node? Currently it only has the usdhc2, 
> but in future,
> the usb regulator will also be added.

When USB regulator gets added it will stay below the usdhc2 regulator.
No problem about this.

Upstream device tree maintainers do not like this unneeded regulator
container node, so we should better align with upstream here.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: dts: fsl-imx8qxp-mek: Move regulator outside "simple-bus"

[Peng Fan]

Hi Fabio,

> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2018年10月26日 8:50
> To: sba...@denx.de
> Cc: Peng Fan ; u-boot@lists.denx.de; Fabio Estevam
> 
> Subject: [PATCH] ARM: dts: fsl-imx8qxp-mek: Move regulator outside
> "simple-bus"
> 
> Commit 3c28576bb0f0 ("arm: dts: imx8qxp: fix build warining") fixed the dts
> warning by removing the unnecessary #address-cells/#size-cells, but the
> recommendation for regulators is not to place them under "simple-bus", so
> move the reg_usdhc2_vmmc regulator accordingly.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  arch/arm/dts/fsl-imx8qxp-mek.dts | 20 
>  1 file changed, 8 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm/dts/fsl-imx8qxp-mek.dts
> b/arch/arm/dts/fsl-imx8qxp-mek.dts
> index c14e184..adab494 100644
> --- a/arch/arm/dts/fsl-imx8qxp-mek.dts
> +++ b/arch/arm/dts/fsl-imx8qxp-mek.dts
> @@ -16,18 +16,14 @@
>   stdout-path = 
>   };
> 
> - regulators {

Will it be better to keep regulators node? Currently it only has the usdhc2, 
but in future, 
the usb regulator will also be added.

Thanks,
Peng.

> - compatible = "simple-bus";
> -
> - reg_usdhc2_vmmc: usdhc2-vmmc {
> - compatible = "regulator-fixed";
> - regulator-name = "SD1_SPWR";
> - regulator-min-microvolt = <300>;
> - regulator-max-microvolt = <300>;
> - gpio = < 19 GPIO_ACTIVE_HIGH>;
> - off-on-delay = <3480>;
> - enable-active-high;
> - };
> + reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
> + compatible = "regulator-fixed";
> + regulator-name = "SD1_SPWR";
> + regulator-min-microvolt = <300>;
> + regulator-max-microvolt = <300>;
> + gpio = < 19 GPIO_ACTIVE_HIGH>;
> + off-on-delay = <3480>;
> + enable-active-high;
>   };
>  };
> 
> --
> 2.7.4

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

[U-Boot] [PATCH] ARM: dts: fsl-imx8qxp-mek: Move regulator outside "simple-bus"

[Fabio Estevam]

Commit 3c28576bb0f0 ("arm: dts: imx8qxp: fix build warining")
fixed the dts warning by removing the unnecessary 
#address-cells/#size-cells, but the recommendation for regulators is not
to place them under "simple-bus", so move the reg_usdhc2_vmmc regulator
accordingly.

Signed-off-by: Fabio Estevam 
---
 arch/arm/dts/fsl-imx8qxp-mek.dts | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/arch/arm/dts/fsl-imx8qxp-mek.dts b/arch/arm/dts/fsl-imx8qxp-mek.dts
index c14e184..adab494 100644
--- a/arch/arm/dts/fsl-imx8qxp-mek.dts
+++ b/arch/arm/dts/fsl-imx8qxp-mek.dts
@@ -16,18 +16,14 @@
stdout-path = 
};
 
-   regulators {
-   compatible = "simple-bus";
-
-   reg_usdhc2_vmmc: usdhc2-vmmc {
-   compatible = "regulator-fixed";
-   regulator-name = "SD1_SPWR";
-   regulator-min-microvolt = <300>;
-   regulator-max-microvolt = <300>;
-   gpio = < 19 GPIO_ACTIVE_HIGH>;
-   off-on-delay = <3480>;
-   enable-active-high;
-   };
+   reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
+   compatible = "regulator-fixed";
+   regulator-name = "SD1_SPWR";
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   gpio = < 19 GPIO_ACTIVE_HIGH>;
+   off-on-delay = <3480>;
+   enable-active-high;
};
 };
 
-- 
2.7.4

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

Re: [U-Boot] [PATCH] mx8mq_evk: README: Delete file introduced by mistake

[Peng Fan]

> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2018年10月26日 8:23
> To: sba...@denx.de
> Cc: u-boot@lists.denx.de; thar...@gateworks.com; Peng Fan
> ; Fabio Estevam 
> Subject: [PATCH] mx8mq_evk: README: Delete file introduced by mistake
> 
> board/freescale/mx8mq_evk/README has been introduced by mistake in
> commit d0dd73974c61 ("imx: add i.MX8QXP MEK board support")
> 
> Remove it for now as this should be introduced when mx8mq_evk support is in
> place.
> 
> Reported-by: Tim Harvey 
> Signed-off-by: Fabio Estevam 

Thanks,
Reviewed-by: Peng Fan 

> ---
>  board/freescale/mx8mq_evk/README | 81 
> 
>  1 file changed, 81 deletions(-)
>  delete mode 100644 board/freescale/mx8mq_evk/README
> 
> diff --git a/board/freescale/mx8mq_evk/README
> b/board/freescale/mx8mq_evk/README
> deleted file mode 100644
> index cd7e67e..000
> --- a/board/freescale/mx8mq_evk/README
> +++ /dev/null
> @@ -1,81 +0,0 @@
> -U-Boot for the NXP i.MX8MQ EVK board
> -
> -Quick Start
> -===
> -
> -- Build U-Boot
> -- Build the ARM Trusted firmware binary
> -- Get DDR firmware and mkimage tool
> -- Generate flash.bin using imx-mkimage
> -- Flash the binary into the SD card
> -- Boot
> -
> -Build U-Boot
> -
> -
> -$ make mx8mq_evk_defconfig
> -$ make
> -
> -Get and Build the ARM Trusted firmware
> -==
> -
> -$ git clone
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.
> codeaurora.org%2Fexternal%2Fimx%2Fimx-atfdata=02%7C01%7Cpeng.f
> an%40nxp.com%7C7b3f29a20357475a4b2108d63ad9451a%7C686ea1d3bc2b4
> c6fa92cd99c5c301635%7C0%7C0%7C636761102173985023sdata=6xDil
> qlAeAHIjR%2FDbHTzdpPLBW5fhcwWjeUGOlkjjOs%3Dreserved=0
> -$ cd imx-atf/
> -$ git checkout origin/imx_4.9.51_imx8m_beta -$ make PLAT=imx8mq bl31
> -
> -Get the DDR firmware and mkimage tool
> -==
> -
> -$ wget
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.n
> xp.com%2Flgfiles%2FNMG%2FMAD%2FYOCTO%2Ffirmware-imx-7.2.bin
> data=02%7C01%7Cpeng.fan%40nxp.com%7C7b3f29a20357475a4b2108d63ad9
> 451a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6367611021739
> 85023sdata=%2BuPPIGvFH7VoCGZL4Hw6%2B0KxuxLsH5udefKwWE%2F
> vJZc%3Dreserved=0
> -$ chmod +x firmware-imx-7.2.bin
> -$ ./firmware-imx-7.2.bin
> -
> -Download the imx-mkimage tool:
> -
> -$ git clone
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.
> codeaurora.org%2Fexternal%2Fimx%2Fimx-mkimage%2Fdata=02%7C01
> %7Cpeng.fan%40nxp.com%7C7b3f29a20357475a4b2108d63ad9451a%7C686ea
> 1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636761102173995031sd
> ata=7%2Fgnl%2B6gT5uHlzz5Xt8nCprpna%2FVjnPhw62x4yEICKE%3Drese
> rved=0
> -$ cd imx-mkimage/
> -$ git checkout origin/imx_4.9.51_imx8m_beta
> -
> -
> -Generate flash.bin using imx-mkimage
> -
> -
> -Copy the following binaries to imx-mkimage/iMX8M folder:
> -
> -$ cp imx-atf/build/imx8mq/release/bl31.bin imx-mkimage/iMX8M/ -$ cp
> u-boot/u-boot-nodtb.bin imx-mkimage/iMX8M/ -$ cp u-boot/spl/u-boot-spl.bin
> imx-mkimage/iMX8M/ -$ cp u-boot/arch/arm/dts/fsl-imx8mq-evk.dtb
> imx-mkimage/iMX8M/
> -
> -Copy the following firmwares to imx-mkimage/iMX8 folder :
> -
> -$ cp
> firmware-imx-7.2/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem.bin
> imx-mkimage/iMX8M/ -$ cp
> firmware-imx-7.2/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem.bin
> imx-mkimage/iMX8M/ -$ cp
> firmware-imx-7.2/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem.bin
> imx-mkimage/iMX8M/ -$ cp
> firmware-imx-7.2/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem.bin
> imx-mkimage/iMX8M/
> -
> -If you want to run with HDMI, copy signed_hdmi_imx8m.bin to
> imx-mkimage/iMX8M.
> -
> -Before generating the flash.bin, transfer the mkimage generated by U-Boot to
> iMX8M folder:
> -
> -$ cp u-boot/tools/mkimage imx-mkimage/iMX8M/ -$ mv
> imx-mkimage/iMX8M/mkimage imx-mkimage/iMX8M/mkimage_uboot
> -
> -$ cd imx-mkimage/
> -$ make SOC=iMX8M flash_spl_uboot
> -
> -Or for using HDMI:
> -
> -$ make SOC=iMX8M flash_hdmi_spl_uboot
> -
> -Flash the binary into the SD card
> -=
> -
> -Burn the flash.bin binary to SD card offset 33KB:
> -
> -$ sudo dd if=iMX8M/flash.bin of=/dev/sd[x] bs=1024 seek=33
> -
> -Boot
> -
> -Set Boot switch SW801: 1100 and Bmode: 10 to boot from Micro SD.
> --
> 2.7.4

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

Re: [U-Boot] [PATCH] arm: dts: imx8qxp: fix build warining

[Peng Fan]

> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2018年10月26日 8:41
> To: Peng Fan 
> Cc: Stefano Babic ; U-Boot-Denx 
> Subject: Re: [U-Boot] [PATCH] arm: dts: imx8qxp: fix build warining
> 
> Hi Peng,
> 
> On Thu, Oct 25, 2018 at 5:37 AM Peng Fan  wrote:
> >
> > Fix below build warning.
> >
> > arch/arm/dts/fsl-imx8qxp-mek.dtb: Warning (avoid_unnecessary_addr_size):
> > /regulators: unnecessary #address-cells/#size-cells without "ranges"
> > or child "reg" property
> >
> > Signed-off-by: Peng Fan 
> > ---
> >  arch/arm/dts/fsl-imx8qxp-mek.dts | 2 --
> >  1 file changed, 2 deletions(-)
> >
> > diff --git a/arch/arm/dts/fsl-imx8qxp-mek.dts
> b/arch/arm/dts/fsl-imx8qxp-mek.dts
> > index 09ea3b4a3a..c14e1845a1 100644
> > --- a/arch/arm/dts/fsl-imx8qxp-mek.dts
> > +++ b/arch/arm/dts/fsl-imx8qxp-mek.dts
> > @@ -18,8 +18,6 @@
> >
> > regulators {
> > compatible = "simple-bus";
> > -   #address-cells = <1>;
> > -   #size-cells = <0>;
> 
> The correct fix would be to move the regulators outside simple-bus.
> 
> I will send a follow up patch.

Thanks, please go ahead submit a patch fix.

Thanks,
Peng.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v6 34/34] imx: add i.MX8QXP MEK board support

[Peng Fan]

Hi Tim,

> -Original Message-
> From: Tim Harvey [mailto:thar...@gateworks.com]
> Sent: 2018年10月26日 5:10
> To: Anatolij Gustschin ; Peng Fan 
> Cc: u-boot ; Stefano Babic ; Fabio
> Estevam 
> Subject: Re: [U-Boot] [PATCH v6 34/34] imx: add i.MX8QXP MEK board support
> 
> On Thu, Oct 18, 2018 at 5:52 AM Anatolij Gustschin  wrote:
> >
> > From: Peng Fan 
> >
> > Add i.MX8QXP MEK board support
> > Enabled pinctrl/clk/power-domain/mmc/i2c/fec driver.
> > Added README file.
> >
> > Signed-off-by: Peng Fan 
> > Reviewed-by: Anatolij Gustschin 
> > Cc: Stefano Babic 
> > Cc: Fabio Estevam 
> > ---
> >  arch/arm/dts/Makefile |   2 +
> >  arch/arm/dts/fsl-imx8qxp-mek.dts  | 246
> ++
> >  arch/arm/mach-imx/imx8/Kconfig|  13 ++
> >  board/freescale/imx8qxp_mek/Kconfig   |  14 ++
> >  board/freescale/imx8qxp_mek/MAINTAINERS   |   6 +
> >  board/freescale/imx8qxp_mek/Makefile  |   7 +
> >  board/freescale/imx8qxp_mek/README|  72 +++
> >  board/freescale/imx8qxp_mek/imx8qxp_mek.c | 170 +++
> >  board/freescale/mx8mq_evk/README  |  81 +++
> 
> Peng,
> 
> Was the inclusion of the mx8mq_evk/README a mistake as this patch was
> centered around adding support for the i.MX8QXP MEK board?

That file was added by mistaken. 

> 
> I'm interested in building mainline U-Boot for the NXP i.MX 8M Quad Evaluation
> Kit (IMX8MQUADEVKQSG) which I assume is what the mx8mq_evk is for. Do you
> have plans to submit the rest of what's required for this board
> (configs/mx8mq_evk_defconfig, board/freescale/mx8mq_evk/*,
> arch/arm/dts/fsl-imx8mq-evk.dts).
> 
> It looks like inclusion of imx8mq-evk was was in a patch series early this 
> year and
> got stalled for some reason?

The ddr script is not good enough for upstream. I have asked help internal to 
restructure the code,
but seems I have to be the guy working on this again.

My current plan is the board support including ddr and mkimage could be ready 
in next RC1.

Thanks,
Peng.

> 
> Regards,
> 
> Tim
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] i6300esb watchdog

[Jaap Crezee]

Hi all,


Anybody has experience here with the i6300esb watchdog and u-boot (running 
under qemu-system-arm -M virt)? U-boot has no driver support for it (yet)
and I couldn't get it armed yet using simple pci write commands from the u-boot 
command line.

If someone has more information I am interested in hearing from you,


regards,

Jaap Crezee

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

Re: [U-Boot] [PATCH] arm: dts: imx8qxp: fix build warining

[Fabio Estevam]

Hi Peng,

On Thu, Oct 25, 2018 at 5:37 AM Peng Fan  wrote:
>
> Fix below build warning.
>
> arch/arm/dts/fsl-imx8qxp-mek.dtb: Warning (avoid_unnecessary_addr_size):
> /regulators: unnecessary #address-cells/#size-cells without "ranges"
> or child "reg" property
>
> Signed-off-by: Peng Fan 
> ---
>  arch/arm/dts/fsl-imx8qxp-mek.dts | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm/dts/fsl-imx8qxp-mek.dts 
> b/arch/arm/dts/fsl-imx8qxp-mek.dts
> index 09ea3b4a3a..c14e1845a1 100644
> --- a/arch/arm/dts/fsl-imx8qxp-mek.dts
> +++ b/arch/arm/dts/fsl-imx8qxp-mek.dts
> @@ -18,8 +18,6 @@
>
> regulators {
> compatible = "simple-bus";
> -   #address-cells = <1>;
> -   #size-cells = <0>;

The correct fix would be to move the regulators outside simple-bus.

I will send a follow up patch.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Tom Rini]

On Thu, Oct 25, 2018 at 12:01:10PM +0200, Stefano Babic wrote:

> Hi Tom,
> 
> please pull from u-boot-imx (tag: u-boot-imx-20181024). It contains the
> fixes we discussed:
> 
> - fix build i.MX8 for Travis
> - fix warnings (Warp)
> - fix warning in imx8 DTS
> 
> The following changes since commit 0a60a81ba3860946551cb79aa6486aa076e357f3:
> 
>   Kconfig: sandbox: enable cmd_avb and dependencies (2018-10-07 13:34:19
> -0400)
> 
> are available in the Git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git tags/u-boot-imx-20181025
> 
> for you to fetch changes up to 3c28576bb0f0990d699fd330089412e620706941:
> 
>   arm: dts: imx8qxp: fix build warining (2018-10-25 11:48:13 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

[U-Boot] [PATCH] mx8mq_evk: README: Delete file introduced by mistake

[Fabio Estevam]

board/freescale/mx8mq_evk/README has been introduced by mistake
in commit d0dd73974c61 ("imx: add i.MX8QXP MEK board support")

Remove it for now as this should be introduced when mx8mq_evk
support is in place.

Reported-by: Tim Harvey 
Signed-off-by: Fabio Estevam 
---
 board/freescale/mx8mq_evk/README | 81 
 1 file changed, 81 deletions(-)
 delete mode 100644 board/freescale/mx8mq_evk/README

diff --git a/board/freescale/mx8mq_evk/README b/board/freescale/mx8mq_evk/README
deleted file mode 100644
index cd7e67e..000
--- a/board/freescale/mx8mq_evk/README
+++ /dev/null
@@ -1,81 +0,0 @@
-U-Boot for the NXP i.MX8MQ EVK board
-
-Quick Start
-===
-
-- Build U-Boot
-- Build the ARM Trusted firmware binary
-- Get DDR firmware and mkimage tool
-- Generate flash.bin using imx-mkimage
-- Flash the binary into the SD card
-- Boot
-
-Build U-Boot
-
-
-$ make mx8mq_evk_defconfig
-$ make
-
-Get and Build the ARM Trusted firmware
-==
-
-$ git clone https://source.codeaurora.org/external/imx/imx-atf
-$ cd imx-atf/
-$ git checkout origin/imx_4.9.51_imx8m_beta
-$ make PLAT=imx8mq bl31
-
-Get the DDR firmware and mkimage tool
-==
-
-$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-7.2.bin
-$ chmod +x firmware-imx-7.2.bin
-$ ./firmware-imx-7.2.bin
-
-Download the imx-mkimage tool:
-
-$ git clone https://source.codeaurora.org/external/imx/imx-mkimage/
-$ cd imx-mkimage/
-$ git checkout origin/imx_4.9.51_imx8m_beta
-
-
-Generate flash.bin using imx-mkimage
-
-
-Copy the following binaries to imx-mkimage/iMX8M folder:
-
-$ cp imx-atf/build/imx8mq/release/bl31.bin imx-mkimage/iMX8M/
-$ cp u-boot/u-boot-nodtb.bin imx-mkimage/iMX8M/
-$ cp u-boot/spl/u-boot-spl.bin imx-mkimage/iMX8M/
-$ cp u-boot/arch/arm/dts/fsl-imx8mq-evk.dtb imx-mkimage/iMX8M/
-
-Copy the following firmwares to imx-mkimage/iMX8 folder :
-
-$ cp firmware-imx-7.2/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem.bin 
imx-mkimage/iMX8M/
-$ cp firmware-imx-7.2/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem.bin 
imx-mkimage/iMX8M/
-$ cp firmware-imx-7.2/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem.bin 
imx-mkimage/iMX8M/
-$ cp firmware-imx-7.2/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem.bin 
imx-mkimage/iMX8M/
-
-If you want to run with HDMI, copy signed_hdmi_imx8m.bin to imx-mkimage/iMX8M.
-
-Before generating the flash.bin, transfer the mkimage generated by U-Boot to 
iMX8M folder:
-
-$ cp u-boot/tools/mkimage imx-mkimage/iMX8M/
-$ mv imx-mkimage/iMX8M/mkimage imx-mkimage/iMX8M/mkimage_uboot
-
-$ cd imx-mkimage/
-$ make SOC=iMX8M flash_spl_uboot
-
-Or for using HDMI:
-
-$ make SOC=iMX8M flash_hdmi_spl_uboot
-
-Flash the binary into the SD card
-=
-
-Burn the flash.bin binary to SD card offset 33KB:
-
-$ sudo dd if=iMX8M/flash.bin of=/dev/sd[x] bs=1024 seek=33
-
-Boot
-
-Set Boot switch SW801: 1100 and Bmode: 10 to boot from Micro SD.
-- 
2.7.4

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

Re: [U-Boot] [PATCH v6 34/34] imx: add i.MX8QXP MEK board support

[Tim Harvey]

On Thu, Oct 18, 2018 at 5:52 AM Anatolij Gustschin  wrote:
>
> From: Peng Fan 
>
> Add i.MX8QXP MEK board support
> Enabled pinctrl/clk/power-domain/mmc/i2c/fec driver.
> Added README file.
>
> Signed-off-by: Peng Fan 
> Reviewed-by: Anatolij Gustschin 
> Cc: Stefano Babic 
> Cc: Fabio Estevam 
> ---
>  arch/arm/dts/Makefile |   2 +
>  arch/arm/dts/fsl-imx8qxp-mek.dts  | 246 ++
>  arch/arm/mach-imx/imx8/Kconfig|  13 ++
>  board/freescale/imx8qxp_mek/Kconfig   |  14 ++
>  board/freescale/imx8qxp_mek/MAINTAINERS   |   6 +
>  board/freescale/imx8qxp_mek/Makefile  |   7 +
>  board/freescale/imx8qxp_mek/README|  72 +++
>  board/freescale/imx8qxp_mek/imx8qxp_mek.c | 170 +++
>  board/freescale/mx8mq_evk/README  |  81 +++

Peng,

Was the inclusion of the mx8mq_evk/README a mistake as this patch was
centered around adding support for the i.MX8QXP MEK board?

I'm interested in building mainline U-Boot for the NXP i.MX 8M Quad
Evaluation Kit (IMX8MQUADEVKQSG) which I assume is what the mx8mq_evk
is for. Do you have plans to submit the rest of what's required for
this board (configs/mx8mq_evk_defconfig, board/freescale/mx8mq_evk/*,
arch/arm/dts/fsl-imx8mq-evk.dts).

It looks like inclusion of imx8mq-evk was was in a patch series early
this year and got stalled for some reason?

Regards,

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

Re: [U-Boot] [PATCH v2] net: e1000: support 'write_hwaddr' in DM

[Hannes Schmelzer]

On 10/25/2018 08:41 PM, Joe Hershberger wrote:

On Thu, Oct 25, 2018 at 9:26 AM Hannes Schmelzer
 wrote:

Hi Joe,



+* reading the current address failed
+*/
+   if (!ret_val && memcmp(current_mac, mac, 6) == 0)
+   return 0;
+
+   for (i = 0; i < 3; ++i)
+   data[i] = mac[i * 2 + 1] << 8 | mac[i * 2];
+
+   ret_val = e1000_write_eeprom_srwr(hw, 0x0, 3, data);

This is a pretty uncommon implementation of this driver operation.
Does the i120 in this case read the MAC directly from the EEPROM?

Usually this function is used to write the hwaddr into the registers
of the MAC. The .read_rom_hwaddr is used to fetch the hwaddr from the
EEPROM and that address is used in the case that the U-Boot env has
not set one.
This implementation is not new, just moved a bit upward in the file to 
avoid forward declaration for non-DM build.
I will double check it, but i guess there will be no change until we've 
no fail behavior of the existing code.


I didn't imagine that this little change would become so big ;-)
I will provide some v3 within next days with the cosmetic cleanup and 
other requested changes.


cheers,
Hannes


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

Re: [U-Boot] [PATCH v2] net: e1000: support 'write_hwaddr' in DM

[Joe Hershberger]

On Thu, Oct 25, 2018 at 9:26 AM Hannes Schmelzer
 wrote:
>
> This commit ports the existing (non-DM) function for writing the MAC-
> address into the shadow ram (and flash) for DM.
>
> Signed-off-by: Hannes Schmelzer 
> ---
>
> Changes in v2:
> - fix build for non-DM board
> - rebase on current master
>
>  drivers/net/e1000.c | 89 
> +
>  1 file changed, 48 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
> index a34f697..3df 100644
> --- a/drivers/net/e1000.c
> +++ b/drivers/net/e1000.c
> @@ -862,7 +862,6 @@ e1000_read_eeprom(struct e1000_hw *hw, uint16_t offset,
> return E1000_SUCCESS;
>  }
>
> -#ifndef CONFIG_DM_ETH
>  
> /**
>   *  e1000_write_eeprom_srwr - Write to Shadow Ram using EEWR
>   *  @hw: pointer to the HW structure
> @@ -1028,7 +1027,6 @@ static int32_t e1000_update_eeprom_checksum_i210(struct 
> e1000_hw *hw)
>  out:
> return ret_val;
>  }
> -#endif
>
>  
> /**
>   * Verifies that the EEPROM has a valid checksum
> @@ -5488,6 +5486,53 @@ void e1000_get_bus_type(struct e1000_hw *hw)
>  }
>
>  #ifndef CONFIG_DM_ETH

Please don't use negative logic when an else is present. Switch the
cases and use #ifdef.

> +static int e1000_write_hwaddr(struct eth_device *dev)
> +#else
> +static int e1000_write_hwaddr(struct udevice *dev)
> +#endif
> +{
> +#ifndef CONFIG_E1000_NO_NVM

Same here

> +#ifndef CONFIG_DM_ETH

Same here

> +   unsigned char *mac = dev->enetaddr;
> +   struct e1000_hw *hw = dev->priv;
> +#else
> +   struct eth_pdata *plat = dev_get_platdata(dev);
> +   unsigned char *mac = plat->enetaddr;
> +   struct e1000_hw *hw = dev_get_priv(dev);
> +#endif
> +   unsigned char current_mac[6];
> +   u16 data[3];
> +   int ret_val, i;
> +
> +   DEBUGOUT("%s: mac=%pM\n", __func__, mac);
> +
> +   memset(current_mac, 0, 6);
> +
> +   /* Read from EEPROM, not from registers, to make sure

Please use a /* on a blank line for multi-line comments.

> +* the address is persistently configured
> +*/
> +   ret_val = e1000_read_mac_addr_from_eeprom(hw, current_mac);
> +   DEBUGOUT("%s: current mac=%pM\n", __func__, current_mac);
> +
> +   /* Only write to EEPROM if the given address is different or

Please use a /* on a blank line for multi-line comments.

> +* reading the current address failed
> +*/
> +   if (!ret_val && memcmp(current_mac, mac, 6) == 0)
> +   return 0;
> +
> +   for (i = 0; i < 3; ++i)
> +   data[i] = mac[i * 2 + 1] << 8 | mac[i * 2];
> +
> +   ret_val = e1000_write_eeprom_srwr(hw, 0x0, 3, data);

This is a pretty uncommon implementation of this driver operation.
Does the i120 in this case read the MAC directly from the EEPROM?

Usually this function is used to write the hwaddr into the registers
of the MAC. The .read_rom_hwaddr is used to fetch the hwaddr from the
EEPROM and that address is used in the case that the U-Boot env has
not set one.

> +   if (!ret_val)
> +   ret_val = e1000_update_eeprom_checksum_i210(hw);
> +   return ret_val;
> +#else  /* CONFIG_E1000_NO_NVM */
> +   return 0;
> +#endif
> +}
> +
> +#ifndef CONFIG_DM_ETH
>  /* A list of all registered e1000 devices */
>  static LIST_HEAD(e1000_hw_list);
>  #endif
> @@ -5649,45 +5694,6 @@ e1000_poll(struct eth_device *nic)
> return len ? 1 : 0;
>  }
>
> -static int e1000_write_hwaddr(struct eth_device *dev)
> -{
> -#ifndef CONFIG_E1000_NO_NVM
> -   unsigned char *mac = dev->enetaddr;
> -   unsigned char current_mac[6];
> -   struct e1000_hw *hw = dev->priv;
> -   uint16_t data[3];
> -   int ret_val, i;
> -
> -   DEBUGOUT("%s: mac=%pM\n", __func__, mac);
> -
> -   memset(current_mac, 0, 6);
> -
> -   /* Read from EEPROM, not from registers, to make sure
> -* the address is persistently configured
> -*/
> -   ret_val = e1000_read_mac_addr_from_eeprom(hw, current_mac);
> -   DEBUGOUT("%s: current mac=%pM\n", __func__, current_mac);
> -
> -   /* Only write to EEPROM if the given address is different or
> -* reading the current address failed
> -*/
> -   if (!ret_val && memcmp(current_mac, mac, 6) == 0)
> -   return 0;
> -
> -   for (i = 0; i < 3; ++i)
> -   data[i] = mac[i * 2 + 1] << 8 | mac[i * 2];
> -
> -   ret_val = e1000_write_eeprom_srwr(hw, 0x0, 3, data);
> -
> -   if (!ret_val)
> -   ret_val = e1000_update_eeprom_checksum_i210(hw);
> -
> -   return ret_val;
> -#else
> -   return 0;
> -#endif
> -}
> -
>  /**
>  PROBE - Look for an adapter, this routine's visible to the outside
>  You should omit the 

Re: [U-Boot] [PATCH] x86: Fix car_uninit weak symbol definition

[Hannes Schmelzer]

On 10/25/18 12:05 PM, Bin Meng wrote:

Since commit 80df194f0165 ("x86: detect unsupported relocation types"),
an error message is seen on QEMU x86 target during boot:

do_elf_reloc_fixups32: unsupported relocation type 0x1 at fff841f0, offset = 
0xfff00087
do_elf_reloc_fixups32: unsupported relocation type 0x2 at fff841f8, offset = 
0xfff00091

Check offset 0xfff00087 and 0xfff00091 in the u-boot ELF image,

fff00087  000df401 R_386_32     car_uninit
fff00091  000df402 R_386_PC32   car_uninit

we see R_386_32 and R_386_PC32 relocation type is generated for
symbol car_uninit, which is declared as a weak symbol in start.S.

However the actual weak symbol implementation ends up nowhere. As
we can see below, it's *UND*.

$ objdump -t u-boot | grep car_uninit
  w  *UND*   car_uninit

With this fix, it is normal now.


My pp065 board is also working fine with this.

Tested-by: Hannes Schmelzer 

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

[U-Boot] [PATCH v2] ARM: mvebu: dts: add Clearfog GT-8K

[Baruch Siach]

From: Rabeeh Khoury 

The SolidRun Clearfog GT-8K is based on Armada 8040.

https://wiki.solid-run.com/doku.php?id=products:a8040:clearfoggt8k

The config file is identical to the Macchiatobin one
(mvebu_mcbin-88f8040_defconfig) with only the default device-tree
changed.

Signed-off-by: Rabeeh Khoury 
Signed-off-by: Baruch Siach 
---
v2:
  * Change top board compatible string to match the kernel one
  * Add "spi-flash" compatible string (Chris Packham)
  * Add defconfig file (Stefan Roese)
---
 arch/arm/dts/Makefile   |   1 +
 arch/arm/dts/armada-8040-clearfog-gt-8k.dts | 315 
 configs/clearfog_gt_8k_defconfig|  75 +
 3 files changed, 391 insertions(+)
 create mode 100644 arch/arm/dts/armada-8040-clearfog-gt-8k.dts
 create mode 100644 configs/clearfog_gt_8k_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 44ebc50bfab1..c9a23ea68450 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -99,6 +99,7 @@ dtb-$(CONFIG_ARCH_MVEBU) +=   \
armada-7040-db-nand.dtb \
armada-8040-db.dtb  \
armada-8040-mcbin.dtb   \
+   armada-8040-clearfog-gt-8k.dtb  \
armada-xp-gp.dtb\
armada-xp-maxbcm.dtb\
armada-xp-synology-ds414.dtb\
diff --git a/arch/arm/dts/armada-8040-clearfog-gt-8k.dts 
b/arch/arm/dts/armada-8040-clearfog-gt-8k.dts
new file mode 100644
index ..498105f25f05
--- /dev/null
+++ b/arch/arm/dts/armada-8040-clearfog-gt-8k.dts
@@ -0,0 +1,315 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 SolidRun ltd
+ */
+
+#include "armada-8040.dtsi"
+
+/ {
+   model = "ClearFog-GT-8K";
+   compatible = "solidrun,clearfog-gt-8k",
+"marvell,armada8040";
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   aliases {
+   i2c0 = _i2c0;
+   i2c1 = _i2c1;
+   spi0 = _spi1;
+   };
+
+   memory@ {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x8000>;
+   };
+
+   simple-bus {
+   compatible = "simple-bus";
+
+   reg_usb3h0_vbus: usb3-vbus0 {
+   compatible = "regulator-fixed";
+   pinctrl-names = "default";
+   pinctrl-0 = <_xhci_vbus_pins>;
+   regulator-name = "reg-usb3h0-vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   startup-delay-us = <30>;
+   shutdown-delay-us = <50>;
+   regulator-force-boot-off;
+   gpio = <_gpio1 15 GPIO_ACTIVE_LOW>; /* GPIO[47] */
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+_pinctl {
+   /*
+* MPP Bus:
+* eMMC [0-10]
+* UART0 [11,19]
+*/
+ /* 0 1 2 3 4 5 6 7 8 9 */
+   pin-func = < 1 1 1 1 1 1 1 1 1 1
+1 3 0 0 0 0 0 0 0 3 >;
+};
+
+/* on-board eMMC */
+_sdhci0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_emmc_pins>;
+   bus-width = <8>;
+   status = "okay";
+};
+
+_pinctl {
+   /*
+* MPP Bus:
+* [0-31] = 0xff: Keep default CP0_shared_pins:
+* [11] CLKOUT_MPP_11 (out)
+* [23] LINK_RD_IN_CP2CP (in)
+* [25] CLKOUT_MPP_25 (out)
+* [29] AVS_FB_IN_CP2CP (in)
+* [32, 33, 34] pci0/1/2 reset
+* [35-38] CP0 I2C1 and I2C0
+* [39] GPIO reset button
+* [40,41] LED0 and LED1
+* [43] 1512 phy reset
+* [47] USB VBUS EN (active low)
+* [48] FAN PWM
+* [49] SFP+ present signal
+* [50] TPM interrupt
+* [51] WLAN0 disable
+* [52] WLAN1 disable
+* [53] LTE disable
+* [54] NFC reset
+* [55] Micro SD card detect
+* [56-61] Micro SD
+*/
+   /*   0123456789 */
+   pin-func = < 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
+0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
+0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
+0xff 000022220
+0000000000
+0000000xe  0xe  0xe  0xe
+0xe  0xe  0 >;
+
+   cpm_xhci_vbus_pins: cpm-xhci-vbus-pins {
+   marvell,pins = < 47 >;
+   marvell,function = <0>;
+   };
+
+   cps_1g_phy_reset: cps-1g-phy-reset {
+   marvell,pins = < 43 >;
+   marvell,function = <0>;
+   };
+};
+
+/* uSD slot */
+_sdhci0 {
+   pinctrl-names = "default";
+   

Re: [U-Boot] [PATCH] x86: Fix car_uninit weak symbol definition

[Heinrich Schuchardt]

On 10/25/2018 12:05 PM, Bin Meng wrote:
> Since commit 80df194f0165 ("x86: detect unsupported relocation types"),
> an error message is seen on QEMU x86 target during boot:
> 
> do_elf_reloc_fixups32: unsupported relocation type 0x1 at fff841f0, offset = 
> 0xfff00087
> do_elf_reloc_fixups32: unsupported relocation type 0x2 at fff841f8, offset = 
> 0xfff00091
> 
> Check offset 0xfff00087 and 0xfff00091 in the u-boot ELF image,
> 
> fff00087  000df401 R_386_32     car_uninit
> fff00091  000df402 R_386_PC32   car_uninit
> 
> we see R_386_32 and R_386_PC32 relocation type is generated for
> symbol car_uninit, which is declared as a weak symbol in start.S.
> 
> However the actual weak symbol implementation ends up nowhere. As
> we can see below, it's *UND*.
> 
> $ objdump -t u-boot | grep car_uninit
>   w  *UND*   car_uninit
> 
> With this fix, it is normal now.
> 
> $ objdump -t u-boot | grep car_uninit
> fff00094  wF .text.start0001 car_uninit
> 
> Reported-by: Hannes Schmelzer 
> Signed-off-by: Bin Meng 
> ---

qemu-x86_defconfig works fine now.

Tested-by: Heinrich Schuchardt 
Reviewed-by: Heinrich Schuchardt 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3] sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)

[York Sun]

On 10/25/18 08:59, Stefan Roese wrote:
> Hi York,
> 
> On 25.10.18 17:49, York Sun wrote:
>> Guys,
>>
>> Let get back to the original thread. Since Rajat's first reply, the
>> message id has been changed. All the comments were not captured by
>> patchwork.
> 
> I also wondered about this. Seems to have happened at some top-posting
> quite at the beginning of this thread.
>   

I am having trouble recently with office365. It seems breaking all my
email threads if senders use outlook.

>>
>>  From what I read, Rajat's method is to extend the controller driver to
>> support read SFDP and default to 4-byte mode if supported, or
>> overwritten by user's flag. Stefan's method is to read 4-byte status bit
>> and doesn't change controller driver.
> 
> Yes, the last sentence it correct.
> 
>> Is the default value of this 4-byte status bit valid and correct for all
>> cases?
> 
> This 4-byte address status bit implementation is SPI NOR chip
> specific (vendor specific?). With Simon's help we already support
> 2 vendors now. Extending for other vendors / chips is fairly
> easy.

Let's wait for Rajat's comment. If this method doesn't work for his
boards or his controllers, he still needs to extend controller's driver
feature.

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

Re: [U-Boot] [PATCH 29/30] dm: core: add missing prototype for ofnode_read_u64

[Auer, Lukas]

Hi Bin,

On Mon, 2018-10-22 at 17:35 +0800, Bin Meng wrote:
> Hi Lukas,
> 
> On Sat, Oct 20, 2018 at 6:11 AM Lukas Auer
>  wrote:
> > 
> > Signed-off-by: Lukas Auer 
> > ---
> > 
> >  include/dm/ofnode.h | 10 ++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
> > index 2fc9fa39a3..a7b8609cf4 100644
> > --- a/include/dm/ofnode.h
> > +++ b/include/dm/ofnode.h
> > @@ -216,6 +216,16 @@ static inline int ofnode_read_s32(ofnode node,
> > const char *propname,
> > return ofnode_read_u32(node, propname, (u32 *)out_value);
> >  }
> > 
> > +/**
> > + * ofnode_read_u64() - Read a 64-bit integer from a property
> > + *
> > + * @node:  valid node reference to read property from
> > + * @propname:  name of the property to read from
> > + * @outp:  place to put value (if found)
> > + * @return 0 if OK, -ve on error
> > + */
> > +int ofnode_read_u64(ofnode node, const char *propname, u64 *outp);
> > +
> 
> Can you please put this at the same location in ofnode.c? eg: put
> after ofnode_read_s32_default()
> 

Yes, I will fix this in v2.

Thanks,
Lukas

> >  /**
> >   * ofnode_read_u32_default() - Read a 32-bit integer from a
> > property
> >   *
> > --
> 
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3] sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)

[Stefan Roese]

Hi York,

On 25.10.18 17:49, York Sun wrote:

Guys,

Let get back to the original thread. Since Rajat's first reply, the
message id has been changed. All the comments were not captured by
patchwork.


I also wondered about this. Seems to have happened at some top-posting
quite at the beginning of this thread.
 

On 10/11/18 07:50, Stefan Roese wrote:

Some SPI NOR chips only support 4-byte mode addressing. Here the default
3-byte mode does not work and leads to incorrect accesses. This patch
now reads the 4-byte mode status bit (in this case in the CR register
of the Macronix SPI NOR) and configures the SPI transfers accordingly.

This was noticed on the LinkIt Smart 7688 modul, which is equipped with
an Macronix MX25L25635F device. But this device does *NOT* support
switching to 3-byte mode via the EX4B command.

This should also work when the bootrom configures the SPI flash to
4-byte mode and runs U-Boot after this. U-Boot should dectect this
mode (if the 4-byte mode detection is available for this chip) and
use the correct OPs in this case.


 From what I read, Rajat's method is to extend the controller driver to
support read SFDP and default to 4-byte mode if supported, or
overwritten by user's flag. Stefan's method is to read 4-byte status bit
and doesn't change controller driver.


Yes, the last sentence it correct.


Is the default value of this 4-byte status bit valid and correct for all
cases?


This 4-byte address status bit implementation is SPI NOR chip
specific (vendor specific?). With Simon's help we already support
2 vendors now. Extending for other vendors / chips is fairly
easy.

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 22/30] riscv: remove unused labels in start.S

[Auer, Lukas]

Hi Rick,

On Thu, 2018-10-25 at 09:16 +0800, Rick Chen wrote:
> Auer, Lukas  於 2018年10月24日 週三
> 下午10:14寫道：
> > 
> > Hi Rick,
> > 
> > On Wed, 2018-10-24 at 13:47 +0800, Rick Chen wrote:
> > > Rick Chen  於 2018年10月24日 週三 下午1:20寫道：
> > > > 
> > > > Bin Meng  於 2018年10月24日 週三 上午11:34寫道：
> > > > > 
> > > > > Hi Rich,
> > > > > 
> > > > > On Wed, Oct 24, 2018 at 10:37 AM Rick Chen <
> > > > > rickche...@gmail.com>
> > > > > wrote:
> > > > > > 
> > > > > > > > > The labels nmi_vector, trap_vector and handle_reset
> > > > > > > > > in
> > > > > > > > > start.S are not
> > > > > > > > > used for RISC-V. Remove them.
> > > > > > > > > 
> > > > > > 
> > > > > > Hi Lukas
> > > > > > 
> > > > > > Agree with the above part.
> > > > > > 
> > > > > > > > > While we are here, also remove the code from the
> > > > > > > > > beginning of start.S,
> > > > > > > > > which stores the contents of a2 to memory. Only
> > > > > > > > > registers
> > > > > > > > > a0 and a1
> > > > > > > > > contain information from the previous boot stage.
> > > > > > > > > There
> > > > > > > > > is therefore
> > > > > > > > > no reason for saving a2.
> > > > > > 
> > > > > > NOT agree with this part.
> > > > > > Saving a2 is trying to support dynamically dtb pass at
> > > > > > runtime.
> > > > > > 
> > > > > 
> > > > > Could you please describe in more details on what the use
> > > > > case is
> > > > > here?
> > > > > 
> > > > 
> > > > Hi Bin and Lukas
> > > > 
> > > > After I study [PATCH 24/30] riscv: save hart ID and device tree
> > > > passed
> > > > by prior boot stage.
> > > > I found it is the same thing.
> > > > I will accepted this patch.
> > > > So this patch is
> > > > 
> > > > Reviewed-by: Rick Chen 
> > > > 
> > > > But I shall send a patch to fix ax25-ae350 to work as well
> > > > later.
> > > > And it will be as below :
> > > > 
> > > > ax5-ae350.c
> > > > void *board_fdt_blob_setup(void)
> > > > {
> > > > void **ptr = (void *)_stage_fdt_address;
> > > > if (fdt_magic(*ptr) == FDT_MAGIC)
> > > > return (void *)*ptr;
> > > > 
> > > > return (void *)CONFIG_SYS_FDT_BASE;
> > > > }
> > > > 
> > > 
> > > Sorry!
> > > 
> > > I shall send a fixed patch as below:
> > > riscv: ax25-ae350: use device tree passed by prior boot stage
> > > 
> > > --- a/configs/ax25-ae350_defconfig
> > > +++ b/configs/ax25-ae350_defconfig
> > > @@ -15,7 +15,7 @@ CONFIG_CMD_SF_TEST=y
> > >  # CONFIG_CMD_SETEXPR is not set
> > >  CONFIG_BOOTP_PREFER_SERVERIP=y
> > >  CONFIG_CMD_CACHE=y
> > > -CONFIG_OF_BOARD=y
> > > +CONFIG_OF_PRIOR_STAGE=y
> > > 
> > > +++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > @@ -64,15 +64,6 @@ ulong board_flash_get_legacy(ulong base, int
> > > banknum, flash_info_t *info)
> > > return 0;
> > >  }
> > > 
> > > -void *board_fdt_blob_setup(void)
> > > -{
> > > -   void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > -   if (fdt_magic(*ptr) == FDT_MAGIC)
> > > -   return (void *)*ptr;
> > > -
> > > -   return (void *)CONFIG_SYS_FDT_BASE;
> > > -}
> > > -
> > > 
> > > Rick
> > > 
> > 
> > Sorry, I have missed your commit. Just to clarify, does the ax25
> > pass
> > the device tree in a2 instead of a1? In that case, my patch must be
> > changed since it assumes the device tree to be in a1.
> > Related to this, can I assume that a0 stores the hart ID?
> > 
> > If you want, I can add this patch to my series.
> > 
> 
> Hi Lukas
> 
> Your patch is correct.
> I will send out a patch to fix the mismatch in ax25-ae350 later.
> And maybe you can put this patch into your v2 series.
> 
> Thanks
> 
> Rick
> 

Ok. Yes, I will pick up your patch in my v2.

Thanks,
Lukas

> > Thanks,
> > Lukas
> > 
> > > > 
> > > > > > You can see it in the following commit :
> > > > > > 
> > > > > > commit d58717e42559189a226ea800173147399c8edef9
> > > > > > Author: Rick Chen 
> > > > > > Date:   Thu Mar 29 10:08:33 2018 +0800
> > > > > > 
> > > > > > riscv: ae250: Support DT provided by the board at
> > > > > > runtime
> > > > > > 
> > > > > 
> > > > > Regards,
> > > > > Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 18/27] drivers: qe: add TFABOOT support

[York Sun]

On 10/25/18 01:34, Rajesh Bhagat wrote:
> 
> 
>> -Original Message-
>> From: York Sun
>> Sent: Monday, October 22, 2018 9:55 PM
>> To: Rajesh Bhagat ; u-boot@lists.denx.de
>> Cc: Prabhakar Kushwaha ; Pankit Garg
>> 
>> Subject: Re: [PATCH v4 18/27] drivers: qe: add TFABOOT support
>>
>> On 10/12/18 07:45, Rajesh Bhagat wrote:
>>> Adds TFABOOT support and allows to pick QE firmware on basis of boot
>>> source.
>>>
>>> Signed-off-by: Pankit Garg 
>>> Signed-off-by: Rajesh Bhagat 
>>> ---
>>> Change in v4: None
>>>
>>> Change in v3: None
>>>
>>> Change in v2:
>>>  - Removed extra CONFIG_TFABOOT flag usage
>>>
>>>  drivers/qe/qe.c | 81
>>> +
>>>  1 file changed, 81 insertions(+)
>>>
>>> diff --git a/drivers/qe/qe.c b/drivers/qe/qe.c index
>>> 7010bbc230..daefb5aa07 100644
>>> --- a/drivers/qe/qe.c
>>> +++ b/drivers/qe/qe.c
>>> @@ -17,9 +17,17 @@
>>>  #include 
>>>  #endif
>>>
>>> +#ifdef CONFIG_TFABOOT
>>> +#include 
>>> +/* required to include IFC and QSPI base address */ #include
>>> + #include  #include
>> 
>>> +#else
>>>  #ifdef CONFIG_SYS_QE_FMAN_FW_IN_MMC
>>>  #include 
>>>  #endif
>>> +#endif
>>>
>>
>>
>> Would there be any conflict if you drop the #ifdef here? No need to respin 
>> the
>> patch set for this change. I can fix it for you if you confirm.
>>
> 
> AFAIR, there was some conflict. Shall I check it again. 

Please check.

York

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

Re: [U-Boot] [PATCH v3] sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)

[York Sun]

Guys,

Let get back to the original thread. Since Rajat's first reply, the
message id has been changed. All the comments were not captured by
patchwork.

On 10/11/18 07:50, Stefan Roese wrote:
> Some SPI NOR chips only support 4-byte mode addressing. Here the default
> 3-byte mode does not work and leads to incorrect accesses. This patch
> now reads the 4-byte mode status bit (in this case in the CR register
> of the Macronix SPI NOR) and configures the SPI transfers accordingly.
> 
> This was noticed on the LinkIt Smart 7688 modul, which is equipped with
> an Macronix MX25L25635F device. But this device does *NOT* support
> switching to 3-byte mode via the EX4B command.
> 
> This should also work when the bootrom configures the SPI flash to
> 4-byte mode and runs U-Boot after this. U-Boot should dectect this
> mode (if the 4-byte mode detection is available for this chip) and
> use the correct OPs in this case.

From what I read, Rajat's method is to extend the controller driver to
support read SFDP and default to 4-byte mode if supported, or
overwritten by user's flag. Stefan's method is to read 4-byte status bit
and doesn't change controller driver.

Is the default value of this 4-byte status bit valid and correct for all
cases?

Rajat, without your patch set, does Stefan's solution work for your board?

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

Re: [U-Boot] [PATCH v3] sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)

[Stefan Roese]

Hi Rajat,

On 25.10.18 11:28, Rajat Srivastava wrote:




Simply adding SPI_FLASH_USE_SFDP flag is not enough to make SFDP work.

You'll

need to add the driver code corresponding to the mtd layer code (in

spi_flash.c)

which will send the actual READ SFDP command to flash.

The patch-set I floated adds driver code in fsl_qspi.c (Freescale/NXP QSPI

driver).

Please find the patch at

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F985329data=02%7C01%7Crajat.srivastava%40nxp.com%7Cc967de2c68464c6561b508d639091e21%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636759108670133878sdata=uZfP5lWvGmpA%2Fxi5AS06c15PKqYwwndgU%2BC3zYu2K3w%3Dreserved=0.


After the mtd layer calls spi_flash_read_common() function to send any read
command to flash, it lands on driver which ultimately fires the command
(in this case 0x5A command to read SFDP) to flash.


So you say, that each SPI driver needs to get some changes to
support the SFDP reading? That does not sound like a generic
approach to me. But maybe I misunderstood this.


To read SFDP parameters, a READ_SFDP command (0x5A) needs to be
sent to flash which can be sent only with help of a SPI driver.
Even if one wants to initiate a simple basic 1-byte read operation,
there must exist a SPI driver that actually sends the read command
to flash.


But does this READ SFDP stuff need to be handled in each and every
SPI driver (platform specific)? Can't this be moved to a common
location in the SPI flash framework so that the platform specific
drivers don't need to be changed here?
 

I think this is a generic approach because that is how mtd
framework is designed.




Since you say the flash is designed to support only 4-byte addressing mode


No. The flash itself (as you have seen in the datasheet) supports
both. But the special chip version equipped on the LinkIt MT7688
boards is somehow strapped to only support 4-byte mode. This is
not documented anywhere (and did cost me quite some time to figure
it out).


Ok I get it. I think this flash does not follow standard SFDP
framework. Can you please confirm?


This specific flash chip most likely not. But I'm not 100% sure,
as I've never tried to use it this way yet.
 



then it is possible that the READ_SFDP command (0x5A) is also required to be
sent in 4-byte mode (My patch sends 0x5A in 3-byte addressing mode which
is also the SFDP standard that every other flash supports).
Although I looked up the datasheet of mx25l25635f and it says that the
READ_SFDP command will be sent in 3-byte mode (as supported by my patch).



SF: Detected mx25l25635f with page size 0 Bytes, erase size 64 KiB, total 0

Bytes

*** Warning - bad CRC, using default environment

Please note that I'm not opposed to using your SFDP support. But
in our case it does not work - at least not without the
SPI_FLASH_USE_SFDP addition. And it needs some fixing as well to
fully detect the chip parameters. So I would prefer to go ahead
with my patch for now.


My point is that if your case can be handled by adding a generic code,
instead of flash specific code then we should prefer the generic approach,

what

do you say?


Please see above, my questions about SPI driver additions for this
SFDP support. This does not sound very "generic" to me.


As mentioned above, this is the generic approach and this is how
Linux has also implemented SFDP. By design, the SPI driver should
adapt to changes in mtd framework.


Again my question from above, if this SFDP read needs to be
added to all SPI device drivers, or if this can be handled
in a common place?
 


But I think both solutions, your SFDP support and my "simple"
pre-configured 3-byte vs 4-byte addressing mode detection and
usage can co-exist.


Ok.
Let us wait for the SPI maintainer to comment on this since for
both solutions to co-exist we may have to resolve code conflicts.


Sure. Resolving such potential merge conflicts should not be too
hard though.

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 21/30] riscv: remove CONFIG_INIT_CRITICAL

[Auer, Lukas]

Hi Bin,

On Thu, 2018-10-25 at 10:57 +0800, Bin Meng wrote:
> Hi Lukas,
> 
> On Mon, Oct 22, 2018 at 5:19 PM Bin Meng  wrote:
> > 
> > Hi Lukas,
> > 
> > On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
> >  wrote:
> > > 
> > > CONFIG_INIT_CRITICAL is deprecated and not used for RISC-V.
> > > Remove it.
> > > 
> > > Signed-off-by: Lukas Auer 
> > > ---
> > > 
> > >  arch/riscv/cpu/start.S | 11 ---
> > >  1 file changed, 11 deletions(-)
> > > 
> > 
> > Please see my patch which does more :)
> > 
> > 
http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commitdiff;h=1f1c216d426a6c2196f8c39f5a2d85fe35096102
> 
> You can take my patch above in your v2 if you want.
> 
> Regards,
> Bin

That looks very good! Yes, I'll replace this patch with yours in v2.

Thanks,
Lukas
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [BUG] efi-x86_app_defconfig does not build with gcc 8.2

[Bin Meng]

Hi Andy,

On Thu, Oct 11, 2018 at 5:36 PM Andy Shevchenko
 wrote:
>
> On Tue, Oct 09, 2018 at 07:28:36AM +0800, Bin Meng wrote:
> > Hi Andy,
> >
> > On Tue, Oct 9, 2018 at 12:31 AM Andy Shevchenko
> >  wrote:
> > >
> > > On Mon, Oct 08, 2018 at 11:31:32PM +0800, Bin Meng wrote:
> > > > +Andy
> > > >
> > > > On Sat, Sep 8, 2018 at 5:00 PM Heinrich Schuchardt  
> > > > wrote:
> > > > >
> > > > > make mrproper && make efi-x86_app_defconfig && make
> > > > >
> > > > > results in
> > > > >
> > > > >   CC  common/image.o
> > > > > {standard input}: Assembler messages:
> > > > > {standard input}:21662: Error: junk at end of line, first unrecognized
> > > > > character is `@'
> > > > > {standard input}:21707: Error: junk at end of line, first unrecognized
> > > > > character is `@'
> > > > > {standard input}:21662: Error: can't resolve `end.6878'
> > > > > {.u_boot_list_2_fit_loadable_3 section} - `start.6875'
> > > > > {.u_boot_list_2_fit_loadable_1 section}
> > > > > {standard input}:21707: Error: can't resolve `end.6878'
> > > > > {.u_boot_list_2_fit_loadable_3 section} - `start.6875'
> > > > > {.u_boot_list_2_fit_loadable_1 section}
> > > > >
> > > > > I am using Debian Buster with gcc-8.2.0.
> > > > >
> > > > > Building with gcc-7.3.0 works fine.
> > > > >
> > > > > We had a similar issue for qemu-x86_defconfig in
> > > > > https://lists.denx.de/pipermail/u-boot/2018-July/336393.html
> > > > > which has been resolved.
> > > >
> > > > I can reproduce this with kernel.org GCC 8.1.0 toolchain now. But I
> > > > have no idea how this error is related to anything. Andy may have some
> > > > idea.
> > >
> > > Does below fixes the issue (check also if the resulting binary runs)?
> > >
> > > --- a/arch/x86/config.mk
> > > +++ b/arch/x86/config.mk
> > > @@ -41,7 +41,7 @@ OBJCOPYFLAGS_EFI := -j .text -j .sdata -j .data -j 
> > > .dynamic -j .dynsym \
> > >  ifeq ($(IS_32BIT),y)
> > >  CFLAGS_NON_EFI := -mregparm=3
> > >  endif
> > > -CFLAGS_EFI := -fpic -fshort-wchar
> > > +CFLAGS_EFI := -fshort-wchar
> > >
> >
> > Thanks for checking. I tried this but the resulted binary does not
> > boot. Hangs at "U-Boot EFI " and no console output anymore.
>
> That's what I was suspecting after looking how EFI applications are being 
> built.
>
> So, someone familiar with compilers probably needs to check the following and 
> act accordingly:
> - either new compiler provides new switches to change behaviour as it was in 
> GCC < 8, or
> - create a small verifiable example with this linked list sections and submit 
> a bug report to GCC, or
> - U-Boot code (for linked lists) should be reconsidered from new requirements 
> of the compiler, or
> - EFI U-Boot application should have it's own relocation code (like normal 
> U-Boot does), or
> - ...anything I missed...
>
> The issue from my limited knowledge looks like this:
> EFI loader relies on the sections that are natural for dynamically linked
> libraries (AKA .so), while U-Boot (when runs on bare metal) has another
> approach, i.e. specific code that does a relocation based only on .reloc
> information. The linked list sections in U-Boot are meant to be statically
> compiled, which is not the case for EFI by some reason.
>
> OTOH, it's clearly a compiler behaviour change, since with -fPIC -g it
> generates DWARF that can't be translated by its own assembler!
> (See option 2 in above list)
>

Thank you for these useful suggestions! I will see if I can create a
small test program to trigger this issue.

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

[U-Boot] [PATCH] cmd: remove CONFIG_SOURCE support in Makefile

[Patrick Delaunay]

This line is no more needed and can be removed.

Only CONFIG_CMD_SOURCE is defined in Kconfig and
used in defconfig files.

CONFIG_SOURCE if not defined in source code and
"config SOURCE" is not present in any Kconfig.

Signed-off-by: Patrick Delaunay 
---

 cmd/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/cmd/Makefile b/cmd/Makefile
index d9cdaf6..ac4830a 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -15,7 +15,6 @@ obj-$(CONFIG_CMD_AES) += aes.o
 obj-$(CONFIG_CMD_ADC) += adc.o
 obj-$(CONFIG_CMD_ARMFLASH) += armflash.o
 obj-y += blk_common.o
-obj-$(CONFIG_SOURCE) += source.o
 obj-$(CONFIG_CMD_SOURCE) += source.o
 obj-$(CONFIG_CMD_BDI) += bdinfo.o
 obj-$(CONFIG_CMD_BEDBUG) += bedbug.o
-- 
2.7.4

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

Re: [U-Boot] [PATCH V2] imx: mkimage: avoid stop CI when required files not exists

[Anatolij Gustschin]

On Thu, 25 Oct 2018 08:32:40 +
Peng Fan peng@nxp.com wrote:
...
> diff --git a/tools/imx_cntr_image.sh b/tools/imx_cntr_image.sh
> new file mode 100755
> index 00..4c629e8694
> --- /dev/null
> +++ b/tools/imx_cntr_image.sh
> @@ -0,0 +1,29 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# script to check whether the file exists in imximage.cfg for i.MX8
> +#
> +# usage: $0 
> +
> +file=$1
> +
> +blobs=`awk '/^APPEND/ {print $2} /^IMAGE/ || /^DATA/ {print $3}' $file`

If we want to skip checking for u-boot-dtb.bin, then better drop
DATA pattern matching. This should be okay since we have only one
DATA field and it is for u-boot-dtb.bin.

Please use blobs=`awk '/^APPEND/ {print $2} /^IMAGE/ {print $3}'`

> +for f in $blobs; do
> + tmp=$srctree/$f
> + if [ $f == "u-boot-dtb.bin" ]; then
> + continue
> + fi

and drop the above string check.

> +
> + if [ -f $f ]; then
> + continue
> + fi
> +
> + if [ ! -f $tmp ]; then
> + echo "WARNING '$tmp' not found, resulting binary is 
> not-functional" >&2
> + exit 1
> + fi
> +
> + sed -in "s;$f;$tmp;" $file
> +done
> +
> +exit 0


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

Re: [U-Boot] [PATCH] net: e1000: support 'write_hwaddr' in DM

[Hannes Schmelzer]

On 24.10.2018 20:42, Joseph Hershberger wrote:

Hi Hannes,

Hi Joe,

This seems to break many boards. Please build boards that failed and address 
the break.

https://travis-ci.org/jhershbe/u-boot/builds/444858982

Sorry for inconvenience, i fixed that and sent a V2 to the mailinglist.
Made also a travis build: https://travis-ci.org/oe5hpm/u-boot/jobs/446070290


Thanks,
-Joe

cheers,
Hannes

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

[U-Boot] [PATCH v2] net: e1000: support 'write_hwaddr' in DM

[Hannes Schmelzer]

This commit ports the existing (non-DM) function for writing the MAC-
address into the shadow ram (and flash) for DM.

Signed-off-by: Hannes Schmelzer 
---

Changes in v2:
- fix build for non-DM board
- rebase on current master

 drivers/net/e1000.c | 89 +
 1 file changed, 48 insertions(+), 41 deletions(-)

diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index a34f697..3df 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -862,7 +862,6 @@ e1000_read_eeprom(struct e1000_hw *hw, uint16_t offset,
return E1000_SUCCESS;
 }
 
-#ifndef CONFIG_DM_ETH
 /**
  *  e1000_write_eeprom_srwr - Write to Shadow Ram using EEWR
  *  @hw: pointer to the HW structure
@@ -1028,7 +1027,6 @@ static int32_t e1000_update_eeprom_checksum_i210(struct 
e1000_hw *hw)
 out:
return ret_val;
 }
-#endif
 
 /**
  * Verifies that the EEPROM has a valid checksum
@@ -5488,6 +5486,53 @@ void e1000_get_bus_type(struct e1000_hw *hw)
 }
 
 #ifndef CONFIG_DM_ETH
+static int e1000_write_hwaddr(struct eth_device *dev)
+#else
+static int e1000_write_hwaddr(struct udevice *dev)
+#endif
+{
+#ifndef CONFIG_E1000_NO_NVM
+#ifndef CONFIG_DM_ETH
+   unsigned char *mac = dev->enetaddr;
+   struct e1000_hw *hw = dev->priv;
+#else
+   struct eth_pdata *plat = dev_get_platdata(dev);
+   unsigned char *mac = plat->enetaddr;
+   struct e1000_hw *hw = dev_get_priv(dev);
+#endif
+   unsigned char current_mac[6];
+   u16 data[3];
+   int ret_val, i;
+
+   DEBUGOUT("%s: mac=%pM\n", __func__, mac);
+
+   memset(current_mac, 0, 6);
+
+   /* Read from EEPROM, not from registers, to make sure
+* the address is persistently configured
+*/
+   ret_val = e1000_read_mac_addr_from_eeprom(hw, current_mac);
+   DEBUGOUT("%s: current mac=%pM\n", __func__, current_mac);
+
+   /* Only write to EEPROM if the given address is different or
+* reading the current address failed
+*/
+   if (!ret_val && memcmp(current_mac, mac, 6) == 0)
+   return 0;
+
+   for (i = 0; i < 3; ++i)
+   data[i] = mac[i * 2 + 1] << 8 | mac[i * 2];
+
+   ret_val = e1000_write_eeprom_srwr(hw, 0x0, 3, data);
+   if (!ret_val)
+   ret_val = e1000_update_eeprom_checksum_i210(hw);
+   return ret_val;
+#else  /* CONFIG_E1000_NO_NVM */
+   return 0;
+#endif
+}
+
+#ifndef CONFIG_DM_ETH
 /* A list of all registered e1000 devices */
 static LIST_HEAD(e1000_hw_list);
 #endif
@@ -5649,45 +5694,6 @@ e1000_poll(struct eth_device *nic)
return len ? 1 : 0;
 }
 
-static int e1000_write_hwaddr(struct eth_device *dev)
-{
-#ifndef CONFIG_E1000_NO_NVM
-   unsigned char *mac = dev->enetaddr;
-   unsigned char current_mac[6];
-   struct e1000_hw *hw = dev->priv;
-   uint16_t data[3];
-   int ret_val, i;
-
-   DEBUGOUT("%s: mac=%pM\n", __func__, mac);
-
-   memset(current_mac, 0, 6);
-
-   /* Read from EEPROM, not from registers, to make sure
-* the address is persistently configured
-*/
-   ret_val = e1000_read_mac_addr_from_eeprom(hw, current_mac);
-   DEBUGOUT("%s: current mac=%pM\n", __func__, current_mac);
-
-   /* Only write to EEPROM if the given address is different or
-* reading the current address failed
-*/
-   if (!ret_val && memcmp(current_mac, mac, 6) == 0)
-   return 0;
-
-   for (i = 0; i < 3; ++i)
-   data[i] = mac[i * 2 + 1] << 8 | mac[i * 2];
-
-   ret_val = e1000_write_eeprom_srwr(hw, 0x0, 3, data);
-
-   if (!ret_val)
-   ret_val = e1000_update_eeprom_checksum_i210(hw);
-
-   return ret_val;
-#else
-   return 0;
-#endif
-}
-
 /**
 PROBE - Look for an adapter, this routine's visible to the outside
 You should omit the last argument struct pci_device * for a non-PCI NIC
@@ -5914,6 +5920,7 @@ static const struct eth_ops e1000_eth_ops = {
.recv   = e1000_eth_recv,
.stop   = e1000_eth_stop,
.free_pkt = e1000_free_pkt,
+   .write_hwaddr = e1000_write_hwaddr,
 };
 
 static const struct udevice_id e1000_eth_ids[] = {
-- 
2.7.4


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

Re: [U-Boot] [PATCH] drivers: serial: probe all serial devices

[Bin Meng]

Hi Simon,

On Fri, Oct 19, 2018 at 11:26 AM Simon Glass  wrote:
>
> Hi Bin,
>
> On 15 October 2018 at 06:28, Bin Meng  wrote:
> > On Mon, Oct 15, 2018 at 8:15 PM Vabhav Sharma  wrote:
> >>
> >> Serial subsystem search and probe only one first serial
> >> device and unable to use remaining available UART devices
> >>
> >> This patch changes the logic to probe all available serial devices
> >> using platform data or device tree in DM model in order to use all
> >> UART devices
> >>
> >> Signed-off-by: Vabhav Sharma 
> >> ---
> >>  drivers/serial/Kconfig | 12 
> >>  drivers/serial/serial-uclass.c | 42 
> >> ++
> >>  2 files changed, 54 insertions(+)
> >>
> >
> > Looks more and more devices have requirement to be probed during boot.
> > Guess we should handle such in a unified way?
>
> How about:
>
> - in dm_init(), after binding, we move on to an auto-probe step
> - a uclass flag indicates that all devices in that uclass must be probed
>  (that will be useful for PCI)
>
> - a way to tell DM to probe all devices in a particular uclass (e.g. a
> call to dm_set_uclass_autoprobe(enum uclass_id, bool)
>   (that will be useful for this serial case)

Sounds good to me. Thanks for checking.

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

Re: [U-Boot] Please pull u-boot-dm

[Tom Rini]

On Wed, Oct 24, 2018 at 08:33:01AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On 24 October 2018 at 08:28, Bin Meng  wrote:
> > Hi Simon,
> >
> > On Wed, Oct 24, 2018 at 10:14 PM Simon Glass  wrote:
> >>
> >> Hi Tom,
> >>
> >> On 19 October 2018 at 06:10, Tom Rini  wrote:
> >> > On Thu, Oct 18, 2018 at 09:27:49PM -0600, Simon Glass wrote:
> >> >> Hi,
> >> >>
> >> >> On 17 October 2018 at 11:14, Stephen Warren  
> >> >> wrote:
> >> >> > On 10/16/18 8:33 PM, Bin Meng wrote:
> >> >> >>
> >> >> >> On Wed, Oct 17, 2018 at 7:01 AM Bin Meng  wrote:
> >> >> >>>
> >> >> >>>
> >> >> >>> Hi Stephen,
> >> >> >>>
> >> >> >>> On Wed, Oct 17, 2018 at 12:27 AM Stephen Warren 
> >> >> >>> 
> >> >> >>> wrote:
> >> >> 
> >> >> 
> >> >>  On 10/15/18 5:43 PM, Bin Meng wrote:
> >> >> >
> >> >> > Hi Stephen,
> >> >> >
> >> >> > On Tue, Oct 16, 2018 at 6:43 AM Stephen Warren 
> >> >> > 
> >> >> > wrote:
> >> >> >>
> >> >> >>
> >> >> >> On 10/15/18 3:53 PM, Stephen Warren wrote:
> >> >> >>>
> >> >> >>> On 10/15/18 2:17 PM, Simon Glass wrote:
> >> >> 
> >> >>  Hi Tom,
> >> >> 
> >> >>  The following changes since commit
> >> >>  6e7a186dc5d50f563e224e9ae7be70defff7ee0d:
> >> >> 
> >> >>   Merge tag 'arc-more-updates-for-2018.11-rc2-2' of
> >> >>  git://git.denx.de/u-boot-arc (2018-10-15 07:20:07 -0400)
> >> >> 
> >> >>  are available in the Git repository at:
> >> >> 
> >> >>   git://git.denx.de/u-boot-dm.git tags/pull-15oct-18
> >> >> 
> >> >>  for you to fetch changes up to
> >> >>  02f2d266c75106a2fefd1f4e8e6f703fe00ed21d:
> >> >> 
> >> >>   buildman: Add a --boards option to specify particular 
> >> >>  boards to
> >> >>  build (2018-10-15 08:20:43 -0600)
> >> >> >>>
> >> >> >>>
> >> >> >>> There's something wrong with these patches; both Jetson TX1 and
> >> >> >>> Jetson
> >> >> >>> TX2 (both 64-bit ARM without SPL) fail to boot with this 
> >> >> >>> branch; the
> >> >> >>> system hangs with no output at all from U-Boot. Jetson TK1 
> >> >> >>> (32-bit
> >> >> >>> ARM
> >> >> >>> with SPL) and sandbox boot fine.
> >> >> >>
> >> >> >>
> >> >> >> Reverting the following solves the issue:
> >> >> >>
> >> >> >> 1) dm: core: Mirror the chosen node parse logic in the livetree
> >> >> >> scanning
> >> >> >>
> >> >> >> 2) dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
> >> >> >> lists_bind_fdt()
> >> >> >>
> >> >> >> Reverting just (1) or just (2) does not. Can you please take a 
> >> >> >> look?
> >> >> >> Thanks.
> >> >> >
> >> >> >
> >> >> > The failure is probably due to some drivers that Tegra uses are 
> >> >> > not
> >> >> > properly written, ie: these drivers are declared via U_BOOT_DRIVER
> >> >> > with flags DM_FLAG_PRE_RELOC yet it was never working (bound 
> >> >> > before
> >> >> > relocation) until patch (1) & (2). Now these drivers get bound 
> >> >> > before
> >> >> > relocation but they were never bound before (assume they were 
> >> >> > never
> >> >> > required before relocation), so we should identify which driver 
> >> >> > were
> >> >> > wrongly written, but as a quick solution, can you please enlarge 
> >> >> > the
> >> >> > CONFIG_SYS_MALLOC_F_LEN of your board and have a try?
> >> >> 
> >> >> 
> >> >>  Yes, bumping CONFIG_SYS_MALLOC_F_LEN from 0x1800 to 0x1a90 solves 
> >> >>  the
> >> >>  issue. Alternatively, removing DM_FLAG_PRE_RELOC in tegra_gpio.c or
> >> >>  tegra186_gpio.c (depending on board/SoC) also solves this.
> >> >> 
> >> >>  I suppose the correct solution is to remove the DM flag from the 
> >> >>  driver,
> >> >>  since if it never used to work before your patches, it's clear 
> >> >>  that the
> >> >>  flag/feature is not actually required.
> >> >> >>>
> >> >> >>>
> >> >> >>> Thank you Stephen. I will prepare a patch to update the tegra*_gpio
> >> >> >>> driver.
> >> >>
> >> >> Thanks Bin,
> >> >>
> >> >> >>
> >> >> >>
> >> >> >> Ah, it turns out so many drivers/dts are mis-written ...
> >> >> >>
> >> >> >> For example, the driver has the DM_FLAG_PRE_RELOC flag, and the dts
> >> >> >> file also has "u-boot,dm-pre-reloc". The "u-boot,dm-pre-reloc" must
> >> >> >> have been added to workaround the DM bug (fixed in patch 1 & 2
> >> >> >> mentioned in this thread). But now since the DM bug has been fixed,
> >> >> >> these "u-boot,dm-pre-reloc" properties are really unnecessary but I 
> >> >> >> am
> >> >> >> afraid I don't have the knowledge to clean up all of these.
> >> >> >>
> >> >> >> Of course, I've identified some additional drivers that have
> >> >> >> DM_FLAG_PRE_RELOC flag set but dts file doesn't have
> >> >> >> "u-boot,dm-pre-reloc". These drivers should 

Re: [U-Boot] [U-Boot-DM] [PATCH] drivers: serial: probe all serial devices

[Vabhav Sharma]

> -Original Message-
> From: Wolfgang Denk 
> Sent: Thursday, October 25, 2018 7:35 PM
> To: Vabhav Sharma 
> Cc: Marek Vasut ; u-boot@lists.denx.de; u-boot-
> d...@lists.denx.de; s...@chromium.org; yamada.masah...@socionext.com;
> bmeng...@gmail.com
> Subject: Re: [U-Boot-DM] [PATCH] drivers: serial: probe all serial devices
> 
> Dear Vabhav,
> 
> In message
>  prod.outlook.com> you wrote:
> >
> > > You can also use setenv stdin/stdout/stderr to alternate between
> > > stdio devices. So what is the problem ?
> > Problem is seen with PL011 driver using DM model, Only boot console
> baud rate is set.
> 
> U-Boot can talk to only one serial device at a time anyway, so why should it
> intiaalize othe rports than the one used for the (then
> current) console?
> 
> U-Boot does lazy initializationintentionally.  It is wrong to initialize 
> devices
> which are not actually used.
There is configuration option to enable the device using platform data or 
device tree using DM model.
For e.g: 2 UART controllers are enabled in device tree but DM model initialized 
only one, This is limitation
My suggestion is to initialize all devices which are enabled, E.g. use case is 
using UART1 for uboot consoled and UART2 for linux boot 
On NXP SoC, We also use UART3 for ethernet firmware logging but using DM model 
all enabled devices are not probed  posing limitation
> 
> > Tried modifying the environment variable but seems readonly  (## Error
> > inserting "stdout" variable, errno=22)
> 
> How exactly did you try to do that?
#editenv stdout
> 
> > Multiple UART enablement is required to use all console.
> 
> I have a feeling that you attempt to do the Wong Thing.
I quoted the reason above and also discussed on in email(23 may) " [U-Boot-DM] 
QUERY:U-boot DM:SERIAL:Multiple On-chip UART Controller Support" with suggested 
solution from Simon which is sent as patch for review.
Similar issue was faced by Andreas
> 
> Best regards,
> 
> Wolfgang Denk
> 
> --
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I
> am an atheist, thank God!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot-DM] [PATCH] drivers: serial: probe all serial devices

[Wolfgang Denk]

Dear Vabhav,

In message 

 you wrote:
>
> > You can also use setenv stdin/stdout/stderr to alternate between stdio
> > devices. So what is the problem ?
> Problem is seen with PL011 driver using DM model, Only boot console baud rate 
> is set.

U-Boot can talk to only one serial device at a time anyway, so why
should it intiaalize othe rports than the one used for the (then
current) console?

U-Boot does lazy initializationintentionally.  It is wrong to
initialize devices which are not actually used.

> Tried modifying the environment variable but seems readonly  (##
> Error inserting "stdout" variable, errno=22)

How exactly did you try to do that?

> Multiple UART enablement is required to use all console.

I have a feeling that you attempt to do the Wong Thing.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I am an atheist, thank God!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] drivers: serial: probe all serial devices

[Vabhav Sharma]

> -Original Message-
> From: s...@google.com  On Behalf Of Simon Glass
> Sent: Friday, October 19, 2018 8:56 AM
> To: Bin Meng 
> Cc: Vabhav Sharma ; U-Boot Mailing List  b...@lists.denx.de>; u-boot...@lists.denx.de; Andreas Dannenberg
> ; Masahiro Yamada
> ; Stefan Roese 
> Subject: Re: [PATCH] drivers: serial: probe all serial devices
> 
> Hi Bin,
> 
> On 15 October 2018 at 06:28, Bin Meng  wrote:
> > On Mon, Oct 15, 2018 at 8:15 PM Vabhav Sharma
>  wrote:
> >>
> >> Serial subsystem search and probe only one first serial device and
> >> unable to use remaining available UART devices
> >>
> >> This patch changes the logic to probe all available serial devices
> >> using platform data or device tree in DM model in order to use all
> >> UART devices
> >>
> >> Signed-off-by: Vabhav Sharma 
> >> ---
> >>  drivers/serial/Kconfig | 12 
> >>  drivers/serial/serial-uclass.c | 42
> >> ++
> >>  2 files changed, 54 insertions(+)
> >>
> >
> > Looks more and more devices have requirement to be probed during boot.
> > Guess we should handle such in a unified way?
> 
> How about:
> 
> - in dm_init(), after binding, we move on to an auto-probe step
> - a uclass flag indicates that all devices in that uclass must be probed  
> (that
> will be useful for PCI)
For devices class respective UCLASS to be provided with auto-probe, How many 
class to be included?
> 
> - a way to tell DM to probe all devices in a particular uclass (e.g. a call to
> dm_set_uclass_autoprobe(enum uclass_id, bool)
>   (that will be useful for this serial case)
Do you mean to verify and send patch for serial uclass with this approach after 
device_probe in dm_init
> 
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot-DM] [PATCH] drivers: serial: probe all serial devices

[Vabhav Sharma]

Hi Marek Vasut,
Apology for delayed reply, Occupied with other work

> -Original Message-
> From: Marek Vasut 
> Sent: Tuesday, October 16, 2018 2:39 PM
> To: Vabhav Sharma ; u-boot@lists.denx.de; u-
> boot...@lists.denx.de; s...@chromium.org
> Cc: yamada.masah...@socionext.com; bmeng...@gmail.com; Andreas
> Dannenberg 
> Subject: Re: [U-Boot-DM] [PATCH] drivers: serial: probe all serial devices
> 
> On 10/16/2018 09:20 AM, Vabhav Sharma wrote:
> >
> >
> >> -Original Message-
> >> From: Marek Vasut 
> >> Sent: Tuesday, October 16, 2018 12:29 PM
> >> To: Vabhav Sharma ; u-boot@lists.denx.de;
> >> u-boot- d...@lists.denx.de; s...@chromium.org
> >> Cc: yamada.masah...@socionext.com; bmeng...@gmail.com
> >> Subject: Re: [U-Boot-DM] [PATCH] drivers: serial: probe all serial
> >> devices
> >>
> >> On 10/15/2018 02:09 AM, Vabhav Sharma wrote:
> >>> Serial subsystem search and probe only one first serial device and
> >>> unable to use remaining available UART devices
> >>
> >> The serial devices are bound and you can switch to them. What is the
> >> real problem ?
> > Yes, I understand switch is possible with change in DTS or platform data for
> choosing UART device to be used as boot console(e.g. UART0) with gd-
> >cur_serial_dev is updated to chosen UART device.
> > The problem was stated in email(attached 23 may) " [U-Boot-DM]
> QUERY:U-boot DM:SERIAL:Multiple On-chip UART Controller Support" with
> suggested solution from Simon which is sent as patch for review.
> > Similar issue was faced by Andreas
> 
> You can also use setenv stdin/stdout/stderr to alternate between stdio
> devices. So what is the problem ?
Problem is seen with PL011 driver using DM model, Only boot console baud rate 
is set.
Tried modifying the environment variable but seems readonly  (## Error 
inserting "stdout" variable, errno=22)
Multiple UART enablement is required to use all console.
> 
> >>> This patch changes the logic to probe all available serial devices
> >>> using platform data or device tree in DM model in order to use all
> >>> UART devices
> >>
> >> Get rid of the ifdeffery and copied code please.
> > This is case for using uclass_next_device() to iterate through them, Having
> CONFIG option doesn't make it mandatory for every platform to probe all
> serial devices.
> 
> Is this also the case for having 6 copies of exactly the same code ? You can
> turn it into a function if needed.
Ok, I understand
> 
> >>> Signed-off-by: Vabhav Sharma 
> >>> ---
> >>>  drivers/serial/Kconfig | 12 
> >>>  drivers/serial/serial-uclass.c | 42
> >>> ++
> >>>  2 files changed, 54 insertions(+)
> >>>
> >>> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index
> >>> 597db4b..d6451b1 100644
> >>> --- a/drivers/serial/Kconfig
> >>> +++ b/drivers/serial/Kconfig
> >>> @@ -133,6 +133,18 @@ config SERIAL_SEARCH_ALL
> >>>
> >>> If unsure, say N.
> >>>
> >>> +config SERIAL_PROBE_ALL
> >>> + bool "Probe all available serial devices"
> >>> + depends on DM_SERIAL
> >>> + help
> >>> +  The serial subsystem only probe for single serial device, but does
> >>> +  not probe for remaining available devices.
> >>> +  With this option set,we make probing for all available devices
> >>> +  mandatory.
> >>> +
> >>> +  If probing is not required for all remaining available
> >>> +  devices other than default current console device, say N.
> >>> +
> >>>  config SPL_DM_SERIAL
> >>>   bool "Enable Driver Model for serial drivers in SPL"
> >>>   depends on DM_SERIAL && SPL_DM
> >>> diff --git a/drivers/serial/serial-uclass.c
> >>> b/drivers/serial/serial-uclass.c index e50f0aa..405e60e 100644
> >>> --- a/drivers/serial/serial-uclass.c
> >>> +++ b/drivers/serial/serial-uclass.c
> >>> @@ -82,6 +82,13 @@ static void serial_find_console_or_panic(void)
> >>>   uclass_first_device(UCLASS_SERIAL, );
> >>>   if (dev) {
> >>>   gd->cur_serial_dev = dev;
> >>> +#ifdef CONFIG_SERIAL_PROBE_ALL
> >>> + /* Scanning uclass to probe all devices */
> >>> + for (;
> >>> +  dev;
> >>> +  uclass_next_device())
> >>> + ;
> >>> +#endif
> >>>   return;
> >>>   }
> >>>   } else if (CONFIG_IS_ENABLED(OF_CONTROL) && blob) { @@ -92,11
> >> +99,25
> >>> @@ static void serial_find_console_or_panic(void)
> >>>   if (np
> >> && !uclass_get_device_by_ofnode(UCLASS_SERIAL,
> >>>   np_to_ofnode(np), )) {
> >>>   gd->cur_serial_dev = dev;
> >>> +#ifdef CONFIG_SERIAL_PROBE_ALL
> >>> + /* Scanning uclass to probe all devices */
> >>> + for (;
> >>> +  dev;
> >>> +  uclass_next_device())
> >>> + ;
> >>> +#endif
> >>>   return;
> >>> 

Re: [U-Boot] [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register

[Bin Meng]

Hi Rick,

On Thu, Oct 25, 2018 at 11:27 AM Rick Chen  wrote:
>
> Bin Meng  於 2018年10月25日 週四 上午11:16寫道：
> >
> > Hi Rick,
> >
> > On Thu, Oct 25, 2018 at 11:11 AM Rick Chen  wrote:
> > >
> > > Bin Meng  於 2018年10月25日 週四 上午10:33寫道：
> > > >
> > > > Hi Rick,
> > > >
> > > > On Thu, Oct 25, 2018 at 9:20 AM Andes  wrote:
> > > > >
> > > > > From: Rick Chen 
> > > > >
> > > > > ax25-ae350 use CONFIG_OF_BOARD which allow the board to
> > > > > override the fdt address. And prior_stage_fdt_address offer
> > > > > a temporary memory address to keep the dtb address which was
> > > > > passed from loader(gdb) to u-boot with a1.
> > > >
> > > > nits: U-Boot
> > > >
> > > > >
> > > > > Signed-off-by: Rick Chen 
> > > > > Cc: Greentime Hu 
> > > > > ---
> > > > >  board/AndesTech/ax25-ae350/ax25-ae350.c | 3 ++-
> > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c 
> > > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > index 5f4ca0f..d343453 100644
> > > > > --- a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > +++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > @@ -14,6 +14,7 @@
> > > > >
> > > > >  DECLARE_GLOBAL_DATA_PTR;
> > > > >
> > > > > +extern phys_addr_t prior_stage_fdt_address;
> > > > >  /*
> > > > >   * Miscellaneous platform dependent initializations
> > > > >   */
> > > > > @@ -66,7 +67,7 @@ ulong board_flash_get_legacy(ulong base, int 
> > > > > banknum, flash_info_t *info)
> > > > >
> > > > >  void *board_fdt_blob_setup(void)
> > > > >  {
> > > > > -   void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > > +   void **ptr = (void *)_stage_fdt_address;
> > > > > if (fdt_magic(*ptr) == FDT_MAGIC)
> > > > > return (void *)*ptr;
> > > > >
> > > > > --
> > > >
> > > > board_fdt_blob_setup() should be completely removed. Instead the
> > > > simple fix should be add CONFIG_OF_PRIOR_STAGE to your board defconfig
> > > > files.
> > > >
> > >
> > > Hi Bin
> > >
> > > I have tried to switch from CONFIG_OF_BOARD to CONFIG_OF_PRIOR_STAGE.
> > >
> > > But it will lost the function
> > > that dtb will be pre-burned into designated flash location,
> > > when U-Boot was booting from flash.
> > >
> >
> > I don't get it. Do you mean on ae350 board, the DTB is pre-flashed on the 
> > flash?
> >
>
> Yes
> On ae350 board, the DTB is pre-flashed on the flash in booting from rom case.
>
> u-boot boot from ram case:
> CONFIG_OF_PRIOR_STAGE can achieve u-boot boot from ram and dtb was
> passed by loader with a1(0xf).
>
> u-boot boot from rom case:
> If DTB is pre-flashed on the flash 0x800f (This address can be
> dynamically changed)
> But no one assign a1=0x800f000, how can be gd->fdt_blob changed to 0x800f000.
> I am wondering about that ?
>

In the ROM case, U-Boot does not boot from reset vector, right? So the
first stage bootloader can pass DTB to U-Boot via a1 register, no?

> 0xf is ram space
> 0x800f is flash rom space
>

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

Re: [U-Boot] [PATCH 09/30] riscv: move target selection into separate file

[Bin Meng]

Hi Lukas,

On Thu, Oct 25, 2018 at 7:39 PM Auer, Lukas
 wrote:
>
> Hi Bin,
>
> On Mon, 2018-10-22 at 15:22 +0800, Bin Meng wrote:
> > Hi Lukas,
> >
> > On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
> >  wrote:
> > >
> > > Move the target selection into a separate file (Kconfig.board) to
> > > avoid
> > > clutter once we support more boards.
> > >
> > > Signed-off-by: Lukas Auer 
> > > ---
> > >
> > >  arch/riscv/Kconfig   | 17 ++---
> > >  arch/riscv/Kconfig.board | 14 ++
> > >  2 files changed, 16 insertions(+), 15 deletions(-)
> > >  create mode 100644 arch/riscv/Kconfig.board
> > >
> > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > > index ce07fb4b55..10d17a0e18 100644
> > > --- a/arch/riscv/Kconfig
> > > +++ b/arch/riscv/Kconfig
> > > @@ -4,21 +4,6 @@ menu "RISC-V architecture"
> > >  config SYS_ARCH
> > > default "riscv"
> > >
> > > -choice
> > > -   prompt "Target select"
> > > -   optional
> > > -
> > > -config TARGET_AX25_AE350
> > > -   bool "Support ax25-ae350"
> > > -
> > > -config TARGET_QEMU_VIRT
> > > -   bool "Support QEMU Virt Board"
> > > -
> > > -endchoice
> > > -
> > > -source "board/AndesTech/ax25-ae350/Kconfig"
> > > -source "board/emulation/qemu-riscv/Kconfig"
> > > -
> > >  choice
> > > prompt "Base ISA"
> > > default ARCH_RV32I
> > > @@ -72,4 +57,6 @@ config 32BIT
> > >  config 64BIT
> > > bool
> > >
> > > +source "arch/riscv/Kconfig.board"
> > > +
> >
> > I am OK with moving board one to a separate file, though it looks no
> > other arch uses scuh convention in U-Boot :)
> >
> > However, with this change, it lost the capability of overriding an
> > architecture defined Kconfig option at board level.
> >
> > I have a patch @
> >
> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commitdiff;h=5a650689410482907a37f77b2a4257d81bb4daa2
> > to express such capability.
> >
>
> This should be easy to fix by just moving the source statement, right?
>

Yes. You can drop this patch.

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

Re: [U-Boot] [PATCH v2 01/18] tools: MediaTek: add MTK boot header generation to mkimage

[Ryder Lee]

On Wed, 2018-10-24 at 21:29 -0600, Simon Glass wrote:
> Hi Ryder,
> 
> On 12 October 2018 at 01:00, Ryder Lee  wrote:
> > This patch adds support for MTK boot image generation.
> >
> > Signed-off-by: Weijie Gao 
> > Signed-off-by: Ryder Lee 
> > ---
> >  Makefile |  22 ++
> >  common/image.c   |   1 +
> >  include/image.h  |   1 +
> >  scripts/Makefile.spl |  11 +
> >  tools/Makefile   |   1 +
> >  tools/mtkimage.c | 749 
> > +++
> >  tools/mtkimage.h | 199 ++
> >  7 files changed, 984 insertions(+)
> >  create mode 100644 tools/mtkimage.c
> >  create mode 100644 tools/mtkimage.h
> 
> The mkimage stuff looks fine.
> 
> But can you use binman for the pad/cat part of this? See for example
> sunxi. - sunxi-u-boot.dtsi
> 
> Also mtkimage.c is too close to mkimage.c - how about mtk_image.c ?
> 

This looks great. I will switch to use binman in v3.

Thanks
Ryder


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

Re: [U-Boot] [PATCH 3/4] x86: theadorable-x86: Generate and pass root=PARTUUID instead of /dev/sdaX

[Bin Meng]

On Tue, Oct 23, 2018 at 12:54 PM Bin Meng  wrote:
>
> On Mon, Oct 22, 2018 at 8:08 PM Stefan Roese  wrote:
> >
> > To enable the root device selection (kernel cmd-line) via PARTUUID, this
> > patch enables CMD_PART on all missing theadorable-x86 boards and
> > changes the default environment to generate the root=PARTUUID string
> > automatically.
> >
> > This fixes problems that have been noticed on systems with multiple
> > SATA/AHCI controller connected via PCIe, where the device name for the
> > root device / partition (/dev/sdaX) was incorrect.
> >
> > Signed-off-by: Stefan Roese 
> > ---
> >  ...able-x86-conga-qa3-e3845-pcie-x4_defconfig |  1 +
> >  .../theadorable-x86-conga-qa3-e3845_defconfig |  1 +
> >  include/configs/theadorable-x86-common.h  | 35 +++
> >  3 files changed, 23 insertions(+), 14 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

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

Re: [U-Boot] [PATCH 4/4] x86: theadorable-x86-xxx_defconfig: Move VGA BIOS to make room for U-Boot

[Bin Meng]

On Tue, Oct 23, 2018 at 12:54 PM Bin Meng  wrote:
>
> On Mon, Oct 22, 2018 at 8:09 PM Stefan Roese  wrote:
> >
> > The build breaks because its not fitting the U-Boot binary into the ROM
> > image. So lets move VGA BIOS a bit to make room for the grown U-Boot
> > binary.
> >
> > Signed-off-by: Stefan Roese 
> > ---
> >  configs/theadorable-x86-conga-qa3-e3845-pcie-x4_defconfig | 2 +-
> >  configs/theadorable-x86-conga-qa3-e3845_defconfig | 2 +-
> >  configs/theadorable-x86-dfi-bt700_defconfig   | 2 +-
> >  3 files changed, 3 insertions(+), 3 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

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

Re: [U-Boot] [PATCH 2/4] x86: theadorable-x86-common: Change pci hotplug cmdline parameters (again)

[Bin Meng]

On Tue, Oct 23, 2018 at 12:54 PM Bin Meng  wrote:
>
> On Mon, Oct 22, 2018 at 8:08 PM Stefan Roese  wrote:
> >
> > This is needed for the PCIe hotplug to work correctly on some boards
> > with the newer Linux kernel versions.
> >
> > Signed-off-by: Stefan Roese 
> > Cc: Bin Meng 
> > ---
> >  include/configs/theadorable-x86-common.h | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
>
> I cannot find 'hpmemprefsize' as a kernel command line parameter, so I
> assume removing it does not introduce any issue.
>
> Reviewed-by: Bin Meng 

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

Re: [U-Boot] [PATCH 1/4] x86: BayTrail: southcluster.asl: Change PCI 64 bit address range / region

[Bin Meng]

On Tue, Oct 23, 2018 at 12:54 PM Bin Meng  wrote:
>
> On Mon, Oct 22, 2018 at 8:08 PM Stefan Roese  wrote:
> >
> > To allow bigger 64 bit prefetchable PCI regions in Linux, this patch
> > changes the base address and range of the ACPI area passed to Linux.
> > BayTrail can only physically access 36 bit of PCI address space. So
> > just chaning the range without changing the base address won't work
> > here, as 0xf.. is already the maximum address.
> >
> > With this patch, a maximum of 16 GiB of local DDR is supported. This
> > should be enough for all BayTrail boards though.
> >
> > Signed-off-by: Stefan Roese 
> > Cc: Bin Meng 
> > Cc: Simon Glass 
> > ---
> >  arch/x86/include/asm/arch-baytrail/acpi/southcluster.asl | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

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

Re: [U-Boot] U-Boot and The Boot Loader Specification

[Dennis Gilmore]

El vie, 19-10-2018 a las 12:12 +0200, Wolfgang Denk escribió:
> Dear Alexander,
> 
> In message <118460556.a0Y5euKZZ7@ada> you wrote:
> > >  864 /*
> > >  865  * Keywords recognized.
> > >  866  */
> > >  867 static const struct token keywords[] = {
> > >  868 {"menu", T_MENU},
> > >  869 {"title", T_TITLE},
> > >  870 {"timeout", T_TIMEOUT},
> > >  871 {"default", T_DEFAULT},
> > >  872 {"prompt", T_PROMPT},
> > >  873 {"label", T_LABEL},
> > >  874 {"kernel", T_KERNEL},
> > >  875 {"linux", T_LINUX},
> > >  876 {"localboot", T_LOCALBOOT},
> > >  877 {"append", T_APPEND},
> > >  878 {"initrd", T_INITRD},
> > >  879 {"include", T_INCLUDE},
> > >  880 {"devicetree", T_FDT},
> > >  881 {"fdt", T_FDT},
> > >  882 {"devicetreedir", T_FDTDIR},
> > >  883 {"fdtdir", T_FDTDIR},
> > >  884 {"ontimeout", T_ONTIMEOUT,},
> > >  885 {"ipappend", T_IPAPPEND,},
> > >  886 {NULL, T_INVALID}
> > >  887 };
> > > 
> > > This does not fit with your description, as you list:
> > > > Ignoring unknown command: title
> > > > Ignoring unknown command: version
> > > > Ignoring unknown command: options
> > > > Ignoring unknown command: linux
> > > > Ignoring unknown command: devicetree
> > > 
> > > OK, "version" and "options" are not implemented, but the other
> > > keywords are, so you must be doing something else wrong.
> > 
> > That's what I was saying. I suppose the handling of label and title
> > is 
> > different, so the entry group I had below 'title' was not
> > recognized as group 
> > of options for one entry, like it was when replacing title with
> > label. I can 
> > write an actually working extlinux.conf file (as showed in my last
> > mail), but 
> > that was not the question I had in the first place.
> 
> Well, what confuses me here is that you cleanly show error messages
> for example for title, linux, and devicetree, even though these
> should be recognized as valid keywords.
> 
> I think there are sublte imcompatibilities in your config file
> (and/or bugs in the code).  See also this comment (same file):
> 
>  440  * A note on the pxe file parser.
>  441  *
>  442  * We're parsing files that use syslinux grammar, which has a
> few quirks.
>  443  * String literals must be recognized based on context - there
> is no
>  444  * quoting or escaping support. There's also nothing to
> explicitly indicate
>  445  * when a label section completes. We deal with that by ending a
> label
>  446  * section whenever we see a line that doesn't include.
>  447  *
>  448  * As with the syslinux family, this same file format could be
> reused in the
>  449  * future for non pxe purposes. The only action it takes during
> parsing that
>  450  * would throw this off is handling of include files. It assumes
> we're using
>  451  * pxe, and does a tftp download of a file listed as an include
> file in the
>  452  * middle of the parsing operation. That could be handled by
> refactoring it to
>  453  * take a 'include file getter' function.
> 
> > The U-Boot documentation in the file 'doc/README.distro' could lead
> > to the 
> > impression as if U-Boot would support the BootLoaderSpec and even
> > links to it: 
> > http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
> > 
> > That spec says basically, in my own words: "put one conf file for
> > each boot 
> > menu item in the directory /boot/loader/entries and let it have the
> > following 
> > format." 
> > 
> > The keywords differ from the ones used by extlinux/U-Boot, in my
> > opinion the 
> > U-Boot documentation in 'doc/README.distro' however is not very
> > clear about 
> > that.
> 
> I'm adding Dennis on Cc: who submitted the doc; I hope he has a
> better understanding of the state of things.

Sorry for the slow response, I have been travelling,  currently u-boot
does not support the boot loader spec, it was a goal that no-one found
the time to solve, the main issue being how to we traverse the
directories to parse all the snippets.

> > Is U-Boot supposed to honour that Boot Loader Specification?
> 
> I think it should, if possible.
> 
> > If yes: then it does not work as specified. Is anybody working on
> > making U-
> > Boot comply?
> 
> None that I know of.
There is no one working on it, I should remove the link to
BootLoaderSpec 

> > If no: would anybody mind changing the documentation to better
> > reflect what U-
> > Boot actually does and not mislead people into thinking U-Boot
> > would be 
> > compliant to that specification (like it was the case for me)? I
> > would send a 
> > patch if nobody objects.
> 
> Can we not do it the other way round, and fix the code that it
> improves and conforms (better) to the spec?

We could, I have not yet found a way to solve the problems. It would be
nice to solve them

Dennis
> Best regards,
> 
> Wolfgang Denk
> 

Re: [U-Boot] [PATCH 13/30] riscv: do not reimplement generic io functions

[Auer, Lukas]

Hi Bin,

On Mon, 2018-10-22 at 15:36 +0800, Bin Meng wrote:
> Hi Lukas,
> 
> On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
>  wrote:
> > 
> > RISC-V u-boot reimplements the generic io functions from
> 
> nits: U-Boot
> 

Fixed in v2.

Thanks,
Lukas

> > asm-generic/io.h. Remove the redundant implementation and include
> > the
> > generic io.h instead.
> > 
> > Signed-off-by: Lukas Auer 
> > ---
> > 
> >  arch/riscv/include/asm/io.h | 31 +++
> >  1 file changed, 3 insertions(+), 28 deletions(-)
> > 
> 
> Reviewed-by: Bin Meng 
> 
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 12/30] riscv: make use of the barrier functions from Linux

[Auer, Lukas]

Hi Bin,

On Mon, 2018-10-22 at 15:36 +0800, Bin Meng wrote:
> Hi Lukas,
> 
> On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
>  wrote:
> > 
> > Replace the barrier functions in arch/riscv/include/asm/io.h with
> > those
> > defined in barrier.h, which is imported from Linux. This version is
> > modified to remove the include statement of asm-generic/barrier.h,
> > which
> > is not available in u-boot or required.
> 
> nits: U-Boot
> 

Fixed.

> > 
> > Signed-off-by: Lukas Auer 
> > ---
> > Checkpatch reports style errors in barrier.h. I did not fix them,
> > because I imported the file from Linux. Is that the correct way to
> > handle this?
> > 
> 
> I think this is OK.
> 

Ok, I will keep it as is.

Thanks,
Lukas

> >  arch/riscv/include/asm/barrier.h | 67
> > 
> >  arch/riscv/include/asm/io.h  | 11 ++
> >  2 files changed, 71 insertions(+), 7 deletions(-)
> >  create mode 100644 arch/riscv/include/asm/barrier.h
> > 
> 
> Reviewed-by: Bin Meng 
> 
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 11/30] riscv: fix use of incorrectly sized variables

[Auer, Lukas]

Hi Rick and Bin,

On Tue, 2018-10-23 at 13:52 +0800, Rick Chen wrote:
> > > -static void _exit_trap(int code, uint epc, struct pt_regs *regs)
> > > +static void _exit_trap(ulong code, ulong epc, struct pt_regs
> > > *regs)
> > >  {
> > > static const char * const exception_code[] = {
> > > "Instruction address misaligned",
> > > @@ -70,6 +70,6 @@ static void _exit_trap(int code, uint epc,
> > > struct pt_regs
> > 
> > *regs)
> > > "Load address misaligned"
> > > };
> > > 
> > > -   printf("exception code: %d , %s , epc %08x , ra %08lx\n",
> > > +   printf("exception code: %ld , %s , epc %016lx , ra
> > > %016lx\n",
> > 
> > We should not print 16 digits on a RV32 system.
> 
> Hi Lukas
> 
> Maybe you can try as below :
> 
> printf("exception code: %ld , %s , epc %p , ra %p\n",
>   code, exception_code[code], (void *)epc, (void *)regs->ra);
> 
> Rick
> 

Thanks, I will update the patch to use this format string in v2.

Thanks,
Lukas

> > 
> > > code, exception_code[code], epc, regs->ra);
> > >  }
> > > --
> > 
> > Others look good to me.
> > 
> > Regards,
> > Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 09/30] riscv: move target selection into separate file

[Auer, Lukas]

Hi Bin,

On Mon, 2018-10-22 at 15:22 +0800, Bin Meng wrote:
> Hi Lukas,
> 
> On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer
>  wrote:
> > 
> > Move the target selection into a separate file (Kconfig.board) to
> > avoid
> > clutter once we support more boards.
> > 
> > Signed-off-by: Lukas Auer 
> > ---
> > 
> >  arch/riscv/Kconfig   | 17 ++---
> >  arch/riscv/Kconfig.board | 14 ++
> >  2 files changed, 16 insertions(+), 15 deletions(-)
> >  create mode 100644 arch/riscv/Kconfig.board
> > 
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index ce07fb4b55..10d17a0e18 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -4,21 +4,6 @@ menu "RISC-V architecture"
> >  config SYS_ARCH
> > default "riscv"
> > 
> > -choice
> > -   prompt "Target select"
> > -   optional
> > -
> > -config TARGET_AX25_AE350
> > -   bool "Support ax25-ae350"
> > -
> > -config TARGET_QEMU_VIRT
> > -   bool "Support QEMU Virt Board"
> > -
> > -endchoice
> > -
> > -source "board/AndesTech/ax25-ae350/Kconfig"
> > -source "board/emulation/qemu-riscv/Kconfig"
> > -
> >  choice
> > prompt "Base ISA"
> > default ARCH_RV32I
> > @@ -72,4 +57,6 @@ config 32BIT
> >  config 64BIT
> > bool
> > 
> > +source "arch/riscv/Kconfig.board"
> > +
> 
> I am OK with moving board one to a separate file, though it looks no
> other arch uses scuh convention in U-Boot :)
> 
> However, with this change, it lost the capability of overriding an
> architecture defined Kconfig option at board level.
> 
> I have a patch @
> 
http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commitdiff;h=5a650689410482907a37f77b2a4257d81bb4daa2
> to express such capability.
> 

This should be easy to fix by just moving the source statement, right?

Thanks,
Lukas

> >  endmenu
> > diff --git a/arch/riscv/Kconfig.board b/arch/riscv/Kconfig.board
> > new file mode 100644
> > index 00..fcada760c8
> > --- /dev/null
> > +++ b/arch/riscv/Kconfig.board
> > @@ -0,0 +1,14 @@
> > +choice
> > +   prompt "Target select"
> > +   optional
> > +
> > +config TARGET_AX25_AE350
> > +   bool "Support ax25-ae350"
> > +
> > +config TARGET_QEMU_VIRT
> > +   bool "Support QEMU Virt Board"
> > +
> > +endchoice
> > +
> > +source "board/AndesTech/ax25-ae350/Kconfig"
> > +source "board/emulation/qemu-riscv/Kconfig"
> > --
> 
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 09/30] riscv: move target selection into separate file

[Auer, Lukas]

Hi Bin,

On Thu, 2018-10-25 at 10:50 +0800, Bin Meng wrote:
> On Tue, Oct 23, 2018 at 10:48 AM Rick Chen 
> wrote:
> > 
> > > > Subject: Re: [PATCH 09/30] riscv: move target selection into
> > > > separate file
> > > > 
> > > > Hi Lukas,
> > > > 
> > > > On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer <
> > > > lukas.a...@aisec.fraunhofer.de>
> > > > wrote:
> > > > > 
> > > > > Move the target selection into a separate file
> > > > > (Kconfig.board) to
> > > > > avoid clutter once we support more boards.
> > > > > 
> > > > > Signed-off-by: Lukas Auer 
> > > > > ---
> > > > > 
> > > > >  arch/riscv/Kconfig   | 17 ++---
> > > > >  arch/riscv/Kconfig.board | 14 ++
> > > > >  2 files changed, 16 insertions(+), 15 deletions(-)  create
> > > > > mode
> > > > > 100644 arch/riscv/Kconfig.board
> > > > > 
> > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index
> > > > > ce07fb4b55..10d17a0e18 100644
> > > > > --- a/arch/riscv/Kconfig
> > > > > +++ b/arch/riscv/Kconfig
> > > > > @@ -4,21 +4,6 @@ menu "RISC-V architecture"
> > > > >  config SYS_ARCH
> > > > > default "riscv"
> > > > > 
> > > > > -choice
> > > > > -   prompt "Target select"
> > > > > -   optional
> > > > > -
> > > > > -config TARGET_AX25_AE350
> > > > > -   bool "Support ax25-ae350"
> > > > > -
> > > > > -config TARGET_QEMU_VIRT
> > > > > -   bool "Support QEMU Virt Board"
> > > > > -
> > > > > -endchoice
> > > > > -
> > > > > -source "board/AndesTech/ax25-ae350/Kconfig"
> > > > > -source "board/emulation/qemu-riscv/Kconfig"
> > > > > -
> > > > >  choice
> > > > > prompt "Base ISA"
> > > > > default ARCH_RV32I
> > > > > @@ -72,4 +57,6 @@ config 32BIT
> > > > >  config 64BIT
> > > > > bool
> > > > > 
> > > > > +source "arch/riscv/Kconfig.board"
> > > > > +
> > > > 
> > > > I am OK with moving board one to a separate file, though it
> > > > looks no other arch
> > > > uses scuh convention in U-Boot :)
> > > > 
> > 
> > Though no other arch use Kconfig.board here.
> > Because RISC-V is an open architechture.
> > Maybe separate board option from Kconfig to Kconfig.board is an
> > good idea.
> > 
> 
> I suggest we keep current kconfig structure for now to be in
> consistent with other archs.
> 
> Regards,
> Bin

I previously worked with U-Boot on ARM processors. The ARM Kconfig is
already quite crowded with both board and ARM specific configuration
entries. That's the reason behind this patch, trying to avoid mixing
both processor and board specific entries.
At the moment, there are only two boards and therefore no real need for
this patch, so I am fine with dropping this patch.

Thanks,
Lukas
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: mvebu: Move PCI(e) MBUS window to end of RAM

[Владислав]

Ok, no problem

Tested-by: VlaoMao 



Stefan Roese  23 октября 2018 г. 13:21:52 написал:


On 23.10.18 12:19, Владислав wrote:

I checked this patch, and seems to work for me on clearfog base and silicon
motion pcie video card


Thats good, thanks for checking. Could you please send a
proper git "Tested-by" tag then?

Thanks,
Stefan



Stefan Roese  22 октября 2018 г. 15:21:20 написал:


With patch 49b23e035d96 (pci: mvebu: Increase size of PCIe default mapping)
the mapping size for each PCI(e) controller was increased from 32MiB to
128MiB. This leads to problems on boards with multiple PCIe slots / ports
which are unable to map all PCIe ports, e.g. the Armada-XP theadorable:

DRAM:  2 GiB (667 MHz, 64-bit, ECC not enabled)
SF: Detected m25p128 with page size 256 Bytes, erase size 256 KiB, total 16 MiB
Cannot add window '4:f8', conflicts with another window
PCIe unable to add mbus window for mem at f000+0800
Model: Marvell Armada XP theadorable

This patch moves the base address for the PCI(e) memory spaces from
0xe800 to the end of SDRAM (clipped to a max of 0xc000 right now).
This gives move room and flexibility for PCI(e) mappings.

Signed-off-by: Stefan Roese 
Cc: VlaoMao 
---
  arch/arm/mach-mvebu/dram.c | 8 +++-
  arch/arm/mach-mvebu/include/mach/cpu.h | 4 +++-
  2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-mvebu/dram.c b/arch/arm/mach-mvebu/dram.c
index 68383d06a2..b5671b8c20 100644
--- a/arch/arm/mach-mvebu/dram.c
+++ b/arch/arm/mach-mvebu/dram.c
@@ -33,8 +33,6 @@ struct sdram_addr_dec {
  #define REG_CPUCS_WIN_WIN0_CS(x)  (((x) & 0x3) << 2)
  #define REG_CPUCS_WIN_SIZE(x) (((x) & 0xff) << 24)

-#define SDRAM_SIZE_MAX 0xc000
-
  #define SCRUB_MAGIC   0xbeefdead

  #define SCRB_XOR_UNIT 0
@@ -275,8 +273,8 @@ int dram_init(void)
 * address space left for the internal registers etc.
 */
size += mvebu_sdram_bs(i);
-   if (size > SDRAM_SIZE_MAX)
-   size = SDRAM_SIZE_MAX;
+   if (size > MVEBU_SDRAM_SIZE_MAX)
+   size = MVEBU_SDRAM_SIZE_MAX;
}

for (; i < CONFIG_NR_DRAM_BANKS; i++) {
@@ -312,7 +310,7 @@ int dram_init_banksize(void)

/* Clip the banksize to 1GiB if it exceeds the max size */
size += gd->bd->bi_dram[i].size;
-   if (size > SDRAM_SIZE_MAX)
+   if (size > MVEBU_SDRAM_SIZE_MAX)
mvebu_sdram_bs_set(i, 0x4000);
}

diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
b/arch/arm/mach-mvebu/include/mach/cpu.h
index d1042100a8..85d7dd1610 100644
--- a/arch/arm/mach-mvebu/include/mach/cpu.h
+++ b/arch/arm/mach-mvebu/include/mach/cpu.h
@@ -68,10 +68,12 @@ enum {
MVEBU_SOC_UNKNOWN,
  };

+#define MVEBU_SDRAM_SIZE_MAX   0xc000
+
  /*
   * Default Device Address MAP BAR values
   */
-#define MBUS_PCI_MEM_BASE  0xE800
+#define MBUS_PCI_MEM_BASE  MVEBU_SDRAM_SIZE_MAX
  #define MBUS_PCI_MEM_SIZE (128 << 20)
  #define MBUS_PCI_IO_BASE  0xF110
  #define MBUS_PCI_IO_SIZE  (64 << 10)
--
2.19.1






Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de



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

[U-Boot] [PATCH] Kconfig: Convert CONFIG_IMX_WATCHDOG to Kconfig

[Xiaoliang Yang]

Move this option to Kconfig and tidy up the config file of eight
boards which use it.

Signed-off-by: Xiaoliang Yang 
---
 configs/aristainetos2_defconfig   |1 +
 configs/aristainetos2b_defconfig  |1 +
 configs/aristainetos_defconfig|1 +
 configs/dh_imx6_defconfig |1 +
 configs/display5_defconfig|1 +
 configs/display5_factory_defconfig|1 +
 configs/ge_bx50v3_defconfig   |1 +
 configs/kp_imx6q_tpc_defconfig|1 +
 configs/mx53ppd_defconfig |1 +
 configs/tqma6s_wru4_mmc_defconfig |1 +
 configs/warp_defconfig|1 +
 drivers/watchdog/Kconfig  |7 +++
 include/configs/aristainetos-common.h |3 ---
 include/configs/dh_imx6.h |2 --
 include/configs/display5.h|2 --
 include/configs/ge_bx50v3.h   |2 --
 include/configs/kp_imx6q_tpc.h|2 --
 include/configs/mx53ppd.h |2 --
 include/configs/tqma6_wru4.h  |2 --
 include/configs/warp.h|2 --
 scripts/config_whitelist.txt  |1 -
 21 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/configs/aristainetos2_defconfig b/configs/aristainetos2_defconfig
index 5044a59..c55e39c 100644
--- a/configs/aristainetos2_defconfig
+++ b/configs/aristainetos2_defconfig
@@ -50,4 +50,5 @@ CONFIG_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_VIDEO=y
 # CONFIG_VIDEO_SW_CURSOR is not set
+CONFIG_IMX_WATCHDOG=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/aristainetos2b_defconfig b/configs/aristainetos2b_defconfig
index 6641382..95c3063 100644
--- a/configs/aristainetos2b_defconfig
+++ b/configs/aristainetos2b_defconfig
@@ -50,4 +50,5 @@ CONFIG_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_VIDEO=y
 # CONFIG_VIDEO_SW_CURSOR is not set
+CONFIG_IMX_WATCHDOG=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/aristainetos_defconfig b/configs/aristainetos_defconfig
index 6a31ee6..4082b12 100644
--- a/configs/aristainetos_defconfig
+++ b/configs/aristainetos_defconfig
@@ -49,4 +49,5 @@ CONFIG_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_VIDEO=y
 # CONFIG_VIDEO_SW_CURSOR is not set
+CONFIG_IMX_WATCHDOG=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/dh_imx6_defconfig b/configs/dh_imx6_defconfig
index 2cb7164..92b2377 100644
--- a/configs/dh_imx6_defconfig
+++ b/configs/dh_imx6_defconfig
@@ -59,4 +59,5 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0525
 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
 CONFIG_CI_UDC=y
 CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_IMX_WATCHDOG=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/display5_defconfig b/configs/display5_defconfig
index 697138e..ab5ec59 100644
--- a/configs/display5_defconfig
+++ b/configs/display5_defconfig
@@ -75,3 +75,4 @@ CONFIG_MII=y
 CONFIG_MXC_UART=y
 CONFIG_SPI=y
 CONFIG_MXC_SPI=y
+CONFIG_IMX_WATCHDOG=y
diff --git a/configs/display5_factory_defconfig 
b/configs/display5_factory_defconfig
index 5962b64..5d1c746 100644
--- a/configs/display5_factory_defconfig
+++ b/configs/display5_factory_defconfig
@@ -82,4 +82,5 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x1b67
 CONFIG_USB_GADGET_PRODUCT_NUM=0x4000
 CONFIG_CI_UDC=y
 CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_IMX_WATCHDOG=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/ge_bx50v3_defconfig b/configs/ge_bx50v3_defconfig
index 729377d..c907779 100644
--- a/configs/ge_bx50v3_defconfig
+++ b/configs/ge_bx50v3_defconfig
@@ -41,5 +41,6 @@ CONFIG_CMD_E1000=y
 CONFIG_MII=y
 CONFIG_SPI=y
 CONFIG_MXC_SPI=y
+CONFIG_IMX_WATCHDOG=y
 CONFIG_OF_LIBFDT=y
 # CONFIG_EFI_LOADER is not set
diff --git a/configs/kp_imx6q_tpc_defconfig b/configs/kp_imx6q_tpc_defconfig
index 84ca1ce..5ebbe1d 100644
--- a/configs/kp_imx6q_tpc_defconfig
+++ b/configs/kp_imx6q_tpc_defconfig
@@ -40,4 +40,5 @@ CONFIG_MII=y
 CONFIG_IMX_THERMAL=y
 CONFIG_USB=y
 CONFIG_USB_STORAGE=y
+CONFIG_IMX_WATCHDOG=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/mx53ppd_defconfig b/configs/mx53ppd_defconfig
index 7be5c04..34328fd 100644
--- a/configs/mx53ppd_defconfig
+++ b/configs/mx53ppd_defconfig
@@ -37,4 +37,5 @@ CONFIG_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_VIDEO=y
 # CONFIG_VIDEO_SW_CURSOR is not set
+CONFIG_IMX_WATCHDOG=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/tqma6s_wru4_mmc_defconfig 
b/configs/tqma6s_wru4_mmc_defconfig
index df4c87e..c1be704 100644
--- a/configs/tqma6s_wru4_mmc_defconfig
+++ b/configs/tqma6s_wru4_mmc_defconfig
@@ -65,4 +65,5 @@ CONFIG_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_IMX_WATCHDOG=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/warp_defconfig b/configs/warp_defconfig
index 6a9c91e..63eee27 100644
--- a/configs/warp_defconfig
+++ b/configs/warp_defconfig
@@ -37,4 +37,5 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0525
 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
 CONFIG_CI_UDC=y
 CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_IMX_WATCHDOG=y
 CONFIG_OF_LIBFDT=y
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index d5dbc80..988c702 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -117,4 +117,11 @@ 

Re: [U-Boot] sunxi: add custom board

[Giulio Benetti]

Hello Maxime,

Il 24/10/2018 19:59, Maxime Ripard ha scritto:

On Wed, Oct 24, 2018 at 03:59:56PM +0200, Giulio Benetti wrote:

Hello Jagan and Maxime,

I've looked around a lot, but I can't find a way to use the board/sunxi:
http://git.denx.de/?p=u-boot.git;a=tree;f=board/sunxi;h=304ee6b4cc8e075759d3bd0beb250b56f6901702;hb=HEAD

to fit what we need.

We have 5 gpios that control the max current setting on
current-driver for Backlight biasing shunt kathode resistor, and I
don't know where to place the code to set those pins.

I would like to avoid to create another new board if possible, since
board/sunxi has everything we need to make our board operative.
In general, is there some sort of __weak__ hooks to be used to extend an
existing board?
Because I understand that probably you wouldn't add this code I'm talking
about inside board/sunxi.

This request is done with idea to upstream patch for this board.

Can you help me?


If that's backlight related, maybe you can just create a new backlight
driver?


If it makes sense for sure we can.

But please can you take a look at the schematics of current-driver with 
mosfets biasing power?

https://pasteboard.co/HK4ChzF.png
As you can see we bias BKL_K (Backlight Kathode) to slightly influence 
the shunt(R81+R76).

I don't know how it could be useful for the others.

We use that to handle different displays with the same board(A20 based).

So does it make sense to write a driver?
And if yes, I would think about adding:
backlight_current.c under u-boot/drivers/video
or another option could be to write a driver under:
u-boot/drivers/power

What do you think?

We only need a road to follow to be upstreamed later.

Thanks a lot
Best regards
--
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] net: e1000: support 'write_hwaddr' in DM

[Joseph Hershberger]

Hi Hannes,

> -Original Message-
> From: Hannes Schmelzer 
> Sent: Thursday, October 11, 2018 12:42 AM
> To: u-boot@lists.denx.de
> Cc: Hannes Schmelzer ; Joseph
> Hershberger 
> Subject: [PATCH] net: e1000: support 'write_hwaddr' in DM
> 
> This commit ports the existing (non-DM) function for writing the MAC-
> address into the shadow ram (and flash) for DM.
> 
> Signed-off-by: Hannes Schmelzer 
> ---

This seems to break many boards. Please build boards that failed and address 
the break.

https://travis-ci.org/jhershbe/u-boot/builds/444858982

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

Re: [U-Boot] [PATCH 2/3] net: phy: aquantia: add firmware loading support

[Jeremy Gebben]

On Wed, Oct 24, 2018 at 3:34 AM Prabhakar Kushwaha
 wrote:
>
>
> > -Original Message-
> > From: U-Boot  On Behalf Of Jeremy
> > Gebben
> > Sent: Wednesday, September 19, 2018 3:20 AM
> > To: u-boot@lists.denx.de
> > Cc: Joe Hershberger ; Shaohui Xie
> > ; York Sun 
> > Subject: [U-Boot] [PATCH 2/3] net: phy: aquantia: add firmware loading
> > support
> >
> > Aquantia phys have firmware that can be loaded automatically from storage
> > directly attached to the phy or via MDIO commands.
> > Add support for loading firmware from either a file or a raw location on an
> > MMC device.
> >
>   We  have integrated your patch series.  Now we have one AQR FW:  
> AQR-G3_v4.2.C-AQR.cld
> How to flash this FW on Aquantia card ?

Not sure what you are asking here.

My patches don't provide support for programming the persistent
storage attached to the aquantia phy on NXP's development boards.

To program the firmware, put the AQR-G3_v4.2.C-AQR.cld file in a
directory on a partition that uboot can read.  Then set
PHY_AQUANTIA_FW_PART to the parition code (for example "0:2")  and
PHY_AQUANTIA_FW_NAME to the full path to the firmware file (for
example "/boot/AQR-G3_v4.2.C-AQR.cld")

If you #define DEBUG in aquantia.c, you should get some output as the
code loads the file and verifies checksums.

> When my u-boot will boot, does Firmware programming process will trigger by 
> itself or do we need to execute some command on u-boot prompt ?

Firmware programming should happen automatically when the phy is configured.

Does that help?

Jeremy


>
> --pk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] sunxi: add custom board

[Giulio Benetti]

Hello Jagan and Maxime,

I've looked around a lot, but I can't find a way to use the board/sunxi:
http://git.denx.de/?p=u-boot.git;a=tree;f=board/sunxi;h=304ee6b4cc8e075759d3bd0beb250b56f6901702;hb=HEAD

to fit what we need.

We have 5 gpios that control the max current setting on current-driver 
for Backlight biasing shunt kathode resistor, and I don't know where to 
place the code to set those pins.


I would like to avoid to create another new board if possible, since 
board/sunxi has everything we need to make our board operative.
In general, is there some sort of __weak__ hooks to be used to extend an 
existing board?
Because I understand that probably you wouldn't add this code I'm 
talking about inside board/sunxi.


This request is done with idea to upstream patch for this board.

Can you help me?

Thanks in advance
Best regards
--
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register

[Auer, Lukas]

Hi Rick,

On Thu, 2018-10-25 at 11:28 +0800, Rick Chen wrote:
> Bin Meng  於 2018年10月25日 週四 上午11:16寫道：
> > 
> > Hi Rick,
> > 
> > On Thu, Oct 25, 2018 at 11:11 AM Rick Chen 
> > wrote:
> > > 
> > > Bin Meng  於 2018年10月25日 週四 上午10:33寫道：
> > > > 
> > > > Hi Rick,
> > > > 
> > > > On Thu, Oct 25, 2018 at 9:20 AM Andes 
> > > > wrote:
> > > > > 
> > > > > From: Rick Chen 
> > > > > 
> > > > > ax25-ae350 use CONFIG_OF_BOARD which allow the board to
> > > > > override the fdt address. And prior_stage_fdt_address offer
> > > > > a temporary memory address to keep the dtb address which was
> > > > > passed from loader(gdb) to u-boot with a1.
> > > > 
> > > > nits: U-Boot
> > > > 
> > > > > 
> > > > > Signed-off-by: Rick Chen 
> > > > > Cc: Greentime Hu 
> > > > > ---
> > > > >  board/AndesTech/ax25-ae350/ax25-ae350.c | 3 ++-
> > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > index 5f4ca0f..d343453 100644
> > > > > --- a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > +++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > > @@ -14,6 +14,7 @@
> > > > > 
> > > > >  DECLARE_GLOBAL_DATA_PTR;
> > > > > 
> > > > > +extern phys_addr_t prior_stage_fdt_address;
> > > > >  /*
> > > > >   * Miscellaneous platform dependent initializations
> > > > >   */
> > > > > @@ -66,7 +67,7 @@ ulong board_flash_get_legacy(ulong base,
> > > > > int banknum, flash_info_t *info)
> > > > > 
> > > > >  void *board_fdt_blob_setup(void)
> > > > >  {
> > > > > -   void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > > +   void **ptr = (void *)_stage_fdt_address;
> > > > > if (fdt_magic(*ptr) == FDT_MAGIC)
> > > > > return (void *)*ptr;
> > > > > 
> > > > > --
> > > > 
> > > > board_fdt_blob_setup() should be completely removed. Instead
> > > > the
> > > > simple fix should be add CONFIG_OF_PRIOR_STAGE to your board
> > > > defconfig
> > > > files.
> > > > 
> > > 
> > > Hi Bin
> > > 
> > > I have tried to switch from CONFIG_OF_BOARD to
> > > CONFIG_OF_PRIOR_STAGE.
> > > 
> > > But it will lost the function
> > > that dtb will be pre-burned into designated flash location,
> > > when U-Boot was booting from flash.
> > > 
> > 
> > I don't get it. Do you mean on ae350 board, the DTB is pre-flashed
> > on the flash?
> > 
> 
> Yes
> On ae350 board, the DTB is pre-flashed on the flash in booting from
> rom case.
> 
> u-boot boot from ram case:
> CONFIG_OF_PRIOR_STAGE can achieve u-boot boot from ram and dtb was
> passed by loader with a1(0xf).
> 
> u-boot boot from rom case:
> If DTB is pre-flashed on the flash 0x800f (This address can be
> dynamically changed)
> But no one assign a1=0x800f000, how can be gd->fdt_blob changed to
> 0x800f000.
> I am wondering about that ?
> 
> 0xf is ram space
> 0x800f is flash rom space
> 
> Rick
> 

If I understood it correctly and looking at the documentation in U-Boot 
you have two boot methods. The ae350 can either boot from the e-bios or
from external SPI ROM. The e-bios loads U-Boot into RAM, starts it, and
passes the build-in device tree to it. If the ae350 boots from SPI ROM,
the software stored in it will be the first thing to run. There is
therefore nothing, which can pass the built-in device tree to software.
Is this correct?

Would it makes sense to use CONFIG_OF_PRIOR_STAGE and boot using the 
e-bios by default? The SPI ROM could then be documented in the README
with instructions on how to use the built-in device tree.
Another option would be to only use the device tree from U-Boot.

Thanks,
Lukas
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/6] sunxi: extend SPL header to propagate DRAM size and H6 3GiB DRAM support

[Maxime Ripard]

On Thu, Oct 25, 2018 at 05:23:01PM +0800, Icenowy Zheng wrote:
> This series tries to solve three issues we currently have on
> Allwinner boards:
> - The DRAM sizing routine can only cope with power-of-two sized DRAM.
> - The DRAM sizing routine steps through all DRAM, possibly hitting secure
>   memory.
> - The SPL header versioning is quite strict and tends to break every time
>   we need to update it.
> - On some Allwinner SoCs the maximum supported DRAM size of the DRAM
>   controller is bigger than the accessible DRAM size of the CPU.
> 
> So Andre Przywara adapted something along the lines of semantic
> versioning[1], where we can add backwards-compatible changes to the SPL
> header without breaking every tool.
> 
> The second patch and the third patches introduces the version schema and
> does necessary refactors, then the fourth and the fifth patches prepare
> for 3GiB memory support. The sixth patch finally enables the SPL header
> to store the the DRAM size, and let U-Boot binary check which range is
> accessible when picking the data.
> 
> The first patch is a prepare for the other patches, as without it newly
> introduced code will make H6 SPL overflow, which makes the patchset not
> possible to test, as the only available 3GiB DRAM device now is the
> 3GiB version of Pine H64 sample.

For the whole series,
Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] x86: tsc: Add support for APL soc

[Bernhard Messerklinger]

Signed-off-by: Bernhard Messerklinger 
---

 drivers/timer/tsc_timer.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/timer/tsc_timer.c b/drivers/timer/tsc_timer.c
index da7c812908..b2a982812a 100644
--- a/drivers/timer/tsc_timer.c
+++ b/drivers/timer/tsc_timer.c
@@ -64,6 +64,8 @@ static struct freq_desc freq_desc_tables[] = {
8, 93300, 9, 88900, 87500 } },
/* Ivybridge */
{ 6, 0x3a, 2, { 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
+   /* Intel Atom processor E3900 series */
+   { 6, 0x5c, 2, { 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
 };
 
 static int match_cpu(u8 family, u8 model)
-- 
2.19.1


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

[U-Boot] [PATCH 2/2] spi: ich-spi: Add DT spi-max-frequency support

[Bernhard Messerklinger]

Signed-off-by: Bernhard Messerklinger 
---

 drivers/spi/ich.c | 7 +++
 drivers/spi/ich.h | 1 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
index d84bbdb2e5..4ec107d323 100644
--- a/drivers/spi/ich.c
+++ b/drivers/spi/ich.c
@@ -213,6 +213,10 @@ static int ich_init_controller(struct udevice *dev,
return -EINVAL;
}
 
+   /* Check devicetree for max frequency */
+   if (plat->max_speed)
+   ctlr->max_speed = plat->max_speed;
+
debug("ICH SPI: Version ID %d detected at %p, speed %ld\n",
  plat->ich_version, ctlr->base, ctlr->max_speed);
 
@@ -784,6 +788,9 @@ static int ich_spi_ofdata_to_platdata(struct udevice *dev)
plat->lockdown = fdtdec_get_bool(gd->fdt_blob, node,
 "intel,spi-lock-down");
 
+   plat->max_speed = fdtdec_get_uint(gd->fdt_blob, node,
+ "spi-max-frequency", 0);
+
return ret;
 }
 
diff --git a/drivers/spi/ich.h b/drivers/spi/ich.h
index 5e3ac2d2c2..85ddc171cc 100644
--- a/drivers/spi/ich.h
+++ b/drivers/spi/ich.h
@@ -214,6 +214,7 @@ struct ich_spi_platdata {
enum ich_version ich_version;   /* Controller version*/
bool lockdown;  /* lock down controller settings? */
unsigned long base; /* PCI device BAR */
+   unsigned long max_speed;
 };
 
 struct ich_spi_priv {
-- 
2.19.1


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

[U-Boot] [PATCH 1/2] spi: ich-spi: Add APL support

[Bernhard Messerklinger]

Signed-off-by: Bernhard Messerklinger 
---

 drivers/spi/ich.c | 168 +-
 drivers/spi/ich.h |  46 -
 2 files changed, 178 insertions(+), 36 deletions(-)

diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
index 03531a8c0c..d84bbdb2e5 100644
--- a/drivers/spi/ich.c
+++ b/drivers/spi/ich.c
@@ -110,6 +110,34 @@ static int ich9_can_do_33mhz(struct udevice *dev)
return speed == 1;
 }
 
+/* @return speed register bit mask from speed */
+static int ich_speed_to_mask(enum ich_version ver, unsigned long speed)
+{
+   int size = 0;
+   const unsigned long *list = NULL;
+   int i;
+   int act = 0;
+   int64_t diff = 0;
+
+   if (ver == ICHV_9) {
+   size = ARRAY_SIZE(ich9_speed);
+   list = ich9_speed;
+   } else if (ver == ICUV_APL) {
+   size = ARRAY_SIZE(pcu_apl_speed);
+   list = pcu_apl_speed;
+   }
+
+   for (i = 1; i < size; i++) {
+   diff = speed - list[i];
+   if (diff >= 0) {
+   if (diff < (speed - list[act]))
+   act = i;
+   }
+   }
+
+   return act;
+}
+
 static int ich_init_controller(struct udevice *dev,
   struct ich_spi_platdata *plat,
   struct ich_spi_priv *ctlr)
@@ -117,9 +145,14 @@ static int ich_init_controller(struct udevice *dev,
ulong sbase_addr;
void *sbase;
 
-   /* SBASE is similar */
-   pch_get_spi_base(dev->parent, _addr);
-   sbase = (void *)sbase_addr;
+   if (plat->ich_version == ICHV_7 ||
+   plat->ich_version == ICHV_9) {
+   /* SBASE is similar */
+   pch_get_spi_base(dev->parent, _addr);
+   sbase = (void *)sbase_addr;
+   } else {
+   sbase = (void *)plat->base;
+   }
debug("%s: sbase=%p\n", __func__, sbase);
 
if (plat->ich_version == ICHV_7) {
@@ -136,6 +169,7 @@ static int ich_init_controller(struct udevice *dev,
ctlr->bbar = offsetof(struct ich7_spi_regs, bbar);
ctlr->preop = offsetof(struct ich7_spi_regs, preop);
ctlr->base = ich7_spi;
+   ctlr->max_speed = 2000;
} else if (plat->ich_version == ICHV_9) {
struct ich9_spi_regs *ich9_spi = sbase;
 
@@ -153,20 +187,38 @@ static int ich_init_controller(struct udevice *dev,
ctlr->bcr = offsetof(struct ich9_spi_regs, bcr);
ctlr->pr = _spi->pr[0];
ctlr->base = ich9_spi;
+   if (ich9_can_do_33mhz(dev))
+   ctlr->max_speed = 3300;
+   else
+   ctlr->max_speed = 2000;
+   } else if (plat->ich_version == ICUV_APL) {
+   struct pcu_apl_spi_regs *pcu_spi = sbase;
+
+   ctlr->opmenu = offsetof(struct pcu_apl_spi_regs, opmenu);
+   ctlr->menubytes = sizeof(pcu_spi->opmenu);
+   ctlr->optype = offsetof(struct pcu_apl_spi_regs, optype);
+   ctlr->addr = offsetof(struct pcu_apl_spi_regs, faddr);
+   ctlr->data = offsetof(struct pcu_apl_spi_regs, fdata);
+   ctlr->databytes = sizeof(pcu_spi->fdata);
+   ctlr->status = offsetof(struct pcu_apl_spi_regs, ssfs);
+   ctlr->control = offsetof(struct pcu_apl_spi_regs, ssfc);
+   ctlr->speed = ctlr->control + 2;
+   ctlr->preop = offsetof(struct pcu_apl_spi_regs, preop);
+   ctlr->pr = _spi->pr[0];
+   ctlr->base = pcu_spi;
+   ctlr->max_speed = 12000;
} else {
debug("ICH SPI: Unrecognised ICH version %d\n",
  plat->ich_version);
return -EINVAL;
}
 
-   /* Work out the maximum speed we can support */
-   ctlr->max_speed = 2000;
-   if (plat->ich_version == ICHV_9 && ich9_can_do_33mhz(dev))
-   ctlr->max_speed = 3300;
debug("ICH SPI: Version ID %d detected at %p, speed %ld\n",
  plat->ich_version, ctlr->base, ctlr->max_speed);
 
-   ich_set_bbar(ctlr, 0);
+   if (plat->ich_version == ICHV_7 ||
+   plat->ich_version == ICHV_9)
+   ich_set_bbar(ctlr, 0);
 
return 0;
 }
@@ -193,6 +245,10 @@ static void spi_lock_down(struct ich_spi_platdata *plat, 
void *sbase)
struct ich9_spi_regs *ich9_spi = sbase;
 
setbits_le16(_spi->hsfs, HSFS_FLOCKDN);
+   } else if (plat->ich_version == ICUV_APL) {
+   struct pcu_apl_spi_regs *ipcu_spi = sbase;
+
+   setbits_le16(_spi->hsfs, HSFS_FLOCKDN);
}
 }
 
@@ -208,6 +264,10 @@ static bool spi_lock_status(struct ich_spi_platdata *plat, 
void *sbase)
struct ich9_spi_regs *ich9_spi = sbase;
 
lock = readw(_spi->hsfs) & HSFS_FLOCKDN;
+   } else 

Re: [U-Boot] [PATCH v2 5/6] sunxi: add Kconfig option for the maximum accessible DRAM

[André Przywara]

On 10/25/18 10:23 AM, Icenowy Zheng wrote:
> Allwinner 64-bit SoCs can use 4GiB DRAM chip, however their memory map
> has only allocated 3GiB for DRAM, so only 3GiB of the DRAM is
> accessible.
> 
> Add a Kconfig option for the maximum accessible DRAM.
> 
> For A80 it should be a much higher value (8GiB), but as I have no A80
> device to test and originally U-Boot only supports 2GiB DRAM on A80, it
> currently still falls under the 2GiB situation.
> 
> Signed-off-by: Icenowy Zheng 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
> This used to be in another patchset targeting 3GiB support.
> 
> Changes in v2:
> - Add H6 to SoCs that support 3GiB DRAM.
> 
>  arch/arm/mach-sunxi/Kconfig | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 764337c643..e9e1b4bc0e 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -140,6 +140,14 @@ config MACH_SUNXI_H3_H5
>   select SUNXI_GEN_SUN6I
>   select SUPPORT_SPL
>  
> +# TODO: try out A80's 8GiB DRAM space
> +config SUNXI_DRAM_MAX_SIZE
> + hex
> + default 0xC000 if MACH_SUN50I
> + default 0xC000 if MACH_SUN50I_H5
> + default 0xC000 if MACH_SUN50I_H6
> + default 0x8000
> +
>  choice
>   prompt "Sunxi SoC Variant"
>   optional
> 

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

Re: [U-Boot] [PATCH v2 1/6] sunxi: disable Pine A64 model detection code on other boards

[André Przywara]

On 10/25/18 10:23 AM, Icenowy Zheng wrote:
> The Pine A64 Plus/non-Plus model detection code is now built on all
> 64-bit ARM SoCs, even if the code cannot be triggered when H5/H6 is in
> use.
> 
> Disable them when the board is Pine A64 by adding a Kconfig option that
> is only selected on Pine A64.
> 
> On GCC 7.3.1 this makes the size of the function reduces 184 bytes, and
> saves a 104 byte strstr() function, then makes SPL on H6 succeed to
> build.
> 
> Signed-off-by: Icenowy Zheng 

Reviewed-by: Andre Przywara 

Thanks!
Andre.

> ---
> This used to be a independently sent patch.
> 
> Changes in v2:
> - Added a Kconfig option to restrict the code on only Pine A64.
> 
>  arch/arm/mach-sunxi/Kconfig   | 10 ++
>  board/sunxi/board.c   |  5 -
>  configs/pine64_plus_defconfig |  1 +
>  3 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 686f38fec4..764337c643 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -970,4 +970,14 @@ config SPL_SPI_SUNXI
> sunxi SPI Flash. It uses the same method as the boot ROM, so does
> not need any extra configuration.
>  
> +config PINE64_DT_SELECTION
> + bool "Enable Pine64 device tree selection code"
> + depends on MACH_SUN50I
> + help
> +   The original Pine A64 and Pine A64+ are similar but different
> +   boards and can be differed by the DRAM size. Pine A64 has
> +   512MiB DRAM, and Pine A64+ has 1GiB or 2GiB. By selecting this
> +   option, the device tree selection code specific to Pine64 which
> +   utilizes the DRAM size will be enabled.
> +
>  endif
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index d1d7f9f400..49f5695566 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -820,6 +820,7 @@ int board_fit_config_name_match(const char *name)
>  #endif
>   };
>  
> +#ifdef CONFIG_PINE64_DT_SELECTION
>  /* Differentiate the two Pine64 board DTs by their DRAM size. */
>   if (strstr(name, "-pine64") && strstr(cmp_str, "-pine64")) {
>   if ((gd->ram_size > 512 * 1024 * 1024))
> @@ -829,5 +830,7 @@ int board_fit_config_name_match(const char *name)
>   } else {
>   return strcmp(name, cmp_str);
>   }
> -}
>  #endif
> + return strcmp(name, cmp_str);
> +#endif
> +}
> diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
> index 14ccc9ba05..a5b87b9063 100644
> --- a/configs/pine64_plus_defconfig
> +++ b/configs/pine64_plus_defconfig
> @@ -3,6 +3,7 @@ CONFIG_ARCH_SUNXI=y
>  CONFIG_SPL=y
>  CONFIG_MACH_SUN50I=y
>  CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y
> +CONFIG_PINE64_DT_SELECTION=y
>  CONFIG_NR_DRAM_BANKS=1
>  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
>  # CONFIG_CMD_FLASH is not set
> 

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

Re: [U-Boot] [PATCH v2 4/6] sunxi: map DRAM part with 3G size

[André Przywara]

On 10/25/18 10:23 AM, Icenowy Zheng wrote:
> All Allwinner 64-bit SoCs now are known to be able to access 3GiB of
> external DRAM, however the size of DRAM part in the MMU translation
> table is still 2GiB.
> 
> Change the size of DRAM part in MMU table to 3GiB.
> 
> Signed-off-by: Icenowy Zheng 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
> This used to be in another patchset targeting 3GiB support.
> 
> No changes in v2.
> 
>  arch/arm/mach-sunxi/board.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index d22a84ea6b..b74eaf2a0e 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -52,7 +52,7 @@ static struct mm_region sunxi_mem_map[] = {
>   /* RAM */
>   .virt = 0x4000UL,
>   .phys = 0x4000UL,
> - .size = 0x8000UL,
> + .size = 0xC000UL,
>   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
>PTE_BLOCK_INNER_SHARE
>   }, {
> 

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

Re: [U-Boot] [PATCH v2 0/6] sunxi: extend SPL header to propagate DRAM size and H6 3GiB DRAM support

[Icenowy Zheng]

于 2018年10月25日 GMT+08:00 下午6:15:11, "André Przywara"  写到:
>On 10/25/18 10:23 AM, Icenowy Zheng wrote:
>
>Hi Icenowy,
>
>thanks for picking this up, resending and adapting this!
>
>> This series tries to solve three issues we currently have on
>> Allwinner boards:
>> - The DRAM sizing routine can only cope with power-of-two sized DRAM.
>> - The DRAM sizing routine steps through all DRAM, possibly hitting
>secure
>>   memory.
>> - The SPL header versioning is quite strict and tends to break every
>time
>>   we need to update it.
>> - On some Allwinner SoCs the maximum supported DRAM size of the DRAM
>>   controller is bigger than the accessible DRAM size of the CPU.
>> 
>> So Andre Przywara adapted something along the lines of semantic
>> versioning[1], where we can add backwards-compatible changes to the
>SPL
>> header without breaking every tool.
>> 
>> The second patch and the third patches introduces the version schema
>and
>> does necessary refactors, then the fourth and the fifth patches
>prepare
>> for 3GiB memory support. The sixth patch finally enables the SPL
>header
>> to store the the DRAM size, and let U-Boot binary check which range
>is
>> accessible when picking the data.
>
>Out of curiosity: Do you know whether one can play around with the DRAM
>controller's mapping registers to make the upper GB of a 4GB DRAM
>accessible (so map 3-4GB to 0xc000 instead of 2-3GB)? To use
>something like bank switching, maybe? This is not really aimed at any
>upstream OS, I am just curious from a hacker's perspective.
>
>> The first patch is a prepare for the other patches, as without it
>newly
>> introduced code will make H6 SPL overflow, which makes the patchset
>not
>> possible to test, as the only available 3GiB DRAM device now is the
>> 3GiB version of Pine H64 sample.
>
>I guess this tight memory situation is also the reason that you
>disabled
>PSCI_RESET in the defconfig? Do you know what causes the bigger memory
>consumption for H6 boards? Is that the DRAM driver? For A64 I end up at
>a rather comfortable 30KB SPL with my GCC 7.3.0 these days.

Yes, the DRAM driver is ~2.5KiB larger.

>
>And just in case: If you run into size issues while testing and
>developing, you can always disable ARMV8_SPL_EXCEPTION_VECTORS to gain
>some additional KBs. I don't really want to make this permanent in a
>defconfig, though.
>
>Cheers,
>Andre.
>
>> 
>> Andre Przywara (3):
>>   sunxi: Extend SPL header versioning
>>   sunxi: board.c: refactor SPL header checks
>>   sunxi: store DRAM size in SPL header
>> 
>> Icenowy Zheng (3):
>>   sunxi: disable Pine A64 model detection code on other boards
>>   sunxi: map DRAM part with 3G size
>>   sunxi: add Kconfig option for the maximum accessible DRAM
>> 
>>  arch/arm/include/asm/arch-sunxi/spl.h | 22 +---
>>  arch/arm/mach-sunxi/Kconfig   | 18 +++
>>  arch/arm/mach-sunxi/board.c   |  2 +-
>>  board/sunxi/board.c   | 74
>++-
>>  configs/pine64_plus_defconfig |  1 +
>>  5 files changed, 97 insertions(+), 20 deletions(-)
>> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/6] sunxi: extend SPL header to propagate DRAM size and H6 3GiB DRAM support

[André Przywara]

On 10/25/18 10:23 AM, Icenowy Zheng wrote:

Hi Icenowy,

thanks for picking this up, resending and adapting this!

> This series tries to solve three issues we currently have on
> Allwinner boards:
> - The DRAM sizing routine can only cope with power-of-two sized DRAM.
> - The DRAM sizing routine steps through all DRAM, possibly hitting secure
>   memory.
> - The SPL header versioning is quite strict and tends to break every time
>   we need to update it.
> - On some Allwinner SoCs the maximum supported DRAM size of the DRAM
>   controller is bigger than the accessible DRAM size of the CPU.
> 
> So Andre Przywara adapted something along the lines of semantic
> versioning[1], where we can add backwards-compatible changes to the SPL
> header without breaking every tool.
> 
> The second patch and the third patches introduces the version schema and
> does necessary refactors, then the fourth and the fifth patches prepare
> for 3GiB memory support. The sixth patch finally enables the SPL header
> to store the the DRAM size, and let U-Boot binary check which range is
> accessible when picking the data.

Out of curiosity: Do you know whether one can play around with the DRAM
controller's mapping registers to make the upper GB of a 4GB DRAM
accessible (so map 3-4GB to 0xc000 instead of 2-3GB)? To use
something like bank switching, maybe? This is not really aimed at any
upstream OS, I am just curious from a hacker's perspective.

> The first patch is a prepare for the other patches, as without it newly
> introduced code will make H6 SPL overflow, which makes the patchset not
> possible to test, as the only available 3GiB DRAM device now is the
> 3GiB version of Pine H64 sample.

I guess this tight memory situation is also the reason that you disabled
PSCI_RESET in the defconfig? Do you know what causes the bigger memory
consumption for H6 boards? Is that the DRAM driver? For A64 I end up at
a rather comfortable 30KB SPL with my GCC 7.3.0 these days.

And just in case: If you run into size issues while testing and
developing, you can always disable ARMV8_SPL_EXCEPTION_VECTORS to gain
some additional KBs. I don't really want to make this permanent in a
defconfig, though.

Cheers,
Andre.

> 
> Andre Przywara (3):
>   sunxi: Extend SPL header versioning
>   sunxi: board.c: refactor SPL header checks
>   sunxi: store DRAM size in SPL header
> 
> Icenowy Zheng (3):
>   sunxi: disable Pine A64 model detection code on other boards
>   sunxi: map DRAM part with 3G size
>   sunxi: add Kconfig option for the maximum accessible DRAM
> 
>  arch/arm/include/asm/arch-sunxi/spl.h | 22 +---
>  arch/arm/mach-sunxi/Kconfig   | 18 +++
>  arch/arm/mach-sunxi/board.c   |  2 +-
>  board/sunxi/board.c   | 74 ++-
>  configs/pine64_plus_defconfig |  1 +
>  5 files changed, 97 insertions(+), 20 deletions(-)
> 

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

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

[Stefano Babic]

Hi Tom,

please pull from u-boot-imx (tag: u-boot-imx-20181024). It contains the
fixes we discussed:

- fix build i.MX8 for Travis
- fix warnings (Warp)
- fix warning in imx8 DTS

The following changes since commit 0a60a81ba3860946551cb79aa6486aa076e357f3:

  Kconfig: sandbox: enable cmd_avb and dependencies (2018-10-07 13:34:19
-0400)

are available in the Git repository at:

  git://www.denx.de/git/u-boot-imx.git tags/u-boot-imx-20181025

for you to fetch changes up to 3c28576bb0f0990d699fd330089412e620706941:

  arm: dts: imx8qxp: fix build warining (2018-10-25 11:48:13 +0200)


Merged imx8 architecture, fix build for imx8 + warnings


Anatolij Gustschin (3):
  imx8: cpu: add function for reading FEC MAC from fuse
  imx8: cpu: add uclass based CPU driver
  i2c: imx_lpi2c: fix typo and register base address format

Bernhard Messerklinger (1):
  serial: mxc: Add match string for i.mx6 quad/dual lite serial

Breno Matheus Lima (7):
  doc: imx: reorganize i.MX documentation
  doc: imx: Move SPD related info to the appropriate doc
  doc: imx: mkimage: reorganize i.MX mkimage documentation
  doc: imx: Reorganize i.MX SoC common documentation
  doc: imx: hab: Reorganize High Assurance Boot documentation
  doc: imx: misc: Reorganize miscellaneous documentation
  doc: imx: Improve i.MX documentation naming

Dan Cimpoca (1):
  board: ge: bx50v3: fix initialization of i2c bus0

Fabien Lahoudere (1):
  board: ge: bx50v3: Change maintainer

Fabio Estevam (5):
  pico-imx7d: Make SPL binary fit into 64kB
  pico-imx7d: Add USB Host support
  colibri_imx7: prime get_ram_size() using imx_ddr_size()
  configs: mx7: Remove CONFIG_DBG_MONITOR
  warp7: MAINTAINERS: Add an entry for warp7_bl33_defconfig

Ian Ray (2):
  board: ge: bx50v3: correct LDB clock
  board: ge: bx50v3: b{4,6}50v3 modeline

Marcel Ziswiler (1):
  imx: mx7: fix potential overflow in imx_ddr_size()

Marek Vasut (3):
  arm: imx: mx5: Make videoskip available on MX5
  arm: mx5: Add LDB clock config code
  arm: mx5: Add M53Menlo board

Otavio Salvador (2):
  pico-imx6ul, pico-imx7d: Use eMMC user partition by default
  pico-imx6ul, pico-imx7d: Enable USB and PXE boot support

Peng Fan (35):
  dt-bindings: pinctrl: add i.MX8QXP pads definition
  dt-bindings: clock: dt-bindings: pinctrl: add i.MX8QXP clocks
definition
  dt-bindings: soc: add i.MX8QXP pm and rsrc definition
  imx8: add scfw macro definition
  imx: add Kconfig entry for i.MX8QXP
  arm: build mach-imx for i.MX8
  arm: global_data: add scu_dev for i.MX8
  misc: add i.MX8 misc driver
  misc: imx8: add scfw api impementation
  imx: boot_mode: Add FLEXSPI boot entry
  imx8: add imx-regs header file
  imx8: pins: include i.MX8QXP pin header when CONFIG_IMX8QXP defined
  imx: add i.MX8 cpu type
  armv8: add cpu core helper functions
  imx8: add basic cpu support
  imx8: add boot device detection
  imx8: implement mmc_get_env_dev
  imx8: add mmu and dram related functions
  imx8: add arch_cpu_init arch_cpu_init_dm
  imx8: add iomux configuration api
  imx8: add dummy clock
  gpio: mxc_gpio: add support for i.MX8
  pinctrl: Add pinctrl driver for i.MX8
  power: Add power domain driver for i.MX8
  clk: imx: add clk driver for i.MX8QXP
  serial_lpuart: Update lpuart driver to support i.MX8
  serial: lpuart: support uclass clk api
  mmc: fsl_esdhc: add uclass clk support
  arm: dts: introduce dtsi for i.MX8QXP
  imx: add i.MX8QXP MEK board support
  tools: add i.MX8/8X image support
  arm: imx: include imx8image support
  imx: imx8qxp_mek: update to build image in U-Boot
  imx: mkimage: avoid stop CI when required files not exists
  arm: dts: imx8qxp: fix build warining

Rui Miguel Silva (4):
  imx: mx7: avoid some initialization if low level is skipped
  optee: adjust dependencies and default values for dram
  warp7: include: configs: set skip low level init
  warp7: configs: add bl33 defconfig

Sébastien Szymanski (1):
  ARM: opos6ul: make the board boot again

Xiaoliang Yang (1):
  Kconfig: Convert CONFIG_IMX_WATCHDOG to Kconfig

Ye Li (2):
  serial: lpuart: Enable RX and TX FIFO
  fsl_esdhc: Update usdhc driver to support i.MX8

 arch/arm/Kconfig  |   8 ++
 arch/arm/Makefile |   2 +-
 arch/arm/dts/Makefile |   2 +
 arch/arm/dts/fsl-imx8-ca35.dtsi   |  66 +
 arch/arm/dts/fsl-imx8dx.dtsi  | 499
+
 arch/arm/dts/fsl-imx8dxp.dtsi |  11

[U-Boot] [PATCH] x86: Fix car_uninit weak symbol definition

[Bin Meng]

Since commit 80df194f0165 ("x86: detect unsupported relocation types"),
an error message is seen on QEMU x86 target during boot:

do_elf_reloc_fixups32: unsupported relocation type 0x1 at fff841f0, offset = 
0xfff00087
do_elf_reloc_fixups32: unsupported relocation type 0x2 at fff841f8, offset = 
0xfff00091

Check offset 0xfff00087 and 0xfff00091 in the u-boot ELF image,

fff00087  000df401 R_386_32     car_uninit
fff00091  000df402 R_386_PC32   car_uninit

we see R_386_32 and R_386_PC32 relocation type is generated for
symbol car_uninit, which is declared as a weak symbol in start.S.

However the actual weak symbol implementation ends up nowhere. As
we can see below, it's *UND*.

$ objdump -t u-boot | grep car_uninit
  w  *UND*   car_uninit

With this fix, it is normal now.

$ objdump -t u-boot | grep car_uninit
fff00094  wF .text.start0001 car_uninit

Reported-by: Hannes Schmelzer 
Signed-off-by: Bin Meng 
---

 arch/x86/cpu/start.S | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S
index e1f634f..30fa7de 100644
--- a/arch/x86/cpu/start.S
+++ b/arch/x86/cpu/start.S
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 .section .text.start
 .code32
@@ -184,13 +185,8 @@ board_init_f_r_trampoline:
movl%eax, %esp
 
/* See if we need to disable CAR */
-.weak  car_uninit
-   movl$car_uninit, %eax
-   cmpl$0, %eax
-   jz  1f
-
callcar_uninit
-1:
+
/* Re-enter U-Boot by calling board_init_f_r() */
callboard_init_f_r
 
@@ -199,6 +195,10 @@ die:
jmp die
hlt
 
+WEAK(car_uninit)
+   ret
+ENDPROC(car_uninit)
+
 blank_idt_ptr:
.word   0   /* limit */
.long   0   /* base */
-- 
2.7.4

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

[U-Boot] [question] need help with mmc-env-addr

[Frank Wunderlich]

Hi,

i hope questions are also allowed on this mailing list :)

i try to port environment-saving from 2014-04 to 2018-11...and in 2014 i see 
that an offset of 1 MB is added to address when booting from SD-Card. I have 
the boot-device-detection ready, but i'm unsure how to implement the 
env-adress...
 
i know i can override mmc_get_env_addr (because it's weak), but original 
function uses an inline-function mmc_offset which i cannot use outside (without 
removing the inline-statement and/or adding function to mmc.h).

this is the function call i'm talking about:

https://github.com/frank-w/u-boot/blob/bpi-r2_v2/env/mmc.c#L113

here i want to add it:

https://github.com/frank-w/u-boot/blob/bpi-r2_v2/board/mediatek/mt7623/mt7623_rfb.c

and this is how it's implemented in 2014 uboot:

https://github.com/BPI-SINOVOIP/BPI-R2-bsp/commit/0b7eb9e24a66d405970aff1b466bb50b21f925b8

especially this mmc_offset is differently implemented depending on 
CONFIG_IS_ENABLED(OF_CONTROL)...if this is set, there are accesses to 
Device-tree...imho i have not (yet) enabled this (what does it exactly?).

if this flag is not used i want to implement the function like this:

int mmc_get_env_addr(struct mmc *mmc, int copy, u32 *env_addr)
{
s64 offset = CONFIG_ENV_OFFSET;
#ifdef CONFIG_ENV_OFFSET_REDUND
if (copy)
offset = CONFIG_ENV_OFFSET_REDUND;
#endif
if (offset < 0)
offset += mmc->capacity;

//If mmc is SD, then set offset 1Mb
if(mmc_get_boot_dev() == 1)
*env_addr = offset + 0x10;
else
*env_addr = offset;

return 0;
}

maybe the question "why adding an additional offset??" this is because on 
SD-Card on BPI-R2 there are additional headers for booting (MMC_BOOT and 
BRLYT-signature). for more see here: 
https://www.fw-web.de/dokuwiki/doku.php?id=en/bpi-r2/storage#extended_boot-headers

i hope i have explained enough...

what is the best way to implement it? imho propagate the mmc_offset-functions 
to outside but this changes common code (why is this function "hidden" and 
can/should this be changed?). i don't want to create too much redundant code 
(reimplement mmc_offset) and the 1MB-offset should also be defined in 
board-specific area (in opposition to 2014-code).

regards Frank
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Kconfig: Convert CONFIG_IMX_WATCHDOG to Kconfig

[Lukasz Majewski]

Hi Xiaoliang,

> Move this option to Kconfig and tidy up the config file of eight
> boards which use it.

Reviewed-by: Łukasz Majewski 

> 
> Signed-off-by: Xiaoliang Yang 
> ---
>  configs/aristainetos2_defconfig   |1 +
>  configs/aristainetos2b_defconfig  |1 +
>  configs/aristainetos_defconfig|1 +
>  configs/dh_imx6_defconfig |1 +
>  configs/display5_defconfig|1 +
>  configs/display5_factory_defconfig|1 +
>  configs/ge_bx50v3_defconfig   |1 +
>  configs/kp_imx6q_tpc_defconfig|1 +
>  configs/mx53ppd_defconfig |1 +
>  configs/tqma6s_wru4_mmc_defconfig |1 +
>  configs/warp_defconfig|1 +
>  drivers/watchdog/Kconfig  |7 +++
>  include/configs/aristainetos-common.h |3 ---
>  include/configs/dh_imx6.h |2 --
>  include/configs/display5.h|2 --
>  include/configs/ge_bx50v3.h   |2 --
>  include/configs/kp_imx6q_tpc.h|2 --
>  include/configs/mx53ppd.h |2 --
>  include/configs/tqma6_wru4.h  |2 --
>  include/configs/warp.h|2 --
>  scripts/config_whitelist.txt  |1 -
>  21 files changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/configs/aristainetos2_defconfig
> b/configs/aristainetos2_defconfig index 5044a59..c55e39c 100644
> --- a/configs/aristainetos2_defconfig
> +++ b/configs/aristainetos2_defconfig
> @@ -50,4 +50,5 @@ CONFIG_USB=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_VIDEO=y
>  # CONFIG_VIDEO_SW_CURSOR is not set
> +CONFIG_IMX_WATCHDOG=y
>  CONFIG_OF_LIBFDT=y
> diff --git a/configs/aristainetos2b_defconfig
> b/configs/aristainetos2b_defconfig index 6641382..95c3063 100644
> --- a/configs/aristainetos2b_defconfig
> +++ b/configs/aristainetos2b_defconfig
> @@ -50,4 +50,5 @@ CONFIG_USB=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_VIDEO=y
>  # CONFIG_VIDEO_SW_CURSOR is not set
> +CONFIG_IMX_WATCHDOG=y
>  CONFIG_OF_LIBFDT=y
> diff --git a/configs/aristainetos_defconfig
> b/configs/aristainetos_defconfig index 6a31ee6..4082b12 100644
> --- a/configs/aristainetos_defconfig
> +++ b/configs/aristainetos_defconfig
> @@ -49,4 +49,5 @@ CONFIG_USB=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_VIDEO=y
>  # CONFIG_VIDEO_SW_CURSOR is not set
> +CONFIG_IMX_WATCHDOG=y
>  CONFIG_OF_LIBFDT=y
> diff --git a/configs/dh_imx6_defconfig b/configs/dh_imx6_defconfig
> index 2cb7164..92b2377 100644
> --- a/configs/dh_imx6_defconfig
> +++ b/configs/dh_imx6_defconfig
> @@ -59,4 +59,5 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0525
>  CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
>  CONFIG_CI_UDC=y
>  CONFIG_USB_GADGET_DOWNLOAD=y
> +CONFIG_IMX_WATCHDOG=y
>  CONFIG_OF_LIBFDT=y
> diff --git a/configs/display5_defconfig b/configs/display5_defconfig
> index 697138e..ab5ec59 100644
> --- a/configs/display5_defconfig
> +++ b/configs/display5_defconfig
> @@ -75,3 +75,4 @@ CONFIG_MII=y
>  CONFIG_MXC_UART=y
>  CONFIG_SPI=y
>  CONFIG_MXC_SPI=y
> +CONFIG_IMX_WATCHDOG=y
> diff --git a/configs/display5_factory_defconfig
> b/configs/display5_factory_defconfig index 5962b64..5d1c746 100644
> --- a/configs/display5_factory_defconfig
> +++ b/configs/display5_factory_defconfig
> @@ -82,4 +82,5 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x1b67
>  CONFIG_USB_GADGET_PRODUCT_NUM=0x4000
>  CONFIG_CI_UDC=y
>  CONFIG_USB_GADGET_DOWNLOAD=y
> +CONFIG_IMX_WATCHDOG=y
>  CONFIG_OF_LIBFDT=y
> diff --git a/configs/ge_bx50v3_defconfig b/configs/ge_bx50v3_defconfig
> index 729377d..c907779 100644
> --- a/configs/ge_bx50v3_defconfig
> +++ b/configs/ge_bx50v3_defconfig
> @@ -41,5 +41,6 @@ CONFIG_CMD_E1000=y
>  CONFIG_MII=y
>  CONFIG_SPI=y
>  CONFIG_MXC_SPI=y
> +CONFIG_IMX_WATCHDOG=y
>  CONFIG_OF_LIBFDT=y
>  # CONFIG_EFI_LOADER is not set
> diff --git a/configs/kp_imx6q_tpc_defconfig
> b/configs/kp_imx6q_tpc_defconfig index 84ca1ce..5ebbe1d 100644
> --- a/configs/kp_imx6q_tpc_defconfig
> +++ b/configs/kp_imx6q_tpc_defconfig
> @@ -40,4 +40,5 @@ CONFIG_MII=y
>  CONFIG_IMX_THERMAL=y
>  CONFIG_USB=y
>  CONFIG_USB_STORAGE=y
> +CONFIG_IMX_WATCHDOG=y
>  CONFIG_OF_LIBFDT=y
> diff --git a/configs/mx53ppd_defconfig b/configs/mx53ppd_defconfig
> index 7be5c04..34328fd 100644
> --- a/configs/mx53ppd_defconfig
> +++ b/configs/mx53ppd_defconfig
> @@ -37,4 +37,5 @@ CONFIG_USB=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_VIDEO=y
>  # CONFIG_VIDEO_SW_CURSOR is not set
> +CONFIG_IMX_WATCHDOG=y
>  CONFIG_OF_LIBFDT=y
> diff --git a/configs/tqma6s_wru4_mmc_defconfig
> b/configs/tqma6s_wru4_mmc_defconfig index df4c87e..c1be704 100644
> --- a/configs/tqma6s_wru4_mmc_defconfig
> +++ b/configs/tqma6s_wru4_mmc_defconfig
> @@ -65,4 +65,5 @@ CONFIG_USB=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_USB_HOST_ETHER=y
>  CONFIG_USB_ETHER_SMSC95XX=y
> +CONFIG_IMX_WATCHDOG=y
>  CONFIG_OF_LIBFDT=y
> diff --git a/configs/warp_defconfig b/configs/warp_defconfig
> index 6a9c91e..63eee27 100644
> --- a/configs/warp_defconfig
> +++ b/configs/warp_defconfig
> @@ -37,4 +37,5 @@ 

Re: [U-Boot] [PATCH] imx: mkimage: avoid stop CI when required files not exists

[Stefano Babic]

Hi Peng,

On 25/10/18 10:45, Peng Fan wrote:
> Hi Stefano,
> 
>> -Original Message-
>> From: Stefano Babic [mailto:sba...@denx.de]
>> Sent: 2018年10月25日 16:35
>> To: Peng Fan ; Stefano Babic ; Anatolij
>> Gustschin 
>> Cc: u-boot@lists.denx.de
>> Subject: Re: [U-Boot] [PATCH] imx: mkimage: avoid stop CI when required files
>> not exists
>>
>> On 25/10/18 10:27, Peng Fan wrote:
>>>
>>>
 -Original Message-
 From: Stefano Babic [mailto:sba...@denx.de]
 Sent: 2018年10月25日 16:26
 To: Peng Fan ; Anatolij Gustschin 
 Cc: sba...@denx.de; u-boot@lists.denx.de
 Subject: Re: [U-Boot] [PATCH] imx: mkimage: avoid stop CI when
 required files not exists

 Hi Peng,

 On 25/10/18 03:14, Peng Fan wrote:
>
>
>> -Original Message-
>> From: Anatolij Gustschin [mailto:ag...@denx.de]
>> Sent: 2018年10月25日 7:44
>> To: Peng Fan 
>> Cc: sba...@denx.de; u-boot@lists.denx.de
>> Subject: Re: [U-Boot] [PATCH] imx: mkimage: avoid stop CI when
>> required files not exists
>>
>> Hi Peng,
>>
>> On Wed, 24 Oct 2018 09:49:04 +
>> Peng Fan peng@nxp.com wrote:
>> ...
>>> --- /dev/null
>>> +++ b/tools/imx8_cntr_image.sh
>>> @@ -0,0 +1,32 @@
>>> +#!/bin/sh
>>> +# SPDX-License-Identifier: GPL-2.0+ # # script to generate FIT
>>> +image source for K3 Family boards with # ATF, OPTEE, SPL and
>>> +multiple device trees (given on the command line).
>>> +# Inspired from board/sunxi/mksunxi_fit_atf.sh
>>
>> Please drop this comment, it doesn't describe what the script is
>> actually
 doing.
>
> Thanks. Fix in V2.

 I wanted to send my PR as soon as possible to Tom. I didn't want to
 block i.MX8 merge just for this, and I merged V1 and sent PR.
>>>
>>> No, please not use v1.
>>>
>>> V2 patch will be out soon. It is under CI test. I'll send out now.
>>
>> Ok, I drop from server and I wait for it.
> 
> V2 has been out. CI: https://travis-ci.org/MrVan/u-boot/builds/446043677 
> There is a build warning because of dts, I also send a follow up patch to fix
> dts build warning, but not kick a new CI build, because it is only i.mx8qxp 
> related.
> In my local, with ahah image removed.
> ./tools/buildman/buildman imx8qxp_mek mx6sabresd
> Building current source for 2 boards (2 threads, 2 jobs per thread)
> 200 /2  mx6sabresd
> 
> I think it should be fine to be merged into your tree for the v2 and dts fix 
> now.

Fully agree, I merged both, it is fine.

I prepare a new PR.

Regards,
Stefano

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

Re: [U-Boot] [PATCH v2 15/18] ram: MediaTek: add DDR3 driver for MT7629 SoC

[Ryder Lee]

On Wed, 2018-10-24 at 21:30 -0600, Simon Glass wrote:
> On 12 October 2018 at 01:01, Ryder Lee  wrote:
> > This patch adds a DDR3 driver for MT7629 SoC.
> >
> > Signed-off-by: Wu Zou 
> > Signed-off-by: Ryder Lee 
> > ---
> >  drivers/ram/Makefile   |   1 +
> >  drivers/ram/mediatek/Makefile  |   7 +
> >  drivers/ram/mediatek/ddr3-mt7629.c | 766 
> > +
> >  3 files changed, 774 insertions(+)
> >  create mode 100644 drivers/ram/mediatek/Makefile
> >  create mode 100644 drivers/ram/mediatek/ddr3-mt7629.c
> 
> Reviewed-by: Simon Glass 
> 
> Thoughts below.
> 
> [..]
> 
> > +#define DDRPHY_PLL10x
> > +#define DDRPHY_PLL20x0004
> 
> Why not use a C struct for these registers?

These are copy-n-paste from our SDK. I've considered converting these
into C struct but it will take me a while. Just let it be.

But, I could do that if you insist.

> [..]
> 
> > +   writel(0x400, priv->dramc_ao + DRAMC_MRS);
> > +   writel(0x1d7000, priv->dramc_ao + DRAMC_MRS);
> > +   writel(0x1, priv->dramc_ao + DRAMC_SPCMD);
> > +   writel(0x0, priv->dramc_ao + DRAMC_SPCMD);
> > +   udelay(100);
> 
> Are these delays specified in a datasheet? Why did you chose 100?
> Perhaps add an enum for this value? Is there a way to check for when
> the hardware is ready, e.g. by reading a registers in a loop?

Rule of thumb. There is no registers to read here, but I can try to
reduce the delay time.

> [..]
> 
> > +static int mtk_ddr3_probe(struct udevice *dev)
> > +{
> > +   struct mtk_ddr3_priv *priv = dev_get_priv(dev);
> > +
> > +   priv->emi = dev_read_addr_index(dev, 0);
> > +   if (priv->emi == FDT_ADDR_T_NONE)
> > +   return -EINVAL;
> > +
> > +   priv->ddrphy = dev_read_addr_index(dev, 1);
> > +   if (priv->ddrphy == FDT_ADDR_T_NONE)
> > +   return -EINVAL;
> > +
> > +   priv->dramc_ao = dev_read_addr_index(dev, 2);
> > +   if (priv->dramc_ao == FDT_ADDR_T_NONE)
> > +   return -EINVAL;
> > +
> > +#ifdef CONFIG_SPL_BUILD
> > +   int ret;
> > +
> > +   ret = clk_get_by_index(dev, 0, >phy);
> > +   if (ret)
> > +   return ret;
> > +
> > +   ret = clk_get_by_index(dev, 1, >phy_mux);
> > +   if (ret)
> > +   return ret;
> > +
> > +   ret = clk_get_by_index(dev, 2, >mem);
> > +   if (ret)
> > +   return ret;
> > +
> > +   ret = clk_get_by_index(dev, 3, >mem_mux);
> > +   if (ret)
> > +   return ret;
> 
> Do you have phandles for these clocks? I only worry that it is a bit
> brittle to have them numbered.

Yes. I choose clk_get_by_index() here as I stripped the 'clock-names'
via CONFIG_OF_SPL_REMOVE_PROPS to reduce the size .

Also I don't understand why we cannot use clk_set_defaults() in
pre-relocate state?


Ryder

> > +
> > +   ret = mtk_ddr3_init(dev);
> > +   if (ret)
> > +   return ret;
> > +#endif
> > +   return 0;
> > +}
> > +
> 
> Regards,
> Simon


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

[U-Boot] [PATCH V2 4/6] doc: uImage.FIT: signature.txt: add option padding

[Philippe Reynes]

Signed-off-by: Philippe Reynes 
Reviewed-by: Simon Glass 
---
 doc/uImage.FIT/signature.txt | 3 +++
 1 file changed, 3 insertions(+)

Changelog:
v2:
- no change

diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt
index a765722..bfff6fd 100644
--- a/doc/uImage.FIT/signature.txt
+++ b/doc/uImage.FIT/signature.txt
@@ -106,6 +106,9 @@ When the image is signed, the following properties are 
optional:
 
 - comment: Additional information about the signer or image
 
+- padding: The padding algorithm, it may be pkcs-1.5 or pss,
+   if no value is provided we assume pkcs-1.5
+
 For config bindings (see Signed Configurations below), the following
 additional properties are optional:
 
-- 
2.7.4

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

[U-Boot] [PATCH V2 6/6] test: vboot: add padding pss for rsa signature

[Philippe Reynes]

The padding pss is now supported for rsa signature.
This add test with padding pss on vboot test.

Signed-off-by: Philippe Reynes 
---
 test/py/tests/test_vboot.py | 10 +++---
 test/py/tests/vboot/sign-configs-sha1-pss.its   | 46 +
 test/py/tests/vboot/sign-configs-sha256-pss.its | 46 +
 test/py/tests/vboot/sign-images-sha1-pss.its| 44 +++
 test/py/tests/vboot/sign-images-sha256-pss.its  | 44 +++
 5 files changed, 186 insertions(+), 4 deletions(-)
 create mode 100644 test/py/tests/vboot/sign-configs-sha1-pss.its
 create mode 100644 test/py/tests/vboot/sign-configs-sha256-pss.its
 create mode 100644 test/py/tests/vboot/sign-images-sha1-pss.its
 create mode 100644 test/py/tests/vboot/sign-images-sha256-pss.its

Changelog:
v2:
- new patch in the serie
- add vboot for pss padding (thanks Simon Glass)

diff --git a/test/py/tests/test_vboot.py b/test/py/tests/test_vboot.py
index e9cbd57..f427c69 100644
--- a/test/py/tests/test_vboot.py
+++ b/test/py/tests/test_vboot.py
@@ -126,7 +126,7 @@ def test_vboot(u_boot_console):
 handle.write(struct.pack(">I", size))
 return struct.unpack(">I", total_size)[0]
 
-def test_with_algo(sha_algo):
+def test_with_algo(sha_algo, padding):
 """Test verified boot with the given hash algorithm.
 
 This is the main part of the test code. The same procedure is followed
@@ -144,7 +144,7 @@ def test_vboot(u_boot_console):
 
 # Build the FIT, but don't sign anything yet
 cons.log.action('%s: Test FIT with signed images' % sha_algo)
-make_fit('sign-images-%s.its' % sha_algo)
+make_fit('sign-images-%s%s.its' % (sha_algo , padding))
 run_bootm(sha_algo, 'unsigned images', 'dev-', True)
 
 # Sign images with our dev keys
@@ -226,8 +226,10 @@ def test_vboot(u_boot_console):
 # afterwards.
 old_dtb = cons.config.dtb
 cons.config.dtb = dtb
-test_with_algo('sha1')
-test_with_algo('sha256')
+test_with_algo('sha1','')
+test_with_algo('sha1','-pss')
+test_with_algo('sha256','')
+test_with_algo('sha256','-pss')
 finally:
 # Go back to the original U-Boot with the correct dtb.
 cons.config.dtb = old_dtb
diff --git a/test/py/tests/vboot/sign-configs-sha1-pss.its 
b/test/py/tests/vboot/sign-configs-sha1-pss.its
new file mode 100644
index 000..3c3ab20
--- /dev/null
+++ b/test/py/tests/vboot/sign-configs-sha1-pss.its
@@ -0,0 +1,46 @@
+/dts-v1/;
+
+/ {
+   description = "Chrome OS kernel image with one or more FDT blobs";
+   #address-cells = <1>;
+
+   images {
+   kernel@1 {
+   data = /incbin/("test-kernel.bin");
+   type = "kernel_noload";
+   arch = "sandbox";
+   os = "linux";
+   compression = "none";
+   load = <0x4>;
+   entry = <0x8>;
+   kernel-version = <1>;
+   hash@1 {
+   algo = "sha1";
+   };
+   };
+   fdt@1 {
+   description = "snow";
+   data = /incbin/("sandbox-kernel.dtb");
+   type = "flat_dt";
+   arch = "sandbox";
+   compression = "none";
+   fdt-version = <1>;
+   hash@1 {
+   algo = "sha1";
+   };
+   };
+   };
+   configurations {
+   default = "conf@1";
+   conf@1 {
+   kernel = "kernel@1";
+   fdt = "fdt@1";
+   signature@1 {
+   algo = "sha1,rsa2048";
+   padding = "pss";
+   key-name-hint = "dev";
+   sign-images = "fdt", "kernel";
+   };
+   };
+   };
+};
diff --git a/test/py/tests/vboot/sign-configs-sha256-pss.its 
b/test/py/tests/vboot/sign-configs-sha256-pss.its
new file mode 100644
index 000..8e33510
--- /dev/null
+++ b/test/py/tests/vboot/sign-configs-sha256-pss.its
@@ -0,0 +1,46 @@
+/dts-v1/;
+
+/ {
+   description = "Chrome OS kernel image with one or more FDT blobs";
+   #address-cells = <1>;
+
+   images {
+   kernel@1 {
+   data = /incbin/("test-kernel.bin");
+   type = "kernel_noload";
+   arch = "sandbox";
+   os = "linux";
+   compression = "none";
+   load = <0x4>;
+   entry = <0x8>;
+   kernel-version = <1>;
+   hash@1 {
+   

[U-Boot] [PATCH V2 5/6] configs: sandbox: enable padding pss for rsa signature

[Philippe Reynes]

Signed-off-by: Philippe Reynes 
---
 configs/sandbox_defconfig | 1 +
 1 file changed, 1 insertion(+)

Changelog:
v2:
- new patch in the serie

diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 2ce336f..b2565e1 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -6,6 +6,7 @@ CONFIG_NR_DRAM_BANKS=1
 CONFIG_ANDROID_BOOT_IMAGE=y
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
+CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_BOOTSTAGE=y
 CONFIG_BOOTSTAGE_REPORT=y
-- 
2.7.4

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

[U-Boot] [PATCH V2 2/6] rsa: add a structure for the padding

[Philippe Reynes]

The rsa signature use a padding algorithm. By default, we use the
padding pkcs-1.5. In order to add some new padding algorithm, we
add a padding framework to manage several padding algorithm.
The choice of the padding is done in the file .its.

Signed-off-by: Philippe Reynes 
Reviewed-by: Simon Glass 
---
 common/image-fit.c   |  5 +
 common/image-sig.c   | 29 ++
 include/image.h  | 16 +++
 include/u-boot/rsa.h | 13 
 lib/rsa/rsa-sign.c   | 15 +++---
 lib/rsa/rsa-verify.c | 57 ++--
 tools/image-host.c   |  4 
 7 files changed, 116 insertions(+), 23 deletions(-)

Changelog:
v2:
- no change

diff --git a/common/image-fit.c b/common/image-fit.c
index 8d39a24..ac901e1 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -165,6 +165,7 @@ static void fit_image_print_data(const void *fit, int 
noffset, const char *p,
uint8_t *value;
int value_len;
char *algo;
+   const char *padding;
int required;
int ret, i;
 
@@ -184,6 +185,10 @@ static void fit_image_print_data(const void *fit, int 
noffset, const char *p,
printf(" (required)");
printf("\n");
 
+   padding = fdt_getprop(fit, noffset, "padding", NULL);
+   if (padding)
+   printf("%s  %s padding: %s\n", p, type, padding);
+
ret = fit_image_hash_get_value(fit, noffset, ,
   _len);
printf("%s  %s value:   ", p, type);
diff --git a/common/image-sig.c b/common/image-sig.c
index 5a269d3..b7ca657 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -71,6 +71,13 @@ struct crypto_algo crypto_algos[] = {
 
 };
 
+struct padding_algo padding_algos[] = {
+   {
+   .name = "pkcs-1.5",
+   .verify = padding_pkcs_15_verify,
+   },
+};
+
 struct checksum_algo *image_get_checksum_algo(const char *full_name)
 {
int i;
@@ -106,6 +113,21 @@ struct crypto_algo *image_get_crypto_algo(const char 
*full_name)
return NULL;
 }
 
+struct padding_algo *image_get_padding_algo(const char *name)
+{
+   int i;
+
+   if (!name)
+   return NULL;
+
+   for (i = 0; i < ARRAY_SIZE(padding_algos); i++) {
+   if (!strcmp(padding_algos[i].name, name))
+   return _algos[i];
+   }
+
+   return NULL;
+}
+
 /**
  * fit_region_make_list() - Make a list of image regions
  *
@@ -155,6 +177,7 @@ static int fit_image_setup_verify(struct image_sign_info 
*info,
char **err_msgp)
 {
char *algo_name;
+   const char *padding_name;
 
if (fdt_totalsize(fit) > CONFIG_FIT_SIGNATURE_MAX_SIZE) {
*err_msgp = "Total size too large";
@@ -165,6 +188,11 @@ static int fit_image_setup_verify(struct image_sign_info 
*info,
*err_msgp = "Can't get hash algo property";
return -1;
}
+
+   padding_name = fdt_getprop(fit, noffset, "padding", NULL);
+   if (!padding_name)
+   padding_name = RSA_DEFAULT_PADDING_NAME;
+
memset(info, '\0', sizeof(*info));
info->keyname = fdt_getprop(fit, noffset, "key-name-hint", NULL);
info->fit = (void *)fit;
@@ -172,6 +200,7 @@ static int fit_image_setup_verify(struct image_sign_info 
*info,
info->name = algo_name;
info->checksum = image_get_checksum_algo(algo_name);
info->crypto = image_get_crypto_algo(algo_name);
+   info->padding = image_get_padding_algo(padding_name);
info->fdt_blob = gd_fdt_blob();
info->required_keynode = required_keynode;
printf("%s:%s", algo_name, info->keyname);
diff --git a/include/image.h b/include/image.h
index 3bb7d29..5c8154e 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1099,6 +1099,7 @@ struct image_sign_info {
int node_offset;/* Offset of signature node */
const char *name;   /* Algorithm name */
struct checksum_algo *checksum; /* Checksum algorithm information */
+   struct padding_algo *padding;   /* Padding algorithm information */
struct crypto_algo *crypto; /* Crypto algorithm information */
const void *fdt_blob;   /* FDT containing public keys */
int required_keynode;   /* Node offset of key to use: -1=any */
@@ -1184,6 +1185,13 @@ struct crypto_algo {
  uint8_t *sig, uint sig_len);
 };
 
+struct padding_algo {
+   const char *name;
+   int (*verify)(struct image_sign_info *info,
+ uint8_t *pad, int pad_len,
+ const uint8_t *hash, int hash_len);
+};
+
 /**
  * image_get_checksum_algo() - Look up a checksum algorithm
  *
@@ -1201,6 +1209,14 @@ struct checksum_algo *image_get_checksum_algo(const char 
*full_name);
 struct crypto_algo *image_get_crypto_algo(const char *full_name);
 
 /**
+ * image_get_padding_algo() - Look up a 

[U-Boot] [PATCH V2 3/6] rsa: add support of padding pss

[Philippe Reynes]

We add the support of the padding pss for rsa signature.
This new padding is often recommended instead of pkcs-1.5.

Signed-off-by: Philippe Reynes 
---
 Kconfig  |   8 +++
 common/image-sig.c   |   6 ++
 include/image.h  |   1 +
 include/u-boot/rsa.h |  15 
 lib/rsa/rsa-sign.c   |  10 +++
 lib/rsa/rsa-verify.c | 190 +++
 6 files changed, 230 insertions(+)

Changelog:
v2:
- add a Kconfig option (thanks Simon Glass)
- some code cleaning (thanks Simon Glass)

diff --git a/Kconfig b/Kconfig
index dca9bb4..3120553 100644
--- a/Kconfig
+++ b/Kconfig
@@ -290,6 +290,14 @@ config FIT_SIGNATURE_MAX_SIZE
  device memory. Assure this size does not extend past expected storage
  space.
 
+config FIT_ENABLE_RSASSA_PSS_SUPPORT
+   bool "Support rsassa-pss signature scheme of FIT image contents"
+   depends on FIT_SIGNATURE
+   default n
+   help
+ Enable this to support the pss padding algorithm as described
+ in the rfc8017 (https://tools.ietf.org/html/rfc8017).
+
 config FIT_VERBOSE
bool "Show verbose messages when FIT images fail"
help
diff --git a/common/image-sig.c b/common/image-sig.c
index b7ca657..f5ce3b2 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -76,6 +76,12 @@ struct padding_algo padding_algos[] = {
.name = "pkcs-1.5",
.verify = padding_pkcs_15_verify,
},
+#ifdef CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT
+   {
+   .name = "pss",
+   .verify = padding_pss_verify,
+   }
+#endif /* CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT */
 };
 
 struct checksum_algo *image_get_checksum_algo(const char *full_name)
diff --git a/include/image.h b/include/image.h
index 5c8154e..ac4ec59 100644
--- a/include/image.h
+++ b/include/image.h
@@ -30,6 +30,7 @@ struct fdt_region;
 #define IMAGE_ENABLE_FIT   1
 #define IMAGE_ENABLE_OF_LIBFDT 1
 #define CONFIG_FIT_VERBOSE 1 /* enable fit_format_{error,warning}() */
+#define CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT 1
 #define CONFIG_FIT_ENABLE_SHA256_SUPPORT
 #define CONFIG_SHA1
 #define CONFIG_SHA256
diff --git a/include/u-boot/rsa.h b/include/u-boot/rsa.h
index 16b4c4c..2d3024d 100644
--- a/include/u-boot/rsa.h
+++ b/include/u-boot/rsa.h
@@ -101,6 +101,12 @@ int rsa_verify(struct image_sign_info *info,
 int padding_pkcs_15_verify(struct image_sign_info *info,
   uint8_t *msg, int msg_len,
   const uint8_t *hash, int hash_len);
+
+#ifdef CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT
+int padding_pss_verify(struct image_sign_info *info,
+  uint8_t *msg, int msg_len,
+  const uint8_t *hash, int hash_len);
+#endif /* CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT */
 #else
 static inline int rsa_verify(struct image_sign_info *info,
const struct image_region region[], int region_count,
@@ -115,6 +121,15 @@ static inline int padding_pkcs_15_verify(struct 
image_sign_info *info,
 {
return -ENXIO;
 }
+
+#ifdef CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT
+static inline int padding_pss_verify(struct image_sign_info *info,
+uint8_t *msg, int msg_len,
+const uint8_t *hash, int hash_len)
+{
+   return -ENXIO;
+}
+#endif /* CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT */
 #endif
 
 #define RSA_DEFAULT_PADDING_NAME   "pkcs-1.5"
diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
index 6aa0e2a..fb5e07b 100644
--- a/lib/rsa/rsa-sign.c
+++ b/lib/rsa/rsa-sign.c
@@ -438,6 +438,16 @@ static int rsa_sign_with_key(RSA *rsa, struct padding_algo 
*padding_algo,
goto err_sign;
}
 
+#ifdef CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT
+   if (padding_algo && !strcmp(padding_algo->name, "pss")) {
+   if (EVP_PKEY_CTX_set_rsa_padding(ckey,
+RSA_PKCS1_PSS_PADDING) <= 0) {
+   ret = rsa_err("Signer padding setup failed");
+   goto err_sign;
+   }
+   }
+#endif /* CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT */
+
for (i = 0; i < region_count; i++) {
if (!EVP_DigestSignUpdate(context, region[i].data,
  region[i].size)) {
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index 279a9ba..9734f6d 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -80,6 +80,196 @@ int padding_pkcs_15_verify(struct image_sign_info *info,
return 0;
 }
 
+#ifdef CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT
+static void u32_i2osp(uint32_t val, uint8_t *buf)
+{
+   buf[0] = (uint8_t)((val >> 24) & 0xff);
+   buf[1] = (uint8_t)((val >> 16) & 0xff);
+   buf[2] = (uint8_t)((val >>  8) & 0xff);
+   buf[3] = (uint8_t)((val >>  0) & 0xff);
+}
+
+/**
+ * mask_generation_function1() - generate an octet string
+ *
+ * Generate an octet string used to check 

[U-Boot] [PATCH V2 1/6] rsa: use new openssl API to create signature

[Philippe Reynes]

Previous implementation of the rsa signature was using
the openssl API EVP_Sign*, but the new openssl API
EVP_DigestSign* is more flexible. So we move to this
new API.

Signed-off-by: Philippe Reynes 
Reviewed-by: Simon Glass 
---
 lib/rsa/rsa-sign.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

Changelog:
v2:
- no change

diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
index 05ac67b..78e348e 100644
--- a/lib/rsa/rsa-sign.c
+++ b/lib/rsa/rsa-sign.c
@@ -393,7 +393,8 @@ static int rsa_sign_with_key(RSA *rsa, struct checksum_algo 
*checksum_algo,
 {
EVP_PKEY *key;
EVP_MD_CTX *context;
-   int size, ret = 0;
+   int ret = 0;
+   size_t size;
uint8_t *sig;
int i;
 
@@ -409,7 +410,7 @@ static int rsa_sign_with_key(RSA *rsa, struct checksum_algo 
*checksum_algo,
size = EVP_PKEY_size(key);
sig = malloc(size);
if (!sig) {
-   fprintf(stderr, "Out of memory for signature (%d bytes)\n",
+   fprintf(stderr, "Out of memory for signature (%zu bytes)\n",
size);
ret = -ENOMEM;
goto err_alloc;
@@ -421,22 +422,26 @@ static int rsa_sign_with_key(RSA *rsa, struct 
checksum_algo *checksum_algo,
goto err_create;
}
EVP_MD_CTX_init(context);
-   if (!EVP_SignInit(context, checksum_algo->calculate_sign())) {
+   if (EVP_DigestSignInit(context, NULL,
+  checksum_algo->calculate_sign(),
+  NULL, key) <= 0) {
ret = rsa_err("Signer setup failed");
goto err_sign;
}
 
for (i = 0; i < region_count; i++) {
-   if (!EVP_SignUpdate(context, region[i].data, region[i].size)) {
+   if (!EVP_DigestSignUpdate(context, region[i].data,
+ region[i].size)) {
ret = rsa_err("Signing data failed");
goto err_sign;
}
}
 
-   if (!EVP_SignFinal(context, sig, sig_size, key)) {
+   if (!EVP_DigestSignFinal(context, sig, )) {
ret = rsa_err("Could not obtain signature");
goto err_sign;
}
+
#if OPENSSL_VERSION_NUMBER < 0x1010L || \
(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 
0x0207fL)
EVP_MD_CTX_cleanup(context);
@@ -446,7 +451,7 @@ static int rsa_sign_with_key(RSA *rsa, struct checksum_algo 
*checksum_algo,
EVP_MD_CTX_destroy(context);
EVP_PKEY_free(key);
 
-   debug("Got signature: %d bytes, expected %d\n", *sig_size, size);
+   debug("Got signature: %d bytes, expected %zu\n", *sig_size, size);
*sigp = sig;
*sig_size = size;
 
-- 
2.7.4

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

Re: [U-Boot] [PATCH v3] sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)

[Rajat Srivastava]

Hi Stefan

> -Original Message-
> From: Stefan Roese 
> Sent: Tuesday, October 23, 2018 10:31 PM
> To: Rajat Srivastava ; ja...@openedev.com;
> simon.k.r.goldschm...@gmail.com
> Cc: Ashish Kumar ; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH v3] sf: Add auto detection of 4-byte mode (vs
> standard 3-byte mode)
> 
> Hi Rajat,
> 
> On 23.10.18 07:17, Rajat Srivastava wrote:
> >> -Original Message-
> >> From: Stefan Roese [mailto:s...@denx.de]
> >> Sent: Monday, October 22, 2018 12:45 PM
> >> To: Rajat Srivastava ; 
> >> mailto:ja...@openedev.com;
> >> mailto:simon.k.r.goldschm...@gmail.com
> >> Cc: Ashish Kumar ; mailto:u-boot@lists.denx.de
> >> Subject: Re: [U-Boot] [PATCH v3] sf: Add auto detection of 4-byte mode (vs
> >> standard 3-byte mode)
> >>
> >> Hi Rajat,
> >>
> >> On 17.10.18 13:52, Rajat Srivastava wrote:
> >>> Hi Stefan
> >>>
> >>> Sorry for top-posting.
> >>>
> >>> Why can't we read SFDP parameters from flash and auto-detect
> >>> 3-byte/4-byte addressing mode?
> >>> Using address width information we can support both types of flash
> >>> i.e. flashes supporting 3-byte addressing mode as well as flashes
> >>> supporting 4-byte addressing mode.
> >>
> >> Our flash supports 3- and 4-byte addressing mode. But this special
> >> chip is factory strapped to only support 4-byte mode, even though
> >> its device ID tells us that it should support also 3-byte mode.
> >> This current pretty simple patch enables the use of this flash
> >> with very limited code additions. It also helps others (Simon on
> >> SoCFPGA) with their issues regarding 3-byte vs 4-byte mode -
> >> especially in regard to the bootrom and its setup.
> >
> > If you look into my patch, for the flashes that support both
> > 3-byte and 4-byte addressing modes, the default addressing mode is set to
> > 4-byte. In such case if the user wants to send a command in 3-byte mode
> > then he has to set a flag. So SFDP path will be able to handle the special
> > chip that is factory strapped to 4-byte addressing mode.
> >
> > Code snippet from patch which handles 3-byte/4-byte/both addressing modes:
> > + switch (bfpt.dwords[BFPT_DWORD(1)] &
> BFPT_DWORD1_ADDRESS_BYTES_MASK) {
> > +case BFPT_DWORD1_ADDRESS_BYTES_3_ONLY: // flashes with 3-byte
> addressing
> > +flash->addr_width = 3;
> > +break;
> > +case BFPT_DWORD1_ADDRESS_BYTES_3_OR_4: // flashes with both 3 or
> 4 byte
> > +printf("SF: Flash defaults to 3-Byte mode; enters 4-Byte 
> > ");
> > +printf("mode on command\n");
> > +/*
> > + * By default, 4-byte addressing mode is set.
> > + * To enforce 3-byte addressing mode, set addrwd_3_in_use 
> > flag
> > + * in struct spi_flash for every command.
> > + */
> > +flash->addr_width = 4;
> > +break;
> > + case BFPT_DWORD1_ADDRESS_BYTES_4_ONLY: // flashes with 4-byte
> addressing
> > +flash->addr_width = 4;
> > +break;
> >
> >>
> >>> I've floated a similar patch in U-boot that reads and parses SFDP
> >>> parameters from flash and auto-detects its addressing mode. It send
> >>> commands according to the address width it detects.
> >>> Please find the patch set at:
> >>>
> >>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> >>
> work.ozlabs.org%2Fcover%2F985326%2Fdata=02%7C01%7Crajat.srivast
> >>
> ava%40nxp.com%7C56b81d26a6954324bebd08d637ee0c35%7C686ea1d3bc2b4
> >>
> c6fa92cd99c5c301635%7C0%7C0%7C636757892882342025sdata=M2aU
> >>
> WUxSn9wmlBlYj336%2Bay5rwOddG%2Br7Qn5kH%2Bf1uw%3Dreserved=
> >> 0
> >>>
> >>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> >>
> work.ozlabs.org%2Fpatch%2F985327%2Fdata=02%7C01%7Crajat.srivast
> >>
> ava%40nxp.com%7C56b81d26a6954324bebd08d637ee0c35%7C686ea1d3bc2b4
> >>
> c6fa92cd99c5c301635%7C0%7C0%7C636757892882342025sdata=IIzUJuI
> >> 9nL5Wn7K5uAqjig9edpW6YIIcSOExNJNB5qE%3Dreserved=0
> >>>
> >>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> >>
> work.ozlabs.org%2Fpatch%2F985329%2Fdata=02%7C01%7Crajat.srivast
> >>
> ava%40nxp.com%7C56b81d26a6954324bebd08d637ee0c35%7C686ea1d3bc2b4
> >>
> c6fa92cd99c5c301635%7C0%7C0%7C636757892882342025sdata=N5qQJ
> >> E1776Wb3siJApPDCkUyY4vn0ZVLjCebn4hi6bk%3Dreserved=0
> >>>
> >>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> >>
> work.ozlabs.org%2Fpatch%2F985328%2Fdata=02%7C01%7Crajat.srivast
> >>
> ava%40nxp.com%7C56b81d26a6954324bebd08d637ee0c35%7C686ea1d3bc2b4
> >>
> c6fa92cd99c5c301635%7C0%7C0%7C636757892882342025sdata=tC%2F
> >>
> %2FsGVwV%2FrHBPX1gJ5TNYmVnJOL13XpAjgP87w3%2Bx0%3Dreserved
> >> =0
> >>
> >> I've just applied your 3 patches and have added SFDP support for
> >> our equipped SPI chip (with my patch not applied):
> >>
> >> -   

[U-Boot] [PATCH v2 6/6] sunxi: store DRAM size in SPL header

[Icenowy Zheng]

From: Andre Przywara 

At the moment we rely on the infamous get_ram_size() function to learn
the actual DRAM size in U-Boot proper. This function has two issues:
1) It only works if the DRAM size is a power of two. We start to see
boards which have 3GB of (usable) DRAM, so this does not fit anymore.
2) As U-Boot has no notion of reserved memory so far, it will happily
ride through the DRAM, possibly stepping on secure-only memory. This
could be a region of DRAM reserved for OP-TEE or some other secure
payload, for instance. It will most likely crash in that case.

As the SPL DRAM init routine has very accurate knowledge of the actual
DRAM size, lets propagate this wisdom to U-Boot proper.
We re-purpose a currently reserved word in our SPL header for that.
The SPL itself stores the detected DRAM size there, and bumps the SPL
header version number in that case. U-Boot proper checks for a valid
SPL header and a high enough version number, then uses the DRAM size
from there. If the SPL header field is not sufficient, we fall back to
the old DRAM scanning routine.

Part of the DRAM might be present and probed by SPL, but not accessible
by the CPU. They're restricted in the main U-Boot binary, when accessing
the DRAM size from SPL header.

Signed-off-by: Andre Przywara 
Signed-off-by: Icenowy Zheng 
---
Changes in v2:
- Restrict the DRAM size to the accessible range.

 arch/arm/include/asm/arch-sunxi/spl.h |  3 ++-
 board/sunxi/board.c   | 28 ++-
 2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/spl.h 
b/arch/arm/include/asm/arch-sunxi/spl.h
index 014184b638..4baba38b00 100644
--- a/arch/arm/include/asm/arch-sunxi/spl.h
+++ b/arch/arm/include/asm/arch-sunxi/spl.h
@@ -19,6 +19,7 @@
 
 #define SPL_ENV_HEADER_VERSION SPL_VERSION(0, 1)
 #define SPL_DT_HEADER_VERSION  SPL_VERSION(0, 2)
+#define SPL_DRAM_HEADER_VERSIONSPL_VERSION(0, 3)
 
 #define SPL_ADDR   CONFIG_SUNXI_SRAM_ADDRESS
 
@@ -70,7 +71,7 @@ struct boot_file_head {
 * to the users.
 */
uint32_t dt_name_offset;/* since v0.2, set by mksunxiboot */
-   uint32_t reserved1;
+   uint32_t dram_size; /* in MiB, since v0.3, set by SPL */
uint32_t boot_media;/* written here by the boot ROM */
/* A padding area (may be used for storing text strings) */
uint32_t string_pool[13];   /* since v0.2, filled by mksunxiboot */
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index bdec82b065..65ae0c4219 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -281,7 +281,16 @@ static struct boot_file_head * get_spl_header(uint8_t 
req_version)
 
 int dram_init(void)
 {
-   gd->ram_size = get_ram_size((long *)PHYS_SDRAM_0, PHYS_SDRAM_0_SIZE);
+   struct boot_file_head *spl = get_spl_header(SPL_DRAM_HEADER_VERSION);
+
+   if (spl == INVALID_SPL_HEADER)
+   gd->ram_size = get_ram_size((long *)PHYS_SDRAM_0,
+   PHYS_SDRAM_0_SIZE);
+   else
+   gd->ram_size = (phys_addr_t)spl->dram_size << 20;
+
+   if (gd->ram_size > CONFIG_SUNXI_DRAM_MAX_SIZE)
+   gd->ram_size = CONFIG_SUNXI_DRAM_MAX_SIZE;
 
return 0;
 }
@@ -545,6 +554,21 @@ int board_mmc_init(bd_t *bis)
 #endif
 
 #ifdef CONFIG_SPL_BUILD
+
+static void sunxi_spl_store_dram_size(phys_addr_t dram_size)
+{
+   struct boot_file_head *spl = get_spl_header(SPL_DT_HEADER_VERSION);
+
+   if (spl == INVALID_SPL_HEADER)
+   return;
+
+   /* Promote the header version for U-Boot proper, if needed. */
+   if (spl->spl_signature[3] < SPL_DRAM_HEADER_VERSION)
+   spl->spl_signature[3] = SPL_DRAM_HEADER_VERSION;
+
+   spl->dram_size = dram_size >> 20;
+}
+
 void sunxi_board_init(void)
 {
int power_failed = 0;
@@ -613,6 +637,8 @@ void sunxi_board_init(void)
if (!gd->ram_size)
hang();
 
+   sunxi_spl_store_dram_size(gd->ram_size);
+
/*
 * Only clock up the CPU to full speed if we are reasonably
 * assured it's being powered with suitable core voltage
-- 
2.18.1

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

[U-Boot] [PATCH v2 4/6] sunxi: map DRAM part with 3G size

[Icenowy Zheng]

All Allwinner 64-bit SoCs now are known to be able to access 3GiB of
external DRAM, however the size of DRAM part in the MMU translation
table is still 2GiB.

Change the size of DRAM part in MMU table to 3GiB.

Signed-off-by: Icenowy Zheng 
---
This used to be in another patchset targeting 3GiB support.

No changes in v2.

 arch/arm/mach-sunxi/board.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index d22a84ea6b..b74eaf2a0e 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -52,7 +52,7 @@ static struct mm_region sunxi_mem_map[] = {
/* RAM */
.virt = 0x4000UL,
.phys = 0x4000UL,
-   .size = 0x8000UL,
+   .size = 0xC000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {
-- 
2.18.1

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

[U-Boot] [PATCH v2 5/6] sunxi: add Kconfig option for the maximum accessible DRAM

[Icenowy Zheng]

Allwinner 64-bit SoCs can use 4GiB DRAM chip, however their memory map
has only allocated 3GiB for DRAM, so only 3GiB of the DRAM is
accessible.

Add a Kconfig option for the maximum accessible DRAM.

For A80 it should be a much higher value (8GiB), but as I have no A80
device to test and originally U-Boot only supports 2GiB DRAM on A80, it
currently still falls under the 2GiB situation.

Signed-off-by: Icenowy Zheng 
---
This used to be in another patchset targeting 3GiB support.

Changes in v2:
- Add H6 to SoCs that support 3GiB DRAM.

 arch/arm/mach-sunxi/Kconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 764337c643..e9e1b4bc0e 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -140,6 +140,14 @@ config MACH_SUNXI_H3_H5
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
 
+# TODO: try out A80's 8GiB DRAM space
+config SUNXI_DRAM_MAX_SIZE
+   hex
+   default 0xC000 if MACH_SUN50I
+   default 0xC000 if MACH_SUN50I_H5
+   default 0xC000 if MACH_SUN50I_H6
+   default 0x8000
+
 choice
prompt "Sunxi SoC Variant"
optional
-- 
2.18.1

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

[U-Boot] [PATCH v2 2/6] sunxi: Extend SPL header versioning

[Icenowy Zheng]

From: Andre Przywara 

On Allwinner SoCs we use some free bytes at the beginning of the SPL image
to store various information. We have a version byte to allow updates,
but changing this always requires all tools to be updated as well.

Introduce the concept of semantic versioning [1] to the SPL header:
The major part of the version number only changes on incompatible
updates, a minor number bump indicates backward compatibility.
This patch just documents the major/minor split, adds some comments
to the header file and uses the versioning information for the existing
users.

[1] https://semver.org

Signed-off-by: Andre Przywara 
Signed-off-by: Icenowy Zheng 
---
No changes in v2.

 arch/arm/include/asm/arch-sunxi/spl.h | 19 ++-
 board/sunxi/board.c   |  4 ++--
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/spl.h 
b/arch/arm/include/asm/arch-sunxi/spl.h
index 55f2deb18d..014184b638 100644
--- a/arch/arm/include/asm/arch-sunxi/spl.h
+++ b/arch/arm/include/asm/arch-sunxi/spl.h
@@ -9,7 +9,16 @@
 
 #define BOOT0_MAGIC"eGON.BT0"
 #define SPL_SIGNATURE  "SPL" /* marks "sunxi" SPL header */
-#define SPL_HEADER_VERSION 2
+#define SPL_MAJOR_BITS 3
+#define SPL_MINOR_BITS 5
+#define SPL_VERSION(maj, min)  \
+   maj) & ((1U << SPL_MAJOR_BITS) - 1)) << SPL_MINOR_BITS) | \
+   ((min) & ((1U << SPL_MINOR_BITS) - 1)))
+
+#define SPL_HEADER_VERSION SPL_VERSION(0, 2)
+
+#define SPL_ENV_HEADER_VERSION SPL_VERSION(0, 1)
+#define SPL_DT_HEADER_VERSION  SPL_VERSION(0, 2)
 
 #define SPL_ADDR   CONFIG_SUNXI_SRAM_ADDRESS
 
@@ -45,14 +54,14 @@ struct boot_file_head {
uint32_t pub_head_size;
uint8_t spl_signature[4];
};
-   uint32_t fel_script_address;
+   uint32_t fel_script_address;/* since v0.1, set by sunxi-fel */
/*
 * If the fel_uEnv_length member below is set to a non-zero value,
 * it specifies the size (byte count) of data at fel_script_address.
 * At the same time this indicates that the data is in uEnv.txt
 * compatible format, ready to be imported via "env import -t".
 */
-   uint32_t fel_uEnv_length;
+   uint32_t fel_uEnv_length;   /* since v0.1, set by sunxi-fel */
/*
 * Offset of an ASCIIZ string (relative to the SPL header), which
 * contains the default device tree name (CONFIG_DEFAULT_DEVICE_TREE).
@@ -60,11 +69,11 @@ struct boot_file_head {
 * by flash programming tools for providing nice informative messages
 * to the users.
 */
-   uint32_t dt_name_offset;
+   uint32_t dt_name_offset;/* since v0.2, set by mksunxiboot */
uint32_t reserved1;
uint32_t boot_media;/* written here by the boot ROM */
/* A padding area (may be used for storing text strings) */
-   uint32_t string_pool[13];
+   uint32_t string_pool[13];   /* since v0.2, filled by mksunxiboot */
/* The header must be a multiple of 32 bytes (for VBAR alignment) */
 };
 
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 49f5695566..94555ef468 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -667,9 +667,9 @@ static void parse_spl_header(const uint32_t spl_addr)
return; /* signature mismatch, no usable header */
 
uint8_t spl_header_version = spl->spl_signature[3];
-   if (spl_header_version != SPL_HEADER_VERSION) {
+   if (spl_header_version < SPL_ENV_HEADER_VERSION) {
printf("sunxi SPL version mismatch: expected %u, got %u\n",
-  SPL_HEADER_VERSION, spl_header_version);
+  SPL_ENV_HEADER_VERSION, spl_header_version);
return;
}
if (!spl->fel_script_address)
-- 
2.18.1

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

[U-Boot] [PATCH v2 3/6] sunxi: board.c: refactor SPL header checks

[Icenowy Zheng]

From: Andre Przywara 

So far we have two users which want to look at the SPL header. We will
get more in the future.
Refactor the existing SPL header checks into a common function, to
simplify reusing the code.
Now that this is easy, add proper version checks to the DT name parsing.

Signed-off-by: Andre Przywara 
Signed-off-by: Icenowy Zheng 
---
No changes in v2.

 board/sunxi/board.c | 41 ++---
 1 file changed, 30 insertions(+), 11 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 94555ef468..bdec82b065 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -255,6 +255,30 @@ int board_init(void)
return soft_i2c_board_init();
 }
 
+/*
+ * On older SoCs the SPL is actually at address zero, so using NULL as
+ * an error value does not work.
+ */
+#define INVALID_SPL_HEADER ((void *)~0UL)
+
+static struct boot_file_head * get_spl_header(uint8_t req_version)
+{
+   struct boot_file_head *spl = (void *)(ulong)SPL_ADDR;
+   uint8_t spl_header_version = spl->spl_signature[3];
+
+   /* Is there really the SPL header (still) there? */
+   if (memcmp(spl->spl_signature, SPL_SIGNATURE, 3) != 0)
+   return INVALID_SPL_HEADER;
+
+   if (spl_header_version < req_version) {
+   printf("sunxi SPL version mismatch: expected %u, got %u\n",
+  req_version, spl_header_version);
+   return INVALID_SPL_HEADER;
+   }
+
+   return spl;
+}
+
 int dram_init(void)
 {
gd->ram_size = get_ram_size((long *)PHYS_SDRAM_0, PHYS_SDRAM_0_SIZE);
@@ -662,16 +686,11 @@ void get_board_serial(struct tag_serialnr *serialnr)
  */
 static void parse_spl_header(const uint32_t spl_addr)
 {
-   struct boot_file_head *spl = (void *)(ulong)spl_addr;
-   if (memcmp(spl->spl_signature, SPL_SIGNATURE, 3) != 0)
-   return; /* signature mismatch, no usable header */
+   struct boot_file_head *spl = get_spl_header(SPL_ENV_HEADER_VERSION);
 
-   uint8_t spl_header_version = spl->spl_signature[3];
-   if (spl_header_version < SPL_ENV_HEADER_VERSION) {
-   printf("sunxi SPL version mismatch: expected %u, got %u\n",
-  SPL_ENV_HEADER_VERSION, spl_header_version);
+   if (spl == INVALID_SPL_HEADER)
return;
-   }
+
if (!spl->fel_script_address)
return;
 
@@ -806,11 +825,11 @@ int ft_board_setup(void *blob, bd_t *bd)
 #ifdef CONFIG_SPL_LOAD_FIT
 int board_fit_config_name_match(const char *name)
 {
-   struct boot_file_head *spl = (void *)(ulong)SPL_ADDR;
-   const char *cmp_str = (void *)(ulong)SPL_ADDR;
+   struct boot_file_head *spl = get_spl_header(SPL_DT_HEADER_VERSION);
+   const char *cmp_str = (const char *)spl;
 
/* Check if there is a DT name stored in the SPL header and use that. */
-   if (spl->dt_name_offset) {
+   if (spl != INVALID_SPL_HEADER && spl->dt_name_offset) {
cmp_str += spl->dt_name_offset;
} else {
 #ifdef CONFIG_DEFAULT_DEVICE_TREE
-- 
2.18.1

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

[U-Boot] [PATCH v2 1/6] sunxi: disable Pine A64 model detection code on other boards

[Icenowy Zheng]

The Pine A64 Plus/non-Plus model detection code is now built on all
64-bit ARM SoCs, even if the code cannot be triggered when H5/H6 is in
use.

Disable them when the board is Pine A64 by adding a Kconfig option that
is only selected on Pine A64.

On GCC 7.3.1 this makes the size of the function reduces 184 bytes, and
saves a 104 byte strstr() function, then makes SPL on H6 succeed to
build.

Signed-off-by: Icenowy Zheng 
---
This used to be a independently sent patch.

Changes in v2:
- Added a Kconfig option to restrict the code on only Pine A64.

 arch/arm/mach-sunxi/Kconfig   | 10 ++
 board/sunxi/board.c   |  5 -
 configs/pine64_plus_defconfig |  1 +
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 686f38fec4..764337c643 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -970,4 +970,14 @@ config SPL_SPI_SUNXI
  sunxi SPI Flash. It uses the same method as the boot ROM, so does
  not need any extra configuration.
 
+config PINE64_DT_SELECTION
+   bool "Enable Pine64 device tree selection code"
+   depends on MACH_SUN50I
+   help
+ The original Pine A64 and Pine A64+ are similar but different
+ boards and can be differed by the DRAM size. Pine A64 has
+ 512MiB DRAM, and Pine A64+ has 1GiB or 2GiB. By selecting this
+ option, the device tree selection code specific to Pine64 which
+ utilizes the DRAM size will be enabled.
+
 endif
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index d1d7f9f400..49f5695566 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -820,6 +820,7 @@ int board_fit_config_name_match(const char *name)
 #endif
};
 
+#ifdef CONFIG_PINE64_DT_SELECTION
 /* Differentiate the two Pine64 board DTs by their DRAM size. */
if (strstr(name, "-pine64") && strstr(cmp_str, "-pine64")) {
if ((gd->ram_size > 512 * 1024 * 1024))
@@ -829,5 +830,7 @@ int board_fit_config_name_match(const char *name)
} else {
return strcmp(name, cmp_str);
}
-}
 #endif
+   return strcmp(name, cmp_str);
+#endif
+}
diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
index 14ccc9ba05..a5b87b9063 100644
--- a/configs/pine64_plus_defconfig
+++ b/configs/pine64_plus_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_SPL=y
 CONFIG_MACH_SUN50I=y
 CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y
+CONFIG_PINE64_DT_SELECTION=y
 CONFIG_NR_DRAM_BANKS=1
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 # CONFIG_CMD_FLASH is not set
-- 
2.18.1

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