[v5 6/8] dm: arm64: ls1043a: add i2c DM support

[Biwen Li]

This supports i2c DM and enables CONFIG_DM_I2C
for SoC LS1043A

Reviewed-by: Priyanka Jain 
Signed-off-by: Biwen Li 
---
Changes in v5:
- update subject

Changes in v4:
- update copyright

Changes in v3:
- none

Changes in v2:
- merge some patches to one patch

 arch/arm/include/asm/gpio.h   |  2 +-
 board/freescale/ls1043aqds/ls1043aqds.c   | 98 +--
 configs/ls1043aqds_defconfig  |  2 +
 configs/ls1043aqds_lpuart_defconfig   |  2 +
 configs/ls1043aqds_nand_defconfig |  2 +
 configs/ls1043aqds_nor_ddr3_defconfig |  2 +
 configs/ls1043aqds_qspi_defconfig |  2 +
 configs/ls1043aqds_sdcard_ifc_defconfig   |  2 +
 configs/ls1043aqds_sdcard_qspi_defconfig  |  2 +
 configs/ls1043aqds_tfa_SECURE_BOOT_defconfig  |  2 +
 configs/ls1043aqds_tfa_defconfig  |  2 +
 configs/ls1043ardb_SECURE_BOOT_defconfig  |  2 +
 configs/ls1043ardb_defconfig  |  2 +
 configs/ls1043ardb_nand_SECURE_BOOT_defconfig |  2 +
 configs/ls1043ardb_nand_defconfig |  2 +
 .../ls1043ardb_sdcard_SECURE_BOOT_defconfig   |  2 +
 configs/ls1043ardb_sdcard_defconfig   |  2 +
 configs/ls1043ardb_tfa_SECURE_BOOT_defconfig  |  2 +
 configs/ls1043ardb_tfa_defconfig  |  2 +
 include/configs/ls1043a_common.h  |  6 ++
 20 files changed, 133 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
index 9f8c9da564..45cb04801c 100644
--- a/arch/arm/include/asm/gpio.h
+++ b/arch/arm/include/asm/gpio.h
@@ -3,7 +3,7 @@
!defined(CONFIG_ARCH_BCM63158) && !defined(CONFIG_ARCH_ROCKCHIP) && \
!defined(CONFIG_ARCH_LX2160A) && !defined(CONFIG_ARCH_LS1028A) && \
!defined(CONFIG_ARCH_LS2080A) && !defined(CONFIG_ARCH_LS1088A) && \
-   !defined(CONFIG_ARCH_LS1012A) && \
+   !defined(CONFIG_ARCH_LS1012A) && !defined(CONFIG_ARCH_LS1043A) && \
!defined(CONFIG_ARCH_ASPEED)
 #include 
 #endif
diff --git a/board/freescale/ls1043aqds/ls1043aqds.c 
b/board/freescale/ls1043aqds/ls1043aqds.c
index 8c96b962b7..2d4b18cdbc 100644
--- a/board/freescale/ls1043aqds/ls1043aqds.c
+++ b/board/freescale/ls1043aqds/ls1043aqds.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
  * Copyright 2015 Freescale Semiconductor, Inc.
+ * Copyright 2019 NXP
  */
 
 #include 
@@ -271,11 +272,24 @@ unsigned long get_board_ddr_clk(void)
return ;
 }
 
