Re: [PATCH u-boot-marvell 05/19] arm: mvebu: Espressobin: Use DM registered MDIO to configure switch

2022-05-01 Thread Stefan Roese

On 27.04.22 12:41, Marek Behún wrote:

From: Marek Behún 

In order to be able to get rid of the non-DM MDIO bus registered in
mvneta driver, we need to stop using board_network_enable() and instead
use the DM registered MDIO device to configure switch in
last_stage_init().

Signed-off-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan



---
  board/Marvell/mvebu_armada-37xx/board.c | 26 -
  configs/mvebu_espressobin-88f3720_defconfig |  1 +
  2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/board/Marvell/mvebu_armada-37xx/board.c 
b/board/Marvell/mvebu_armada-37xx/board.c
index 98e1b36d11..3e5e0a0b5c 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -11,6 +11,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -254,14 +255,15 @@ int board_xhci_enable(fdt_addr_t base)
return 0;
  }
  
+#ifdef CONFIG_LAST_STAGE_INIT

  /* Helper function for accessing switch devices in multi-chip connection mode 
*/
-static int mii_multi_chip_mode_write(struct mii_dev *bus, int dev_smi_addr,
+static int mii_multi_chip_mode_write(struct udevice *bus, int dev_smi_addr,
 int smi_addr, int reg, u16 value)
  {
u16 smi_cmd = 0;
  
-	if (bus->write(bus, dev_smi_addr, 0,

-  MVEBU_SW_SMI_DATA_REG, value) != 0) {
+   if (dm_mdio_write(bus, dev_smi_addr, MDIO_DEVAD_NONE,
+ MVEBU_SW_SMI_DATA_REG, value) != 0) {
printf("Error writing to the PHY addr=%02x reg=%02x\n",
   smi_addr, reg);
return -EFAULT;
@@ -272,8 +274,8 @@ static int mii_multi_chip_mode_write(struct mii_dev *bus, 
int dev_smi_addr,
  (1 << SW_SMI_CMD_SMI_OP_OFF) |
  (smi_addr << SW_SMI_CMD_DEV_ADDR_OFF) |
  (reg << SW_SMI_CMD_REG_ADDR_OFF);
-   if (bus->write(bus, dev_smi_addr, 0,
-  MVEBU_SW_SMI_CMD_REG, smi_cmd) != 0) {
+   if (dm_mdio_write(bus, dev_smi_addr, MDIO_DEVAD_NONE,
+ MVEBU_SW_SMI_CMD_REG, smi_cmd) != 0) {
printf("Error writing to the PHY addr=%02x reg=%02x\n",
   smi_addr, reg);
return -EFAULT;
@@ -283,11 +285,22 @@ static int mii_multi_chip_mode_write(struct mii_dev *bus, 
int dev_smi_addr,
  }
  
  /* Bring-up board-specific network stuff */

-int board_network_enable(struct mii_dev *bus)
+int last_stage_init(void)
  {
+   struct udevice *bus;
+   ofnode node;
+
if (!of_machine_is_compatible("globalscale,espressobin"))
return 0;
  
+	node = ofnode_by_compatible(ofnode_null(), "marvell,orion-mdio");

+   if (!ofnode_valid(node) ||
+   uclass_get_device_by_ofnode(UCLASS_MDIO, node, &bus) ||
+   device_probe(bus)) {
+   printf("Cannot find MDIO bus\n");
+   return 0;
+   }
+
/*
 * FIXME: remove this code once Topaz driver gets available
 * A3720 Community Board Only
@@ -327,6 +340,7 @@ int board_network_enable(struct mii_dev *bus)
  
  	return 0;

  }
+#endif
  
  #ifdef CONFIG_OF_BOARD_SETUP

  int ft_board_setup(void *blob, struct bd_info *bd)
diff --git a/configs/mvebu_espressobin-88f3720_defconfig 
b/configs/mvebu_espressobin-88f3720_defconfig
index af30f1b363..37e4fdc41e 100644
--- a/configs/mvebu_espressobin-88f3720_defconfig
+++ b/configs/mvebu_espressobin-88f3720_defconfig
@@ -25,6 +25,7 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y
  CONFIG_ARCH_EARLY_INIT_R=y
  CONFIG_BOARD_EARLY_INIT_F=y
  CONFIG_BOARD_LATE_INIT=y
+CONFIG_LAST_STAGE_INIT=y
  # CONFIG_CMD_FLASH is not set
  CONFIG_CMD_FUSE=y
  CONFIG_CMD_GPIO=y


Viele Grüße,
Stefan Roese

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


Re: [PATCH u-boot-marvell 04/19] net: mvneta: Remember fixed link instead of PHY address in priv data

2022-05-01 Thread Stefan Roese

On 27.04.22 12:41, Marek Behún wrote:

From: Marek Behún 

We don't need to remember PHY address anymore, because since using DM
MDIO for connecting PHY, the address is parsed by mdio-uclass from
the ofnode.

But the driver uses a special value of the address to signal fixed link
usage.

Drop phyaddr add fixed_link in driver private structure. This simplifies
code a little.

Signed-off-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan



---
  drivers/net/mvneta.c | 23 +--
  1 file changed, 5 insertions(+), 18 deletions(-)

diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
index 24a491dcde..83e9629138 100644
--- a/drivers/net/mvneta.c
+++ b/drivers/net/mvneta.c
@@ -277,12 +277,12 @@ struct mvneta_port {
u16 rx_ring_size;
  
  	phy_interface_t phy_interface;

+   bool fixed_link;
unsigned int link;
unsigned int duplex;
unsigned int speed;
  
  	int init;

-   int phyaddr;
struct phy_device *phydev;
  #if CONFIG_IS_ENABLED(DM_GPIO)
struct gpio_desc phy_reset_gpio;
@@ -576,13 +576,6 @@ static void mvneta_rxq_buf_size_set(struct mvneta_port *pp,
mvreg_write(pp, MVNETA_RXQ_SIZE_REG(rxq->id), val);
  }
  
-static int mvneta_port_is_fixed_link(struct mvneta_port *pp)

-{
-   /* phy_addr is set to invalid value for fixed link */
-   return pp->phyaddr > PHY_MAX_ADDR;
-}
-
-
  /* Start the Ethernet port RX and TX activity */
  static void mvneta_port_up(struct mvneta_port *pp)
  {
@@ -834,7 +827,7 @@ static void mvneta_defaults_set(struct mvneta_port *pp)
mvreg_write(pp, MVNETA_SDMA_CONFIG, val);
  
  	/* Enable PHY polling in hardware if not in fixed-link mode */

-   if (!mvneta_port_is_fixed_link(pp)) {
+   if (!pp->fixed_link) {
val = mvreg_read(pp, MVNETA_UNIT_CONTROL);
val |= MVNETA_PHY_POLLING_ENABLE;
mvreg_write(pp, MVNETA_UNIT_CONTROL, val);
@@ -1173,7 +1166,7 @@ static void mvneta_adjust_link(struct udevice *dev)
struct phy_device *phydev = pp->phydev;
int status_change = 0;
  
-	if (mvneta_port_is_fixed_link(pp)) {

+   if (pp->fixed_link) {
debug("Using fixed link, skip link adjust\n");
return;
}
@@ -1548,7 +1541,7 @@ static int mvneta_start(struct udevice *dev)
mvneta_port_power_up(pp, pp->phy_interface);
  
  	if (!pp->init || pp->link == 0) {

-   if (mvneta_port_is_fixed_link(pp)) {
+   if (pp->fixed_link) {
u32 val;
  
  			pp->init = 1;

@@ -1698,7 +1691,6 @@ static int mvneta_probe(struct udevice *dev)
void *blob = (void *)gd->fdt_blob;
int node = dev_of_offset(dev);
struct mii_dev *bus;
-   unsigned long addr;
void *bd_space;
int ret;
int fl_node;
@@ -1742,14 +1734,9 @@ static int mvneta_probe(struct udevice *dev)
fl_node = fdt_subnode_offset(blob, node, "fixed-link");
if (fl_node != -FDT_ERR_NOTFOUND) {
/* set phy_addr to invalid value for fixed link */
-   pp->phyaddr = PHY_MAX_ADDR + 1;
pp->duplex = fdtdec_get_bool(blob, fl_node, "full-duplex");
pp->speed = fdtdec_get_int(blob, fl_node, "speed", 0);
-   } else {
-   /* Now read phyaddr from DT */
-   addr = fdtdec_get_int(blob, node, "phy", 0);
-   addr = fdt_node_offset_by_phandle(blob, addr);
-   pp->phyaddr = fdtdec_get_int(blob, addr, "reg", 0);
+   pp->fixed_link = true;
}
  
  	bus = mdio_alloc();


Viele Grüße,
Stefan Roese

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


Re: [PATCH u-boot-marvell 03/19] net: mvneta: Use DM MDIO API for connecting PHY

2022-05-01 Thread Stefan Roese

On 27.04.22 12:41, Marek Behún wrote:

From: Marek Behún 

Use the modern DM MDIO API for connecting PHY in the mvneta driver.

This requires enabling MVMDIO driver in several config files.

Signed-off-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan



---
  configs/clearfog_defconfig  |  1 +
  configs/controlcenterdc_defconfig   |  1 +
  configs/db-88f6820-amc_defconfig|  1 +
  configs/db-88f6820-gp_defconfig |  1 +
  configs/db-mv784mp-gp_defconfig |  1 +
  configs/ds414_defconfig |  1 +
  configs/helios4_defconfig   |  1 +
  configs/maxbcm_defconfig|  1 +
  configs/mvebu_espressobin-88f3720_defconfig |  1 +
  configs/theadorable_debug_defconfig |  1 +
  configs/turris_mox_defconfig|  1 +
  configs/turris_omnia_defconfig  |  1 +
  configs/uDPU_defconfig  |  1 +
  drivers/net/Kconfig |  1 +
  drivers/net/mvneta.c| 11 +--
  15 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
index 880f16a6e0..b8f59d2962 100644
--- a/configs/clearfog_defconfig
+++ b/configs/clearfog_defconfig
@@ -63,6 +63,7 @@ CONFIG_PHY_MARVELL=y
  CONFIG_PHY_GIGE=y
  CONFIG_MVNETA=y
  CONFIG_MII=y
+CONFIG_MVMDIO=y
  CONFIG_PCI=y
  CONFIG_PCI_MVEBU=y
  CONFIG_SCSI=y
diff --git a/configs/controlcenterdc_defconfig 
b/configs/controlcenterdc_defconfig
index d4b966b93f..df38b2c54f 100644
--- a/configs/controlcenterdc_defconfig
+++ b/configs/controlcenterdc_defconfig
@@ -77,6 +77,7 @@ CONFIG_PHY_MARVELL=y
  CONFIG_PHY_GIGE=y
  CONFIG_MVNETA=y
  CONFIG_MII=y
+CONFIG_MVMDIO=y
  CONFIG_PCI=y
  CONFIG_DM_PCI_COMPAT=y
  CONFIG_PCI_MVEBU=y
diff --git a/configs/db-88f6820-amc_defconfig b/configs/db-88f6820-amc_defconfig
index 46c822fccd..9b77b4a5f0 100644
--- a/configs/db-88f6820-amc_defconfig
+++ b/configs/db-88f6820-amc_defconfig
@@ -67,6 +67,7 @@ CONFIG_PHY_MARVELL=y
  CONFIG_PHY_GIGE=y
  CONFIG_MVNETA=y
  CONFIG_MII=y
+CONFIG_MVMDIO=y
  CONFIG_PCI=y
  CONFIG_PCI_MVEBU=y
  CONFIG_DEBUG_UART_SHIFT=2
diff --git a/configs/db-88f6820-gp_defconfig b/configs/db-88f6820-gp_defconfig
index 2dcbc2f29a..f56d1fbf25 100644
--- a/configs/db-88f6820-gp_defconfig
+++ b/configs/db-88f6820-gp_defconfig
@@ -62,6 +62,7 @@ CONFIG_PHY_MARVELL=y
  CONFIG_PHY_GIGE=y
  CONFIG_MVNETA=y
  CONFIG_MII=y
+CONFIG_MVMDIO=y
  CONFIG_PCI=y
  CONFIG_PCI_MVEBU=y
  CONFIG_SCSI=y
diff --git a/configs/db-mv784mp-gp_defconfig b/configs/db-mv784mp-gp_defconfig
index f19cc54975..5683f11836 100644
--- a/configs/db-mv784mp-gp_defconfig
+++ b/configs/db-mv784mp-gp_defconfig
@@ -65,6 +65,7 @@ CONFIG_PHY_MARVELL=y
  CONFIG_PHY_GIGE=y
  CONFIG_MVNETA=y
  CONFIG_MII=y
+CONFIG_MVMDIO=y
  CONFIG_PCI=y
  CONFIG_PCI_MVEBU=y
  CONFIG_DEBUG_UART_SHIFT=2
diff --git a/configs/ds414_defconfig b/configs/ds414_defconfig
index a3279c15c5..a83fe079b3 100644
--- a/configs/ds414_defconfig
+++ b/configs/ds414_defconfig
@@ -65,6 +65,7 @@ CONFIG_PHY_MARVELL=y
  CONFIG_PHY_GIGE=y
  CONFIG_MVNETA=y
  CONFIG_MII=y
+CONFIG_MVMDIO=y
  CONFIG_PCI=y
  CONFIG_PCI_MVEBU=y
  CONFIG_DEBUG_UART_SHIFT=2
diff --git a/configs/helios4_defconfig b/configs/helios4_defconfig
index 7d812e8fab..c2130bacb4 100644
--- a/configs/helios4_defconfig
+++ b/configs/helios4_defconfig
@@ -63,6 +63,7 @@ CONFIG_PHY_MARVELL=y
  CONFIG_PHY_GIGE=y
  CONFIG_MVNETA=y
  CONFIG_MII=y
+CONFIG_MVMDIO=y
  CONFIG_PCI=y
  CONFIG_PCI_MVEBU=y
  CONFIG_SCSI=y
diff --git a/configs/maxbcm_defconfig b/configs/maxbcm_defconfig
index 8dd6adf247..40f79d47ea 100644
--- a/configs/maxbcm_defconfig
+++ b/configs/maxbcm_defconfig
@@ -47,6 +47,7 @@ CONFIG_PHY_MARVELL=y
  CONFIG_PHY_GIGE=y
  CONFIG_MVNETA=y
  CONFIG_MII=y
+CONFIG_MVMDIO=y
  CONFIG_DEBUG_UART_SHIFT=2
  CONFIG_SYS_NS16550=y
  CONFIG_KIRKWOOD_SPI=y
diff --git a/configs/mvebu_espressobin-88f3720_defconfig 
b/configs/mvebu_espressobin-88f3720_defconfig
index ff05630d20..af30f1b363 100644
--- a/configs/mvebu_espressobin-88f3720_defconfig
+++ b/configs/mvebu_espressobin-88f3720_defconfig
@@ -76,6 +76,7 @@ CONFIG_PHY_MARVELL=y
  CONFIG_PHY_GIGE=y
  CONFIG_E1000=y
  CONFIG_MVNETA=y
+CONFIG_MVMDIO=y
  CONFIG_NVME_PCI=y
  CONFIG_PCI=y
  CONFIG_PCI_AARDVARK=y
diff --git a/configs/theadorable_debug_defconfig 
b/configs/theadorable_debug_defconfig
index 86129e7d2d..9a03a0a7a3 100644
--- a/configs/theadorable_debug_defconfig
+++ b/configs/theadorable_debug_defconfig
@@ -70,6 +70,7 @@ CONFIG_PHY_MARVELL=y
  CONFIG_PHY_GIGE=y
  CONFIG_MVNETA=y
  CONFIG_MII=y
+CONFIG_MVMDIO=y
  CONFIG_PCI=y
  CONFIG_DM_PCI_COMPAT=y
  CONFIG_PCI_MVEBU=y
diff --git a/configs/turris_mox_defconfig b/configs/turris_mox_defconfig
index 9a76a118c2..bcd3699a4f 100644
--- a/configs/turris_mox_defconfig
+++ b/configs/turris_mox_defconfig
@@ -82,6 +82,7 @@ CONFIG_SPI_FLASH_MTD=y
  CONFIG_PHY_MARVELL=y
  CONFIG_PHY_GIGE=y
  CONFIG_MVNETA=y
+CONFI

Re: [PATCH 07/15] imx: imx8m[m/p]_phycore: Enable DM_SERIAL

2022-05-01 Thread Teresa Remmet
Hello Peng,

Am Samstag, dem 30.04.2022 um 20:43 +0800 schrieb Peng Fan (OSS):
> From: Peng Fan 
> 
> Enable CONFIG_DM_SERIAL. uart and its pinmux was already
> marked with u-boot,dm-spl.
> Move preloader_console_init after spl_early_init to make sure driver
> model work.

thank you for the patch.
Works for phyCORE-i.MX8MM and phyCORE-i.MX8MP.

Tested-by: Teresa Remmet 

Regards,
Teresa



> 
> Signed-off-by: Peng Fan 
> ---
>  board/phytec/phycore_imx8mm/spl.c | 12 ++--
>  board/phytec/phycore_imx8mp/spl.c |  8 
>  configs/phycore-imx8mm_defconfig  |  1 +
>  configs/phycore-imx8mp_defconfig  |  1 +
>  include/configs/phycore_imx8mm.h  |  3 ---
>  include/configs/phycore_imx8mp.h  |  3 ---
>  6 files changed, 4 insertions(+), 24 deletions(-)
> 
> diff --git a/board/phytec/phycore_imx8mm/spl.c
> b/board/phytec/phycore_imx8mm/spl.c
> index d54145ef995..7f24a3affc8 100644
> --- a/board/phytec/phycore_imx8mm/spl.c
> +++ b/board/phytec/phycore_imx8mm/spl.c
> @@ -57,14 +57,8 @@ int board_fit_config_name_match(const char *name)
>   return 0;
>  }
>  
> -#define UART_PAD_CTRL(PAD_CTL_DSE6 | PAD_CTL_FSEL1)
>  #define WDOG_PAD_CTRL(PAD_CTL_DSE6 | PAD_CTL_ODE)
>  
> -static iomux_v3_cfg_t const uart_pads[] = {
> - IMX8MM_PAD_UART3_RXD_UART3_RX | MUX_PAD_CTRL(UART_PAD_CTRL),
> - IMX8MM_PAD_UART3_TXD_UART3_TX | MUX_PAD_CTRL(UART_PAD_CTRL),
> -};
> -
>  static iomux_v3_cfg_t const wdog_pads[] = {
>   IMX8MM_PAD_GPIO1_IO02_WDOG1_WDOG_B  |
> MUX_PAD_CTRL(WDOG_PAD_CTRL),
>  };
> @@ -77,8 +71,6 @@ int board_early_init_f(void)
>  
>   set_wdog_reset(wdog);
>  
> - imx_iomux_v3_setup_multiple_pads(uart_pads,
> ARRAY_SIZE(uart_pads));
> -
>   return 0;
>  }
>  
> @@ -92,8 +84,6 @@ void board_init_f(ulong dummy)
>  
>   board_early_init_f();
>  
> - preloader_console_init();
> -
>   /* Clear the BSS. */
>   memset(__bss_start, 0, __bss_end - __bss_start);
>  
> @@ -103,6 +93,8 @@ void board_init_f(ulong dummy)
>   hang();
>   }
>  
> + preloader_console_init();
> +
>   enable_tzc380();
>  
>   /* DDR initialization */
> diff --git a/board/phytec/phycore_imx8mp/spl.c
> b/board/phytec/phycore_imx8mp/spl.c
> index 19c486e5517..38a581bef57 100644
> --- a/board/phytec/phycore_imx8mp/spl.c
> +++ b/board/phytec/phycore_imx8mp/spl.c
> @@ -89,14 +89,8 @@ int board_fit_config_name_match(const char *name)
>   return 0;
>  }
>  
> -#define UART_PAD_CTRL   (PAD_CTL_DSE6 | PAD_CTL_FSEL1)
>  #define WDOG_PAD_CTRL   (PAD_CTL_DSE6 | PAD_CTL_ODE | PAD_CTL_PUE |
> PAD_CTL_PE)
>  
> -static iomux_v3_cfg_t const uart_pads[] = {
> - MX8MP_PAD_UART1_RXD__UART1_DCE_RX |
> MUX_PAD_CTRL(UART_PAD_CTRL),
> - MX8MP_PAD_UART1_TXD__UART1_DCE_TX |
> MUX_PAD_CTRL(UART_PAD_CTRL),
> -};
> -
>  static iomux_v3_cfg_t const wdog_pads[] = {
>   MX8MP_PAD_GPIO1_IO02__WDOG1_WDOG_B  |
> MUX_PAD_CTRL(WDOG_PAD_CTRL),
>  };
> @@ -109,8 +103,6 @@ int board_early_init_f(void)
>  
>   set_wdog_reset(wdog);
>  
> - imx_iomux_v3_setup_multiple_pads(uart_pads,
> ARRAY_SIZE(uart_pads));
> -
>   return 0;
>  }
>  
> diff --git a/configs/phycore-imx8mm_defconfig b/configs/phycore-
> imx8mm_defconfig
> index ba5833f7060..9da222afc54 100644
> --- a/configs/phycore-imx8mm_defconfig
> +++ b/configs/phycore-imx8mm_defconfig
> @@ -107,6 +107,7 @@ CONFIG_PINCTRL_IMX8M=y
>  CONFIG_DM_REGULATOR=y
>  CONFIG_DM_REGULATOR_FIXED=y
>  CONFIG_DM_REGULATOR_GPIO=y
> +CONFIG_DM_SERIAL=y
>  CONFIG_MXC_UART=y
>  CONFIG_SPI=y
>  CONFIG_DM_SPI=y
> diff --git a/configs/phycore-imx8mp_defconfig b/configs/phycore-
> imx8mp_defconfig
> index 86d0f4df7f6..a851b1bdccb 100644
> --- a/configs/phycore-imx8mp_defconfig
> +++ b/configs/phycore-imx8mp_defconfig
> @@ -98,6 +98,7 @@ CONFIG_DM_REGULATOR=y
>  CONFIG_DM_REGULATOR_FIXED=y
>  CONFIG_DM_REGULATOR_GPIO=y
>  CONFIG_SPL_POWER_I2C=y
> +CONFIG_DM_SERIAL=y
>  CONFIG_MXC_UART=y
>  CONFIG_SYSRESET=y
>  CONFIG_SPL_SYSRESET=y
> diff --git a/include/configs/phycore_imx8mm.h
> b/include/configs/phycore_imx8mm.h
> index 71f0c42ec0c..564b8125ba3 100644
> --- a/include/configs/phycore_imx8mm.h
> +++ b/include/configs/phycore_imx8mm.h
> @@ -83,9 +83,6 @@
>  #define PHYS_SDRAM   0x4000
>  #define PHYS_SDRAM_SIZE SZ_2G /* 2GB DDR */
>  
> -/* UART */
> -#define CONFIG_MXC_UART_BASE UART3_BASE_ADDR
> -
>  /* Monitor Command Prompt */
>  #define CONFIG_SYS_CBSIZESZ_2K
>  #define CONFIG_SYS_MAXARGS   64
> diff --git a/include/configs/phycore_imx8mp.h
> b/include/configs/phycore_imx8mp.h
> index 0c963b62b3b..3e4315f2b81 100644
> --- a/include/configs/phycore_imx8mp.h
> +++ b/include/configs/phycore_imx8mp.h
> @@ -83,9 +83,6 @@
>  #define PHYS_SDRAM   0x4000
>  #define PHYS_SDRAM_SIZE  0x8000
>  
> -/* UART */
> -#define CONFIG_MXC_UART_BASE UART1_BASE_ADDR
> -
>  /* Monitor Command Prompt */
>  #define CONFIG_SYS_CBSIZESZ

Re: [PATCH u-boot-marvell 02/19] net: mvneta: Fix 10Mbps speed

2022-05-01 Thread Stefan Roese

On 27.04.22 12:41, Marek Behún wrote:

From: Marek Behún 

In mvneta_adjust_link() we need to set MII_SPEED bit only if PHY reports
the speed at 100Mbps.

Signed-off-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan



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

diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
index d1c5f7930d..79cdb93341 100644
--- a/drivers/net/mvneta.c
+++ b/drivers/net/mvneta.c
@@ -1195,7 +1195,7 @@ static void mvneta_adjust_link(struct udevice *dev)
  
  			if (phydev->speed == SPEED_1000)

val |= MVNETA_GMAC_CONFIG_GMII_SPEED;
-   else
+   else if (pp->speed == SPEED_100)
val |= MVNETA_GMAC_CONFIG_MII_SPEED;
  
  			mvreg_write(pp, MVNETA_GMAC_AUTONEG_CONFIG, val);


Viele Grüße,
Stefan Roese

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


Re: [PATCH u-boot-marvell 01/19] net: mvneta: Get rid of platdata

2022-05-01 Thread Stefan Roese

On 27.04.22 12:41, Marek Behún wrote:

From: Marek Behún 

Drop .of_to_plat() from the mvneta driver and parse the two properties
in .probe().

Signed-off-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  drivers/net/mvneta.c | 24 
  1 file changed, 4 insertions(+), 20 deletions(-)

diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
index 15dc714058..d1c5f7930d 100644
--- a/drivers/net/mvneta.c
+++ b/drivers/net/mvneta.c
@@ -1692,7 +1692,6 @@ static int mvneta_recv(struct udevice *dev, int flags, 
uchar **packetp)
  
  static int mvneta_probe(struct udevice *dev)

  {
-   struct eth_pdata *pdata = dev_get_plat(dev);
struct mvneta_port *pp = dev_get_priv(dev);
  #if CONFIG_IS_ENABLED(DM_GPIO)
struct ofnode_phandle_args sfp_args;
@@ -1729,7 +1728,10 @@ static int mvneta_probe(struct udevice *dev)
buffer_loc.rx_buffers = (phys_addr_t)(bd_space + size);
}
  
-	pp->base = (void __iomem *)pdata->iobase;

+   pp->base = dev_read_addr_ptr(dev);
+   pp->phy_interface = dev_read_phy_mode(dev);
+   if (pp->phy_interface == PHY_INTERFACE_MODE_NA)
+   return -EINVAL;
  
  	/* Configure MBUS address windows */

if (device_is_compatible(dev, "marvell,armada-3700-neta"))
@@ -1737,9 +1739,6 @@ static int mvneta_probe(struct udevice *dev)
else
mvneta_conf_mbus_windows(pp);
  
-	/* PHY interface is already decoded in mvneta_of_to_plat() */

-   pp->phy_interface = pdata->phy_interface;
-
/* fetch 'fixed-link' property from 'neta' node */
fl_node = fdt_subnode_offset(blob, node, "fixed-link");
if (fl_node != -FDT_ERR_NOTFOUND) {
@@ -1808,20 +1807,6 @@ static const struct eth_ops mvneta_ops = {
.write_hwaddr   = mvneta_write_hwaddr,
  };
  
-static int mvneta_of_to_plat(struct udevice *dev)

-{
-   struct eth_pdata *pdata = dev_get_plat(dev);
-
-   pdata->iobase = dev_read_addr(dev);
-
-   /* Get phy-mode / phy_interface from DT */
-   pdata->phy_interface = dev_read_phy_mode(dev);
-   if (pdata->phy_interface == PHY_INTERFACE_MODE_NA)
-   return -EINVAL;
-
-   return 0;
-}
-
  static const struct udevice_id mvneta_ids[] = {
{ .compatible = "marvell,armada-370-neta" },
{ .compatible = "marvell,armada-xp-neta" },
@@ -1833,7 +1818,6 @@ U_BOOT_DRIVER(mvneta) = {
.name   = "mvneta",
.id = UCLASS_ETH,
.of_match = mvneta_ids,
-   .of_to_plat = mvneta_of_to_plat,
.probe  = mvneta_probe,
.ops= &mvneta_ops,
.priv_auto  = sizeof(struct mvneta_port),


Viele Grüße,
Stefan Roese

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


RE: [PATCH] i.MX6SX: crypto/fsl: fix entropy delay value

2022-05-01 Thread Gaurav Jain
Hello Stefano

This patch is already merged in kernel 
https://patchwork.kernel.org/project/linux-crypto/patch/20220420120601.1015362-1-feste...@gmail.com/
Can you help to check and merge this in Uboot as well.

Regards
Gaurav Jain

> -Original Message-
> From: Gaurav Jain
> Sent: Friday, April 15, 2022 4:41 PM
> To: Stefano Babic ; u-boot@lists.denx.de
> Cc: Fabio Estevam ; Peng Fan ;
> Priyanka Jain ; Ye Li ; Horia Geanta
> ; Silvano Di Ninno ; Varun
> Sethi ; dl-uboot-imx ; Gaurav Jain
> 
> Subject: [PATCH] i.MX6SX: crypto/fsl: fix entropy delay value
> 
> RNG Hardware error is reported due to incorrect entropy delay
> 
> rng self test are run to determine the correct ent_dly.
> test is executed with different voltage and temperature to identify the worst
> case value for ent_dly. after adding a margin value(1000), ent_dly should be 
> at
> least 12000.
> 
> Signed-off-by: Gaurav Jain 
> ---
>  drivers/crypto/fsl/jr.c | 11 ++-
>  include/fsl_sec.h   |  6 +-
>  2 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c index
> 1d951cf0a6..85a3dac796 100644
> --- a/drivers/crypto/fsl/jr.c
> +++ b/drivers/crypto/fsl/jr.c
> @@ -623,7 +623,7 @@ static void kick_trng(int ent_delay, ccsr_sec_t *sec)
> 
>  static int rng_init(uint8_t sec_idx, ccsr_sec_t *sec)  {
> - int ret, gen_sk, ent_delay = RTSDCTL_ENT_DLY_MIN;
> + int ret, gen_sk, ent_delay = RTSDCTL_ENT_DLY;
>   struct rng4tst __iomem *rng =
>   (struct rng4tst __iomem *)&sec->rng;
>   u32 inst_handles;
> @@ -652,6 +652,15 @@ static int rng_init(uint8_t sec_idx, ccsr_sec_t *sec)
>* the RNG.
>*/
>   ret = instantiate_rng(sec_idx, sec, gen_sk);
> + /*
> +  * entropy delay is calculated via self-test method.
> +  * self-test are run across different volatge, temp.
> +  * if worst case value for ent_dly is identified,
> +  * loop can be skipped for that platform.
> +  */
> + if (IS_ENABLED(CONFIG_MX6SX))
> + break;
> +
>   } while ((ret == -1) && (ent_delay < RTSDCTL_ENT_DLY_MAX));
>   if (ret) {
>   printf("SEC%u:  Failed to instantiate RNG\n", sec_idx); diff 
> --git
> a/include/fsl_sec.h b/include/fsl_sec.h index 7b6e3e2c20..d57c4ca820 100644
> --- a/include/fsl_sec.h
> +++ b/include/fsl_sec.h
> @@ -48,7 +48,11 @@ struct rng4tst {
>   u32 rtmctl; /* misc. control register */
>   u32 rtscmisc;   /* statistical check misc. register */
>   u32 rtpkrrng;   /* poker range register */
> -#define RTSDCTL_ENT_DLY_MIN  3200
> +#ifdef CONFIG_MX6SX
> +#define RTSDCTL_ENT_DLY  12000
> +#else
> +#define RTSDCTL_ENT_DLY  3200
> +#endif
>  #define RTSDCTL_ENT_DLY_MAX  12800
>   union {
>   u32 rtpkrmax;   /* PRGM=1: poker max. limit register */
> --
> 2.25.1



Re: [PATCH 2/5] arm: mvebu: turris_omnia: Define CONFIG_ETHPRIME instead of ethact= ENV

2022-05-01 Thread Stefan Roese

On 06.04.22 11:39, Pali Rohár wrote:

CONFIG_ETHPRIME defines primary ethernet device and env variable $ethact
stores currently active ethernet device.

So there is no point to set ethact= in default environment. Instead set
CONFIG_ETHPRIME properly.

Signed-off-by: Pali Rohár 
---
  include/configs/turris_omnia.h | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/configs/turris_omnia.h b/include/configs/turris_omnia.h
index b35299b2fbb3..15f874ea22e1 100644
--- a/include/configs/turris_omnia.h
+++ b/include/configs/turris_omnia.h
@@ -26,6 +26,8 @@
"fdt_high=0x1000\0"   \
"initrd_high=0x1000\0"
  
+#define CONFIG_ETHPRIME		"ethernet@34000"

+


This was moved to Kconfig in the meantime. I'll make the necessary
myself, no need to resend.

Thanks,
Stefan


  /* Defines for SPL */
  #define CONFIG_SPL_SIZE   (140 << 10)
  #define CONFIG_SPL_MAX_SIZE   (CONFIG_SPL_SIZE - 
(CONFIG_SPL_TEXT_BASE - 0x4000))
@@ -119,7 +121,6 @@
LOAD_ADDRESS_ENV_SETTINGS \
"fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
"console=ttyS0,115200\0" \
-   "ethact=ethernet@34000\0" \
"bootcmd_rescue=" TURRIS_OMNIA_BOOTCMD_RESCUE "\0" \
BOOTENV
  


Viele Grüße,
Stefan Roese

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


Re: [PATCH u-boot-marvell 00/19] some mvneta changes, cleanups, fixes

2022-05-01 Thread Stefan Roese

Hi Ramon,

On 27.04.22 12:41, Marek Behún wrote:

From: Marek Behún 

Hello Stefan,

here come some refactors, cleanups and fixed for the mvneta driver.


Ramon, you've already reviewed those patches. Thanks for this. The
patches are assigned to me in patchwork, which makes perhaps sense,
as some touch the ARM related files. Are you okay with me pulling
these patches via the marvell tree?

Thanks,
Stefan


Marek Behún (19):
   net: mvneta: Get rid of platdata
   net: mvneta: Fix 10Mbps speed
   net: mvneta: Use DM MDIO API for connecting PHY
   net: mvneta: Remember fixed link instead of PHY address in priv data
   arm: mvebu: Espressobin: Use DM registered MDIO to configure switch
   net: mdio-uclass: add dm_phy_find_by_ofnode() helper
   arm: mvebu: turris_mox: Use DM registered MDIO
   net: mvneta: Don't register MDIO bus
   net: mvneta: Fix unused variable warning if DM_GPIO is disabled
   net: mvneta: Drop one indentation level in mvneta_adjust_link()
   net: mvneta: Use bool instead of int for boolean variable
   net: mvneta: Drop unnecessary space
   net: mventa: Don't check for CONFIG_PHYLIB
   net: mvneta: Rename CONFIG_NR_CPUS to MVNETA_NR_CPUS
   net: mvneta: Convert to use PHY_FIXED for fixed-link
   net: mvneta: Write PHY address just before enabling HW polling
   net: mvneta: Drop fixed_link member from private struct
   net: mvneta: Disable fixed PHY code if PHY_FIXED is not compiled in
   net: mvneta: Drop unneeded macro

  .../dts/armada-3720-turris-mox-u-boot.dtsi|  19 -
  board/CZ.NIC/turris_mox/turris_mox.c  |  88 ++---
  board/Marvell/mvebu_armada-37xx/board.c   |  26 +-
  configs/clearfog_defconfig|   1 +
  configs/controlcenterdc_defconfig |   1 +
  configs/db-88f6820-amc_defconfig  |   1 +
  configs/db-88f6820-gp_defconfig   |   1 +
  configs/db-mv784mp-gp_defconfig   |   1 +
  configs/ds414_defconfig   |   1 +
  configs/helios4_defconfig |   1 +
  configs/maxbcm_defconfig  |   1 +
  configs/mvebu_espressobin-88f3720_defconfig   |   3 +
  configs/theadorable_debug_defconfig   |   1 +
  configs/turris_mox_defconfig  |   1 +
  configs/turris_omnia_defconfig|   2 +
  configs/uDPU_defconfig|   1 +
  drivers/net/Kconfig   |   1 +
  drivers/net/mvneta.c  | 343 --
  include/miiphy.h  |   9 +
  net/mdio-uclass.c |  22 ++
  20 files changed, 181 insertions(+), 343 deletions(-)



Viele Grüße,
Stefan Roese

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


Re: [PATCH] arm: mvebu: turris_omnia: Fix SYS_RSTOUT_* macro names

2022-05-01 Thread Stefan Roese

On 29.04.22 13:53, Pali Rohár wrote:

This is A385 register.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  board/CZ.NIC/turris_omnia/turris_omnia.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 97292456f148..6132c8f94369 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -43,8 +43,8 @@ DECLARE_GLOBAL_DATA_PTR;
  #define OMNIA_I2C_EEPROM_CHIP_LEN 2
  #define OMNIA_I2C_EEPROM_MAGIC0x0341a034
  
-#define SYS_RSTOUT_MASK			MVEBU_REGISTER(0x18260)

-#define   SYS_RSTOUT_MASK_WD   BIT(10)
+#define A385_SYS_RSTOUT_MASK   MVEBU_REGISTER(0x18260)
+#define   A385_SYS_RSTOUT_MASK_WD  BIT(10)
  
  #define A385_WDT_GLOBAL_CTRL		MVEBU_REGISTER(0x20300)

  #define   A385_WDT_GLOBAL_RATIO_MASK  GENMASK(18, 16)
@@ -187,7 +187,7 @@ static void enable_a385_watchdog(unsigned int 
timeout_minutes)
setbits_32(A385_WD_RSTOUT_UNMASK, A385_WD_RSTOUT_UNMASK_GLOBAL);
  
  	/* Unmask reset for watchdog */

-   clrbits_32(SYS_RSTOUT_MASK, SYS_RSTOUT_MASK_WD);
+   clrbits_32(A385_SYS_RSTOUT_MASK, A385_SYS_RSTOUT_MASK_WD);
  }
  
  static bool disable_mcu_watchdog(void)


Viele Grüße,
Stefan Roese

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


Re: [PATCH] arm: mvebu: clearfog_defconfig: enable setexpr command

2022-05-01 Thread Stefan Roese

On 29.04.22 17:49, Josef Schlehofer wrote:

This command is useful in U-boot scripts and it is being used by
OpenWrt bootscript for this board [1]. Otherwise shell scripting
commands are enabled by default in cmd/Kconfig.

[1] 
https://github.com/openwrt/openwrt/blob/852126680e21edc71c0c66561ae5a6d7479dcc67/target/linux/mvebu/image/clearfog.bootscript#L7

[2] 
https://source.denx.de/u-boot/u-boot/-/blob/e95afa56753cebcd20a5114b6d121f281b789006/cmd/Kconfig#L1504

Fixes: 0299c90f396c5b2971a4bac596339f4b03661c27 ("arm: mvebu: Add
SolidRun ClearFog Armada 38x initial support")

Signed-off-by: Josef Schlehofer 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  configs/clearfog_defconfig | 1 -
  1 file changed, 1 deletion(-)

diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
index 880f16a6e0..1e9c389deb 100644
--- a/configs/clearfog_defconfig
+++ b/configs/clearfog_defconfig
@@ -34,7 +34,6 @@ CONFIG_CMD_MMC=y
  CONFIG_CMD_PCI=y
  CONFIG_CMD_SPI=y
  CONFIG_CMD_USB=y
-# CONFIG_CMD_SETEXPR is not set
  CONFIG_CMD_TFTPPUT=y
  CONFIG_CMD_CACHE=y
  CONFIG_CMD_TIME=y


Viele Grüße,
Stefan Roese

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


Re: [PATCH] ARM: mvebu: x530: set MPP55 to gpio

2022-05-01 Thread Stefan Roese

On 02.05.22 05:16, Chris Packham wrote:

MPP55 is used as a reset connected to the L3 switch chip. This doesn't
matter for u-boot as it doesn't use the L3 switch but it is useful to
be able to toggle the switch in/out of reset for the OS.

Signed-off-by: Chris Packham 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
I sent this out a while back but it was part of a series that has been dropped
for the time being. There's not reason to hold this change up behind the other
so I'm sending it as a standalong change.


Good.



  board/alliedtelesis/x530/x530.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/alliedtelesis/x530/x530.c b/board/alliedtelesis/x530/x530.c
index c0ec2afa3011..cbf4533e78de 100644
--- a/board/alliedtelesis/x530/x530.c
+++ b/board/alliedtelesis/x530/x530.c
@@ -93,7 +93,7 @@ int board_early_init_f(void)
writel(0x0550, MVEBU_MPP_BASE + 0x0c);
writel(0x, MVEBU_MPP_BASE + 0x10);
writel(0x00100565, MVEBU_MPP_BASE + 0x14);
-   writel(0x4000, MVEBU_MPP_BASE + 0x18);
+   writel(0x, MVEBU_MPP_BASE + 0x18);
writel(0x, MVEBU_MPP_BASE + 0x1c);
  
  	return 0;


Viele Grüße,
Stefan Roese

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


[PATCH 1/1] lib: fix selection of CONFIG_CHARSET

2022-05-01 Thread Heinrich Schuchardt
lib/charset.c is not optional for
EFI_APP || EFI_LOADER || UFS || UT_UNICODE.
These must select CONFIG_CHARSET.

Fixes: 726cd9836db0 ("efi: Make unicode printf available to the app")
Signed-off-by: Heinrich Schuchardt 
---
 drivers/ufs/Kconfig| 1 +
 lib/Kconfig| 5 -
 lib/efi/Kconfig| 1 +
 lib/efi_loader/Kconfig | 1 +
 test/Kconfig   | 1 +
 5 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/ufs/Kconfig b/drivers/ufs/Kconfig
index c2aafd3020..69ea18edf8 100644
--- a/drivers/ufs/Kconfig
+++ b/drivers/ufs/Kconfig
@@ -3,6 +3,7 @@ menu "UFS Host Controller Support"
 config UFS
bool "Support UFS controllers"
depends on DM_SCSI
+   select CHARSET
help
  This selects support for Universal Flash Subsystem (UFS).
  Say Y here if you want UFS Support.
diff --git a/lib/Kconfig b/lib/Kconfig
index 858be14f09..25d15058e9 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -52,11 +52,6 @@ config CC_OPTIMIZE_LIBS_FOR_SPEED
 
 config CHARSET
bool
-   default y if UT_UNICODE || EFI_LOADER || UFS || EFI_APP
-   help
- Enables support for various conversions between different
- character sets, such as between unicode representations and
- different 'code pages'.
 
 config DYNAMIC_CRC_TABLE
bool "Enable Dynamic tables for CRC"
diff --git a/lib/efi/Kconfig b/lib/efi/Kconfig
index 15ce99e1a7..c2b9bb73f7 100644
--- a/lib/efi/Kconfig
+++ b/lib/efi/Kconfig
@@ -14,6 +14,7 @@ choice
 
 config EFI_APP
bool "Support running as an EFI application"
+   select CHARSET
help
  Build U-Boot as an application which can be started from EFI. This
  is useful for examining a platform in the early stages of porting
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 6b245f50a7..eb2d6fddc4 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -14,6 +14,7 @@ config EFI_LOADER
depends on DM_ETH || !NET
depends on !EFI_APP
default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8
+   select CHARSET
select DM_EVENT
select EVENT_DYNAMIC
select LIB_UUID
diff --git a/test/Kconfig b/test/Kconfig
index e15ba239eb..7f3447ae5a 100644
--- a/test/Kconfig
+++ b/test/Kconfig
@@ -91,6 +91,7 @@ config UT_UNICODE
bool "Unit tests for Unicode functions"
depends on UNIT_TEST
default y
+   select CHARSET
help
  Enables the 'ut unicode' command which tests that the functions for
  manipulating Unicode strings work correctly.
-- 
2.34.1



Re: [PATCH 1/2] misc: i2c_eeprom: add support for microchip 24aa025e48

2022-05-01 Thread Heiko Schocher
Hello Eugen,

On 29.04.22 16:22, Eugen Hristev wrote:
> 24aa025e48 is a variant of 24aa02e48 that has a page size of 16 bytes.
> 
> Signed-off-by: Eugen Hristev 
> ---
>  drivers/misc/i2c_eeprom.c | 8 
>  1 file changed, 8 insertions(+)

Reviewed-by: Heiko Schocher 

bye,
Heiko

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


[PATCH] ARM: mvebu: x530: set MPP55 to gpio

2022-05-01 Thread Chris Packham
MPP55 is used as a reset connected to the L3 switch chip. This doesn't
matter for u-boot as it doesn't use the L3 switch but it is useful to
be able to toggle the switch in/out of reset for the OS.

Signed-off-by: Chris Packham 
---
I sent this out a while back but it was part of a series that has been dropped
for the time being. There's not reason to hold this change up behind the other
so I'm sending it as a standalong change.

 board/alliedtelesis/x530/x530.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/alliedtelesis/x530/x530.c b/board/alliedtelesis/x530/x530.c
index c0ec2afa3011..cbf4533e78de 100644
--- a/board/alliedtelesis/x530/x530.c
+++ b/board/alliedtelesis/x530/x530.c
@@ -93,7 +93,7 @@ int board_early_init_f(void)
writel(0x0550, MVEBU_MPP_BASE + 0x0c);
writel(0x, MVEBU_MPP_BASE + 0x10);
writel(0x00100565, MVEBU_MPP_BASE + 0x14);
-   writel(0x4000, MVEBU_MPP_BASE + 0x18);
+   writel(0x, MVEBU_MPP_BASE + 0x18);
writel(0x, MVEBU_MPP_BASE + 0x1c);
 
return 0;
-- 
2.36.0



Re: [PATCH v5 10/17] bootmenu: add distro boot entry

2022-05-01 Thread Heinrich Schuchardt

On 4/28/22 10:09, Masahisa Kojima wrote:

This commit adds the distro_boot entries into the bootmenu.
The bootmenu read the "boot_targets" U-Boot environment variable
and enumerate it.
User can select the distro boot entry, then bootmenu executes
"run bootcmd_xxx" command.

The bootmenu also checks the existing block devices and network
option("dhcp" and "pxe") availability, then filter out
the "boot_targets" appeared in bootmenu.

The bootmenu example is as follows, distro boot entry has the
"distro_boot" prefix.

   *** U-Boot Boot Menu ***

  distro_boot   : usb0
  distro_boot   : scsi0
  distro_boot   : virtio0
  distro_boot   : dhcp


You will be creating UEFI boot options for all block devices anyway.
We should avoid duplicate entries. Please, drop this patch.

Best regards

heinrich



Signed-off-by: Masahisa Kojima 
---
Changes in v5:
- split into the separate patch
- add function description comment
- handle the case boot_targets variable is empty
- filter out the non-exist device entry

  cmd/bootmenu.c | 177 +
  1 file changed, 177 insertions(+)

diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
index da688e6213..afe42b8041 100644
--- a/cmd/bootmenu.c
+++ b/cmd/bootmenu.c
@@ -7,6 +7,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -14,6 +15,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 

@@ -31,6 +33,7 @@ enum boot_type {
BOOTMENU_TYPE_NONE = 0,
BOOTMENU_TYPE_BOOTMENU,
BOOTMENU_TYPE_UEFI_BOOT_OPTION,
+   BOOTMENU_TYPE_DISTRO_BOOT,
  };

  struct bootmenu_entry {
@@ -90,6 +93,8 @@ static void bootmenu_print_entry(void *data)
printf("bootmenu_%02d   : %ls", entry->bootorder, entry->title);
else if (entry->type == BOOTMENU_TYPE_UEFI_BOOT_OPTION)
printf("UEFI BOOT%04X : %ls", entry->bootorder, entry->title);
+   else if (entry->type == BOOTMENU_TYPE_DISTRO_BOOT)
+   printf("distro_boot   : %ls", entry->title);
else
printf("%ls", entry->title);

@@ -465,6 +470,172 @@ static int prepare_uefi_bootorder_entry(struct 
bootmenu_data *menu,
return 1;
  }

+static int is_blk_device_available(char *token)
+{
+   struct driver *d = ll_entry_start(struct driver, driver);
+   const int n_ents = ll_entry_count(struct driver, driver);
+   struct driver *entry;
+   struct udevice *udev;
+   struct uclass *uc;
+   struct blk_desc *desc;
+   int ret, i;
+   const char *if_type_name;
+
+   ret = uclass_get(UCLASS_BLK, &uc);
+   if (ret)
+   return -ENODEV;
+
+   for (entry = d; entry < d + n_ents; entry++) {
+   if (entry->id != UCLASS_BLK)
+   continue;
+   i = 0;
+   uclass_foreach_dev(udev, uc) {
+   if (udev->driver != entry)
+   continue;
+   desc = dev_get_uclass_plat(udev);
+   if_type_name = blk_get_if_type_name(desc->if_type);
+   if (strncmp(token, if_type_name, strlen(if_type_name)) 
== 0) {
+   char *p;
+   int j, len;
+   int devnum = 0;
+
+   p = token + strlen(if_type_name);
+   len = strlen(p);
+   if (!len)
+   continue; /* no device number */
+
+   for (j = 0; j < len; j++) {
+   if (!isdigit(*p)) {
+   /* invalid device number */
+   devnum = INT_MAX;
+   break;
+   }
+   devnum = (devnum * 10) + (*p++ - '0');
+   }
+
+   if (devnum == INT_MAX)
+   continue;
+
+   if (devnum == desc->devnum)
+   return 1;
+   }
+   }
+   }
+
+   if (strncmp(token, "dhcp", strlen("dhcp")) == 0) {
+   if (IS_ENABLED(CONFIG_CMD_DHCP))
+   return 1;
+   }
+
+   if (strncmp(token, "pxe", strlen("pxe")) == 0) {
+   if (IS_ENABLED(CONFIG_CMD_PXE))
+   return 1;
+   }
+
+   return -ENODEV;
+}
+
+/**
+ * prepare_distro_boot_entry() - generate the distro boot entries
+ *
+ * This function read the "boot_targets" U-Boot environment variable
+ * and generate the bootmenu entries.
+ *
+ * @menu:  pointer to the bootmenu structure
+ * @current:   pointer to the last bootmenu entry list
+ * @index: pointer to the index of the last

Re: [PATCH v5 09/17] bootmenu: add UEFI boot entry into bootmenu

2022-05-01 Thread Heinrich Schuchardt

On 4/28/22 10:09, Masahisa Kojima wrote:

This commit adds the UEFI related menu entries
into the bootmenu.

User can select which UEFI "Boot" option to execute
from bootmenu, then bootmenu sets the "BootNext" UEFI
variable and invoke efi bootmgr. The efi bootmgr
will handle the "BootNext" UEFI variable.

If the "BootNext" UEFI variable is preset and efi bootmgr is enabled,
bootmenu invokes efi bootmgr to handle "BootNext" as first priority.

The UEFI boot entry has the "UEFI BOOT" prefix as below.


This prefix provides no value.



   *** U-Boot Boot Menu ***

  UEFI BOOT : debian
  UEFI BOOT0001 : ubuntu

Signed-off-by: Masahisa Kojima 
---
Changes in v5:
- split into the separate patch
- add function description comment
- remove non-volatile attribute for BootNext variable to minimize
   the access to the non-volatile storage

  cmd/bootmenu.c | 155 -
  1 file changed, 154 insertions(+), 1 deletion(-)

diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
index 15ad621c9f..da688e6213 100644
--- a/cmd/bootmenu.c
+++ b/cmd/bootmenu.c
@@ -7,6 +7,8 @@
  #include 
  #include 
  #include 
+#include 
+#include 
  #include 
  #include 
  #include 
@@ -28,6 +30,7 @@
  enum boot_type {
BOOTMENU_TYPE_NONE = 0,
BOOTMENU_TYPE_BOOTMENU,
+   BOOTMENU_TYPE_UEFI_BOOT_OPTION,
  };

  struct bootmenu_entry {
@@ -85,6 +88,8 @@ static void bootmenu_print_entry(void *data)

if (entry->type == BOOTMENU_TYPE_BOOTMENU)
printf("bootmenu_%02d   : %ls", entry->bootorder, entry->title);
+   else if (entry->type == BOOTMENU_TYPE_UEFI_BOOT_OPTION)
+   printf("UEFI BOOT%04X : %ls", entry->bootorder, entry->title);


Please, remove this hunk.

Best regards

Heinrich


else
printf("%ls", entry->title);

@@ -371,6 +376,95 @@ static int prepare_bootmenu_entry(struct bootmenu_data 
*menu,
return 1;
  }

+/**
+ * prepare_uefi_bootorder_entry() - generate the uefi bootmenu entries
+ *
+ * This function read the "BootOrder" UEFI variable
+ * and generate the bootmenu entries in the order of "BootOrder".
+ *
+ * @menu:  pointer to the bootmenu structure
+ * @current:   pointer to the last bootmenu entry list
+ * @index: pointer to the index of the last bootmenu entry,
+ * the number of uefi entry is added by this function
+ * Return: 1 on success, negative value on error
+ */
+static int prepare_uefi_bootorder_entry(struct bootmenu_data *menu,
+   struct bootmenu_entry **current,
+   unsigned short int *index)
+{
+   u16 *bootorder;
+   efi_status_t ret;
+   unsigned short j;
+   efi_uintn_t num, size;
+   void *load_option;
+   struct efi_load_option lo;
+   u16 varname[] = u"Boot";
+   unsigned short int i = *index;
+   struct bootmenu_entry *entry = NULL;
+   struct bootmenu_entry *iter = *current;
+
+   bootorder = efi_get_var(u"BootOrder", &efi_global_variable_guid, &size);
+   if (!bootorder)
+   return -ENOENT;
+
+   num = size / sizeof(u16);
+   for (j = 0; j < num; j++) {
+   entry = malloc(sizeof(struct bootmenu_entry));
+   if (!entry)
+   return -ENOMEM;
+
+   efi_create_indexed_name(varname, sizeof(varname),
+   "Boot", bootorder[j]);
+   load_option = efi_get_var(varname, &efi_global_variable_guid, 
&size);
+   if (!load_option)
+   continue;
+
+   ret = efi_deserialize_load_option(&lo, load_option, &size);
+   if (ret != EFI_SUCCESS) {
+   log_warning("Invalid load option for %ls\n", varname);
+   free(load_option);
+   free(entry);
+   continue;
+   }
+
+   if (lo.attributes & LOAD_OPTION_ACTIVE) {
+   entry->title = u16_strdup(lo.label);
+   if (!entry->title) {
+   free(load_option);
+   free(entry);
+   free(bootorder);
+   return -ENOMEM;
+   }
+   entry->command = strdup("bootefi bootmgr");
+   sprintf(entry->key, "%d", i);
+   entry->num = i;
+   entry->menu = menu;
+   entry->type = BOOTMENU_TYPE_UEFI_BOOT_OPTION;
+   entry->bootorder = bootorder[j];
+   entry->next = NULL;
+
+   if (!iter)
+   menu->first = entry;
+   else
+   iter->next = entry;
+
+   iter = entry;
+   i++;
+   }
+
+   

[PATCH 1/1] cmd: simplify bootmenu

2022-05-01 Thread Heinrich Schuchardt
* correct output for timeout > 99 s
* don't use spaces to advance to the output column

Signed-off-by: Heinrich Schuchardt 
---
 cmd/bootmenu.c | 20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
index d573487272..fe35607472 100644
--- a/cmd/bootmenu.c
+++ b/cmd/bootmenu.c
@@ -68,9 +68,7 @@ static void bootmenu_print_entry(void *data)
 * Move cursor to line where the entry will be drown (entry->num)
 * First 3 lines contain bootmenu header + 1 empty line
 */
-   printf(ANSI_CURSOR_POSITION, entry->num + 4, 1);
-
-   puts(" ");
+   printf(ANSI_CURSOR_POSITION, entry->num + 4, 7);
 
if (reverse)
puts(ANSI_COLOR_REVERSE);
@@ -86,12 +84,9 @@ static void bootmenu_autoboot_loop(struct bootmenu_data 
*menu,
 {
int i, c;
 
-   if (menu->delay > 0) {
-   printf(ANSI_CURSOR_POSITION, menu->count + 5, 1);
-   printf("  Hit any key to stop autoboot: %2d ", menu->delay);
-   }
-
while (menu->delay > 0) {
+   printf(ANSI_CURSOR_POSITION, menu->count + 5, 3);
+   printf("Hit any key to stop autoboot: %d ", menu->delay);
for (i = 0; i < 100; ++i) {
if (!tstc()) {
WATCHDOG_RESET();
@@ -125,7 +120,6 @@ static void bootmenu_autoboot_loop(struct bootmenu_data 
*menu,
break;
 
--menu->delay;
-   printf("\b\b\b%2d ", menu->delay);
}
 
printf(ANSI_CURSOR_POSITION, menu->count + 5, 1);
@@ -407,8 +401,8 @@ static void menu_display_statusline(struct menu *m)
 
printf(ANSI_CURSOR_POSITION, 1, 1);
puts(ANSI_CLEAR_LINE);
-   printf(ANSI_CURSOR_POSITION, 2, 1);
-   puts("  *** U-Boot Boot Menu ***");
+   printf(ANSI_CURSOR_POSITION, 2, 3);
+   puts("*** U-Boot Boot Menu ***");
puts(ANSI_CLEAR_LINE_TO_END);
printf(ANSI_CURSOR_POSITION, 3, 1);
puts(ANSI_CLEAR_LINE);
@@ -416,8 +410,8 @@ static void menu_display_statusline(struct menu *m)
/* First 3 lines are bootmenu header + 2 empty lines between entries */
printf(ANSI_CURSOR_POSITION, menu->count + 5, 1);
puts(ANSI_CLEAR_LINE);
-   printf(ANSI_CURSOR_POSITION, menu->count + 6, 1);
-   puts("  Press UP/DOWN to move, ENTER to select, ESC/CTRL+C to quit");
+   printf(ANSI_CURSOR_POSITION, menu->count + 6, 3);
+   puts("Press UP/DOWN to move, ENTER to select, ESC/CTRL+C to quit");
puts(ANSI_CLEAR_LINE_TO_END);
printf(ANSI_CURSOR_POSITION, menu->count + 7, 1);
puts(ANSI_CLEAR_LINE);
-- 
2.34.1



Re: [PATCH v5 08/17] bootmenu: update bootmenu_entry structure

2022-05-01 Thread Heinrich Schuchardt

On 4/29/22 21:51, Heinrich Schuchardt wrote:

On 4/28/22 10:09, Masahisa Kojima wrote:

This is a preparation for succeeding addition of uefi boot
and distro boot menu entries into bootmenu.
The bootmenu_entry title is updated to u16 string because
uefi use u16 string. This commit also factors out the function
to prepare the entries generated by "bootmenu_x" U-Boot environment
variable.

This commit also updates the bootmenu entry title.
The entry derived from "bootmenu_x" U-Boot environment variable
has the "bootmenu_xx" prefix as below.

   *** U-Boot Boot Menu ***

  bootmenu_00   : Boot 1. kernel
  bootmenu_01   : Boot 2. kernel
  bootmenu_02   : Reset board

Signed-off-by: Masahisa Kojima 
---
Changes in v5:
- split into the separate patch
- add function description comment

  cmd/bootmenu.c | 110 +++--
  1 file changed, 78 insertions(+), 32 deletions(-)

diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
index 9a32a18b19..15ad621c9f 100644
--- a/cmd/bootmenu.c
+++ b/cmd/bootmenu.c
@@ -3,6 +3,7 @@
   * (C) Copyright 2011-2013 Pali Rohár 
   */

+#include 
  #include 
  #include 
  #include 
@@ -24,11 +25,18 @@
   */
  #define MAX_ENV_SIZE    (9 + 2 + 1)

+enum boot_type {
+    BOOTMENU_TYPE_NONE = 0,
+    BOOTMENU_TYPE_BOOTMENU,
+};
+
  struct bootmenu_entry {
  unsigned short int num;    /* unique number 0 .. MAX_COUNT */
  char key[3];    /* key identifier of number */
-    char *title;    /* title of entry */
+    u16 *title;    /* title of entry */
  char *command;    /* hush command of entry */
+    enum boot_type type;    /* boot type of entry */
+    u16 bootorder;    /* order for each boot type */
  struct bootmenu_data *menu;    /* this bootmenu */
  struct bootmenu_entry *next;    /* next menu entry (num+1) */
  };
@@ -75,7 +83,10 @@ static void bootmenu_print_entry(void *data)
  if (reverse)
  puts(ANSI_COLOR_REVERSE);

-    puts(entry->title);
+    if (entry->type == BOOTMENU_TYPE_BOOTMENU)
+    printf("bootmenu_%02d   : %ls", entry->bootorder, entry->title);


This "bootmen_%02d" strings conveys not information of interest. Please 
remove this hunk.



+    else
+    printf("%ls", entry->title);

  if (reverse)
  puts(ANSI_COLOR_RESET);
@@ -279,31 +290,32 @@ static void bootmenu_destroy(struct 
bootmenu_data *menu)

  free(menu);
  }

-static struct bootmenu_data *bootmenu_create(int delay)
+/**
+ * prepare_bootmenu_entry() - generate the bootmenu_xx entries
+ *
+ * This function read the "bootmenu_x" U-Boot environment variable
+ * and generate the bootmenu entries.
+ *
+ * @menu:    pointer to the bootmenu structure
+ * @current:    pointer to the last bootmenu entry list
+ * @index:    pointer to the index of the last bootmenu entry,
+ *    the number of bootmenu entry is added by this function
+ * Return:    1 on success, negative value on error
+ */
+static int prepare_bootmenu_entry(struct bootmenu_data *menu,
+  struct bootmenu_entry **current,
+  unsigned short int *index)
  {
-    unsigned short int i = 0;
-    const char *option;
-    struct bootmenu_data *menu;
-    struct bootmenu_entry *iter = NULL;
-
  int len;
  char *sep;
-    char *default_str;
-    struct bootmenu_entry *entry;
-
-    menu = malloc(sizeof(struct bootmenu_data));
-    if (!menu)
-    return NULL;
-
-    menu->delay = delay;
-    menu->active = 0;
-    menu->first = NULL;
-
-    default_str = env_get("bootmenu_default");
-    if (default_str)
-    menu->active = (int)simple_strtol(default_str, NULL, 10);
+    const char *option;
+    unsigned short int i = *index;
+    struct bootmenu_entry *entry = NULL;
+    struct bootmenu_entry *iter = *current;

  while ((option = bootmenu_getoption(i))) {
+    u16 *buf;
+
  sep = strchr(option, '=');
  if (!sep) {
  printf("Invalid bootmenu entry: %s\n", option);
@@ -312,23 +324,23 @@ static struct bootmenu_data *bootmenu_create(int 
delay)


  entry = malloc(sizeof(struct bootmenu_entry));
  if (!entry)
-    goto cleanup;
+    return -ENOMEM;

  len = sep-option;
-    entry->title = malloc(len + 1);
+    buf = calloc(1, (len + 1) * sizeof(u16));
+    entry->title = buf;
  if (!entry->title) {
  free(entry);
-    goto cleanup;
+    return -ENOMEM;
  }
-    memcpy(entry->title, option, len);
-    entry->title[len] = 0;
+    utf8_utf16_strncpy(&buf, option, len);

  len = strlen(sep + 1);
  entry->command = malloc(len + 1);
  if (!entry->command) {
  free(entry->title);
  free(entry);
-    goto cleanup;
+    return -ENOMEM;
  }
  memcpy(entry->command, sep + 1, len);
  entry->command[len] = 0;
@@ -337,6 +349,8 @@ static struct bootmenu_da

Re: [PATCH v5 05/17] efi_loader: export efi_locate_device_handle()

2022-05-01 Thread Heinrich Schuchardt

On 4/28/22 10:09, Masahisa Kojima wrote:

From: AKASHI Takahiro 

This function will be used in the next commit where some behavior
of EFI boot manager will be expanded.

Signed-off-by: AKASHI Takahiro 
Reviewed-by: Ilias Apalodimas 


Reviewed-by: Heinrich Schuchardt 


---
No changes from original version

  include/efi_loader.h  | 4 
  lib/efi_loader/efi_boottime.c | 7 +++
  2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index ba79a9afb4..effb43369d 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -595,6 +595,10 @@ efi_status_t efi_create_handle(efi_handle_t *handle);
  void efi_delete_handle(efi_handle_t obj);
  /* Call this to validate a handle and find the EFI object for it */
  struct efi_object *efi_search_obj(const efi_handle_t handle);
+/* Locate device_path handle */
+efi_status_t EFIAPI efi_locate_device_path(const efi_guid_t *protocol,
+  struct efi_device_path **device_path,
+  efi_handle_t *device);
  /* Load image */
  efi_status_t EFIAPI efi_load_image(bool boot_policy,
   efi_handle_t parent_image,
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 5bcb8253ed..4da64b5d29 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1799,10 +1799,9 @@ failure:
   *
   * Return: status code
   */
-static efi_status_t EFIAPI efi_locate_device_path(
-   const efi_guid_t *protocol,
-   struct efi_device_path **device_path,
-   efi_handle_t *device)
+efi_status_t EFIAPI efi_locate_device_path(const efi_guid_t *protocol,
+  struct efi_device_path **device_path,
+  efi_handle_t *device)
  {
struct efi_device_path *dp;
size_t i;




Re: [PATCH 3/5] arm: mvebu: turris_omnia: Always enable MMC, SCSI and USB boot targets

2022-05-01 Thread Marek Behún
On Sun, 1 May 2022 16:52:31 +0200
Pali Rohár  wrote:

> On Friday 08 April 2022 11:00:24 Pali Rohár wrote:
> > On Wednesday 06 April 2022 21:31:18 Marek Behún wrote:  
> > > On Wed,  6 Apr 2022 11:39:34 +0200
> > > Pali Rohár  wrote:
> > >   
> > > > U-Boot for Turris Omnia is always compiled with MMC, SCSI and USB 
> > > > support,
> > > > so always enable macros for booting from these devices.  
> > > 
> > > This is not true. Attaching config where scsi is disabled.
> > > 
> > > If we want to enforce MMC, SCSI and USB, we should add
> > >   select MMC
> > > and others to Kconfig under TURRIS_OMNIA. But do we want to enfore
> > > these?
> > > 
> > > Marek  
> > 
> > IIRC macro BOOT_TARGET_DEVICES just defines default values for ENV. So
> > in default ENV would be macros for booting from SCSI, MMC and USB
> > targets. Which means that if you call saveenv on U-Boot compiled with
> > all these options and then replace U-Boot with the one without e.g. MMC
> > support, it does not replace env variables for MMC booting.
> > 
> > Anyway, does not defining e.g. SCSI booting env variables on U-Boot
> > without SCSI support result in the same state as defining SCSI booting
> > env variables on U-Boot with SCSI support with disconnected SCSI
> > controllers or disks? In both cases there would be no SCSI suitable boot
> > device.  
> 
> So, any issues with it?

No. If this cannot cause compilation failures, then I am okay with it.


Re: [PATCH 2/2] ARM: stm32: Use CONFIG_TFTP_TSIZE on DHSOM

2022-05-01 Thread Ramon Fried
On Sun, May 1, 2022 at 7:43 PM Marek Vasut  wrote:
>
> Long TFTP transfers lead to a wall of # characters on UART, which in
> the end may slow down the transfer itself. Use CONFIG_TFTP_TSIZE to
> print progress in fewer # characters.
>
> Signed-off-by: Marek Vasut 
> Cc: Patrick Delaunay 
> Cc: Patrice Chotard 
> Cc: Ramon Fried 
> ---
>  configs/stm32mp15_dhcom_basic_defconfig | 1 +
>  configs/stm32mp15_dhcor_basic_defconfig | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/configs/stm32mp15_dhcom_basic_defconfig 
> b/configs/stm32mp15_dhcom_basic_defconfig
> index 0ff015cae49..7f7aecf2510 100644
> --- a/configs/stm32mp15_dhcom_basic_defconfig
> +++ b/configs/stm32mp15_dhcom_basic_defconfig
> @@ -80,6 +80,7 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>  CONFIG_SPL_ENV_IS_NOWHERE=y
>  CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_IP_DEFRAG=y
> +CONFIG_TFTP_TSIZE=y
>  CONFIG_STM32_ADC=y
>  CONFIG_SPL_BLOCK_CACHE=y
>  CONFIG_DFU_MMC=y
> diff --git a/configs/stm32mp15_dhcor_basic_defconfig 
> b/configs/stm32mp15_dhcor_basic_defconfig
> index 83614b9fc8e..35e43a9a2fc 100644
> --- a/configs/stm32mp15_dhcor_basic_defconfig
> +++ b/configs/stm32mp15_dhcor_basic_defconfig
> @@ -77,6 +77,7 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>  CONFIG_SPL_ENV_IS_NOWHERE=y
>  CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_IP_DEFRAG=y
> +CONFIG_TFTP_TSIZE=y
>  CONFIG_STM32_ADC=y
>  CONFIG_SPL_BLOCK_CACHE=y
>  CONFIG_DFU_MMC=y
> --
> 2.35.1
>
Reviewed-by: Ramon Fried 


Re: [PATCH 1/2] ARM: stm32: Use default CONFIG_TFTP_BLOCKSIZE on DHSOM

2022-05-01 Thread Ramon Fried
On Sun, May 1, 2022 at 7:43 PM Marek Vasut  wrote:
>
> The DHCOM does ship with KS8851 with 1.5 kiB packet buffer. The DHSOM
> may be extended with other MAC options connected to FMC2 bus, like the
> DM9000, wih similar limitations. Use default CONFIG_TFTP_BLOCKSIZE of
> 1468 Bytes instead of 1536 Bytes, which always avoids overflowing the
> packet buffers of such limited MACs, which leads to e.g. TFTP timeouts.
> This also avoids receiving a short packet fragment at the end of each
> TFTP block, which led to reduced performance.
>
> Signed-off-by: Marek Vasut 
> Cc: Patrick Delaunay 
> Cc: Patrice Chotard 
> Cc: Ramon Fried 
> ---
>  configs/stm32mp15_dhcom_basic_defconfig | 1 -
>  configs/stm32mp15_dhcor_basic_defconfig | 1 -
>  2 files changed, 2 deletions(-)
>
> diff --git a/configs/stm32mp15_dhcom_basic_defconfig 
> b/configs/stm32mp15_dhcom_basic_defconfig
> index ec955eae200..0ff015cae49 100644
> --- a/configs/stm32mp15_dhcom_basic_defconfig
> +++ b/configs/stm32mp15_dhcom_basic_defconfig
> @@ -80,7 +80,6 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>  CONFIG_SPL_ENV_IS_NOWHERE=y
>  CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_IP_DEFRAG=y
> -CONFIG_TFTP_BLOCKSIZE=1536
>  CONFIG_STM32_ADC=y
>  CONFIG_SPL_BLOCK_CACHE=y
>  CONFIG_DFU_MMC=y
> diff --git a/configs/stm32mp15_dhcor_basic_defconfig 
> b/configs/stm32mp15_dhcor_basic_defconfig
> index 387e068155e..83614b9fc8e 100644
> --- a/configs/stm32mp15_dhcor_basic_defconfig
> +++ b/configs/stm32mp15_dhcor_basic_defconfig
> @@ -77,7 +77,6 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>  CONFIG_SPL_ENV_IS_NOWHERE=y
>  CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_IP_DEFRAG=y
> -CONFIG_TFTP_BLOCKSIZE=1536
>  CONFIG_STM32_ADC=y
>  CONFIG_SPL_BLOCK_CACHE=y
>  CONFIG_DFU_MMC=y
> --
> 2.35.1
>
Reviewed-by: Ramon Fried 


[PATCH] powerpc: mmu: Fix FSL_BOOKE_MAS2() macro

2022-05-01 Thread Pali Rohár
Effective page number mask for MAS2 register is stored in macro MAS2_EPN.

Fixes: 2146cf56821c ("Reworked FSL Book-E TLB macros to be more readable")
Signed-off-by: Pali Rohár 
---
 arch/powerpc/include/asm/mmu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 2e6255f0d606..b0aafdcdae10 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -447,7 +447,7 @@ extern void print_bats(void);
(((ts) << 12) & MAS1_TS)|\
(MAS1_TSIZE(tsize)))
 #define FSL_BOOKE_MAS2(epn, wimge) \
-   (((epn) & MAS3_RPN) | (wimge))
+   (((epn) & MAS2_EPN) | (wimge))
 #define FSL_BOOKE_MAS3(rpn, user, perms) \
(((rpn) & MAS3_RPN) | (user) | (perms))
 #define FSL_BOOKE_MAS7(rpn) \
-- 
2.20.1



[PATCH] net: Fix discuss discard typo

2022-05-01 Thread Marek Vasut
Replace discuss with discard, that is what happens with packet with
incorrect checksum. Fix the typo.

Fixes: 4b37fd146bb ("Convert CONFIG_UDP_CHECKSUM to Kconfig")
Signed-off-by: Marek Vasut 
Cc: Ramon Fried 
Cc: Simon Glass 
---
 net/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/Kconfig b/net/Kconfig
index 964a4fe4999..564ea8b2d28 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -158,7 +158,7 @@ config UDP_CHECKSUM
default y if SANDBOX
help
  Enable this to verify the checksum on UDP packets. If the checksum
- is wrong then the packet is discussed and an error is shown, like
+ is wrong then the packet is discarded and an error is shown, like
  "UDP wrong checksum 29374a23 30ff3826"
 
 config BOOTP_SERVERIP
-- 
2.35.1



[PATCH 2/2] ARM: stm32: Use CONFIG_TFTP_TSIZE on DHSOM

2022-05-01 Thread Marek Vasut
Long TFTP transfers lead to a wall of # characters on UART, which in
the end may slow down the transfer itself. Use CONFIG_TFTP_TSIZE to
print progress in fewer # characters.

Signed-off-by: Marek Vasut 
Cc: Patrick Delaunay 
Cc: Patrice Chotard 
Cc: Ramon Fried 
---
 configs/stm32mp15_dhcom_basic_defconfig | 1 +
 configs/stm32mp15_dhcor_basic_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/stm32mp15_dhcom_basic_defconfig 
b/configs/stm32mp15_dhcom_basic_defconfig
index 0ff015cae49..7f7aecf2510 100644
--- a/configs/stm32mp15_dhcom_basic_defconfig
+++ b/configs/stm32mp15_dhcom_basic_defconfig
@@ -80,6 +80,7 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_SPL_ENV_IS_NOWHERE=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_IP_DEFRAG=y
+CONFIG_TFTP_TSIZE=y
 CONFIG_STM32_ADC=y
 CONFIG_SPL_BLOCK_CACHE=y
 CONFIG_DFU_MMC=y
diff --git a/configs/stm32mp15_dhcor_basic_defconfig 
b/configs/stm32mp15_dhcor_basic_defconfig
index 83614b9fc8e..35e43a9a2fc 100644
--- a/configs/stm32mp15_dhcor_basic_defconfig
+++ b/configs/stm32mp15_dhcor_basic_defconfig
@@ -77,6 +77,7 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_SPL_ENV_IS_NOWHERE=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_IP_DEFRAG=y
+CONFIG_TFTP_TSIZE=y
 CONFIG_STM32_ADC=y
 CONFIG_SPL_BLOCK_CACHE=y
 CONFIG_DFU_MMC=y
-- 
2.35.1



[PATCH 1/2] ARM: stm32: Use default CONFIG_TFTP_BLOCKSIZE on DHSOM

2022-05-01 Thread Marek Vasut
The DHCOM does ship with KS8851 with 1.5 kiB packet buffer. The DHSOM
may be extended with other MAC options connected to FMC2 bus, like the
DM9000, wih similar limitations. Use default CONFIG_TFTP_BLOCKSIZE of
1468 Bytes instead of 1536 Bytes, which always avoids overflowing the
packet buffers of such limited MACs, which leads to e.g. TFTP timeouts.
This also avoids receiving a short packet fragment at the end of each
TFTP block, which led to reduced performance.

Signed-off-by: Marek Vasut 
Cc: Patrick Delaunay 
Cc: Patrice Chotard 
Cc: Ramon Fried 
---
 configs/stm32mp15_dhcom_basic_defconfig | 1 -
 configs/stm32mp15_dhcor_basic_defconfig | 1 -
 2 files changed, 2 deletions(-)

diff --git a/configs/stm32mp15_dhcom_basic_defconfig 
b/configs/stm32mp15_dhcom_basic_defconfig
index ec955eae200..0ff015cae49 100644
--- a/configs/stm32mp15_dhcom_basic_defconfig
+++ b/configs/stm32mp15_dhcom_basic_defconfig
@@ -80,7 +80,6 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_SPL_ENV_IS_NOWHERE=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_IP_DEFRAG=y
-CONFIG_TFTP_BLOCKSIZE=1536
 CONFIG_STM32_ADC=y
 CONFIG_SPL_BLOCK_CACHE=y
 CONFIG_DFU_MMC=y
diff --git a/configs/stm32mp15_dhcor_basic_defconfig 
b/configs/stm32mp15_dhcor_basic_defconfig
index 387e068155e..83614b9fc8e 100644
--- a/configs/stm32mp15_dhcor_basic_defconfig
+++ b/configs/stm32mp15_dhcor_basic_defconfig
@@ -77,7 +77,6 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_SPL_ENV_IS_NOWHERE=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_IP_DEFRAG=y
-CONFIG_TFTP_BLOCKSIZE=1536
 CONFIG_STM32_ADC=y
 CONFIG_SPL_BLOCK_CACHE=y
 CONFIG_DFU_MMC=y
-- 
2.35.1



Re: [PATCH 00/12] sunxi: Devicetree sync from Linux v5.18-rc1

2022-05-01 Thread Tom Rini
On Sat, Apr 30, 2022 at 01:08:43AM +0100, Andre Przywara wrote:
> On Fri, 29 Apr 2022 14:14:19 -0400
> Tom Rini  wrote:
> 
> Hi,
> 
> > On Fri, Apr 29, 2022 at 06:05:03PM +0200, Mark Kettenis wrote:
> > > > Date: Fri, 29 Apr 2022 11:31:00 -0400
> > > > From: Tom Rini 
> > > > 
> > > > On Fri, Apr 29, 2022 at 04:25:51PM +0100, Andre Przywara wrote:  
> > > > > On Fri, 29 Apr 2022 10:57:10 -0400
> > > > > Tom Rini  wrote:
> > > > > 
> > > > > Hi,
> > > > >   
> > > > > > On Fri, Apr 29, 2022 at 03:51:59PM +0100, Andre Przywara wrote:  
> > > > > > > On Wed, 27 Apr 2022 15:31:19 -0500
> > > > > > > Samuel Holland  wrote:
> > > > > > > 
> > > > > > > Hi Samuel, Tom,
> > > > > > > 
> > > > > > > > This series brings all of our devicetrees up to date with Linux.
> > > > > > > > 
> > > > > > > > Older SoCs (before A83T) have not been synchronized in over 3 
> > > > > > > > years.
> > > > > > > > And I don't have any of this hardware to test. But there are 
> > > > > > > > not major
> > > > > > > > changes to those devicetrees either.
> > > > > > > > 
> > > > > > > > The big motivation for including older SoCs in this update is 
> > > > > > > > converting
> > > > > > > > the USB PHY driver to get its VBUS detection GPIO/regulator 
> > > > > > > > from the
> > > > > > > > devicetree instead of from a pin name in Kconfig. Many older 
> > > > > > > > boards had
> > > > > > > > those properties added or fixed since the last devicetree sync. 
> > > > > > > > This PHY
> > > > > > > > driver change is necessary to complete the DM_GPIO migration.
> > > > > > > > 
> > > > > > > > A couple of breaking changes were made to several SoCs' 
> > > > > > > > devicetrees in
> > > > > > > > Linux relating to the "r_intc" interrupt controller. New 
> > > > > > > > kernels support
> > > > > > > > old devicetrees, but not the other way around. So to be most 
> > > > > > > > compatible
> > > > > > > > and avoid regressions, those changes are skipped here.
> > > > > > > 
> > > > > > > Many thanks for considering this! I just skimmed over the A64 and 
> > > > > > > H6
> > > > > > > patches, and this is indeed the only difference.
> > > > > > > 
> > > > > > > But while I love this pragmatic approach, and would be happy to 
> > > > > > > take this,
> > > > > > > this goes against our own rules, and more importantly against 
> > > > > > > Tom's one's:
> > > > > > > to take only direct DT file copies from the kernel tree.
> > > > > > > 
> > > > > > > Tom, can you give your opinion here? As Samuel mentioned above, 
> > > > > > > the
> > > > > > > current mainline DTs wouldn't boot on older kernels (the changes 
> > > > > > > affect
> > > > > > > critical devices), so this spoils stable distro and installer 
> > > > > > > kernels,
> > > > > > > when using $fdtcontroladdr, for instance when booting via UEFI.
> > > > > > > 
> > > > > > > As a side effect of always defining SYS_SOC to "sunxi", we cannot 
> > > > > > > easily
> > > > > > > use per-SoC DT overrides using sun50i-a64-u-boot.dtsi, for 
> > > > > > > instance.
> > > > > > > 
> > > > > > > For context, those changed properties were in the mainline kernel 
> > > > > > > tree at
> > > > > > > some point, but have been amended since. So it's not some random 
> > > > > > > change.
> > > > > > 
> > > > > > So, this is I guess a bit annoying.  But, we aren't at the point 
> > > > > > where
> > > > > > the common use case is the downstream OS using the DTB we've loaded 
> > > > > > and
> > > > > > are using, are we?  I mean, we can't be, as ours are so far out of 
> > > > > > date,
> > > > > > so this will only be an option when we use a recent DT ourself.  So 
> > > > > > we
> > > > > > should be able to sync in the changes and update our code, as they 
> > > > > > can't
> > > > > > be using $fdtcontroladdr in this case, right?  Or am I missing the 
> > > > > > use
> > > > > > case that's in the wild atm?  Thanks!  
> > > > > 
> > > > > While it sounds like the DTs are wildly out of date, this mostly 
> > > > > affects
> > > > > secondary functionality. The mainline updates for the 64-bit SoCs are:
> > > > > - H6: adding the VP9 video h/w codec and an additional wakeup timer
> > > > > - A64: adding GPU DVFS, adding DRAM DVFS, add support for secondary
> > > > > digital audio interfaces, plus the wakeup timer
> > > > > Also there are cosmetic changes, like changing node names to make them
> > > > > binding compliant.
> > > > > So those DT updates are really only important for mobile devices like 
> > > > > the
> > > > > Pinephone, which probably don't use UEFI booting.
> > > > > 
> > > > > At the moment I boot distro grubs and installers just fine, and 
> > > > > without
> > > > > losing any real functionality (minus suspend/resume, maybe). The
> > > > > out-of-the-box default boot works now, and would break when pulling 
> > > > > in the
> > > > > pure mainline DTs. Plus FreeBSD (which relies more heavily on UEFI, 
> > > > > IIUC),
> > > > > can only deal with the older DTs (#inte

Re: Pull request for efi-2022-07-rc2

2022-05-01 Thread Tom Rini
On Fri, Apr 29, 2022 at 07:03:16PM +0200, Heinrich Schuchardt wrote:

> Dear Tom,
> 
> The following changes since commit 8b2b125e95c44bb007b4573945f4aedb8a56222c:
> 
>   Merge https://gitlab.denx.de/u-boot/custodians/u-boot-mpc85xx
> (2022-04-27 09:19:41 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-efi.git
> tags/efi-2022-07-rc2
> 
> for you to fetch changes up to 5e847f7729b3cc34b572b4f59ee7d468b3b76ccc:
> 
>   efi_loader: call efi_init_early() earlier
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/6] Revert "Convert CONFIG_SYS_BR0_PRELIM et al to Kconfig"

2022-05-01 Thread Tom Rini
On Sun, May 01, 2022 at 05:33:19PM +0200, Pali Rohár wrote:
> On Sunday 01 May 2022 11:14:21 Tom Rini wrote:
> > On Sun, May 01, 2022 at 04:44:16PM +0200, Pali Rohár wrote:
> > > On Sunday 01 May 2022 10:39:39 Tom Rini wrote:
> > > > On Sun, May 01, 2022 at 04:23:52PM +0200, Pali Rohár wrote:
> > > > 
> > > > > This reverts commit c7fad78ec0ee41b72a58bebb61959570eb937ab1.
> > > > > 
> > > > > This commit made configuration, understanding, maintenance, debugging 
> > > > > and
> > > > > future development of the powerpc/mpc85xx Local Bus Controller on 
> > > > > P1/P2
> > > > > boards impossible.
> > > > > 
> > > > > All preliminary Base and Option registers depends on other code and C
> > > > > macros generated at C compile time and they comes from the other 
> > > > > macros.
> > > > > 
> > > > > For example, NOR base address and NOR options are set via macros
> > > > > CONFIG_SYS_FLASH_BR_PRELIM and CONFIG_SYS_FLASH_OR_PRELIM. And then 
> > > > > based
> > > > > on other logic are filled correct values in to the correct macros
> > > > > CONFIG_SYS_BR*_PRELIM and CONFIG_SYS_OR*_PRELIM.
> > > > > 
> > > > > These config options are not user configurable options and therefore
> > > > > should not appear in menuconfig. Moreover for P1/P2 boards they have
> > > > > nothing with DDR driver, so they should not appear in drivers/ddr.
> > > > > 
> > > > > This change was completely wrong direction, so revert it. It allows to
> > > > > start fixing issues with FLASH, NOR, NAND and CPLD LBC configuration.
> > > > > In current state it is impossible.
> > > > > 
> > > > > See also thread for more details:
> > > > > https://lore.kernel.org/u-boot/20220426181740.o2n7xfg46ytljcdx@pali/t/#u
> > > > > 
> > > > > Signed-off-by: Pali Rohár 
> > > > 
> > > > NAK.  We are not moving things back in to board config headers under
> > > > CONFIG namespace.  Some other solution is required.
> > > 
> > > I spend time on this and I do not see any other solution. As explained
> > > that commit just introduced more issues then what it brought, so it was
> > > step backward, not forward. So please show other solution, if you do not
> > > like this one.
> > 
> > Anything that I suggested in the previous thread about moving to board
> > Kconfig files.
> 
> Kconfig does not support evaluating C macros from C header files. So it
> would not work.

Document how to derive them using tools like 'printf' when adding more
boards, which should not be a common case anyhow.

> > Or move it to some other header and out of CONFIG namespace.
> 
> This is board specific setting, used by drivers and arch code. So it
> needs to be in some board location, like the config header file.

But all include/config/*.h files are destined to be removed, so they
cannot live there.  Everything in the CONFIG namespace needs to be in
Kconfig.  Nothing outside of CONFIG namespace belongs under
include/configs/.

> > Or if dtoc (doc/develop/driver-model/of-plat.rst) isn't
> > sufficient today to pull out the infos to use at build time, expand it
> > to cover this case as it would be useful for large numbers of other
> > cases.
> 
> This would mean to rewrite completely everything about LBC configuration
> and its peripherals. I really do not have energy nor time for it.

Neither apparently has anyone else for the last far far too long.

> There are issues which needs to be fixed first, then some "code cleanup"
> and "non-functional" changes could be done.
> 
> But that your commit c7fad78ec0ee41b72a58bebb61959570eb937ab1 make it
> impossible to do anything with LBC, neither new development, nor doing
> bug fixes. So it is in the worst state in which it can be.

How?  Derive the correct hex value and put it in.

> That commit has same effect as conservation of the code and putting it
> into the state to disallow future development in this area. Because
> everybody who wants to touch it, has to first do what you wrote above.

Yes.  The code is sub-standard and needs improvement.

> But this is such giant work which nobody is going to do, just for fixing
> small bug, which is completely unrelated to that work. And that work is
> only refactor/code cleanup which does not bring any functional value.
> Nothing so fancy, that somebody would do in spare time.
> 
> So I hope that this was not your intension.

My intention is to get the PowerPC code up to modern U-Boot standards.
Or, to get it removed since there's not enough interest in maintaining
and updating it.

To re-iterate, I agree that it would be good to construct the values at
build time using macros.  No one likes looking at raw magic values.  But
for an otherwise dead end platform, documenting how these magic values
are constructed (something under doc/arch/ or doc/board/) for anyone in
the future doing more work is Good Enough for me.  Alternatively,
re-working things so that instead of being pulled from
include/configs/board-config.h they come from board/.../something.h is
Good Enough, so long as they are NOT usin

[PATCH] powerpc: fsl_law: Add definition for first PCIe target interface

2022-05-01 Thread Pali Rohár
Header file asm/fsl_law.h already provides correct definition for second
and third PCIe controller (LAW_TRGT_IF_PCIE_2 and LAW_TRGT_IF_PCIE_3). But
is missing definition for the first PCIe controller (LAW_TRGT_IF_PCIE_1).

Note that existing definition for LAW_TRGT_IF_PCIE_2 and LAW_TRGT_IF_PCIE_3
are slightly complicated, but are really correct for P2020 platform.

Signed-off-by: Pali Rohár 
---
 arch/powerpc/include/asm/fsl_law.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/include/asm/fsl_law.h 
b/arch/powerpc/include/asm/fsl_law.h
index 39fbc04e4744..9e2f2d5370d9 100644
--- a/arch/powerpc/include/asm/fsl_law.h
+++ b/arch/powerpc/include/asm/fsl_law.h
@@ -78,6 +78,7 @@ enum law_trgt_if {
 enum law_trgt_if {
LAW_TRGT_IF_PCI = 0x00,
LAW_TRGT_IF_PCI_2 = 0x01,
+   LAW_TRGT_IF_PCIE_1 = 0x02,
 #if defined(CONFIG_ARCH_BSC9131) || defined(CONFIG_ARCH_BSC9132)
LAW_TRGT_IF_OCN_DSP = 0x03,
 #else
-- 
2.20.1



Re: [PATCH v5 03/17] menu: always show the menu regardless of the number of entry

2022-05-01 Thread Heinrich Schuchardt

On 4/28/22 10:09, Masahisa Kojima wrote:

To make user aware of the menu entry selection, menu always
appears regardless of the number of entry.

Signed-off-by: Masahisa Kojima 


Reviewed-by: Heinrich Schuchardt 


---
No changes since v4

Newly created in v4

  common/menu.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/menu.c b/common/menu.c
index 5fb2ffbd06..b577d80b4f 100644
--- a/common/menu.c
+++ b/common/menu.c
@@ -271,7 +271,7 @@ int menu_get_choice(struct menu *m, void **choice)
if (!m || !choice)
return -EINVAL;

-   if (!m->prompt || m->item_cnt == 1)
+   if (!m->prompt)
return menu_default_choice(m, choice);

return menu_interactive_choice(m, choice);




Re: [PATCH 1/6] Revert "Convert CONFIG_SYS_BR0_PRELIM et al to Kconfig"

2022-05-01 Thread Pali Rohár
On Sunday 01 May 2022 11:14:21 Tom Rini wrote:
> On Sun, May 01, 2022 at 04:44:16PM +0200, Pali Rohár wrote:
> > On Sunday 01 May 2022 10:39:39 Tom Rini wrote:
> > > On Sun, May 01, 2022 at 04:23:52PM +0200, Pali Rohár wrote:
> > > 
> > > > This reverts commit c7fad78ec0ee41b72a58bebb61959570eb937ab1.
> > > > 
> > > > This commit made configuration, understanding, maintenance, debugging 
> > > > and
> > > > future development of the powerpc/mpc85xx Local Bus Controller on P1/P2
> > > > boards impossible.
> > > > 
> > > > All preliminary Base and Option registers depends on other code and C
> > > > macros generated at C compile time and they comes from the other macros.
> > > > 
> > > > For example, NOR base address and NOR options are set via macros
> > > > CONFIG_SYS_FLASH_BR_PRELIM and CONFIG_SYS_FLASH_OR_PRELIM. And then 
> > > > based
> > > > on other logic are filled correct values in to the correct macros
> > > > CONFIG_SYS_BR*_PRELIM and CONFIG_SYS_OR*_PRELIM.
> > > > 
> > > > These config options are not user configurable options and therefore
> > > > should not appear in menuconfig. Moreover for P1/P2 boards they have
> > > > nothing with DDR driver, so they should not appear in drivers/ddr.
> > > > 
> > > > This change was completely wrong direction, so revert it. It allows to
> > > > start fixing issues with FLASH, NOR, NAND and CPLD LBC configuration.
> > > > In current state it is impossible.
> > > > 
> > > > See also thread for more details:
> > > > https://lore.kernel.org/u-boot/20220426181740.o2n7xfg46ytljcdx@pali/t/#u
> > > > 
> > > > Signed-off-by: Pali Rohár 
> > > 
> > > NAK.  We are not moving things back in to board config headers under
> > > CONFIG namespace.  Some other solution is required.
> > 
> > I spend time on this and I do not see any other solution. As explained
> > that commit just introduced more issues then what it brought, so it was
> > step backward, not forward. So please show other solution, if you do not
> > like this one.
> 
> Anything that I suggested in the previous thread about moving to board
> Kconfig files.

Kconfig does not support evaluating C macros from C header files. So it
would not work.

> Or move it to some other header and out of CONFIG namespace.

This is board specific setting, used by drivers and arch code. So it
needs to be in some board location, like the config header file.

> Or if dtoc (doc/develop/driver-model/of-plat.rst) isn't
> sufficient today to pull out the infos to use at build time, expand it
> to cover this case as it would be useful for large numbers of other
> cases.

This would mean to rewrite completely everything about LBC configuration
and its peripherals. I really do not have energy nor time for it.

There are issues which needs to be fixed first, then some "code cleanup"
and "non-functional" changes could be done.

But that your commit c7fad78ec0ee41b72a58bebb61959570eb937ab1 make it
impossible to do anything with LBC, neither new development, nor doing
bug fixes. So it is in the worst state in which it can be.

That commit has same effect as conservation of the code and putting it
into the state to disallow future development in this area. Because
everybody who wants to touch it, has to first do what you wrote above.
But this is such giant work which nobody is going to do, just for fixing
small bug, which is completely unrelated to that work. And that work is
only refactor/code cleanup which does not bring any functional value.
Nothing so fancy, that somebody would do in spare time.

So I hope that this was not your intension.


Re: [PATCH] pci: Do not enable PCIe ASMedia ASM2824 workaround by default

2022-05-01 Thread Pali Rohár
On Friday 08 April 2022 00:18:48 Maciej W. Rozycki wrote:
> On Thu, 7 Apr 2022, Stefan Roese wrote:
> 
> > > Hello! What do you think about this change? I think it is good
> > > compromise between enable this workaround for all builds on all boards
> > > and enable it only based on device id. Or would it be better to restrict
> > > this workaround just for ASM2824 device like the last iteration of
> > > kernel patch?
> > 
> > I'm not sure if we should name this "workaround" ASM2824, even though
> > it's currently (only) targeted exactly for this PCIe switch. It might
> > be helpful for other PCIe switches as well. So perhaps it's better to
> > give this function a more generic name instead? With this change, it
> > makes perhaps also sense to keep this function in pci_auto.c but also
> > rename the Kconfig option to some more generic version.
> 
>  By now I have become somewhat tired arguing and explaining matters over 
> and over again as things have been moving as slow as molasses in this 
> area, but one point I want to raise here is while it is indeed the ASM2824 
> device that seems problematic, it may actually be downstream, so you won't 
> know it's there until you go through the workaround, as observed with the 
> root port of the SiFive FU740-C000 SOC (which has a separate workaround in 
> U-boot, clearly for the same issue; cf. `pcie_sifive_force_gen1').  So it 
> looks like the erratum is going to show up with some device combinations 
> in which the device enumerator may not have a way to know an ASM2824 is 
> there until the workaround applied to an upstream device has let the link 
> work.

I see that Linux patch was not not merged yet and there are already
comments that this issue is probably board or arch specific and maybe
should be in arch/riscv linux dir:
https://lore.kernel.org/linux-pci/20220421202711.GA1415244@bhelgaas/

>From that comment I have feeling that the issue could be really specific
to board or combination of connected devices (ASM2824+PI7C9X2G304) as
there is really no other report about this issue.

In any case it is weird.

>  And as I previously already mentioned the Linux version of the workaround 
> is only activated by the vendor:device ID because you cannot busy-loop 
> polling on the Link Training bit in Linux (while you can do it in U-Boot, 
> because U-Boot is not an OS).

Is is not _only_ because of this. For a longer time there is a direction
to specify exact list of _affected_ hw which needs workaround. And not
usage of wildcard which match all hardware, even unaffected. See for
example comments which are adding workaround for broken GIC HW:
https://lore.kernel.org/lkml/87ilsutb6w.wl-...@kernel.org/

And this makes sense, workarounds should be targeted.

> Arguably I could have broadened it to cover 
> all Gen 3+ devices and poll on the Data Link Layer Link Active bit, which 
> doesn't require busy-looping for meaningful results, but that would still 
> leave Gen 2 devices out and chances are the system boots from U-Boot with 
> the generic workaround applied and the link already negotiated at 2.5GT/s.
> 
>  NB the ASM2824 switch has been used with option cards as well, e.g. 
> , so it can be there in any system 
> that has a connector of any kind that lets one use PCIe option cards.
> 
>  FWIW,
> 
>   Maciej


Re: [RFC 2/3] serial: mxc: Enable getting and enabling clocks with CCF Composite

2022-05-01 Thread Adam Ford
On Sun, May 1, 2022 at 4:48 AM Peng Fan (OSS)  wrote:
>
>
>
> On 2022/5/1 0:14, Adam Ford wrote:
> > Certain platforms have the UART clocks exposed through the CCF.
> > When they are, it's possible to enable and query the clock(s)
> > for a given UART. Add support getting, enabling, and querying
> > the clocks.
> >
> > Signed-off-by: Adam Ford 
> >
> > diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
> > index e4970a169b..c68040ba74 100644
> > --- a/drivers/serial/serial_mxc.c
> > +++ b/drivers/serial/serial_mxc.c
> > @@ -10,6 +10,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > @@ -266,8 +267,13 @@ __weak struct serial_device 
> > *default_serial_console(void)
> >   int mxc_serial_setbrg(struct udevice *dev, int baudrate)
> >   {
> >   struct mxc_serial_plat *plat = dev_get_plat(dev);
> > - u32 clk = imx_get_uartclk();
> > + u32 clk;
> >
> > +#if CONFIG_IS_ENABLED(CLK_COMPOSITE_CCF)
>
> CONFIG_IS_ENABLED(CLK) should be fine.

I chose the composite because I knew it was limited to the imx8m
family and there is one imx6 and an imxrt with CLK enabled.  I can
look into the imx6, but the imxrt isn't hardware i have.
I'll try to add the clocks for both imx6q and the imxrt.

>
> > +  clk = clk_get_rate(&plat->ipg_clk);
> > +#else
> > + clk = imx_get_uartclk;
>
> "()" should not be dropped.

oops.  I'll fix that.


>
> > +#endif
> >   _mxc_serial_setbrg(plat->reg, clk, baudrate, plat->use_dte);
> >
> >   return 0;
> > @@ -277,6 +283,22 @@ static int mxc_serial_probe(struct udevice *dev)
> >   {
> >   struct mxc_serial_plat *plat = dev_get_plat(dev);
> >
> > +#if CONFIG_IS_ENABLED(CLK_COMPOSITE_CCF)
>
> Ditto
>
> > + int ret = 0;
> > +
> > + ret = clk_enable(&plat->per_clk);
> > + if (ret) {
> > + printf("Failed to enable per_clk\n");
> > + return ret;
> > + }
> > +
> > + ret = clk_enable(&plat->per_clk);
>
> ipg_clk?

Opps.  Copy-paste error.  I'll fix that.
>
> > + if (ret) {
> > + printf("Failed to enable ipg_clk\n");
> > + return ret;
> > + }
> > +
> > +#endif
> >   _mxc_serial_init(plat->reg, plat->use_dte);
> >
> >   return 0;
> > @@ -339,6 +361,21 @@ static int mxc_serial_of_to_plat(struct udevice *dev)
> >
> >   plat->use_dte = fdtdec_get_bool(gd->fdt_blob, dev_of_offset(dev),
> >   "fsl,dte-mode");
> > +#if CONFIG_IS_ENABLED(CLK_COMPOSITE_CCF)
> > + int ret = 0;
> > +
> > + ret = clk_get_by_name(dev, "per", &plat->per_clk);
> > + if (ret) {
> > + printf("Failed to get per_clk\n");
> > + return ret;
> > + }
> > +
> > + ret = clk_get_by_name(dev, "ipg", &plat->ipg_clk);
> > + if (ret) {
> > + printf("Failed to get per_clk\n");

There is a copy-paste error here too that I'll fix.

> > + return ret;
> > + }
> > +#endif
>
> Regards,
> Peng.

Thanks for the review  I'll try to get a more formal patch with the
additional clocks added for the other SoC's, then fix the typos in
here.  I'm on vacation out of the country on May 8-23, so I'm going to
try to get it submitted before I leave.

adam
>
> >   return 0;
> >   }
> >
> > diff --git a/include/dm/platform_data/serial_mxc.h 
> > b/include/dm/platform_data/serial_mxc.h
> > index cc59eeb1dd..9a8c8498bf 100644
> > --- a/include/dm/platform_data/serial_mxc.h
> > +++ b/include/dm/platform_data/serial_mxc.h
> > @@ -10,6 +10,8 @@
> >   struct mxc_serial_plat {
> >   struct mxc_uart *reg;  /* address of registers in physical memory */
> >   bool use_dte;
> > + struct clk per_clk;
> > + struct clk ipg_clk;
> >   };
> >
> >   #endif
> >


Re: [PATCH 1/6] Revert "Convert CONFIG_SYS_BR0_PRELIM et al to Kconfig"

2022-05-01 Thread Tom Rini
On Sun, May 01, 2022 at 04:44:16PM +0200, Pali Rohár wrote:
> On Sunday 01 May 2022 10:39:39 Tom Rini wrote:
> > On Sun, May 01, 2022 at 04:23:52PM +0200, Pali Rohár wrote:
> > 
> > > This reverts commit c7fad78ec0ee41b72a58bebb61959570eb937ab1.
> > > 
> > > This commit made configuration, understanding, maintenance, debugging and
> > > future development of the powerpc/mpc85xx Local Bus Controller on P1/P2
> > > boards impossible.
> > > 
> > > All preliminary Base and Option registers depends on other code and C
> > > macros generated at C compile time and they comes from the other macros.
> > > 
> > > For example, NOR base address and NOR options are set via macros
> > > CONFIG_SYS_FLASH_BR_PRELIM and CONFIG_SYS_FLASH_OR_PRELIM. And then based
> > > on other logic are filled correct values in to the correct macros
> > > CONFIG_SYS_BR*_PRELIM and CONFIG_SYS_OR*_PRELIM.
> > > 
> > > These config options are not user configurable options and therefore
> > > should not appear in menuconfig. Moreover for P1/P2 boards they have
> > > nothing with DDR driver, so they should not appear in drivers/ddr.
> > > 
> > > This change was completely wrong direction, so revert it. It allows to
> > > start fixing issues with FLASH, NOR, NAND and CPLD LBC configuration.
> > > In current state it is impossible.
> > > 
> > > See also thread for more details:
> > > https://lore.kernel.org/u-boot/20220426181740.o2n7xfg46ytljcdx@pali/t/#u
> > > 
> > > Signed-off-by: Pali Rohár 
> > 
> > NAK.  We are not moving things back in to board config headers under
> > CONFIG namespace.  Some other solution is required.
> 
> I spend time on this and I do not see any other solution. As explained
> that commit just introduced more issues then what it brought, so it was
> step backward, not forward. So please show other solution, if you do not
> like this one.

Anything that I suggested in the previous thread about moving to board
Kconfig files.  Or move it to some other header and out of CONFIG
namespace.  Or if dtoc (doc/develop/driver-model/of-plat.rst) isn't
sufficient today to pull out the infos to use at build time, expand it
to cover this case as it would be useful for large numbers of other
cases.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot-marvell 0/8] Turris Omnia: Add support for configuring mSATA and WWAN slots via env variables

2022-05-01 Thread Pali Rohár
On Wednesday 02 March 2022 12:47:50 Pali Rohár wrote:
> Some mPCIe cards are broken and their PIN 43 incorrectly that card is
> mSATA. U-Boot SPL on Turris Omnia is using PIN 43 for configuring PCIe
> vs SATA functionality on SerDes. Allow to configure functionality via
> additional env variable "omnia_msata_slot" which may override PIN 43.
> 
> To force PCIe mode for broken MiniPCIe cards, call U-Boot commands:
> 
>   => setenv omnia_msata_slot pcie
>   => saveenv
>   => reset
> 
> 
> PCI-SIG in PCIe Mini CEM 2.1 spec added support for USB3.0 mode to mPCIe
> cards. PCIe and USB3.0 functions share same pins (like SATA pins on mSATA
> with PCIe on mPCIe) and therefore only one function may be active at the
> same time. This mode was introduced by PCI-SIG specially for LTE/5G modems.
> 
> One mPCIe slot on Turris Omnia is connected to A385 CPU SerDes which
> can be configured for PCIe or USB3.0 function. It is the slot with SIM
> card suitable for cellular modems. As PCIe Mini CEM 2.1 spec say that
> detection of PCIe vs USB3.0 functionality is platform specific, add a
> new U-Boot variable "omnia_wwan_slot" for configuring functionality in
> this slot. By default PCIe is used like before.
> 
> To set this WWAN slot to USB3.0 mode, call U-Boot commands:
> 
>   => setenv omnia_wwan_slot usb3
>   => saveenv
>   => reset
> 

PING? Any more comments on this patch series? It is there for two months.

> Pali Rohár (8):
>   env: sf: Allow to use env_sf_init_addr() at any stage
>   arm: mvebu: turris_omnia: Provide env_sf_get_env_addr() function
>   arm: mvebu: turris_omnia: Enable ENV support in SPL
>   arm: mvebu: turris_omnia: Define only one serdes map variable
>   arm: mvebu: turris_omnia: Allow to configure mSATA slot via env
> variable
>   arm: mvebu: turris_omnia: Extract code for disabling sata/pcie
>   arm: mvebu: turris_omnia: Signal error when sata/pcie DT mode
>   arm: mvebu: turris_omnia: Add support for USB3.0 mode in WWAN MiniPCIe
> slot
> 
>  board/CZ.NIC/turris_omnia/turris_omnia.c | 207 +--
>  configs/turris_omnia_defconfig   |   1 +
>  env/sf.c |  22 +--
>  3 files changed, 163 insertions(+), 67 deletions(-)
> 
> -- 
> 2.20.1
> 


Re: [PATCH 3/5] arm: mvebu: turris_omnia: Always enable MMC, SCSI and USB boot targets

2022-05-01 Thread Pali Rohár
On Friday 08 April 2022 11:00:24 Pali Rohár wrote:
> On Wednesday 06 April 2022 21:31:18 Marek Behún wrote:
> > On Wed,  6 Apr 2022 11:39:34 +0200
> > Pali Rohár  wrote:
> > 
> > > U-Boot for Turris Omnia is always compiled with MMC, SCSI and USB support,
> > > so always enable macros for booting from these devices.
> > 
> > This is not true. Attaching config where scsi is disabled.
> > 
> > If we want to enforce MMC, SCSI and USB, we should add
> >   select MMC
> > and others to Kconfig under TURRIS_OMNIA. But do we want to enfore
> > these?
> > 
> > Marek
> 
> IIRC macro BOOT_TARGET_DEVICES just defines default values for ENV. So
> in default ENV would be macros for booting from SCSI, MMC and USB
> targets. Which means that if you call saveenv on U-Boot compiled with
> all these options and then replace U-Boot with the one without e.g. MMC
> support, it does not replace env variables for MMC booting.
> 
> Anyway, does not defining e.g. SCSI booting env variables on U-Boot
> without SCSI support result in the same state as defining SCSI booting
> env variables on U-Boot with SCSI support with disconnected SCSI
> controllers or disks? In both cases there would be no SCSI suitable boot
> device.

So, any issues with it?


Re: [PATCH 1/6] Revert "Convert CONFIG_SYS_BR0_PRELIM et al to Kconfig"

2022-05-01 Thread Pali Rohár
On Sunday 01 May 2022 10:39:39 Tom Rini wrote:
> On Sun, May 01, 2022 at 04:23:52PM +0200, Pali Rohár wrote:
> 
> > This reverts commit c7fad78ec0ee41b72a58bebb61959570eb937ab1.
> > 
> > This commit made configuration, understanding, maintenance, debugging and
> > future development of the powerpc/mpc85xx Local Bus Controller on P1/P2
> > boards impossible.
> > 
> > All preliminary Base and Option registers depends on other code and C
> > macros generated at C compile time and they comes from the other macros.
> > 
> > For example, NOR base address and NOR options are set via macros
> > CONFIG_SYS_FLASH_BR_PRELIM and CONFIG_SYS_FLASH_OR_PRELIM. And then based
> > on other logic are filled correct values in to the correct macros
> > CONFIG_SYS_BR*_PRELIM and CONFIG_SYS_OR*_PRELIM.
> > 
> > These config options are not user configurable options and therefore
> > should not appear in menuconfig. Moreover for P1/P2 boards they have
> > nothing with DDR driver, so they should not appear in drivers/ddr.
> > 
> > This change was completely wrong direction, so revert it. It allows to
> > start fixing issues with FLASH, NOR, NAND and CPLD LBC configuration.
> > In current state it is impossible.
> > 
> > See also thread for more details:
> > https://lore.kernel.org/u-boot/20220426181740.o2n7xfg46ytljcdx@pali/t/#u
> > 
> > Signed-off-by: Pali Rohár 
> 
> NAK.  We are not moving things back in to board config headers under
> CONFIG namespace.  Some other solution is required.

I spend time on this and I do not see any other solution. As explained
that commit just introduced more issues then what it brought, so it was
step backward, not forward. So please show other solution, if you do not
like this one.


Re: [PATCH 2/6] Revert "p1_p2_rdb: Remove CONFIG_CPLD_[BO]R_PRELIM"

2022-05-01 Thread Pali Rohár
On Sunday 01 May 2022 10:38:31 Tom Rini wrote:
> On Sun, May 01, 2022 at 04:23:53PM +0200, Pali Rohár wrote:
> 
> > This reverts commit 53fc71df0fce21d403400a9bc1532e08107c.
> > 
> > These macros and their values are required for configuring CPLD memory
> > mapping in LBC. So revert them back.
> > 
> > Signed-off-by: Pali Rohár 
> > ---
> >  include/configs/p1_p2_rdb_pc.h | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> > index 648d941c59b2..9726ef3077f7 100644
> > --- a/include/configs/p1_p2_rdb_pc.h
> > +++ b/include/configs/p1_p2_rdb_pc.h
> > @@ -323,6 +323,9 @@
> >  #define CONFIG_SYS_CPLD_BASE_PHYS  CONFIG_SYS_CPLD_BASE
> >  #endif
> >  /* CPLD config size: 1Mb */
> > +#define CONFIG_CPLD_BR_PRELIM  
> > (BR_PHYS_ADDR(CONFIG_SYS_CPLD_BASE_PHYS) | \
> > +   BR_PS_8 | BR_V)
> > +#define CONFIG_CPLD_OR_PRELIM  (0xfff009f7)
> >  
> >  #define CONFIG_SYS_PMC_BASE0xff98
> >  #define CONFIG_SYS_PMC_BASE_PHYS   CONFIG_SYS_PMC_BASE
> 
> I'm missing something.  I don't see anything when I "git grep
> CPLD_.R_PRELIM" so where / how are they referenced?

See other patches in this series. These two macros are used for defining other 
BR/OR macros.


Re: [PATCH 1/6] Revert "Convert CONFIG_SYS_BR0_PRELIM et al to Kconfig"

2022-05-01 Thread Tom Rini
On Sun, May 01, 2022 at 04:23:52PM +0200, Pali Rohár wrote:

> This reverts commit c7fad78ec0ee41b72a58bebb61959570eb937ab1.
> 
> This commit made configuration, understanding, maintenance, debugging and
> future development of the powerpc/mpc85xx Local Bus Controller on P1/P2
> boards impossible.
> 
> All preliminary Base and Option registers depends on other code and C
> macros generated at C compile time and they comes from the other macros.
> 
> For example, NOR base address and NOR options are set via macros
> CONFIG_SYS_FLASH_BR_PRELIM and CONFIG_SYS_FLASH_OR_PRELIM. And then based
> on other logic are filled correct values in to the correct macros
> CONFIG_SYS_BR*_PRELIM and CONFIG_SYS_OR*_PRELIM.
> 
> These config options are not user configurable options and therefore
> should not appear in menuconfig. Moreover for P1/P2 boards they have
> nothing with DDR driver, so they should not appear in drivers/ddr.
> 
> This change was completely wrong direction, so revert it. It allows to
> start fixing issues with FLASH, NOR, NAND and CPLD LBC configuration.
> In current state it is impossible.
> 
> See also thread for more details:
> https://lore.kernel.org/u-boot/20220426181740.o2n7xfg46ytljcdx@pali/t/#u
> 
> Signed-off-by: Pali Rohár 

NAK.  We are not moving things back in to board config headers under
CONFIG namespace.  Some other solution is required.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/6] Revert "p1_p2_rdb: Remove CONFIG_CPLD_[BO]R_PRELIM"

2022-05-01 Thread Tom Rini
On Sun, May 01, 2022 at 04:23:53PM +0200, Pali Rohár wrote:

> This reverts commit 53fc71df0fce21d403400a9bc1532e08107c.
> 
> These macros and their values are required for configuring CPLD memory
> mapping in LBC. So revert them back.
> 
> Signed-off-by: Pali Rohár 
> ---
>  include/configs/p1_p2_rdb_pc.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
> index 648d941c59b2..9726ef3077f7 100644
> --- a/include/configs/p1_p2_rdb_pc.h
> +++ b/include/configs/p1_p2_rdb_pc.h
> @@ -323,6 +323,9 @@
>  #define CONFIG_SYS_CPLD_BASE_PHYSCONFIG_SYS_CPLD_BASE
>  #endif
>  /* CPLD config size: 1Mb */
> +#define CONFIG_CPLD_BR_PRELIM
> (BR_PHYS_ADDR(CONFIG_SYS_CPLD_BASE_PHYS) | \
> + BR_PS_8 | BR_V)
> +#define CONFIG_CPLD_OR_PRELIM(0xfff009f7)
>  
>  #define CONFIG_SYS_PMC_BASE  0xff98
>  #define CONFIG_SYS_PMC_BASE_PHYS CONFIG_SYS_PMC_BASE

I'm missing something.  I don't see anything when I "git grep
CPLD_.R_PRELIM" so where / how are they referenced?

-- 
Tom


signature.asc
Description: PGP signature


[PATCH 6/6] board: freescale: p1_p2_rdb_pc: Fix size of NAND mapping

2022-05-01 Thread Pali Rohár
P1020RDB-PD has NAND with large page. All other P1/P2 RDB boards have NAND
with small page. According to P1/P2 RM documentation, for NAND with large
page it is needed to use 256 kB mapping and for small page just 32 kB.

Currenly in p1_p2_rdb_pc board code there is a mix of 32 kB and 1 MB
settings which effetively restrict to just 32 kB. Fix this issue and set
TLB, LAW and LBC OR registers which correct mapping size based on the
selected board.

Note that E500 core does not support Book-E page of 32 kB, so choose 64 kB
settings for TLB.

Signed-off-by: Pali Rohár 
---
 board/freescale/p1_p2_rdb_pc/law.c |  4 
 board/freescale/p1_p2_rdb_pc/tlb.c | 11 +--
 include/configs/p1_p2_rdb_pc.h |  4 ++--
 3 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/board/freescale/p1_p2_rdb_pc/law.c 
b/board/freescale/p1_p2_rdb_pc/law.c
index 80adf21a1183..60672d34e11c 100644
--- a/board/freescale/p1_p2_rdb_pc/law.c
+++ b/board/freescale/p1_p2_rdb_pc/law.c
@@ -19,8 +19,12 @@ struct law_entry law_table[] = {
SET_LAW(CONFIG_SYS_FLASH_BASE_PHYS, LAW_SIZE_16M, LAW_TRGT_IF_LBC),
 #endif
 #ifdef CONFIG_SYS_NAND_BASE_PHYS
+#ifdef CONFIG_TARGET_P1020RDB_PD
+   SET_LAW(CONFIG_SYS_NAND_BASE_PHYS, LAW_SIZE_256K, LAW_TRGT_IF_LBC),
+#else
SET_LAW(CONFIG_SYS_NAND_BASE_PHYS, LAW_SIZE_32K, LAW_TRGT_IF_LBC),
 #endif
+#endif
 };
 
 int num_law_entries = ARRAY_SIZE(law_table);
diff --git a/board/freescale/p1_p2_rdb_pc/tlb.c 
b/board/freescale/p1_p2_rdb_pc/tlb.c
index 5bbeae302ad0..a5b80762f0fc 100644
--- a/board/freescale/p1_p2_rdb_pc/tlb.c
+++ b/board/freescale/p1_p2_rdb_pc/tlb.c
@@ -78,10 +78,17 @@ struct fsl_e_tlb_entry tlb_table[] = {
 #endif /* not SPL */
 
 #ifdef CONFIG_SYS_NAND_BASE
-   /* *I*G - NAND */
+#ifdef CONFIG_TARGET_P1020RDB_PD
+   /* *I*G - NAND large page 256K */
SET_TLB_ENTRY(1, CONFIG_SYS_NAND_BASE, CONFIG_SYS_NAND_BASE_PHYS,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
-   0, 7, BOOKE_PAGESZ_1M, 1),
+   0, 7, BOOKE_PAGESZ_256K, 1),
+#else
+   /* *I*G - NAND small page 64K (effective only 32K; e500 does not 
support BOOKE_PAGESZ_32K) */
+   SET_TLB_ENTRY(1, CONFIG_SYS_NAND_BASE, CONFIG_SYS_NAND_BASE_PHYS,
+   MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
+   0, 7, BOOKE_PAGESZ_64K, 1),
+#endif
 #endif
 
 #if defined(CONFIG_SYS_RAMBOOT) || \
diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
index cf84f4045538..2ddf768f2c82 100644
--- a/include/configs/p1_p2_rdb_pc.h
+++ b/include/configs/p1_p2_rdb_pc.h
@@ -214,7 +214,7 @@
  * 0xec00_ 0xefff_ NOR flash   Up to 64M non-cacheable CS0/1
  * 0xf8f8_ 0xf8ff_ L2 SRAM Up to 512K cacheable
  *   (early boot only)
- * 0xff80_ 0xff80_7fff NAND flash  32K non-cacheable   CS1/0
+ * 0xff80_ 0xff83_ NAND flash  32K/256K non-cacheable  CS1/0
  * 0xff98_ 0xff98_ PMC 64K non-cacheable   CS2
  * 0xffa0_ 0xffa1_ CPLD128K non-cacheable  CS3
  * 0xffb0_ 0xffbf_ VSC7385 switch  1M non-cacheableCS2
@@ -283,7 +283,7 @@
| BR_MS_FCM /* MSEL = FCM */ \
| BR_V) /* valid */
 #if defined(CONFIG_TARGET_P1020RDB_PD)
-#define CONFIG_SYS_NAND_OR_PRELIM  (OR_AM_32KB \
+#define CONFIG_SYS_NAND_OR_PRELIM  (OR_AM_256KB \
| OR_FCM_PGS/* Large Page*/ \
| OR_FCM_CSCT \
| OR_FCM_CST \
-- 
2.20.1



[PATCH 1/6] Revert "Convert CONFIG_SYS_BR0_PRELIM et al to Kconfig"

2022-05-01 Thread Pali Rohár
This reverts commit c7fad78ec0ee41b72a58bebb61959570eb937ab1.

This commit made configuration, understanding, maintenance, debugging and
future development of the powerpc/mpc85xx Local Bus Controller on P1/P2
boards impossible.

All preliminary Base and Option registers depends on other code and C
macros generated at C compile time and they comes from the other macros.

For example, NOR base address and NOR options are set via macros
CONFIG_SYS_FLASH_BR_PRELIM and CONFIG_SYS_FLASH_OR_PRELIM. And then based
on other logic are filled correct values in to the correct macros
CONFIG_SYS_BR*_PRELIM and CONFIG_SYS_OR*_PRELIM.

These config options are not user configurable options and therefore
should not appear in menuconfig. Moreover for P1/P2 boards they have
nothing with DDR driver, so they should not appear in drivers/ddr.

This change was completely wrong direction, so revert it. It allows to
start fixing issues with FLASH, NOR, NAND and CPLD LBC configuration.
In current state it is impossible.

See also thread for more details:
https://lore.kernel.org/u-boot/20220426181740.o2n7xfg46ytljcdx@pali/t/#u

Signed-off-by: Pali Rohár 
---
 README   |  11 ++
 arch/powerpc/cpu/mpc83xx/elbc/elbc.h | 170 +++
 arch/powerpc/cpu/mpc8xx/Kconfig  |  85 ++
 configs/M5272C3_defconfig|  24 ---
 configs/MCR3000_defconfig|  47 +++--
 configs/MPC837XERDB_defconfig|   9 -
 configs/MPC8548CDS_36BIT_defconfig   |  12 --
 configs/MPC8548CDS_defconfig |  12 --
 configs/MPC8548CDS_legacy_defconfig  |  12 --
 configs/P1020RDB-PC_36BIT_NAND_defconfig |  12 --
 configs/P1020RDB-PC_36BIT_SDCARD_defconfig   |   9 -
 configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig |   9 -
 configs/P1020RDB-PC_36BIT_defconfig  |   9 -
 configs/P1020RDB-PC_NAND_defconfig   |  12 --
 configs/P1020RDB-PC_SDCARD_defconfig |   9 -
 configs/P1020RDB-PC_SPIFLASH_defconfig   |   9 -
 configs/P1020RDB-PC_defconfig|   9 -
 configs/P1020RDB-PD_NAND_defconfig   |  12 --
 configs/P1020RDB-PD_SDCARD_defconfig |   9 -
 configs/P1020RDB-PD_SPIFLASH_defconfig   |   9 -
 configs/P1020RDB-PD_defconfig|   9 -
 configs/P2020RDB-PC_36BIT_NAND_defconfig |  12 --
 configs/P2020RDB-PC_36BIT_SDCARD_defconfig   |   9 -
 configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig |   9 -
 configs/P2020RDB-PC_36BIT_defconfig  |   9 -
 configs/P2020RDB-PC_NAND_defconfig   |  12 --
 configs/P2020RDB-PC_SDCARD_defconfig |   9 -
 configs/P2020RDB-PC_SPIFLASH_defconfig   |   9 -
 configs/P2020RDB-PC_defconfig|   9 -
 configs/P2041RDB_NAND_defconfig  |   9 -
 configs/P2041RDB_SDCARD_defconfig|   6 -
 configs/P2041RDB_SPIFLASH_defconfig  |   6 -
 configs/P2041RDB_defconfig   |   6 -
 configs/P3041DS_NAND_defconfig   |  12 --
 configs/P3041DS_SDCARD_defconfig |   9 -
 configs/P3041DS_SPIFLASH_defconfig   |   9 -
 configs/P3041DS_defconfig|   9 -
 configs/P4080DS_SDCARD_defconfig |   9 -
 configs/P4080DS_SPIFLASH_defconfig   |   9 -
 configs/P4080DS_defconfig|   9 -
 configs/P5040DS_NAND_defconfig   |  12 --
 configs/P5040DS_SDCARD_defconfig |   9 -
 configs/P5040DS_SPIFLASH_defconfig   |   9 -
 configs/P5040DS_defconfig|   9 -
 configs/cobra5272_defconfig  |  24 ---
 configs/gazerbeam_defconfig  |   9 -
 configs/ids8313_defconfig|  12 --
 configs/kmcoge5ne_defconfig  |  12 --
 configs/kmeter1_defconfig|   9 -
 configs/kmopti2_defconfig|  12 --
 configs/kmsupx5_defconfig|   9 -
 configs/kmtegr1_defconfig|   9 -
 configs/kmtepr2_defconfig|  12 --
 configs/socrates_defconfig   |  12 --
 configs/tuge1_defconfig  |   9 -
 configs/tuxx1_defconfig  |  12 --
 drivers/ddr/fsl/Kconfig  |  92 --
 include/configs/M5272C3.h|  20 +++
 include/configs/MPC8548CDS.h |  17 ++
 include/configs/P2041RDB.h   |  18 ++
 include/configs/cobra5272.h  |  30 
 include/configs/corenet_ds.h |  22 +++
 include/configs/p1_p2_rdb_pc.h   |  19 +++
 include/configs/socrates.h   |   9 +
 scripts/config_whitelist.txt |  18 ++
 65 files changed, 442 insertions(+), 653 deletions(-)

diff --git a/README b/README
index b7ab6e50708d..dbea360bbf70 100644
--- a/README
+++ b/README
@@ -2233,6 +2233,17 @@ Low Level (hardware related) configuration options:
 - CONFIG_SYS_MAMR_PTA:

[PATCH 3/6] mpc85xx: Replace magic values in BR/OR PRELIM config options by proper C macros

2022-05-01 Thread Pali Rohár
This change allows to understand how are Preliminary Base and Option
registers configured and later fix improper configuration.

Signed-off-by: Pali Rohár 
---
 include/configs/P2041RDB.h |  7 ---
 include/configs/corenet_ds.h   |  8 +---
 include/configs/p1_p2_rdb_pc.h | 11 ---
 3 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/include/configs/P2041RDB.h b/include/configs/P2041RDB.h
index 687b88bd2abd..c2d7c76f6063 100644
--- a/include/configs/P2041RDB.h
+++ b/include/configs/P2041RDB.h
@@ -118,7 +118,8 @@
(BR_PHYS_ADDR((CONFIG_SYS_FLASH_BASE_PHYS + 0x800)) | \
BR_PS_16 | BR_V)
 #define CONFIG_SYS_FLASH_OR_PRELIM \
-   ((0xf8000ff7 & ~OR_GPCM_SCY & ~OR_GPCM_EHTR) \
+   (OR_AM_128MB | OR_GPCM_CSNT | OR_GPCM_ACS_DIV2 \
+| OR_GPCM_XACS | OR_GPCM_TRLX | OR_GPCM_EAD \
 | OR_GPCM_SCY_8 | OR_GPCM_EHTR_CLEAR)
 
 #define CONFIG_FSL_CPLD
@@ -162,11 +163,11 @@
 
 /* NAND flash config */
 #define CONFIG_SYS_NAND_BR_PRELIM  (BR_PHYS_ADDR(CONFIG_SYS_NAND_BASE_PHYS) \
-  | (2<

[PATCH 5/6] board: freescale: p1_p2_rdb_pc: Fix size of FLASH NOR mapping

2022-05-01 Thread Pali Rohár
FLASH NOR on P1020RDB-PD has size of 64 MB. On all other P1/P2 RDB boards
it has only size of 16 MB. So fix this size in TLB, LAW and LBC OR
registers.

Signed-off-by: Pali Rohár 
---
 board/freescale/p1_p2_rdb_pc/law.c | 4 
 board/freescale/p1_p2_rdb_pc/tlb.c | 6 ++
 include/configs/p1_p2_rdb_pc.h | 7 +++
 3 files changed, 17 insertions(+)

diff --git a/board/freescale/p1_p2_rdb_pc/law.c 
b/board/freescale/p1_p2_rdb_pc/law.c
index 901145ded3b0..80adf21a1183 100644
--- a/board/freescale/p1_p2_rdb_pc/law.c
+++ b/board/freescale/p1_p2_rdb_pc/law.c
@@ -13,7 +13,11 @@ struct law_entry law_table[] = {
 #ifdef CONFIG_VSC7385_ENET
SET_LAW(CONFIG_SYS_VSC7385_BASE_PHYS, LAW_SIZE_1M, LAW_TRGT_IF_LBC),
 #endif
+#ifdef CONFIG_TARGET_P1020RDB_PD
SET_LAW(CONFIG_SYS_FLASH_BASE_PHYS, LAW_SIZE_64M, LAW_TRGT_IF_LBC),
+#else
+   SET_LAW(CONFIG_SYS_FLASH_BASE_PHYS, LAW_SIZE_16M, LAW_TRGT_IF_LBC),
+#endif
 #ifdef CONFIG_SYS_NAND_BASE_PHYS
SET_LAW(CONFIG_SYS_NAND_BASE_PHYS, LAW_SIZE_32K, LAW_TRGT_IF_LBC),
 #endif
diff --git a/board/freescale/p1_p2_rdb_pc/tlb.c 
b/board/freescale/p1_p2_rdb_pc/tlb.c
index ca47e15067a4..5bbeae302ad0 100644
--- a/board/freescale/p1_p2_rdb_pc/tlb.c
+++ b/board/freescale/p1_p2_rdb_pc/tlb.c
@@ -39,9 +39,15 @@ struct fsl_e_tlb_entry tlb_table[] = {
 #ifndef CONFIG_SPL_BUILD
/* W**G* - Flash/promjet, localbus */
/* This will be changed to *I*G* after relocation to RAM. */
+#ifdef CONFIG_TARGET_P1020RDB_PD
SET_TLB_ENTRY(1, CONFIG_SYS_FLASH_BASE, CONFIG_SYS_FLASH_BASE_PHYS,
MAS3_SX|MAS3_SR, MAS2_W|MAS2_G,
0, 2, BOOKE_PAGESZ_64M, 1),
+#else
+   SET_TLB_ENTRY(1, CONFIG_SYS_FLASH_BASE, CONFIG_SYS_FLASH_BASE_PHYS,
+   MAS3_SX|MAS3_SR, MAS2_W|MAS2_G,
+   0, 2, BOOKE_PAGESZ_16M, 1),
+#endif
 
 #ifdef CONFIG_PCI
/* *I*G* - PCI memory 1.5G */
diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
index 69fbb4ad8fe4..cf84f4045538 100644
--- a/include/configs/p1_p2_rdb_pc.h
+++ b/include/configs/p1_p2_rdb_pc.h
@@ -243,10 +243,17 @@
 #define CONFIG_FLASH_BR_PRELIM (BR_PHYS_ADDR(CONFIG_SYS_FLASH_BASE_PHYS) \
| BR_PS_16 | BR_V)
 
+#if defined(CONFIG_TARGET_P1020RDB_PD)
 #define CONFIG_FLASH_OR_PRELIM (OR_AM_64MB | OR_GPCM_CSNT | \
 OR_GPCM_ACS_DIV2 | OR_GPCM_XACS | \
 OR_GPCM_SCY_15 | OR_GPCM_TRLX | \
 OR_GPCM_EHTR | OR_GPCM_EAD)
+#else
+#define CONFIG_FLASH_OR_PRELIM (OR_AM_16MB | OR_GPCM_CSNT | \
+OR_GPCM_ACS_DIV2 | OR_GPCM_XACS | \
+OR_GPCM_SCY_15 | OR_GPCM_TRLX | \
+OR_GPCM_EHTR | OR_GPCM_EAD)
+#endif
 
 #define CONFIG_SYS_FLASH_BANKS_LIST{CONFIG_SYS_FLASH_BASE_PHYS}
 #define CONFIG_SYS_FLASH_QUIET_TEST
-- 
2.20.1



[PATCH 2/6] Revert "p1_p2_rdb: Remove CONFIG_CPLD_[BO]R_PRELIM"

2022-05-01 Thread Pali Rohár
This reverts commit 53fc71df0fce21d403400a9bc1532e08107c.

These macros and their values are required for configuring CPLD memory
mapping in LBC. So revert them back.

Signed-off-by: Pali Rohár 
---
 include/configs/p1_p2_rdb_pc.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
index 648d941c59b2..9726ef3077f7 100644
--- a/include/configs/p1_p2_rdb_pc.h
+++ b/include/configs/p1_p2_rdb_pc.h
@@ -323,6 +323,9 @@
 #define CONFIG_SYS_CPLD_BASE_PHYS  CONFIG_SYS_CPLD_BASE
 #endif
 /* CPLD config size: 1Mb */
+#define CONFIG_CPLD_BR_PRELIM  (BR_PHYS_ADDR(CONFIG_SYS_CPLD_BASE_PHYS) | \
+   BR_PS_8 | BR_V)
+#define CONFIG_CPLD_OR_PRELIM  (0xfff009f7)
 
 #define CONFIG_SYS_PMC_BASE0xff98
 #define CONFIG_SYS_PMC_BASE_PHYS   CONFIG_SYS_PMC_BASE
-- 
2.20.1



[PATCH 4/6] board: freescale: p1_p2_rdb_pc: Fix size of CPLD mapping

2022-05-01 Thread Pali Rohár
Per Freescale P1021RDB Combo board CPLD Specification V4.2, CPLD memory
space on all these P1/P2 RDB-PC boards, which use Lattice FPGA for CPLD
implementation, is only 128 kB long.

So decrease mapping size from 1 MB to 128 kB.

Note that E500 core, which is on P1/P2 boards does not support Book-E page
size of 128 kB. It ignores lowest bit in size definition, so macro
BOOKE_PAGESZ_128K has same effect as BOOKE_PAGESZ_64K. Therefore for TLB
entry use BOOKE_PAGESZ_256K to cover whole 128 kB of CPLD memory space.

Signed-off-by: Pali Rohár 
---
 board/freescale/p1_p2_rdb_pc/law.c | 2 +-
 board/freescale/p1_p2_rdb_pc/tlb.c | 3 ++-
 include/configs/p1_p2_rdb_pc.h | 6 +++---
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/board/freescale/p1_p2_rdb_pc/law.c 
b/board/freescale/p1_p2_rdb_pc/law.c
index 5f4d713ca569..901145ded3b0 100644
--- a/board/freescale/p1_p2_rdb_pc/law.c
+++ b/board/freescale/p1_p2_rdb_pc/law.c
@@ -8,7 +8,7 @@
 #include 
 
 struct law_entry law_table[] = {
-   SET_LAW(CONFIG_SYS_CPLD_BASE_PHYS, LAW_SIZE_1M, LAW_TRGT_IF_LBC),
+   SET_LAW(CONFIG_SYS_CPLD_BASE_PHYS, LAW_SIZE_128K, LAW_TRGT_IF_LBC),
SET_LAW(CONFIG_SYS_PMC_BASE_PHYS, LAW_SIZE_64K, LAW_TRGT_IF_LBC),
 #ifdef CONFIG_VSC7385_ENET
SET_LAW(CONFIG_SYS_VSC7385_BASE_PHYS, LAW_SIZE_1M, LAW_TRGT_IF_LBC),
diff --git a/board/freescale/p1_p2_rdb_pc/tlb.c 
b/board/freescale/p1_p2_rdb_pc/tlb.c
index 5931ec650bd8..ca47e15067a4 100644
--- a/board/freescale/p1_p2_rdb_pc/tlb.c
+++ b/board/freescale/p1_p2_rdb_pc/tlb.c
@@ -62,9 +62,10 @@ struct fsl_e_tlb_entry tlb_table[] = {
0, 5, BOOKE_PAGESZ_1M, 1),
 #endif
 
+   /* *I*G - CPLD 256K (effective only 128K; e500 does not support 
BOOKE_PAGESZ_128K) */
SET_TLB_ENTRY(1, CONFIG_SYS_CPLD_BASE, CONFIG_SYS_CPLD_BASE_PHYS,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
-   0, 6, BOOKE_PAGESZ_1M, 1),
+   0, 6, BOOKE_PAGESZ_256K, 1),
SET_TLB_ENTRY(1, CONFIG_SYS_PMC_BASE, CONFIG_SYS_PMC_BASE_PHYS,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 10, BOOKE_PAGESZ_64K, 1),
diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
index b567eb1a03cc..69fbb4ad8fe4 100644
--- a/include/configs/p1_p2_rdb_pc.h
+++ b/include/configs/p1_p2_rdb_pc.h
@@ -216,7 +216,7 @@
  *   (early boot only)
  * 0xff80_ 0xff80_7fff NAND flash  32K non-cacheable   CS1/0
  * 0xff98_ 0xff98_ PMC 64K non-cacheable   CS2
- * 0xffa0_ 0xffaf_ CPLD1M non-cacheableCS3
+ * 0xffa0_ 0xffa1_ CPLD128K non-cacheable  CS3
  * 0xffb0_ 0xffbf_ VSC7385 switch  1M non-cacheableCS2
  * 0xffc0_ 0xffc3_ PCI IO range256k non-cacheable
  * 0xffd0_ 0xffd0_3fff L1 for stack16K cacheable
@@ -325,10 +325,10 @@
 #else
 #define CONFIG_SYS_CPLD_BASE_PHYS  CONFIG_SYS_CPLD_BASE
 #endif
-/* CPLD config size: 1Mb */
+/* CPLD config size: 128 kB */
 #define CONFIG_CPLD_BR_PRELIM  (BR_PHYS_ADDR(CONFIG_SYS_CPLD_BASE_PHYS) | \
BR_PS_8 | BR_V)
-#define CONFIG_CPLD_OR_PRELIM  (OR_AM_1MB | OR_GPCM_CSNT | OR_GPCM_XACS | \
+#define CONFIG_CPLD_OR_PRELIM  (OR_AM_128KB | OR_GPCM_CSNT | OR_GPCM_XACS | \
OR_GPCM_SCY_15 | OR_GPCM_TRLX | \
OR_GPCM_EHTR | OR_GPCM_EAD)
 
-- 
2.20.1



[PATCH 0/6] board: freescale: p1_p2_rdb_pc: Fix sizes of LBC peripherals

2022-05-01 Thread Pali Rohár
On LBC (Local Bus Controller) are connected memory peripherals (NOR,
NAND, CPLD). Fix size mappings of all these peripherals. Size needs to
be correctly set in TLB, LAW and LBC OR registers. Use named macros for
human readable configuration.

Pali Rohár (6):
  Revert "Convert CONFIG_SYS_BR0_PRELIM et al to Kconfig"
  Revert "p1_p2_rdb: Remove CONFIG_CPLD_[BO]R_PRELIM"
  mpc85xx: Replace magic values in BR/OR PRELIM config options by proper
C macros
  board: freescale: p1_p2_rdb_pc: Fix size of CPLD mapping
  board: freescale: p1_p2_rdb_pc: Fix size of FLASH NOR mapping
  board: freescale: p1_p2_rdb_pc: Fix size of NAND mapping

 README   |  11 ++
 arch/powerpc/cpu/mpc83xx/elbc/elbc.h | 170 +++
 arch/powerpc/cpu/mpc8xx/Kconfig  |  85 ++
 board/freescale/p1_p2_rdb_pc/law.c   |  10 +-
 board/freescale/p1_p2_rdb_pc/tlb.c   |  20 ++-
 configs/M5272C3_defconfig|  24 ---
 configs/MCR3000_defconfig|  47 +++--
 configs/MPC837XERDB_defconfig|   9 -
 configs/MPC8548CDS_36BIT_defconfig   |  12 --
 configs/MPC8548CDS_defconfig |  12 --
 configs/MPC8548CDS_legacy_defconfig  |  12 --
 configs/P1020RDB-PC_36BIT_NAND_defconfig |  12 --
 configs/P1020RDB-PC_36BIT_SDCARD_defconfig   |   9 -
 configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig |   9 -
 configs/P1020RDB-PC_36BIT_defconfig  |   9 -
 configs/P1020RDB-PC_NAND_defconfig   |  12 --
 configs/P1020RDB-PC_SDCARD_defconfig |   9 -
 configs/P1020RDB-PC_SPIFLASH_defconfig   |   9 -
 configs/P1020RDB-PC_defconfig|   9 -
 configs/P1020RDB-PD_NAND_defconfig   |  12 --
 configs/P1020RDB-PD_SDCARD_defconfig |   9 -
 configs/P1020RDB-PD_SPIFLASH_defconfig   |   9 -
 configs/P1020RDB-PD_defconfig|   9 -
 configs/P2020RDB-PC_36BIT_NAND_defconfig |  12 --
 configs/P2020RDB-PC_36BIT_SDCARD_defconfig   |   9 -
 configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig |   9 -
 configs/P2020RDB-PC_36BIT_defconfig  |   9 -
 configs/P2020RDB-PC_NAND_defconfig   |  12 --
 configs/P2020RDB-PC_SDCARD_defconfig |   9 -
 configs/P2020RDB-PC_SPIFLASH_defconfig   |   9 -
 configs/P2020RDB-PC_defconfig|   9 -
 configs/P2041RDB_NAND_defconfig  |   9 -
 configs/P2041RDB_SDCARD_defconfig|   6 -
 configs/P2041RDB_SPIFLASH_defconfig  |   6 -
 configs/P2041RDB_defconfig   |   6 -
 configs/P3041DS_NAND_defconfig   |  12 --
 configs/P3041DS_SDCARD_defconfig |   9 -
 configs/P3041DS_SPIFLASH_defconfig   |   9 -
 configs/P3041DS_defconfig|   9 -
 configs/P4080DS_SDCARD_defconfig |   9 -
 configs/P4080DS_SPIFLASH_defconfig   |   9 -
 configs/P4080DS_defconfig|   9 -
 configs/P5040DS_NAND_defconfig   |  12 --
 configs/P5040DS_SDCARD_defconfig |   9 -
 configs/P5040DS_SPIFLASH_defconfig   |   9 -
 configs/P5040DS_defconfig|   9 -
 configs/cobra5272_defconfig  |  24 ---
 configs/gazerbeam_defconfig  |   9 -
 configs/ids8313_defconfig|  12 --
 configs/kmcoge5ne_defconfig  |  12 --
 configs/kmeter1_defconfig|   9 -
 configs/kmopti2_defconfig|  12 --
 configs/kmsupx5_defconfig|   9 -
 configs/kmtegr1_defconfig|   9 -
 configs/kmtepr2_defconfig|  12 --
 configs/socrates_defconfig   |  12 --
 configs/tuge1_defconfig  |   9 -
 configs/tuxx1_defconfig  |  12 --
 drivers/ddr/fsl/Kconfig  |  92 --
 include/configs/M5272C3.h|  20 +++
 include/configs/MPC8548CDS.h |  17 ++
 include/configs/P2041RDB.h   |  25 ++-
 include/configs/cobra5272.h  |  30 
 include/configs/corenet_ds.h |  30 +++-
 include/configs/p1_p2_rdb_pc.h   |  46 -
 include/configs/socrates.h   |   9 +
 scripts/config_whitelist.txt |  18 ++
 67 files changed, 498 insertions(+), 669 deletions(-)

-- 
2.20.1



Re: [PATCH v3 00/15] Add support for MediaTek MT7621 SoC

2022-05-01 Thread Tom Rini
On Sat, Apr 30, 2022 at 03:48:04PM +0200, Marek Behún wrote:
> On Sat, 30 Apr 2022 21:31:15 +0800
> Weijie Gao  wrote:
> 
> > On Fri, 2022-04-29 at 17:13 +0200, Marek Behún wrote:
> > > On Fri, 29 Apr 2022 15:59:44 +0800
> > > Weijie Gao  wrote:
> > >   
> > > > On Fri, 2022-04-29 at 08:15 +0200, Stefan Roese wrote:  
> > > > > Hi Weijie
> > > > > 
> > > > > On 4/29/22 03:23, Weijie Gao wrote:
> > > > > > Hi Marek,
> > > > > > 
> > > > > > Yes. MT7621 does need such a proprietary binary for DDR
> > > > > > initialization
> > > > > > and calibration. That's why I submit only the ram-bootable part
> > > > > > here.
> > > > > > 
> > > > > > I'm considering to create a preloader to load and run DDR
> > > > > > init&calib
> > > > > > binary and ram-bootable u-boot image. The ram-bootable u-boot
> > > > > > image
> > > > > > can be appended to the proloader to form the flash-bootable
> > > > > > bootloader.
> > > > > > 
> > > > > > The source code of preloader will be uploaded to github.
> > > > > 
> > > > > Just to be sure: You are not implementing this preloader as an U-
> > > > > Boot
> > > > > SPL loader, as this would conflict with U-Boot's GPL
> > > > > compatibility?
> > > > 
> > > > Yes. Submitting the source code of this binary also violates MTK's
> > > > non-
> > > > disclosure agreement.  
> > > 
> > > Isn't it possible to submit the DDR training code in binary version,
> > > and somehow call into it from SPL?  
> > 
> > It's possible and I've already implemented it. But will u-boot accept
> > binary file?
> 
> U-Boot at least accepts drivers that require proprietary firmware to
> load (bnxt driver, for example).
> 
> I don't know whether a binary firmware can be accepted into the U-Boot
> repository, whether in a separate file or as an u8 array in a .c file,
> but it should at least be possible to make it so that the user can
> compile it thsemsevles to be bundled, i.e. create a Kconfig option that
> configures a path to the firmware. If it is present, it will be
> compiled with DDR training bundled.
> 
> Stefan, Tom, can this be done?
> 
> BTW, Weijie, can I already test this on mt7621 board, also with DDR
> training? Can you send me the patch that adds calling the proprietary
> code?

At the high level, I would make a further disappointed sigh and note the
NXP ddr firmware blobs, the binary blobs we pull in for x86, and all of
the other blobs we bring in today via binman.  Please make use of one of
these otherwise existing mechanics to bring in the required DDR blobs
here.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH 4/5] mx6cuboxi: fixup dtb ethernet phy nodes before booting an OS

2022-05-01 Thread Josua Mayer
SoM revision 1.9 has replaced the ar8035 phy address 0 with an adin1300
at address 1. Because early SoMs had a hardware flaw, the ar8035 can
also appear at address 4 - making it a total of 3 phy nodes in the DTB.

To avoid confusing Linux with probe errors, fixup the dtb to only enable
the phy node that is detected at runtime.

Signed-off-by: Josua Mayer 
---
 board/solidrun/mx6cuboxi/mx6cuboxi.c | 78 
 configs/mx6cuboxi_defconfig  |  1 +
 2 files changed, 79 insertions(+)

diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c 
b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index 6207bf8253..42aa5cb63c 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -1,5 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
+ * Copyright (C) 2022 Josua Mayer 
+ *
  * Copyright (C) 2015 Freescale Semiconductor, Inc.
  *
  * Author: Fabio Estevam 
@@ -39,6 +41,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -407,6 +411,80 @@ out:
return 0;
 }
 
+static int find_ethernet_phy(void)
+{
+   struct mii_dev *bus = NULL;
+   struct phy_device *phydev = NULL;
+   int phy_addr = -ENOENT;
+
+#ifdef CONFIG_FEC_MXC
+   bus = fec_get_miibus(ENET_BASE_ADDR, -1);
+   if (!bus)
+   return -ENOENT;
+
+   // scan address 0, 1, 4
+   phydev = phy_find_by_mask(bus, 0b00010011);
+   if (!phydev) {
+   free(bus);
+   return -ENOENT;
+   }
+   pr_debug("%s: detected ethernet phy at address %d\n", __func__, 
phydev->addr);
+   phy_addr = phydev->addr;
+
+   free(phydev);
+#endif
+
+   return phy_addr;
+}
+
+#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
+/*
+ * Configure the correct ethernet PHYs nodes in device-tree:
+ * - AR8035 at addresses 0 or 4: Cubox
+ * - AR8035 at address 0: HummingBoard, HummingBoard 2
+ * - ADIN1300 at address 1: since SoM rev 1.9
+ */
+int ft_board_setup(void *fdt, struct bd_info *bd)
+{
+   int node_phy0, node_phy1, node_phy4;
+   int ret, phy;
+   bool enable_phy0 = false, enable_phy1 = false, enable_phy4 = false;
+
+   // detect phy
+   phy = find_ethernet_phy();
+   if (phy == 0 || phy == 4) {
+   enable_phy0 = true;
+   switch (board_type()) {
+   case CUBOXI:
+   case UNKNOWN:
+   default:
+   enable_phy4 = true;
+   }
+   } else if (phy == 1) {
+   enable_phy1 = true;
+   } else {
+   pr_err("%s: couldn't detect ethernet phy, not patching dtb!\n", 
__func__);
+   return 0;
+   }
+
+   // update all phy nodes status
+   node_phy0 = fdt_path_offset(fdt, 
"/soc/bus@210/ethernet@2188000/mdio/ethernet-phy@0");
+   ret = fdt_setprop_string(fdt, node_phy0, "status", enable_phy0 ? "okay" 
: "disabled");
+   if (ret < 0 && enable_phy0)
+   pr_err("%s: failed to enable ethernet phy at address 0 in 
dtb!\n", __func__);
+   node_phy1 = fdt_path_offset(fdt, 
"/soc/bus@210/ethernet@2188000/mdio/ethernet-phy@1");
+   ret = fdt_setprop_string(fdt, node_phy1, "status", enable_phy1 ? "okay" 
: "disabled");
+   if (ret < 0 && enable_phy1)
+   pr_err("%s: failed to enable ethernet phy at address 1 in 
dtb!\n", __func__);
+   node_phy4 = fdt_path_offset(fdt, 
"/soc/bus@210/ethernet@2188000/mdio/ethernet-phy@4");
+   ret = fdt_setprop_string(fdt, node_phy4, "status", enable_phy4 ? "okay" 
: "disabled");
+   if (ret < 0 && enable_phy4)
+   pr_err("%s: failed to enable ethernet phy at address 4 in 
dtb!\n", __func__);
+
+   return 0;
+}
+#endif
+
 /* Override the default implementation, DT model is not accurate */
 int show_board_info(void)
 {
diff --git a/configs/mx6cuboxi_defconfig b/configs/mx6cuboxi_defconfig
index 1e2e332af9..d3ac8eeeba 100644
--- a/configs/mx6cuboxi_defconfig
+++ b/configs/mx6cuboxi_defconfig
@@ -22,6 +22,7 @@ CONFIG_CMD_HDMIDETECT=y
 CONFIG_AHCI=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_FIT=y
+CONFIG_OF_BOARD_SETUP=y
 CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run distro_bootcmd"
 CONFIG_USE_PREBOOT=y
 CONFIG_PREBOOT="if hdmidet; then usb start; setenv stdin  serial,usbkbd; 
setenv stdout serial,vidconsole; setenv stderr serial,vidconsole; else setenv 
stdin  serial; setenv stdout serial; setenv stderr serial; fi;"
-- 
2.34.1



[PATCH 5/5] mx6cuboxi: enable driver for adin1300 phy

2022-05-01 Thread Josua Mayer
Since SoMs revision 1.9 the ar8038 phy has been replaced by adin1300.
Enable the driver so that the new SoMs have functional networking.

Signed-off-by: Josua Mayer 
---
 configs/mx6cuboxi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/mx6cuboxi_defconfig b/configs/mx6cuboxi_defconfig
index d3ac8eeeba..46634a1727 100644
--- a/configs/mx6cuboxi_defconfig
+++ b/configs/mx6cuboxi_defconfig
@@ -55,6 +55,7 @@ CONFIG_DWC_AHSATA=y
 CONFIG_SPL_SYS_I2C_LEGACY=y
 CONFIG_FSL_USDHC=y
 CONFIG_PHYLIB=y
+CONFIG_PHY_ADIN=y
 CONFIG_PHY_ATHEROS=y
 CONFIG_DM_ETH=y
 CONFIG_FEC_MXC=y
-- 
2.34.1



[PATCH 3/5] ARM: dts: imx6qdl-sr-som: add support for alternate phy addresses

2022-05-01 Thread Josua Mayer
The Cubox has an unstable phy address - which can appear at either
address 0 (intended) or 4 (unintended).

SoM revision 1.9 has replaced the ar8035 phy with an adin1300, which
will always appear at address 1.

Change the reg property of the phy node to the magic value 0x,
which indicates to the generic phy driver that all addresses should be
probed. That allows the same node (which is pinned by phy-handle) to match
either the AR8035 PHY at both possible addresses, as well as the new one
at address 1.
Also add the new adi,phy-output-clock property for enabling the 125MHz
clock used by the fec ethernet controller, as submitted to Linux [1].

Linux solves this problem differently:
For the ar8035 phy it will probe both phy nodes in device-tree in order,
and use the one that succeeds. For the new adin1300 it expects U-Boot to
patch the status field in the DTB before booting

While at it also sync the reset-delay with the upstream Linux dtb.

[1] 
https://patchwork.kernel.org/project/netdevbpf/patch/20220428082848.12191-4-jo...@solid-run.com/

Signed-off-by: Josua Mayer 
---
 arch/arm/dts/imx6qdl-sr-som.dtsi | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/imx6qdl-sr-som.dtsi b/arch/arm/dts/imx6qdl-sr-som.dtsi
index b06577808f..c20bed2721 100644
--- a/arch/arm/dts/imx6qdl-sr-som.dtsi
+++ b/arch/arm/dts/imx6qdl-sr-som.dtsi
@@ -55,7 +55,13 @@
pinctrl-0 = <&pinctrl_microsom_enet_ar8035>;
phy-handle = <&phy>;
phy-mode = "rgmii-id";
-   phy-reset-duration = <2>;
+
+   /*
+* The PHY seems to require a long-enough reset duration to avoid
+* some rare issues where the PHY gets stuck in an inconsistent and
+* non-functional state at boot-up. 10ms proved to be fine .
+*/
+   phy-reset-duration = <10>;
phy-reset-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
status = "okay";
 
@@ -64,8 +70,15 @@
#size-cells = <0>;
 
phy: ethernet-phy@0 {
-   reg = <0>;
+   /*
+* The PHY can appear either:
+* - AR8035: at address 0 or 4
+* - ADIN1300: at address 1
+* Actual address being detected at runtime.
+*/
+   reg = <0x>;
qca,clk-out-frequency = <12500>;
+   adi,phy-output-clock = "125mhz-free-running";
};
};
 };
-- 
2.34.1



[PATCH 2/5] phy: adin: add support for clock output

2022-05-01 Thread Josua Mayer
The ADIN1300 supports generating certain clocks on its GP_CLK pin, as
well as providing the reference clock on CLK25_REF.

Add support for selecting the clock via device-tree properties.

This patch is based on just submitted patches to Linux [1] [2].

[1] 
https://patchwork.kernel.org/project/netdevbpf/patch/20220428082848.12191-2-jo...@solid-run.com/
[2] 
https://patchwork.kernel.org/project/netdevbpf/patch/20220428082848.12191-4-jo...@solid-run.com/

Signed-off-by: Josua Mayer 
---
 drivers/net/phy/adin.c | 46 ++
 1 file changed, 46 insertions(+)

diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
index 2433e76fea..485430b128 100644
--- a/drivers/net/phy/adin.c
+++ b/drivers/net/phy/adin.c
@@ -4,6 +4,7 @@
  *
  * Copyright 2019 Analog Devices Inc.
  * Copyright 2022 Variscite Ltd.
+ * Copyright 2022 Josua Mayer 
  */
 #include 
 #include 
@@ -13,6 +14,16 @@
 #define PHY_ID_ADIN13000x0283bc30
 #define ADIN1300_EXT_REG_PTR   0x10
 #define ADIN1300_EXT_REG_DATA  0x11
+
+#define ADIN1300_GE_CLK_CFG_REG0xff1f
+#define   ADIN1300_GE_CLK_CFG_MASK GENMASK(5, 0)
+#define   ADIN1300_GE_CLK_CFG_RCVR_125 BIT(5)
+#define   ADIN1300_GE_CLK_CFG_FREE_125 BIT(4)
+#define   ADIN1300_GE_CLK_CFG_REF_EN   BIT(3)
+#define   ADIN1300_GE_CLK_CFG_HRT_RCVR BIT(2)
+#define   ADIN1300_GE_CLK_CFG_HRT_FREE BIT(1)
+#define   ADIN1300_GE_CLK_CFG_25   BIT(0)
+
 #define ADIN1300_GE_RGMII_CFG  0xff23
 #define ADIN1300_GE_RGMII_RX_MSK   GENMASK(8, 6)
 #define ADIN1300_GE_RGMII_RX_SEL(x)\
@@ -115,6 +126,37 @@ static int adin_ext_write(struct phy_device *phydev, const 
u32 regnum, const u16
return phy_write(phydev, MDIO_DEVAD_NONE, ADIN1300_EXT_REG_DATA, val);
 }
 
+static int adin_config_clk_out(struct phy_device *phydev)
+{
+   ofnode node = phy_get_ofnode(phydev);
+   const char *val = NULL;
+   u8 sel = 0;
+
+   val = ofnode_read_string(node, "adi,phy-output-clock");
+   if (!val) {
+   /* property not present, do not enable GP_CLK pin */
+   } else if (strcmp(val, "25mhz-reference") == 0) {
+   sel |= ADIN1300_GE_CLK_CFG_25;
+   } else if (strcmp(val, "125mhz-free-running") == 0) {
+   sel |= ADIN1300_GE_CLK_CFG_FREE_125;
+   } else if (strcmp(val, "125mhz-recovered") == 0) {
+   sel |= ADIN1300_GE_CLK_CFG_RCVR_125;
+   } else if (strcmp(val, "adaptive-free-running") == 0) {
+   sel |= ADIN1300_GE_CLK_CFG_HRT_FREE;
+   } else if (strcmp(val, "adaptive-recovered") == 0) {
+   sel |= ADIN1300_GE_CLK_CFG_HRT_RCVR;
+   } else {
+   pr_err("%s: invalid adi,phy-output-clock\n", __func__);
+   return -EINVAL;
+   }
+
+   if (ofnode_read_bool(node, "adi,phy-output-reference-clock"))
+   sel |= ADIN1300_GE_CLK_CFG_REF_EN;
+
+   return adin_ext_write(phydev, ADIN1300_GE_CLK_CFG_REG,
+ ADIN1300_GE_CLK_CFG_MASK & sel);
+}
+
 static int adin_config_rgmii_mode(struct phy_device *phydev)
 {
u16 reg_val;
@@ -168,6 +210,10 @@ static int adin1300_config(struct phy_device *phydev)
 
printf("ADIN1300 PHY detected at addr %d\n", phydev->addr);
 
+   ret = adin_config_clk_out(phydev);
+   if (ret < 0)
+   return ret;
+
ret = adin_config_rgmii_mode(phydev);
 
if (ret < 0)
-- 
2.34.1



[PATCH 1/5] phy: adin: remove broken support for adi, phy-mode-override

2022-05-01 Thread Josua Mayer
The adin_get_phy_mode_override function does not compile, because it is
missing both declaration and implementation of
phy_get_interface_by_name.

Remove the whole function for now, since the missing implementation is
not included in mainline Linux - and thus can not be copied.

Signed-off-by: Josua Mayer 
---
 drivers/net/phy/adin.c | 34 --
 1 file changed, 34 deletions(-)

diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
index cff841ab3d..2433e76fea 100644
--- a/drivers/net/phy/adin.c
+++ b/drivers/net/phy/adin.c
@@ -94,35 +94,6 @@ static u32 adin_get_reg_value(struct phy_device *phydev,
return rc;
 }
 
-/**
- * adin_get_phy_mode_override - Get phy-mode override for adin PHY
- *
- * The function gets phy-mode string from property 'adi,phy-mode-override'
- * and return its index in phy_interface_strings table, or -1 in error case.
- */
-int adin_get_phy_mode_override(struct phy_device *phydev)
-{
-   ofnode node = phy_get_ofnode(phydev);
-   const char *phy_mode_override;
-   const char *prop_phy_mode_override = "adi,phy-mode-override";
-   int override_interface;
-
-   phy_mode_override = ofnode_read_string(node, prop_phy_mode_override);
-   if (!phy_mode_override)
-   return -ENODEV;
-
-   debug("%s: %s = '%s'\n",
- __func__, prop_phy_mode_override, phy_mode_override);
-
-   override_interface = phy_get_interface_by_name(phy_mode_override);
-
-   if (override_interface < 0)
-   printf("%s: %s = '%s' is not valid\n",
-  __func__, prop_phy_mode_override, phy_mode_override);
-
-   return override_interface;
-}
-
 static u16 adin_ext_read(struct phy_device *phydev, const u32 regnum)
 {
u16 val;
@@ -148,11 +119,6 @@ static int adin_config_rgmii_mode(struct phy_device 
*phydev)
 {
u16 reg_val;
u32 val;
-   int phy_mode_override = adin_get_phy_mode_override(phydev);
-
-   if (phy_mode_override >= 0) {
-   phydev->interface = (phy_interface_t) phy_mode_override;
-   }
 
reg_val = adin_ext_read(phydev, ADIN1300_GE_RGMII_CFG);
 
-- 
2.34.1



[PATCH 0/5] mx6cuboxi: add eth support for SoMs revision 1.9+

2022-05-01 Thread Josua Mayer
As of Revision 1.9 the SolidRun i.MX6 SoMs ship with a new PHY - an
ADIN1300 at address 1. This patchset carries many small parts to
facilitate proper operation of the ethernet port in U-Boot as well as
Linux:

1. Fix a compile error in the recently phy driver
2. Add support for configuring the clock output pins to the phy driver
3. update device-tree with support for the neew phy
4. support runtime patching of device-tree for Linux:
   enables only the phy node detected during boot, to avoid
   warning messages during boot.
5. finally enable the phy driver in the cuboxi defconfig

Josua Mayer (5):
  phy: adin: remove broken support for adi,phy-mode-override
  phy: adin: add support for clock output
  ARM: dts: imx6qdl-sr-som: add support for alternate phy addresses
  mx6cuboxi: fixup dtb ethernet phy nodes before booting an OS
  mx6cuboxi: enable driver for adin1300 phy

 arch/arm/dts/imx6qdl-sr-som.dtsi | 17 +-
 board/solidrun/mx6cuboxi/mx6cuboxi.c | 78 +++
 configs/mx6cuboxi_defconfig  |  2 +
 drivers/net/phy/adin.c   | 80 
 4 files changed, 141 insertions(+), 36 deletions(-)

-- 
2.34.1



[PATCH 3/3] board: freescale: p1_p2_rdb_pc: Implement board_reset()

2022-05-01 Thread Pali Rohár
Do board reset via CPLD's system reset register.

Signed-off-by: Pali Rohár 
---
 board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c 
b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
index 24b5ec435e4e..53ff121d3b3d 100644
--- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
+++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
@@ -83,6 +83,12 @@ struct cpld_data {
 #define CPLD_FXS_LED   0x0F
 #define CPLD_SYS_RST   0x00
 
+void board_reset(void)
+{
+   struct cpld_data *cpld_data = (void *)(CONFIG_SYS_CPLD_BASE);
+   out_8(&cpld_data->system_rst, 1);
+}
+
 void board_cpld_init(void)
 {
struct cpld_data *cpld_data = (void *)(CONFIG_SYS_CPLD_BASE);
-- 
2.20.1



[PATCH 1/3] board: freescale: p1_p2_rdb_pc: Add workaround for board reset reboot loop

2022-05-01 Thread Pali Rohár
CPLD's system reset register on P1/P2 RDB boards is not autocleared after
flipping it. If this register is set to one then CPLD triggers reset of CPU
in few ms.

This means that trying to reset board via CPLD system reset register cause
reboot loop. To prevent this reboot loop, the only workaround is to try to
clear CPLD's system reset register as early as possible. U-Boot is already
doing it in its board_early_init_f() function, which seems to be enough as
register is cleared prior CPLD triggers another reset.

But board_early_init_f() is not called from SPL and therefore usage of SPL
can cause reboot loop.

To prevent reboot loop when using SPL, calls board_early_init_f() function
in SPL too. For accessing CPLD memory space it is needed to have CPLD entry
in TLB.

With this change it is possible to trigger board reset via CPLD's system
reset register on P2020 RDB board.

Signed-off-by: Pali Rohár 
---
 board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 10 ++
 board/freescale/p1_p2_rdb_pc/spl.c  |  6 ++
 board/freescale/p1_p2_rdb_pc/tlb.c  |  2 +-
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c 
b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
index 7b168fa091b1..26ea8a525228 100644
--- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
+++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
@@ -91,6 +91,16 @@ void board_cpld_init(void)
out_8(&cpld_data->status_led, CPLD_STATUS_LED);
out_8(&cpld_data->fxo_led, CPLD_FXO_LED);
out_8(&cpld_data->fxs_led, CPLD_FXS_LED);
+
+   /*
+* CPLD's system reset register on P1/P2 RDB boards is not autocleared
+* after flipping it. If this register is set to one then CPLD triggers
+* reset of CPU in few ms.
+*
+* This means that trying to reset board via CPLD system reset register
+* cause reboot loop. To prevent this reboot loop, the only workaround
+* is to try to clear CPLD's system reset register as early as possible.
+*/
out_8(&cpld_data->system_rst, CPLD_SYS_RST);
 }
 
diff --git a/board/freescale/p1_p2_rdb_pc/spl.c 
b/board/freescale/p1_p2_rdb_pc/spl.c
index 22156f2824ec..def28665960d 100644
--- a/board/freescale/p1_p2_rdb_pc/spl.c
+++ b/board/freescale/p1_p2_rdb_pc/spl.c
@@ -31,6 +31,12 @@ void board_init_f(ulong bootflag)
u32 plat_ratio, bus_clk;
ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
 
+   /*
+* Call board_early_init_f() as early as possible as it workarounds
+* reboot loop due to broken CPLD state machine for reset line.
+*/
+   board_early_init_f();
+
console_init_f();
 
/* Set pmuxcr to allow both i2c1 and i2c2 */
diff --git a/board/freescale/p1_p2_rdb_pc/tlb.c 
b/board/freescale/p1_p2_rdb_pc/tlb.c
index 13f3a1edf68d..2d431d6d0d90 100644
--- a/board/freescale/p1_p2_rdb_pc/tlb.c
+++ b/board/freescale/p1_p2_rdb_pc/tlb.c
@@ -61,11 +61,11 @@ struct fsl_e_tlb_entry tlb_table[] = {
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 5, BOOKE_PAGESZ_1M, 1),
 #endif
+#endif /* not SPL */
 
SET_TLB_ENTRY(1, CONFIG_SYS_CPLD_BASE, CONFIG_SYS_CPLD_BASE_PHYS,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 6, BOOKE_PAGESZ_1M, 1),
-#endif /* not SPL */
 
 #ifdef CONFIG_SYS_NAND_BASE
/* *I*G - NAND */
-- 
2.20.1



[PATCH 2/3] board: freescale: p1_p2_rdb_pc: Add workaround for non-working watchdog

2022-05-01 Thread Pali Rohár
If watchdog timer was already set to non-disabled value then it means that
watchdog timer was already activated, has already expired and caused CPU
reset. If this happened then due to CPLD firmware bug, writing to wd_cfg
register has no effect and therefore it is not possible to reactivate
watchdog timer again. Also if CPU was reset via watchdog then some
peripherals like i2c do not work. Watchdog and i2c start working again
after CPU reset via non-watchdog method.

Implement this workaround (reset CPU when it was reset by watchdog) to make
watchdog usable again. Watchdog timer logic on these P1/P2 RDB boards is
connected to CPLD, not to SoC itself.

Signed-off-by: Pali Rohár 
---
 board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c 
b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
index 26ea8a525228..24b5ec435e4e 100644
--- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
+++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
@@ -86,6 +86,7 @@ struct cpld_data {
 void board_cpld_init(void)
 {
struct cpld_data *cpld_data = (void *)(CONFIG_SYS_CPLD_BASE);
+   u8 prev_wd_cfg = in_8(&cpld_data->wd_cfg);
 
out_8(&cpld_data->wd_cfg, CPLD_WD_CFG);
out_8(&cpld_data->status_led, CPLD_STATUS_LED);
@@ -102,6 +103,23 @@ void board_cpld_init(void)
 * is to try to clear CPLD's system reset register as early as possible.
 */
out_8(&cpld_data->system_rst, CPLD_SYS_RST);
+
+   /*
+* If watchdog timer was already set to non-disabled value then it means
+* that watchdog timer was already activated, has already expired and
+* caused CPU reset. If this happened then due to CPLD firmware bug,
+* writing to wd_cfg register has no effect and therefore it is not
+* possible to reactivate watchdog timer again. Also if CPU was reset
+* via watchdog then some peripherals like i2c do not work. Watchdog and
+* i2c start working again after CPU reset via non-watchdog method.
+*
+* So in case watchdog timer register in CPLD was already enabled then
+* disable it in CPLD and reset CPU which cause new boot. Watchdog timer
+* is disabled few lines above, after reading CPLD previous value.
+* This logic (disabling timer before reset) prevents reboot loop.
+*/
+   if (prev_wd_cfg != CPLD_WD_CFG)
+   do_reset(NULL, 0, 0, NULL);
 }
 
 void board_gpio_init(void)
-- 
2.20.1



[PATCH] board: freescale: p1_p2_rdb_pc: Enable TDM function only for P1010

2022-05-01 Thread Pali Rohár
TDM function is supported only on P1010. P2020 does not have PMUXCR_TDM_ENA
register, so do not enable it.

Signed-off-by: Pali Rohár 
---
 board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c 
b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
index e559a77b2dac..2e1aff59b15b 100644
--- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
+++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
@@ -154,7 +154,9 @@ int board_early_init_f(void)
clrbits_be32(&gur->sdhcdcr, SDHCDCR_CD_INV);
 
clrbits_be32(&gur->pmuxcr, MPC85xx_PMUXCR_SD_DATA);
+#if defined(CONFIG_TARGET_P1020RDB_PD) || defined(CONFIG_TARGET_P1020RDB_PC)
setbits_be32(&gur->pmuxcr, MPC85xx_PMUXCR_TDM_ENA);
+#endif
 
board_gpio_init();
board_cpld_init();
-- 
2.20.1



Re: [PATCH 00/12] sunxi: Devicetree sync from Linux v5.18-rc1

2022-05-01 Thread Mark Kettenis
> Date: Sun, 1 May 2022 01:59:21 +0100
> From: Andre Przywara 

Hi Andre,

> On Fri, 29 Apr 2022 21:38:58 -0500
> Samuel Holland  wrote:
> 
> Hi Samuel,
> 
> > On 4/29/22 7:08 PM, Andre Przywara wrote:
> > > On Fri, 29 Apr 2022 14:14:19 -0400
> > > Tom Rini  wrote:
> > > 
> > > Hi,
> > >   
> > >> On Fri, Apr 29, 2022 at 06:05:03PM +0200, Mark Kettenis wrote:  
> >  Date: Fri, 29 Apr 2022 11:31:00 -0400
> >  From: Tom Rini 
> > 
> >  On Fri, Apr 29, 2022 at 04:25:51PM +0100, Andre Przywara wrote:
> > > On Fri, 29 Apr 2022 10:57:10 -0400
> > > Tom Rini  wrote:
> > >
> > > Hi,
> > > 
> > >> On Fri, Apr 29, 2022 at 03:51:59PM +0100, Andre Przywara wrote:
> > >>> On Wed, 27 Apr 2022 15:31:19 -0500
> > >>> Samuel Holland  wrote:
> > >>>
> > >>> Hi Samuel, Tom,
> > >>>   
> >  This series brings all of our devicetrees up to date with Linux.
> > 
> >  Older SoCs (before A83T) have not been synchronized in over 3 
> >  years.
> >  And I don't have any of this hardware to test. But there are not 
> >  major
> >  changes to those devicetrees either.
> > 
> >  The big motivation for including older SoCs in this update is 
> >  converting
> >  the USB PHY driver to get its VBUS detection GPIO/regulator from 
> >  the
> >  devicetree instead of from a pin name in Kconfig. Many older 
> >  boards had
> >  those properties added or fixed since the last devicetree sync. 
> >  This PHY
> >  driver change is necessary to complete the DM_GPIO migration.
> > 
> >  A couple of breaking changes were made to several SoCs' 
> >  devicetrees in
> >  Linux relating to the "r_intc" interrupt controller. New kernels 
> >  support
> >  old devicetrees, but not the other way around. So to be most 
> >  compatible
> >  and avoid regressions, those changes are skipped here.  
> > >>>
> > >>> Many thanks for considering this! I just skimmed over the A64 and H6
> > >>> patches, and this is indeed the only difference.
> > >>>
> > >>> But while I love this pragmatic approach, and would be happy to 
> > >>> take this,
> > >>> this goes against our own rules, and more importantly against Tom's 
> > >>> one's:
> > >>> to take only direct DT file copies from the kernel tree.
> > >>>
> > >>> Tom, can you give your opinion here? As Samuel mentioned above, the
> > >>> current mainline DTs wouldn't boot on older kernels (the changes 
> > >>> affect
> > >>> critical devices), so this spoils stable distro and installer 
> > >>> kernels,
> > >>> when using $fdtcontroladdr, for instance when booting via UEFI.
> > >>>
> > >>> As a side effect of always defining SYS_SOC to "sunxi", we cannot 
> > >>> easily
> > >>> use per-SoC DT overrides using sun50i-a64-u-boot.dtsi, for instance.
> > >>>
> > >>> For context, those changed properties were in the mainline kernel 
> > >>> tree at
> > >>> some point, but have been amended since. So it's not some random 
> > >>> change.  
> > >>
> > >> So, this is I guess a bit annoying.  But, we aren't at the point 
> > >> where
> > >> the common use case is the downstream OS using the DTB we've loaded 
> > >> and
> > >> are using, are we?  I mean, we can't be, as ours are so far out of 
> > >> date,
> > >> so this will only be an option when we use a recent DT ourself.  So 
> > >> we
> > >> should be able to sync in the changes and update our code, as they 
> > >> can't
> > >> be using $fdtcontroladdr in this case, right?  Or am I missing the 
> > >> use
> > >> case that's in the wild atm?  Thanks!
> > >
> > > While it sounds like the DTs are wildly out of date, this mostly 
> > > affects
> > > secondary functionality. The mainline updates for the 64-bit SoCs are:
> > > - H6: adding the VP9 video h/w codec and an additional wakeup timer
> > > - A64: adding GPU DVFS, adding DRAM DVFS, add support for secondary
> > > digital audio interfaces, plus the wakeup timer
> > > Also there are cosmetic changes, like changing node names to make them
> > > binding compliant.  
> > 
> > The SoCs where the DTs are wildly out of date (v4.18-rc3) are:
> > A10 A10s/A13 A31 A20 A80 A23/A33 A83T
> > 
> > The SoCs with the r_intc binding change are:
> > A31 A23/A33 A83T A64 H3/H5 H6
> > 
> > For the SoCs which are in both lists, yes, it is unlikely that anyone is 
> > using
> > $fdtcontroladdr for Linux. So we could probably fully update those DTs. That
> > leaves just A64, H3/H5, and H6 which would temporarily need to exclude the
> > r_intc-related changes.
> 
> Yes, I don't really care about those older SoCs, devices using them are
> probably not really distro / UEFI ma

Re: [RFC 2/3] serial: mxc: Enable getting and enabling clocks with CCF Composite

2022-05-01 Thread Peng Fan (OSS)




On 2022/5/1 0:14, Adam Ford wrote:

Certain platforms have the UART clocks exposed through the CCF.
When they are, it's possible to enable and query the clock(s)
for a given UART. Add support getting, enabling, and querying
the clocks.

Signed-off-by: Adam Ford 

diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index e4970a169b..c68040ba74 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -10,6 +10,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -266,8 +267,13 @@ __weak struct serial_device *default_serial_console(void)
  int mxc_serial_setbrg(struct udevice *dev, int baudrate)
  {
struct mxc_serial_plat *plat = dev_get_plat(dev);
-   u32 clk = imx_get_uartclk();
+   u32 clk;
  
+#if CONFIG_IS_ENABLED(CLK_COMPOSITE_CCF)


CONFIG_IS_ENABLED(CLK) should be fine.


+clk = clk_get_rate(&plat->ipg_clk);
+#else
+   clk = imx_get_uartclk;


"()" should not be dropped.


+#endif
_mxc_serial_setbrg(plat->reg, clk, baudrate, plat->use_dte);
  
  	return 0;

@@ -277,6 +283,22 @@ static int mxc_serial_probe(struct udevice *dev)
  {
struct mxc_serial_plat *plat = dev_get_plat(dev);
  
+#if CONFIG_IS_ENABLED(CLK_COMPOSITE_CCF)


Ditto


+   int ret = 0;
+
+   ret = clk_enable(&plat->per_clk);
+   if (ret) {
+   printf("Failed to enable per_clk\n");
+   return ret;
+   }
+
+   ret = clk_enable(&plat->per_clk);


ipg_clk?


+   if (ret) {
+   printf("Failed to enable ipg_clk\n");
+   return ret;
+   }
+
+#endif
_mxc_serial_init(plat->reg, plat->use_dte);
  
  	return 0;

@@ -339,6 +361,21 @@ static int mxc_serial_of_to_plat(struct udevice *dev)
  
  	plat->use_dte = fdtdec_get_bool(gd->fdt_blob, dev_of_offset(dev),

"fsl,dte-mode");
+#if CONFIG_IS_ENABLED(CLK_COMPOSITE_CCF)
+   int ret = 0;
+
+   ret = clk_get_by_name(dev, "per", &plat->per_clk);
+   if (ret) {
+   printf("Failed to get per_clk\n");
+   return ret;
+   }
+
+   ret = clk_get_by_name(dev, "ipg", &plat->ipg_clk);
+   if (ret) {
+   printf("Failed to get per_clk\n");
+   return ret;
+   }
+#endif


Regards,
Peng.


return 0;
  }
  
diff --git a/include/dm/platform_data/serial_mxc.h b/include/dm/platform_data/serial_mxc.h

index cc59eeb1dd..9a8c8498bf 100644
--- a/include/dm/platform_data/serial_mxc.h
+++ b/include/dm/platform_data/serial_mxc.h
@@ -10,6 +10,8 @@
  struct mxc_serial_plat {
struct mxc_uart *reg;  /* address of registers in physical memory */
bool use_dte;
+   struct clk per_clk;
+   struct clk ipg_clk;
  };
  
  #endif




Re: [PATCH 2/3] imx: imx8mq: default select CLK_IMX8MQ

2022-05-01 Thread Peng Fan (OSS)




On 2022/4/30 21:49, Adam Ford wrote:

On Fri, Apr 29, 2022 at 2:20 AM Peng Fan (OSS)  wrote:


From: Peng Fan 

Since the power domain driver default select CONFIG_CLK, so we will
meet lots failures without CLK_IMX8MQ, so default select it.



There is a related patch [1] that I submitted for all imx8m SoC's t
select their respective CLK_IMX8M[MNPQ]


Actually default select CLK_IMX8MQ will not make i.MX8MQ bootable,
patch 1 in this patchset still needed. If possible, you could take
my patch 1 in your patchset and drop patch 2 in this patchset.

Thanks,
Peng.



adam

[1] - 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F20220417221647.2390750-1-aford173%40gmail.com%2F&data=05%7C01%7Cpeng.fan%40nxp.com%7C48339c3e1efe45476e6d08da2ab04211%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637869233759129025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wZCdJR%2BVf%2BpeBkq%2BtGA%2FcXkxY5GUPUfU%2FeyPtrc%2Bpn0%3D&reserved=0


Fixes: commit 4eb82c2e56a7c ("imx: power-domain: Get rid of SMCCC dependency")
Signed-off-by: Peng Fan 
---
  arch/arm/mach-imx/imx8m/Kconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig
index 24299ae037f..7f23d687be3 100644
--- a/arch/arm/mach-imx/imx8m/Kconfig
+++ b/arch/arm/mach-imx/imx8m/Kconfig
@@ -8,6 +8,7 @@ config IMX8M
  config IMX8MQ
 bool
 select IMX8M
+   select CLK_IMX8MQ

  config IMX8MM
 bool
--
2.36.0



[PATCH 1/1] efi_selftest: error handling in efi_selftest_tcg2

2022-05-01 Thread Heinrich Schuchardt
If memory allocation fails, write an error message.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_selftest/efi_selftest_tcg2.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/lib/efi_selftest/efi_selftest_tcg2.c 
b/lib/efi_selftest/efi_selftest_tcg2.c
index a2b4a79e9b..67a886efaa 100644
--- a/lib/efi_selftest/efi_selftest_tcg2.c
+++ b/lib/efi_selftest/efi_selftest_tcg2.c
@@ -631,8 +631,10 @@ static int efi_st_tcg2_setup(const efi_handle_t img_handle,
  sizeof(struct efi_tcg2_event) +
  sizeof(struct uefi_image_load_event),
  (void **)&efi_tcg2_event);
-   if (!efi_tcg2_event)
+   if (ret != EFI_SUCCESS) {
+   efi_st_error("Out of memory\n");
return EFI_ST_FAILURE;
+   }
 
efi_tcg2_event->size = sizeof(struct efi_tcg2_event) +
   sizeof(struct uefi_image_load_event);
@@ -659,8 +661,10 @@ static int efi_st_tcg2_setup(const efi_handle_t img_handle,
  (EFI_TCG2_MAX_PCR_INDEX + 1) *
  TPM2_SHA256_DIGEST_SIZE,
  (void **)&pcrs);
-   if (!pcrs)
+   if (ret != EFI_SUCCESS) {
+   efi_st_error("Out of memory\n");
return EFI_ST_FAILURE;
+   }
 
boottime->set_mem(pcrs, (EFI_TCG2_MAX_PCR_INDEX + 1) * 
TPM2_SHA256_DIGEST_SIZE, 0);
 
-- 
2.34.1



[PATCH 1/1] efi_selftest: clean up unaligned unit test

2022-05-01 Thread Heinrich Schuchardt
* fix typo %s/give/given/
* don't use void * in pointer arithmetic

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_selftest/efi_selftest_unaligned.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/lib/efi_selftest/efi_selftest_unaligned.c 
b/lib/efi_selftest/efi_selftest_unaligned.c
index 6fce110b76..7c6bf2d6e8 100644
--- a/lib/efi_selftest/efi_selftest_unaligned.c
+++ b/lib/efi_selftest/efi_selftest_unaligned.c
@@ -14,14 +14,14 @@ struct aligned_buffer {
 };
 
 /*
- * Return an u32 at a give address.
+ * Return an u32 at a given address.
  * If the address is not four byte aligned, an unaligned memory access
  * occurs.
  *
  * @addr:  address to read
  * Return: value at the address
  */
-static inline u32 deref(u32 *addr)
+static inline u32 deref(void *addr)
 {
int ret;
 
@@ -43,12 +43,11 @@ static int execute(void)
 {
struct aligned_buffer buf = {
{0, 1, 2, 3, 4, 5, 6, 7},
-   };
-   void *v = &buf;
+   };
u32 r = 0;
 
/* Read an unaligned address */
-   r = deref(v + 1);
+   r = deref(&buf.a[1]);
 
/* UEFI only supports low endian systems */
if (r != 0x04030201) {
-- 
2.34.1



[PATCH 1/1] efi_selftest: buildefi_selftest_unaligned.c

2022-05-01 Thread Heinrich Schuchardt
The unit test has not been built since CPU_V7 was rename CPU_V7A.

Fixes: acf1500138bb ("arm: v7: Kconfig: Rename CPU_V7 as CPU_V7A")
Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_selftest/Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
index be8040d1c7..33536c9ec0 100644
--- a/lib/efi_selftest/Makefile
+++ b/lib/efi_selftest/Makefile
@@ -55,7 +55,9 @@ obj-$(CONFIG_EFI_DEVICE_PATH_TO_TEXT) += 
efi_selftest_devicepath.o
 obj-$(CONFIG_EFI_UNICODE_COLLATION_PROTOCOL2) += \
 efi_selftest_unicode_collation.o
 
-obj-$(CONFIG_CPU_V7) += efi_selftest_unaligned.o
+ifeq ($(CONFIG_CPU_V7A)$(CONFIG_CPU_V7M)$(CONFIG_CPU_V7R),y)
+obj-y += efi_selftest_unaligned.o
+endif
 obj-$(CONFIG_EFI_LOADER_HII) += efi_selftest_hii.o
 obj-$(CONFIG_EFI_RNG_PROTOCOL) += efi_selftest_rng.o
 obj-$(CONFIG_EFI_GET_TIME) += efi_selftest_rtc.o
-- 
2.34.1