-int select_i2c_ch_pca9547(u8 ch)
+int select_i2c_ch_pca9547(u8 ch, int bus_num)
 {
int ret;
 
+#ifdef CONFIG_DM_I2C
+   struct udevice *dev;
+
+   ret = i2c_get_chip_for_busnum(bus_num, I2C_MUX_PCA_ADDR_PRI,
+ 1, );
+   if (ret) {
+   printf("%s: Cannot find udev for a bus %d\n", __func__,
+  bus_num);
+   return ret;
+   }
+   ret = dm_i2c_write(dev, 0, , 1);
+#else
ret = i2c_write(I2C_MUX_PCA_ADDR_PRI, 0, 1, , 1);
+#endif
if (ret) {
puts("PCA: failed to select proper channel\n");
return ret;
@@ -290,8 +304,10 @@ int dram_init(void)
 * When resuming from deep sleep, the I2C channel may not be
 * in the default channel. So, switch to the default channel
 * before accessing DDR SPD.
+*
+* PCA9547 mount on I2C1 bus
 */
-   select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
+   select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT, 0);
fsl_initdram();
 #if (!defined(CONFIG_SPL) && !defined(CONFIG_TFABOOT)) || \
defined(CONFIG_SPL_BUILD)
@@ -304,16 +320,83 @@ int dram_init(void)
 
 int i2c_multiplexer_select_vid_channel(u8 channel)
 {
-   return select_i2c_ch_pca9547(channel);
+   return select_i2c_ch_pca9547(channel, 0);
 }
 
 void board_retimer_init(void)
 {
u8 reg;
+   int bus_num = 0;
 
/* Retimer is connected to I2C1_CH7_CH5 */
-   select_i2c_ch_pca9547(I2C_MUX_CH7);
+   select_i2c_ch_pca9547(I2C_MUX_CH7, bus_num);
reg = I2C_MUX_CH5;
+#ifdef CONFIG_DM_I2C
+   struct udevice *dev;
+   int ret;
+
+   ret = i2c_get_chip_for_busnum(bus_num, I2C_MUX_PCA_ADDR_SEC,
+ 1, );
+   if (ret) {
+   printf("%s: Cannot find udev for a bus %d\n", __func__,
+  bus_num);
+   return;
+   }
+   dm_i2c_write(dev, 0, , 1);
+
+   /* Access to Control/Shared register */
+   ret = i2c_get_chip_for_busnum(bus_num, I2C_RETIMER_ADDR,
+ 1, );
+   if (ret) {
+   printf("%s: Cannot find udev for a bus %d\n", __func__,
+  bus_num);
+   return;
+   }
+
+   reg = 0x0;
+   dm_i2c_write(dev, 0xff, , 1);
+
+   /* Read device revision and ID */
+   dm_i2c_read(dev, 1, , 1);
+   debug("Retimer version id = 0x%x\n", reg);
+

[v5 7/8] dm: arm64: ls1046a: add i2c DM support

[Biwen Li]

This supports i2c DM and enables CONFIG_DM_I2C
for SoC LS1046A

Reviewed-by: Priyanka Jain 
Signed-off-by: Biwen Li 
---
Changes in v5:
- update subject

Changes in v4:
- update copyright

Changes in v3:
- none

Changes in v2:
- merge some patches to one patch

 arch/arm/dts/fsl-ls1046a-frwy.dts |  3 ++
 arch/arm/dts/fsl-ls1046a-qds.dtsi |  4 ++
 arch/arm/dts/fsl-ls1046a-rdb.dts  |  8 
 arch/arm/include/asm/gpio.h   |  1 +
 board/freescale/ls1046afrwy/ls1046afrwy.c | 17 ++-
 board/freescale/ls1046aqds/ls1046aqds.c   | 25 --
 configs/ls1046afrwy_tfa_defconfig |  2 +
 configs/ls1046aqds_SECURE_BOOT_defconfig  |  2 +
 configs/ls1046aqds_defconfig  |  2 +
 configs/ls1046aqds_lpuart_defconfig   |  2 +
 configs/ls1046aqds_nand_defconfig |  2 +
 configs/ls1046aqds_qspi_defconfig |  2 +
 configs/ls1046aqds_sdcard_ifc_defconfig   |  2 +
 configs/ls1046aqds_sdcard_qspi_defconfig  |  2 +
 configs/ls1046aqds_tfa_SECURE_BOOT_defconfig  |  2 +
 configs/ls1046aqds_tfa_defconfig  |  2 +
 configs/ls1046ardb_emmc_defconfig |  2 +
 configs/ls1046ardb_qspi_SECURE_BOOT_defconfig |  2 +
 configs/ls1046ardb_qspi_defconfig |  2 +
 configs/ls1046ardb_qspi_spl_defconfig |  2 +
 .../ls1046ardb_sdcard_SECURE_BOOT_defconfig   |  2 +
 configs/ls1046ardb_sdcard_defconfig   |  2 +
 configs/ls1046ardb_tfa_SECURE_BOOT_defconfig  |  2 +
 configs/ls1046ardb_tfa_defconfig  |  2 +
 drivers/power/power_i2c.c | 46 ++-
 include/configs/ls1046a_common.h  |  6 +++
 26 files changed, 138 insertions(+), 8 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1046a-frwy.dts 
b/arch/arm/dts/fsl-ls1046a-frwy.dts
index 3d41e3bd44..d39159322a 100644
--- a/arch/arm/dts/fsl-ls1046a-frwy.dts
+++ b/arch/arm/dts/fsl-ls1046a-frwy.dts
@@ -32,3 +32,6 @@
 
 };
 
+ {
+   status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1046a-qds.dtsi 
b/arch/arm/dts/fsl-ls1046a-qds.dtsi
index c95f44fc36..76dc397328 100644
--- a/arch/arm/dts/fsl-ls1046a-qds.dtsi
+++ b/arch/arm/dts/fsl-ls1046a-qds.dtsi
@@ -80,3 +80,7 @@
  {
status = "okay";
 };
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1046a-rdb.dts b/arch/arm/dts/fsl-ls1046a-rdb.dts
index a05c9e9b9e..83e34ab02a 100644
--- a/arch/arm/dts/fsl-ls1046a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1046a-rdb.dts
@@ -43,3 +43,11 @@
  {
status = "okay";
 };
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
index 45cb04801c..9adebf6c04 100644
--- a/arch/arm/include/asm/gpio.h
+++ b/arch/arm/include/asm/gpio.h
@@ -4,6 +4,7 @@
!defined(CONFIG_ARCH_LX2160A) && !defined(CONFIG_ARCH_LS1028A) && \
!defined(CONFIG_ARCH_LS2080A) && !defined(CONFIG_ARCH_LS1088A) && \
!defined(CONFIG_ARCH_LS1012A) && !defined(CONFIG_ARCH_LS1043A) && \
+   !defined(CONFIG_ARCH_LS1046A) && \
!defined(CONFIG_ARCH_ASPEED)
 #include 
 #endif
diff --git a/board/freescale/ls1046afrwy/ls1046afrwy.c 
b/board/freescale/ls1046afrwy/ls1046afrwy.c
index ac2f8ee436..4a9189b3ee 100644
--- a/board/freescale/ls1046afrwy/ls1046afrwy.c
+++ b/board/freescale/ls1046afrwy/ls1046afrwy.c
@@ -35,11 +35,24 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-int select_i2c_ch_pca9547(u8 ch)
+int select_i2c_ch_pca9547(u8 ch, int bus_num)
 {
int ret;
 
+#ifdef CONFIG_DM_I2C
+   struct udevice *dev;
+
+   ret = i2c_get_chip_for_busnum(bus_num, I2C_MUX_PCA_ADDR_PRI,
+ 1, );
+   if (ret) {
+   printf("%s: Cannot find udev for a bus %d\n", __func__,
+  bus_num);
+   return ret;
+   }
+   ret = dm_i2c_write(dev, 0, , 1);
+#else
ret = i2c_write(I2C_MUX_PCA_ADDR_PRI, 0, 1, , 1);
+#endif
if (ret) {
puts("PCA: failed to select proper channel\n");
return ret;
@@ -144,7 +157,7 @@ val = (in_le32(SMMU_SCR0) | SCR0_CLIENTPD_MASK) & 
~(SCR0_USFCFG_MASK);
sec_init();
 #endif
 
-   select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
+   select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT, 0);
return 0;
 }
 
diff --git a/board/freescale/ls1046aqds/ls1046aqds.c 
b/board/freescale/ls1046aqds/ls1046aqds.c
index aac5d9aa84..cabd7ee648 100644
--- a/board/freescale/ls1046aqds/ls1046aqds.c
+++ b/board/freescale/ls1046aqds/ls1046aqds.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
  * Copyright 2016 Freescale Semiconductor, Inc.
+ * Copyright 2019 NXP
  */
 
 #include 
@@ -269,11 +270,23 @@ u32 get_lpuart_clk(void)
 }
 #endif
 
-int select_i2c_ch_pca9547(u8 ch)
+int select_i2c_ch_pca9547(u8 ch, int bus_num)
 {
int ret;
+#ifdef CONFIG_DM_I2C
+   struct udevice *dev;
 
+   ret = i2c_get_chip_for_busnum(bus_num, 

[v5 8/8] dm: arm: ls1021a: add i2c DM support

[Biwen Li]

This supports i2c DM and enables CONFIG_DM_I2C
for SoC LS1021A

Reviewed-by: Priyanka Jain 
Signed-off-by: Biwen Li 
---
Changes in v5:
- none

Changes in v4:
- update copyright

Changes in v3:
- none

Changes in v2:
- merge some patches to one patch

 board/freescale/common/dcu_sii9022a.c | 95 +++
 board/freescale/common/diu_ch7301.c   | 80 
 board/freescale/ls1021aqds/dcu.c  | 44 -
 board/freescale/ls1021aqds/ls1021aqds.c   | 21 +++-
 board/freescale/ls1021atwr/ls1021atwr.c   | 27 +-
 configs/ls1021aiot_qspi_defconfig |  2 +
 configs/ls1021aiot_sdcard_defconfig   |  2 +
 configs/ls1021aqds_ddr4_nor_defconfig |  2 +
 configs/ls1021aqds_ddr4_nor_lpuart_defconfig  |  2 +
 configs/ls1021aqds_nand_defconfig |  2 +
 configs/ls1021aqds_nor_SECURE_BOOT_defconfig  |  2 +
 configs/ls1021aqds_nor_defconfig  |  2 +
 configs/ls1021aqds_nor_lpuart_defconfig   |  2 +
 configs/ls1021aqds_qspi_defconfig |  2 +
 configs/ls1021aqds_sdcard_ifc_defconfig   |  2 +
 configs/ls1021aqds_sdcard_qspi_defconfig  |  2 +
 configs/ls1021atsn_qspi_defconfig |  2 +
 configs/ls1021atsn_sdcard_defconfig   |  2 +
 configs/ls1021atwr_nor_SECURE_BOOT_defconfig  |  2 +
 configs/ls1021atwr_nor_defconfig  |  2 +
 configs/ls1021atwr_nor_lpuart_defconfig   |  2 +
 configs/ls1021atwr_qspi_defconfig |  2 +
 ...s1021atwr_sdcard_ifc_SECURE_BOOT_defconfig |  2 +
 configs/ls1021atwr_sdcard_ifc_defconfig   |  2 +
 configs/ls1021atwr_sdcard_qspi_defconfig  |  2 +
 include/configs/ls1021aiot.h  |  4 +
 include/configs/ls1021aqds.h  |  3 +
 include/configs/ls1021atsn.h  |  4 +-
 include/configs/ls1021atwr.h  |  4 +
 29 files changed, 314 insertions(+), 8 deletions(-)

diff --git a/board/freescale/common/dcu_sii9022a.c 
b/board/freescale/common/dcu_sii9022a.c
index 3bf71abf55..b2a094ad6c 100644
--- a/board/freescale/common/dcu_sii9022a.c
+++ b/board/freescale/common/dcu_sii9022a.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
  * Copyright 2014 Freescale Semiconductor, Inc.
+ * Copyright 2019 NXP
  */
 
 #include 
@@ -63,7 +64,100 @@ int dcu_set_dvi_encoder(struct fb_videomode *videomode)
u8 temp;
u16 temp1, temp2;
u32 temp3;
+#ifdef CONFIG_DM_I2C
+   struct udevice *dev;
+   int ret;
+
+   ret = i2c_get_chip_for_busnum(CONFIG_SYS_I2C_DVI_BUS_NUM, 
CONFIG_SYS_I2C_DVI_ADDR,
+ 1, );
+   if (ret) {
+   printf("%s: Cannot find udev for a bus %d\n", __func__,
+  CONFIG_SYS_I2C_DVI_BUS_NUM);
+   return ret;
+   }
 
+   /* Enable TPI transmitter mode */
+   temp = TPI_TRANS_MODE_ENABLE;
+   dm_i2c_write(dev, TPI_TRANS_MODE_REG, , 1);
+
+   /* Enter into D0 state, full operation */
+   dm_i2c_read(dev, TPI_PWR_STAT_REG, , 1);
+   temp &= ~TPI_PWR_STAT_MASK;
+   temp |= TPI_PWR_STAT_D0;
+   dm_i2c_write(dev, TPI_PWR_STAT_REG, , 1);
+
+   /* Enable source termination */
+   temp = TPI_SET_PAGE_SII9022A;
+   dm_i2c_write(dev, TPI_SET_PAGE_REG, , 1);
+   temp = TPI_SET_OFFSET_SII9022A;
+   dm_i2c_write(dev, TPI_SET_OFFSET_REG, , 1);
+
+   dm_i2c_read(dev, TPI_RW_ACCESS_REG, , 1);
+   temp |= TPI_RW_EN_SRC_TERMIN;
+   dm_i2c_write(dev, TPI_RW_ACCESS_REG, , 1);
+
+   /* Set TPI system control */
+   temp = TPI_SYS_TMDS_OUTPUT | TPI_SYS_AV_NORAML | TPI_SYS_DVI_MODE;
+   dm_i2c_write(dev, TPI_SYS_CTRL_REG, , 1);
+
+   /* Set pixel clock */
+   temp1 = PICOS2KHZ(videomode->pixclock) / 10;
+   temp = (u8)(temp1 & 0xFF);
+   dm_i2c_write(dev, PIXEL_CLK_LSB_REG, , 1);
+   temp = (u8)(temp1 >> 8);
+   dm_i2c_write(dev, PIXEL_CLK_MSB_REG, , 1);
+
+   /* Set total pixels per line */
+   temp1 = videomode->hsync_len + videomode->left_margin +
+   videomode->xres + videomode->right_margin;
+   temp = (u8)(temp1 & 0xFF);
+   dm_i2c_write(dev, TOTAL_PIXELS_LSB_REG, , 1);
+   temp = (u8)(temp1 >> 8);
+   dm_i2c_write(dev, TOTAL_PIXELS_MSB_REG, , 1);
+
+   /* Set total lines */
+   temp2 = videomode->vsync_len + videomode->upper_margin +
+   videomode->yres + videomode->lower_margin;
+   temp = (u8)(temp2 & 0xFF);
+   dm_i2c_write(dev, TOTAL_LINES_LSB_REG, , 1);
+   temp = (u8)(temp2 >> 8);
+   dm_i2c_write(dev, TOTAL_LINES_MSB_REG, , 1);
+
+   /* Set vertical frequency in Hz */
+   temp3 = temp1 * temp2;
+   temp3 = (PICOS2KHZ(videomode->pixclock) * 1000) / temp3;
+   temp1 = (u16)temp3 * 100;
+   temp = (u8)(temp1 & 0xFF);
+   dm_i2c_write(dev, VERT_FREQ_LSB_REG, , 1);
+   temp = (u8)(temp1 >> 8);
+   dm_i2c_write(dev, VERT_FREQ_MSB_REG, , 1);
+
+ 

[v5 5/8] dm: arm64: ls1012a: add i2c DM support

[Biwen Li]

This supports i2c DM and enables CONFIG_DM_I2C
for SoC LS1012A

Reviewed-by: Priyanka Jain 
Signed-off-by: Biwen Li 
---
Changes in v5:
- update subject

Changes in v4:
- update copyright

Changes in v3:
- none

Changes in v2:
- merge some patches to one patch

 arch/arm/include/asm/gpio.h   |   1 +
 board/freescale/ls1012aqds/ls1012aqds.c   |  21 ++-
 board/freescale/ls1012ardb/eth.c  |  36 +
 board/freescale/ls1012ardb/ls1012ardb.c   | 148 +++---
 configs/ls1012a2g5rdb_qspi_defconfig  |   3 +
 configs/ls1012a2g5rdb_tfa_defconfig   |   3 +
 configs/ls1012afrdm_qspi_defconfig|   3 +
 configs/ls1012afrdm_tfa_defconfig |   3 +
 .../ls1012afrwy_qspi_SECURE_BOOT_defconfig|   3 +
 configs/ls1012afrwy_qspi_defconfig|   3 +
 configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig |   3 +
 configs/ls1012afrwy_tfa_defconfig |   3 +
 configs/ls1012aqds_qspi_defconfig |   3 +
 configs/ls1012aqds_tfa_SECURE_BOOT_defconfig  |   3 +
 configs/ls1012aqds_tfa_defconfig  |   3 +
 configs/ls1012ardb_qspi_SECURE_BOOT_defconfig |   3 +
 configs/ls1012ardb_qspi_defconfig |   3 +
 configs/ls1012ardb_tfa_SECURE_BOOT_defconfig  |   3 +
 configs/ls1012ardb_tfa_defconfig  |   3 +
 include/configs/ls1012a_common.h  |   6 +
 20 files changed, 231 insertions(+), 26 deletions(-)

diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
index 6ff5f42424..9f8c9da564 100644
--- a/arch/arm/include/asm/gpio.h
+++ b/arch/arm/include/asm/gpio.h
@@ -3,6 +3,7 @@
!defined(CONFIG_ARCH_BCM63158) && !defined(CONFIG_ARCH_ROCKCHIP) && \
!defined(CONFIG_ARCH_LX2160A) && !defined(CONFIG_ARCH_LS1028A) && \
!defined(CONFIG_ARCH_LS2080A) && !defined(CONFIG_ARCH_LS1088A) && \
+   !defined(CONFIG_ARCH_LS1012A) && \
!defined(CONFIG_ARCH_ASPEED)
 #include 
 #endif
diff --git a/board/freescale/ls1012aqds/ls1012aqds.c 
b/board/freescale/ls1012aqds/ls1012aqds.c
index 86c72ee357..231447895f 100644
--- a/board/freescale/ls1012aqds/ls1012aqds.c
+++ b/board/freescale/ls1012aqds/ls1012aqds.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
  * Copyright 2016 Freescale Semiconductor, Inc.
+ * Copyright 2019 NXP
  */
 
 #include 
@@ -107,10 +108,26 @@ int board_early_init_f(void)
 int misc_init_r(void)
 {
u8 mux_sdhc_cd = 0x80;
-
-   i2c_set_bus_num(0);
+   int bus_num = 0;
+
+#ifdef CONFIG_DM_I2C
+   struct udevice *dev;
+   int ret;
+
+   ret = i2c_get_chip_for_busnum(bus_num, CONFIG_SYS_I2C_FPGA_ADDR,
+ 1, );
+   if (ret) {
+   printf("%s: Cannot find udev for a bus %d\n", __func__,
+  bus_num);
+   return ret;
+   }
+   dm_i2c_write(dev, 0x5a, _sdhc_cd, 1);
+#else
+   i2c_set_bus_num(bus_num);
 
i2c_write(CONFIG_SYS_I2C_FPGA_ADDR, 0x5a, 1, _sdhc_cd, 1);
+#endif
+
return 0;
 }
 #endif
diff --git a/board/freescale/ls1012ardb/eth.c b/board/freescale/ls1012ardb/eth.c
index b35d5343e4..2283f0affe 100644
--- a/board/freescale/ls1012ardb/eth.c
+++ b/board/freescale/ls1012ardb/eth.c
@@ -2,6 +2,7 @@
 /*
  * Copyright 2015-2016 Freescale Semiconductor, Inc.
  * Copyright 2017 NXP
+ * Copyright 2019 NXP
  */
 
 #include 
@@ -27,12 +28,47 @@ static inline void ls1012ardb_reset_phy(void)
 {
 #ifdef CONFIG_TARGET_LS1012ARDB
/* Through reset IO expander reset both RGMII and SGMII PHYs */
+#ifdef CONFIG_DM_I2C
+   struct udevice *dev;
+   int ret;
+
+   /*
+* The I2C IO-expander PCAL9555A is mouted on I2C1 bus(bus number is 0).
+*/
+   ret = i2c_get_chip_for_busnum(0, I2C_MUX_IO2_ADDR,
+ 1, );
+   if (ret) {
+   printf("%s: Cannot find udev for a bus %d\n", __func__,
+  0);
+   return;
+   }
+   /* Config port 0
+* - config pin IOXP_RST_ETH1_B and IOXP_RST_ETH2_B
+*   are enabled as an output.
+*/
+   dm_i2c_reg_write(dev, 6, __PHY_MASK);
+
+   /*
+* Set port 0 output a value to reset ETH2 interface
+* - pin IOXP_RST_ETH2_B output 0b0
+*/
+   dm_i2c_reg_write(dev, 2, __PHY_ETH2_MASK);
+   mdelay(10);
+   dm_i2c_reg_write(dev, 2, __PHY_ETH1_MASK);
+   /*
+* Set port 0 output a value to reset ETH1 interface
+* - pin IOXP_RST_ETH1_B output 0b0
+*/
+   mdelay(10);
+   dm_i2c_reg_write(dev, 2, 0xFF);
+#else
i2c_reg_write(I2C_MUX_IO2_ADDR, 6, __PHY_MASK);
i2c_reg_write(I2C_MUX_IO2_ADDR, 2, __PHY_ETH2_MASK);
mdelay(10);
i2c_reg_write(I2C_MUX_IO2_ADDR, 2, __PHY_ETH1_MASK);
mdelay(10);
i2c_reg_write(I2C_MUX_IO2_ADDR, 2, 0xFF);
+#endif
mdelay(50);
 #endif
 }
diff --git a/board/freescale/ls1012ardb/ls1012ardb.c 

[v5 4/8] Kconfigs: layerscape: use a convenient default value for SYS_MALLOC_F_LEN

[Biwen Li]

The default value of CONFIG_SYS_MALLOC_F_LEN (0x400)
leaves U-Boot with not enough memory to load i2c driver
before relocate, causing it to hang.

Change the default value of CONFIG_SYS_MALLOC_F_LEN
for below SoCs,
- LS1012A
- LS1021A
- LS1043A
- LS1046A

Reviewed-by: Priyanka Jain 
Signed-off-by: Biwen Li 
---
Changes in v5:
- none

Changes in v4:
- none

Changes in v3:
- update commit messages

Changes in v2:
- none

 Kconfig | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Kconfig b/Kconfig
index 92fc4fc135..3253428bbf 100644
--- a/Kconfig
+++ b/Kconfig
@@ -147,7 +147,9 @@ config SYS_MALLOC_F_LEN
default 0x1000 if AM33XX
default 0x2800 if SANDBOX
default 0x2000 if (ARCH_IMX8 || ARCH_IMX8M || ARCH_MX7 || \
-  ARCH_MX7ULP || ARCH_MX6 || ARCH_MX5)
+  ARCH_MX7ULP || ARCH_MX6 || ARCH_MX5 || \
+  ARCH_LS1012A || ARCH_LS1021A || ARCH_LS1043A || \
+  ARCH_LS1046A)
default 0x400
help
  Before relocation, memory is very limited on many platforms. Still,
-- 
2.17.1

[v5 2/8] armv8: fsl-layerscape: spl: fix build error when DM_I2C is enabled

[Biwen Li]

Fix below SPL build error when DM_I2C is enabled,
- arch/arm/cpu/armv8/built-in.o: In function `board_init_f:
  arch/arm/cpu/armv8/fsl-layerscape/spl.c:74: undefined reference to 
`i2c_init_all'
  arch/arm/cpu/armv8/fsl-layerscape/spl.c:74:(.text.board_init_f+0x30):
  relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
  `i2c_init_all'
  make[2]: *** [spl/u-boot-spl] Error 1
  make[1]: *** [spl/u-boot-spl] Error 2
  make: *** [sub-make] Error 2
  arch/arm/cpu/armv8/fsl-layerscape/spl.c: In function 'board_init_f':
  arch/arm/cpu/armv8/fsl-layerscape/spl.c:74:2: warning: implicit
  declaration of function 'i2c_init_all'; did you mean 'misc_init_r'?
  [-Wimplicit-function-declaration]`

Reviewed-by: Priyanka Jain 
Signed-off-by: Biwen Li 
---
Changes in v5:
- none

Changes in v4:
- update copyright

Changes in v3:
- update commit messages

Changes in v2:
- none

 arch/arm/cpu/armv8/fsl-layerscape/spl.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/spl.c 
b/arch/arm/cpu/armv8/fsl-layerscape/spl.c
index 58a39e1123..30792afe82 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/spl.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/spl.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
  * Copyright 2014-2015 Freescale Semiconductor, Inc.
+ * Copyright 2019 NXP
  */
 
 #include 
@@ -71,9 +72,11 @@ void board_init_f(ulong dummy)
preloader_console_init();
spl_set_bd();
 
+#ifdef CONFIG_SYS_I2C
 #ifdef CONFIG_SPL_I2C_SUPPORT
i2c_init_all();
 #endif
+#endif
 #ifdef CONFIG_VID
init_func_vid();
 #endif
-- 
2.17.1

[v5 1/8] rtc: pcf8563: Add driver model support

[Biwen Li]

Add support of driver model of pcf8563

Signed-off-by: Biwen Li 
---
Changes in v5:
- none

Changes in v4:
- update commit messages
- update copyright

Changes in v3:
- update commit messages

Changes in v2:
- none

 drivers/rtc/pcf8563.c | 108 ++
 1 file changed, 108 insertions(+)

diff --git a/drivers/rtc/pcf8563.c b/drivers/rtc/pcf8563.c
index a839d6cc98..d99e0b70a6 100644
--- a/drivers/rtc/pcf8563.c
+++ b/drivers/rtc/pcf8563.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
  * (C) Copyright 2001
+ * (C) Copyright 2019 NXP
  * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
  */
 
@@ -12,9 +13,11 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
+#if !CONFIG_IS_ENABLED(DM_RTC)
 static uchar rtc_read  (uchar reg);
 static void  rtc_write (uchar reg, uchar val);
 
@@ -115,3 +118,108 @@ static void rtc_write (uchar reg, uchar val)
 {
i2c_reg_write (CONFIG_SYS_I2C_RTC_ADDR, reg, val);
 }
+#else
+static int pcf8563_rtc_get(struct udevice *dev, struct rtc_time *tmp)
+{
+   int rel = 0;
+   uchar sec, min, hour, mday, wday, mon_cent, year;
+
+   sec = dm_i2c_reg_read(dev, 0x02);
+   min = dm_i2c_reg_read(dev, 0x03);
+   hour= dm_i2c_reg_read(dev, 0x04);
+   mday= dm_i2c_reg_read(dev, 0x05);
+   wday= dm_i2c_reg_read(dev, 0x06);
+   mon_cent = dm_i2c_reg_read(dev, 0x07);
+   year= dm_i2c_reg_read(dev, 0x08);
+
+   debug ("Get RTC year: %02x mon/cent: %02x mday: %02x wday: %02x "
+  "hr: %02x min: %02x sec: %02x\n",
+  year, mon_cent, mday, wday,
+  hour, min, sec);
+   debug ("Alarms: wday: %02x day: %02x hour: %02x min: %02x\n",
+  dm_i2c_reg_read(dev, 0x0C),
+  dm_i2c_reg_read(dev, 0x0B),
+  dm_i2c_reg_read(dev, 0x0A),
+  dm_i2c_reg_read(dev, 0x09));
+
+   if (sec & 0x80) {
+   puts ("### Warning: RTC Low Voltage - date/time not 
reliable\n");
+   rel = -1;
+   }
+
+   tmp->tm_sec = bcd2bin (sec & 0x7F);
+   tmp->tm_min = bcd2bin (min & 0x7F);
+   tmp->tm_hour = bcd2bin (hour & 0x3F);
+   tmp->tm_mday = bcd2bin (mday & 0x3F);
+   tmp->tm_mon = bcd2bin (mon_cent & 0x1F);
+   tmp->tm_year = bcd2bin (year) + ((mon_cent & 0x80) ? 1900 : 2000);
+   tmp->tm_wday = bcd2bin (wday & 0x07);
+   tmp->tm_yday = 0;
+   tmp->tm_isdst = 0;
+
+   debug ("Get DATE: %4d-%02d-%02d (wday=%d)  TIME: %2d:%02d:%02d\n",
+  tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
+  tmp->tm_hour, tmp->tm_min, tmp->tm_sec);
+
+   return rel;
+}
+
+static int pcf8563_rtc_set(struct udevice *dev, const struct rtc_time *tmp)
+{
+   uchar century;
+
+   debug ("Set DATE: %4d-%02d-%02d (wday=%d)  TIME: %2d:%02d:%02d\n",
+  tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
+  tmp->tm_hour, tmp->tm_min, tmp->tm_sec);
+
+   dm_i2c_reg_write(dev, 0x08, bin2bcd(tmp->tm_year % 100));
+
+   century = (tmp->tm_year >= 2000) ? 0 : 0x80;
+   dm_i2c_reg_write(dev, 0x07, bin2bcd(tmp->tm_mon) | century);
+
+   dm_i2c_reg_write(dev, 0x06, bin2bcd(tmp->tm_wday));
+   dm_i2c_reg_write(dev, 0x05, bin2bcd(tmp->tm_mday));
+   dm_i2c_reg_write(dev, 0x04, bin2bcd(tmp->tm_hour));
+   dm_i2c_reg_write(dev, 0x03, bin2bcd(tmp->tm_min));
+   dm_i2c_reg_write(dev, 0x02, bin2bcd(tmp->tm_sec));
+
+   return 0;
+}
+
+static int pcf8563_rtc_reset(struct udevice *dev)
+{
+   /* clear all control & status registers */
+   dm_i2c_reg_write(dev, 0x00, 0x00);
+   dm_i2c_reg_write(dev, 0x01, 0x00);
+   dm_i2c_reg_write(dev, 0x0D, 0x00);
+
+   /* clear Voltage Low bit */
+   dm_i2c_reg_write(dev, 0x02, dm_i2c_reg_read (dev, 0x02) & 0x7F);
+
+   /* reset all alarms */
+   dm_i2c_reg_write(dev, 0x09, 0x00);
+   dm_i2c_reg_write(dev, 0x0A, 0x00);
+   dm_i2c_reg_write(dev, 0x0B, 0x00);
+   dm_i2c_reg_write(dev, 0x0C, 0x00);
+
+   return 0;
+}
+
+static const struct rtc_ops pcf8563_rtc_ops = {
+   .get = pcf8563_rtc_get,
+   .set = pcf8563_rtc_set,
+   .reset = pcf8563_rtc_reset,
+};
+
+static const struct udevice_id pcf8563_rtc_ids[] = {
+   { .compatible = "nxp,pcf8563" },
+   { }
+};
+
+U_BOOT_DRIVER(rtc_pcf8563) = {
+   .name   = "rtc-pcf8563",
+   .id = UCLASS_RTC,
+   .of_match = pcf8563_rtc_ids,
+   .ops= _rtc_ops,
+};
+#endif
-- 
2.17.1

[v5 3/8] i2c: mxc_i2c: add DM_FLAG_PRE_RELOC flag

[Biwen Li]

This adds DM_FLAG_PRE_RELOC flag to probe i2c driver
before relocation

Reviewed-by: Priyanka Jain 
Signed-off-by: Biwen Li 
---
Changes in v5:
- none

Changes in v4:
- update copyright

Changes in v3:
- none

Changes in v2:
- none

 drivers/i2c/mxc_i2c.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index 786b5a2226..1c2a18bed2 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -10,6 +10,7 @@
  *  Copyright (C) 2005 Matthias Blaschke 
  *  Copyright (C) 2007 RightHand Technologies, Inc.
  *  Copyright (C) 2008 Darius Augulis 
+ *  Copyright (C) 2019 NXP
  *
  */
 
@@ -1049,5 +1050,6 @@ U_BOOT_DRIVER(i2c_mxc) = {
.probe = mxc_i2c_probe,
.priv_auto_alloc_size = sizeof(struct mxc_i2c_bus),
.ops = _i2c_ops,
+   .flags = DM_FLAG_PRE_RELOC,
 };
 #endif
-- 
2.17.1

RE: [U-Boot] [PATCH] net/phy: Fix phy_connect() for phy addr 0

[Priyanka Jain]

>-Original Message-
>From: U-Boot  On Behalf Of Marek Vasut
>Sent: Wednesday, December 18, 2019 9:47 PM
>To: joe.hershber...@ni.com
>Cc: u-boot@lists.denx.de; Tom Rini ; Joseph
>Hershberger 
>Subject: Re: [U-Boot] [PATCH] net/phy: Fix phy_connect() for phy addr 0
>
>On 12/18/19 5:15 PM, Joe Hershberger wrote:
>> On Tue, Dec 17, 2019 at 11:55 PM Marek Vasut  wrote:
>>>
>>> On 12/18/19 3:06 AM, Joe Hershberger wrote:
 On Tue, Dec 17, 2019 at 1:04 PM Marek Vasut  wrote:
>
> On 12/17/19 7:47 PM, Joe Hershberger wrote:
>> On Tue, Dec 17, 2019 at 11:46 AM Marek Vasut 
>wrote:
>>>
>>> On 12/17/19 5:25 PM, Joe Hershberger wrote:
 Hi Marek,
>>>
>>> Hi Joe,
>>>
 On Tue, Dec 17, 2019 at 1:39 AM Marek Vasut 
>wrote:
>
> On 11/7/19 9:04 PM, Joe Hershberger wrote:
>> On Thu, Nov 7, 2019 at 1:16 PM Tom Rini 
>wrote:
>>>
>>> On Tue, Nov 05, 2019 at 04:05:11AM +, Priyanka Jain wrote:
>>>
 Fix 'mask' calculation in phy_connect() for phy addr '0'.
 'mask' is getting set to '0x' for phy addr '0'
 in phy_connect() whereas expected value is '0'.


 Signed-off-by: Priyanka Jain 
>>>
>>> Reported-by: tetsu-aoki via github
>>
>> Acked-by: Joe Hershberger 
>
> Sadly, this breaks systems where a PHY is at address 0.
> I have such an STM32MP1 system with LAN8720 PHY and since this
> patch, I cannot use ethernet. Please revert.

 It seems like a case that shouldn't have worked before.
>>>
>>> Eh? PHY at address 0 definitely did work before and must work now.
>>
>> Agreed that a phy at address 0 should work. Not agreed that
>> because the value "0" used to work due to a bug that it must
>> still. Which of these is the statement you are making? Do we
>> already agree or disagree?
>
> I am saying that because a board worked on rc4 and does not work on
> rc5, this is a bug introduced by this patch in rc5 and must be
> fixed before the release.
>
> The address 0 is a PHY broadcast address for some PHYs, it's a
> fixed address for other PHYs. Thus, a PHY at address 0 must work.
> If this is broken now, it's a bug.

 The only thing this patch should change is to not access addresses
 other than 0. I read the data sheet for the LAN8720 and it doesn't
 mention anything about any broadcast behavior, so I'm not sure what
 you're trying to state here.
>>>
>>> Read [1] section 3.7.1 PHYAD[2:0]: PHY ADDRESS CONFIGURATION
>>>
>>> What I am saying is that there are two types of PHYs, ones which
>>> treat PHY address 0 as broadcast and ones which treat it as regular
>address.
>>> This one is the later and is configured as such in my case.
>>>
>>> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww1.
>>>
>microchip.com%2Fdownloads%2Fen%2FDeviceDoc%2F2164B.pdfda
>ta=0
>>>
>2%7C01%7Cpriyanka.jain%40nxp.com%7C5270d34d955647ee66ea08d783d5ab
>c8%7
>>>
>C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637122826047859376
>mp;sd
>>>
>ata=s22V5eU1kUe0030lbvWazQpooiM2OutlJbTxrPjbxs0%3Dreserved=0
>>
>> I see. What's an example of a phy that treats 0 as broadcast?
>
>IIRC KSZ9031 does.
>
 What about
 this board requires the mask to be all 'f's, other than
 specifying the wrong phy address? It seems that in your case the
 phy address is not actually 0 (or the computed mask would find
 it), but your board dts may be setting it to 0 as an "unknown"
 value, but the correct unknown value should be "-1". It seems the
>issue is with these boards.
>>>
>>> Nope, the address is actually configured to 0 in hardware.
>>
>> Can you double check that?
>
> No, sorry, I know the hardware is fixed to 0. Checking it again
> will not change this fact.

 It seems there is no phy driver for this in U-Boot so the generic
 behavior is being used. I'm at a disadvantage of not having this
 board to try. Can you revert this patch and run with debug enabled
 for drivers/net/phy/phy.c to determine what is happening for this
 board? I would appreciate you helping with this.
>>>
>>> It only says "connected to Generic PHY" .
>>>
>>> So looking at the commit message, I am not really sure which board or
>>> issue does this patch fix. But if I understand the commit message
>>> right, then the aim is to set mask to 0 instead of 0x for address 0.
>>> But that's not right either, the mask should be BIT(0) = 1 for
>>> address 0, and that's what the patch actually does. I guess this then
>>> fails somewhere further down the road ...
>>
>> Yes, the commit message is wrong... the expected value is 1, not 0.  I
>> missed that in the review.
>>
>> Is the patch you sent earlier a solution for your board or something
>> unrelated you found 

Re: [PATCH] riscv: Add option to print registers on exception

[Rick Chen]

Hi Sean

> From: Sean Anderson [mailto:sean...@gmail.com]
> Sent: Wednesday, December 18, 2019 10:32 AM
> To: u-boot@lists.denx.de
> Cc: Rick Jian-Zhi Chen(陳建志)
> Subject: [PATCH] riscv: Add option to print registers on exception
>
> When debugging, it can be helpful to see more information about an unhandled 
> exception. This patch adds an option to view the registers at the time of the 
> trap, similar to the linux output on a kernel panic.
>
> Signed-off-by: Sean Anderson 
> ---
>  arch/riscv/Kconfig  |  3 +++
>  arch/riscv/cpu/mtrap.S  |  3 ++-
>  arch/riscv/lib/interrupts.c | 50 +
>  3 files changed, 44 insertions(+), 12 deletions(-)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 
> 85e15ebffa..3338b788f8 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -222,6 +222,9 @@ config XIP
>   from a NOR flash memory without copying the code to ram.
>   Say yes here if U-Boot boots from flash directly.
>
> +config SHOW_REGS
> +   bool "Show registers on unhandled exception"
> +
>  config STACK_SIZE_SHIFT
> int
> default 14
> diff --git a/arch/riscv/cpu/mtrap.S b/arch/riscv/cpu/mtrap.S index 
> 407ecfa9c0..e40c7bd3f4 100644
> --- a/arch/riscv/cpu/mtrap.S
> +++ b/arch/riscv/cpu/mtrap.S
> @@ -64,7 +64,8 @@ trap_entry:
> SREG x31, 31 * REGBYTES(sp)
> csrr a0, MODE_PREFIX(cause)
> csrr a1, MODE_PREFIX(epc)
> -   mv a2, sp
> +   csrr a2, MODE_PREFIX(tval)
> +   mv a3, sp
> jal handle_trap
> csrw MODE_PREFIX(epc), a0
>
> diff --git a/arch/riscv/lib/interrupts.c b/arch/riscv/lib/interrupts.c index 
> 3b25c5b7a7..0f1e5123d2 100644
> --- a/arch/riscv/lib/interrupts.c
> +++ b/arch/riscv/lib/interrupts.c
> @@ -5,6 +5,8 @@
>   *
>   * Copyright (C) 2017 Andes Technology Corporation
>   * Rick Chen, Andes Technology Corporation 
> + *
> + * Copyright (C) 2019 Sean Anderson 
>   */
>
>  #include 
> @@ -13,7 +15,34 @@
>  #include 
>  #include 
>
> -static void _exit_trap(ulong code, ulong epc, struct pt_regs *regs)
> +static void show_regs(struct pt_regs *regs) { #ifdef CONFIG_SHOW_REGS
> +   printf("RA: " REG_FMT " SP:  " REG_FMT " GP:  " REG_FMT "\n",
> +  regs->ra, regs->sp, regs->gp);
> +   printf("TP: " REG_FMT " T0:  " REG_FMT " T1:  " REG_FMT "\n",
> +  regs->tp, regs->t0, regs->t1);
> +   printf("T2: " REG_FMT " S0:  " REG_FMT " S1:  " REG_FMT "\n",
> +  regs->t2, regs->s0, regs->s1);
> +   printf("A0: " REG_FMT " A1:  " REG_FMT " A2:  " REG_FMT "\n",
> +  regs->a0, regs->a1, regs->a2);
> +   printf("A3: " REG_FMT " A4:  " REG_FMT " A5:  " REG_FMT "\n",
> +  regs->a3, regs->a4, regs->a5);
> +   printf("A6: " REG_FMT " A7:  " REG_FMT " S2:  " REG_FMT "\n",
> +  regs->a6, regs->a7, regs->s2);
> +   printf("S3: " REG_FMT " S4:  " REG_FMT " S5:  " REG_FMT "\n",
> +  regs->s3, regs->s4, regs->s5);
> +   printf("S6: " REG_FMT " S7:  " REG_FMT " S8:  " REG_FMT "\n",
> +  regs->s6, regs->s7, regs->s8);
> +   printf("S9: " REG_FMT " S10: " REG_FMT " S11: " REG_FMT "\n",
> +  regs->s9, regs->s10, regs->s11);
> +   printf("T3: " REG_FMT " T4:  " REG_FMT " T5:  " REG_FMT "\n",
> +  regs->t3, regs->t4, regs->t5);
> +   printf("T6: " REG_FMT "\n", regs->t6); #endif }
> +
> +static void _exit_trap(ulong code, ulong epc, ulong tval, struct
> +pt_regs *regs)
>  {
> static const char * const exception_code[] = {
> "Instruction address misaligned",
> @@ -34,14 +63,13 @@ static void _exit_trap(ulong code, ulong epc, struct 
> pt_regs *regs)
> "Store/AMO page fault",
> };
>
> -   if (code < ARRAY_SIZE(exception_code)) {
> -   printf("exception code: %ld , %s , epc %lx , ra %lx\n",
> -  code, exception_code[code], epc, regs->ra);
> -   } else {
> -   printf("reserved exception code: %ld , epc %lx , ra %lx\n",
> -  code, epc, regs->ra);
> -   }
> +   if (code < ARRAY_SIZE(exception_code))
> +   printf("Unhandled exception: %s\n", exception_code[code]);
> +   else
> +   printf("Unhandled exception code: %ld\n", code);
>
> +   printf("PC: " REG_FMT " TVAL: " REG_FMT "\n", epc, tval);

Please modify PC as EPC.

LGTM.
Other than that,

Thanks
Rick

> +   show_regs(regs);
> hang();
>  }
>
> @@ -65,7 +93,7 @@ int disable_interrupts(void)
> return 0;
>  }
>
> -ulong handle_trap(ulong cause, ulong epc, struct pt_regs *regs)
> +ulong handle_trap(ulong cause, ulong epc, ulong tval, struct pt_regs
> +*regs)
>  {
> ulong is_irq, irq;
>
> @@ -83,11 +111,11 @@ ulong handle_trap(ulong cause, ulong epc, struct pt_regs 
> *regs)
> timer_interrupt(0); /* handle timer interrupt */
> break;
> 

Re: [U-Boot] [PATCH] qemu-riscv64_smode, sifive-fu540: fix extlinux (define preboot)

[David Abdurachmanov]

On Thu, Dec 19, 2019 at 12:18 AM Vagrant Cascadian  wrote:
>
> On 2019-12-18, David Abdurachmanov wrote:
> > On Wed, Dec 18, 2019 at 3:13 AM Vagrant Cascadian  
> > wrote:
> >>
> >> On 2019-09-25, Vagrant Cascadian wrote:
> >> > On 2019-08-21, David Abdurachmanov wrote:
> >> >> Commit 37304aaf60bf92a5dc3ef222ba520698bd862a44 removed preboot
> >> >> commands in RISC-V targets and broke extlinux support as reported
> >> >> by Fu Wei .
> >> >>
> >> >> The patch finishes migration of CONFIG_USE_PREBOOT and CONFIG_REBOOT
> >> >> to Kconfig.
> >> >
> >> > Tested using qemu-riscv64_smode and it fixes extlinux booting. Thanks!
> >> >
> >> > Please CC me on future updates to the patch series.
> >> >
> >> > Tested-by: Vagrant Cascadian 
> >>
> >> This patch, or something like it, is still needed with u-boot
> >> v2020.01-rc5 for extlinux support to load the device-tree from the boot
> >> firmware.
> >>
> >> Is there a new approach in the works, or any chance to see something
> >> like this get merged soon?
> >
> > I do carry several experiment patches in Fedora/RISCV, which I didn't
> > yet sent for a review.
> > Basically that allows me to boot a single Fedora/RISCV disk image on
> > QEMU virt machine
> > and SiFive Unleashed.
> >
> > See: 
> > http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/uboot-tools.spec#L36
> >
> > Note some of the patches were merged in rc5.
>
> Thanks! I'll give your patches some testing when I get a chance.
>
>
> Some potentially quite naive questions:
>
> > You would want the following two patches:
> > http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/riscv64-set-fdt_addr.patch
>
> Why does it need fdt_addr=0x8800 need to be set (and to the same
> value as fdt_addr_r)? According to README fdt_addr is for the flash
> media, which I don't think is used in the qemu case, at least. Is
> fdt_addr being (ab)used for some other purpose? I guess the README also
> gives free reign to use the variables for other purposes... but it would
> be good to know why that is needed vs. just using fdt_addr_r as
> documented.

The comments in uboot-tools.spec explain it.
This is only needed if you use EXTLINUX to boot your image. IIRC
EXTLINUX will assume DTB blob is available at fdt_addr or you can load
one via fdt/fdtdir label in extlinux.conf (never tried).
If you are booting in some other way you probably don't care about it.

>
>
> > http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/riscv-bootargs-preboot.patch
>
> CONFIG_PREBOOT="cp.l ${fdtcontroladdr} ${fdt_addr_r} 0x1;"

This used to solve memory corruption for DTB in v5.3 kernel IIRC. That
was fixed in v5.4 kernel thus should be removed (I will test later).

>
> What does cp.l do?
>
> Do you need to force setting the console in CONFIG_BOOTARGS? It seemed
> to autodetect the console on the installations I have running, possibly
> getting the chosen console from device-tree?

It doesn't detect it for me. Well it does on QEMU, but not on SiFive
Unleashed. Both use different console (ttyS0 vs ttySIF0). I think the
kernel doesn't look into chosen console expect powerpc IIRC.

I can retest since this was added:
https://github.com/torvalds/linux/commit/2993c9b04e616df0848b655d7202a707a70fc876

I am updating kernel in Fedora/RISCV to 5.5-rc2 now thus I can
re-check various patches again.

david
>
>
> live well,
>   vagrant

Re: [PATCH v2 1/4] serial: ns16550: Support run-time configuration

[Simon Glass]

Hi Bin,

On Mon, 16 Dec 2019 at 00:03, Bin Meng  wrote:
>
> Hi Simon,
>
> On Wed, Dec 11, 2019 at 3:35 AM Park, Aiden  wrote:
> >
> > Hi Simon,
> >
> > > -Original Message-
> > > From: U-Boot  On Behalf Of Simon Glass
> > > Sent: Monday, December 9, 2019 8:59 AM
> > > To: U-Boot Mailing List 
> > > Cc: Stefan Roese ; Angelo Dureghello 
> > > Subject: [PATCH v2 1/4] serial: ns16550: Support run-time configuration
> > >
> > > At present this driver uses an assortment of CONFIG options to control how
> > > it accesses the hardware. This is painful for platforms that are supposed 
> > > to be
> > > controlled by a device tree or a previous-stage bootloader.
> > >
> > > Add a new CONFIG option to enable fully dynamic configuration. This
> > > controls register spacing, size, offset and endianness.
> > >
> > > Signed-off-by: Simon Glass 
> > > ---
> > >
> > > Changes in v2:
> > > - runtime -> run-time
> > > - Enable run-time config for slimbootloader too
> > > - Improve Kconfig help based on Bin's comments
> > > - Use ns16550 in patch subject
> > >
> > >  drivers/serial/Kconfig   | 21 +++
> > >  drivers/serial/ns16550.c | 57 ++
> > > --
> > >  include/ns16550.h| 13 +
> > >  3 files changed, 83 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index
> > > ece7d87d4c..472a9f0929 100644
> > > --- a/drivers/serial/Kconfig
> > > +++ b/drivers/serial/Kconfig
> > > @@ -598,6 +598,27 @@ config SYS_NS16550
> > > be used. It can be a constant or a function to get clock, eg,
> > > get_serial_clock().
> > >
> > > +config NS16550_DYNAMIC
> > > + bool "Allow NS16550 to be configured at runtime"
> > > + default y if SYS_COREBOOT || SYS_SLIMBOOTLOADER
> > > + help
> > > +   Enable this option to allow device-tree control of the driver.
> > > +
> > > +   Normally this driver is controlled by the following options:
> > > +
> > > +   CONFIG_SYS_NS16550_PORT_MAPPED - indicates that port I/O is
> > > used for
> > > +  access. If not enabled, then the UART is memory-mapped.
> > > +   CONFIG_SYS_NS16550_MEM32 - if memory-mapped, indicates that
> > > 32-bit
> > > +  access should be used (instead of 8-bit)
> > > +   CONFIG_SYS_NS16550_REG_SIZE - indicates register width and also
> > > +  endianness. If positive, big-endian access is used. If 
> > > negative,
> > > +  little-endian is used.
> > > +
> > > +   It is not a good practice for a driver to be statically 
> > > configured,
> > > +   since it prevents the same driver being used for different types 
> > > of
> > > +   UARTs in a system. This option avoids this problem at the cost of 
> > > a
> > > +   slightly increased code size.
> > > +
> > >  config INTEL_MID_SERIAL
> > >   bool "Intel MID platform UART support"
> > >   depends on DM_SERIAL && OF_CONTROL
> > > diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index
> > > 754b6e9921..96c4471efd 100644
> > > --- a/drivers/serial/ns16550.c
> > > +++ b/drivers/serial/ns16550.c
> > > @@ -92,19 +92,57 @@ static inline int serial_in_shift(void *addr, int 
> > > shift)
> > > #define CONFIG_SYS_NS16550_CLK  0  #endif
> > >
> > > +static void serial_out_dynamic(struct ns16550_platdata *plat, u8 *addr,
> > > +int value)
> > > +{
> > > + if (plat->flags & NS16550_FLAG_BE) {
> > > + if (plat->reg_width == 1)
> > > + writeb(value, addr + (1 << plat->reg_shift) - 1);
> > > + else if (plat->flags & NS16550_FLAG_IO)
> > > + out_be32(addr, value);
> > > + else
> > > + writel(value, addr);
> > > + } else {
> > > + if (plat->reg_width == 1)
> > > + writeb(value, addr);
> > > + else if (plat->flags & NS16550_FLAG_IO)
> > > + out_le32(addr, value);
> > > + else
> > > + writel(value, addr);
> > > + }
> > > +}
> > IO needs to use outb(). It breaks QEMU 0x3f8 IO (reg_width = 1, flags=IO).
> > I have verified 0x3f8 IO on QEMU and MMIO32 on APL with below code.
> > if (plat->flags & NS16550_FLAG_IO) {
> > outb(value, addr);
> > } else {
> > if (plat->flags & NS16550_FLAG_BE) {
> > if (plat->reg_width == 1)
> > writeb(value, addr + (1 << plat->reg_shift) 
> > - 1);
> > else
> > out_be32(addr, value);
> > } else {
> > if (plat->reg_width == 1)
> > writeb(value, addr);
> > else
> > out_le32(addr, value);
> > }
> > }
> >
>
> Would you post a v3 that fixes the issue that Aiden pointed 

Re: [RFC PATCH] Revert "arm: Show cache warnings in U-Boot proper only"

[André Przywara]

On 19/12/2019 00:55, Marek Vasut wrote:

Hi Marek,

> On 12/19/19 1:52 AM, Andre Przywara wrote:
>> According to commit 11aa6a32eb5f ("arm: cache: Implement cache range
>> check for v7"), which introduced check_cache_range(), this was meant
>> as a pure debugging feature, only to be compiled in when a developer
>> explicitly #defined DEBUG in cache.c. Presumably the intention was to
>> help with finding *certain* alignment issues with DMA buffers.
>>
>> Commit bcc53bf09589 ("arm: Show cache warnings in U-Boot proper only")
>> compiled this in *unconditionally* into U-Boot proper.
>>
>> This has the annoying side effect of producing tons of somewhat
>> pointless warnings about non-aligned clean operations, which
>> tend to be appeased by even more pointless rounding operations in many
>> drivers (mostly those used on ARM boards).
>>
>> Bring back the old behaviour, of only compiling this in for DEBUG
>> situations, but staying silent otherwise.
>>
>> This reverts commit bcc53bf095893fbdae531a9a7b5d4ef4a125a7fc.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>> Hi,
>>
>> if the intention was indeed to always force cache maintenance range
>> alignments, I would like to open a discussion on this, because I believe
>> it is not useful, especially in the clean case.
> 
> Why don't you rather fix the cache op alignment bugs ?

Which bugs do you mean?

Those that would currently trigger those warnings?
I don't think they are actual bugs, besides I don't think they are any
cases left for 32-bit ARM boards (leave alone the new RPi4 Ethernet
driver in the rpi-4-32b_defconfig).

Or those that are currently hidden because we *force* an alignment on
the *arguments* passed to invalidate_dcache_range, for instance?
These are quite numerous, so I would rather get some input first before
spending a lot of time on this.

Starting a discussion on this topic and getting some feedback was the
actual reason for this patch - even though it is still valid, IMHO.

Cheers,
Andre

Re: [RFC PATCH] Revert "arm: Show cache warnings in U-Boot proper only"

[Marek Vasut]

On 12/19/19 1:52 AM, Andre Przywara wrote:
> According to commit 11aa6a32eb5f ("arm: cache: Implement cache range
> check for v7"), which introduced check_cache_range(), this was meant
> as a pure debugging feature, only to be compiled in when a developer
> explicitly #defined DEBUG in cache.c. Presumably the intention was to
> help with finding *certain* alignment issues with DMA buffers.
> 
> Commit bcc53bf09589 ("arm: Show cache warnings in U-Boot proper only")
> compiled this in *unconditionally* into U-Boot proper.
> 
> This has the annoying side effect of producing tons of somewhat
> pointless warnings about non-aligned clean operations, which
> tend to be appeased by even more pointless rounding operations in many
> drivers (mostly those used on ARM boards).
> 
> Bring back the old behaviour, of only compiling this in for DEBUG
> situations, but staying silent otherwise.
> 
> This reverts commit bcc53bf095893fbdae531a9a7b5d4ef4a125a7fc.
> 
> Signed-off-by: Andre Przywara 
> ---
> Hi,
> 
> if the intention was indeed to always force cache maintenance range
> alignments, I would like to open a discussion on this, because I believe
> it is not useful, especially in the clean case.

Why don't you rather fix the cache op alignment bugs ?

[RFC PATCH] Revert "arm: Show cache warnings in U-Boot proper only"

[Andre Przywara]

According to commit 11aa6a32eb5f ("arm: cache: Implement cache range
check for v7"), which introduced check_cache_range(), this was meant
as a pure debugging feature, only to be compiled in when a developer
explicitly #defined DEBUG in cache.c. Presumably the intention was to
help with finding *certain* alignment issues with DMA buffers.

Commit bcc53bf09589 ("arm: Show cache warnings in U-Boot proper only")
compiled this in *unconditionally* into U-Boot proper.

This has the annoying side effect of producing tons of somewhat
pointless warnings about non-aligned clean operations, which
tend to be appeased by even more pointless rounding operations in many
drivers (mostly those used on ARM boards).

Bring back the old behaviour, of only compiling this in for DEBUG
situations, but staying silent otherwise.

This reverts commit bcc53bf095893fbdae531a9a7b5d4ef4a125a7fc.

Signed-off-by: Andre Przywara 
---
Hi,

if the intention was indeed to always force cache maintenance range
alignments, I would like to open a discussion on this, because I believe
it is not useful, especially in the clean case.

Cheers,
Andre.

 arch/arm/lib/cache.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/lib/cache.c b/arch/arm/lib/cache.c
index 007d4ebc49..f6c5c774cd 100644
--- a/arch/arm/lib/cache.c
+++ b/arch/arm/lib/cache.c
@@ -57,8 +57,8 @@ int check_cache_range(unsigned long start, unsigned long stop)
ok = 0;
 
if (!ok) {
-   warn_non_spl("CACHE: Misaligned operation at range [%08lx, 
%08lx]\n",
-start, stop);
+   debug("CACHE: Misaligned operation at range [%08lx, %08lx]\n",
+ start, stop);
}
 
return ok;
-- 
2.14.5

Re: [PATCH] drivers: net: fsl_enetc: use write_hwaddr()

[Michael Walle]

Am 2019-12-18 19:44, schrieb Alexandru Marginean:

Hi Michael,

On 12/18/2019 5:47 PM, Michael Walle wrote:

Intead of setting the MAC address in enetc_start() use the proper
write_hwaddr(). U-Boot takes care of the random MAC address, too. 
Also,

this will correctly handle ethNmacskip etc.

Signed-off-by: Michael Walle 
---
  drivers/net/fsl_enetc.c | 17 -
  1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/net/fsl_enetc.c b/drivers/net/fsl_enetc.c
index e86f3dddb5..1949530460 100644
--- a/drivers/net/fsl_enetc.c
+++ b/drivers/net/fsl_enetc.c
@@ -272,14 +272,19 @@ static int enetc_remove(struct udevice *dev)
return 0;
  }
  -/* ENETC Port MAC address registers, accepts big-endian format */
-static void enetc_set_primary_mac_addr(struct enetc_priv *priv, const 
u8 *addr)

+static int enetc_write_hwaddr(struct udevice *dev)
  {
+   struct eth_pdata *plat = dev_get_platdata(dev);
+   struct enetc_priv *priv = dev_get_priv(dev);
+   u8 *addr = plat->enetaddr;
+
u16 lower = *(const u16 *)(addr + 4);
u32 upper = *(const u32 *)addr;
enetc_write_port(priv, ENETC_PSIPMAR0, upper);
enetc_write_port(priv, ENETC_PSIPMAR1, lower);


The SI registers hold temporary values which are cleared on FLR.
These MAC addresses will be wiped out at the next _start.  The
persistent values are the one stored in IERB.  Is this what you want?


Yes that was actually the intention. These register names are very
confusing ;)




+
+   return 0;
  }
/* Configure port parameters (# of rings, frame size, enable port) 
*/
@@ -410,7 +415,6 @@ static void enetc_setup_rx_bdr(struct udevice 
*dev)

   */
  static int enetc_start(struct udevice *dev)
  {
-   struct eth_pdata *plat = dev_get_platdata(dev);
struct enetc_priv *priv = dev_get_priv(dev);
/* reset and enable the PCI device */
@@ -418,12 +422,6 @@ static int enetc_start(struct udevice *dev)
dm_pci_clrset_config16(dev, PCI_COMMAND, 0,
   PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER);
  - if (!is_valid_ethaddr(plat->enetaddr)) {
-   enetc_dbg(dev, "invalid MAC address, generate random ...\n");
-   net_random_ethaddr(plat->enetaddr);
-   }
-   enetc_set_primary_mac_addr(priv, plat->enetaddr);
-


This looks like the right thing to do, but with enetc_write_hwaddr
writing to IERB.  Do you want to send a v2, or do you want me to pick
it up?


I'll send a v2 tomorrow.

-michael

Re: [PATCH] dm: uclass: don't assign aliased seq numbers

[Michael Walle]

Am 2019-12-18 21:00, schrieb Alexandru Marginean:

Hi Michael,

On 12/18/2019 5:42 PM, Michael Walle wrote:

If there are aliases for an uclass, set the base for the "dynamically"
allocated numbers next to the highest alias.

Please note, that this might lead to holes in the sequences, depending
on the device tree. For example if there is only an alias "ethernet1",
the next device seq number would be 2.

In particular this fixes a problem with boards which are using 
ethernet
aliases but also might have network add-in cards like the E1000. If 
the
board is started with the add-in card and depending on the order of 
the

drivers, the E1000 might occupy the first ethernet device and mess up
all the hardware addresses, because the devices are now shifted by 
one.


As a side effect, this should also make the following commits
superfluous:
  - 7f3289bf6d ("dm: device: Request next sequence number")
  - 61607225d1 ("i2c: Fill req_seq in i2c_post_bind()")
Although I don't understand the root cause of the said problem.

Thomas, Michal, could you please test this and then I'd add a second
patch removing the old code.

Cc: Thomas Fitzsimmons 
Cc: Michal Simek 

Signed-off-by: Michael Walle 
---
  drivers/core/uclass.c | 20 ++--
  1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index c520ef113a..c3b325141a 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -675,13 +675,14 @@ int uclass_unbind_device(struct udevice *dev)
int uclass_resolve_seq(struct udevice *dev)
  {
+   struct uclass *uc = dev->uclass;
+   struct uclass_driver *uc_drv = uc->uc_drv;
struct udevice *dup;
-   int seq;
+   int seq = 0;
int ret;
assert(dev->seq == -1);
-	ret = uclass_find_device_by_seq(dev->uclass->uc_drv->id, 
dev->req_seq,

-   false, );
+	ret = uclass_find_device_by_seq(uc_drv->id, dev->req_seq, false, 
);

if (!ret) {
dm_warn("Device '%s': seq %d is in use by '%s'\n",
dev->name, dev->req_seq, dup->name);
@@ -693,9 +694,16 @@ int uclass_resolve_seq(struct udevice *dev)
return ret;
}
  - for (seq = 0; seq < DM_MAX_SEQ; seq++) {
-   ret = uclass_find_device_by_seq(dev->uclass->uc_drv->id, seq,
-   false, );
+   if (CONFIG_IS_ENABLED(DM_SEQ_ALIAS) &&
+   (uc_drv->flags & DM_UC_FLAG_SEQ_ALIAS)) {
+   /* dev_read_alias_highest_id() will return -1 if there no


nits: there /is/ no and multi-line comment starts with just /* on the 
1st line


yeah, I'd prefer that style too. But checkpatch.pl would complain
about it.. or so I thought.. well seems only to be the case in linux and
only in "NETWORKING_BLOCK_COMMENT_STYLE" (only for net/ and 
drivers/net/).


I'll definitely fix that ;)




+* alias. Thus we can always add one.
+*/
+   seq = dev_read_alias_highest_id(uc_drv->name) + 1;
+   }
+
+   for (; seq < DM_MAX_SEQ; seq++) {
+   ret = uclass_find_device_by_seq(uc_drv->id, seq, false, );
if (ret == -ENODEV)
break;
if (ret)




Reviewed-by: Alex Marginean 
Tested-by: Alex Marginean 

This looks nice.
One thing I noticed is that 'dm tree' indexes now don't match dev->seq
which can be a bit confusing.  The index is produced by
dev_get_uclass_index, which in effect counts devices in the uclass.
Any issue if 'dm tree' prints dev->seq instead and maybe call the
column Seq rather than Index?


Mhh, did this ever match if req_seq/aliases was used? "dm uclass" dumps
the seq and req_seq. So I don't know if that was ever intended to match.
But I'm open to suggestions.

-michael

Re: OMAP L138 LCDK - giving up maintainership

[Peter Howard]

On Wed, 2019-12-18 at 18:26 +0530, Sekhar Nori wrote:
> On 18/12/19 6:15 PM, Adam Ford wrote:
> > On Tue, Dec 17, 2019 at 5:15 PM Peter Howard <
> > p...@northern-ridge.com.au> wrote:
> > > Tom and others,
> > > 
> > > I finish at my current job on Friday, as such I will have no
> > > immediate
> > > involvement with the L138 chip (not that I've had that much in
> > > recent
> > > times).  So it makes sense to remove me as
> > > maintainer.  Especially as
> > > the email listed for me will start bouncing.  so is the simplest
> > > way
> > 
> > Best wishes in the new endeavors.
> > 
> > > just to submit a patch clearing out the maintainer entry in
> > > board/davinci/da8xxevm/MAINTAINERS ?  Also does anyone on the
> > > list wish
> > > to take over?  Adam, I know you don't have the time from recent
> > > emails.
> > 
> > Because my employer views the LCDK as the replacement to the
> > product
> > they made (da850-evm), I don't think they would take kindly to me
> > being the maintainer of it.  I have been helping where can I to try
> > and unify those two devices as much as I can, because I think there
> > is
> > value in sharing as many of the resources as possible.  I have an
> > LCDK, and I will continue to help where I can.
> > 
> > > Bartosz?  Sekhar - do you want to nominate someone from TI?
> 
> Lokesh from TI has been a prolific U-Boot contributor. Has access to
> LCDK board. I just requested him to take up LCDK maintainership and
> he
> agreed.

Can I assume that he will submit a the patch to change over to him?

> 
> Thanks,
> Sekhar
-- 
Peter Howard 


signature.asc
Description: This is a digitally signed message part

Re: [U-Boot] [PATCH] rockchip: rk3399: Add Pinebook Pro laptop support

[Vagrant Cascadian]

On 2019-11-14, Peter Robinson wrote:
> Add initial support for Pinebook Pro laptop.
>
> Specification
> - Rockchip RK3399
> - 4GB Dual-Channel LPDDR4
> - SD card slot
> - eMMC socket
> - 128Mb SPI Flash
> - PCIe 4X slot
> - AP6256 for WiFi + BT
> - 1920*1080 screen
> - USB 3.0, 2.0
> - USB Type C power and data
> - DC 12V/2A

5V/3A, as already mentioned.

> Signed-off-by: Peter Robinson 
> ---
>
> Initial v1 for feedback

Tested on u-boot v2020.01-rc5; applied with trivial adjustments.

Thanks for working on it!

Tested-by: Vagrant Cascadian 

live well,
  vagrant

> U-Boot TPL 2020.01-rc2-5-g7d87be0ff5 (Nov 14 2019 - 00:27:33)
> Trying to boot from BOOTROM
> Returning to boot ROM...
>
> U-Boot SPL 2020.01-rc2-5-g7d87be0ff5 (Nov 14 2019 - 00:27:33 +)
> Trying to boot from MMC1
>
>
> U-Boot 2020.01-rc2-5-g7d87be0ff5 (Nov 14 2019 - 00:27:33 +)
>
> Model: Pine64 Pinebook Pro
> DRAM:  3.9 GiB
> PMIC:  RK808 
> MMC:   dwmmc@fe32: 1, sdhci@fe33: 0
> In:serial@ff1a
> Out:   serial@ff1a
> Err:   serial@ff1a
> Model: Pine64 Pinebook Pro
> ## Error: Can't overwrite "serial#"
> ## Error inserting "serial#" variable, errno=1
> rockchip_dnl_key_pressed: adc_channel_single_shot fail!
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0 
> =>
>
>
>  arch/arm/dts/Makefile |   1 +
>  arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi  |  25 +
>  arch/arm/dts/rk3399-pinebook-pro.dts  | 631 ++
>  arch/arm/mach-rockchip/rk3399/Kconfig |   8 +
>  board/pine64/pinebook_pro_rk3399/Kconfig  |  15 +
>  board/pine64/pinebook_pro_rk3399/MAINTAINERS  |   8 +
>  board/pine64/pinebook_pro_rk3399/Makefile |   1 +
>  .../pinebook_pro_rk3399/pinebook-pro-rk3399.c | 192 ++
>  configs/pinebook_pro-rk3399_defconfig |  76 +++
>  include/configs/pinebook_pro_rk3399.h |  29 +
>  10 files changed, 986 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-pinebook-pro.dts
>  create mode 100644 board/pine64/pinebook_pro_rk3399/Kconfig
>  create mode 100644 board/pine64/pinebook_pro_rk3399/MAINTAINERS
>  create mode 100644 board/pine64/pinebook_pro_rk3399/Makefile
>  create mode 100644 board/pine64/pinebook_pro_rk3399/pinebook-pro-rk3399.c
>  create mode 100644 configs/pinebook_pro-rk3399_defconfig
>  create mode 100644 include/configs/pinebook_pro_rk3399.h
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 5a64fcc5a7..affedfd666 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -116,6 +116,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
>   rk3399-nanopi-m4.dtb \
>   rk3399-nanopi-neo4.dtb \
>   rk3399-orangepi.dtb \
> + rk3399-pinebook-pro.dtb \
>   rk3399-puma-ddr1333.dtb \
>   rk3399-puma-ddr1600.dtb \
>   rk3399-puma-ddr1866.dtb \
> diff --git a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi 
> b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
> new file mode 100644
> index 00..9b0cb7010f
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
> @@ -0,0 +1,25 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Peter Robinson 
> + */
> +
> +#include "rk3399-u-boot.dtsi"
> +#include "rk3399-sdram-lpddr4-100.dtsi"
> +
> +/ {
> + chosen {
> + u-boot,spl-boot-order = "same-as-spl", , 
> + };
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> +u-boot,dm-pre-reloc;
> +};
> +
> + {
> +u-boot,dm-pre-reloc;
> +};
> diff --git a/arch/arm/dts/rk3399-pinebook-pro.dts 
> b/arch/arm/dts/rk3399-pinebook-pro.dts
> new file mode 100644
> index 00..85ce0206d7
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-pinebook-pro.dts
> @@ -0,0 +1,631 @@
> +/*
> + * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +/dts-v1/;
> +#include 
> +#include 
> +#include 
> +#include "rk3399.dtsi"
> +#include "rk3399-opp.dtsi"
> +
> +/ {
> + model = "Pine64 Pinebook Pro";
> + compatible = "pine64,pinebook-pro", "rockchip,rk3399";
> +
> + chosen {
> + stdout-path = 
> + };
> +
> + aliases {
> + spi0 = 
> + };
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + enable-gpios = < RK_PA0 GPIO_ACTIVE_HIGH>;
> + pwms = < 0 740740 0>;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + autorepeat;
> + pinctrl-names = "default";
> + pinctrl-0 = <>;
> +
> + power {
> + debounce-interval = <100>;
> + gpios = < RK_PA5 GPIO_ACTIVE_LOW>;
> + label = "GPIO Key Power";
> + linux,code = ;
> + wakeup-source;
> + };
> + };
> +
> + leds {
> + status = "okay";
> + 

Re: [PATCH] dm: uclass: don't assign aliased seq numbers

[Alexandru Marginean]

Hi Michael,

On 12/18/2019 5:42 PM, Michael Walle wrote:

If there are aliases for an uclass, set the base for the "dynamically"
allocated numbers next to the highest alias.

Please note, that this might lead to holes in the sequences, depending
on the device tree. For example if there is only an alias "ethernet1",
the next device seq number would be 2.

In particular this fixes a problem with boards which are using ethernet
aliases but also might have network add-in cards like the E1000. If the
board is started with the add-in card and depending on the order of the
drivers, the E1000 might occupy the first ethernet device and mess up
all the hardware addresses, because the devices are now shifted by one.

As a side effect, this should also make the following commits
superfluous:
  - 7f3289bf6d ("dm: device: Request next sequence number")
  - 61607225d1 ("i2c: Fill req_seq in i2c_post_bind()")
Although I don't understand the root cause of the said problem.

Thomas, Michal, could you please test this and then I'd add a second
patch removing the old code.

Cc: Thomas Fitzsimmons 
Cc: Michal Simek 

Signed-off-by: Michael Walle 
---
  drivers/core/uclass.c | 20 ++--
  1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index c520ef113a..c3b325141a 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -675,13 +675,14 @@ int uclass_unbind_device(struct udevice *dev)
  
  int uclass_resolve_seq(struct udevice *dev)

  {
+   struct uclass *uc = dev->uclass;
+   struct uclass_driver *uc_drv = uc->uc_drv;
struct udevice *dup;
-   int seq;
+   int seq = 0;
int ret;
  
  	assert(dev->seq == -1);

-   ret = uclass_find_device_by_seq(dev->uclass->uc_drv->id, dev->req_seq,
-   false, );
+   ret = uclass_find_device_by_seq(uc_drv->id, dev->req_seq, false, );
if (!ret) {
dm_warn("Device '%s': seq %d is in use by '%s'\n",
dev->name, dev->req_seq, dup->name);
@@ -693,9 +694,16 @@ int uclass_resolve_seq(struct udevice *dev)
return ret;
}
  
-	for (seq = 0; seq < DM_MAX_SEQ; seq++) {

-   ret = uclass_find_device_by_seq(dev->uclass->uc_drv->id, seq,
-   false, );
+   if (CONFIG_IS_ENABLED(DM_SEQ_ALIAS) &&
+   (uc_drv->flags & DM_UC_FLAG_SEQ_ALIAS)) {
+   /* dev_read_alias_highest_id() will return -1 if there no


nits: there /is/ no and multi-line comment starts with just /* on the 
1st line



+* alias. Thus we can always add one.
+*/
+   seq = dev_read_alias_highest_id(uc_drv->name) + 1;
+   }
+
+   for (; seq < DM_MAX_SEQ; seq++) {
+   ret = uclass_find_device_by_seq(uc_drv->id, seq, false, );
if (ret == -ENODEV)
break;
if (ret)




Reviewed-by: Alex Marginean 
Tested-by: Alex Marginean 

This looks nice.
One thing I noticed is that 'dm tree' indexes now don't match dev->seq 
which can be a bit confusing.  The index is produced by 
dev_get_uclass_index, which in effect counts devices in the uclass.  Any 
issue if 'dm tree' prints dev->seq instead and maybe call the column Seq 
rather than Index?


Thanks!
Alex

riscv: Sipeed Maix support

[Sean Anderson]

I've been working on adding support for the Sipeed Maix-series boards,
specifically the Bit .
The majority of the work has been going toward the Kendryte K210 CPU,
and should be generalizable to all of the Maix boards. I've gotten
u-boot to reach the relocation stage (at which point if fails silently).
However, before continuing, I'd like to get some feedback on what I've
already written. My current code is located at
.

How is the function fdtdec_setup_memory_banksize_fdt supposed to work?
I've tried different combinations of having a single /memory node,
having multiple /memory@X nodes, and having /memory/memory@foo nodes,
but it never seems to detect anything other than a start and size of
0x0. I've added the device_type = "memory" property, but it doesn't seem
to detect anything. The k210 has two banks of sram adjacent in address
space, each with their own clock. Should these count toward
NR_DRAM_BANKS? Should they be separate top-level memory nodes in the
device tree, or part of a single memory node using ranges to keep the
parent address space?

What configuration should be located in board/*/*/Kconfig and what
should be located in include/configs? It seems like generally only SYS_
configs are in include/configs, but some like SYS_BOARD or SYS_VENDOR
are located in the board Kconfig.

What should the max frequency be for the MicroSD card slot (located in
arch/riscv/dts/k210-maix.dts)? Most other devicetrees I've seen have
some kind of sdhci controller, but this slot is wired directly to one of
the spi controllers.

What does /cpus/timebase-frequency represent? How does it differ from
/cpus/cpu@X/cpu-frequency?

The instruction and data cache line sizes are not specified in the data
sheet. Is it better to over- or underestimate them until they can be
determined?

I'm not sure which drivers (if any) correspond to the gpio, timer,
watchdog, and rtc devices. There are also missing drivers for the kpu,
fft, sha256, aes, dvp, and sysctl devices, but those seem like
non-standard IP blocks at first glance. There are some good descriptions
of the registers at
,
which are themselves derived from
.

Is the way the sysctl device (located on line 326 of
arch/riscv/dts/k210.dtsi) described reasonable? The primary function of
this device is to control clocks and resets, but there are also several
other functions thrown in. For example, there are dma- and power-related
registers located in that address range as well. Presumably a future
k220 could add more (unrelated) functionality to this region.

Which devices should have status = "disabled" in
arch/riscv/dts/k210.dtsi? From looking at other dtsi files, it seems
like only "core devices" should be left enabled, but I'm not sure how to
make that decision for this cpu.

How does the gpio/pin-controller model work? Should the device tree
describe the default configuration, even if it can be changed at
runtime?

There is a region of memory used by the kpu (neural network accelerator)
as scratch memory. When the kpu is disabled, this region may be treated
like any other region of memory. I've left this region out of the device
tree, but since the kpu is unlikely to be needed when u-boot is running,
should this region of memory be added? Perhaps it should be documented
as reserved-memory and referenced by the kpu device?

There is a region of memory at 0x4000 which is a non-cached version
of memory at 0x8000. How should this be described? I believe using
this lower region of memory is necessary for interfacing with the DMA
controller.

This cpu uses both the Andes PLIC and SiFive Clint devices. Currently
they both provide riscv_*_ipi functions, despite their other
functionalities as interrupt controllers and counter controllers,
respectively. Commit b380dbb adds a simple ifdef to disable the ipi
functions of the Andes plic, as IPIs are handled by the clint on the
k210. However, presumably this situation is not unique, and there could
be other processors which include both devices. I think there should be
some kind of kconfig for this, but I'm not sure how it should be worded.
Part of this problem could be fixed by making both devices proper
interrupt-controllers.

The mcounteren CSR raises an exception when written to in
arch/riscv/cpu/cpu.c (c.f. commit b768942). The datasheet claims the
k210 "Support for different privilege levels to improve safety," so
perhaps the k210 only has M and U privilege levels. The exact bits which
cause a problem will need further investigation.

The magic bytes for the device tree get zeroed-out by something prior to
being parsed by u-boot. Trying to write to the magic byte location
causes the device to become unresponsive. The tree is otherwise intact.
The current fix is to just disable the check at runtime 

Re: [PATCH] drivers: net: fsl_enetc: use write_hwaddr()

[Alexandru Marginean]

Hi Michael,

On 12/18/2019 5:47 PM, Michael Walle wrote:

Intead of setting the MAC address in enetc_start() use the proper
write_hwaddr(). U-Boot takes care of the random MAC address, too. Also,
this will correctly handle ethNmacskip etc.

Signed-off-by: Michael Walle 
---
  drivers/net/fsl_enetc.c | 17 -
  1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/net/fsl_enetc.c b/drivers/net/fsl_enetc.c
index e86f3dddb5..1949530460 100644
--- a/drivers/net/fsl_enetc.c
+++ b/drivers/net/fsl_enetc.c
@@ -272,14 +272,19 @@ static int enetc_remove(struct udevice *dev)
return 0;
  }
  
-/* ENETC Port MAC address registers, accepts big-endian format */

-static void enetc_set_primary_mac_addr(struct enetc_priv *priv, const u8 *addr)
+static int enetc_write_hwaddr(struct udevice *dev)
  {
+   struct eth_pdata *plat = dev_get_platdata(dev);
+   struct enetc_priv *priv = dev_get_priv(dev);
+   u8 *addr = plat->enetaddr;
+
u16 lower = *(const u16 *)(addr + 4);
u32 upper = *(const u32 *)addr;
  
  	enetc_write_port(priv, ENETC_PSIPMAR0, upper);

enetc_write_port(priv, ENETC_PSIPMAR1, lower);


The SI registers hold temporary values which are cleared on FLR.  These 
MAC addresses will be wiped out at the next _start.  The persistent 
values are the one stored in IERB.  Is this what you want?



+
+   return 0;
  }
  
  /* Configure port parameters (# of rings, frame size, enable port) */

@@ -410,7 +415,6 @@ static void enetc_setup_rx_bdr(struct udevice *dev)
   */
  static int enetc_start(struct udevice *dev)
  {
-   struct eth_pdata *plat = dev_get_platdata(dev);
struct enetc_priv *priv = dev_get_priv(dev);
  
  	/* reset and enable the PCI device */

@@ -418,12 +422,6 @@ static int enetc_start(struct udevice *dev)
dm_pci_clrset_config16(dev, PCI_COMMAND, 0,
   PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER);
  
-	if (!is_valid_ethaddr(plat->enetaddr)) {

-   enetc_dbg(dev, "invalid MAC address, generate random ...\n");
-   net_random_ethaddr(plat->enetaddr);
-   }
-   enetc_set_primary_mac_addr(priv, plat->enetaddr);
-


This looks like the right thing to do, but with enetc_write_hwaddr 
writing to IERB.  Do you want to send a v2, or do you want me to pick it up?


Thanks!
Alex


enetc_enable_si_port(priv);
  
  	/* setup Tx/Rx buffer descriptors */

@@ -549,6 +547,7 @@ static const struct eth_ops enetc_ops = {
.send   = enetc_send,
.recv   = enetc_recv,
.stop   = enetc_stop,
+   .write_hwaddr = enetc_write_hwaddr,
  };
  
  U_BOOT_DRIVER(eth_enetc) = {

[PATCH] test_env: don't strip() printenv results

[Stephen Warren]

From: Stephen Warren 

get_env() was originally written to strip() the output of printenv to
isolate the test from any whitespace changes in printenv's output.
However, this throws away any whitespace in the variable value, which can
cause issues when test code expects to see that whitespace. In fact,
printenv never adds any whitespace at all, so there's no need to strip.

The strip causes a practical problem for test_env_echo_exists() if
state_test_env.get_existent_var() happens to choose a U-Boot variable that
contains trailing whitespace. This is true for variable boot_targets.

With Python 2, get_existent_var() never returned boot_targets so this
issue never caused a practical problem.

With Python 3, get_existent_var does sometimes return boot_targets, no
doubt due to Python 3's different dict hash key order implementation,
about 0.5-2% of the time, so this test appears intermittent. With the
strip removed, this intermittency is solved, since the test passes for all
possible U-Boot variables.

Signed-off-by: Stephen Warren 
---
 test/py/tests/test_env.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/py/tests/test_env.py b/test/py/tests/test_env.py
index 9bdaef9373fd..6ff38f1020b5 100644
--- a/test/py/tests/test_env.py
+++ b/test/py/tests/test_env.py
@@ -49,7 +49,7 @@ class StateTestEnv(object):
 for l in response.splitlines():
 if not '=' in l:
 continue
-(var, value) = l.strip().split('=', 1)
+(var, value) = l.split('=', 1)
 self.env[var] = value
 
 def get_existent_var(self):
-- 
2.24.1

[PATCH 2/2] u-boot: fit: add support to decrypt fit with aes

[Philippe Reynes]

This commit add to u-boot the support to decrypt
fit image encrypted with aes. The FIT image contains
the key name and the IV name. Then u-boot look for
the key and IV in his device tree and decrypt images
before moving to the next stage.

Signed-off-by: Philippe Reynes 
---
 common/image-cipher.c | 104 ++
 common/image-fit.c|  63 ++
 include/image.h   |  12 ++
 include/u-boot/aes.h  |  13 +++
 lib/Makefile  |   1 +
 lib/aes/Makefile  |   5 +++
 lib/aes/aes-decrypt.c |  41 
 tools/Makefile|   2 +-
 8 files changed, 240 insertions(+), 1 deletion(-)
 create mode 100644 lib/aes/Makefile
 create mode 100644 lib/aes/aes-decrypt.c

diff --git a/common/image-cipher.c b/common/image-cipher.c
index ab8b45b..cee3b03 100644
--- a/common/image-cipher.c
+++ b/common/image-cipher.c
@@ -24,6 +24,7 @@ struct cipher_algo cipher_algos[] = {
.calculate_type = EVP_aes_128_cbc,
 #endif
.encrypt = image_aes_encrypt,
+   .decrypt = image_aes_decrypt,
.add_cipher_data = image_aes_add_cipher_data
},
{
@@ -34,6 +35,7 @@ struct cipher_algo cipher_algos[] = {
.calculate_type = EVP_aes_192_cbc,
 #endif
.encrypt = image_aes_encrypt,
+   .decrypt = image_aes_decrypt,
.add_cipher_data = image_aes_add_cipher_data
},
{
@@ -44,6 +46,7 @@ struct cipher_algo cipher_algos[] = {
.calculate_type = EVP_aes_256_cbc,
 #endif
.encrypt = image_aes_encrypt,
+   .decrypt = image_aes_decrypt,
.add_cipher_data = image_aes_add_cipher_data
}
 };
@@ -61,3 +64,104 @@ struct cipher_algo *image_get_cipher_algo(const char 
*full_name)
 
return NULL;
 }
+
+static int fit_image_setup_decrypt(struct image_cipher_info *info,
+  const void *fit, int image_noffset,
+  int cipher_noffset)
+{
+   const void *fdt = gd_fdt_blob();
+   const char *node_name;
+   char node_path[128];
+   int noffset;
+   char *algo_name;
+   int ret;
+
+   node_name = fit_get_name(fit, image_noffset, NULL);
+   if (!node_name) {
+   printf("Can't get node name\n");
+   return -1;
+   }
+
+   if (fit_image_cipher_get_algo(fit, cipher_noffset, _name)) {
+   printf("Can't get algo name for cipher '%s' in image '%s'\n",
+  node_name, node_name);
+   return -1;
+   }
+
+   info->keyname = fdt_getprop(fit, cipher_noffset, "key-name-hint", NULL);
+   if (!info->keyname) {
+   printf("Can't get key name\n");
+   return -1;
+   }
+
+   info->ivname = fdt_getprop(fit, cipher_noffset, "iv-name-hint", NULL);
+   if (!info->ivname) {
+   printf("Can't get IV name\n");
+   return -1;
+   }
+
+   info->fit = fit;
+   info->node_noffset = image_noffset;
+   info->name = algo_name;
+   info->cipher = image_get_cipher_algo(algo_name);
+   if (!info->cipher) {
+   printf("Can't get cipher\n");
+   return -1;
+   }
+
+   ret = fit_image_get_data_size_unciphered(fit, image_noffset,
+>size_unciphered);
+   if (ret) {
+   printf("Can't get size of unciphered data\n");
+   return -1;
+   }
+
+   /*
+* Search the cipher node in the u-boot fdt
+* the path should be: /cipher/key---
+*/
+   snprintf(node_path, sizeof(node_path), "/%s/key-%s-%s-%s",
+FIT_CIPHER_NODENAME, algo_name, info->keyname, info->ivname);
+
+   noffset = fdt_path_offset(fdt, node_path);
+   if (noffset < 0) {
+   printf("Can't found cipher node offset\n");
+   return -1;
+   }
+
+   /* read key */
+   info->key = fdt_getprop(fdt, noffset, "key", NULL);
+   if (!info->key) {
+   printf("Can't get key in cipher node '%s'\n", node_path);
+   return -1;
+   }
+
+   /* read iv */
+   info->iv = fdt_getprop(fdt, noffset, "iv", NULL);
+   if (!info->iv) {
+   printf("Can't get IV in cipher node '%s'\n", node_path);
+   return -1;
+   }
+
+   return 0;
+}
+
+int fit_image_decrypt_data(const void *fit,
+  int image_noffset, int cipher_noffset,
+  const void *data_ciphered, size_t size_ciphered,
+  void **data_unciphered, size_t *size_unciphered)
+{
+   struct image_cipher_info info;
+   int ret;
+
+   ret = fit_image_setup_decrypt(, fit, image_noffset,
+ cipher_noffset);
+   if (ret < 0)
+   goto out;
+
+   ret = 

[PATCH 1/2] mkimage: fit: add support to encrypt image with aes

[Philippe Reynes]

This commit add the support of encrypting image with aes
in mkimage. To enable the ciphering, a node cipher with
a reference to a key and IV (Initialization Vector) must
be added to the its file. Then mkimage add the encrypted
image to the FIT and add the key and IV to the u-boot
device tree.

Signed-off-by: Philippe Reynes 
---
 Kconfig   |   8 ++
 common/Makefile   |   1 +
 common/image-cipher.c |  63 +++
 common/image-fit.c|  27 +
 include/image.h   |  63 +++
 include/u-boot/aes.h  |  31 ++
 lib/aes/aes-encrypt.c | 136 +++
 tools/Makefile|  14 ++-
 tools/fit_image.c |  83 +-
 tools/image-host.c| 292 ++
 10 files changed, 716 insertions(+), 2 deletions(-)
 create mode 100644 common/image-cipher.c
 create mode 100644 include/u-boot/aes.h
 create mode 100644 lib/aes/aes-encrypt.c

diff --git a/Kconfig b/Kconfig
index 92fc4fc..13e2c6c 100644
--- a/Kconfig
+++ b/Kconfig
@@ -383,6 +383,14 @@ config FIT_ENABLE_RSASSA_PSS_SUPPORT
  Enable this to support the pss padding algorithm as described
  in the rfc8017 (https://tools.ietf.org/html/rfc8017).
 
+config FIT_CIPHER
+   bool "Enable ciphering data in a FIT uImages"
+   depends on DM
+   select AES
+   help
+ Enable the feature of data ciphering/unciphering in the tool mkimage
+ and in the u-boot support of the FIT image.
+
 config FIT_VERBOSE
bool "Show verbose messages when FIT images fail"
help
diff --git a/common/Makefile b/common/Makefile
index 302d8be..a02b073 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -113,6 +113,7 @@ obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += image-fdt.o
 obj-$(CONFIG_$(SPL_TPL_)FIT) += image-fit.o
 obj-$(CONFIG_$(SPL_)MULTI_DTB_FIT) += boot_fit.o common_fit.o
 obj-$(CONFIG_$(SPL_TPL_)FIT_SIGNATURE) += image-sig.o
+obj-$(CONFIG_$(SPL_TPL_)FIT_CIPHER) += image-cipher.o
 obj-$(CONFIG_IO_TRACE) += iotrace.o
 obj-y += memsize.o
 obj-y += stdio.o
diff --git a/common/image-cipher.c b/common/image-cipher.c
new file mode 100644
index 000..ab8b45b
--- /dev/null
+++ b/common/image-cipher.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019, Softathome
+ */
+
+#ifdef USE_HOSTCC
+#include "mkimage.h"
+#include 
+#else
+#include 
+#include 
+DECLARE_GLOBAL_DATA_PTR;
+#endif /* !USE_HOSTCC*/
+#include 
+#include 
+#include 
+
+struct cipher_algo cipher_algos[] = {
+   {
+   .name = "aes128",
+   .key_len = AES128_KEY_LENGTH,
+   .iv_len  = AES_BLOCK_LENGTH,
+#if IMAGE_ENABLE_ENCRYPT
+   .calculate_type = EVP_aes_128_cbc,
+#endif
+   .encrypt = image_aes_encrypt,
+   .add_cipher_data = image_aes_add_cipher_data
+   },
+   {
+   .name = "aes192",
+   .key_len = AES192_KEY_LENGTH,
+   .iv_len  = AES_BLOCK_LENGTH,
+#if IMAGE_ENABLE_ENCRYPT
+   .calculate_type = EVP_aes_192_cbc,
+#endif
+   .encrypt = image_aes_encrypt,
+   .add_cipher_data = image_aes_add_cipher_data
+   },
+   {
+   .name = "aes256",
+   .key_len = AES256_KEY_LENGTH,
+   .iv_len  = AES_BLOCK_LENGTH,
+#if IMAGE_ENABLE_ENCRYPT
+   .calculate_type = EVP_aes_256_cbc,
+#endif
+   .encrypt = image_aes_encrypt,
+   .add_cipher_data = image_aes_add_cipher_data
+   }
+};
+
+struct cipher_algo *image_get_cipher_algo(const char *full_name)
+{
+   int i;
+   const char *name;
+
+   for (i = 0; i < ARRAY_SIZE(cipher_algos); i++) {
+   name = cipher_algos[i].name;
+   if (!strncmp(name, full_name, strlen(name)))
+   return _algos[i];
+   }
+
+   return NULL;
+}
diff --git a/common/image-fit.c b/common/image-fit.c
index c52f945..a06760e 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1080,6 +1080,33 @@ static int fit_image_hash_get_ignore(const void *fit, 
int noffset, int *ignore)
return 0;
 }
 
+/**
+ * fit_image_cipher_get_algo - get cipher algorithm name
+ * @fit: pointer to the FIT format image header
+ * @noffset: cipher node offset
+ * @algo: double pointer to char, will hold pointer to the algorithm name
+ *
+ * fit_image_cipher_get_algo() finds cipher algorithm property in a given
+ * cipher node. If the property is found its data start address is returned
+ * to the caller.
+ *
+ * returns:
+ * 0, on success
+ * -1, on failure
+ */
+int fit_image_cipher_get_algo(const void *fit, int noffset, char **algo)
+{
+   int len;
+
+   *algo = (char *)fdt_getprop(fit, noffset, FIT_ALGO_PROP, );
+   if (!*algo) {
+   fit_get_debug(fit, noffset, FIT_ALGO_PROP, len);
+   return -1;
+   }
+
+   return 0;
+}
+
 ulong fit_get_end(const void *fit)
 {
return map_to_sysmem((void *)(fit 

[PATCH] drivers: net: fsl_enetc: use write_hwaddr()

[Michael Walle]

Intead of setting the MAC address in enetc_start() use the proper
write_hwaddr(). U-Boot takes care of the random MAC address, too. Also,
this will correctly handle ethNmacskip etc.

Signed-off-by: Michael Walle 
---
 drivers/net/fsl_enetc.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/net/fsl_enetc.c b/drivers/net/fsl_enetc.c
index e86f3dddb5..1949530460 100644
--- a/drivers/net/fsl_enetc.c
+++ b/drivers/net/fsl_enetc.c
@@ -272,14 +272,19 @@ static int enetc_remove(struct udevice *dev)
return 0;
 }
 
-/* ENETC Port MAC address registers, accepts big-endian format */
-static void enetc_set_primary_mac_addr(struct enetc_priv *priv, const u8 *addr)
+static int enetc_write_hwaddr(struct udevice *dev)
 {
+   struct eth_pdata *plat = dev_get_platdata(dev);
+   struct enetc_priv *priv = dev_get_priv(dev);
+   u8 *addr = plat->enetaddr;
+
u16 lower = *(const u16 *)(addr + 4);
u32 upper = *(const u32 *)addr;
 
enetc_write_port(priv, ENETC_PSIPMAR0, upper);
enetc_write_port(priv, ENETC_PSIPMAR1, lower);
+
+   return 0;
 }
 
 /* Configure port parameters (# of rings, frame size, enable port) */
@@ -410,7 +415,6 @@ static void enetc_setup_rx_bdr(struct udevice *dev)
  */
 static int enetc_start(struct udevice *dev)
 {
-   struct eth_pdata *plat = dev_get_platdata(dev);
struct enetc_priv *priv = dev_get_priv(dev);
 
/* reset and enable the PCI device */
@@ -418,12 +422,6 @@ static int enetc_start(struct udevice *dev)
dm_pci_clrset_config16(dev, PCI_COMMAND, 0,
   PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER);
 
-   if (!is_valid_ethaddr(plat->enetaddr)) {
-   enetc_dbg(dev, "invalid MAC address, generate random ...\n");
-   net_random_ethaddr(plat->enetaddr);
-   }
-   enetc_set_primary_mac_addr(priv, plat->enetaddr);
-
enetc_enable_si_port(priv);
 
/* setup Tx/Rx buffer descriptors */
@@ -549,6 +547,7 @@ static const struct eth_ops enetc_ops = {
.send   = enetc_send,
.recv   = enetc_recv,
.stop   = enetc_stop,
+   .write_hwaddr = enetc_write_hwaddr,
 };
 
 U_BOOT_DRIVER(eth_enetc) = {
-- 
2.20.1

[PATCH] dm: uclass: don't assign aliased seq numbers

[Michael Walle]

If there are aliases for an uclass, set the base for the "dynamically"
allocated numbers next to the highest alias.

Please note, that this might lead to holes in the sequences, depending
on the device tree. For example if there is only an alias "ethernet1",
the next device seq number would be 2.

In particular this fixes a problem with boards which are using ethernet
aliases but also might have network add-in cards like the E1000. If the
board is started with the add-in card and depending on the order of the
drivers, the E1000 might occupy the first ethernet device and mess up
all the hardware addresses, because the devices are now shifted by one.

As a side effect, this should also make the following commits
superfluous:
 - 7f3289bf6d ("dm: device: Request next sequence number")
 - 61607225d1 ("i2c: Fill req_seq in i2c_post_bind()")
   Although I don't understand the root cause of the said problem.

Thomas, Michal, could you please test this and then I'd add a second
patch removing the old code.

Cc: Thomas Fitzsimmons 
Cc: Michal Simek 

Signed-off-by: Michael Walle 
---
 drivers/core/uclass.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index c520ef113a..c3b325141a 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -675,13 +675,14 @@ int uclass_unbind_device(struct udevice *dev)
 
 int uclass_resolve_seq(struct udevice *dev)
 {
+   struct uclass *uc = dev->uclass;
+   struct uclass_driver *uc_drv = uc->uc_drv;
struct udevice *dup;
-   int seq;
+   int seq = 0;
int ret;
 
assert(dev->seq == -1);
-   ret = uclass_find_device_by_seq(dev->uclass->uc_drv->id, dev->req_seq,
-   false, );
+   ret = uclass_find_device_by_seq(uc_drv->id, dev->req_seq, false, );
if (!ret) {
dm_warn("Device '%s': seq %d is in use by '%s'\n",
dev->name, dev->req_seq, dup->name);
@@ -693,9 +694,16 @@ int uclass_resolve_seq(struct udevice *dev)
return ret;
}
 
-   for (seq = 0; seq < DM_MAX_SEQ; seq++) {
-   ret = uclass_find_device_by_seq(dev->uclass->uc_drv->id, seq,
-   false, );
+   if (CONFIG_IS_ENABLED(DM_SEQ_ALIAS) &&
+   (uc_drv->flags & DM_UC_FLAG_SEQ_ALIAS)) {
+   /* dev_read_alias_highest_id() will return -1 if there no
+* alias. Thus we can always add one.
+*/
+   seq = dev_read_alias_highest_id(uc_drv->name) + 1;
+   }
+
+   for (; seq < DM_MAX_SEQ; seq++) {
+   ret = uclass_find_device_by_seq(uc_drv->id, seq, false, );
if (ret == -ENODEV)
break;
if (ret)
-- 
2.20.1

Re: [PATCH] net: dwc_eth_qos: Pass -1 to phy_connect() to scan for all PHYs

[Joe Hershberger]

On Wed, Dec 18, 2019 at 12:49 AM Marek Vasut  wrote:
>
> PHY address 0 is a valid PHY address, to scan for all PHYs, pass -1 to
> phy_connect(). Passing 0 used to work before be accident, but does no
> longer.
>
> Signed-off-by: Marek Vasut 
> Cc: Joe Hershberger 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> Cc: Ramon Fried 

Acked-by: Joe Hershberger 

Re: [U-Boot] [PATCH] net/phy: Fix phy_connect() for phy addr 0

[Marek Vasut]

On 12/18/19 5:15 PM, Joe Hershberger wrote:
> On Tue, Dec 17, 2019 at 11:55 PM Marek Vasut  wrote:
>>
>> On 12/18/19 3:06 AM, Joe Hershberger wrote:
>>> On Tue, Dec 17, 2019 at 1:04 PM Marek Vasut  wrote:

 On 12/17/19 7:47 PM, Joe Hershberger wrote:
> On Tue, Dec 17, 2019 at 11:46 AM Marek Vasut  wrote:
>>
>> On 12/17/19 5:25 PM, Joe Hershberger wrote:
>>> Hi Marek,
>>
>> Hi Joe,
>>
>>> On Tue, Dec 17, 2019 at 1:39 AM Marek Vasut  wrote:

 On 11/7/19 9:04 PM, Joe Hershberger wrote:
> On Thu, Nov 7, 2019 at 1:16 PM Tom Rini  wrote:
>>
>> On Tue, Nov 05, 2019 at 04:05:11AM +, Priyanka Jain wrote:
>>
>>> Fix 'mask' calculation in phy_connect() for phy addr '0'.
>>> 'mask' is getting set to '0x' for phy addr '0'
>>> in phy_connect() whereas expected value is '0'.
>>>
>>>
>>> Signed-off-by: Priyanka Jain 
>>
>> Reported-by: tetsu-aoki via github
>
> Acked-by: Joe Hershberger 

 Sadly, this breaks systems where a PHY is at address 0.
 I have such an STM32MP1 system with LAN8720 PHY and since this patch, I
 cannot use ethernet. Please revert.
>>>
>>> It seems like a case that shouldn't have worked before.
>>
>> Eh? PHY at address 0 definitely did work before and must work now.
>
> Agreed that a phy at address 0 should work. Not agreed that because
> the value "0" used to work due to a bug that it must still. Which of
> these is the statement you are making? Do we already agree or
> disagree?

 I am saying that because a board worked on rc4 and does not work on rc5,
 this is a bug introduced by this patch in rc5 and must be fixed before
 the release.

 The address 0 is a PHY broadcast address for some PHYs, it's a fixed
 address for other PHYs. Thus, a PHY at address 0 must work. If this is
 broken now, it's a bug.
>>>
>>> The only thing this patch should change is to not access addresses
>>> other than 0. I read the data sheet for the LAN8720 and it doesn't
>>> mention anything about any broadcast behavior, so I'm not sure what
>>> you're trying to state here.
>>
>> Read [1] section 3.7.1 PHYAD[2:0]: PHY ADDRESS CONFIGURATION
>>
>> What I am saying is that there are two types of PHYs, ones which treat
>> PHY address 0 as broadcast and ones which treat it as regular address.
>> This one is the later and is configured as such in my case.
>>
>> http://ww1.microchip.com/downloads/en/DeviceDoc/2164B.pdf
> 
> I see. What's an example of a phy that treats 0 as broadcast?

IIRC KSZ9031 does.

>>> What about
>>> this board requires the mask to be all 'f's, other than specifying the
>>> wrong phy address? It seems that in your case the phy address is not
>>> actually 0 (or the computed mask would find it), but your board dts
>>> may be setting it to 0 as an "unknown" value, but the correct unknown
>>> value should be "-1". It seems the issue is with these boards.
>>
>> Nope, the address is actually configured to 0 in hardware.
>
> Can you double check that?

 No, sorry, I know the hardware is fixed to 0. Checking it again will not
 change this fact.
>>>
>>> It seems there is no phy driver for this in U-Boot so the generic
>>> behavior is being used. I'm at a disadvantage of not having this board
>>> to try. Can you revert this patch and run with debug enabled for
>>> drivers/net/phy/phy.c to determine what is happening for this board? I
>>> would appreciate you helping with this.
>>
>> It only says "connected to Generic PHY" .
>>
>> So looking at the commit message, I am not really sure which board or
>> issue does this patch fix. But if I understand the commit message right,
>> then the aim is to set mask to 0 instead of 0x for address 0.
>> But that's not right either, the mask should be BIT(0) = 1 for address
>> 0, and that's what the patch actually does. I guess this then fails
>> somewhere further down the road ...
> 
> Yes, the commit message is wrong... the expected value is 1, not 0.  I
> missed that in the review.
> 
> Is the patch you sent earlier a solution for your board or something
> unrelated you found as a result of this discussion?

It works for my board, but I wonder how many other boards got broken here.

Re: [U-Boot] [PATCH] net/phy: Fix phy_connect() for phy addr 0

[Joe Hershberger]

On Tue, Dec 17, 2019 at 11:55 PM Marek Vasut  wrote:
>
> On 12/18/19 3:06 AM, Joe Hershberger wrote:
> > On Tue, Dec 17, 2019 at 1:04 PM Marek Vasut  wrote:
> >>
> >> On 12/17/19 7:47 PM, Joe Hershberger wrote:
> >>> On Tue, Dec 17, 2019 at 11:46 AM Marek Vasut  wrote:
> 
>  On 12/17/19 5:25 PM, Joe Hershberger wrote:
> > Hi Marek,
> 
>  Hi Joe,
> 
> > On Tue, Dec 17, 2019 at 1:39 AM Marek Vasut  wrote:
> >>
> >> On 11/7/19 9:04 PM, Joe Hershberger wrote:
> >>> On Thu, Nov 7, 2019 at 1:16 PM Tom Rini  wrote:
> 
>  On Tue, Nov 05, 2019 at 04:05:11AM +, Priyanka Jain wrote:
> 
> > Fix 'mask' calculation in phy_connect() for phy addr '0'.
> > 'mask' is getting set to '0x' for phy addr '0'
> > in phy_connect() whereas expected value is '0'.
> >
> >
> > Signed-off-by: Priyanka Jain 
> 
>  Reported-by: tetsu-aoki via github
> >>>
> >>> Acked-by: Joe Hershberger 
> >>
> >> Sadly, this breaks systems where a PHY is at address 0.
> >> I have such an STM32MP1 system with LAN8720 PHY and since this patch, I
> >> cannot use ethernet. Please revert.
> >
> > It seems like a case that shouldn't have worked before.
> 
>  Eh? PHY at address 0 definitely did work before and must work now.
> >>>
> >>> Agreed that a phy at address 0 should work. Not agreed that because
> >>> the value "0" used to work due to a bug that it must still. Which of
> >>> these is the statement you are making? Do we already agree or
> >>> disagree?
> >>
> >> I am saying that because a board worked on rc4 and does not work on rc5,
> >> this is a bug introduced by this patch in rc5 and must be fixed before
> >> the release.
> >>
> >> The address 0 is a PHY broadcast address for some PHYs, it's a fixed
> >> address for other PHYs. Thus, a PHY at address 0 must work. If this is
> >> broken now, it's a bug.
> >
> > The only thing this patch should change is to not access addresses
> > other than 0. I read the data sheet for the LAN8720 and it doesn't
> > mention anything about any broadcast behavior, so I'm not sure what
> > you're trying to state here.
>
> Read [1] section 3.7.1 PHYAD[2:0]: PHY ADDRESS CONFIGURATION
>
> What I am saying is that there are two types of PHYs, ones which treat
> PHY address 0 as broadcast and ones which treat it as regular address.
> This one is the later and is configured as such in my case.
>
> http://ww1.microchip.com/downloads/en/DeviceDoc/2164B.pdf

I see. What's an example of a phy that treats 0 as broadcast?

> > What about
> > this board requires the mask to be all 'f's, other than specifying the
> > wrong phy address? It seems that in your case the phy address is not
> > actually 0 (or the computed mask would find it), but your board dts
> > may be setting it to 0 as an "unknown" value, but the correct unknown
> > value should be "-1". It seems the issue is with these boards.
> 
>  Nope, the address is actually configured to 0 in hardware.
> >>>
> >>> Can you double check that?
> >>
> >> No, sorry, I know the hardware is fixed to 0. Checking it again will not
> >> change this fact.
> >
> > It seems there is no phy driver for this in U-Boot so the generic
> > behavior is being used. I'm at a disadvantage of not having this board
> > to try. Can you revert this patch and run with debug enabled for
> > drivers/net/phy/phy.c to determine what is happening for this board? I
> > would appreciate you helping with this.
>
> It only says "connected to Generic PHY" .
>
> So looking at the commit message, I am not really sure which board or
> issue does this patch fix. But if I understand the commit message right,
> then the aim is to set mask to 0 instead of 0x for address 0.
> But that's not right either, the mask should be BIT(0) = 1 for address
> 0, and that's what the patch actually does. I guess this then fails
> somewhere further down the road ...

Yes, the commit message is wrong... the expected value is 1, not 0.  I
missed that in the review.

Is the patch you sent earlier a solution for your board or something
unrelated you found as a result of this discussion?

RE: [PATCH] ARM: stm32: Permit multiple board targets

[Patrick DELAUNAY]

Hi,

> From: Marek Vasut 
> Sent: mercredi 18 décembre 2019 15:15
> 
> On 12/18/19 3:04 PM, Patrick DELAUNAY wrote:
> > Hi Marek,
> >
> >> From: Patrick DELAUNAY
> >> Sent: mercredi 18 décembre 2019 14:20
> >>
> >> Hi Marek,
> >>
> >>> From: Marek Vasut 
> >>> Sent: mercredi 18 décembre 2019 07:59
> >>>
> >>> Setting TARGET_STM32MP1 in Kconfig always forces SYS_BOARD,
> >> SYS_VENDOR
> >>> and SYS_CONFIG_NAME to values set by the ST reference platforms.
> >>> Allow changing that by pulling out the TARGET_STM32MP157C_DK2 and
> >>> making the ST reference platform settings conditional on
> >>> TARGET_STM32MP157C_DK2 .
> >>> Other platforms can now define a different TARGET_ and thus override
> >>> the SYS_ settings in their Kconfig.
> >>>
> >>> Signed-off-by: Marek Vasut 
> >>> Cc: Patrick Delaunay 
> >>> Cc: Patrice Chotard 
> >>> ---
> >>>  board/st/stm32mp1/Kconfig | 10 +-
> >>>  1 file changed, 5 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/board/st/stm32mp1/Kconfig b/board/st/stm32mp1/Kconfig
> >>> index
> >>> 4fa2360b4f..c84aa41f06 100644
> >>> --- a/board/st/stm32mp1/Kconfig
> >>> +++ b/board/st/stm32mp1/Kconfig
> >>> @@ -1,4 +1,8 @@
> >>> -if TARGET_STM32MP1
> >>> +config TARGET_STM32MP157C_DK2
> >>> + bool "support of STMicroelectronics STM32MP157C-DK2 Discovery
> >>> Board"
> >>> + default y
> >>> +
> >>> +if TARGET_STM32MP157C_DK2
> >>>
> >>>  config SYS_BOARD
> >>>   default "stm32mp1"
> >>> @@ -22,8 +26,4 @@ config CMD_STBOARD
> >>> This compile the stboard command to
> >>> read and write the board in the OTP.
> >>>
> >>> -config TARGET_STM32MP157C_DK2
> >>> - bool "support of STMicroelectronics STM32MP157C-DK2 Discovery
> >>> Board"
> >>> - default y
> >>
> >> I try to understood the issue but checked DK2 is not enought (I will
> >> soon introduce a new config for EV1 support)
> >>
> >> What it the use case ?
> >>
> >> Add a new board (not a board provided by ST)  which are managed by a
> >> new directory
> >>board//
> >>
> >> I think, if it is the case, we should test CONFIG_SYS_VENDOR = "stm32mp1"
> >> in board/st/stm32mp1/Kconfig
> >>
> >> And move CONFIG_SYS_VENDOR to arch
> >>
> >> NB: default value can be overidde in your board defconfig...
> >>
> >> Normally:
> >> - stm32mp1_trusted_defconfig
> >> - stm32mp1_basic_defconfig
> >> - stm32mp1_optee_defconfig
> >>
> >> only support the directory ST board with board/st/stm32mp1
> >
> > After deeper check => it is already managed by the config
> >
> > CONFIG_TARGET_STM32MP1
> >
> > board/st/stm32mp1.Kconfig
> >
> > dtb-$(CONFIG_TARGET_STM32MP1) += \
> > stm32mp157a-dk1.dtb \
> > stm32mp157a-avenger96.dtb \
> > stm32mp157c-dk2.dtb \
> > stm32mp157c-ed1.dtb \
> > stm32mp157c-ev1.dtb
> >
> > Activated by default in the ST defconfig (stm32mp1_trusted_defconfig,
> > stm32mp1_basic_defconfig,  stm32mp1_optee_defconfig)
> >
> > Do you need other way of configuration ?
> 
> Yes, I need to override the configuration which is currently forced by the ST
> Kconfig file. Hence this patch.
> 
> I can repost this patch with the board patch once that's ready. It might make 
> it
> easier to understand the purpose.

Yes thanks.

I am waiting your patchset..

Anyway it is not yet clear for me how manage customer board...

I perhaps need to have a common directory (board/st/common)  to share code 
between ST board
and customer board (as it is done by other arch)

I expect it will be the same than imx or rockwell board 

   one board (or one family)  => one defconfig

for all ST board (EV1 DK1 DK2)  => CONFIG_TARGET_STM32MP1
for custom board CUST0 => CONFIG_TARGET_CUST0

with Kconfig

if TARGET_STM32MP1

config SYS_BOARD
default "stm32mp1"

config SYS_VENDOR
default "st"

config SYS_CONFIG_NAME
default "stm32mp1"

<>

endif

if TARGET_CUST0

config SYS_BOARD
default "cust0"

config SYS_VENDOR
default "customer"

config SYS_CONFIG_NAME
default "cust0"

endif

Regards Patrick

[PATCH V2] ARM: stm32: Allow overriding setup_mac_address()

[Marek Vasut]

Let board code override setup_mac_address(), which is useful e.g. if the
board derives the MAC address from another source, like an I2C EEPROM.

Signed-off-by: Marek Vasut 
Cc: Patrick Delaunay 
Cc: Patrice Chotard 
---
V2: Add prototype to sys_proto.h
---
 arch/arm/mach-stm32mp/cpu.c| 2 +-
 arch/arm/mach-stm32mp/include/mach/sys_proto.h | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
index ed7d9f61dc..856c7ced7a 100644
--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -449,7 +449,7 @@ static void setup_boot_mode(void)
  * If there is no MAC address in the environment, then it will be initialized
  * (silently) from the value in the OTP.
  */
-static int setup_mac_address(void)
+__weak int setup_mac_address(void)
 {
 #if defined(CONFIG_NET)
int ret;
diff --git a/arch/arm/mach-stm32mp/include/mach/sys_proto.h 
b/arch/arm/mach-stm32mp/include/mach/sys_proto.h
index 99eefabf6e..47e57922d1 100644
--- a/arch/arm/mach-stm32mp/include/mach/sys_proto.h
+++ b/arch/arm/mach-stm32mp/include/mach/sys_proto.h
@@ -30,3 +30,5 @@ u32 get_cpu_package(void);
 
 /* return boot mode */
 u32 get_bootmode(void);
+
+int setup_mac_address(void);
-- 
2.24.1

Re: [PATCH v3 5/5] test/py: Create a test for launching UEFI binaries from FIT images

[Cristian Ciocaltea]

On Wed, Dec 18, 2019 at 11:56:00AM +0100, Heinrich Schuchardt wrote:
> On 12/18/19 9:22 AM, Cristian Ciocaltea wrote:
> > > > +};
> > > > +};
> > > > +'''
> > > > +
> > > > +@pytest.mark.boardspec('sandbox')
> > > This test looks ok in principal. But why should we restrict it to the
> > > sandbox?
> > Let me see how this should work on real hardware, I'm going to test
> > on qemu for the moment.
> 
> Device trees cannot be used in conjunction with ACPI tables when booting
> via UEFI. Currently this concerns only x86 and x86_64 but Phytec is
> working on an arm64 board which shall provide an ACPI table. So you
> probably want to check CONFIG_GENERATE_ACPI_TABLE instead of the board
> type, e.g.
> 
> @pytest.mark.notbuildconfigspec('generate_acpi_table')

Thanks for the hint! 

For some strange reason, whatever I put in the 'notbuildconfigspec'
marker causes the test to be skipped:

[-] Section: test_efi_fit
TIME: NOW: 2019/12/18 17:33:14.976576
TIME: SINCE-PREV: 0:00:00.192132
TIME: SINCE-START: 0:00:00.192132
SKIPPED:
('[...]/uboot/test/py/conftest.py', 463, 'Skipped: .config feature "bootm_efi" 
enabled')

I don't really understand the connection to 'bootm_efi'. If I comment
out the 'bootm_efi' marker, the reported status becomes:

SKIPPED:
('[].../uboot/test/py/conftest.py', 463, 'Skipped: .config feature 
"cmd_bootefi_hello_compile" enabled')

So it seems 'notbuildconfigspec' gets its parameter from the first
active 'buildconfigspec' statement. This is my current test:

#@pytest.mark.buildconfigspec('bootm_efi')
@pytest.mark.buildconfigspec('cmd_bootefi_hello_compile')
#@pytest.mark.notbuildconfigspec('generate_acpi_table')
@pytest.mark.notbuildconfigspec('fake_item')
@pytest.mark.requiredtool('dtc')

> Best regards
> 
> Heinrich

Re: [PATCH] net: dwc_eth_qos: Pass -1 to phy_connect() to scan for all PHYs

[Fabio Estevam]

On Wed, Dec 18, 2019 at 3:49 AM Marek Vasut  wrote:
>
> PHY address 0 is a valid PHY address, to scan for all PHYs, pass -1 to
> phy_connect(). Passing 0 used to work before be accident, but does no

s/be/by

Re: [PATCH] net: dwc_eth_qos: Pass -1 to phy_connect() to scan for all PHYs

[Ramon Fried]

On Wed, Dec 18, 2019 at 2:17 PM Patrick DELAUNAY
 wrote:
>
> Hi,
>
> > From: Marek Vasut 
> > Sent: mercredi 18 décembre 2019 07:49
> >
> > PHY address 0 is a valid PHY address, to scan for all PHYs, pass -1 to
> > phy_connect(). Passing 0 used to work before be accident, but does no 
> > longer.
> >
> > Signed-off-by: Marek Vasut 
> > Cc: Joe Hershberger 
> > Cc: Patrice Chotard 
> > Cc: Patrick Delaunay 
> > Cc: Ramon Fried 
>
> Reviewed-by: Patrick Delaunay 
>
> > ---
> >  drivers/net/dwc_eth_qos.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c index
> > da5b696c9d..4632111635 100644
> > --- a/drivers/net/dwc_eth_qos.c
> > +++ b/drivers/net/dwc_eth_qos.c
> > @@ -1045,7 +1045,7 @@ static int eqos_start(struct udevice *dev)
> >* don't need to reconnect/reconfigure again
> >*/
> >   if (!eqos->phy) {
> > - eqos->phy = phy_connect(eqos->mii, 0, dev,
> > + eqos->phy = phy_connect(eqos->mii, -1, dev,
> >   eqos->config->interface(dev));
> >   if (!eqos->phy) {
> >   pr_err("phy_connect() failed");
> > --
> > 2.24.1
>
> Regards
>
Reviewed-By: Ramon Fried 

Re: [U-Boot] [PATCH] qemu-riscv64_smode, sifive-fu540: fix extlinux (define preboot)

[Vagrant Cascadian]

On 2019-12-18, David Abdurachmanov wrote:
> On Wed, Dec 18, 2019 at 3:13 AM Vagrant Cascadian  wrote:
>>
>> On 2019-09-25, Vagrant Cascadian wrote:
>> > On 2019-08-21, David Abdurachmanov wrote:
>> >> Commit 37304aaf60bf92a5dc3ef222ba520698bd862a44 removed preboot
>> >> commands in RISC-V targets and broke extlinux support as reported
>> >> by Fu Wei .
>> >>
>> >> The patch finishes migration of CONFIG_USE_PREBOOT and CONFIG_REBOOT
>> >> to Kconfig.
>> >
>> > Tested using qemu-riscv64_smode and it fixes extlinux booting. Thanks!
>> >
>> > Please CC me on future updates to the patch series.
>> >
>> > Tested-by: Vagrant Cascadian 
>>
>> This patch, or something like it, is still needed with u-boot
>> v2020.01-rc5 for extlinux support to load the device-tree from the boot
>> firmware.
>>
>> Is there a new approach in the works, or any chance to see something
>> like this get merged soon?
>
> I do carry several experiment patches in Fedora/RISCV, which I didn't
> yet sent for a review.
> Basically that allows me to boot a single Fedora/RISCV disk image on
> QEMU virt machine
> and SiFive Unleashed.
>
> See: 
> http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/uboot-tools.spec#L36
>
> Note some of the patches were merged in rc5.

Thanks! I'll give your patches some testing when I get a chance.


Some potentially quite naive questions:

> You would want the following two patches:
> http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/riscv64-set-fdt_addr.patch

Why does it need fdt_addr=0x8800 need to be set (and to the same
value as fdt_addr_r)? According to README fdt_addr is for the flash
media, which I don't think is used in the qemu case, at least. Is
fdt_addr being (ab)used for some other purpose? I guess the README also
gives free reign to use the variables for other purposes... but it would
be good to know why that is needed vs. just using fdt_addr_r as
documented.


> http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/riscv-bootargs-preboot.patch

CONFIG_PREBOOT="cp.l ${fdtcontroladdr} ${fdt_addr_r} 0x1;"

What does cp.l do?

Do you need to force setting the console in CONFIG_BOOTARGS? It seemed
to autodetect the console on the installations I have running, possibly
getting the chosen console from device-tree?


live well,
  vagrant


signature.asc
Description: PGP signature

Re: [PATCH v3 5/5] test/py: Create a test for launching UEFI binaries from FIT images

[Cristian Ciocaltea]

On Wed, Dec 18, 2019 at 11:06:48AM +0100, Heinrich Schuchardt wrote:
> On 12/18/19 9:22 AM, Cristian Ciocaltea wrote:
> > On Tue, Dec 17, 2019 at 10:08:31PM +0100, Heinrich Schuchardt wrote:
> > > On 12/17/19 8:47 AM, Cristian Ciocaltea wrote:
> > > > This test verifies the implementation of the 'bootm' extension that
> > > > handles UEFI binaries inside FIT images (enabled via CONFIG_BOOTM_EFI).
> > > > 
> > > > Signed-off-by: Cristian Ciocaltea 
> > > > ---
> > > >test/py/tests/test_efi_fit.py | 233 
> > > > ++
> > > >1 file changed, 233 insertions(+)
> > > >create mode 100644 test/py/tests/test_efi_fit.py
> > > > 
> > > > diff --git a/test/py/tests/test_efi_fit.py 
> > > > b/test/py/tests/test_efi_fit.py
> > > > new file mode 100644
> > > > index 00..52b415b198
> > > > --- /dev/null
> > > > +++ b/test/py/tests/test_efi_fit.py
> > > > @@ -0,0 +1,233 @@
> > > > +# SPDX-License-Identifier: GPL-2.0
> > > > +# Copyright (c) 2019, Cristian Ciocaltea 
> > > > +
> > > > +# Test launching UEFI binaries from FIT images.
> > > > +
> > > > +import os
> > > > +import pytest
> > > > +import u_boot_utils as util
> > > > +
> > > > +# Define the parametrized ITS data to be used for FIT image generation.
> > > > +its_data = '''
> > > > +/dts-v1/;
> > > > +
> > > > +/ {
> > > > +description = "EFI image with FDT blob";
> > > > +#address-cells = <1>;
> > > > +
> > > > +images {
> > > > +efi {
> > > > +description = "Sandbox EFI";
> > > > +data = /incbin/("%(efi-bin)s");
> > > > +type = "%(kernel-type)s";
> > > > +arch = "sandbox";
> > > > +os = "efi";
> > > > +compression = "%(efi-comp)s";
> > > > +load = <0x0>;
> > > > +entry = <0x0>;
> > > > +};
> > > > +fdt {
> > > > +description = "Sandbox FDT";
> > > > +data = /incbin/("%(fdt-bin)s");
> > > > +type = "flat_dt";
> > > > +arch = "sandbox";
> > > > +compression = "%(fdt-comp)s";
> > > > +};
> > > > +};
> > > > +
> > > > +configurations {
> > > > +default = "config-efi-fdt";
> > > > +config-efi-fdt {
> > > > +description = "EFI FIT w/ FDT";
> > > > +kernel = "efi";
> > > > +fdt = "fdt";
> > > > +};
> > > > +config-efi-nofdt {
> > > > +description = "EFI FIT w/o FDT";
> > > > +kernel = "efi";
> > > > +};
> > > > +};
> > > > +};
> > > > +'''
> > > > +
> > > > +# Define the parametrized FDT data.
> > > > +fdt_data = '''
> > > > +/dts-v1/;
> > > > +
> > > > +/ {
> > > > +model = "Sandbox %(fdt_type) EFI FIT Boot Test ";
> > > > +compatible = "sandbox";
> > > > +
> > > > +reset@0 {
> > > > +compatible = "sandbox,reset";
> > > 
> > > This produces a warning:
> > > 
> > > +dtc ./test-efi-fit-sandbox-internal.dts -O dtb -o
> > > ./test-efi-fit-sandbox-internal.dtb
> > > ./test-efi-fit-sandbox-internal.dts:8.13-10.7: Warning
> > > (unit_address_vs_reg): /reset@0: node has a unit name, but no reg property
> > 
> > A similar sample is also used by test_fit.py and test_vboot.py, which
> > expose the same warning, that's why I initially ignored it.
> > If acceptable, I can suppress it via '-W no-unit_address_vs_reg'.
> 
> reset@0 includes a unit-address. So a reg property is expected. How about:
> 
> /dts-v1/;
> 
> / {
>   #address-cells = <1>;
>   #size-cells = <0>;
> 
>   model = "Sandbox %(fdt_type) EFI FIT Boot Test ";
>   compatible = "sandbox";
> 
>   reset@0 {
>   compatible = "sandbox,reset";
>   reg = <0>;
>   };
> };

Yes, that's a much better approach. It works fine, thanks!

> Best regards
> 
> Heinrich
> 
> > 
> > > > +};
> > > > +};
> > > > +'''
> > > > +
> > > > +@pytest.mark.boardspec('sandbox')
> > > 
> > > This test looks ok in principal. But why should we restrict it to the
> > > sandbox?
> > 
> > Let me see how this should work on real hardware, I'm going to test
> > on qemu for the moment.
> > 
> > > Best regards
> > > 
> > > Heinrich
> > > 
> > > > +@pytest.mark.buildconfigspec('bootm_efi')
> > > > +@pytest.mark.buildconfigspec('cmd_bootefi_hello_compile')
> > > > +@pytest.mark.requiredtool('dtc')
> > > > +def test_efi_fit(u_boot_console):
> > > > +"""Test handling of UEFI binaries inside FIT images.
> > > > +
> > > > +The tests are trying to launch U-Boot's helloworld.efi embedded 
> > > > into
> > > > +FIT images, in uncompressed or gzip compressed format.
> > > > +
> > > > +Additionally, a sample FDT blob is created and embedded into the 
> > > > above
> > > > +mentioned FIT images, in uncompressed or gzip compressed format.
> > > > +
> > > > +The following test cases are currently defined and enabled:
> > > > +- Launch uncompressed FIT EFI & FIT FDT
> > > > +- Launch compressed FIT EFI & FIT FDT
> > 

Re: [PATCH 1/1] sunxi: remove __packed from struct sunxi_prcm_reg

[Jagan Teki]

On Wed, Dec 18, 2019 at 3:25 AM Heinrich Schuchardt  wrote:
>
> struct sunxi_prcm_reg is naturally packed. There is no need to define it as
> packed. Defining it as packed leads to compilation errors with GCC 9.2.1:
>
>   CC  arch/arm/lib/reloc_arm_efi.o
> arch/arm/cpu/armv7/sunxi/psci.c: In function ‘sunxi_cpu_set_power’:
> :qarch/arm/cpu/armv7/sunxi/psci.c:163:21: error: taking address of packed
> member of ‘struct sunxi_prcm_reg’ may result in an unaligned pointer value
> [-Werror=address-of-packed-member]
>   163 |  sunxi_power_switch(>cpu_pwr_clamp[cpu], >cpu_pwroff,
>   | ^
>
> Remove __packed attribute from struct sunxi_prcm_reg.
>
> Signed-off-by: Heinrich Schuchardt 
> ---

Applied to u-boot-sunxi/master

Re: [PATCH v4 1/3] spi: nxp_fspi: new driver for the FlexSPI controller

[Jagan Teki]

On Wed, Dec 18, 2019 at 4:40 AM Michael Walle  wrote:
>
> This is a port of the kernel's spi-nxp-fspi driver. It uses the new
> spi-mem interface and does not expose the more generic spi-xfer
> interface. The source was taken from the v5.3-rc3 tag.
>
> The port was straightforward:
>  - remove the interrupt handling and the completion by busy polling the
>controller
>  - remove locks
>  - move the setup of the memory windows into claim_bus()
>  - move the setup of the speed into set_speed()
>  - port the device tree bindings from the original fspi_probe() to
>ofdata_to_platdata()
>
> There were only some style change fixes, no change in any logic. For
> example, there are busy loops where the return code is not handled
> correctly, eg. only prints a warning with WARN_ON(). This port
> intentionally left most functions unchanged to ease future bugfixes.
>
> This was tested on a custom LS1028A board. Because the LS1028A doesn't
> have proper clock framework support, changing the clock speed was not
> tested. This also means that it is not possible to change the SPI
> speed on LS1028A for now (neither is it possible in the linux driver).
>
> Signed-off-by: Michael Walle 
> Reviewed-by: Jagan Teki 
> Tested-by: Kuldeep Singh 

Applied to u-boot-spi/master

Re: [PATCH] ARM: stm32: Permit multiple board targets

[Marek Vasut]

On 12/18/19 2:20 PM, Patrick DELAUNAY wrote:
> Hi Marek,

Hi,

>> From: Marek Vasut 
>> Sent: mercredi 18 décembre 2019 07:59
>>
>> Setting TARGET_STM32MP1 in Kconfig always forces SYS_BOARD,
>> SYS_VENDOR and SYS_CONFIG_NAME to values set by the ST reference
>> platforms. Allow changing that by pulling out the TARGET_STM32MP157C_DK2
>> and making the ST reference platform settings conditional on
>> TARGET_STM32MP157C_DK2 .
>> Other platforms can now define a different TARGET_ and thus override the SYS_
>> settings in their Kconfig.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Patrick Delaunay 
>> Cc: Patrice Chotard 
>> ---
>>  board/st/stm32mp1/Kconfig | 10 +-
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/board/st/stm32mp1/Kconfig b/board/st/stm32mp1/Kconfig index
>> 4fa2360b4f..c84aa41f06 100644
>> --- a/board/st/stm32mp1/Kconfig
>> +++ b/board/st/stm32mp1/Kconfig
>> @@ -1,4 +1,8 @@
>> -if TARGET_STM32MP1
>> +config TARGET_STM32MP157C_DK2
>> +bool "support of STMicroelectronics STM32MP157C-DK2 Discovery
>> Board"
>> +default y
>> +
>> +if TARGET_STM32MP157C_DK2
>>
>>  config SYS_BOARD
>>  default "stm32mp1"
>> @@ -22,8 +26,4 @@ config CMD_STBOARD
>>This compile the stboard command to
>>read and write the board in the OTP.
>>
>> -config TARGET_STM32MP157C_DK2
>> -bool "support of STMicroelectronics STM32MP157C-DK2 Discovery
>> Board"
>> -default y
> 
> I try to understood the issue but checked DK2 is not enought
> (I will soon introduce a new config for EV1 support)
> 
> What it the use case ?

Custom board.

> Add a new board (not a board provided by ST)  which are managed by a new 
> directory
>   board//
> 
> I think, if it is the case, we should test CONFIG_SYS_VENDOR = "stm32mp1"
> in board/st/stm32mp1/Kconfig
> 
> And move CONFIG_SYS_VENDOR to arch

Nope, SYS_VENDOR is the board manufacturer . For you it's ST, for me
it's "thus far undisclosed custom board vendor".

> NB: default value can be overidde in your board defconfig...
> 
> Normally:
> - stm32mp1_trusted_defconfig
> - stm32mp1_basic_defconfig 
> - stm32mp1_optee_defconfig
> 
> only support the directory ST board with board/st/stm32mp1

That's not how it's supposed to work -- these values should be defaulted
in Kconfig.

Re: [PATCH] ARM: stm32: Fill in missing loadaddr

[Marek Vasut]

On 12/18/19 2:04 PM, Patrick DELAUNAY wrote:
> Hi Marek,

Hi,

>> From: Marek Vasut 
>> Sent: mercredi 18 décembre 2019 07:59
>>
>> Since CONFIG_LOADADDR is not set, the default value of $loadaddr variable is
>> not set in the environment either. Set the default load address to 256 MiB 
>> from the
>> start of DRAM.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Patrick Delaunay 
>> Cc: Patrice Chotard 
>> ---
>>  include/configs/stm32mp1.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h index
>> dfc397c63c..59a86aee79 100644
>> --- a/include/configs/stm32mp1.h
>> +++ b/include/configs/stm32mp1.h
>> @@ -36,6 +36,7 @@
>>   * Needed by "loadb"
>>   */
>>  #define CONFIG_SYS_LOAD_ADDRSTM32_DDR_BASE
>> +#define CONFIG_LOADADDR 0xd000
>>
>>  /* ATAGs */
>>  #define CONFIG_CMDLINE_TAG
>> --
>> 2.24.1
> 
> Yes 
> 
> I never defined this CONFIG because not yet needed...

It is needed all right, to make the system behave sane.

> I alway use the load or boot command with address.

That's not how it was designed to be used. I always use it without the
address , because the $loadaddr should provide sane loading default. If
it's not defined, there's a problem.

> Just  to known, you need to have loadaddr for which use case ?

For the sane default use case ? :)

> I check the usage in U-Boot code ...
> And it is the only the default address when the value is not defined in CLI

Correct

> ./cmd/qfw.c:126:  env = env_get("loadaddr");
> ./cmd/load.c:432: s = env_get("loadaddr");
> ./cmd/bootefi.c:369:  saddr = env_get("loadaddr");
> ./cmd/ini.c:240:  argc < 3 ? env_get("loadaddr") : argv[2], NULL, 
> 16);
> ./cmd/net.c:190:  s = env_get("loadaddr");
> ./cmd/reiser.c:91:addr_str = env_get("loadaddr");
> ./cmd/zfs.c:57:   addr_str = env_get("loadaddr");
> ./cmd/mvebu/bubt.c:101:   addr_str = env_get("loadaddr");
> ./fs/fs.c:691:addr_str = env_get("loadaddr");
> ./common/board_r.c:467:   load_addr = env_get_ulong("loadaddr", 16, 
> load_addr);
> ./common/update.c:269:env_addr = env_get("loadaddr");
> ./common/image.c:563:static int on_loadaddr(const char *name, const char 
> *value, enum env_op op,
> ./common/image.c:1079:select = (argc == 0) ? 
> env_get("loadaddr") : argv[0];
> 
> It is more or less the same usage than: 
> 
> ./include/configs/stm32mp1.h:38:#define CONFIG_SYS_LOAD_ADDR  
> STM32_DDR_BASE
> 
> PS: I don't known why we have 2 differents CONFIG : CONFIG_SYS_LOAD_ADDR & 
> CONFIG_LOADADDR

That's something on my list of things to sort out. If you want to take
it up, have at it.

[...]

Re: [PATCH] ARM: stm32: Permit multiple board targets

[Marek Vasut]

On 12/18/19 3:04 PM, Patrick DELAUNAY wrote:
> Hi Marek,
> 
>> From: Patrick DELAUNAY
>> Sent: mercredi 18 décembre 2019 14:20
>>
>> Hi Marek,
>>
>>> From: Marek Vasut 
>>> Sent: mercredi 18 décembre 2019 07:59
>>>
>>> Setting TARGET_STM32MP1 in Kconfig always forces SYS_BOARD,
>> SYS_VENDOR
>>> and SYS_CONFIG_NAME to values set by the ST reference platforms. Allow
>>> changing that by pulling out the TARGET_STM32MP157C_DK2 and making the
>>> ST reference platform settings conditional on
>>> TARGET_STM32MP157C_DK2 .
>>> Other platforms can now define a different TARGET_ and thus override
>>> the SYS_ settings in their Kconfig.
>>>
>>> Signed-off-by: Marek Vasut 
>>> Cc: Patrick Delaunay 
>>> Cc: Patrice Chotard 
>>> ---
>>>  board/st/stm32mp1/Kconfig | 10 +-
>>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/board/st/stm32mp1/Kconfig b/board/st/stm32mp1/Kconfig
>>> index
>>> 4fa2360b4f..c84aa41f06 100644
>>> --- a/board/st/stm32mp1/Kconfig
>>> +++ b/board/st/stm32mp1/Kconfig
>>> @@ -1,4 +1,8 @@
>>> -if TARGET_STM32MP1
>>> +config TARGET_STM32MP157C_DK2
>>> +   bool "support of STMicroelectronics STM32MP157C-DK2 Discovery
>>> Board"
>>> +   default y
>>> +
>>> +if TARGET_STM32MP157C_DK2
>>>
>>>  config SYS_BOARD
>>> default "stm32mp1"
>>> @@ -22,8 +26,4 @@ config CMD_STBOARD
>>>   This compile the stboard command to
>>>   read and write the board in the OTP.
>>>
>>> -config TARGET_STM32MP157C_DK2
>>> -   bool "support of STMicroelectronics STM32MP157C-DK2 Discovery
>>> Board"
>>> -   default y
>>
>> I try to understood the issue but checked DK2 is not enought (I will soon 
>> introduce
>> a new config for EV1 support)
>>
>> What it the use case ?
>>
>> Add a new board (not a board provided by ST)  which are managed by a new
>> directory
>>  board//
>>
>> I think, if it is the case, we should test CONFIG_SYS_VENDOR = "stm32mp1"
>> in board/st/stm32mp1/Kconfig
>>
>> And move CONFIG_SYS_VENDOR to arch
>>
>> NB: default value can be overidde in your board defconfig...
>>
>> Normally:
>> - stm32mp1_trusted_defconfig
>> - stm32mp1_basic_defconfig
>> - stm32mp1_optee_defconfig
>>
>> only support the directory ST board with board/st/stm32mp1
> 
> After deeper check => it is already managed by the config
> 
> CONFIG_TARGET_STM32MP1
> 
> board/st/stm32mp1.Kconfig
> 
> dtb-$(CONFIG_TARGET_STM32MP1) += \
>   stm32mp157a-dk1.dtb \
>   stm32mp157a-avenger96.dtb \
>   stm32mp157c-dk2.dtb \
>   stm32mp157c-ed1.dtb \
>   stm32mp157c-ev1.dtb
> 
> Activated by default in the ST defconfig (stm32mp1_trusted_defconfig, 
> stm32mp1_basic_defconfig,  stm32mp1_optee_defconfig)
> 
> Do you need other way of configuration ?

Yes, I need to override the configuration which is currently forced by
the ST Kconfig file. Hence this patch.

I can repost this patch with the board patch once that's ready. It might
make it easier to understand the purpose.

RE: [PATCH] ARM: stm32: Permit multiple board targets

[Patrick DELAUNAY]

Hi Marek,

> From: Patrick DELAUNAY
> Sent: mercredi 18 décembre 2019 14:20
> 
> Hi Marek,
> 
> > From: Marek Vasut 
> > Sent: mercredi 18 décembre 2019 07:59
> >
> > Setting TARGET_STM32MP1 in Kconfig always forces SYS_BOARD,
> SYS_VENDOR
> > and SYS_CONFIG_NAME to values set by the ST reference platforms. Allow
> > changing that by pulling out the TARGET_STM32MP157C_DK2 and making the
> > ST reference platform settings conditional on
> > TARGET_STM32MP157C_DK2 .
> > Other platforms can now define a different TARGET_ and thus override
> > the SYS_ settings in their Kconfig.
> >
> > Signed-off-by: Marek Vasut 
> > Cc: Patrick Delaunay 
> > Cc: Patrice Chotard 
> > ---
> >  board/st/stm32mp1/Kconfig | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/board/st/stm32mp1/Kconfig b/board/st/stm32mp1/Kconfig
> > index
> > 4fa2360b4f..c84aa41f06 100644
> > --- a/board/st/stm32mp1/Kconfig
> > +++ b/board/st/stm32mp1/Kconfig
> > @@ -1,4 +1,8 @@
> > -if TARGET_STM32MP1
> > +config TARGET_STM32MP157C_DK2
> > +   bool "support of STMicroelectronics STM32MP157C-DK2 Discovery
> > Board"
> > +   default y
> > +
> > +if TARGET_STM32MP157C_DK2
> >
> >  config SYS_BOARD
> > default "stm32mp1"
> > @@ -22,8 +26,4 @@ config CMD_STBOARD
> >   This compile the stboard command to
> >   read and write the board in the OTP.
> >
> > -config TARGET_STM32MP157C_DK2
> > -   bool "support of STMicroelectronics STM32MP157C-DK2 Discovery
> > Board"
> > -   default y
> 
> I try to understood the issue but checked DK2 is not enought (I will soon 
> introduce
> a new config for EV1 support)
> 
> What it the use case ?
> 
> Add a new board (not a board provided by ST)  which are managed by a new
> directory
>   board//
> 
> I think, if it is the case, we should test CONFIG_SYS_VENDOR = "stm32mp1"
> in board/st/stm32mp1/Kconfig
> 
> And move CONFIG_SYS_VENDOR to arch
> 
> NB: default value can be overidde in your board defconfig...
> 
> Normally:
> - stm32mp1_trusted_defconfig
> - stm32mp1_basic_defconfig
> - stm32mp1_optee_defconfig
> 
> only support the directory ST board with board/st/stm32mp1

After deeper check => it is already managed by the config

CONFIG_TARGET_STM32MP1

board/st/stm32mp1.Kconfig

dtb-$(CONFIG_TARGET_STM32MP1) += \
stm32mp157a-dk1.dtb \
stm32mp157a-avenger96.dtb \
stm32mp157c-dk2.dtb \
stm32mp157c-ed1.dtb \
stm32mp157c-ev1.dtb

Activated by default in the ST defconfig (stm32mp1_trusted_defconfig, 
stm32mp1_basic_defconfig,  stm32mp1_optee_defconfig)

Do you need other way of configuration ?

Patrick

Re: [PULL] Pull request: u-boot-stm32 u-boot-stm32-20191218

[Tom Rini]

On Wed, Dec 18, 2019 at 12:13:29PM +, Patrick DELAUNAY wrote:

> Hi Tom
> 
> Please pull the last STM32 related patches for v2020.01
> 
> Travis CI status:
>  https://travis-ci.org/patrickdelaunay/u-boot/builds/626655770
> 
> With the following fixes:
> - fix crash for stm32mp1: remove the BOOTSTAGE feature
> - fix warning for stm32mp1: add the missing cls command
> 
> And I also resync the stm32mp1 defconfig.
> 
> Thanks,
> Patrick
> 
> git request-pull origin/master 
> https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git u-boot-stm32-20191218
> warn: No match for commit eddd79291d2026f8fefebc3f5d39928d7c649241 found at 
> https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git
> warn: Are you sure you pushed 'u-boot-stm32-20191218' there?
> The following changes since commit ef7c2af65966a57c98d3c47e6c2fe1ce2103b7f6:
> 
>   Prepare v2020.01-rc5 (2019-12-16 07:39:56 -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git 
> u-boot-stm32-20191218
> 
> for you to fetch changes up to eddd79291d2026f8fefebc3f5d39928d7c649241:
> 
>   stm32mp1: configs: Resync with savedefconfig (2019-12-18 11:58:36 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

RE: [PATCH] ARM: stm32: Permit multiple board targets

[Patrick DELAUNAY]

Hi Marek,

> From: Marek Vasut 
> Sent: mercredi 18 décembre 2019 07:59
> 
> Setting TARGET_STM32MP1 in Kconfig always forces SYS_BOARD,
> SYS_VENDOR and SYS_CONFIG_NAME to values set by the ST reference
> platforms. Allow changing that by pulling out the TARGET_STM32MP157C_DK2
> and making the ST reference platform settings conditional on
> TARGET_STM32MP157C_DK2 .
> Other platforms can now define a different TARGET_ and thus override the SYS_
> settings in their Kconfig.
> 
> Signed-off-by: Marek Vasut 
> Cc: Patrick Delaunay 
> Cc: Patrice Chotard 
> ---
>  board/st/stm32mp1/Kconfig | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/board/st/stm32mp1/Kconfig b/board/st/stm32mp1/Kconfig index
> 4fa2360b4f..c84aa41f06 100644
> --- a/board/st/stm32mp1/Kconfig
> +++ b/board/st/stm32mp1/Kconfig
> @@ -1,4 +1,8 @@
> -if TARGET_STM32MP1
> +config TARGET_STM32MP157C_DK2
> + bool "support of STMicroelectronics STM32MP157C-DK2 Discovery
> Board"
> + default y
> +
> +if TARGET_STM32MP157C_DK2
> 
>  config SYS_BOARD
>   default "stm32mp1"
> @@ -22,8 +26,4 @@ config CMD_STBOARD
> This compile the stboard command to
> read and write the board in the OTP.
> 
> -config TARGET_STM32MP157C_DK2
> - bool "support of STMicroelectronics STM32MP157C-DK2 Discovery
> Board"
> - default y

I try to understood the issue but checked DK2 is not enought
(I will soon introduce a new config for EV1 support)

What it the use case ?

Add a new board (not a board provided by ST)  which are managed by a new 
directory
board//

I think, if it is the case, we should test CONFIG_SYS_VENDOR = "stm32mp1"
in board/st/stm32mp1/Kconfig

And move CONFIG_SYS_VENDOR to arch

NB: default value can be overidde in your board defconfig...

Normally:
- stm32mp1_trusted_defconfig
- stm32mp1_basic_defconfig 
- stm32mp1_optee_defconfig

only support the directory ST board with board/st/stm32mp1

>  endif
> --
> 2.24.1

Patrick

RE: [PATCH] ARM: stm32: Fill in missing loadaddr

[Patrick DELAUNAY]

Hi Marek,

> From: Marek Vasut 
> Sent: mercredi 18 décembre 2019 07:59
> 
> Since CONFIG_LOADADDR is not set, the default value of $loadaddr variable is
> not set in the environment either. Set the default load address to 256 MiB 
> from the
> start of DRAM.
> 
> Signed-off-by: Marek Vasut 
> Cc: Patrick Delaunay 
> Cc: Patrice Chotard 
> ---
>  include/configs/stm32mp1.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h index
> dfc397c63c..59a86aee79 100644
> --- a/include/configs/stm32mp1.h
> +++ b/include/configs/stm32mp1.h
> @@ -36,6 +36,7 @@
>   * Needed by "loadb"
>   */
>  #define CONFIG_SYS_LOAD_ADDR STM32_DDR_BASE
> +#define CONFIG_LOADADDR  0xd000
> 
>  /* ATAGs */
>  #define CONFIG_CMDLINE_TAG
> --
> 2.24.1

Yes 

I never defined this CONFIG because not yet needed...
I alway use the load or boot command with address.

Just  to known, you need to have loadaddr for which use case ?

I check the usage in U-Boot code ...
And it is the only the default address when the value is not defined in CLI

./cmd/qfw.c:126:env = env_get("loadaddr");
./cmd/load.c:432:   s = env_get("loadaddr");
./cmd/bootefi.c:369:saddr = env_get("loadaddr");
./cmd/ini.c:240:argc < 3 ? env_get("loadaddr") : argv[2], NULL, 
16);
./cmd/net.c:190:s = env_get("loadaddr");
./cmd/reiser.c:91:  addr_str = env_get("loadaddr");
./cmd/zfs.c:57: addr_str = env_get("loadaddr");
./cmd/mvebu/bubt.c:101: addr_str = env_get("loadaddr");
./fs/fs.c:691:  addr_str = env_get("loadaddr");
./common/board_r.c:467: load_addr = env_get_ulong("loadaddr", 16, load_addr);
./common/update.c:269:  env_addr = env_get("loadaddr");
./common/image.c:563:static int on_loadaddr(const char *name, const char 
*value, enum env_op op,
./common/image.c:1079:  select = (argc == 0) ? env_get("loadaddr") : 
argv[0];

It is more or less the same usage than: 

./include/configs/stm32mp1.h:38:#define CONFIG_SYS_LOAD_ADDR
STM32_DDR_BASE

PS: I don't known why we have 2 differents CONFIG : CONFIG_SYS_LOAD_ADDR & 
CONFIG_LOADADDR

Normally with distro, the others variables for location of each binary are used:

kernel_addr_r=0xc200
fdt_addr_r=0xc400
scriptaddr=0xc410
pxefile_addr_r=0xc420
splashimage=0xc430
ramdisk_addr_r=0xc440


And I don't see reason to don't use the beginning of the DDR for load with 
address,
so I prefer:

- /*
-  * Needed by "loadb"
-  */
-  #define CONFIG_SYS_LOAD_ADDR STM32_DDR_BASE

+ /*
+  * default load location
-+ */
+ #define CONFIG_LOADADDR   STM32_DDR_BASE
+ #define CONFIG_SYS_LOAD_ADDR  CONFIG_LOADADDR 


But perhaps I miss something...

Patrick

Re: OMAP L138 LCDK - giving up maintainership

[Sekhar Nori]

On 18/12/19 6:15 PM, Adam Ford wrote:
> On Tue, Dec 17, 2019 at 5:15 PM Peter Howard  
> wrote:
>>
>> Tom and others,
>>
>> I finish at my current job on Friday, as such I will have no immediate
>> involvement with the L138 chip (not that I've had that much in recent
>> times).  So it makes sense to remove me as maintainer.  Especially as
>> the email listed for me will start bouncing.  so is the simplest way
> 
> Best wishes in the new endeavors.
> 
>> just to submit a patch clearing out the maintainer entry in
>> board/davinci/da8xxevm/MAINTAINERS ?  Also does anyone on the list wish
>> to take over?  Adam, I know you don't have the time from recent emails.
> 
> Because my employer views the LCDK as the replacement to the product
> they made (da850-evm), I don't think they would take kindly to me
> being the maintainer of it.  I have been helping where can I to try
> and unify those two devices as much as I can, because I think there is
> value in sharing as many of the resources as possible.  I have an
> LCDK, and I will continue to help where I can.
> 
>> Bartosz?  Sekhar - do you want to nominate someone from TI?

Lokesh from TI has been a prolific U-Boot contributor. Has access to
LCDK board. I just requested him to take up LCDK maintainership and he
agreed.

Thanks,
Sekhar

Re: OMAP L138 LCDK - giving up maintainership

[Adam Ford]

On Tue, Dec 17, 2019 at 5:15 PM Peter Howard  wrote:
>
> Tom and others,
>
> I finish at my current job on Friday, as such I will have no immediate
> involvement with the L138 chip (not that I've had that much in recent
> times).  So it makes sense to remove me as maintainer.  Especially as
> the email listed for me will start bouncing.  so is the simplest way

Best wishes in the new endeavors.

> just to submit a patch clearing out the maintainer entry in
> board/davinci/da8xxevm/MAINTAINERS ?  Also does anyone on the list wish
> to take over?  Adam, I know you don't have the time from recent emails.

Because my employer views the LCDK as the replacement to the product
they made (da850-evm), I don't think they would take kindly to me
being the maintainer of it.  I have been helping where can I to try
and unify those two devices as much as I can, because I think there is
value in sharing as many of the resources as possible.  I have an
LCDK, and I will continue to help where I can.

> Bartosz?  Sekhar - do you want to nominate someone from TI?
>
>

adam
> --
> Peter Howard 
> Peter Howard 

RE: [PATCH] ARM: stm32: Allow overriding setup_mac_address()

[Patrick DELAUNAY]

Hi Marek,

> From: Marek Vasut 
> Sent: mercredi 18 décembre 2019 07:59
> 
> Let board code override setup_mac_address(), which is useful e.g. if the board
> derives the MAC address from another source, like an I2C EEPROM.
> 
> Signed-off-by: Marek Vasut 
> Cc: Patrick Delaunay 
> Cc: Patrice Chotard 

Reviewed-by: Patrick Delaunay 

> ---
>  arch/arm/mach-stm32mp/cpu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c index
> ed7d9f61dc..856c7ced7a 100644
> --- a/arch/arm/mach-stm32mp/cpu.c
> +++ b/arch/arm/mach-stm32mp/cpu.c
> @@ -449,7 +449,7 @@ static void setup_boot_mode(void)
>   * If there is no MAC address in the environment, then it will be initialized
>   * (silently) from the value in the OTP.
>   */
> -static int setup_mac_address(void)
> +__weak int setup_mac_address(void)

Perhaps add prototype in:
arch/arm/mach-stm32mp/include/mach/sys_proto.h

just to avoid the new warning with W=1

warning: no previous prototype for 'setup_mac_address' [-Wmissing-prototypes]


>  {
>  #if defined(CONFIG_NET)
>   int ret;
> --
> 2.24.1

But anyway

Reviewed-by: Patrick Delaunay 

Regards

Re: [U-Boot] Please pull from u-boot-i2c next

[Tom Rini]

On Tue, Dec 17, 2019 at 01:01:58PM +0100, Heiko Schocher wrote:

> Hello Tom,
> 
> please pull from uboot-i2c next branch:
> 
> The following changes since commit 553cb06887825314e74a9bdac337467c77d1db88:
> 
>   Merge tag 'dm-next-13dec19' of
> https://gitlab.denx.de/u-boot/custodians/u-boot-dm into next (2019-12-12
> 08:18:59 -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-i2c.git 
> tags/20191217-for-next
> 
> for you to fetch changes up to 033e18b47bd020610f84ca88c5ce3b88215d563a:
> 
>   misc: i2c_eeprom: add size query (2019-12-17 06:58:19 +0100)
> 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

RE: [PATCH] net: dwc_eth_qos: Pass -1 to phy_connect() to scan for all PHYs

[Patrick DELAUNAY]

Hi,

> From: Marek Vasut 
> Sent: mercredi 18 décembre 2019 07:49
> 
> PHY address 0 is a valid PHY address, to scan for all PHYs, pass -1 to
> phy_connect(). Passing 0 used to work before be accident, but does no longer.
> 
> Signed-off-by: Marek Vasut 
> Cc: Joe Hershberger 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> Cc: Ramon Fried 

Reviewed-by: Patrick Delaunay 

> ---
>  drivers/net/dwc_eth_qos.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c index
> da5b696c9d..4632111635 100644
> --- a/drivers/net/dwc_eth_qos.c
> +++ b/drivers/net/dwc_eth_qos.c
> @@ -1045,7 +1045,7 @@ static int eqos_start(struct udevice *dev)
>* don't need to reconnect/reconfigure again
>*/
>   if (!eqos->phy) {
> - eqos->phy = phy_connect(eqos->mii, 0, dev,
> + eqos->phy = phy_connect(eqos->mii, -1, dev,
>   eqos->config->interface(dev));
>   if (!eqos->phy) {
>   pr_err("phy_connect() failed");
> --
> 2.24.1

Regards

[PULL] Pull request: u-boot-stm32 u-boot-stm32-20191218

[Patrick DELAUNAY]

Hi Tom

Please pull the last STM32 related patches for v2020.01

Travis CI status:
 https://travis-ci.org/patrickdelaunay/u-boot/builds/626655770

With the following fixes:
- fix crash for stm32mp1: remove the BOOTSTAGE feature
- fix warning for stm32mp1: add the missing cls command

And I also resync the stm32mp1 defconfig.

Thanks,
Patrick

git request-pull origin/master 
https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git u-boot-stm32-20191218
warn: No match for commit eddd79291d2026f8fefebc3f5d39928d7c649241 found at 
https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git
warn: Are you sure you pushed 'u-boot-stm32-20191218' there?
The following changes since commit ef7c2af65966a57c98d3c47e6c2fe1ce2103b7f6:

  Prepare v2020.01-rc5 (2019-12-16 07:39:56 -0500)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git u-boot-stm32-20191218

for you to fetch changes up to eddd79291d2026f8fefebc3f5d39928d7c649241:

  stm32mp1: configs: Resync with savedefconfig (2019-12-18 11:58:36 +0100)


- Fix stm32mp1 crash (bootstage) and warning (cls)


Patrick Delaunay (3):
  stm32mp1: imply CMD_CLS
  stm32mp1: remove the imply BOOTSTAGE
  stm32mp1: configs: Resync with savedefconfig

 arch/arm/mach-stm32mp/Kconfig   | 3 +--
 configs/stm32mp15_basic_defconfig   | 2 +-
 configs/stm32mp15_optee_defconfig   | 2 +-
 configs/stm32mp15_trusted_defconfig | 2 +-
 4 files changed, 4 insertions(+), 5 deletions(-)

[PATCH] riscv: Add option to print registers on exception

[Sean Anderson]

When debugging, it can be helpful to see more information about an
unhandled exception. This patch adds an option to view the registers at
the time of the trap, similar to the linux output on a kernel panic.

Signed-off-by: Sean Anderson 
---
 arch/riscv/Kconfig  |  3 +++
 arch/riscv/cpu/mtrap.S  |  3 ++-
 arch/riscv/lib/interrupts.c | 50 +
 3 files changed, 44 insertions(+), 12 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 85e15ebffa..3338b788f8 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -222,6 +222,9 @@ config XIP
  from a NOR flash memory without copying the code to ram.
  Say yes here if U-Boot boots from flash directly.

+config SHOW_REGS
+   bool "Show registers on unhandled exception"
+
 config STACK_SIZE_SHIFT
int
default 14
diff --git a/arch/riscv/cpu/mtrap.S b/arch/riscv/cpu/mtrap.S
index 407ecfa9c0..e40c7bd3f4 100644
--- a/arch/riscv/cpu/mtrap.S
+++ b/arch/riscv/cpu/mtrap.S
@@ -64,7 +64,8 @@ trap_entry:
SREG x31, 31 * REGBYTES(sp)
csrr a0, MODE_PREFIX(cause)
csrr a1, MODE_PREFIX(epc)
-   mv a2, sp
+   csrr a2, MODE_PREFIX(tval)
+   mv a3, sp
jal handle_trap
csrw MODE_PREFIX(epc), a0

diff --git a/arch/riscv/lib/interrupts.c b/arch/riscv/lib/interrupts.c
index 3b25c5b7a7..0f1e5123d2 100644
--- a/arch/riscv/lib/interrupts.c
+++ b/arch/riscv/lib/interrupts.c
@@ -5,6 +5,8 @@
  *
  * Copyright (C) 2017 Andes Technology Corporation
  * Rick Chen, Andes Technology Corporation 
+ *
+ * Copyright (C) 2019 Sean Anderson 
  */

 #include 
@@ -13,7 +15,34 @@
 #include 
 #include 

-static void _exit_trap(ulong code, ulong epc, struct pt_regs *regs)
+static void show_regs(struct pt_regs *regs)
+{
+#ifdef CONFIG_SHOW_REGS
+   printf("RA: " REG_FMT " SP:  " REG_FMT " GP:  " REG_FMT "\n",
+  regs->ra, regs->sp, regs->gp);
+   printf("TP: " REG_FMT " T0:  " REG_FMT " T1:  " REG_FMT "\n",
+  regs->tp, regs->t0, regs->t1);
+   printf("T2: " REG_FMT " S0:  " REG_FMT " S1:  " REG_FMT "\n",
+  regs->t2, regs->s0, regs->s1);
+   printf("A0: " REG_FMT " A1:  " REG_FMT " A2:  " REG_FMT "\n",
+  regs->a0, regs->a1, regs->a2);
+   printf("A3: " REG_FMT " A4:  " REG_FMT " A5:  " REG_FMT "\n",
+  regs->a3, regs->a4, regs->a5);
+   printf("A6: " REG_FMT " A7:  " REG_FMT " S2:  " REG_FMT "\n",
+  regs->a6, regs->a7, regs->s2);
+   printf("S3: " REG_FMT " S4:  " REG_FMT " S5:  " REG_FMT "\n",
+  regs->s3, regs->s4, regs->s5);
+   printf("S6: " REG_FMT " S7:  " REG_FMT " S8:  " REG_FMT "\n",
+  regs->s6, regs->s7, regs->s8);
+   printf("S9: " REG_FMT " S10: " REG_FMT " S11: " REG_FMT "\n",
+  regs->s9, regs->s10, regs->s11);
+   printf("T3: " REG_FMT " T4:  " REG_FMT " T5:  " REG_FMT "\n",
+  regs->t3, regs->t4, regs->t5);
+   printf("T6: " REG_FMT "\n", regs->t6);
+#endif
+}
+
+static void _exit_trap(ulong code, ulong epc, ulong tval, struct pt_regs *regs)
 {
static const char * const exception_code[] = {
"Instruction address misaligned",
@@ -34,14 +63,13 @@ static void _exit_trap(ulong code, ulong epc, struct 
pt_regs *regs)
"Store/AMO page fault",
};

-   if (code < ARRAY_SIZE(exception_code)) {
-   printf("exception code: %ld , %s , epc %lx , ra %lx\n",
-  code, exception_code[code], epc, regs->ra);
-   } else {
-   printf("reserved exception code: %ld , epc %lx , ra %lx\n",
-  code, epc, regs->ra);
-   }
+   if (code < ARRAY_SIZE(exception_code))
+   printf("Unhandled exception: %s\n", exception_code[code]);
+   else
+   printf("Unhandled exception code: %ld\n", code);

+   printf("PC: " REG_FMT " TVAL: " REG_FMT "\n", epc, tval);
+   show_regs(regs);
hang();
 }

@@ -65,7 +93,7 @@ int disable_interrupts(void)
return 0;
 }

-ulong handle_trap(ulong cause, ulong epc, struct pt_regs *regs)
+ulong handle_trap(ulong cause, ulong epc, ulong tval, struct pt_regs *regs)
 {
ulong is_irq, irq;

@@ -83,11 +111,11 @@ ulong handle_trap(ulong cause, ulong epc, struct pt_regs 
*regs)
timer_interrupt(0); /* handle timer interrupt */
break;
default:
-   _exit_trap(cause, epc, regs);
+   _exit_trap(cause, epc, tval, regs);
break;
};
} else {
-   _exit_trap(cause, epc, regs);
+   _exit_trap(cause, epc, tval, regs);
}

return epc;
-- 
2.23.0

[PATCH] Add dependencies for MALLOC_F and OF_LIBFDT

[Sean Anderson]

Some features implicitly depended on MALLOC_F and OF_LIBFDT and would
fail at link-time if these features were not enabled.

Signed-off-by: Sean Anderson 
---
 drivers/serial/Kconfig | 3 +++
 dts/Kconfig| 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index ece7d87d4c..bd95f70b61 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -100,6 +100,7 @@ config CONS_INDEX
 config DM_SERIAL
bool "Enable Driver Model for serial drivers"
depends on DM
+   select SYS_MALLOC_F
help
  Enable driver model for serial. This replaces
  drivers/serial/serial.c with the serial uclass, which
@@ -136,6 +137,7 @@ config SERIAL_SEARCH_ALL
 config SPL_DM_SERIAL
bool "Enable Driver Model for serial drivers in SPL"
depends on DM_SERIAL && SPL_DM
+   select SYS_SPL_MALLOC_F
default y
help
  Enable driver model for serial in SPL. This replaces
@@ -146,6 +148,7 @@ config SPL_DM_SERIAL
 config TPL_DM_SERIAL
bool "Enable Driver Model for serial drivers in TPL"
depends on DM_SERIAL && TPL_DM
+   select SYS_TPL_MALLOC_F
default y if TPL && DM_SERIAL
help
  Enable driver model for serial in TPL. This replaces
diff --git a/dts/Kconfig b/dts/Kconfig
index 2bd959a7dc..01665f8e56 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -25,6 +25,7 @@ menu "Device Tree Control"
 config OF_CONTROL
bool "Run-time configuration via Device Tree"
select DTC
+   select OF_LIBFDT if !OF_PLATDATA
help
  This feature provides for run-time configuration of U-Boot
  via a flattened device tree.
@@ -42,6 +43,7 @@ config OF_BOARD_FIXUP
 config SPL_OF_CONTROL
bool "Enable run-time configuration via Device Tree in SPL"
depends on SPL && OF_CONTROL
+   select SPL_OF_LIBFDT if !SPL_OF_PLATDATA
help
  Some boards use device tree in U-Boot but only have 4KB of SRAM
  which is not enough to support device tree. Disable this option to
@@ -50,6 +52,7 @@ config SPL_OF_CONTROL
 config TPL_OF_CONTROL
bool "Enable run-time configuration via Device Tree in TPL"
depends on TPL && OF_CONTROL
+   select TPL_OF_LIBFDT if !TPL_OF_PLATDATA
help
  Some boards use device tree in U-Boot but only have 4KB of SRAM
  which is not enough to support device tree. Enable this option to
-- 
2.23.0

[PATCH] riscv: Fix breakage caused by linker relaxation

[Sean Anderson]

Due to the two-instruction sequence needed to access arbitrary memory
locations, the RISC-V linker aggressively optimises memory accesses and
jumps at link-time. This is called "linker relaxation," and is discussed
in this SiFive article
.
One of the optimizations in place is to assume that the __global_pointer
symbol is placed in the gp register. To quote the article:

"...The magic __global_pointer$ symbol is defined to point 0x800 bytes
past the start of the .sdata section. The 0x800 magic number allows
signed 12-bit offsets from __global_pointer$ to address symbols at the
start of the .sdata section. The linker assumes that if this symbol is
defined, then the gp register contains that value, which it can then use
to relax accesses to global symbols within that 12-bit range. The
compiler treats the gp register as a constant so it doesn't need to be
saved or restored, which means it is generally only written by _start,
the ELF entry point."

However, U-Boot instead keeps the global data pointer in gp. This causes
memory accesses and jumps optimized to use the gp pointer to fail. To
fix this problem, we undefine the __global_pointer symbol.

Signed-off-by: Sean Anderson 
---
 arch/riscv/cpu/u-boot.lds | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/riscv/cpu/u-boot.lds b/arch/riscv/cpu/u-boot.lds
index 838a844399..c00d17c736 100644
--- a/arch/riscv/cpu/u-boot.lds
+++ b/arch/riscv/cpu/u-boot.lds
@@ -32,7 +32,6 @@ SECTIONS

. = ALIGN(4);
.data : {
-   __global_pointer$ = . + 0x800;
*(.data*)
}
. = ALIGN(4);
-- 
2.23.0

[PATCH] Include missing headers for fdt_support.h

[Sean Anderson]

fdt_support.h is missing declarations for bd_t. Including asm/u-boot.h
pulls in the definition.

Signed-off-by: Sean Anderson 
---
 include/fdt_support.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/fdt_support.h b/include/fdt_support.h
index 2286ea7793..3f4bc643d4 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -9,6 +9,7 @@

 #ifdef CONFIG_OF_LIBFDT

+#include 
 #include 

 u32 fdt_getprop_u32_default_node(const void *fdt, int off, int cell,
-- 
2.23.0

[PATCH] Make the sandbox board_run_command the default

[Sean Anderson]

If CONFIG_CMDLINE=n, common/cli.c calls board_run_command. This fails to
link on most architectures. However, the sandbox architecture has an
implementation which we can use.

Signed-off-by: Sean Anderson 
---
 arch/sandbox/cpu/start.c | 7 ---
 common/cli.c | 7 +++
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
index fff9cbdd79..5b7d54869d 100644
--- a/arch/sandbox/cpu/start.c
+++ b/arch/sandbox/cpu/start.c
@@ -319,13 +319,6 @@ static int sandbox_cmdline_cb_show_of_platdata(struct
sandbox_state *state,
 }
 SANDBOX_CMDLINE_OPT(show_of_platdata, 0, "Show of-platdata in SPL");

-int board_run_command(const char *cmdline)
-{
-   printf("## Commands are disabled. Please enable CONFIG_CMDLINE.\n");
-
-   return 1;
-}
-
 static void setup_ram_buf(struct sandbox_state *state)
 {
/* Zero the RAM buffer if we didn't read it, to keep valgrind happy */
diff --git a/common/cli.c b/common/cli.c
index 67ceb635a6..59551ef40b 100644
--- a/common/cli.c
+++ b/common/cli.c
@@ -70,6 +70,13 @@ int run_command_repeatable(const char *cmd, int flag)
return 0;
 #endif
 }
+#else
+__weak int board_run_command(const char *cmdline)
+{
+   printf("## Commands are disabled. Please enable CONFIG_CMDLINE.\n");
+
+   return 1;
+}
 #endif /* CONFIG_CMDLINE */

 int run_command_list(const char *cmd, int len, int flag)
-- 
2.23.0

[PATCH] Include missing headers for asm-generic/sections.h

[Sean Anderson]

asm-generic/sections.h references ulong but does not include
linux/types.h

Signed-off-by: Sean Anderson 
---
 include/asm-generic/sections.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index 296c0cf9b8..17a31ec788 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -8,6 +8,8 @@
 #ifndef _ASM_GENERIC_SECTIONS_H_
 #define _ASM_GENERIC_SECTIONS_H_

+#include 
+
 /* References to section boundaries */

 extern char _text[], _stext[], _etext[];
-- 
2.23.0

[PATCH 2/3] rpi4: Update memory map to accommodate scb devices

[Andre Przywara]

From: Amit Singh Tomar 

Some of the devices(for instance, pcie and gnet controller) sitting on
SCB bus falls behind/below the memory range that we currenty have.

This patch updates the memory range to map those devices correctly.

Signed-off-by: Amit Singh Tomar 
Reviewed-by: Andre Przywara 
Signed-off-by: Andre Przywara 
---
 arch/arm/mach-bcm283x/init.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index 3b5f45b431..9966d6c833 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -42,9 +42,9 @@ static struct mm_region bcm2711_mem_map[] = {
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {
-   .virt = 0xfe00UL,
-   .phys = 0xfe00UL,
-   .size = 0x0180UL,
+   .virt = 0xfc00UL,
+   .phys = 0xfc00UL,
+   .size = 0x0380UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
 PTE_BLOCK_NON_SHARE |
 PTE_BLOCK_PXN | PTE_BLOCK_UXN
-- 
2.17.1

[PATCH 3/3] rpi4: Enable GENET Ethernet controller

[Andre Przywara]

From: Amit Singh Tomar 

The Raspberry Pi 4 SoC features an integrated Gigabit Ethernet
controller, connected as a platform device.

Enable the new driver in the three applicable defconfigs, to allow
TFTP booting on the board.

Signed-off-by: Amit Singh Tomar 
[Andre: Add joined and 32-bit configs]
Signed-off-by: Andre Przywara 
---
 configs/rpi_4_32b_defconfig | 2 ++
 configs/rpi_4_defconfig | 2 ++
 configs/rpi_arm64_defconfig | 1 +
 3 files changed, 5 insertions(+)

diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig
index 00f80f71ad..e7ea88bd4b 100644
--- a/configs/rpi_4_32b_defconfig
+++ b/configs/rpi_4_32b_defconfig
@@ -24,6 +24,8 @@ CONFIG_DM_KEYBOARD=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_BCM2835=y
+CONFIG_DM_ETH=y
+CONFIG_BCMGENET=y
 CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_GENERIC is not set
 # CONFIG_REQUIRE_SERIAL_CONSOLE is not set
diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
index 8cf1bb81ff..b0f9cf1c0e 100644
--- a/configs/rpi_4_defconfig
+++ b/configs/rpi_4_defconfig
@@ -24,6 +24,8 @@ CONFIG_DM_KEYBOARD=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_BCM2835=y
+CONFIG_DM_ETH=y
+CONFIG_BCMGENET=y
 CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_GENERIC is not set
 # CONFIG_REQUIRE_SERIAL_CONSOLE is not set
diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
index 10fbe0db92..00b3096481 100644
--- a/configs/rpi_arm64_defconfig
+++ b/configs/rpi_arm64_defconfig
@@ -36,6 +36,7 @@ CONFIG_USB_KEYBOARD=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_LAN78XX=y
 CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_BCMGENET=y
 CONFIG_DM_VIDEO=y
 CONFIG_VIDEO_BPP32=y
 CONFIG_SYS_WHITE_ON_BLACK=y
-- 
2.17.1

[PATCH 1/3] net: Add support for Broadcom GENETv5 Ethernet controller

[Andre Przywara]

From: Amit Singh Tomar 

The Broadcom GENET Ethernet MACs are used in several MIPS based SoCs
and in the Broadcom 2711/2838 SoC used on the Raspberry Pi 4.
There is no publicly available documentation, so this driver is based
on the Linux driver. Compared to that the queue management is
drastically simplified, also we only support version 5 of the IP and
RGMII connections between MAC and PHY, as used on the RPi4.

Signed-off-by: Amit Singh Tomar 
Reviewed-by: Andre Przywara 
[Andre: heavy cleanup and a few fixes]
Signed-off-by: Andre Przywara 
---
 drivers/net/Kconfig|   7 +
 drivers/net/Makefile   |   1 +
 drivers/net/bcmgenet.c | 702 +
 3 files changed, 710 insertions(+)
 create mode 100644 drivers/net/bcmgenet.c

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 142a2c6953..999714dd39 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -136,6 +136,13 @@ config BCM6368_ETH
help
  This driver supports the BCM6368 Ethernet MAC.
 
+config BCMGENET
+   bool "BCMGENET V5 support"
+   depends on DM_ETH
+   select PHYLIB
+   help
+ This driver supports the BCMGENET Ethernet MAC.
+
 config DWC_ETH_QOS
bool "Synopsys DWC Ethernet QOS device support"
depends on DM_ETH
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 30991834ec..6e0a68834d 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_AG7XXX) += ag7xxx.o
 obj-$(CONFIG_ARMADA100_FEC) += armada100_fec.o
 obj-$(CONFIG_BCM6348_ETH) += bcm6348-eth.o
 obj-$(CONFIG_BCM6368_ETH) += bcm6368-eth.o
+obj-$(CONFIG_BCMGENET) += bcmgenet.o
 obj-$(CONFIG_DRIVER_AT91EMAC) += at91_emac.o
 obj-$(CONFIG_DRIVER_AX88180) += ax88180.o
 obj-$(CONFIG_BCM_SF2_ETH) += bcm-sf2-eth.o
diff --git a/drivers/net/bcmgenet.c b/drivers/net/bcmgenet.c
new file mode 100644
index 00..24b025d804
--- /dev/null
+++ b/drivers/net/bcmgenet.c
@@ -0,0 +1,702 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Amit Singh Tomar 
+ *
+ * Driver for Broadcom GENETv5 Ethernet controller (as found on the RPi4)
+ * This driver is based on the Linux driver:
+ *  drivers/net/ethernet/broadcom/genet/bcmgenet.c
+ *  which is: Copyright (c) 2014-2017 Broadcom
+ *
+ * The hardware supports multiple queues (16 priority queues and one
+ * default queue), both for RX and TX. There are 256 DMA descriptors (both
+ * for TX and RX), and they live in MMIO registers. The hardware allows
+ * assigning descriptor ranges to queues, but we choose the most simple setup:
+ * All 256 descriptors are assigned to the default queue (#16).
+ * Also the Linux driver supports multiple generations of the MAC, whereas
+ * we only support v5, as used in the Raspberry Pi 4.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Register definitions derived from Linux source */
+#define SYS_REV_CTRL   0x00
+
+#define SYS_PORT_CTRL  0x04
+#define PORT_MODE_EXT_GPHY 3
+
+#define GENET_SYS_OFF  0x
+#define SYS_RBUF_FLUSH_CTRL(GENET_SYS_OFF  + 0x08)
+#define SYS_TBUF_FLUSH_CTRL(GENET_SYS_OFF  + 0x0c)
+
+#define GENET_EXT_OFF  0x0080
+#define EXT_RGMII_OOB_CTRL (GENET_EXT_OFF + 0x0c)
+#define RGMII_LINK BIT(4)
+#define OOB_DISABLEBIT(5)
+#define RGMII_MODE_EN  BIT(6)
+#define ID_MODE_DISBIT(16)
+
+#define GENET_RBUF_OFF 0x0300
+#define RBUF_TBUF_SIZE_CTRL(GENET_RBUF_OFF + 0xb4)
+#define RBUF_CTRL  (GENET_RBUF_OFF + 0x00)
+#define RBUF_ALIGN_2B  BIT(1)
+
+#define GENET_UMAC_OFF 0x0800
+#define UMAC_MIB_CTRL  (GENET_UMAC_OFF + 0x580)
+#define UMAC_MAX_FRAME_LEN (GENET_UMAC_OFF + 0x014)
+#define UMAC_MAC0  (GENET_UMAC_OFF + 0x00c)
+#define UMAC_MAC1  (GENET_UMAC_OFF + 0x010)
+#define UMAC_CMD   (GENET_UMAC_OFF + 0x008)
+#define MDIO_CMD   (GENET_UMAC_OFF + 0x614)
+#define UMAC_TX_FLUSH  (GENET_UMAC_OFF + 0x334)
+#define MDIO_START_BUSYBIT(29)
+#define MDIO_READ_FAIL BIT(28)
+#define MDIO_RD(2 << 26)
+#define MDIO_WRBIT(26)
+#define MDIO_PMD_SHIFT 21
+#define MDIO_PMD_MASK  0x1f
+#define MDIO_REG_SHIFT 16
+#define MDIO_REG_MASK  0x1f
+
+#define CMD_TX_EN  BIT(0)
+#define CMD_RX_EN  BIT(1)
+#define UMAC_SPEED_10  0
+#define UMAC_SPEED_100 1
+#define UMAC_SPEED_10002
+#define 

[PATCH 0/3] Ethernet support for Raspberry Pi 4

[Andre Przywara]

This series adds Ethernet support for the Raspberry Pi 4. The SoC
includes a "Broadcom Genet v5 MAC" IP, connected as a proper platform
device (no USB anymore!). Patch 1 provides a driver for that. There does
not seem to be publicly available documentation, so this is based on the
Linux driver, but stripped down to just provide what U-Boot needs.
Patch 2 fixes up the RPi4 memory map to accommodate the MMIO area the
MAC lives in, while patch 3 enables it in the respective defconfigs.

Compared to the RFC post from Friday this is now fully functional,
although there are some minor issues left (sometimes unstable
initialisation, weird behaviour on repeated tftp gets (though it works),
PHY startup not properly timing out, (unjustified?) cache complaints on
32-bit).

Please have a look and test it, I hope this helps to simplify
development, as you spare the SD card and its slot from heavy swapping.

This tries to address the review comments on the RFC post (mostly my
own ;-), I put a branch on [1] showing what was changed over the original
post.

Cheers,
Andre.

P.S.: Since Amit will be busy this week, I took the freedom of fixing this up
and posting this (with his permission).

[1] https://github.com/apritzel/u-boot/commits/rpi4-eth

Amit Singh Tomar (3):
  net: Add support for Broadcom GENETv5 Ethernet controller
  rpi4: Update memory map to accommodate scb devices
  rpi4: Enable GENET Ethernet controller

 arch/arm/mach-bcm283x/init.c |   6 +-
 configs/rpi_4_32b_defconfig  |   2 +
 configs/rpi_4_defconfig  |   2 +
 configs/rpi_arm64_defconfig  |   1 +
 drivers/net/Kconfig  |   7 +
 drivers/net/Makefile |   1 +
 drivers/net/bcmgenet.c   | 702 +++
 7 files changed, 718 insertions(+), 3 deletions(-)
 create mode 100644 drivers/net/bcmgenet.c

-- 
2.17.1

Re: [PATCH] usb: dwc3: Fix UTMI/UTMIW phy interface initialization

[Marek Vasut]

On 12/18/19 11:43 AM, Andy Shevchenko wrote:
> On Wed, Dec 18, 2019 at 9:30 AM Jagan Teki  wrote:
>>
>> DWC3 support phy interfaces like 8/16-bit UTMI+. phy interface
>> initialization code would handle them properly along with UNKNOWN
>> type by default if none of the user/board doesn't need to use the
>> phy interfaces at all.
>>
>> The current code is masking the 8/16-bit UTMI+ interface bits globally
>> which indeed effect the UNKNOWN cases, therefore it effects the platforms
>> which are not using phy interfaces at all.
>>
>> So, handle the phy masking bits accordingly on respective interface
>> type cases.
>>
> 
> Thanks, it works again!
> Tested-by: Andy Shevchenko 

Applied to usb/master.

RE: [PATCH 2/2] stm32mp1: configs: Resync with savedefconfig

[Patrick DELAUNAY]

Hi,

> From: Patrick DELAUNAY 
> Sent: mercredi 18 décembre 2019 10:13
> 
> Rsync all defconfig files using moveconfig.py
> 
> Signed-off-by: Patrick Delaunay 

Acked-by: Patrick Delaunay 

Applied to u-boot-stm32/master, thanks!

> ---
> 
>  configs/stm32mp15_basic_defconfig   | 2 +-
>  configs/stm32mp15_optee_defconfig   | 2 +-
>  configs/stm32mp15_trusted_defconfig | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/configs/stm32mp15_basic_defconfig
> b/configs/stm32mp15_basic_defconfig
> index 358c2cd079..713a7e6c57 100644
> --- a/configs/stm32mp15_basic_defconfig
> +++ b/configs/stm32mp15_basic_defconfig
> @@ -132,10 +132,10 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0483
>  CONFIG_USB_GADGET_PRODUCT_NUM=0x5720
>  CONFIG_USB_GADGET_DWC2_OTG=y
>  CONFIG_DM_VIDEO=y
> +CONFIG_BACKLIGHT_GPIO=y
>  CONFIG_VIDEO_BPP8=y
>  CONFIG_VIDEO_BPP16=y
>  CONFIG_VIDEO_BPP32=y
> -CONFIG_BACKLIGHT_GPIO=y
>  CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
>  CONFIG_VIDEO_LCD_RAYDIUM_RM68200=y
>  CONFIG_VIDEO_STM32=y
> diff --git a/configs/stm32mp15_optee_defconfig
> b/configs/stm32mp15_optee_defconfig
> index a065d3e088..f9161fd7d1 100644
> --- a/configs/stm32mp15_optee_defconfig
> +++ b/configs/stm32mp15_optee_defconfig
> @@ -116,10 +116,10 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0483
>  CONFIG_USB_GADGET_PRODUCT_NUM=0x5720
>  CONFIG_USB_GADGET_DWC2_OTG=y
>  CONFIG_DM_VIDEO=y
> +CONFIG_BACKLIGHT_GPIO=y
>  CONFIG_VIDEO_BPP8=y
>  CONFIG_VIDEO_BPP16=y
>  CONFIG_VIDEO_BPP32=y
> -CONFIG_BACKLIGHT_GPIO=y
>  CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
>  CONFIG_VIDEO_LCD_RAYDIUM_RM68200=y
>  CONFIG_VIDEO_STM32=y
> diff --git a/configs/stm32mp15_trusted_defconfig
> b/configs/stm32mp15_trusted_defconfig
> index 632f11f59b..a5ea528ae3 100644
> --- a/configs/stm32mp15_trusted_defconfig
> +++ b/configs/stm32mp15_trusted_defconfig
> @@ -115,10 +115,10 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0483
>  CONFIG_USB_GADGET_PRODUCT_NUM=0x5720
>  CONFIG_USB_GADGET_DWC2_OTG=y
>  CONFIG_DM_VIDEO=y
> +CONFIG_BACKLIGHT_GPIO=y
>  CONFIG_VIDEO_BPP8=y
>  CONFIG_VIDEO_BPP16=y
>  CONFIG_VIDEO_BPP32=y
> -CONFIG_BACKLIGHT_GPIO=y
>  CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
>  CONFIG_VIDEO_LCD_RAYDIUM_RM68200=y
>  CONFIG_VIDEO_STM32=y
> --
> 2.17.1

Regards

Patrick

RE: [PATCH 1/2] stm32mp1: remove the imply BOOTSTAGE

[Patrick DELAUNAY]

Hi,

> From: Patrick DELAUNAY 
> Sent: mercredi 18 décembre 2019 10:13
> 
> This patch is only a temporarily workaround for crash introduced by commit
> ac9cd4805c8b ("bootstage: Correct relocation algorithm").
> 
> The crash occurs because the bootstage struct is not correctly aligned when
> BOOTSTAGE feature is activated.
> 
> Signed-off-by: Patrick Delaunay 

Acked-by: Patrick Delaunay 

Applied to u-boot-stm32/master, thanks!

> ---
> Hi,
> 
> For issue analysis and patch proposal, see the patch
> 
> [U-Boot,v3] board_f.c: Insure gd->new_bootstage alignment
> http://patchwork.ozlabs.org/patch/1201452/
> 
> Patrick
> 
> 
>  arch/arm/mach-stm32mp/Kconfig | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
> index c9bc084194..a110522095 100644
> --- a/arch/arm/mach-stm32mp/Kconfig
> +++ b/arch/arm/mach-stm32mp/Kconfig
> @@ -46,9 +46,7 @@ config TARGET_STM32MP1
>   select STM32_SERIAL
>   select SYS_ARCH_TIMER
>   imply BOOTCOUNT_LIMIT
> - imply BOOTSTAGE
>   imply CMD_BOOTCOUNT
> - imply CMD_BOOTSTAGE
>   imply DISABLE_CONSOLE
>   imply PRE_CONSOLE_BUFFER
>   imply SILENT_CONSOLE
> --
> 2.17.1

Regards
Patrick

Re: [PATCH v3 5/5] test/py: Create a test for launching UEFI binaries from FIT images

[Heinrich Schuchardt]

On 12/18/19 9:22 AM, Cristian Ciocaltea wrote:

+};
+};
+'''
+
+@pytest.mark.boardspec('sandbox')

This test looks ok in principal. But why should we restrict it to the
sandbox?

Let me see how this should work on real hardware, I'm going to test
on qemu for the moment.


Device trees cannot be used in conjunction with ACPI tables when booting
via UEFI. Currently this concerns only x86 and x86_64 but Phytec is
working on an arm64 board which shall provide an ACPI table. So you
probably want to check CONFIG_GENERATE_ACPI_TABLE instead of the board
type, e.g.

@pytest.mark.notbuildconfigspec('generate_acpi_table')

Best regards

Heinrich

[PATCH] board: xilinx: Add support for user configurable boot script offset

[Michal Simek]

From: T Karthik Reddy 

Currently "script_offset_f" env variable is hardcoded, this variable
specifies from which offset of the flash boot.scr should be read/write.
As flashes are of different sizes having a fixed offset makes it
difficult to load other images into the flash which may overwrite the
boot script or cannot utilize the full memory. This current fix
creates a new config "CONFIG_BOOT_SCRIPT_OFFSET" which holds the
offset address, overwrites the "script_offset_f" variable.
Also removed existing variable with default values, as the default
values are held by CONFIG_BOOT_SCRIPT_OFFSET

Signed-off-by: T Karthik Reddy 
Signed-off-by: Michal Simek 
---

 board/xilinx/Kconfig| 9 +
 board/xilinx/versal/board.c | 2 ++
 board/xilinx/zynq/board.c   | 2 ++
 board/xilinx/zynqmp/zynqmp.c| 2 ++
 include/configs/xilinx_versal.h | 1 -
 include/configs/xilinx_zynqmp.h | 1 -
 include/configs/zynq-common.h   | 1 -
 7 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/board/xilinx/Kconfig b/board/xilinx/Kconfig
index cb272eafda7a..7833b11767c4 100644
--- a/board/xilinx/Kconfig
+++ b/board/xilinx/Kconfig
@@ -47,3 +47,12 @@ config XILINX_OF_BOARD_DTB_ADDR
depends on OF_BOARD
help
  Offset in the memory where the board configuration DTB is placed.
+
+config BOOT_SCRIPT_OFFSET
+   hex "Boot script offset"
+   depends on ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL
+   default 0xFC if ARCH_ZYNQ
+   default 0x3E8 if ARCH_ZYNQMP
+   default 0x7F8 if ARCH_VERSAL
+   help
+  Specifies distro boot script offset in NAND/NOR flash.
diff --git a/board/xilinx/versal/board.c b/board/xilinx/versal/board.c
index 45724478a25e..9fa9e76e6663 100644
--- a/board/xilinx/versal/board.c
+++ b/board/xilinx/versal/board.c
@@ -203,6 +203,8 @@ int board_late_init(void)
initrd_hi = round_down(initrd_hi, SZ_16M);
env_set_addr("initrd_high", (void *)initrd_hi);
 
+   env_set_hex("script_offset_f", CONFIG_BOOT_SCRIPT_OFFSET);
+
return 0;
 }
 
diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
index 8929b6c5d22d..420a5ca66311 100644
--- a/board/xilinx/zynq/board.c
+++ b/board/xilinx/zynq/board.c
@@ -76,6 +76,8 @@ int board_late_init(void)
 
env_set("boot_targets", new_targets);
 
+   env_set_hex("script_offset_f", CONFIG_BOOT_SCRIPT_OFFSET);
+
return 0;
 }
 
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index b72eade43eea..8bdc67748ec2 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -667,6 +667,8 @@ int board_late_init(void)
initrd_hi = round_down(initrd_hi, SZ_16M);
env_set_addr("initrd_high", (void *)initrd_hi);
 
+   env_set_hex("script_offset_f", CONFIG_BOOT_SCRIPT_OFFSET);
+
reset_reason();
 
return 0;
diff --git a/include/configs/xilinx_versal.h b/include/configs/xilinx_versal.h
index f426127edcff..dec5001b5fe4 100644
--- a/include/configs/xilinx_versal.h
+++ b/include/configs/xilinx_versal.h
@@ -92,7 +92,6 @@
"kernel_size_r=0x1000\0" \
"scriptaddr=0x2000\0" \
"ramdisk_addr_r=0x0210\0" \
-   "script_offset_f=0x7F8\0" \
"script_size_f=0x8\0"
 
 #if defined(CONFIG_MMC_SDHCI_ZYNQ)
diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
index b13765e17593..010738363d13 100644
--- a/include/configs/xilinx_zynqmp.h
+++ b/include/configs/xilinx_zynqmp.h
@@ -113,7 +113,6 @@
"kernel_addr_r=0x1800\0" \
"scriptaddr=0x2000\0" \
"ramdisk_addr_r=0x0210\0" \
-   "script_offset_f=0x3e8\0" \
"script_size_f=0x8\0" \
 
 #if defined(CONFIG_MMC_SDHCI_ZYNQ)
diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
index 4dbd30054643..fe4679a90b2c 100644
--- a/include/configs/zynq-common.h
+++ b/include/configs/zynq-common.h
@@ -203,7 +203,6 @@
"fdt_high=0x2000\0" \
"initrd_high=0x2000\0"  \
"scriptaddr=0x2\0"  \
-   "script_offset_f=0xFC\0"\
"script_size_f=0x4\0"   \
"fdt_addr_r=0x1f0\0"\
"pxefile_addr_r=0x200\0"\
-- 
2.24.0

RE: [PATCH] stm32mp1: imply CMD_CLS

[Patrick DELAUNAY]

Hi,

> From: Patrick DELAUNAY 
> Sent: mardi 3 décembre 2019 09:39
> To: u-boot@lists.denx.de
> Cc: Patrick DELAUNAY ; Patrice CHOTARD
> ; U-Boot STM32  mailman.stormreply.com>
> Subject: [PATCH] stm32mp1: imply CMD_CLS
> Importance: High
> 
> Activate by default the command CLS (clear screen); this command used in pxe
> or sysboot command (DISTRO support) when the "menu background" keyword is
> present.
> 
> This patch avoid the warning "Unknown command 'cls'"
> with extlinux.conf:
> 
> # Generic Distro Configuration file generated by OpenEmbedded menu title 
> Select
> the boot mode MENU BACKGROUND /splash.bmp TIMEOUT 20 DEFAULT
> stm32mp157c-ev1-emmc LABEL stm32mp157c-ev1-emmc
>   KERNEL /uImage
>   FDT /stm32mp157c-ev1.dtb
>   APPEND root=/dev/mmcblk1p4 rootwait rw console=ttySTM0,115200
> 
> 
>   ...
>   Retrieving file: /mmc0_stm32mp157c-ev1_extlinux/extlinux.conf
>   614 bytes read in 36 ms (16.6 KiB/s)
>   Retrieving file: /splash.bmp
>   46180 bytes read in 40 ms (1.1 MiB/s)
>   Unknown command 'cls' - try 'help'
>   Select the boot mode
>   1:  stm32mp157c-ev1-sdcard
>   ...
> 
> Signed-off-by: Patrick Delaunay 


Acked-by: Patrick Delaunay 

Applied to u-boot-stm32/master, thanks!

> ---
> 
>  arch/arm/mach-stm32mp/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
> index c9bc084194..e920b89ef5 100644
> --- a/arch/arm/mach-stm32mp/Kconfig
> +++ b/arch/arm/mach-stm32mp/Kconfig
> @@ -49,6 +49,7 @@ config TARGET_STM32MP1
>   imply BOOTSTAGE
>   imply CMD_BOOTCOUNT
>   imply CMD_BOOTSTAGE
> + imply CMD_CLS if CMD_BMP
>   imply DISABLE_CONSOLE
>   imply PRE_CONSOLE_BUFFER
>   imply SILENT_CONSOLE
> --
> 2.17.1

BR
Patrick

Re: [ANN] U-Boot v2020.01-rc5 released

[Andy Shevchenko]

On Tue, Dec 17, 2019 at 3:46 PM Andy Shevchenko
 wrote:

> Tom, if this is not going to be settled soon (till Friday), I ask to revert 
> it.

Tom, Jagan fixed the issue, I would expect a fix in the release.
Thanks!

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] usb: dwc3: Fix UTMI/UTMIW phy interface initialization

[Andy Shevchenko]

On Wed, Dec 18, 2019 at 9:30 AM Jagan Teki  wrote:
>
> DWC3 support phy interfaces like 8/16-bit UTMI+. phy interface
> initialization code would handle them properly along with UNKNOWN
> type by default if none of the user/board doesn't need to use the
> phy interfaces at all.
>
> The current code is masking the 8/16-bit UTMI+ interface bits globally
> which indeed effect the UNKNOWN cases, therefore it effects the platforms
> which are not using phy interfaces at all.
>
> So, handle the phy masking bits accordingly on respective interface
> type cases.
>

Thanks, it works again!
Tested-by: Andy Shevchenko 

> Fixes: 6b7ebff00190 ("usb: dwc3: Add phy interface for dwc3_uboot")
> Reported-by: Andy Shevchenko 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/usb/dwc3/core.c | 12 
>  drivers/usb/dwc3/core.h | 20 
>  2 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 0f9a632816..77c555e769 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -622,15 +622,19 @@ static void dwc3_uboot_hsphy_mode(struct dwc3_device 
> *dwc3_dev,
>
> /* Set dwc3 usb2 phy config */
> reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
> -   reg |= DWC3_GUSB2PHYCFG_PHYIF;
> -   reg &= ~DWC3_GUSB2PHYCFG_USBTRDTIM_MASK;
>
> switch (hsphy_mode) {
> case USBPHY_INTERFACE_MODE_UTMI:
> -   reg |= DWC3_GUSB2PHYCFG_USBTRDTIM_8BIT;
> +   reg &= ~(DWC3_GUSB2PHYCFG_PHYIF_MASK |
> +   DWC3_GUSB2PHYCFG_USBTRDTIM_MASK);
> +   reg |= DWC3_GUSB2PHYCFG_PHYIF(UTMI_PHYIF_8_BIT) |
> +   DWC3_GUSB2PHYCFG_USBTRDTIM(USBTRDTIM_UTMI_8_BIT);
> break;
> case USBPHY_INTERFACE_MODE_UTMIW:
> -   reg |= DWC3_GUSB2PHYCFG_USBTRDTIM_16BIT;
> +   reg &= ~(DWC3_GUSB2PHYCFG_PHYIF_MASK |
> +   DWC3_GUSB2PHYCFG_USBTRDTIM_MASK);
> +   reg |= DWC3_GUSB2PHYCFG_PHYIF(UTMI_PHYIF_16_BIT) |
> +   DWC3_GUSB2PHYCFG_USBTRDTIM(USBTRDTIM_UTMI_16_BIT);
> break;
> default:
> break;
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index bff53e072b..1c08a2c5b6 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -162,18 +162,14 @@
>  /* Global USB2 PHY Configuration Register */
>  #define DWC3_GUSB2PHYCFG_PHYSOFTRST(1 << 31)
>  #define DWC3_GUSB2PHYCFG_SUSPHY(1 << 6)
> -#define DWC3_GUSB2PHYCFG_PHYIF BIT(3)
> -
> -/* Global USB2 PHY Configuration Mask */
> -#define DWC3_GUSB2PHYCFG_USBTRDTIM_MASK(0xf << 10)
> -
> -/* Global USB2 PHY Configuration Offset */
> -#define DWC3_GUSB2PHYCFG_USBTRDTIM_OFFSET  10
> -
> -#define DWC3_GUSB2PHYCFG_USBTRDTIM_16BIT   (0x5 << \
> -   DWC3_GUSB2PHYCFG_USBTRDTIM_OFFSET)
> -#define DWC3_GUSB2PHYCFG_USBTRDTIM_8BIT(0x9 << \
> -   DWC3_GUSB2PHYCFG_USBTRDTIM_OFFSET)
> +#define DWC3_GUSB2PHYCFG_PHYIF(n)  ((n) << 3)
> +#define DWC3_GUSB2PHYCFG_PHYIF_MASKDWC3_GUSB2PHYCFG_PHYIF(1)
> +#define DWC3_GUSB2PHYCFG_USBTRDTIM(n)  ((n) << 10)
> +#define DWC3_GUSB2PHYCFG_USBTRDTIM_MASK
> DWC3_GUSB2PHYCFG_USBTRDTIM(0xf)
> +#define USBTRDTIM_UTMI_8_BIT   9
> +#define USBTRDTIM_UTMI_16_BIT  5
> +#define UTMI_PHYIF_16_BIT  1
> +#define UTMI_PHYIF_8_BIT   0
>
>  /* Global USB3 PIPE Control Register */
>  #define DWC3_GUSB3PIPECTL_PHYSOFTRST   (1 << 31)
> --
> 2.18.0.321.gffc6fa0e3
>


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 5/5] test/py: Create a test for launching UEFI binaries from FIT images

[Heinrich Schuchardt]

On 12/18/19 9:22 AM, Cristian Ciocaltea wrote:

On Tue, Dec 17, 2019 at 10:08:31PM +0100, Heinrich Schuchardt wrote:

On 12/17/19 8:47 AM, Cristian Ciocaltea wrote:

This test verifies the implementation of the 'bootm' extension that
handles UEFI binaries inside FIT images (enabled via CONFIG_BOOTM_EFI).

Signed-off-by: Cristian Ciocaltea 
---
   test/py/tests/test_efi_fit.py | 233 ++
   1 file changed, 233 insertions(+)
   create mode 100644 test/py/tests/test_efi_fit.py

diff --git a/test/py/tests/test_efi_fit.py b/test/py/tests/test_efi_fit.py
new file mode 100644
index 00..52b415b198
--- /dev/null
+++ b/test/py/tests/test_efi_fit.py
@@ -0,0 +1,233 @@
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2019, Cristian Ciocaltea 
+
+# Test launching UEFI binaries from FIT images.
+
+import os
+import pytest
+import u_boot_utils as util
+
+# Define the parametrized ITS data to be used for FIT image generation.
+its_data = '''
+/dts-v1/;
+
+/ {
+description = "EFI image with FDT blob";
+#address-cells = <1>;
+
+images {
+efi {
+description = "Sandbox EFI";
+data = /incbin/("%(efi-bin)s");
+type = "%(kernel-type)s";
+arch = "sandbox";
+os = "efi";
+compression = "%(efi-comp)s";
+load = <0x0>;
+entry = <0x0>;
+};
+fdt {
+description = "Sandbox FDT";
+data = /incbin/("%(fdt-bin)s");
+type = "flat_dt";
+arch = "sandbox";
+compression = "%(fdt-comp)s";
+};
+};
+
+configurations {
+default = "config-efi-fdt";
+config-efi-fdt {
+description = "EFI FIT w/ FDT";
+kernel = "efi";
+fdt = "fdt";
+};
+config-efi-nofdt {
+description = "EFI FIT w/o FDT";
+kernel = "efi";
+};
+};
+};
+'''
+
+# Define the parametrized FDT data.
+fdt_data = '''
+/dts-v1/;
+
+/ {
+model = "Sandbox %(fdt_type) EFI FIT Boot Test ";
+compatible = "sandbox";
+
+reset@0 {
+compatible = "sandbox,reset";


This produces a warning:

+dtc ./test-efi-fit-sandbox-internal.dts -O dtb -o
./test-efi-fit-sandbox-internal.dtb
./test-efi-fit-sandbox-internal.dts:8.13-10.7: Warning
(unit_address_vs_reg): /reset@0: node has a unit name, but no reg property


A similar sample is also used by test_fit.py and test_vboot.py, which
expose the same warning, that's why I initially ignored it.
If acceptable, I can suppress it via '-W no-unit_address_vs_reg'.


reset@0 includes a unit-address. So a reg property is expected. How about:

/dts-v1/;

/ {
#address-cells = <1>;
#size-cells = <0>;

model = "Sandbox %(fdt_type) EFI FIT Boot Test ";
compatible = "sandbox";

reset@0 {
compatible = "sandbox,reset";
reg = <0>;
};
};

Best regards

Heinrich




+};
+};
+'''
+
+@pytest.mark.boardspec('sandbox')


This test looks ok in principal. But why should we restrict it to the
sandbox?


Let me see how this should work on real hardware, I'm going to test
on qemu for the moment.


Best regards

Heinrich


+@pytest.mark.buildconfigspec('bootm_efi')
+@pytest.mark.buildconfigspec('cmd_bootefi_hello_compile')
+@pytest.mark.requiredtool('dtc')
+def test_efi_fit(u_boot_console):
+"""Test handling of UEFI binaries inside FIT images.
+
+The tests are trying to launch U-Boot's helloworld.efi embedded into
+FIT images, in uncompressed or gzip compressed format.
+
+Additionally, a sample FDT blob is created and embedded into the above
+mentioned FIT images, in uncompressed or gzip compressed format.
+
+The following test cases are currently defined and enabled:
+- Launch uncompressed FIT EFI & FIT FDT
+- Launch compressed FIT EFI & FIT FDT
+- Launch uncompressed FIT EFI & internal FDT
+- Launch compressed FIT EFI & internal FDT
+"""
+
+def make_fpath(fname):
+"""Compute the path of a given (temporary) file.
+
+Args:
+fname: The name of a file within U-Boot build dir.
+Return:
+The computed file path.
+"""
+return os.path.join(u_boot_console.config.build_dir, fname)
+
+def make_efi(fname, comp):
+"""Create an UEFI binary.
+
+This simply copies lib/efi_loader/helloworld.efi into U-Boot
+build dir and, optionally, compresses the file using gzip.
+
+Args:
+fname: The target file name within U-Boot build dir.
+comp: Flag to enable gzip compression.
+Return:
+The path of the created file.
+"""
+bin_path = make_fpath(fname)
+os.system('cp %s %s' % (make_fpath('lib/efi_loader/helloworld.efi'), 
bin_path))
+if comp:
+util.run_and_log(u_boot_console, ['gzip', '-f', bin_path])
+bin_path += '.gz'
+

[PATCH 1/1] test/py: use valid device tree in test_fit.py

[Heinrich Schuchardt]

The device tree compiler expects that a node with a unit-address has a reg
property.

Signed-off-by: Heinrich Schuchardt 
---
 test/py/tests/test_fit.py | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/test/py/tests/test_fit.py b/test/py/tests/test_fit.py
index 356d9a20f2..84b3f95850 100755
--- a/test/py/tests/test_fit.py
+++ b/test/py/tests/test_fit.py
@@ -83,13 +83,16 @@ base_fdt = '''
 /dts-v1/;

 / {
-model = "Sandbox Verified Boot Test";
-compatible = "sandbox";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   model = "Sandbox Verified Boot Test";
+   compatible = "sandbox";

reset@0 {
compatible = "sandbox,reset";
+   reg = <0>;
};
-
 };
 '''

--
2.24.0

[PATCH 2/2] stm32mp1: configs: Resync with savedefconfig

[Patrick Delaunay]

Rsync all defconfig files using moveconfig.py

Signed-off-by: Patrick Delaunay 
---

 configs/stm32mp15_basic_defconfig   | 2 +-
 configs/stm32mp15_optee_defconfig   | 2 +-
 configs/stm32mp15_trusted_defconfig | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/configs/stm32mp15_basic_defconfig 
b/configs/stm32mp15_basic_defconfig
index 358c2cd079..713a7e6c57 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -132,10 +132,10 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0483
 CONFIG_USB_GADGET_PRODUCT_NUM=0x5720
 CONFIG_USB_GADGET_DWC2_OTG=y
 CONFIG_DM_VIDEO=y
+CONFIG_BACKLIGHT_GPIO=y
 CONFIG_VIDEO_BPP8=y
 CONFIG_VIDEO_BPP16=y
 CONFIG_VIDEO_BPP32=y
-CONFIG_BACKLIGHT_GPIO=y
 CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
 CONFIG_VIDEO_LCD_RAYDIUM_RM68200=y
 CONFIG_VIDEO_STM32=y
diff --git a/configs/stm32mp15_optee_defconfig 
b/configs/stm32mp15_optee_defconfig
index a065d3e088..f9161fd7d1 100644
--- a/configs/stm32mp15_optee_defconfig
+++ b/configs/stm32mp15_optee_defconfig
@@ -116,10 +116,10 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0483
 CONFIG_USB_GADGET_PRODUCT_NUM=0x5720
 CONFIG_USB_GADGET_DWC2_OTG=y
 CONFIG_DM_VIDEO=y
+CONFIG_BACKLIGHT_GPIO=y
 CONFIG_VIDEO_BPP8=y
 CONFIG_VIDEO_BPP16=y
 CONFIG_VIDEO_BPP32=y
-CONFIG_BACKLIGHT_GPIO=y
 CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
 CONFIG_VIDEO_LCD_RAYDIUM_RM68200=y
 CONFIG_VIDEO_STM32=y
diff --git a/configs/stm32mp15_trusted_defconfig 
b/configs/stm32mp15_trusted_defconfig
index 632f11f59b..a5ea528ae3 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -115,10 +115,10 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0483
 CONFIG_USB_GADGET_PRODUCT_NUM=0x5720
 CONFIG_USB_GADGET_DWC2_OTG=y
 CONFIG_DM_VIDEO=y
+CONFIG_BACKLIGHT_GPIO=y
 CONFIG_VIDEO_BPP8=y
 CONFIG_VIDEO_BPP16=y
 CONFIG_VIDEO_BPP32=y
-CONFIG_BACKLIGHT_GPIO=y
 CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
 CONFIG_VIDEO_LCD_RAYDIUM_RM68200=y
 CONFIG_VIDEO_STM32=y
-- 
2.17.1

[PATCH 1/2] stm32mp1: remove the imply BOOTSTAGE

[Patrick Delaunay]

This patch is only a temporarily workaround for crash introduced by
commit ac9cd4805c8b ("bootstage: Correct relocation algorithm").

The crash occurs because the bootstage struct is not correctly aligned
when BOOTSTAGE feature is activated.

Signed-off-by: Patrick Delaunay 
---
Hi,

For issue analysis and patch proposal, see the patch

[U-Boot,v3] board_f.c: Insure gd->new_bootstage alignment
http://patchwork.ozlabs.org/patch/1201452/

Patrick


 arch/arm/mach-stm32mp/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
index c9bc084194..a110522095 100644
--- a/arch/arm/mach-stm32mp/Kconfig
+++ b/arch/arm/mach-stm32mp/Kconfig
@@ -46,9 +46,7 @@ config TARGET_STM32MP1
select STM32_SERIAL
select SYS_ARCH_TIMER
imply BOOTCOUNT_LIMIT
-   imply BOOTSTAGE
imply CMD_BOOTCOUNT
-   imply CMD_BOOTSTAGE
imply DISABLE_CONSOLE
imply PRE_CONSOLE_BUFFER
imply SILENT_CONSOLE
-- 
2.17.1

RE: [PATCH v3] board_f.c: Insure gd->new_bootstage alignment

[Patrick DELAUNAY]

Hi Simon,

> From: Simon Glass 
> Sent: mardi 17 décembre 2019 16:46
> 
> Hi Patrice,
> 
> On Wed, 27 Nov 2019 at 02:11, Patrice Chotard  wrote:
> >
> > In reserve_bootstage(), in case size is odd, gd->new_bootstage is not
> > aligned. In bootstage_relocate(), the platform hangs when getting
> > access to data->record[i].name.
> > To avoid this issue, make gd->new_bootstage 16 byte aligned.
> >
> > To insure that new_bootstage is 16 byte aligned (at least needed for
> > x86_64 and ARMv8) and new_bootstage starts down to get enough space,
> > ALIGN_DOWN macro is used.
> >
> > Fixes: ac9cd4805c8b ("bootstage: Correct relocation algorithm")
> >
> > Signed-off-by: Patrice Chotard 
> > Reviewed-by: Vikas MANOCHA 
> > Reviewed-by: Patrick Delaunay 
> > Tested-by: Patrick Delaunay 

For information, Patrice is absent for personal reason up to beginning next 
year.
Don't wait a fast answer.

> For this patch I think it would be better to update reserve_fdt() to keep 
> things
> aligned, assuming that is the problem.

I don't sure that solve the issue, 
for me the problem is only for the bootstage struct (gd->bootstage)
And reserve_fdt() already alligne size on 32 bytes

If I remember the Patrice analysis:

1- bootstage_get_size return a odd value (or at least not 16 bytes aligned I 
don't remember).

2- In reserve_bootstage()
int size = bootstage_get_size();
gd->start_addr_sp -= size
=> it is a unaligned address even if gd->start_addr_sp is 32 bytes 
alligned

gd->new_bootstage = map_sysmem(gd->start_addr_sp, size);
=> also unaligned

3- Then during relocation, in reloc_bootstage()
gd->bootstage = gd->new_bootstage;


4- crash occur because in next bootstage function beaucse the boostage address 
don't respect pointer to struct allignement...

struct bootstage_data *data = gd->bootstage


> At some point we should also document that reservations must keep things
> aligned.
> 
> Perhaps this should be handled by a separate function called from all these
> places, which subtracts gd->start_addr_sp and ensures 16-byte alignment.

Yes that can be a improvement,  but perhaps ia a second step / second serie

Do you think about a function called in all reversed_ functions (when 
start_addr_sp is modified)...

static int reserved_allign_check(void)
{
/* make stack pointer 16-byte aligned */
if (gd->start_addr_sp & 0xf) {
gd->start_addr_sp -= 16;
gd->start_addr_sp &= ~0xf;
 }
}

I prefer a function to reserved a size wich replace in any reserve_ function  
the line : 
gd->start_addr_sp -= ...

/* reserve size and make stack pointer 16-byte aligned */
static int reserve(size_t size)
{
gd->start_addr_sp -= size;
/* make stack pointer 16-byte aligned */
gd->start_addr_sp = ALIGN_DOWN(gd->start_addr_sp, 16);
}

I think I will push it, when the patrice patch will be accepted.

> Regards,
> Simon

Regards
Patrick

Re: [U-Boot] [PATCH] qemu-riscv64_smode, sifive-fu540: fix extlinux (define preboot)

[David Abdurachmanov]

On Wed, Dec 18, 2019 at 3:13 AM Vagrant Cascadian  wrote:
>
> On 2019-09-25, Vagrant Cascadian wrote:
> > On 2019-08-21, David Abdurachmanov wrote:
> >> Commit 37304aaf60bf92a5dc3ef222ba520698bd862a44 removed preboot
> >> commands in RISC-V targets and broke extlinux support as reported
> >> by Fu Wei .
> >>
> >> The patch finishes migration of CONFIG_USE_PREBOOT and CONFIG_REBOOT
> >> to Kconfig.
> >
> > Tested using qemu-riscv64_smode and it fixes extlinux booting. Thanks!
> >
> > Please CC me on future updates to the patch series.
> >
> > Tested-by: Vagrant Cascadian 
>
> This patch, or something like it, is still needed with u-boot
> v2020.01-rc5 for extlinux support to load the device-tree from the boot
> firmware.
>
> Is there a new approach in the works, or any chance to see something
> like this get merged soon?

I do carry several experiment patches in Fedora/RISCV, which I didn't
yet sent for a review.
Basically that allows me to boot a single Fedora/RISCV disk image on
QEMU virt machine
and SiFive Unleashed.

See: 
http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/uboot-tools.spec#L36

Note some of the patches were merged in rc5.

You would want the following two patches:
http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/riscv64-set-fdt_addr.patch
http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/riscv-bootargs-preboot.patch

If you could review them I could send them out.

david

Re: [PATCH v3 2/5] bootm: Add a bootm command for type IH_OS_EFI

[Cristian Ciocaltea]

On Tue, Dec 17, 2019 at 09:34:44PM +0100, Heinrich Schuchardt wrote:
> On 12/17/19 8:46 AM, Cristian Ciocaltea wrote:
> > Add support for booting EFI binaries contained in FIT images.
> > A typical usage scenario is chain-loading GRUB2 in a verified
> > boot environment.
> > 
> > Signed-off-by: Cristian Ciocaltea 
> 
> You missed the current changes in common/bootm_os.c. I will rebase the
> patch.

Right, sorry. I have already rebased the patch and I will resubmit it
as soon as I finalize the changes on pytest.

Thanks!

> Reviewed-by: Heinrich Schuchardt 

RE: [PATCH v3] board_f.c: Insure gd->new_bootstage alignment

[Patrick DELAUNAY]

Hi Tom,

> From: Tom Rini 
> Sent: mardi 17 décembre 2019 13:52
> 
> On Mon, Dec 16, 2019 at 11:53:48AM +, Patrick DELAUNAY wrote:
> > Hi Tom,
> >
> > > From: Patrice CHOTARD 
> > > Sent: mercredi 27 novembre 2019 10:12
> > >
> > > In reserve_bootstage(), in case size is odd, gd->new_bootstage is
> > > not aligned. In bootstage_relocate(), the platform hangs when
> > > getting access to data-
> > > >record[i].name.
> > > To avoid this issue, make gd->new_bootstage 16 byte aligned.
> > >
> > > To insure that new_bootstage is 16 byte aligned (at least needed for
> > > x86_64 and ARMv8) and new_bootstage starts down to get enough space,
> > > ALIGN_DOWN macro is used.
> > >
> > > Fixes: ac9cd4805c8b ("bootstage: Correct relocation algorithm")
> > >
> > > Signed-off-by: Patrice Chotard 
> > > Reviewed-by: Vikas MANOCHA 
> > > Reviewed-by: Patrick Delaunay 
> > > Tested-by: Patrick Delaunay 
> > >
> >
> > Do you plan to merge this fixe for the next rc for v2020.01 ?
> > Or do you expect some change / review.
> >
> > This patch is mandatory for stm32mp1 (ARM plaform with bootstage
> > feature activated).
> > Without this patch, the boot failed (at least for v2020.01-rc3 : crash
> > has struct pointer new_bootstage is not aligned).
> >
> > Or I will deactivate the BOOTSTAGE feature...
> 
> I think at this point I would prefer dropping BOOTSTAGE from those boards for
> the release.  There's already been more than one "I think this is safe" 
> followed by
> "this broke ..." changes I've tried.  Sorry!

I know the number of issue with  "it should work" and I understood.
I sill push a patch to deactivate bootstatge (remove 2 "imply" in fact) and a 
new pull request.


> --
> Tom

BR
Patrick

Re: [PATCH v3 5/5] test/py: Create a test for launching UEFI binaries from FIT images

[Cristian Ciocaltea]

On Tue, Dec 17, 2019 at 10:08:31PM +0100, Heinrich Schuchardt wrote:
> On 12/17/19 8:47 AM, Cristian Ciocaltea wrote:
> > This test verifies the implementation of the 'bootm' extension that
> > handles UEFI binaries inside FIT images (enabled via CONFIG_BOOTM_EFI).
> > 
> > Signed-off-by: Cristian Ciocaltea 
> > ---
> >   test/py/tests/test_efi_fit.py | 233 ++
> >   1 file changed, 233 insertions(+)
> >   create mode 100644 test/py/tests/test_efi_fit.py
> > 
> > diff --git a/test/py/tests/test_efi_fit.py b/test/py/tests/test_efi_fit.py
> > new file mode 100644
> > index 00..52b415b198
> > --- /dev/null
> > +++ b/test/py/tests/test_efi_fit.py
> > @@ -0,0 +1,233 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +# Copyright (c) 2019, Cristian Ciocaltea 
> > +
> > +# Test launching UEFI binaries from FIT images.
> > +
> > +import os
> > +import pytest
> > +import u_boot_utils as util
> > +
> > +# Define the parametrized ITS data to be used for FIT image generation.
> > +its_data = '''
> > +/dts-v1/;
> > +
> > +/ {
> > +description = "EFI image with FDT blob";
> > +#address-cells = <1>;
> > +
> > +images {
> > +efi {
> > +description = "Sandbox EFI";
> > +data = /incbin/("%(efi-bin)s");
> > +type = "%(kernel-type)s";
> > +arch = "sandbox";
> > +os = "efi";
> > +compression = "%(efi-comp)s";
> > +load = <0x0>;
> > +entry = <0x0>;
> > +};
> > +fdt {
> > +description = "Sandbox FDT";
> > +data = /incbin/("%(fdt-bin)s");
> > +type = "flat_dt";
> > +arch = "sandbox";
> > +compression = "%(fdt-comp)s";
> > +};
> > +};
> > +
> > +configurations {
> > +default = "config-efi-fdt";
> > +config-efi-fdt {
> > +description = "EFI FIT w/ FDT";
> > +kernel = "efi";
> > +fdt = "fdt";
> > +};
> > +config-efi-nofdt {
> > +description = "EFI FIT w/o FDT";
> > +kernel = "efi";
> > +};
> > +};
> > +};
> > +'''
> > +
> > +# Define the parametrized FDT data.
> > +fdt_data = '''
> > +/dts-v1/;
> > +
> > +/ {
> > +model = "Sandbox %(fdt_type) EFI FIT Boot Test ";
> > +compatible = "sandbox";
> > +
> > +reset@0 {
> > +compatible = "sandbox,reset";
> 
> This produces a warning:
> 
> +dtc ./test-efi-fit-sandbox-internal.dts -O dtb -o
> ./test-efi-fit-sandbox-internal.dtb
> ./test-efi-fit-sandbox-internal.dts:8.13-10.7: Warning
> (unit_address_vs_reg): /reset@0: node has a unit name, but no reg property

A similar sample is also used by test_fit.py and test_vboot.py, which
expose the same warning, that's why I initially ignored it.
If acceptable, I can suppress it via '-W no-unit_address_vs_reg'.

> > +};
> > +};
> > +'''
> > +
> > +@pytest.mark.boardspec('sandbox')
> 
> This test looks ok in principal. But why should we restrict it to the
> sandbox?

Let me see how this should work on real hardware, I'm going to test
on qemu for the moment.

> Best regards
> 
> Heinrich
> 
> > +@pytest.mark.buildconfigspec('bootm_efi')
> > +@pytest.mark.buildconfigspec('cmd_bootefi_hello_compile')
> > +@pytest.mark.requiredtool('dtc')
> > +def test_efi_fit(u_boot_console):
> > +"""Test handling of UEFI binaries inside FIT images.
> > +
> > +The tests are trying to launch U-Boot's helloworld.efi embedded into
> > +FIT images, in uncompressed or gzip compressed format.
> > +
> > +Additionally, a sample FDT blob is created and embedded into the above
> > +mentioned FIT images, in uncompressed or gzip compressed format.
> > +
> > +The following test cases are currently defined and enabled:
> > +- Launch uncompressed FIT EFI & FIT FDT
> > +- Launch compressed FIT EFI & FIT FDT
> > +- Launch uncompressed FIT EFI & internal FDT
> > +- Launch compressed FIT EFI & internal FDT
> > +"""
> > +
> > +def make_fpath(fname):
> > +"""Compute the path of a given (temporary) file.
> > +
> > +Args:
> > +fname: The name of a file within U-Boot build dir.
> > +Return:
> > +The computed file path.
> > +"""
> > +return os.path.join(u_boot_console.config.build_dir, fname)
> > +
> > +def make_efi(fname, comp):
> > +"""Create an UEFI binary.
> > +
> > +This simply copies lib/efi_loader/helloworld.efi into U-Boot
> > +build dir and, optionally, compresses the file using gzip.
> > +
> > +Args:
> > +fname: The target file name within U-Boot build dir.
> > +comp: Flag to enable gzip compression.
> > +Return:
> > +The path of the created file.
> > +"""
> > +bin_path = make_fpath(fname)
> > +os.system('cp %s %s' % 
> > (make_fpath('lib/efi_loader/helloworld.efi'), bin_path))
> > +if comp:
> > +