Re: [PATCH] net: ti: am65-cpsw-nuss: Use dedicated port mode control registers

[Siddharth Vadapalli]

Hello Tom,

Can this patch please be merged?

On 15/06/23 03:58, Andreas Dannenberg wrote:
> The different CPSW sub-system Ethernet ports have different PHY mode
> control registers. In order to allow the modes to get configured
> independently only the register for the port in question must be
> accessed, otherwise we would just be re-configuring the mode for port 1,
> while leaving all others at their power-on defaults. Fix this issue by
> adding a port-number based offset to the mode control base register
> address based on the fact that the control registers for the different
> ports are spaced exactly 0x4 bytes apart.
> 
> Fixes: 9d0dca1199d1 ("net: ethernet: ti: Introduce am654 gigabit eth switch 
> subsystem driver")
> Signed-off-by: Andreas Dannenberg 
> Reviewed-by: Siddharth Vadapalli 
> ---
> Driver changes bench-tested on an SK-AM62 EVM by iterating through
> different variations of RGMII and RMII modes for CPSW ports 1 and 2 and
> checking operation as well as CTRL_ENET1_CTRL and CTRL_ENET2_CTRL
> control register contents from the U-Boot command line via 'md.l'.
> Testing was done on top of today's 'next' branch.
> 
>  drivers/net/ti/am65-cpsw-nuss.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
> index f674b0baa3..523a4c9f91 100644
> --- a/drivers/net/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ti/am65-cpsw-nuss.c
> @@ -223,6 +223,8 @@ out:
>   return phy->link;
>  }
>  
> +#define AM65_GMII_SEL_PORT_OFFS(x)   (0x4 * ((x) - 1))
> +
>  #define AM65_GMII_SEL_MODE_MII   0
>  #define AM65_GMII_SEL_MODE_RMII  1
>  #define AM65_GMII_SEL_MODE_RGMII 2
> @@ -233,11 +235,12 @@ static void am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv 
> *priv,
> phy_interface_t phy_mode, int slave)
>  {
>   struct am65_cpsw_common *common = priv->cpsw_common;
> + fdt_addr_t gmii_sel = common->gmii_sel + AM65_GMII_SEL_PORT_OFFS(slave);
>   u32 reg;
>   u32 mode = 0;
>   bool rgmii_id = false;
>  
> - reg = readl(common->gmii_sel);
> + reg = readl(gmii_sel);
>  
>   dev_dbg(common->dev, "old gmii_sel: %08x\n", reg);
>  
> @@ -273,9 +276,9 @@ static void am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv 
> *priv,
>   reg = mode;
>   dev_dbg(common->dev, "gmii_sel PHY mode: %u, new gmii_sel: %08x\n",
>   phy_mode, reg);
> - writel(reg, common->gmii_sel);
> + writel(reg, gmii_sel);
>  
> - reg = readl(common->gmii_sel);
> + reg = readl(gmii_sel);
>   if (reg != mode)
>   dev_err(common->dev,
>   "gmii_sel PHY mode NOT SET!: requested: %08x, gmii_sel: 
> %08x\n",

-- 
Regards,
Siddharth.

[PATCH 0/6] Add SGMII support for MAIN CPSW on TI's J7200 SoC

[Siddharth Vadapalli]

Hello,

This series adds support for SGMII mode to the CPSW driver to enable the
functionality on TI's J7200 SoC.

Supporting SGMII mode also requires changes to the WIZ driver which acts
as a wrapper for the SerDes used by the CPSW MAC to transmit data to the
Ethernet PHY daughtercard mounted on the I2C GPIO Expander 2 connector on
the J7200 EVM.

Powering on and resetting the Ethernet PHY requires MDIO support which
is added to the CPSW driver.

For supporting DMA transactions from the MAIN CPSW instance to the A72
Host on J7200 SoC, the corresponding PSI-L endpoint information is
added for the J721E SoC, which is applicable to J7200 SoC as well.

The SGMII daughtercard used for testing SGMII mode has TI's DP83869 PHY.
Thus, enable the config for DP83869 driver functionality. Also, enable
GPIO HOG config.

**NOTE**: This series is based on top of commit:
0beb649053 MAINTAINERS: correct at91 tree link
and depends on the following patch being merged as well:
Link: 
https://patchwork.ozlabs.org/project/uboot/patch/20230614222853.574427-1-dannenb...@ti.com/

Regards,
Siddharth.

Siddharth Vadapalli (4):
  net: ti: am65-cpsw-nuss: Add support for SGMII mode
  phy: ti: phy-j721e-wiz: Add SGMII support in wiz driver for J7200
  phy: ti: j721e-wiz: Add SGMII support in WIZ driver for J721E
  configs: j7200_evm_a72: Enable configs for SGMII support with MAIN
CPSW0

Suman Anna (2):
  dma: ti: Update J21E PSIL endpoint information for MAIN CPSW0
  net: ti: am65-cpsw-nuss: Add logic to support MDIO reset

 configs/j7200_evm_a72_defconfig |  2 ++
 drivers/dma/ti/k3-psil-j721e.c  | 17 --
 drivers/net/ti/am65-cpsw-nuss.c | 57 -
 drivers/phy/ti/phy-j721e-wiz.c  | 21 
 4 files changed, 87 insertions(+), 10 deletions(-)

-- 
2.34.1

[PATCH 2/6] net: ti: am65-cpsw-nuss: Add support for SGMII mode

[Siddharth Vadapalli]

Add support for configuring the CPSW Ethernet Switch in SGMII mode.

Signed-off-by: Siddharth Vadapalli 
---
 drivers/net/ti/am65-cpsw-nuss.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 523a4c9f91..403de3ea25 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -54,6 +54,12 @@
 #define AM65_CPSW_PN_REG_SA_L  0x308
 #define AM65_CPSW_PN_REG_SA_H  0x30c
 
+#define AM65_CPSW_SGMII_CONTROL_REG 0x010
+#define AM65_CPSW_SGMII_MR_ADV_ABILITY_REG  0x018
+#define AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLEBIT(0)
+
+#define ADVERTISE_SGMII0x1
+
 #define AM65_CPSW_ALE_CTL_REG  0x8
 #define AM65_CPSW_ALE_CTL_REG_ENABLE   BIT(31)
 #define AM65_CPSW_ALE_CTL_REG_RESET_TBLBIT(30)
@@ -89,6 +95,7 @@
 
 struct am65_cpsw_port {
fdt_addr_t  port_base;
+   fdt_addr_t  port_sgmii_base;
fdt_addr_t  macsl_base;
booldisabled;
u32 mac_control;
@@ -203,6 +210,8 @@ static int am65_cpsw_update_link(struct am65_cpsw_priv 
*priv)
mac_control |= AM65_CPSW_MACSL_CTL_REG_FULL_DUPLEX;
if (phy->speed == 100)
mac_control |= AM65_CPSW_MACSL_CTL_REG_IFCTL_A;
+   if (phy->interface == PHY_INTERFACE_MODE_SGMII)
+   mac_control |= AM65_CPSW_MACSL_CTL_EXT_EN;
}
 
if (mac_control == port->mac_control)
@@ -228,6 +237,7 @@ out:
 #define AM65_GMII_SEL_MODE_MII 0
 #define AM65_GMII_SEL_MODE_RMII1
 #define AM65_GMII_SEL_MODE_RGMII   2
+#define AM65_GMII_SEL_MODE_SGMII   3
 
 #define AM65_GMII_SEL_RGMII_IDMODE BIT(4)
 
@@ -260,6 +270,10 @@ static void am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv 
*priv,
rgmii_id = true;
break;
 
+   case PHY_INTERFACE_MODE_SGMII:
+   mode = AM65_GMII_SEL_MODE_SGMII;
+   break;
+
default:
dev_warn(common->dev,
 "Unsupported PHY mode: %u. Defaulting to MII.\n",
@@ -396,6 +410,13 @@ static int am65_cpsw_start(struct udevice *dev)
goto err_dis_rx;
}
 
+   if (priv->phydev->interface == PHY_INTERFACE_MODE_SGMII) {
+   writel(ADVERTISE_SGMII,
+  port->port_sgmii_base + 
AM65_CPSW_SGMII_MR_ADV_ABILITY_REG);
+   writel(AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE,
+  port->port_sgmii_base + AM65_CPSW_SGMII_CONTROL_REG);
+   }
+
ret = phy_startup(priv->phydev);
if (ret) {
dev_err(dev, "phy_startup failed\n");
@@ -779,6 +800,8 @@ static int am65_cpsw_probe_nuss(struct udevice *dev)
port->port_base = cpsw_common->cpsw_base +
  AM65_CPSW_CPSW_NU_PORTS_OFFSET +
  (i * AM65_CPSW_CPSW_NU_PORTS_OFFSET);
+   port->port_sgmii_base = cpsw_common->ss_base +
+   AM65_CPSW_SGMII_BASE * (i);
port->macsl_base = port->port_base +
   AM65_CPSW_CPSW_NU_PORT_MACSL_OFFSET;
}
-- 
2.34.1

[PATCH 1/6] dma: ti: Update J21E PSIL endpoint information for MAIN CPSW0

[Siddharth Vadapalli]

From: Suman Anna 

The PSIL endpoint data for J721E currently covers only the MCU domain
CPSW0 instance. Add the data for the MAIN domain CPSW0 as well to allow
the MAIN domain Ethernet ports to be usable on any platform using J721E
SoC.

Additionally, since J721E's PSIL endpoint data is applicable to J7200
SoC as well, the MAIN CPSW0 instance on J7200 will also be usable now.

Signed-off-by: Suman Anna 
[s-vadapa...@ti.com: Update commit message indicating support for J7200]
Signed-off-by: Siddharth Vadapalli 
---
 drivers/dma/ti/k3-psil-j721e.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/ti/k3-psil-j721e.c b/drivers/dma/ti/k3-psil-j721e.c
index 105ffd946f..8e57e860f2 100644
--- a/drivers/dma/ti/k3-psil-j721e.c
+++ b/drivers/dma/ti/k3-psil-j721e.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- *  Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
+ *  Copyright (C) 2019-2023 Texas Instruments Incorporated - https://www.ti.com
  *  Author: Peter Ujfalusi 
  */
 
@@ -21,13 +21,15 @@
 
 /* PSI-L source thread IDs, used for RX (DMA_DEV_TO_MEM) */
 static struct psil_ep j721e_src_ep_map[] = {
-   /* CPSW0 */
+   /* MCU_CPSW0 */
PSIL_ETHERNET(0x7000),
+   /* MAIN_CPSW0 */
+   PSIL_ETHERNET(0x4a00),
 };
 
 /* PSI-L destination thread IDs, used for TX (DMA_MEM_TO_DEV) */
 static struct psil_ep j721e_dst_ep_map[] = {
-   /* CPSW0 */
+   /* MCU_CPSW0 */
PSIL_ETHERNET(0xf000),
PSIL_ETHERNET(0xf001),
PSIL_ETHERNET(0xf002),
@@ -36,6 +38,15 @@ static struct psil_ep j721e_dst_ep_map[] = {
PSIL_ETHERNET(0xf005),
PSIL_ETHERNET(0xf006),
PSIL_ETHERNET(0xf007),
+   /* MAIN_CPSW0 */
+   PSIL_ETHERNET(0xca00),
+   PSIL_ETHERNET(0xca01),
+   PSIL_ETHERNET(0xca02),
+   PSIL_ETHERNET(0xca03),
+   PSIL_ETHERNET(0xca04),
+   PSIL_ETHERNET(0xca05),
+   PSIL_ETHERNET(0xca06),
+   PSIL_ETHERNET(0xca07),
 };
 
 struct psil_ep_map j721e_ep_map = {
-- 
2.34.1

[PATCH 3/6] net: ti: am65-cpsw-nuss: Add logic to support MDIO reset

[Siddharth Vadapalli]

From: Suman Anna 

Enhance the AM65 CPSW NUSS driver to perform a MDIO reset using a GPIO
line. Logic is also added to perform a pre and post delay around reset
using the optional 'reset-delay-us' and 'reset-post-delay-us' properties.
This is similar to the reset being performed in the Linux kernel. The
reset is done once when the CPSW MDIO bus is being initialized.

Signed-off-by: Suman Anna 
Signed-off-by: Siddharth Vadapalli 
---
 drivers/net/ti/am65-cpsw-nuss.c | 34 -
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 403de3ea25..f39d1adc99 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -23,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "cpsw_mdio.h"
@@ -93,6 +95,8 @@
 
 #define AM65_CPSW_CPPI_PKT_TYPE0x7
 
+#define DEFAULT_GPIO_RESET_DELAY   10
+
 struct am65_cpsw_port {
fdt_addr_t  port_base;
fdt_addr_t  port_sgmii_base;
@@ -119,6 +123,10 @@ struct am65_cpsw_common {
struct mii_dev  *bus;
u32 bus_freq;
 
+   struct gpio_descmdio_gpio_reset;
+   u32 reset_delay_us;
+   u32 reset_post_delay_us;
+
struct dma  dma_tx;
struct dma  dma_rx;
u32 rx_next;
@@ -590,6 +598,14 @@ static int am65_cpsw_mdio_init(struct udevice *dev)
if (!priv->has_phy || cpsw_common->bus)
return 0;
 
+   if (dm_gpio_is_valid(&cpsw_common->mdio_gpio_reset)) {
+   dm_gpio_set_value(&cpsw_common->mdio_gpio_reset, 1);
+   udelay(cpsw_common->reset_delay_us);
+   dm_gpio_set_value(&cpsw_common->mdio_gpio_reset, 0);
+   if (cpsw_common->reset_post_delay_us > 0)
+   udelay(cpsw_common->reset_post_delay_us);
+   }
+
cpsw_common->bus = cpsw_mdio_init(dev->name,
  cpsw_common->mdio_base,
  cpsw_common->bus_freq,
@@ -723,7 +739,7 @@ out:
 static int am65_cpsw_probe_nuss(struct udevice *dev)
 {
struct am65_cpsw_common *cpsw_common = dev_get_priv(dev);
-   ofnode ports_np, node;
+   ofnode ports_np, node, mdio_np;
int ret, i;
struct udevice *port_dev;
 
@@ -752,6 +768,22 @@ static int am65_cpsw_probe_nuss(struct udevice *dev)
AM65_CPSW_CPSW_NU_ALE_BASE;
cpsw_common->mdio_base = cpsw_common->ss_base + AM65_CPSW_MDIO_BASE;
 
+   /* get bus level PHY reset GPIO details */
+   mdio_np = dev_read_subnode(dev, "mdio");
+   if (!ofnode_valid(mdio_np)) {
+   ret = -ENOENT;
+   goto out;
+   }
+
+   cpsw_common->reset_delay_us = ofnode_read_u32_default(mdio_np, 
"reset-delay-us",
+ 
DEFAULT_GPIO_RESET_DELAY);
+   cpsw_common->reset_post_delay_us = ofnode_read_u32_default(mdio_np,
+  
"reset-post-delay-us",
+  0);
+   ret = gpio_request_by_name_nodev(mdio_np, "reset-gpios", 0,
+&cpsw_common->mdio_gpio_reset,
+GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
+
ports_np = dev_read_subnode(dev, "ethernet-ports");
if (!ofnode_valid(ports_np)) {
ret = -ENOENT;
-- 
2.34.1

[PATCH 5/6] phy: ti: j721e-wiz: Add SGMII support in WIZ driver for J721E

[Siddharth Vadapalli]

Enable full rate divider configuration support for J721E_WIZ_16G for SGMII.

Signed-off-by: Siddharth Vadapalli 
---
 drivers/phy/ti/phy-j721e-wiz.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 12421f90b0..ecb2f684ef 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -580,6 +580,8 @@ static int wiz_phy_fullrt_div(struct wiz *wiz, int lane)
if (wiz->lane_phy_type[lane] == PHY_TYPE_PCIE)
return regmap_field_write(wiz->p0_fullrt_div[lane], 
0x1);
break;
+
+   case J721E_WIZ_16G:
case J721E_WIZ_10G:
if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
return regmap_field_write(wiz->p0_fullrt_div[lane], 
0x2);
-- 
2.34.1

[PATCH 4/6] phy: ti: phy-j721e-wiz: Add SGMII support in wiz driver for J7200

[Siddharth Vadapalli]

Select the same mac divider for SGMII too as the one being used for
QSGMII.

Enable full rate divider configuration support for J721E_WIZ_10G for
SGMII.

Signed-off-by: Siddharth Vadapalli 
---
 drivers/phy/ti/phy-j721e-wiz.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 23397175d3..12421f90b0 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -575,12 +575,18 @@ static int wiz_reset_assert(struct reset_ctl *reset_ctl)
 
 static int wiz_phy_fullrt_div(struct wiz *wiz, int lane)
 {
-   if (wiz->type != AM64_WIZ_10G)
+   switch (wiz->type) {
+   case AM64_WIZ_10G:
+   if (wiz->lane_phy_type[lane] == PHY_TYPE_PCIE)
+   return regmap_field_write(wiz->p0_fullrt_div[lane], 
0x1);
+   break;
+   case J721E_WIZ_10G:
+   if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
+   return regmap_field_write(wiz->p0_fullrt_div[lane], 
0x2);
+   break;
+   default:
return 0;
-
-   if (wiz->lane_phy_type[lane] == PHY_TYPE_PCIE)
-   return regmap_field_write(wiz->p0_fullrt_div[lane], 0x1);
-
+   }
return 0;
 }
 
@@ -696,7 +702,8 @@ static int wiz_p_mac_div_sel(struct wiz *wiz)
int i;
 
for (i = 0; i < num_lanes; i++) {
-   if (wiz->lane_phy_type[i] == PHY_TYPE_QSGMII) {
+   if (wiz->lane_phy_type[i] == PHY_TYPE_SGMII ||
+   wiz->lane_phy_type[i] == PHY_TYPE_QSGMII) {
ret = regmap_field_write(wiz->p_mac_div_sel0[i], 1);
if (ret)
return ret;
-- 
2.34.1

[PATCH 6/6] configs: j7200_evm_a72: Enable configs for SGMII support with MAIN CPSW0

[Siddharth Vadapalli]

The MAIN CPSW0 instance of CPSW Ethernet Switch on TI's J7200 SoC
supports SGMII mode. To enable support for utilizing the SGMII
daughtercard with TI's DP83869 PHY, enable the corresponding config.

Also, since the SGMII daughtercard is connected to the I2C GPIO
Expander 2 connector on the J7200 EVM, powering on the Ethernet PHY and
resetting it requires GPIO Hogging capability. Enable it as well.

Signed-off-by: Siddharth Vadapalli 
---
 configs/j7200_evm_a72_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig
index e40900fffa..e5b5c85ed1 100644
--- a/configs/j7200_evm_a72_defconfig
+++ b/configs/j7200_evm_a72_defconfig
@@ -122,6 +122,7 @@ CONFIG_FASTBOOT_FLASH=y
 CONFIG_FASTBOOT_FLASH_MMC_DEV=0
 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_GPIO_HOG=y
 CONFIG_DA8XX_GPIO=y
 CONFIG_DM_PCA953X=y
 CONFIG_DM_I2C=y
@@ -154,6 +155,7 @@ CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_MULTIPLEXER=y
 CONFIG_MUX_MMIO=y
+CONFIG_PHY_TI_DP83869=y
 CONFIG_PHY_FIXED=y
 CONFIG_TI_AM65_CPSW_NUSS=y
 CONFIG_PHY=y
-- 
2.34.1

Re: [PATCH] arm: mach-k3: *: dev-data: Update to use ARRAY_SIZE

[Siddharth Vadapalli]

On 14/07/23 01:06, Nishanth Menon wrote:
> Instead of hard-coding the count of entries manually, use ARRAY_SIZE
> to keep the count updates appropriately.
> 
> Cc: Bryan Brattlof 
> Suggested-by: Ravi Gunasekaran 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Siddharth Vadapalli 

> ---
> 
> Link to discussion that triggered this:
> https://lore.kernel.org/all/20230713185927.3h6vqap4x3h62...@bryanbrattlof.com/
> 
>  arch/arm/mach-k3/am62ax/dev-data.c | 8 
>  arch/arm/mach-k3/am62x/dev-data.c  | 8 
>  arch/arm/mach-k3/j7200/dev-data.c  | 8 
>  arch/arm/mach-k3/j721e/dev-data.c  | 8 
>  arch/arm/mach-k3/j721s2/dev-data.c | 8 
>  5 files changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/arm/mach-k3/am62ax/dev-data.c 
> b/arch/arm/mach-k3/am62ax/dev-data.c
> index 74739c638524..abf5d8e91aa2 100644
> --- a/arch/arm/mach-k3/am62ax/dev-data.c
> +++ b/arch/arm/mach-k3/am62ax/dev-data.c
> @@ -66,8 +66,8 @@ const struct ti_k3_pd_platdata am62ax_pd_platdata = {
>   .pd = soc_pd_list,
>   .lpsc = soc_lpsc_list,
>   .devs = soc_dev_list,
> - .num_psc = 2,
> - .num_pd = 4,
> - .num_lpsc = 14,
> - .num_devs = 19,
> + .num_psc = ARRAY_SIZE(soc_psc_list),
> + .num_pd = ARRAY_SIZE(soc_pd_list),
> + .num_lpsc = ARRAY_SIZE(soc_lpsc_list),
> + .num_devs = ARRAY_SIZE(soc_dev_list),
>  };
> diff --git a/arch/arm/mach-k3/am62x/dev-data.c 
> b/arch/arm/mach-k3/am62x/dev-data.c
> index 616d0650b9c0..1a6f9e2ca03e 100644
> --- a/arch/arm/mach-k3/am62x/dev-data.c
> +++ b/arch/arm/mach-k3/am62x/dev-data.c
> @@ -71,8 +71,8 @@ const struct ti_k3_pd_platdata am62x_pd_platdata = {
>   .pd = soc_pd_list,
>   .lpsc = soc_lpsc_list,
>   .devs = soc_dev_list,
> - .num_psc = 2,
> - .num_pd = 5,
> - .num_lpsc = 16,
> - .num_devs = 21,
> + .num_psc = ARRAY_SIZE(soc_psc_list),
> + .num_pd = ARRAY_SIZE(soc_pd_list),
> + .num_lpsc = ARRAY_SIZE(soc_lpsc_list),
> + .num_devs = ARRAY_SIZE(soc_dev_list),
>  };
> diff --git a/arch/arm/mach-k3/j7200/dev-data.c 
> b/arch/arm/mach-k3/j7200/dev-data.c
> index c1a4dab6941a..4ddc34210ebb 100644
> --- a/arch/arm/mach-k3/j7200/dev-data.c
> +++ b/arch/arm/mach-k3/j7200/dev-data.c
> @@ -75,8 +75,8 @@ const struct ti_k3_pd_platdata j7200_pd_platdata = {
>   .pd = soc_pd_list,
>   .lpsc = soc_lpsc_list,
>   .devs = soc_dev_list,
> - .num_psc = 2,
> - .num_pd = 6,
> - .num_lpsc = 17,
> - .num_devs = 23,
> + .num_psc = ARRAY_SIZE(soc_psc_list),
> + .num_pd = ARRAY_SIZE(soc_pd_list),
> + .num_lpsc = ARRAY_SIZE(soc_lpsc_list),
> + .num_devs = ARRAY_SIZE(soc_dev_list),
>  };
> diff --git a/arch/arm/mach-k3/j721e/dev-data.c 
> b/arch/arm/mach-k3/j721e/dev-data.c
> index f0afa3552b7f..97f017f8af50 100644
> --- a/arch/arm/mach-k3/j721e/dev-data.c
> +++ b/arch/arm/mach-k3/j721e/dev-data.c
> @@ -73,8 +73,8 @@ const struct ti_k3_pd_platdata j721e_pd_platdata = {
>   .pd = soc_pd_list,
>   .lpsc = soc_lpsc_list,
>   .devs = soc_dev_list,
> - .num_psc = 2,
> - .num_pd = 5,
> - .num_lpsc = 16,
> - .num_devs = 23,
> + .num_psc = ARRAY_SIZE(soc_psc_list),
> + .num_pd = ARRAY_SIZE(soc_pd_list),
> + .num_lpsc = ARRAY_SIZE(soc_lpsc_list),
> + .num_devs = ARRAY_SIZE(soc_dev_list),
>  };
> diff --git a/arch/arm/mach-k3/j721s2/dev-data.c 
> b/arch/arm/mach-k3/j721s2/dev-data.c
> index 35e8b17eb1e7..8c999a3c5a8b 100644
> --- a/arch/arm/mach-k3/j721s2/dev-data.c
> +++ b/arch/arm/mach-k3/j721s2/dev-data.c
> @@ -79,8 +79,8 @@ const struct ti_k3_pd_platdata j721s2_pd_platdata = {
>   .pd = soc_pd_list,
>   .lpsc = soc_lpsc_list,
>   .devs = soc_dev_list,
> - .num_psc = 2,
> - .num_pd = 6,
> - .num_lpsc = 19,
> - .num_devs = 25,
> + .num_psc = ARRAY_SIZE(soc_psc_list),
> + .num_pd = ARRAY_SIZE(soc_pd_list),
> + .num_lpsc = ARRAY_SIZE(soc_lpsc_list),
> + .num_devs = ARRAY_SIZE(soc_dev_list),
>  };

-- 
Regards,
Siddharth.

Re: [PATCH v4 1/2] net: ti: am65-cpsw-nuss: Enforce pinctrl state on the MDIO child node

[Siddharth Vadapalli]

Hello Maxime,

Thank you for the patch.

On 24/07/23 19:27, Maxime Ripard wrote:
> The binding represents the MDIO controller as a child device tree
> node of the MAC device tree node.
> 
> The U-Boot driver mostly ignores that child device tree node and just
> hardcodes the resources it uses to support both the MAC and MDIO in a
> single driver.
> 
> However, some resources like pinctrl muxing states are thus ignored.
> This has been a problem with some device trees that will put some
> pinctrl states on the MDIO device tree node, like the SK-AM62 Device
> Tree does.
> 
> Let's rework the driver a bit to create a dummy MDIO driver that we will
> then get during our initialization to force the core to select the right
> muxing.
> 
> Signed-off-by: Maxime Ripard 

LGTM.

Reviewed-by: Siddharth Vadapalli 

> ---
>  drivers/net/ti/Kconfig  |  1 +
>  drivers/net/ti/am65-cpsw-nuss.c | 60 
> +
>  2 files changed, 61 insertions(+)
> 
> diff --git a/drivers/net/ti/Kconfig b/drivers/net/ti/Kconfig
> index d9f1c019a885..02660e4fbb44 100644
> --- a/drivers/net/ti/Kconfig
> +++ b/drivers/net/ti/Kconfig
> @@ -41,6 +41,7 @@ endchoice
>  config TI_AM65_CPSW_NUSS
>   bool "TI K3 AM65x MCU CPSW Nuss Ethernet controller driver"
>   depends on ARCH_K3
> + imply DM_MDIO
>   imply MISC_INIT_R
>   imply MISC
>   imply SYSCON
> diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
> index ce52106e5238..51a8167d14a9 100644
> --- a/drivers/net/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ti/am65-cpsw-nuss.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -605,14 +606,62 @@ static const struct soc_attr k3_mdio_soc_data[] = {
>   { /* sentinel */ },
>  };
>  
> +static ofnode am65_cpsw_find_mdio(ofnode parent)
> +{
> + ofnode node;
> +
> + ofnode_for_each_subnode(node, parent)
> + if (ofnode_device_is_compatible(node, "ti,cpsw-mdio"))
> + return node;
> +
> + return ofnode_null();
> +}
> +
> +static int am65_cpsw_mdio_setup(struct udevice *dev)
> +{
> + struct am65_cpsw_priv *priv = dev_get_priv(dev);
> + struct am65_cpsw_common *cpsw_common = priv->cpsw_common;
> + struct udevice *mdio_dev;
> + ofnode mdio;
> + int ret;
> +
> + mdio = am65_cpsw_find_mdio(dev_ofnode(cpsw_common->dev));
> + if (!ofnode_valid(mdio))
> + return 0;
> +
> + /*
> +  * The MDIO controller is represented in the DT binding by a
> +  * subnode of the MAC controller.
> +  *
> +  * We don't have a DM driver for the MDIO device yet, and thus any
> +  * pinctrl setting on its node will be ignored.
> +  *
> +  * However, we do need to make sure the pins states tied to the
> +  * MDIO node are configured properly. Fortunately, the core DM
> +  * does that for use when we get a device, so we can work around
> +  * that whole issue by just requesting a dummy MDIO driver to
> +  * probe, and our pins will get muxed.
> +  */
> + ret = uclass_get_device_by_ofnode(UCLASS_MDIO, mdio, &mdio_dev);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
>  static int am65_cpsw_mdio_init(struct udevice *dev)
>  {
>   struct am65_cpsw_priv *priv = dev_get_priv(dev);
>   struct am65_cpsw_common *cpsw_common = priv->cpsw_common;
> + int ret;
>  
>   if (!priv->has_phy || cpsw_common->bus)
>   return 0;
>  
> + ret = am65_cpsw_mdio_setup(dev);
> + if (ret)
> + return ret;
> +
>   cpsw_common->bus = cpsw_mdio_init(dev->name,
> cpsw_common->mdio_base,
> cpsw_common->bus_freq,
> @@ -868,3 +917,14 @@ U_BOOT_DRIVER(am65_cpsw_nuss_port) = {
>   .plat_auto  = sizeof(struct eth_pdata),
>   .flags = DM_FLAG_ALLOC_PRIV_DMA | DM_FLAG_OS_PREPARE,
>  };
> +
> +static const struct udevice_id am65_cpsw_mdio_ids[] = {
> + { .compatible = "ti,cpsw-mdio" },
> + { }
> +};
> +
> +U_BOOT_DRIVER(am65_cpsw_mdio) = {
> + .name   = "am65_cpsw_mdio",
> + .id = UCLASS_MDIO,
> + .of_match   = am65_cpsw_mdio_ids,
> +};
> 

-- 
Regards,
Siddharth.

Re: [PATCH 1/2] net: ti: am65-cpsw-nuss: Workaround for buggy PHY/Board

[Siddharth Vadapalli]

Roger,

On 22/08/23 17:43, Roger Quadros wrote:
> Beagleplay has a buggy Ethernet PHY implementation for the Gigabit
> PHY in the sense that it is non responsive over MDIO immediately
> after power-up/reset.
> 
> We need to either try multiple times or wait sufficiently long enough
> (couple of 10s of ms?) before the PHY begins to respond correctly.

Based on the datasheet at:
https://datasheet.lcsc.com/lcsc/1912111437_Realtek-Semicon-RTL8211F-CG_C187932.pdf
in the section 7.17. PHY Reset (Hardware Reset), it is stated that
software has to wait for at least 50 ms before accessing the PHY
registers. Is this why the for-loop in the code below tries for at most
5 times with a delay of 10 ms before the next try? If yes, then isn't it
better to move the delay into the realtek PHY driver at
drivers/net/phy/realtek.c
Shouldn't it be the PHY driver which ensures that any reads/writes to the PHY
registers are valid? It can ensure this by having a one time 50ms delay for the
very first access to the PHY registers.

> 
> One theory is that the PHY is configured to operate on MDIO address 0
> which it treats as a special broadcast address.
> 
> Datasheet states:
> "PHYAD (config pins) sets the PHY address for the device.
> The RTL8211F(I)/RTL8211FD(I) supports PHY addresses from 0x01 to 0x07.
> Note 1: An MDIO command with PHY address=0 is a broadcast from the MAC;
> each PHY device should respond."
> 
> This issue is not seen with the other PHY (different make) on the board
> which is configured for address 0x1.
> 
> As a woraround we try to probe the PHY multiple times instead of giving
> up on the first attempt.
> 
> Signed-off-by: Roger Quadros 
> ---
>  drivers/net/ti/am65-cpsw-nuss.c | 19 ++-
>  1 file changed, 14 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
> index 51a8167d14..4f8a2f9b93 100644
> --- a/drivers/net/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ti/am65-cpsw-nuss.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "cpsw_mdio.h"
>  
> @@ -678,14 +679,22 @@ static int am65_cpsw_phy_init(struct udevice *dev)
>   struct am65_cpsw_priv *priv = dev_get_priv(dev);
>   struct am65_cpsw_common *cpsw_common = priv->cpsw_common;
>   struct eth_pdata *pdata = dev_get_plat(dev);
> - struct phy_device *phydev;
>   u32 supported = PHY_GBIT_FEATURES;
> + struct phy_device *phydev;
> + int tries;
>   int ret;
>  
> - phydev = phy_connect(cpsw_common->bus,
> -  priv->phy_addr,
> -  priv->dev,
> -  pdata->phy_interface);
> + /* Some boards (e.g. beagleplay) don't work on first go */
> + for (tries = 1; tries <= 5; tries++) {
> + phydev = phy_connect(cpsw_common->bus,
> +  priv->phy_addr,
> +  priv->dev,
> +  pdata->phy_interface);
> + if (phydev)
> + break;
> +
> + mdelay(10);
> + }
>  
>   if (!phydev) {
>   dev_err(dev, "phy_connect() failed\n");

-- 
Regards,
Siddharth.

Re: [PATCH 2/2] net: phy: Change "PHY not found" message to debug()

[Siddharth Vadapalli]

On 22/08/23 17:43, Roger Quadros wrote:
> Some boards (e.g. Beagleplay) need multiple attempts to detect the PHY
> and the multiple "PHY not found" prints are not nice.

I tried grepping for calls to "phy_connect" across the drivers present in
drivers/net. Most of them simply return -ENODEV on failure. The ones
which add prints indicating failure, don't use debug(). For this reason,
I believe that the drivers which don't have any prints in case of
failure might be relying on the printf() within phy_connect() to indicate
failure. Therefore, if the printf() is being changed to debug() in
phy_connect(), maybe all the drivers which currently return -ENODEV,
should have a print added to them as a part of this patch.

> 
> Change them to debug().
> 
> Signed-off-by: Roger Quadros 
> ---
>  drivers/net/phy/phy.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index ae21acb059..3a524bcd81 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -928,7 +928,7 @@ struct phy_device *phy_connect(struct mii_dev *bus, int 
> addr,
>   if (phydev)
>   phy_connect_dev(phydev, dev, interface);
>   else
> - printf("Could not get PHY for %s: addr %d\n", bus->name, addr);
> + debug("Could not get PHY for %s: addr %d\n", bus->name, addr);
>   return phydev;
>  }
>  

-- 
Regards,
Siddharth.

Re: [PATCH 1/2] net: ti: am65-cpsw-nuss: Workaround for buggy PHY/Board

[Siddharth Vadapalli]

On 23/08/23 13:22, Roger Quadros wrote:
> Hi Siddharth,
> 
> On 23/08/2023 07:35, Siddharth Vadapalli wrote:
>> Roger,
>>
>> On 22/08/23 17:43, Roger Quadros wrote:
>>> Beagleplay has a buggy Ethernet PHY implementation for the Gigabit
>>> PHY in the sense that it is non responsive over MDIO immediately
>>> after power-up/reset.
>>>
>>> We need to either try multiple times or wait sufficiently long enough
>>> (couple of 10s of ms?) before the PHY begins to respond correctly.
>>
>> Based on the datasheet at:
>> https://datasheet.lcsc.com/lcsc/1912111437_Realtek-Semicon-RTL8211F-CG_C187932.pdf
>> in the section 7.17. PHY Reset (Hardware Reset), it is stated that
>> software has to wait for at least 50 ms before accessing the PHY
>> registers. Is this why the for-loop in the code below tries for at most
>> 5 times with a delay of 10 ms before the next try? If yes, then isn't it
> 
> Good catch. This might be the reason why PHY is not responding in the first
> few attempts.
> 
>> better to move the delay into the realtek PHY driver at
>> drivers/net/phy/realtek.c
> 
> We are currently at the MDIO bus driver where we don't even know what PHY
> is on the bus. So this delay cannot come at the realtec PHY driver.
> It has to come at the MDIO bus driver level.

Thank you for clarifying.

> 
>> Shouldn't it be the PHY driver which ensures that any reads/writes to the PHY
>> registers are valid? It can ensure this by having a one time 50ms delay for 
>> the
>> very first access to the PHY registers.> 

...

>>
> 

-- 
Regards,
Siddharth.

Re: [PATCH 1/2] net: ti: am65-cpsw-nuss: Workaround for buggy PHY/Board

[Siddharth Vadapalli]

Hello Roger,

On 22-08-2023 17:43, Roger Quadros wrote:
> Beagleplay has a buggy Ethernet PHY implementation for the Gigabit
> PHY in the sense that it is non responsive over MDIO immediately
> after power-up/reset.
> 
> We need to either try multiple times or wait sufficiently long enough
> (couple of 10s of ms?) before the PHY begins to respond correctly.
> 
> One theory is that the PHY is configured to operate on MDIO address 0
> which it treats as a special broadcast address.
> 
> Datasheet states:
> "PHYAD (config pins) sets the PHY address for the device.
> The RTL8211F(I)/RTL8211FD(I) supports PHY addresses from 0x01 to 0x07.
> Note 1: An MDIO command with PHY address=0 is a broadcast from the MAC;
> each PHY device should respond."
> 
> This issue is not seen with the other PHY (different make) on the board
> which is configured for address 0x1.
> 
> As a woraround we try to probe the PHY multiple times instead of giving
> up on the first attempt.
> 
> Signed-off-by: Roger Quadros 
> ---
>  drivers/net/ti/am65-cpsw-nuss.c | 19 ++-
>  1 file changed, 14 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
> index 51a8167d14..4f8a2f9b93 100644
> --- a/drivers/net/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ti/am65-cpsw-nuss.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "cpsw_mdio.h"
>  
> @@ -678,14 +679,22 @@ static int am65_cpsw_phy_init(struct udevice *dev)
>   struct am65_cpsw_priv *priv = dev_get_priv(dev);
>   struct am65_cpsw_common *cpsw_common = priv->cpsw_common;
>   struct eth_pdata *pdata = dev_get_plat(dev);
> - struct phy_device *phydev;
>   u32 supported = PHY_GBIT_FEATURES;
> + struct phy_device *phydev;
> + int tries;
>   int ret;
>  
> - phydev = phy_connect(cpsw_common->bus,
> -  priv->phy_addr,
> -  priv->dev,
> -  pdata->phy_interface);
> + /* Some boards (e.g. beagleplay) don't work on first go */
> + for (tries = 1; tries <= 5; tries++) {
> + phydev = phy_connect(cpsw_common->bus,
> +  priv->phy_addr,
> +  priv->dev,
> +  pdata->phy_interface);
> + if (phydev)
> + break;
> +
> + mdelay(10);
> + }

After rethinking about the above implementation and the second patch of
this series, the second patch could be dropped altogether if the
following implementation is acceptable:

phydev = phy_connect(cpsw_common->bus,
 priv->phy_addr,
 priv->dev,
 pdata->phy_interface);

if (!phydev) {
/* Some boards (e.g. beagleplay) don't work on first go */
mdelay(50);
phydev = phy_connect(cpsw_common->bus,
 priv->phy_addr,
 priv->dev,
 pdata->phy_interface);
}

if (!phydev) {
dev_err(dev, "phy_connect() failed\n");
...

With this, there would be at most one "PHY not found" print, which
should be fine. The mdelay value of 50 could be replaced with a
sufficiently large value which guarantees success for Beagleplay.

-- 
Regards,
Siddharth.

Re: [PATCH 1/2] net: ti: am65-cpsw-nuss: Workaround for buggy PHY/Board

[Siddharth Vadapalli]

Roger,

On 25/08/23 00:39, Roger Quadros wrote:
> 
> 
> On 24/08/2023 21:24, Tom Rini wrote:
>> On Thu, Aug 24, 2023 at 11:34:29PM +0530, Siddharth Vadapalli wrote:
>>> Hello Roger,
>>>
>>> On 22-08-2023 17:43, Roger Quadros wrote:

...

> 
> Even a single "PHY not found" print is not OK. It looks like an
> error while it should not.
> 
> The correct solution is to use the MDIO uclass framework and add
> some generic handling in the class driver. drivers/net/eth-phy-uclass.c
> 
> We could provide the delay time in the 'reset-deassert-us' property.
> Although I'm not sure if this is the correct property for this case
> as there is no RESET GPIO on the board. What we really want is delay
> from power-on-reset. Which means we might have to introduce a new property
> and use time from boot to determine if PHY is ready or not?
> 
> NOTE: PHY ready time is different for hardware reset and power-on-reset.
> 50ms vs 150ms

Another alternative could be that of implementing the for-loop within
phy_connect() along with the delay, by updating the function with a new
parameter "tries" which indicates the number of retries before finally printing
"PHY not found" in case of an error. Optionally, another parameter "delay" can
be added, which indicates the delay within the for-loop.

This implementation will require updating all drivers in drivers/net which use
phy_connect(), with the "tries" parameter set to 1 for them. The am65-cpsw-nuss
driver can set "tries" to 5 as done in the current patch.

The idea behind moving the for-loop within phy_connect() is that it will help
solve the issue for other drivers as well, if they potentially encounter such
buggy PHYs in future boards.

> 

-- 
Regards,
Siddharth.

Re: [PATCH 1/2] net: ti: am65-cpsw-nuss: Workaround for buggy PHY/Board

[Siddharth Vadapalli]

On 25/08/23 13:22, Roger Quadros wrote:
> Siddharth,
> 
> On 25/08/2023 08:42, Siddharth Vadapalli wrote:
>> Roger,
>>
>> On 25/08/23 00:39, Roger Quadros wrote:
>>>
>>>
>>> On 24/08/2023 21:24, Tom Rini wrote:
>>>> On Thu, Aug 24, 2023 at 11:34:29PM +0530, Siddharth Vadapalli wrote:
>>>>> Hello Roger,
>>>>>
>>>>> On 22-08-2023 17:43, Roger Quadros wrote:

...

>>
> 
> This doesn't sound like a clean solution.
> All hardware specific details (like reset ready-time) should come from the
> device tree and not passed around in PHY APIs.
> 
> Why to do such an intrusive change instead of fixing the am65-cpsw-nuss driver
> to properly use the PHY uclass driver model and encode the required delays
> in the device tree?

Encoding delays in device-tree and using them is better. Kindly ignore my
suggestion.

> 

-- 
Regards,
Siddharth.

[PATCH] board: ti: j721s2: Add support to detect daughtercards

[Siddharth Vadapalli]

From: Kishon Vijay Abraham I 

Add support to detect daughtercards (GESI Ethernet card) in-order
to set the MAC address of the main CPSW2G interface.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Siddharth Vadapalli 
---
 board/ti/j721s2/evm.c | 130 ++
 1 file changed, 130 insertions(+)

diff --git a/board/ti/j721s2/evm.c b/board/ti/j721s2/evm.c
index c86715fa21..b920c441a9 100644
--- a/board/ti/j721s2/evm.c
+++ b/board/ti/j721s2/evm.c
@@ -171,6 +171,135 @@ static void setup_serial(void)
snprintf(serial_string, sizeof(serial_string), "%016lx", board_serial);
env_set("serial#", serial_string);
 }
+
+/*
+ * Declaration of daughtercards to probe. Note that when adding more
+ * cards they should be grouped by the 'i2c_addr' field to allow for a
+ * more efficient probing process.
+ */
+static const struct {
+   u8 i2c_addr;/* I2C address of card EEPROM */
+   char *card_name;/* EEPROM-programmed card name */
+   char *dtbo_name;/* Device tree overlay to apply */
+   u8 eth_offset;  /* ethXaddr MAC address index offset */
+} ext_cards[] = {
+   {
+   0x52,
+   "J7X-GESI-EXP",
+   "k3-j721s2-gesi-exp-board.dtbo",
+   1,  /* Start populating from eth1addr */
+   },
+};
+
+#define DAUGHTER_CARD_NO_OF_MAC_ADDR   5
+static bool daughter_card_detect_flags[ARRAY_SIZE(ext_cards)];
+
+static int probe_daughtercards(void)
+{
+   char mac_addr[DAUGHTER_CARD_NO_OF_MAC_ADDR][TI_EEPROM_HDR_ETH_ALEN];
+   bool eeprom_read_success;
+   struct ti_am6_eeprom ep;
+   u8 previous_i2c_addr;
+   u8 mac_addr_cnt;
+   int i;
+   int ret;
+
+   /* Mark previous I2C address variable as not populated */
+   previous_i2c_addr = 0xff;
+
+   /* No EEPROM data was read yet */
+   eeprom_read_success = false;
+
+   /* Iterate through list of daughtercards */
+   for (i = 0; i < ARRAY_SIZE(ext_cards); i++) {
+   /* Obtain card-specific I2C address */
+   u8 i2c_addr = ext_cards[i].i2c_addr;
+
+   /* Read card EEPROM if not already read previously */
+   if (i2c_addr != previous_i2c_addr) {
+   /* Store I2C address so we can avoid reading twice */
+   previous_i2c_addr = i2c_addr;
+
+   /* Get and parse the daughter card EEPROM record */
+   ret = ti_i2c_eeprom_am6_get(CONFIG_EEPROM_BUS_ADDRESS,
+   i2c_addr,
+   &ep,
+   (char **)mac_addr,
+   
DAUGHTER_CARD_NO_OF_MAC_ADDR,
+   &mac_addr_cnt);
+   if (ret) {
+   debug("%s: No daughtercard EEPROM at 0x%02x 
found %d\n",
+ __func__, i2c_addr, ret);
+   eeprom_read_success = false;
+   /* Skip to the next daughtercard to probe */
+   continue;
+   }
+
+   /* EEPROM read successful, okay to further process. */
+   eeprom_read_success = true;
+   }
+
+   /* Only continue processing if EEPROM data was read */
+   if (!eeprom_read_success)
+   continue;
+
+   /* Only process the parsed data if we found a match */
+   if (strncmp(ep.name, ext_cards[i].card_name, sizeof(ep.name)))
+   continue;
+
+   printf("Detected: %s rev %s\n", ep.name, ep.version);
+   daughter_card_detect_flags[i] = true;
+
+   if (!IS_ENABLED(CONFIG_SPL_BUILD)) {
+   int j;
+   /*
+* Populate any MAC addresses from daughtercard into 
the U-Boot
+* environment, starting with a card-specific offset so 
we can
+* have multiple ext_cards contribute to the MAC pool 
in a well-
+* defined manner.
+*/
+   for (j = 0; j < mac_addr_cnt; j++) {
+   if (!is_valid_ethaddr((u8 *)mac_addr[j]))
+   continue;
+
+   eth_env_set_enetaddr_by_index("eth", 
ext_cards[i].eth_offset + j,
+ (uchar 
*)mac_addr[j]);
+   }
+   }
+   }
+
+   if (!IS_ENABLED(CONFIG_SPL_BUILD)) {
+   char name_overlays[1024] = { 0

Re: [PATCH] board: ti: j721s2: Add support to detect daughtercards

[Siddharth Vadapalli]

Hello Tom,

On 10/04/23 19:00, Tom Rini wrote:
> On Mon, Apr 10, 2023 at 11:40:15AM +0530, Siddharth Vadapalli wrote:
> 
>> From: Kishon Vijay Abraham I 
>>
>> Add support to detect daughtercards (GESI Ethernet card) in-order
>> to set the MAC address of the main CPSW2G interface.
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> Signed-off-by: Siddharth Vadapalli 
>> ---
>>  board/ti/j721s2/evm.c | 130 ++
>>  1 file changed, 130 insertions(+)
> 
> Do we (a) use this interface in U-Boot? If not (b) can Linux not read

Yes, the MAIN CPSW2G interface can be used in U-Boot.

> the MAC directly?
> 

-- 
Regards,
Siddharth.

[PATCH] configs: am62: Add configs for enabling ETHBOOT in R5SPL

[Siddharth Vadapalli]

From: Kishon Vijay Abraham I 

Add configs for enabling ETHBOOT in R5SPL. Adding a separate config
minimizes the risk of going past the R5-SPL size limit for any future
config additions.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Andreas Dannenberg 
Signed-off-by: Siddharth Vadapalli 
---
 configs/am62x_evm_r5_ethboot_defconfig | 118 +
 1 file changed, 118 insertions(+)
 create mode 100644 configs/am62x_evm_r5_ethboot_defconfig

diff --git a/configs/am62x_evm_r5_ethboot_defconfig 
b/configs/am62x_evm_r5_ethboot_defconfig
new file mode 100644
index 00..d9f642cad3
--- /dev/null
+++ b/configs/am62x_evm_r5_ethboot_defconfig
@@ -0,0 +1,118 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x9000
+CONFIG_SOC_K3_AM625=y
+CONFIG_TARGET_AM625_R5_EVM=y
+CONFIG_ENV_SIZE=0x2
+CONFIG_ENV_OFFSET=0x68
+CONFIG_DM_GPIO=y
+CONFIG_SPL_TEXT_BASE=0x43c0
+CONFIG_SPL_MMC_SUPPORT=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_SIZE_LIMIT=0x4
+CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x4000
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-am625-r5-sk"
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x8008
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y
+CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
+CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y
+CONFIG_SPL_BOARD_INIT=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_EARLY_BSS=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400
+CONFIG_SPL_DMA=y
+CONFIG_SPL_ENV_SUPPORT=y
+CONFIG_SPL_ETH_SUPPORT=y
+CONFIG_SPL_I2C_SUPPORT=y
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_NET_SUPPORT=y
+CONFIG_SPL_NET_VCI_STRING="AM62X U-Boot R5 SPL"
+CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_RAM_DEVICE=y
+CONFIG_SPL_REMOTEPROC=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_ASKENV=y
+CONFIG_CMD_DFU=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_REMOTEPROC=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_FAT=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_SYS_MMC_ENV_PART=1
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_SPL_CLK_CCF=y
+CONFIG_SPL_CLK_K3=y
+CONFIG_SPL_CLK_K3_PLL=y
+CONFIG_DMA_CHANNELS=y
+CONFIG_TI_K3_NAVSS_UDMA=y
+CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_DA8XX_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_OMAP24XX=y
+CONFIG_DM_MAILBOX=y
+CONFIG_K3_SEC_PROXY=y
+CONFIG_DM_MMC=y
+CONFIG_SPL_MMC_HS200_SUPPORT=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ADMA=y
+CONFIG_SPL_MMC_SDHCI_ADMA=y
+CONFIG_MMC_SDHCI_AM654=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_DM_ETH=y
+CONFIG_TI_AM65_CPSW_NUSS=y
+CONFIG_PINCTRL=y
+# CONFIG_PINCTRL_GENERIC is not set
+CONFIG_SPL_PINCTRL=y
+# CONFIG_SPL_PINCTRL_GENERIC is not set
+CONFIG_PINCTRL_SINGLE=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_TI_POWER_DOMAIN=y
+CONFIG_K3_SYSTEM_CONTROLLER=y
+CONFIG_REMOTEPROC_TI_K3_ARM64=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_TI_SCI=y
+CONFIG_SPECIFY_CONSOLE_INDEX=y
+CONFIG_DM_SERIAL=y
+CONFIG_SOC_DEVICE=y
+CONFIG_SOC_DEVICE_TI_K3=y
+CONFIG_SOC_TI=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_CADENCE_QSPI=y
+CONFIG_TIMER=y
+CONFIG_SPL_TIMER=y
+CONFIG_OMAP_TIMER=y
+CONFIG_LIB_RATIONAL=y
+CONFIG_SPL_LIB_RATIONAL=y
-- 
2.25.1

[PATCH] configs: j7200_evm_a72: Enhance bootcmd to configure ethernet PHY

[Siddharth Vadapalli]

From: Kishon Vijay Abraham I 

Update the default BOOTCOMMAND to provide an automatic and easier way
to configure ethernet PHY before loading the firmware.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Siddharth Vadapalli 
---
 configs/j7200_evm_a72_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig
index 9b6512bacb..8a32c40543 100644
--- a/configs/j7200_evm_a72_defconfig
+++ b/configs/j7200_evm_a72_defconfig
@@ -32,7 +32,7 @@ CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run 
boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run 
get_overlay_${boot}; run run_kern"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run 
main_cpsw0_qsgmii_phyinit; run boot_rprocs; run get_kern_${boot}; run 
get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
 CONFIG_LOGLEVEL=7
 CONFIG_SPL_MAX_SIZE=0xc
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
-- 
2.25.1

Re: [PATCH] configs: am62: Add configs for enabling ETHBOOT in R5SPL

[Siddharth Vadapalli]

Hello,

Kindly ignore this patch.

On 11-04-2023 15:03, Siddharth Vadapalli wrote:
> From: Kishon Vijay Abraham I 
> 
> Add configs for enabling ETHBOOT in R5SPL. Adding a separate config
> minimizes the risk of going past the R5-SPL size limit for any future
> config additions.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> Signed-off-by: Andreas Dannenberg 
> Signed-off-by: Siddharth Vadapalli 
> ---
>  configs/am62x_evm_r5_ethboot_defconfig | 118 +
>  1 file changed, 118 insertions(+)
>  create mode 100644 configs/am62x_evm_r5_ethboot_defconfig
> 
> diff --git a/configs/am62x_evm_r5_ethboot_defconfig 
> b/configs/am62x_evm_r5_ethboot_defconfig
> new file mode 100644
> index 00..d9f642cad3
> --- /dev/null
> +++ b/configs/am62x_evm_r5_ethboot_defconfig
> @@ -0,0 +1,118 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_K3=y
> +CONFIG_SPL_GPIO_SUPPORT=y
> +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> +CONFIG_SYS_MALLOC_F_LEN=0x9000
> +CONFIG_SOC_K3_AM625=y
> +CONFIG_TARGET_AM625_R5_EVM=y
> +CONFIG_ENV_SIZE=0x2
> +CONFIG_ENV_OFFSET=0x68
> +CONFIG_DM_GPIO=y
> +CONFIG_SPL_TEXT_BASE=0x43c0
> +CONFIG_SPL_MMC_SUPPORT=y
> +CONFIG_SPL_SERIAL_SUPPORT=y
> +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
> +CONFIG_SPL_STACK_R_ADDR=0x8200
> +CONFIG_SPL_SIZE_LIMIT=0x4
> +CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x4000
> +CONFIG_SPL_FS_FAT=y
> +CONFIG_SPL_LIBDISK_SUPPORT=y
> +CONFIG_DEFAULT_DEVICE_TREE="k3-am625-r5-sk"
> +CONFIG_SPL_LOAD_FIT=y
> +CONFIG_SPL_LOAD_FIT_ADDRESS=0x8008
> +CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y
> +CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
> +CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y
> +CONFIG_SPL_BOARD_INIT=y
> +CONFIG_SPL_SYS_MALLOC_SIMPLE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_SEPARATE_BSS=y
> +CONFIG_SPL_EARLY_BSS=y
> +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
> +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400
> +CONFIG_SPL_DMA=y
> +CONFIG_SPL_ENV_SUPPORT=y
> +CONFIG_SPL_ETH_SUPPORT=y
> +CONFIG_SPL_I2C_SUPPORT=y
> +CONFIG_SPL_DM_MAILBOX=y
> +CONFIG_SPL_NET_SUPPORT=y
> +CONFIG_SPL_NET_VCI_STRING="AM62X U-Boot R5 SPL"
> +CONFIG_SPL_DM_RESET=y
> +CONFIG_SPL_POWER_DOMAIN=y
> +CONFIG_SPL_RAM_SUPPORT=y
> +CONFIG_SPL_RAM_DEVICE=y
> +CONFIG_SPL_REMOTEPROC=y
> +CONFIG_HUSH_PARSER=y
> +CONFIG_CMD_ASKENV=y
> +CONFIG_CMD_DFU=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_REMOTEPROC=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_DHCP=y
> +CONFIG_CMD_TIME=y
> +CONFIG_CMD_FAT=y
> +CONFIG_OF_CONTROL=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_SPL_MULTI_DTB_FIT=y
> +CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
> +CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_SYS_MMC_ENV_PART=1
> +CONFIG_DM=y
> +CONFIG_SPL_DM=y
> +CONFIG_SPL_DM_SEQ_ALIAS=y
> +CONFIG_REGMAP=y
> +CONFIG_SPL_REGMAP=y
> +CONFIG_SPL_OF_TRANSLATE=y
> +CONFIG_CLK=y
> +CONFIG_SPL_CLK=y
> +CONFIG_SPL_CLK_CCF=y
> +CONFIG_SPL_CLK_K3=y
> +CONFIG_SPL_CLK_K3_PLL=y
> +CONFIG_DMA_CHANNELS=y
> +CONFIG_TI_K3_NAVSS_UDMA=y
> +CONFIG_TI_SCI_PROTOCOL=y
> +CONFIG_DA8XX_GPIO=y
> +CONFIG_DM_I2C=y
> +CONFIG_SYS_I2C_OMAP24XX=y
> +CONFIG_DM_MAILBOX=y
> +CONFIG_K3_SEC_PROXY=y
> +CONFIG_DM_MMC=y
> +CONFIG_SPL_MMC_HS200_SUPPORT=y
> +CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_ADMA=y
> +CONFIG_SPL_MMC_SDHCI_ADMA=y
> +CONFIG_MMC_SDHCI_AM654=y
> +CONFIG_DM_SPI_FLASH=y
> +CONFIG_SPI_FLASH_SPANSION=y
> +CONFIG_SPI_FLASH_STMICRO=y
> +CONFIG_DM_ETH=y
> +CONFIG_TI_AM65_CPSW_NUSS=y
> +CONFIG_PINCTRL=y
> +# CONFIG_PINCTRL_GENERIC is not set
> +CONFIG_SPL_PINCTRL=y
> +# CONFIG_SPL_PINCTRL_GENERIC is not set
> +CONFIG_PINCTRL_SINGLE=y
> +CONFIG_POWER_DOMAIN=y
> +CONFIG_TI_POWER_DOMAIN=y
> +CONFIG_K3_SYSTEM_CONTROLLER=y
> +CONFIG_REMOTEPROC_TI_K3_ARM64=y
> +CONFIG_DM_RESET=y
> +CONFIG_RESET_TI_SCI=y
> +CONFIG_SPECIFY_CONSOLE_INDEX=y
> +CONFIG_DM_SERIAL=y
> +CONFIG_SOC_DEVICE=y
> +CONFIG_SOC_DEVICE_TI_K3=y
> +CONFIG_SOC_TI=y
> +CONFIG_SPI=y
> +CONFIG_DM_SPI=y
> +CONFIG_CADENCE_QSPI=y
> +CONFIG_TIMER=y
> +CONFIG_SPL_TIMER=y
> +CONFIG_OMAP_TIMER=y
> +CONFIG_LIB_RATIONAL=y
> +CONFIG_SPL_LIB_RATIONAL=y

-- 
Regards,
Siddharth.

Re: [PATCH v2 01/10] arm: dts: introduce j784s4 dtbs from linux kernel

[Siddharth Vadapalli]

Hello Hari,

On 21/03/23 19:40, Hari Nagalla wrote:
> Introduce the basic j784s4 SoC dtbs from the linux kernel along with
> the new j784s4 specific pinmux definitions that we will use to generate
> the dtbs for the u-boot-spl and u-boot binaries.
> 
> Signed-off-by: Apurva Nandan 
> Signed-off-by: Hari Nagalla 
> ---
>  arch/arm/dts/k3-j784s4-evm.dts |  196 +
>  arch/arm/dts/k3-j784s4-main.dtsi   | 1007 
>  arch/arm/dts/k3-j784s4-mcu-wakeup.dtsi |  311 
>  arch/arm/dts/k3-j784s4.dtsi|  287 +++
>  include/dt-bindings/pinctrl/k3.h   |3 +
>  5 files changed, 1804 insertions(+)
>  create mode 100644 arch/arm/dts/k3-j784s4-evm.dts
>  create mode 100644 arch/arm/dts/k3-j784s4-main.dtsi
>  create mode 100644 arch/arm/dts/k3-j784s4-mcu-wakeup.dtsi
>  create mode 100644 arch/arm/dts/k3-j784s4.dtsi
> 
> diff --git a/arch/arm/dts/k3-j784s4-evm.dts b/arch/arm/dts/k3-j784s4-evm.dts
> new file mode 100644
> index 00..8cd4a7ecc1
> --- /dev/null
> +++ b/arch/arm/dts/k3-j784s4-evm.dts
> @@ -0,0 +1,196 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
> + *

[...]

> +
> +&main_gpio0 {
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/k3-j784s4-main.dtsi 
> b/arch/arm/dts/k3-j784s4-main.dtsi
> new file mode 100644
> index 00..7edf324ac1
> --- /dev/null
> +++ b/arch/arm/dts/k3-j784s4-main.dtsi
> @@ -0,0 +1,1007 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for J784S4 SoC Family Main Domain peripherals
> + *
> + * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +&cbass_main {
> + msmc_ram: sram@7000 {
> + compatible = "mmio-sram";
> + reg = <0x00 0x7000 0x00 0x80>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x00 0x00 0x7000 0x80>;
> +
> + atf-sram@0 {
> + reg = <0x00 0x2>;
> + };
> +
> + tifs-sram@1f {
> + reg = <0x1f 0x1>;
> + };
> +
> + l3cache-sram@20 {

[...]

> +
> + main_navss: bus@3000 {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0x00 0x3000 0x00 0x3000 0x00 0x0c40>;

The property: ti,sci-dev-id = <280>; is missing here.
Please refer:
https://lore.kernel.org/r/20230314152611.140969-2-j-choudh...@ti.com/

> + dma-coherent;
> + dma-ranges;
> +
> + main_navss_intr: interrupt-controller@310e {
> + compatible = "ti,sci-intr";
> + reg = <0x00 0x310e 0x00 0x4000>;
> + ti,intr-trigger-type = <4>;
> + interrupt-controller;
> + interrupt-parent = <&gic500>;
> + #interrupt-cells = <1>;
> + ti,sci = <&sms>;
> + ti,sci-dev-id = <283>;
> + ti,interrupt-ranges = <0 64 64>,
> +   <64 448 64>,
> +   <128 672 64>;
> + };
> +

[...]

> + interrupt-names = "int0", "int1";
> + bosch,mram-cfg = <0x00 128 64 64 64 64 32 32>;
> + status = "disabled";
> + };
> +};
> diff --git a/arch/arm/dts/k3-j784s4-mcu-wakeup.dtsi 
> b/arch/arm/dts/k3-j784s4-mcu-wakeup.dtsi
> new file mode 100644
> index 00..93952af618
> --- /dev/null
> +++ b/arch/arm/dts/k3-j784s4-mcu-wakeup.dtsi
> @@ -0,0 +1,311 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for J784S4 SoC Family MCU/WAKEUP Domain peripherals
> + *
> + * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +&cbass_mcu_wakeup {
> + sms: system-controller@44083000 {
> + compatible = "ti,k2g-sci";
> + ti,host-id = <12>;
> +
> + mbox-names = "rx", "tx";
> +
> + mboxes = <&secure_proxy_main 11>,
> +  <&secure_proxy_main 13>;
> +
> + reg-names = "debug_messages";
> + reg = <0x00 0x44083000 0x00 0x1000>;
> +
> + k3_pds: power-controller {

[...]

> + interrupt-names = "int0", "int1";
> + bosch,mram-cfg = <0x00 128 64 64 64 64 32 32>;
> + status = "disabled";
> + };
> +
> + mcu_navss: bus@2838{
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0x00 0x2838 0x00 0x2838 0x00 0x0388>;

The property ti,sci-dev-id = <323>; is missing here.
Please refer:
https://lore.kernel.org/r/20230314152611.140969-2-j-choudh...@ti.com/

> + dma-coherent;
> + dma-ranges;

Re: [PATCH v2 02/10] arm: dts: introduce j784s4 u-boot dtbs

[Siddharth Vadapalli]

Hari,

On 21/03/23 19:40, Hari Nagalla wrote:
> Introduce the base dts files needed for u-boot or to augment the linux
> dtbs for use in the u-boot-spl and u-boot binaries.
> 
> Signed-off-by: Apurva Nandan 
> Signed-off-by: Hari Nagalla 
> ---
>  arch/arm/dts/Makefile|2 +
>  arch/arm/dts/k3-j784s4-ddr-evm-lp4-4266.dtsi | 8757 +
>  arch/arm/dts/k3-j784s4-ddr.dtsi  | 8858 ++
>  arch/arm/dts/k3-j784s4-evm-u-boot.dtsi   |  135 +
>  arch/arm/dts/k3-j784s4-r5-evm.dts|  209 +
>  5 files changed, 17961 insertions(+)
>  create mode 100644 arch/arm/dts/k3-j784s4-ddr-evm-lp4-4266.dtsi
>  create mode 100644 arch/arm/dts/k3-j784s4-ddr.dtsi
>  create mode 100644 arch/arm/dts/k3-j784s4-evm-u-boot.dtsi
>  create mode 100644 arch/arm/dts/k3-j784s4-r5-evm.dts
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 7a577deb50..7690fd21db 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1264,6 +1264,8 @@ dtb-$(CONFIG_SOC_K3_J721S2) += 
> k3-am68-sk-base-board.dtb\
>  k3-am68-sk-r5-base-board.dtb\
>  k3-j721s2-common-proc-board.dtb\
>  k3-j721s2-r5-common-proc-board.dtb

[...]

> +
> +&main_sdhci1 {
> + u-boot,dm-spl;
> +};
> diff --git a/arch/arm/dts/k3-j784s4-r5-evm.dts 
> b/arch/arm/dts/k3-j784s4-r5-evm.dts
> new file mode 100644
> index 00..7350a9be34
> --- /dev/null
> +++ b/arch/arm/dts/k3-j784s4-r5-evm.dts
> @@ -0,0 +1,209 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +/dts-v1/;
> +
> +#include "k3-j784s4.dtsi"
> +#include 
> +#include "k3-j784s4-ddr-evm-lp4-4266.dtsi"
> +#include "k3-j784s4-ddr.dtsi"

Based on the patch by Nishanth at:
https://lore.kernel.org/r/20230414075726.387461-13...@ti.com/

It might be better for "k3-j784s4-r5-evm.dts" to inherit "k3-j784s4-evm.dts" as
it will prevent duplication.

[...]

-- 
Regards,
Siddharth.

Re: [PATCH 3/6] net: ti: am65-cpsw-nuss: Add logic to support MDIO reset

[Siddharth Vadapalli]

Tom,

On 22/07/23 01:06, Tom Rini wrote:
> On Sat, Jul 08, 2023 at 04:15:20PM +0530, Siddharth Vadapalli wrote:
> 
>> From: Suman Anna 
>>
>> Enhance the AM65 CPSW NUSS driver to perform a MDIO reset using a GPIO
>> line. Logic is also added to perform a pre and post delay around reset
>> using the optional 'reset-delay-us' and 'reset-post-delay-us' properties.
>> This is similar to the reset being performed in the Linux kernel. The
>> reset is done once when the CPSW MDIO bus is being initialized.
>>
>> Signed-off-by: Suman Anna 
>> Signed-off-by: Siddharth Vadapalli 
>> ---
>>  drivers/net/ti/am65-cpsw-nuss.c | 34 -
>>  1 file changed, 33 insertions(+), 1 deletion(-)
> 
> So this breaks building on am62x_evm_a53 because now TI_AM65_CPSW_NUSS
> needs to select DM_GPIO.  And the next problem is that we don't enable a
> GPIO driver on that platform as we should I suspect make DA8XX_GPIO
> default y if K3.

Sorry for the delayed response. I am planning to address this issue by using:
#if CONFIG_IS_ENABLED(DM_GPIO)
in the driver, similar to how it is done for other ethernet drivers such as:
drivers/net/mvneta.c and drivers/net/mvpp2.c.

Also, the GPIO hog and reset capabilities are only required on those boards
which have the Ethernet PHY present on a daughtercard connected to the board.

I will post the v2 of this series with the above changes to fix the build
issues. Please let me know if the above approach is acceptable.

> 

-- 
Regards,
Siddharth.

Re: [PATCH 3/6] net: ti: am65-cpsw-nuss: Add logic to support MDIO reset

[Siddharth Vadapalli]

On 31/07/23 10:13, Siddharth Vadapalli wrote:
> Tom,
> 
> On 22/07/23 01:06, Tom Rini wrote:
>> On Sat, Jul 08, 2023 at 04:15:20PM +0530, Siddharth Vadapalli wrote:
>>
>>> From: Suman Anna 
>>>
>>> Enhance the AM65 CPSW NUSS driver to perform a MDIO reset using a GPIO
>>> line. Logic is also added to perform a pre and post delay around reset
>>> using the optional 'reset-delay-us' and 'reset-post-delay-us' properties.
>>> This is similar to the reset being performed in the Linux kernel. The
>>> reset is done once when the CPSW MDIO bus is being initialized.
>>>
>>> Signed-off-by: Suman Anna 
>>> Signed-off-by: Siddharth Vadapalli 
>>> ---
>>>  drivers/net/ti/am65-cpsw-nuss.c | 34 -
>>>  1 file changed, 33 insertions(+), 1 deletion(-)
>>
>> So this breaks building on am62x_evm_a53 because now TI_AM65_CPSW_NUSS
>> needs to select DM_GPIO.  And the next problem is that we don't enable a
>> GPIO driver on that platform as we should I suspect make DA8XX_GPIO
>> default y if K3.
> 
> Sorry for the delayed response. I am planning to address this issue by using:
> #if CONFIG_IS_ENABLED(DM_GPIO)

Instead of CONFIG_IS_ENABLED(DM_GPIO), I will use:
if (IS_ENABLED(CONFIG_DM_GPIO)) {
in the functions.

> in the driver, similar to how it is done for other ethernet drivers such as:
> drivers/net/mvneta.c and drivers/net/mvpp2.c.
> 
> Also, the GPIO hog and reset capabilities are only required on those boards
> which have the Ethernet PHY present on a daughtercard connected to the board.
> 
> I will post the v2 of this series with the above changes to fix the build
> issues. Please let me know if the above approach is acceptable.
> 
>>
> 

-- 
Regards,
Siddharth.

[PATCH v2 0/6] Add SGMII support for MAIN CPSW on TI's J7200 SoC

[Siddharth Vadapalli]

Hello,

This series adds support for SGMII mode to the CPSW driver to enable the
functionality on TI's J7200 SoC.

Supporting SGMII mode also requires changes to the WIZ driver which acts
as a wrapper for the SerDes used by the CPSW MAC to transmit data to the
Ethernet PHY daughtercard mounted on the I2C GPIO Expander 2 connector on
the J7200 EVM.

Powering on and resetting the Ethernet PHY requires MDIO support which
is added to the CPSW driver.

For supporting DMA transactions from the MAIN CPSW instance to the A72
Host on J7200 SoC, the corresponding PSI-L endpoint information is
added for the J721E SoC, which is applicable to J7200 SoC as well.

The SGMII daughtercard used for testing SGMII mode has TI's DP83869 PHY.
Thus, enable the config for DP83869 driver functionality. Also, enable
GPIO HOG config.

Regards,
Siddharth.

---
v1:
https://patchwork.ozlabs.org/project/uboot/list/?series=362969&state=%2A&archive=both
Changes since v1:
- Add checks in the am65-cpsw-nuss.c driver for the DM_GPIO config being 
enabled:
  if (IS_ENABLED(CONFIG_DM_GPIO))
  to fix build errors for SoCs which don't have DM_GPIO config enabled.
- Rebase series on commit 7755b22007 of u-boot master.

**NOTE**: This series is based on top of commit:
7755b22007 Merge tag 'x86-pull-20230801' of 
https://source.denx.de/u-boot/custodians/u-boot-x86

Siddharth Vadapalli (4):
  net: ti: am65-cpsw-nuss: Add support for SGMII mode
  phy: ti: phy-j721e-wiz: Add SGMII support in wiz driver for J7200
  phy: ti: j721e-wiz: Add SGMII support in WIZ driver for J721E
  configs: j7200_evm_a72: Enable configs for SGMII support with MAIN
CPSW0

Suman Anna (2):
  dma: ti: Update J21E PSIL endpoint information for MAIN CPSW0
  net: ti: am65-cpsw-nuss: Add logic to support MDIO reset

 configs/j7200_evm_a72_defconfig |  2 ++
 drivers/dma/ti/k3-psil-j721e.c  | 17 +++--
 drivers/net/ti/am65-cpsw-nuss.c | 61 -
 drivers/phy/ti/phy-j721e-wiz.c  | 21 
 4 files changed, 91 insertions(+), 10 deletions(-)

-- 
2.34.1

[PATCH v2 1/6] dma: ti: Update J21E PSIL endpoint information for MAIN CPSW0

[Siddharth Vadapalli]

From: Suman Anna 

The PSIL endpoint data for J721E currently covers only the MCU domain
CPSW0 instance. Add the data for the MAIN domain CPSW0 as well to allow
the MAIN domain Ethernet ports to be usable on any platform using J721E
SoC.

Additionally, since J721E's PSIL endpoint data is applicable to J7200
SoC as well, the MAIN CPSW0 instance on J7200 will also be usable now.

Signed-off-by: Suman Anna 
[s-vadapa...@ti.com: Update commit message indicating support for J7200]
Signed-off-by: Siddharth Vadapalli 
---
 drivers/dma/ti/k3-psil-j721e.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/ti/k3-psil-j721e.c b/drivers/dma/ti/k3-psil-j721e.c
index 105ffd946f..8e57e860f2 100644
--- a/drivers/dma/ti/k3-psil-j721e.c
+++ b/drivers/dma/ti/k3-psil-j721e.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- *  Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
+ *  Copyright (C) 2019-2023 Texas Instruments Incorporated - https://www.ti.com
  *  Author: Peter Ujfalusi 
  */
 
@@ -21,13 +21,15 @@
 
 /* PSI-L source thread IDs, used for RX (DMA_DEV_TO_MEM) */
 static struct psil_ep j721e_src_ep_map[] = {
-   /* CPSW0 */
+   /* MCU_CPSW0 */
PSIL_ETHERNET(0x7000),
+   /* MAIN_CPSW0 */
+   PSIL_ETHERNET(0x4a00),
 };
 
 /* PSI-L destination thread IDs, used for TX (DMA_MEM_TO_DEV) */
 static struct psil_ep j721e_dst_ep_map[] = {
-   /* CPSW0 */
+   /* MCU_CPSW0 */
PSIL_ETHERNET(0xf000),
PSIL_ETHERNET(0xf001),
PSIL_ETHERNET(0xf002),
@@ -36,6 +38,15 @@ static struct psil_ep j721e_dst_ep_map[] = {
PSIL_ETHERNET(0xf005),
PSIL_ETHERNET(0xf006),
PSIL_ETHERNET(0xf007),
+   /* MAIN_CPSW0 */
+   PSIL_ETHERNET(0xca00),
+   PSIL_ETHERNET(0xca01),
+   PSIL_ETHERNET(0xca02),
+   PSIL_ETHERNET(0xca03),
+   PSIL_ETHERNET(0xca04),
+   PSIL_ETHERNET(0xca05),
+   PSIL_ETHERNET(0xca06),
+   PSIL_ETHERNET(0xca07),
 };
 
 struct psil_ep_map j721e_ep_map = {
-- 
2.34.1

[PATCH v2 2/6] net: ti: am65-cpsw-nuss: Add support for SGMII mode

[Siddharth Vadapalli]

Add support for configuring the CPSW Ethernet Switch in SGMII mode.

Signed-off-by: Siddharth Vadapalli 
---
 drivers/net/ti/am65-cpsw-nuss.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 51a8167d14..456c3eb5b2 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -57,6 +57,12 @@
 #define AM65_CPSW_PN_REG_SA_L  0x308
 #define AM65_CPSW_PN_REG_SA_H  0x30c
 
+#define AM65_CPSW_SGMII_CONTROL_REG 0x010
+#define AM65_CPSW_SGMII_MR_ADV_ABILITY_REG  0x018
+#define AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLEBIT(0)
+
+#define ADVERTISE_SGMII0x1
+
 #define AM65_CPSW_ALE_CTL_REG  0x8
 #define AM65_CPSW_ALE_CTL_REG_ENABLE   BIT(31)
 #define AM65_CPSW_ALE_CTL_REG_RESET_TBLBIT(30)
@@ -92,6 +98,7 @@
 
 struct am65_cpsw_port {
fdt_addr_t  port_base;
+   fdt_addr_t  port_sgmii_base;
fdt_addr_t  macsl_base;
booldisabled;
u32 mac_control;
@@ -204,6 +211,8 @@ static int am65_cpsw_update_link(struct am65_cpsw_priv 
*priv)
mac_control |= AM65_CPSW_MACSL_CTL_REG_FULL_DUPLEX;
if (phy->speed == 100)
mac_control |= AM65_CPSW_MACSL_CTL_REG_IFCTL_A;
+   if (phy->interface == PHY_INTERFACE_MODE_SGMII)
+   mac_control |= AM65_CPSW_MACSL_CTL_EXT_EN;
}
 
if (mac_control == port->mac_control)
@@ -229,6 +238,7 @@ out:
 #define AM65_GMII_SEL_MODE_MII 0
 #define AM65_GMII_SEL_MODE_RMII1
 #define AM65_GMII_SEL_MODE_RGMII   2
+#define AM65_GMII_SEL_MODE_SGMII   3
 
 #define AM65_GMII_SEL_RGMII_IDMODE BIT(4)
 
@@ -280,6 +290,10 @@ static int am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv 
*priv,
rgmii_id = true;
break;
 
+   case PHY_INTERFACE_MODE_SGMII:
+   mode = AM65_GMII_SEL_MODE_SGMII;
+   break;
+
default:
dev_warn(dev,
 "Unsupported PHY mode: %u. Defaulting to MII.\n",
@@ -420,6 +434,13 @@ static int am65_cpsw_start(struct udevice *dev)
goto err_dis_rx;
}
 
+   if (priv->phydev->interface == PHY_INTERFACE_MODE_SGMII) {
+   writel(ADVERTISE_SGMII,
+  port->port_sgmii_base + 
AM65_CPSW_SGMII_MR_ADV_ABILITY_REG);
+   writel(AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE,
+  port->port_sgmii_base + AM65_CPSW_SGMII_CONTROL_REG);
+   }
+
ret = phy_startup(priv->phydev);
if (ret) {
dev_err(dev, "phy_startup failed\n");
@@ -872,6 +893,8 @@ static int am65_cpsw_probe_nuss(struct udevice *dev)
port->port_base = cpsw_common->cpsw_base +
  AM65_CPSW_CPSW_NU_PORTS_OFFSET +
  (i * AM65_CPSW_CPSW_NU_PORTS_OFFSET);
+   port->port_sgmii_base = cpsw_common->ss_base +
+   (i * AM65_CPSW_SGMII_BASE);
port->macsl_base = port->port_base +
   AM65_CPSW_CPSW_NU_PORT_MACSL_OFFSET;
}
-- 
2.34.1

[PATCH v2 3/6] net: ti: am65-cpsw-nuss: Add logic to support MDIO reset

[Siddharth Vadapalli]

From: Suman Anna 

Enhance the AM65 CPSW NUSS driver to perform a MDIO reset using a GPIO
line. Logic is also added to perform a pre and post delay around reset
using the optional 'reset-delay-us' and 'reset-post-delay-us' properties.
This is similar to the reset being performed in the Linux kernel. The
reset is done once when the CPSW MDIO bus is being initialized.

Signed-off-by: Suman Anna 
Signed-off-by: Siddharth Vadapalli 
---
 drivers/net/ti/am65-cpsw-nuss.c | 38 -
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 456c3eb5b2..f4e5809380 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "cpsw_mdio.h"
@@ -96,6 +98,8 @@
 
 #define AM65_CPSW_CPPI_PKT_TYPE0x7
 
+#define DEFAULT_GPIO_RESET_DELAY   10
+
 struct am65_cpsw_port {
fdt_addr_t  port_base;
fdt_addr_t  port_sgmii_base;
@@ -120,6 +124,10 @@ struct am65_cpsw_common {
struct mii_dev  *bus;
u32 bus_freq;
 
+   struct gpio_descmdio_gpio_reset;
+   u32 reset_delay_us;
+   u32 reset_post_delay_us;
+
struct dma  dma_tx;
struct dma  dma_rx;
u32 rx_next;
@@ -679,6 +687,16 @@ static int am65_cpsw_mdio_init(struct udevice *dev)
if (!priv->has_phy || cpsw_common->bus)
return 0;
 
+   if (IS_ENABLED(CONFIG_DM_GPIO)) {
+   if (dm_gpio_is_valid(&cpsw_common->mdio_gpio_reset)) {
+   dm_gpio_set_value(&cpsw_common->mdio_gpio_reset, 1);
+   udelay(cpsw_common->reset_delay_us);
+   dm_gpio_set_value(&cpsw_common->mdio_gpio_reset, 0);
+   if (cpsw_common->reset_post_delay_us > 0)
+   udelay(cpsw_common->reset_post_delay_us);
+   }
+   }
+
ret = am65_cpsw_mdio_setup(dev);
if (ret)
return ret;
@@ -818,7 +836,7 @@ out:
 static int am65_cpsw_probe_nuss(struct udevice *dev)
 {
struct am65_cpsw_common *cpsw_common = dev_get_priv(dev);
-   ofnode ports_np, node;
+   ofnode ports_np, node, mdio_np;
int ret, i;
struct udevice *port_dev;
 
@@ -845,6 +863,24 @@ static int am65_cpsw_probe_nuss(struct udevice *dev)
AM65_CPSW_CPSW_NU_ALE_BASE;
cpsw_common->mdio_base = cpsw_common->ss_base + AM65_CPSW_MDIO_BASE;
 
+   if (IS_ENABLED(CONFIG_DM_GPIO)) {
+   /* get bus level PHY reset GPIO details */
+   mdio_np = dev_read_subnode(dev, "mdio");
+   if (!ofnode_valid(mdio_np)) {
+   ret = -ENOENT;
+   goto out;
+   }
+
+   cpsw_common->reset_delay_us = ofnode_read_u32_default(mdio_np, 
"reset-delay-us",
+ 
DEFAULT_GPIO_RESET_DELAY);
+   cpsw_common->reset_post_delay_us = 
ofnode_read_u32_default(mdio_np,
+  
"reset-post-delay-us",
+  0);
+   ret = gpio_request_by_name_nodev(mdio_np, "reset-gpios", 0,
+&cpsw_common->mdio_gpio_reset,
+GPIOD_IS_OUT | 
GPIOD_IS_OUT_ACTIVE);
+   }
+
ports_np = dev_read_subnode(dev, "ethernet-ports");
if (!ofnode_valid(ports_np)) {
ret = -ENOENT;
-- 
2.34.1

[PATCH v2 4/6] phy: ti: phy-j721e-wiz: Add SGMII support in wiz driver for J7200

[Siddharth Vadapalli]

Select the same mac divider for SGMII too as the one being used for
QSGMII.

Enable full rate divider configuration support for J721E_WIZ_10G for
SGMII.

Signed-off-by: Siddharth Vadapalli 
---
 drivers/phy/ti/phy-j721e-wiz.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 34314d0bd1..cba87f5093 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -585,12 +585,18 @@ static int wiz_reset_assert(struct reset_ctl *reset_ctl)
 
 static int wiz_phy_fullrt_div(struct wiz *wiz, int lane)
 {
-   if (wiz->type != AM64_WIZ_10G)
+   switch (wiz->type) {
+   case AM64_WIZ_10G:
+   if (wiz->lane_phy_type[lane] == PHY_TYPE_PCIE)
+   return regmap_field_write(wiz->p0_fullrt_div[lane], 
0x1);
+   break;
+   case J721E_WIZ_10G:
+   if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
+   return regmap_field_write(wiz->p0_fullrt_div[lane], 
0x2);
+   break;
+   default:
return 0;
-
-   if (wiz->lane_phy_type[lane] == PHY_TYPE_PCIE)
-   return regmap_field_write(wiz->p0_fullrt_div[lane], 0x1);
-
+   }
return 0;
 }
 
@@ -706,7 +712,8 @@ static int wiz_p_mac_div_sel(struct wiz *wiz)
int i;
 
for (i = 0; i < num_lanes; i++) {
-   if (wiz->lane_phy_type[i] == PHY_TYPE_QSGMII) {
+   if (wiz->lane_phy_type[i] == PHY_TYPE_SGMII ||
+   wiz->lane_phy_type[i] == PHY_TYPE_QSGMII) {
ret = regmap_field_write(wiz->p_mac_div_sel0[i], 1);
if (ret)
return ret;
-- 
2.34.1

[PATCH v2 5/6] phy: ti: j721e-wiz: Add SGMII support in WIZ driver for J721E

[Siddharth Vadapalli]

Enable full rate divider configuration support for J721E_WIZ_16G for SGMII.

Signed-off-by: Siddharth Vadapalli 
---
 drivers/phy/ti/phy-j721e-wiz.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index cba87f5093..7261339907 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -590,6 +590,8 @@ static int wiz_phy_fullrt_div(struct wiz *wiz, int lane)
if (wiz->lane_phy_type[lane] == PHY_TYPE_PCIE)
return regmap_field_write(wiz->p0_fullrt_div[lane], 
0x1);
break;
+
+   case J721E_WIZ_16G:
case J721E_WIZ_10G:
if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
return regmap_field_write(wiz->p0_fullrt_div[lane], 
0x2);
-- 
2.34.1

[PATCH v2 6/6] configs: j7200_evm_a72: Enable configs for SGMII support with MAIN CPSW0

[Siddharth Vadapalli]

The MAIN CPSW0 instance of CPSW Ethernet Switch on TI's J7200 SoC
supports SGMII mode. To enable support for utilizing the SGMII
daughtercard with TI's DP83869 PHY, enable the corresponding config.

Also, since the SGMII daughtercard is connected to the I2C GPIO
Expander 2 connector on the J7200 EVM, powering on the Ethernet PHY and
resetting it requires GPIO Hogging capability. Enable it as well.

Signed-off-by: Siddharth Vadapalli 
---
 configs/j7200_evm_a72_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig
index c68d52537e..8dad928493 100644
--- a/configs/j7200_evm_a72_defconfig
+++ b/configs/j7200_evm_a72_defconfig
@@ -115,6 +115,7 @@ CONFIG_FASTBOOT_FLASH=y
 CONFIG_FASTBOOT_FLASH_MMC_DEV=0
 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_GPIO_HOG=y
 CONFIG_DA8XX_GPIO=y
 CONFIG_DM_PCA953X=y
 CONFIG_DM_I2C=y
@@ -147,6 +148,7 @@ CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_MULTIPLEXER=y
 CONFIG_MUX_MMIO=y
+CONFIG_PHY_TI_DP83869=y
 CONFIG_PHY_FIXED=y
 CONFIG_TI_AM65_CPSW_NUSS=y
 CONFIG_PHY=y
-- 
2.34.1

[PATCH] net: Fix the displayed value of bytes transferred

[Siddharth Vadapalli]

In the case of NETLOOP_SUCCESS, the decimal value of the u32 variable
"net_boot_file_size" is printed using "%d", resulting in negative values
being reported for large file sizes. Fix this by using "%lu" to print
the decimal value corresponding to the bytes transferred.

Fixes: 1411157d8578 ("net: cosmetic: Fixup var names related to boot file")
Signed-off-by: Siddharth Vadapalli 
---
 net/net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/net.c b/net/net.c
index 43abbac7c3..7aaeafc247 100644
--- a/net/net.c
+++ b/net/net.c
@@ -716,7 +716,7 @@ restart:
case NETLOOP_SUCCESS:
net_cleanup_loop();
if (net_boot_file_size > 0) {
-   printf("Bytes transferred = %d (%x hex)\n",
+   printf("Bytes transferred = %lu (%x hex)\n",
   net_boot_file_size, net_boot_file_size);
env_set_hex("filesize", net_boot_file_size);
env_set_hex("fileaddr", image_load_addr);
-- 
2.34.1

Re: [PATCH] net: Fix the displayed value of bytes transferred

[Siddharth Vadapalli]

Ravi,

On 10/08/23 17:00, Ravi Gunasekaran wrote:
> Siddharth,
> 
> On 8/10/23 2:45 PM, Siddharth Vadapalli wrote:
>> In the case of NETLOOP_SUCCESS, the decimal value of the u32 variable
>> "net_boot_file_size" is printed using "%d", resulting in negative values
>> being reported for large file sizes. Fix this by using "%lu" to print
>> the decimal value corresponding to the bytes transferred.
>>
>> Fixes: 1411157d8578 ("net: cosmetic: Fixup var names related to boot file")
>> Signed-off-by: Siddharth Vadapalli 
>> ---
>>  net/net.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/net.c b/net/net.c
>> index 43abbac7c3..7aaeafc247 100644
>> --- a/net/net.c
>> +++ b/net/net.c
>> @@ -716,7 +716,7 @@ restart:
>>  case NETLOOP_SUCCESS:
>>  net_cleanup_loop();
>>  if (net_boot_file_size > 0) {
>> -printf("Bytes transferred = %d (%x hex)\n",
>> +printf("Bytes transferred = %lu (%x hex)\n",
> 
> 'net_boot_file_size' is of type u32. Using "%lu" will throw a warning for 
> this.
> As per [0], format specifier for 'unsigned int' is "%d, %x'.
> 
> You could perhaps change the data type of 'net_boot_file_size' to 'ulong' as 
> well.

The issue here isn't the size of the variable itself, but the format specifier.
For large file sizes, the hex value printed for the variable is correct, but the
decimal value is negative.

> 
> [0] - https://u-boot.readthedocs.io/en/latest/develop/printf.html
> 
>> net_boot_file_size, net_boot_file_size);
>>  env_set_hex("filesize", net_boot_file_size);
>>  env_set_hex("fileaddr", image_load_addr);
> 

-- 
Regards,
Siddharth.

Re: [PATCH] net: Fix the displayed value of bytes transferred

[Siddharth Vadapalli]

Hello Tom,

On 11/08/23 21:45, Tom Rini wrote:
> On Fri, Aug 11, 2023 at 10:49:23AM +0530, Siddharth Vadapalli wrote:
>> Ravi,
>>
>> On 10/08/23 17:00, Ravi Gunasekaran wrote:
>>> Siddharth,
>>>
>>> On 8/10/23 2:45 PM, Siddharth Vadapalli wrote:
>>>> In the case of NETLOOP_SUCCESS, the decimal value of the u32 variable
>>>> "net_boot_file_size" is printed using "%d", resulting in negative values
>>>> being reported for large file sizes. Fix this by using "%lu" to print
>>>> the decimal value corresponding to the bytes transferred.
>>>>
>>>> Fixes: 1411157d8578 ("net: cosmetic: Fixup var names related to boot file")
>>>> Signed-off-by: Siddharth Vadapalli 
>>>> ---
>>>>  net/net.c | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/net/net.c b/net/net.c
>>>> index 43abbac7c3..7aaeafc247 100644
>>>> --- a/net/net.c
>>>> +++ b/net/net.c
>>>> @@ -716,7 +716,7 @@ restart:
>>>>case NETLOOP_SUCCESS:
>>>>net_cleanup_loop();
>>>>if (net_boot_file_size > 0) {
>>>> -  printf("Bytes transferred = %d (%x hex)\n",
>>>> +  printf("Bytes transferred = %lu (%x hex)\n",
>>>
>>> 'net_boot_file_size' is of type u32. Using "%lu" will throw a warning for 
>>> this.
>>> As per [0], format specifier for 'unsigned int' is "%d, %x'.
>>>
>>> You could perhaps change the data type of 'net_boot_file_size' to 'ulong' 
>>> as well.
>>
>> The issue here isn't the size of the variable itself, but the format 
>> specifier.
>> For large file sizes, the hex value printed for the variable is correct, but 
>> the
>> decimal value is negative.
>>
>>>
>>> [0] - https://u-boot.readthedocs.io/en/latest/develop/printf.html
> 
> Uh, maybe I'm just missing something, but I think there's two things.
> First, this should be "%u" for "unsigned decimal".  Second,
> doc/develop/printf.rst needs to be fixed since:
> int %d, %x
> unsigned int%d, %x
> 
> Should is wrong and should say %u, %x, because, well, that's what would
> be correct, yes?

Thank you for reviewing the patch. Yes, %u works well and can print u32 variable
accurately. I tested it for 0x. %d prints -1 for the same. So, %lu isn't
necessary and %u is sufficient. I will replace %lu with %u and post the v2
patch. Additionally, I will include a patch in the v2 series to update the
Documentation as pointed out by you.

> 

-- 
Regards,
Siddharth.

[PATCH v2 0/2] Fix format specifier for net_boot_file_size

[Siddharth Vadapalli]

Hello,

This series fixes the format specifier for printing the decimal value of
the variable "net_boot_file_size", changing it from "%d" to "%u". With
the format specifier being "%d", for large file sizes, the value
displayed is negative. Using "%u" fixes this.

Additionally, as reported by Tom Rini  in the mail
thread corresponding to the v1 patch of this series, the documentation
for the printf format specifiers needs to be fixed for the "unsigned
int" variable. Thus, update the documentation as well.

Regards,
Siddharth.

---
v1:
https://patchwork.ozlabs.org/project/uboot/patch/20230810091523.3168975-1-s-vadapa...@ti.com/

Changes since v1:
- Use "%u" instead of "%lu" to display the decimal value of the u32
  variable "net_boot_file_size", as suggested by Tom Rini.
- Add a new patch to update the documentation for printf format
  specifiers, changing the format specifier from "%d" to "%u" for the
  "unsigned int" variable, as reported by Tom Rini.

Siddharth Vadapalli (2):
  net: Fix the displayed value of bytes transferred
  doc: printf() codes: Fix format specifier for unsigned int

 doc/develop/printf.rst | 2 +-
 net/net.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.34.1

[PATCH v2 1/2] net: Fix the displayed value of bytes transferred

[Siddharth Vadapalli]

In the case of NETLOOP_SUCCESS, the decimal value of the u32 variable
"net_boot_file_size" is printed using "%d", resulting in negative values
being reported for large file sizes. Fix this by using "%u" to print the
decimal value corresponding to the bytes transferred.

Fixes: 1411157d8578 ("net: cosmetic: Fixup var names related to boot file")
Signed-off-by: Siddharth Vadapalli 
---
 net/net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/net.c b/net/net.c
index 43abbac7c3..e6f61f0f8f 100644
--- a/net/net.c
+++ b/net/net.c
@@ -716,7 +716,7 @@ restart:
case NETLOOP_SUCCESS:
net_cleanup_loop();
if (net_boot_file_size > 0) {
-   printf("Bytes transferred = %d (%x hex)\n",
+   printf("Bytes transferred = %u (%x hex)\n",
   net_boot_file_size, net_boot_file_size);
env_set_hex("filesize", net_boot_file_size);
env_set_hex("fileaddr", image_load_addr);
-- 
2.34.1

[PATCH v2 2/2] doc: printf() codes: Fix format specifier for unsigned int

[Siddharth Vadapalli]

The format specifier for the "unsigned int" variable is documented as
"%d". However, it should be "%u". Thus, fix it.

Fixes: f5e9035043fb ("doc: printf() codes")
Reported-by: Tom Rini 
Signed-off-by: Siddharth Vadapalli 
---
 doc/develop/printf.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/develop/printf.rst b/doc/develop/printf.rst
index 7b9aea0687..05909a1f22 100644
--- a/doc/develop/printf.rst
+++ b/doc/develop/printf.rst
@@ -111,7 +111,7 @@ unsigned char   %u, %x
 short   %d, %x
 unsigned short  %u, %x
 int %d, %x
-unsigned int%d, %x
+unsigned int%u, %x
 long%ld, %lx
 unsigned long   %lu, %lx
 long long   %lld, %llx
-- 
2.34.1

Re: [PATCH] net: Fix the displayed value of bytes transferred

[Siddharth Vadapalli]

On 14/08/23 10:06, Siddharth Vadapalli wrote:
> Hello Tom,
> 
> On 11/08/23 21:45, Tom Rini wrote:
>> On Fri, Aug 11, 2023 at 10:49:23AM +0530, Siddharth Vadapalli wrote:
>>> Ravi,
>>>
>>> On 10/08/23 17:00, Ravi Gunasekaran wrote:

...

>>
>> Uh, maybe I'm just missing something, but I think there's two things.
>> First, this should be "%u" for "unsigned decimal".  Second,
>> doc/develop/printf.rst needs to be fixed since:
>> int %d, %x
>> unsigned int%d, %x
>>
>> Should is wrong and should say %u, %x, because, well, that's what would
>> be correct, yes?
> 
> Thank you for reviewing the patch. Yes, %u works well and can print u32 
> variable
> accurately. I tested it for 0x. %d prints -1 for the same. So, %lu 
> isn't
> necessary and %u is sufficient. I will replace %lu with %u and post the v2
> patch. Additionally, I will include a patch in the v2 series to update the
> Documentation as pointed out by you.

I have posted the v2 series at:
https://patchwork.ozlabs.org/project/uboot/list/?series=368661&state=%2A&archive=both

> 
>>
> 

-- 
Regards,
Siddharth.

[PATCH] include: env: ti: ti_common: Run main_cpsw0_qsgmii_phyinit conditionally

[Siddharth Vadapalli]

From: Manorit Chawdhry 

The main_cpsw0_qsgmii_phyinit command is defined only for certain TI
SoCs which have the do_main_cpsw0_qsgmii_phyinit variable set.

Add a check to ensure that the main_cpsw0_qsgmii_phyinit command is run
only for such SoCs.

Signed-off-by: Manorit Chawdhry 
Signed-off-by: Siddharth Vadapalli 
---

Hello,

This patch is based on commit
65eed68772 test/py: Disable error E0611 in two cases for pylint

Regards,
Siddharth.

 include/env/ti/ti_common.env | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/env/ti/ti_common.env b/include/env/ti/ti_common.env
index f5d84216e3..f0f89a2287 100644
--- a/include/env/ti/ti_common.env
+++ b/include/env/ti/ti_common.env
@@ -25,7 +25,10 @@ run_fit=run get_fit_config; bootm 
${addr_fit}#${name_fit_config}${overlaystring}
 bootcmd_ti_mmc=
run findfdt; run init_${boot};
 #if CONFIG_CMD_REMOTEPROC
-   run main_cpsw0_qsgmii_phyinit; run boot_rprocs;
+   if test ${do_main_cpsw0_qsgmii_phyinit} -eq 1;
+   then run main_cpsw0_qsgmii_phyinit;
+   fi
+   run boot_rprocs;
 #endif
if test ${boot_fit} -eq 1;
then run get_fit_${boot}; run get_fit_overlaystring; run 
run_fit;
-- 
2.34.1

[PATCH] board/include: ti/env: j721e.env/ti_common: Fix cpsw0_qsgmii_phyinit

[Siddharth Vadapalli]

The command "main_cpsw0_qsgmii_phyinit" has to be run depending on
whether or not the "do_main_cpsw0_qsgmii_phyinit" variable is set.
However, there is no support for the cases where the environment variable
"do_main_cpsw0_qsgmii_phyinit" is updated at runtime. On J721E, the value
of "do_main_cpsw0_qsgmii_phyinit" is updated at runtime.

Fix the existing implementation in order to handle the case where the
value of "do_main_cpsw0_qsgmii_phyinit" is updated at runtime. Do so by
introducing the environment variable "update_do_main_cpsw0_qsgmii_phyinit"
which defaults to setting "do_main_cpsw0_qsgmii_phyinit" to zero, but at
the same time, it allows the board to update the value at runtime.

Fixes: 0d72b0f2f83b ("include: env: ti: ti_common: Run 
main_cpsw0_qsgmii_phyinit conditionally")
Signed-off-by: Siddharth Vadapalli 
---

Hello,

This patch is based on commit
899b088674 Merge patch series "pxe: Add debugging for booting"
of U-Boot's next branch.

Regards,
Siddharth.

 board/ti/j721e/j721e.env | 9 +
 include/env/ti/ti_common.env | 3 ++-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/board/ti/j721e/j721e.env b/board/ti/j721e/j721e.env
index 38bfd7d496..03d7e81aa8 100644
--- a/board/ti/j721e/j721e.env
+++ b/board/ti/j721e/j721e.env
@@ -29,7 +29,7 @@ bootdir=/boot
 rd_spec=-
 
 #if CONFIG_TARGET_J7200_A72_EVM
-do_main_cpsw0_qsgmii_phyinit=1
+update_do_main_cpsw0_qsgmii_phyinit=setenv do_main_cpsw0_qsgmii_phyinit 1;
 init_main_cpsw0_qsgmii_phy=gpio set gpio@22_17;
gpio clear gpio@22_16
 main_cpsw0_qsgmii_phyinit=
@@ -39,10 +39,11 @@ main_cpsw0_qsgmii_phyinit=
 #elif CONFIG_TARGET_J721E_A72_EVM
 init_main_cpsw0_qsgmii_phy=gpio set gpio@22_17;
gpio clear gpio@22_16
-main_cpsw0_qsgmii_phyinit=
+update_do_main_cpsw0_qsgmii_phyinit=
if test $board_name = J721EX-PM1-SOM || test $board_name = 
J721EX-PM2-SOM || test $board_name = j721e; then
-   do_main_cpsw0_qsgmii_phyinit=1; else
-   do_main_cpsw0_qsgmii_phyinit=0; fi;
+   setenv do_main_cpsw0_qsgmii_phyinit 1; else
+   setenv do_main_cpsw0_qsgmii_phyinit 0; fi;
+main_cpsw0_qsgmii_phyinit=
if test ${do_main_cpsw0_qsgmii_phyinit} -eq 1 && test ${dorprocboot} 
-eq 1 && test ${boot} = mmc; then
run init_main_cpsw0_qsgmii_phy; \
fi;
diff --git a/include/env/ti/ti_common.env b/include/env/ti/ti_common.env
index c5c3642177..d0b3d698a0 100644
--- a/include/env/ti/ti_common.env
+++ b/include/env/ti/ti_common.env
@@ -23,9 +23,10 @@ get_fit_overlaystring=
done;
 get_fit_config=setexpr name_fit_config gsub / _ conf-${fdtfile}
 run_fit=run get_fit_config; bootm 
${addr_fit}#${name_fit_config}${overlaystring}
-do_main_cpsw0_qsgmii_phyinit=0
+update_do_main_cpsw0_qsgmii_phyinit=setenv do_main_cpsw0_qsgmii_phyinit 0;
 bootcmd_ti_mmc=
run findfdt; run init_${boot};
+   run update_do_main_cpsw0_qsgmii_phyinit;
 #if CONFIG_CMD_REMOTEPROC
if test ${do_main_cpsw0_qsgmii_phyinit} -eq 1;
then run main_cpsw0_qsgmii_phyinit;
-- 
2.40.1

[PATCH] usb: cdns3: continue probe even when USB PHY device does not exist

[Siddharth Vadapalli]

Prior to commit cd295286c786 ("usb: cdns3: avoid error messages if phys
don't exist"), cdns3_probe() errors out only on failing to initialize the
USB2/USB3 PHY. However, since commit cd295286c786, absence of the PHY
device is also treated as an error, resulting in a regression.

Extend commit cd295286c786 to treat -ENODEV as an acceptable return value
of generic_phy_get_by_name() and continue device probe as was the case
prior to the commit.

Fixes: cd295286c786 ("usb: cdns3: avoid error messages if phys don't exist")
Signed-off-by: Siddharth Vadapalli 
---

Hello,

This patch is based on commit
b4cbd1a257 Merge tag 'u-boot-amlogic-20240701' of 
https://source.denx.de/u-boot/custodians/u-boot-amlogic into next
of the next branch of U-Boot.

Regards,
Siddharth.

 drivers/usb/cdns3/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
index b4e931646b..5b3e32953e 100644
--- a/drivers/usb/cdns3/core.c
+++ b/drivers/usb/cdns3/core.c
@@ -338,7 +338,7 @@ static int cdns3_probe(struct cdns3 *cdns)
dev_err(dev, "USB2 PHY init failed: %d\n", ret);
return ret;
}
-   } else if (ret != -ENOENT && ret != -ENODATA) {
+   } else if (ret != -ENOENT && ret != -ENODATA && ret != -ENODEV) {
dev_err(dev, "Couldn't get USB2 PHY:  %d\n", ret);
return ret;
}
@@ -350,7 +350,7 @@ static int cdns3_probe(struct cdns3 *cdns)
dev_err(dev, "USB3 PHY init failed: %d\n", ret);
return ret;
}
-   } else if (ret != -ENOENT && ret != -ENODATA) {
+   } else if (ret != -ENOENT && ret != -ENODATA && ret != -ENODEV) {
dev_err(dev, "Couldn't get USB3 PHY:  %d\n", ret);
return ret;
}
-- 
2.40.1

Re: [PATCH] usb: cdns3: continue probe even when USB PHY device does not exist

[Siddharth Vadapalli]

On Tue, Jul 02, 2024 at 04:20:43PM +0300, Roger Quadros wrote:
> 
> 
> On 02/07/2024 15:07, Siddharth Vadapalli wrote:
> > Prior to commit cd295286c786 ("usb: cdns3: avoid error messages if phys
> > don't exist"), cdns3_probe() errors out only on failing to initialize the
> > USB2/USB3 PHY. However, since commit cd295286c786, absence of the PHY
> > device is also treated as an error, resulting in a regression.
> > 
> > Extend commit cd295286c786 to treat -ENODEV as an acceptable return value
> > of generic_phy_get_by_name() and continue device probe as was the case
> > prior to the commit.
> > 
> > Fixes: cd295286c786 ("usb: cdns3: avoid error messages if phys don't exist")
> > Signed-off-by: Siddharth Vadapalli 
> > ---
> > 
> > Hello,
> > 
> > This patch is based on commit
> > b4cbd1a257 Merge tag 'u-boot-amlogic-20240701' of 
> > https://source.denx.de/u-boot/custodians/u-boot-amlogic into next
> > of the next branch of U-Boot.
> > 
> > Regards,
> > Siddharth.
> > 
> >  drivers/usb/cdns3/core.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
> > index b4e931646b..5b3e32953e 100644
> > --- a/drivers/usb/cdns3/core.c
> > +++ b/drivers/usb/cdns3/core.c
> > @@ -338,7 +338,7 @@ static int cdns3_probe(struct cdns3 *cdns)
> > dev_err(dev, "USB2 PHY init failed: %d\n", ret);
> > return ret;
> > }
> > -   } else if (ret != -ENOENT && ret != -ENODATA) {
> > +   } else if (ret != -ENOENT && ret != -ENODATA && ret != -ENODEV) {
> 
> With this change we will not error out on a genuine error condition
> that produces ENODEV.

It isn't necessarily a genuine error condition which is why it was a
"dev_warn" earlier for any error. If the previous stage has already
configured the PHY, or if the PHY present in the device-tree in Linux is
not the same as the PHY being used at U-Boot (USB 2 PHY at U-Boot vs
SERDES in Linux), then it isn't an error.

> 
> If PHY phandle is not present the API should return ENOENT right?
> 
> static int __of_parse_phandle_with_args(const struct device_node *np,
> 
> /* Retrieve the phandle list property */
> list = of_get_property(np, list_name, &size);
> if (!list)
> return -ENOENT;

The PHY phandle is present, but it isn't the one being used by U-Boot.
The device-tree could be pointing to SERDES as the PHY, since Linux uses
USB with SERDES. So the entry exists, but the error is -ENODEV rather
than -ENOENT.

> 
> Can you please check and point where the -ENODEV error is coming from?

The sequence of function calls is as follows:
generic_phy_get_by_name
  generic_phy_get_by_index
generic_phy_get_by_index_nodev
  uclass_get_device_by_ofnode
uclass_find_device_by_ofnode
  -ENODEV

In the above sequence, the device-tree contains SERDES PHY as the USB
PHY since Linux uses the same and U-Boot's device-tree is in sync with
Linux's. However, USB at U-Boot will use the USB 2 PHY. So one option is
to remove the SERDES PHY from USB node to have it fallback to USB 2 PHY.
At the same time, if the previous stage has configured SERDES for example,
it might not be necessary to reconfigure SERDES. -ENODEV might be an
acceptable error in such a situation as well. Please let me know.

[...]

Regards,
Siddharth.

[PATCH 00/10] Add support for Ethernet Boot on SK-AM62

[Siddharth Vadapalli]

Hello,

This series enables Ethernet Boot on SK-AM62 device.
Product Link: https://www.ti.com/tool/SK-AM62
User Guide: https://www.ti.com/lit/pdf/spruj40

Ethernet Boot flow is as follows:
1. The BOOT MODE pins are configured for Ethernet Boot.
2. On powering on the device, ROM uses the Ethernet Port corresponding
to CPSW3G's MAC Port 1 to transmit "TI K3 Bootp Boot".
3. The TFTP server and DHCP server on the receiver device need to be
configured such that VCI string "TI K3 Bootp Boot" maps to the file
"tiboot3.bin" and the TFTP server should be capable of transferring
it to the device.
4. ROM loads and executes "tiboot3.bin" provided by the TFTP server.
5. The "tiboot3.bin" file is expected to be built using the config:
am62x_evm_r5_ethboot_defconfig
introduced in this series, which shall enable "tispl.bin" to be fetched
over TFTP using "tiboot3.bin".
6. "tiboot3.bin" is configured to transmit "AM62X U-Boot R5 SPL" as its
NET_VCI_STRING, thereby implying that the DHCP server and TFTP server
need to be configured to transfer "tispl.bin" to the device.
7. "tiboot3.bin" loads and executes "tispl.bin" provided by the TFTP
server.
8. The "tispl.bin" file is expected to be built using the config:
am62x_evm_a53_defconfig
which has been updated in this series to enable Ethernet Boot specific
configs, allowing "u-boot.img" to be fetched over TFTP using
"tispl.bin".
9. "tispl.bin" is configured to transmit "AM62X U-Boot A53 SPL" as its
NET_VCI_STRING. The DHCP server and TFTP server need to be configured to
transfer "u-boot.img" to the device for the aforementioned NET_VCI_STRING.
10. "tispl.bin" then fetches "u-boot.img" using TFTP and loads and
executes it on the device, completing the process of Ethernet Boot on the
device.

NOTE: ROM configures CPSW3G's MAC Port 1 for 100 Mbps full-duplex mode
of operation due to which it is expected that the Link Partner also
supports the same mode of operation.
Additionally, enabling "phy_gmii_sel" node at SPL stage will be
necessary and is not added as a part of this series with the aim of
adding the "bootph-all" property to its counterpart in Linux device-tree
first.

This series is based on commit:
f28a77589e Merge tag 'dm-next-7jan23' of 
https://source.denx.de/u-boot/custodians/u-boot-dm into next
of the next branch of u-boot.

Regards,
Siddharth.

Andreas Dannenberg (1):
  arm: mach-k3: am62: Update SoC autogenerated data to enable Ethernet
Boot

Kishon Vijay Abraham I (7):
  board: ti: am62x: Init DRAM size in R5/A53 SPL
  firmware: ti_sci: Add No-OP for "RX_FL_CFG"
  soc: ti: k3-navss-ringacc: Initialize base address of ring cfg
registers
  dma: ti: k3-udma: Add support for native configuration of chan/flow
  arm: mach-k3: am625_init: Probe AM65 CPSW NUSS
  configs: am62: Add configs for enabling ETHBOOT in R5SPL
  configs: am62x_evm_a53_defconfig: Enable configs required for Ethboot

Siddharth Vadapalli (1):
  arm: dts: k3-am625-r5-sk: Enable DM services for main_pktdma

Vignesh Raghavendra (1):
  soc: ti: k3-navss-ringacc: Fix reset ring API

 arch/arm/dts/k3-am625-r5-sk.dts  |   5 ++
 arch/arm/mach-k3/am625_init.c|  10 +++
 arch/arm/mach-k3/r5/am62x/clk-data.c |  79 
 board/ti/am62x/evm.c |   3 +
 configs/am62x_evm_a53_defconfig  |   8 ++
 configs/am62x_evm_r5_ethboot_defconfig   | 110 +++
 drivers/dma/ti/k3-udma.c |   6 ++
 drivers/firmware/ti_sci.c|   8 +-
 drivers/soc/ti/k3-navss-ringacc-u-boot.c |   9 +-
 drivers/soc/ti/k3-navss-ringacc.c|   7 +-
 10 files changed, 202 insertions(+), 43 deletions(-)
 create mode 100644 configs/am62x_evm_r5_ethboot_defconfig

-- 
2.34.1

[PATCH 01/10] board: ti: am62x: Init DRAM size in R5/A53 SPL

[Siddharth Vadapalli]

From: Kishon Vijay Abraham I 

Call dram_init_banksize() from spl_board_init() otherwise TFTP download
fails with error "TFTP error: trying to overwrite reserved memory..."
due to lmb_get_free_size() not able to find unreserved region due
to lack of DRAM size info. Required to support Ethernet boot on AM62x.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Siddharth Vadapalli 
---
 board/ti/am62x/evm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index ad93908840..35f291d83a 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -85,6 +85,9 @@ void spl_board_init(void)
if (IS_ENABLED(CONFIG_SPL_SPLASH_SCREEN) && IS_ENABLED(CONFIG_SPL_BMP))
splash_display();
 
+   if (IS_ENABLED(CONFIG_SPL_ETH))
+   /* Init DRAM size for R5/A53 SPL */
+   dram_init_banksize();
 }
 
 #if defined(CONFIG_K3_AM64_DDRSS)
-- 
2.34.1

[PATCH 02/10] firmware: ti_sci: Add No-OP for "RX_FL_CFG"

[Siddharth Vadapalli]

From: Kishon Vijay Abraham I 

RX_FL_CFG message should not be forwarded to TIFS
and should be handled within R5 SPL (when DM services
are not available). Add a no-op function to not handle
RX_FL_CFG messages.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Siddharth Vadapalli 
---
 drivers/firmware/ti_sci.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 6e9f93e9a3..a13a2ead08 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -2445,6 +2445,12 @@ fail:
return ret;
 }
 
+static int ti_sci_cmd_rm_udmap_rx_flow_cfg_noop(const struct ti_sci_handle 
*handle,
+   const struct 
ti_sci_msg_rm_udmap_flow_cfg *params)
+{
+   return 0;
+}
+
 /**
  * ti_sci_cmd_set_fwl_region() - Request for configuring a firewall region
  * @handle:pointer to TI SCI handle
@@ -2884,7 +2890,7 @@ static __maybe_unused int ti_sci_dm_probe(struct udevice 
*dev)
udmap_ops = &ops->rm_udmap_ops;
udmap_ops->tx_ch_cfg = ti_sci_cmd_rm_udmap_tx_ch_cfg;
udmap_ops->rx_ch_cfg = ti_sci_cmd_rm_udmap_rx_ch_cfg;
-   udmap_ops->rx_flow_cfg = ti_sci_cmd_rm_udmap_rx_flow_cfg;
+   udmap_ops->rx_flow_cfg = ti_sci_cmd_rm_udmap_rx_flow_cfg_noop;
 
return ret;
 }
-- 
2.34.1

[PATCH 03/10] soc: ti: k3-navss-ringacc: Initialize base address of ring cfg registers

[Siddharth Vadapalli]

From: Kishon Vijay Abraham I 

Initialize base address of ring config registers required to natively
setup ring cfg registers in the absence of Device Manager (DM) services
at R5 SPL stage.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Siddharth Vadapalli 
---
 drivers/soc/ti/k3-navss-ringacc.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/ti/k3-navss-ringacc.c 
b/drivers/soc/ti/k3-navss-ringacc.c
index 7a2fbb0db6..31e9b372ee 100644
--- a/drivers/soc/ti/k3-navss-ringacc.c
+++ b/drivers/soc/ti/k3-navss-ringacc.c
@@ -1030,8 +1030,8 @@ static int k3_nav_ringacc_init(struct udevice *dev, 
struct k3_nav_ringacc *ringa
 struct k3_nav_ringacc *k3_ringacc_dmarings_init(struct udevice *dev,
struct k3_ringacc_init_data 
*data)
 {
+   void __iomem *base_rt, *base_cfg;
struct k3_nav_ringacc *ringacc;
-   void __iomem *base_rt;
int i;
 
ringacc = devm_kzalloc(dev, sizeof(*ringacc), GFP_KERNEL);
@@ -1049,6 +1049,10 @@ struct k3_nav_ringacc *k3_ringacc_dmarings_init(struct 
udevice *dev,
if (!base_rt)
return ERR_PTR(-EINVAL);
 
+   base_cfg = dev_read_addr_name_ptr(dev, "cfg");
+   if (!base_cfg)
+   return ERR_PTR(-EINVAL);
+
ringacc->rings = devm_kzalloc(dev,
  sizeof(*ringacc->rings) *
  ringacc->num_rings * 2,
@@ -1063,6 +1067,7 @@ struct k3_nav_ringacc *k3_ringacc_dmarings_init(struct 
udevice *dev,
for (i = 0; i < ringacc->num_rings; i++) {
struct k3_nav_ring *ring = &ringacc->rings[i];
 
+   ring->cfg = base_cfg + KNAV_RINGACC_CFG_REGS_STEP * i;
ring->rt = base_rt + K3_DMARING_RING_RT_REGS_STEP * i;
ring->parent = ringacc;
ring->ring_id = i;
-- 
2.34.1

[PATCH 04/10] soc: ti: k3-navss-ringacc: Fix reset ring API

[Siddharth Vadapalli]

From: Vignesh Raghavendra 

Expectation of k3_ringacc_ring_reset_raw() is to reset the ring to
requested size and not to 0. Fix this.

Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Siddharth Vadapalli 
---
 drivers/soc/ti/k3-navss-ringacc-u-boot.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/ti/k3-navss-ringacc-u-boot.c 
b/drivers/soc/ti/k3-navss-ringacc-u-boot.c
index f958239c2a..5d650b9de7 100644
--- a/drivers/soc/ti/k3-navss-ringacc-u-boot.c
+++ b/drivers/soc/ti/k3-navss-ringacc-u-boot.c
@@ -25,9 +25,16 @@ struct k3_nav_ring_cfg_regs {
 #define KNAV_RINGACC_CFG_RING_SIZE_ELSIZE_MASK GENMASK(26, 24)
 #define KNAV_RINGACC_CFG_RING_SIZE_ELSIZE_SHIFT(24)
 
+#define KNAV_RINGACC_CFG_RING_SIZE_MASKGENMASK(15, 0)
+
 static void k3_ringacc_ring_reset_raw(struct k3_nav_ring *ring)
 {
-   writel(0, &ring->cfg->size);
+   u32 reg;
+
+   reg = readl(&ring->cfg->size);
+   reg &= KNAV_RINGACC_CFG_RING_SIZE_MASK;
+   reg |= ring->size;
+   writel(reg, &ring->cfg->size);
 }
 
 static void k3_ringacc_ring_reconfig_qmode_raw(struct k3_nav_ring *ring, enum 
k3_nav_ring_mode mode)
-- 
2.34.1

[PATCH 05/10] dma: ti: k3-udma: Add support for native configuration of chan/flow

[Siddharth Vadapalli]

From: Kishon Vijay Abraham I 

In absence of Device Manager (DM) services such as at R5 SPL stage,
driver will have to natively setup TCHAN/RCHAN/RFLOW cfg registers.
Existing UDMA driver performed the above mentioned configuration
for UDMA. Add similar configuration for PKTDMA here.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Siddharth Vadapalli 
---
 drivers/dma/ti/k3-udma.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 8a62d63dfe..3bd1e7668b 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -2110,6 +2110,9 @@ static int bcdma_tisci_tx_channel_config(struct udma_chan 
*uc)
if (ret)
dev_err(ud->dev, "tchan%d cfg failed %d\n", tchan->id, ret);
 
+   if (IS_ENABLED(CONFIG_K3_DM_FW))
+   udma_alloc_tchan_raw(uc);
+
return ret;
 }
 
@@ -2158,6 +2161,9 @@ static int pktdma_tisci_rx_channel_config(struct 
udma_chan *uc)
dev_err(ud->dev, "flow%d config failed: %d\n", uc->rflow->id,
ret);
 
+   if (IS_ENABLED(CONFIG_K3_DM_FW))
+   udma_alloc_rchan_raw(uc);
+
return ret;
 }
 
-- 
2.34.1

[PATCH 06/10] arm: mach-k3: am62: Update SoC autogenerated data to enable Ethernet Boot

[Siddharth Vadapalli]

From: Andreas Dannenberg 

In order to enable Ethernet Boot using CPSW, update the clock data.

Signed-off-by: Andreas Dannenberg 
Signed-off-by: Siddharth Vadapalli 
---
 arch/arm/mach-k3/r5/am62x/clk-data.c | 79 ++--
 1 file changed, 39 insertions(+), 40 deletions(-)

diff --git a/arch/arm/mach-k3/r5/am62x/clk-data.c 
b/arch/arm/mach-k3/r5/am62x/clk-data.c
index d7bfed0e03..880f05c40b 100644
--- a/arch/arm/mach-k3/r5/am62x/clk-data.c
+++ b/arch/arm/mach-k3/r5/am62x/clk-data.c
@@ -3,9 +3,9 @@
  * AM62X specific clock platform data
  *
  * This file is auto generated. Please do not hand edit and report any issues
- * to Dave Gerlach .
+ * to Bryan Brattlof .
  *
- * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2020-2024 Texas Instruments Incorporated - https://www.ti.com/
  */
 
 #include 
@@ -57,7 +57,7 @@ static const char * const 
sam62_pll_ctrl_wrap_mcu_0_sysclkout_clk_parents[] = {
 
 static const char * const clkout0_ctrl_out0_parents[] = {
"hsdiv4_16fft_main_2_hsdivout1_clk",
-   "hsdiv4_16fft_main_2_hsdivout1_clk10",
+   "hsdiv4_16fft_main_2_hsdivout1_clk",
 };
 
 static const char * const clk_32k_rc_sel_out0_parents[] = {
@@ -158,46 +158,45 @@ static const struct clk_data clk_list[] = {
CLK_FIXED_RATE("fss_ul_main_0_ospi_0_ospi_oclk_clk", 0, 0),
CLK_DIV("hsdiv0_16fft_mcu_32khz_gen_0_hsdivout0_clk", 
"gluelogic_hfosc0_clkout", 0x4508030, 0, 7, 0, 0),
CLK_FIXED_RATE("mshsi2c_main_0_porscl", 0, 0),
-   CLK_PLL("pllfracf_ssmod_16fft_main_0_foutvcop_clk", 
"gluelogic_hfosc0_clkout", 0x68, 0),
-   CLK_DIV("pllfracf_ssmod_16fft_main_0_foutpostdiv_clk_subdiv", 
"pllfracf_ssmod_16fft_main_0_foutvcop_clk", 0x680038, 16, 3, 0, 
CLK_DIVIDER_ONE_BASED),
-   CLK_DIV("pllfracf_ssmod_16fft_main_0_foutpostdiv_clk", 
"pllfracf_ssmod_16fft_main_0_foutpostdiv_clk_subdiv", 0x680038, 24, 3, 0, 
CLK_DIVIDER_ONE_BASED),
-   CLK_PLL("pllfracf_ssmod_16fft_main_1_foutvcop_clk", 
"gluelogic_hfosc0_clkout", 0x681000, 0),
-   CLK_DIV("pllfracf_ssmod_16fft_main_1_foutpostdiv_clk_subdiv", 
"pllfracf_ssmod_16fft_main_1_foutvcop_clk", 0x681038, 16, 3, 0, 
CLK_DIVIDER_ONE_BASED),
-   CLK_DIV("pllfracf_ssmod_16fft_main_1_foutpostdiv_clk", 
"pllfracf_ssmod_16fft_main_1_foutpostdiv_clk_subdiv", 0x681038, 24, 3, 0, 
CLK_DIVIDER_ONE_BASED),
-   CLK_PLL("pllfracf_ssmod_16fft_main_12_foutvcop_clk", 
"gluelogic_hfosc0_clkout", 0x68c000, 0),
-   CLK_PLL("pllfracf_ssmod_16fft_main_15_foutvcop_clk", 
"gluelogic_hfosc0_clkout", 0x68f000, 0),
-   CLK_PLL("pllfracf_ssmod_16fft_main_2_foutvcop_clk", 
"gluelogic_hfosc0_clkout", 0x682000, 0),
-   CLK_DIV("pllfracf_ssmod_16fft_main_2_foutpostdiv_clk_subdiv", 
"pllfracf_ssmod_16fft_main_2_foutvcop_clk", 0x682038, 16, 3, 0, 
CLK_DIVIDER_ONE_BASED),
-   CLK_DIV("pllfracf_ssmod_16fft_main_2_foutpostdiv_clk", 
"pllfracf_ssmod_16fft_main_2_foutpostdiv_clk_subdiv", 0x682038, 24, 3, 0, 
CLK_DIVIDER_ONE_BASED),
-   CLK_PLL("pllfracf_ssmod_16fft_main_8_foutvcop_clk", 
"gluelogic_hfosc0_clkout", 0x688000, 0),
-   CLK_PLL("pllfracf_ssmod_16fft_mcu_0_foutvcop_clk", 
"gluelogic_hfosc0_clkout", 0x404, 0),
-   CLK_DIV("postdiv1_16fft_main_1_hsdivout5_clk", 
"pllfracf_ssmod_16fft_main_1_foutpostdiv_clk", 0x681094, 0, 7, 0, 0),
-   CLK_DIV("postdiv4_16ff_main_0_hsdivout5_clk", 
"pllfracf_ssmod_16fft_main_0_foutpostdiv_clk", 0x680094, 0, 7, 0, 0),
-   CLK_DIV("postdiv4_16ff_main_0_hsdivout6_clk", 
"pllfracf_ssmod_16fft_main_0_foutpostdiv_clk", 0x680098, 0, 7, 0, 0),
-   CLK_DIV("postdiv4_16ff_main_0_hsdivout8_clk", 
"pllfracf_ssmod_16fft_main_0_foutpostdiv_clk", 0x6800a0, 0, 7, 0, 0),
-   CLK_DIV("postdiv4_16ff_main_2_hsdivout5_clk", 
"pllfracf_ssmod_16fft_main_2_foutpostdiv_clk", 0x682094, 0, 7, 0, 0),
-   CLK_DIV("postdiv4_16ff_main_2_hsdivout8_clk", 
"pllfracf_ssmod_16fft_main_2_foutpostdiv_clk", 0x6820a0, 0, 7, 0, 0),
-   CLK_DIV("postdiv4_16ff_main_2_hsdivout9_clk", 
"pllfracf_ssmod_16fft_main_2_foutpostdiv_clk", 0x6820a4, 0, 7, 0, 0),
+   CLK_PLL("pllfracf2_ssmod_16fft_main_0_foutvcop_clk", 
"gluelogic_hfosc0_clkout", 0x68, 0),
+   CLK_DIV("pllfracf2_ssmod_16fft_main_0_foutpostdiv_clk_subdiv", 
"pllfracf2_ssmod_16fft_main_0_foutvcop_clk", 0x680038, 16, 3, 0, 
CLK_DIVIDER_ONE_BASED),
+   CLK_DIV("pllfracf2_ssmod_16fft_main_0_foutpostdiv_clk", 
"pllfracf2_ssmod_16fft_main_0_foutpostdi

[PATCH 07/10] arm: mach-k3: am625_init: Probe AM65 CPSW NUSS

[Siddharth Vadapalli]

From: Kishon Vijay Abraham I 

In order to support Ethernet boot on AM62x, probe AM65 CPSW NUSS driver
in board_init_f().

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Siddharth Vadapalli 
---
 arch/arm/mach-k3/am625_init.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c
index 6c96e88114..b89dd206e5 100644
--- a/arch/arm/mach-k3/am625_init.c
+++ b/arch/arm/mach-k3/am625_init.c
@@ -209,6 +209,16 @@ void board_init_f(ulong dummy)
if (ret)
panic("DRAM init failed: %d\n", ret);
}
+
+   if (IS_ENABLED(CONFIG_SPL_ETH) && IS_ENABLED(CONFIG_TI_AM65_CPSW_NUSS) 
&&
+   spl_boot_device() == BOOT_DEVICE_ETHERNET) {
+   struct udevice *cpswdev;
+
+   if (uclass_get_device_by_driver(UCLASS_MISC, 
DM_DRIVER_GET(am65_cpsw_nuss),
+   &cpswdev))
+   printf("Failed to probe am65_cpsw_nuss driver\n");
+   }
+
spl_enable_cache();
 }
 
-- 
2.34.1

[PATCH 08/10] configs: am62: Add configs for enabling ETHBOOT in R5SPL

[Siddharth Vadapalli]

From: Kishon Vijay Abraham I 

Add configs for enabling ETHBOOT in R5SPL. Adding a separate config
minimizes the risk of going past the R5-SPL size limit for any future
config additions.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Andreas Dannenberg 
Signed-off-by: Siddharth Vadapalli 
---
 configs/am62x_evm_r5_ethboot_defconfig | 110 +
 1 file changed, 110 insertions(+)
 create mode 100644 configs/am62x_evm_r5_ethboot_defconfig

diff --git a/configs/am62x_evm_r5_ethboot_defconfig 
b/configs/am62x_evm_r5_ethboot_defconfig
new file mode 100644
index 00..4912f97d7c
--- /dev/null
+++ b/configs/am62x_evm_r5_ethboot_defconfig
@@ -0,0 +1,110 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_SYS_MALLOC_F_LEN=0x9000
+CONFIG_SPL_GPIO=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_SOC_K3_AM625=y
+CONFIG_TARGET_AM625_R5_EVM=y
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x43c3a7f0
+CONFIG_ENV_SIZE=0x2
+CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-am625-r5-sk"
+CONFIG_SPL_TEXT_BASE=0x43c0
+CONFIG_DM_RESET=y
+CONFIG_SPL_MMC=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_DRIVERS_MISC=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x7000
+CONFIG_SPL_SIZE_LIMIT=0x3A7F0
+CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x3500
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x8008
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y
+CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
+CONFIG_SPL_MAX_SIZE=0x3B000
+CONFIG_SPL_PAD_TO=0x0
+CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
+CONFIG_SPL_BSS_START_ADDR=0x43c3b000
+CONFIG_SPL_BSS_MAX_SIZE=0x3000
+CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y
+CONFIG_SPL_BOARD_INIT=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x20
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_EARLY_BSS=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400
+CONFIG_SPL_DMA=y
+CONFIG_SPL_ENV_SUPPORT=y
+CONFIG_SPL_ETH=y
+CONFIG_SPL_I2C=y
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_NET=y
+CONFIG_SPL_NET_VCI_STRING="AM62X U-Boot R5 SPL"
+CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_RAM_DEVICE=y
+CONFIG_SPL_REMOTEPROC=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_ASKENV=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_REMOTEPROC=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_FAT=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SPL_SYSCON=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_SPL_CLK_CCF=y
+CONFIG_SPL_CLK_K3_PLL=y
+CONFIG_SPL_CLK_K3=y
+CONFIG_DMA_CHANNELS=y
+CONFIG_TI_K3_NAVSS_UDMA=y
+CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_DA8XX_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_DM_MAILBOX=y
+CONFIG_K3_SEC_PROXY=y
+CONFIG_PHY_TI_DP83867=y
+CONFIG_TI_AM65_CPSW_NUSS=y
+CONFIG_PINCTRL=y
+# CONFIG_PINCTRL_GENERIC is not set
+CONFIG_SPL_PINCTRL=y
+# CONFIG_SPL_PINCTRL_GENERIC is not set
+CONFIG_PINCTRL_SINGLE=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_TI_POWER_DOMAIN=y
+CONFIG_K3_SYSTEM_CONTROLLER=y
+CONFIG_REMOTEPROC_TI_K3_ARM64=y
+CONFIG_RESET_TI_SCI=y
+CONFIG_SPECIFY_CONSOLE_INDEX=y
+CONFIG_DM_SERIAL=y
+CONFIG_SOC_DEVICE=y
+CONFIG_SOC_DEVICE_TI_K3=y
+CONFIG_SOC_TI=y
+CONFIG_TIMER=y
+CONFIG_SPL_TIMER=y
+CONFIG_OMAP_TIMER=y
+CONFIG_LIB_RATIONAL=y
+CONFIG_SPL_LIB_RATIONAL=y
-- 
2.34.1

[PATCH 09/10] configs: am62x_evm_a53_defconfig: Enable configs required for Ethboot

[Siddharth Vadapalli]

From: Kishon Vijay Abraham I 

Enable config options needed to support Ethernet boot on AM62x SK.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Siddharth Vadapalli 
---
 configs/am62x_evm_a53_defconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index aa96c1b312..5c56b17a3e 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -17,6 +17,7 @@ CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_SPL_MMC=y
 CONFIG_SPL_SERIAL=y
+CONFIG_SPL_DRIVERS_MISC=y
 CONFIG_SPL_STACK_R_ADDR=0x8200
 CONFIG_SPL_SIZE_LIMIT=0x4
 CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x800
@@ -37,13 +38,19 @@ CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
 CONFIG_SPL_BSS_START_ADDR=0x80c8
 CONFIG_SPL_BSS_MAX_SIZE=0x8
 CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y
+CONFIG_SPL_BOARD_INIT=y
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
+CONFIG_SPL_DMA=y
+CONFIG_SPL_ENV_SUPPORT=y
+CONFIG_SPL_ETH=y
 CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img"
 CONFIG_SPL_DM_MAILBOX=y
 CONFIG_SPL_DM_SPI_FLASH=y
+CONFIG_SPL_NET=y
+CONFIG_SPL_NET_VCI_STRING="AM62X U-Boot A53 SPL"
 CONFIG_SPL_POWER_DOMAIN=y
 # CONFIG_SPL_SPI_FLASH_TINY is not set
 CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
@@ -61,6 +68,7 @@ CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_REGMAP=y
 CONFIG_SPL_REGMAP=y
+CONFIG_SPL_SYSCON=y
 CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_CLK=y
 CONFIG_SPL_CLK=y
-- 
2.34.1

[PATCH 10/10] arm: dts: k3-am625-r5-sk: Enable DM services for main_pktdma

[Siddharth Vadapalli]

Enable DM services for main_pktdma during R5 SPL stage.

Signed-off-by: Siddharth Vadapalli 
---
 arch/arm/dts/k3-am625-r5-sk.dts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/dts/k3-am625-r5-sk.dts b/arch/arm/dts/k3-am625-r5-sk.dts
index 6b9f40e555..0912b953db 100644
--- a/arch/arm/dts/k3-am625-r5-sk.dts
+++ b/arch/arm/dts/k3-am625-r5-sk.dts
@@ -83,3 +83,8 @@
reg = <0x00 0x0fc4 0x00 0x100>,
  <0x00 0x6000 0x00 0x0800>;
 };
+
+&main_pktdma {
+   ti,sci = <&dm_tifs>;
+   bootph-all;
+};
-- 
2.34.1

Re: [PATCH 01/10] board: ti: am62x: Init DRAM size in R5/A53 SPL

[Siddharth Vadapalli]

Hello Nishanth,

On 12/01/24 17:56, Nishanth Menon wrote:
> On 12:17-20240112, Siddharth Vadapalli wrote:
>> From: Kishon Vijay Abraham I 
>>
>> Call dram_init_banksize() from spl_board_init() otherwise TFTP download
>> fails with error "TFTP error: trying to overwrite reserved memory..."
>> due to lmb_get_free_size() not able to find unreserved region due
>> to lack of DRAM size info. Required to support Ethernet boot on AM62x.
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> Signed-off-by: Siddharth Vadapalli 
>> ---
>>  board/ti/am62x/evm.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
>> index ad93908840..35f291d83a 100644
>> --- a/board/ti/am62x/evm.c
>> +++ b/board/ti/am62x/evm.c
>> @@ -85,6 +85,9 @@ void spl_board_init(void)
>>  if (IS_ENABLED(CONFIG_SPL_SPLASH_SCREEN) && IS_ENABLED(CONFIG_SPL_BMP))
>>  splash_display();
>>  
>> +if (IS_ENABLED(CONFIG_SPL_ETH))
>> +/* Init DRAM size for R5/A53 SPL */
>> +dram_init_banksize();
>>  }
>>  
>>  #if defined(CONFIG_K3_AM64_DDRSS)
>> -- 
>> 2.34.1
>>
> 
> Are you sure? tftp seems to work without this patch.
> 
> https://gist.github.com/nmenon/91e3282e00e38ae42e8cf640be2ab888

I noticed the error pointed out in the commit message at the A53 SPL stage when
the U-Boot Image is being fetched over TFTP without this patch, so I have
verified that this patch is necessary. The logs you have shared verify TFTP at
U-Boot, but this patch is for enabling TFTP at A53 SPL for fetching U-Boot image
via TFTP.


-- 
Regards,
Siddharth.

Re: [PATCH 00/10] Add support for Ethernet Boot on SK-AM62

[Siddharth Vadapalli]

On 12/01/24 18:02, Nishanth Menon wrote:
> On 12:17-20240112, Siddharth Vadapalli wrote:
>> Hello,
>>
>> This series enables Ethernet Boot on SK-AM62 device.
>> Product Link: https://www.ti.com/tool/SK-AM62
>> User Guide: https://www.ti.com/lit/pdf/spruj40
>>
>> Ethernet Boot flow is as follows:
>> 1. The BOOT MODE pins are configured for Ethernet Boot.
>> 2. On powering on the device, ROM uses the Ethernet Port corresponding
>> to CPSW3G's MAC Port 1 to transmit "TI K3 Bootp Boot".
>> 3. The TFTP server and DHCP server on the receiver device need to be
>> configured such that VCI string "TI K3 Bootp Boot" maps to the file
>> "tiboot3.bin" and the TFTP server should be capable of transferring
>> it to the device.
>> 4. ROM loads and executes "tiboot3.bin" provided by the TFTP server.
>> 5. The "tiboot3.bin" file is expected to be built using the config:
>> am62x_evm_r5_ethboot_defconfig
>> introduced in this series, which shall enable "tispl.bin" to be fetched
>> over TFTP using "tiboot3.bin".
>> 6. "tiboot3.bin" is configured to transmit "AM62X U-Boot R5 SPL" as its
>> NET_VCI_STRING, thereby implying that the DHCP server and TFTP server
>> need to be configured to transfer "tispl.bin" to the device.
>> 7. "tiboot3.bin" loads and executes "tispl.bin" provided by the TFTP
>> server.
>> 8. The "tispl.bin" file is expected to be built using the config:
>> am62x_evm_a53_defconfig
>> which has been updated in this series to enable Ethernet Boot specific
>> configs, allowing "u-boot.img" to be fetched over TFTP using
>> "tispl.bin".
>> 9. "tispl.bin" is configured to transmit "AM62X U-Boot A53 SPL" as its
>> NET_VCI_STRING. The DHCP server and TFTP server need to be configured to
>> transfer "u-boot.img" to the device for the aforementioned NET_VCI_STRING.
>> 10. "tispl.bin" then fetches "u-boot.img" using TFTP and loads and
>> executes it on the device, completing the process of Ethernet Boot on the
>> device.
>>
>> NOTE: ROM configures CPSW3G's MAC Port 1 for 100 Mbps full-duplex mode
>> of operation due to which it is expected that the Link Partner also
>> supports the same mode of operation.
>> Additionally, enabling "phy_gmii_sel" node at SPL stage will be
>> necessary and is not added as a part of this series with the aim of
>> adding the "bootph-all" property to its counterpart in Linux device-tree
>> first.
> 
> 
> NAK - instead of writing all this up in the commit message, why would
> you not spend that time updating the excellent documentation we have?

I plan to document it after the feature is in. The reason for mentioning the
content above is for explaining the flow in case anyone wishes to test and
verify it. Wouldn't documenting it make it appear that the feature is present
when it isn't?

...

-- 
Regards,
Siddharth.

Re: [PATCH 08/10] configs: am62: Add configs for enabling ETHBOOT in R5SPL

[Siddharth Vadapalli]

On 12/01/24 18:01, Nishanth Menon wrote:
> On 12:17-20240112, Siddharth Vadapalli wrote:
>> From: Kishon Vijay Abraham I 
>>
>> Add configs for enabling ETHBOOT in R5SPL. Adding a separate config
>> minimizes the risk of going past the R5-SPL size limit for any future
>> config additions.
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> Signed-off-by: Andreas Dannenberg 
>> Signed-off-by: Siddharth Vadapalli 
>> ---
>>  configs/am62x_evm_r5_ethboot_defconfig | 110 +
> 
> NAK. use config fragments please.

Ok.

-- 
Regards,
Siddharth.

Re: [PATCH 09/10] configs: am62x_evm_a53_defconfig: Enable configs required for Ethboot

[Siddharth Vadapalli]

On 12/01/24 18:03, Nishanth Menon wrote:
> On 12:17-20240112, Siddharth Vadapalli wrote:
>> From: Kishon Vijay Abraham I 
>>
>> Enable config options needed to support Ethernet boot on AM62x SK.
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> Signed-off-by: Siddharth Vadapalli 
>> ---
>>  configs/am62x_evm_a53_defconfig | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/configs/am62x_evm_a53_defconfig 
>> b/configs/am62x_evm_a53_defconfig
>> index aa96c1b312..5c56b17a3e 100644
>> --- a/configs/am62x_evm_a53_defconfig
>> +++ b/configs/am62x_evm_a53_defconfig
>> @@ -17,6 +17,7 @@ CONFIG_OF_LIBFDT_OVERLAY=y
>>  CONFIG_DM_RESET=y
>>  CONFIG_SPL_MMC=y
>>  CONFIG_SPL_SERIAL=y
>> +CONFIG_SPL_DRIVERS_MISC=y
>>  CONFIG_SPL_STACK_R_ADDR=0x8200
>>  CONFIG_SPL_SIZE_LIMIT=0x4
>>  CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x800
>> @@ -37,13 +38,19 @@ CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
>>  CONFIG_SPL_BSS_START_ADDR=0x80c8
>>  CONFIG_SPL_BSS_MAX_SIZE=0x8
>>  CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y
>> +CONFIG_SPL_BOARD_INIT=y
>>  CONFIG_SPL_SYS_MALLOC_SIMPLE=y
>>  CONFIG_SPL_STACK_R=y
>>  CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
>>  CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
>> +CONFIG_SPL_DMA=y
>> +CONFIG_SPL_ENV_SUPPORT=y
>> +CONFIG_SPL_ETH=y
>>  CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img"
>>  CONFIG_SPL_DM_MAILBOX=y
>>  CONFIG_SPL_DM_SPI_FLASH=y
>> +CONFIG_SPL_NET=y
>> +CONFIG_SPL_NET_VCI_STRING="AM62X U-Boot A53 SPL"
>>  CONFIG_SPL_POWER_DOMAIN=y
>>  # CONFIG_SPL_SPI_FLASH_TINY is not set
>>  CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
>> @@ -61,6 +68,7 @@ CONFIG_SPL_DM=y
>>  CONFIG_SPL_DM_SEQ_ALIAS=y
>>  CONFIG_REGMAP=y
>>  CONFIG_SPL_REGMAP=y
>> +CONFIG_SPL_SYSCON=y
>>  CONFIG_SPL_OF_TRANSLATE=y
>>  CONFIG_CLK=y
>>  CONFIG_SPL_CLK=y
>> -- 
>> 2.34.1
>>
> 
> NAK again - why cant we use config fragments?

Ok. I will use config fragments.

> 

-- 
Regards,
Siddharth.

Re: [PATCH 00/10] Add support for Ethernet Boot on SK-AM62

[Siddharth Vadapalli]

On 12/01/24 18:12, Nishanth Menon wrote:
> On 18:06-20240112, Siddharth Vadapalli wrote:
>>
>>
>> On 12/01/24 18:02, Nishanth Menon wrote:
>>> On 12:17-20240112, Siddharth Vadapalli wrote:
>>>> Hello,
>>>>
>>>> This series enables Ethernet Boot on SK-AM62 device.
>>>> Product Link: https://www.ti.com/tool/SK-AM62
>>>> User Guide: https://www.ti.com/lit/pdf/spruj40
>>>>
>>>> Ethernet Boot flow is as follows:
>>>> 1. The BOOT MODE pins are configured for Ethernet Boot.
>>>> 2. On powering on the device, ROM uses the Ethernet Port corresponding
>>>> to CPSW3G's MAC Port 1 to transmit "TI K3 Bootp Boot".
>>>> 3. The TFTP server and DHCP server on the receiver device need to be
>>>> configured such that VCI string "TI K3 Bootp Boot" maps to the file
>>>> "tiboot3.bin" and the TFTP server should be capable of transferring
>>>> it to the device.
>>>> 4. ROM loads and executes "tiboot3.bin" provided by the TFTP server.
>>>> 5. The "tiboot3.bin" file is expected to be built using the config:
>>>> am62x_evm_r5_ethboot_defconfig
>>>> introduced in this series, which shall enable "tispl.bin" to be fetched
>>>> over TFTP using "tiboot3.bin".
>>>> 6. "tiboot3.bin" is configured to transmit "AM62X U-Boot R5 SPL" as its
>>>> NET_VCI_STRING, thereby implying that the DHCP server and TFTP server
>>>> need to be configured to transfer "tispl.bin" to the device.
>>>> 7. "tiboot3.bin" loads and executes "tispl.bin" provided by the TFTP
>>>> server.
>>>> 8. The "tispl.bin" file is expected to be built using the config:
>>>> am62x_evm_a53_defconfig
>>>> which has been updated in this series to enable Ethernet Boot specific
>>>> configs, allowing "u-boot.img" to be fetched over TFTP using
>>>> "tispl.bin".
>>>> 9. "tispl.bin" is configured to transmit "AM62X U-Boot A53 SPL" as its
>>>> NET_VCI_STRING. The DHCP server and TFTP server need to be configured to
>>>> transfer "u-boot.img" to the device for the aforementioned NET_VCI_STRING.
>>>> 10. "tispl.bin" then fetches "u-boot.img" using TFTP and loads and
>>>> executes it on the device, completing the process of Ethernet Boot on the
>>>> device.
>>>>
>>>> NOTE: ROM configures CPSW3G's MAC Port 1 for 100 Mbps full-duplex mode
>>>> of operation due to which it is expected that the Link Partner also
>>>> supports the same mode of operation.
>>>> Additionally, enabling "phy_gmii_sel" node at SPL stage will be
>>>> necessary and is not added as a part of this series with the aim of
>>>> adding the "bootph-all" property to its counterpart in Linux device-tree
>>>> first.
>>>
>>>
>>> NAK - instead of writing all this up in the commit message, why would
>>> you not spend that time updating the excellent documentation we have?
>>
>> I plan to document it after the feature is in. The reason for mentioning the
>> content above is for explaining the flow in case anyone wishes to test and
>> verify it. Wouldn't documenting it make it appear that the feature is present
>> when it isn't?
> 
> So you are saying this series does NOT work! why are you sending patches
> then? If you are introducing a feature and enabling it, ensure you send
> documentation along with it allowing people to be able to actually use
> the feature.

I have mentioned in the "NOTE" above that enabling "phy_gmii_sel" node at SPL
stage by adding the "bootph-all" property is necessary to verify this series.
I cannot post that with this series since Linux device-tree needs to have the
property added first and the merge window is closed now. Once it is in the Linux
device-tree, syncing U-Boot device-tree with Linux device-tree will enable
Ethernet Boot which is when the feature will work. That is when I was planning
to document it. However, based on your feedback, in the next version for this
series I will add the documentation as well along with the note that
"phy_gmii_sel" needs to be enabled at SPL stage for the feature to work.

Please let me know if that is acceptable.

> 

-- 
Regards,
Siddharth.

Re: [PATCH 01/10] board: ti: am62x: Init DRAM size in R5/A53 SPL

[Siddharth Vadapalli]

Hello Tom,

On 12/01/24 18:56, Tom Rini wrote:
> On Fri, Jan 12, 2024 at 12:17:50PM +0530, Siddharth Vadapalli wrote:
> 
>> From: Kishon Vijay Abraham I 
>>
>> Call dram_init_banksize() from spl_board_init() otherwise TFTP download
>> fails with error "TFTP error: trying to overwrite reserved memory..."
>> due to lmb_get_free_size() not able to find unreserved region due
>> to lack of DRAM size info. Required to support Ethernet boot on AM62x.
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> Signed-off-by: Siddharth Vadapalli 
>> ---
>>  board/ti/am62x/evm.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
>> index ad93908840..35f291d83a 100644
>> --- a/board/ti/am62x/evm.c
>> +++ b/board/ti/am62x/evm.c
>> @@ -85,6 +85,9 @@ void spl_board_init(void)
>>  if (IS_ENABLED(CONFIG_SPL_SPLASH_SCREEN) && IS_ENABLED(CONFIG_SPL_BMP))
>>  splash_display();
>>  
>> +if (IS_ENABLED(CONFIG_SPL_ETH))
>> +/* Init DRAM size for R5/A53 SPL */
>> +dram_init_banksize();
> 
> The list of conditionals in common/spl/spl.c::board_init_r() should be
> updated and probably use SPL_NET as the option to check for.

Thank you for reviewing the patch and pointing this out. I wasn't aware of it. I
assume that you are referring to the following change:

if (IS_ENABLED(CONFIG_SPL_OS_BOOT) || CONFIG_IS_ENABLED(HANDOFF) ||
-   IS_ENABLED(CONFIG_SPL_ATF))
+   IS_ENABLED(CONFIG_SPL_ATF) || IS_ENABLED(CONFIG_SPL_NET))
dram_init_banksize();

I shall replace the current patch with the above change in the v2 series. Since
this is in the common section, is there a generic reason I could provide in the
commit message rather than the existing commit message which seems to be board
specific? Also, I hope that the above change will not cause regressions for
other non-TI devices. Please let me know.

> 

-- 
Regards,
Siddharth.

Re: [PATCH 00/10] Add support for Ethernet Boot on SK-AM62

[Siddharth Vadapalli]

On 12/01/24 18:31, Nishanth Menon wrote:
> On 18:17-20240112, Siddharth Vadapalli wrote:
>>
>>
>> On 12/01/24 18:12, Nishanth Menon wrote:
>>> On 18:06-20240112, Siddharth Vadapalli wrote:
>>>>
>>>>
>>>> On 12/01/24 18:02, Nishanth Menon wrote:
>>>>> On 12:17-20240112, Siddharth Vadapalli wrote:
>>>>>> Hello,
>>>>>>
>>>>>> This series enables Ethernet Boot on SK-AM62 device.
>>>>>> Product Link: https://www.ti.com/tool/SK-AM62
>>>>>> User Guide: https://www.ti.com/lit/pdf/spruj40
>>>>>>
>>>>>> Ethernet Boot flow is as follows:
>>>>>> 1. The BOOT MODE pins are configured for Ethernet Boot.
>>>>>> 2. On powering on the device, ROM uses the Ethernet Port corresponding
>>>>>> to CPSW3G's MAC Port 1 to transmit "TI K3 Bootp Boot".
>>>>>> 3. The TFTP server and DHCP server on the receiver device need to be
>>>>>> configured such that VCI string "TI K3 Bootp Boot" maps to the file
>>>>>> "tiboot3.bin" and the TFTP server should be capable of transferring
>>>>>> it to the device.
>>>>>> 4. ROM loads and executes "tiboot3.bin" provided by the TFTP server.
>>>>>> 5. The "tiboot3.bin" file is expected to be built using the config:
>>>>>> am62x_evm_r5_ethboot_defconfig
>>>>>> introduced in this series, which shall enable "tispl.bin" to be fetched
>>>>>> over TFTP using "tiboot3.bin".
>>>>>> 6. "tiboot3.bin" is configured to transmit "AM62X U-Boot R5 SPL" as its
>>>>>> NET_VCI_STRING, thereby implying that the DHCP server and TFTP server
>>>>>> need to be configured to transfer "tispl.bin" to the device.
>>>>>> 7. "tiboot3.bin" loads and executes "tispl.bin" provided by the TFTP
>>>>>> server.
>>>>>> 8. The "tispl.bin" file is expected to be built using the config:
>>>>>> am62x_evm_a53_defconfig
>>>>>> which has been updated in this series to enable Ethernet Boot specific
>>>>>> configs, allowing "u-boot.img" to be fetched over TFTP using
>>>>>> "tispl.bin".
>>>>>> 9. "tispl.bin" is configured to transmit "AM62X U-Boot A53 SPL" as its
>>>>>> NET_VCI_STRING. The DHCP server and TFTP server need to be configured to
>>>>>> transfer "u-boot.img" to the device for the aforementioned 
>>>>>> NET_VCI_STRING.
>>>>>> 10. "tispl.bin" then fetches "u-boot.img" using TFTP and loads and
>>>>>> executes it on the device, completing the process of Ethernet Boot on the
>>>>>> device.
>>>>>>
>>>>>> NOTE: ROM configures CPSW3G's MAC Port 1 for 100 Mbps full-duplex mode
>>>>>> of operation due to which it is expected that the Link Partner also
>>>>>> supports the same mode of operation.
>>>>>> Additionally, enabling "phy_gmii_sel" node at SPL stage will be
>>>>>> necessary and is not added as a part of this series with the aim of
>>>>>> adding the "bootph-all" property to its counterpart in Linux device-tree
>>>>>> first.
>>>>>
>>>>>
>>>>> NAK - instead of writing all this up in the commit message, why would
>>>>> you not spend that time updating the excellent documentation we have?
>>>>
>>>> I plan to document it after the feature is in. The reason for mentioning 
>>>> the
>>>> content above is for explaining the flow in case anyone wishes to test and
>>>> verify it. Wouldn't documenting it make it appear that the feature is 
>>>> present
>>>> when it isn't?
>>>
>>> So you are saying this series does NOT work! why are you sending patches
>>> then? If you are introducing a feature and enabling it, ensure you send
>>> documentation along with it allowing people to be able to actually use
>>> the feature.
>>
>> I have mentioned in the "NOTE" above that enabling "phy_gmii_sel" node at SPL
>> stage by adding the "bootph-all" property is necessary to verify this series.
>> I cannot post that with this series since Linux device-tree needs to have the
>> property added first and the merge window is closed now. Once it is in the 
>> Linux
>> device-tree, syncing U-Boot device-tree with Linux device-tree will enable
>> Ethernet Boot which is when the feature will work. That is when I was 
>> planning
>> to document it. However, based on your feedback, in the next version for this
>> series I will add the documentation as well along with the note that
>> "phy_gmii_sel" needs to be enabled at SPL stage for the feature to work.
>>
> 
> considered first posting a patch to kernel.org (merge window has
> nothing to do with posting and having patches reviewed) and in the
> interim, doing that in u-boot.dtsi so that the next sync will drop it
> from u-boot.dtsi?
> 
> OR hold the series back till it is merged into kernel.org master?
> 
> Either way, please do not send patches to the list that does not work.
> 
> Since it is now hard to trust your patches without detailed cover letter
> analysis, next time you are updating the series post test logs as well
> with just the patches applied and no additional changes.

Thank you for clarifying regarding the approach to be taken. I shall include the
logs when I post the v2 series, in addition to the Documentation update.

> 

-- 
Regards,
Siddharth.

Re: [PATCH 01/10] board: ti: am62x: Init DRAM size in R5/A53 SPL

[Siddharth Vadapalli]

On 20/01/24 22:11, Tom Rini wrote:
> On Mon, Jan 15, 2024 at 01:42:51PM +0530, Siddharth Vadapalli wrote:
>> Hello Tom,
>>
>> On 12/01/24 18:56, Tom Rini wrote:

...

>>> The list of conditionals in common/spl/spl.c::board_init_r() should be
>>> updated and probably use SPL_NET as the option to check for.
>>
>> Thank you for reviewing the patch and pointing this out. I wasn't aware of 
>> it. I
>> assume that you are referring to the following change:
>>
>> if (IS_ENABLED(CONFIG_SPL_OS_BOOT) || CONFIG_IS_ENABLED(HANDOFF) ||
>> -   IS_ENABLED(CONFIG_SPL_ATF))
>> +   IS_ENABLED(CONFIG_SPL_ATF) || IS_ENABLED(CONFIG_SPL_NET))
>> dram_init_banksize();
>>
>> I shall replace the current patch with the above change in the v2 series. 
>> Since
>> this is in the common section, is there a generic reason I could provide in 
>> the
>> commit message rather than the existing commit message which seems to be 
>> board
>> specific? Also, I hope that the above change will not cause regressions for
>> other non-TI devices. Please let me know.
> 
> Yes, that's the area, and just note that networking also requires the
> DDR to be initialized.
> 

Thank you for confirming and providing your suggestion for the contents of the
commit message.

-- 
Regards,
Siddharth.

Re: [PATCH] net: ti: am65-cpsw-nuss: Don't crash in am65_cpsw_phy_init()

[Siddharth Vadapalli]

On Wed, Mar 27, 2024 at 06:09:40PM +0100, A. Sverdlin wrote:
> From: Alexander Sverdlin 

In the $subject, "Don't crash.." seems to indicate the consequence of
not handling the absence of PHYs gracefully within am65_cpsw_phy_init().
So the subject should probably be reworded to emphasize this instead.
Something like:

net: ti: am65-cpsw-nuss: Update am65_cpsw_phy_init() to handle PHY absence

The rest of the patch looks good to me. With the subject reworded,

Reviewed-by: Siddharth Vadapalli 

Regards,
Siddharth.

> 
> am65_cpsw_ofdata_parse_phy() tries to handle the case when PHY is not
> specified in DT gracefully:
> 
> am65_cpsw_nuss_port ethernet@800port@1: can't parse phy-handle port 1 (-2)
> 
> am65_cpsw_mdio_init() is turn is prepared for this, checks
> if priv->has_phy == 0 and bails out (leaving cpsw_common->bus == NULL).
> 
> am65_cpsw_phy_init() however is not prepared for this and calls
> phy_connect(cpsw_common->bus, ...) unconditionally, which leads to:
> 
> "Synchronous Abort" handler, esr 0x860d, far 0x0
> elr: 808ab000 lr : 8083bde4 (reloc)
> 
> where lr points to the instruction right after bus->read() in get_phy_id().
> 
> Fixes: 9d0dca1199d1 ("net: ethernet: ti: Introduce am654 gigabit eth switch 
> subsystem driver")
> Signed-off-by: Alexander Sverdlin 
> ---
>  drivers/net/ti/am65-cpsw-nuss.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
> index 6da018c0f9d5..d1e452b6b43c 100644
> --- a/drivers/net/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ti/am65-cpsw-nuss.c
> @@ -722,6 +722,9 @@ static int am65_cpsw_phy_init(struct udevice *dev)
>   u32 supported = PHY_GBIT_FEATURES;
>   int ret;
>  
> + if (!priv->has_phy || !cpsw_common->bus)
> + return 0;
> +
>   phydev = phy_connect(cpsw_common->bus,
>priv->phy_addr,
>priv->dev,
> -- 
> 2.44.0
> 

Re: [PATCH v2] net: ti: am65-cpsw-nuss: handle missing PHY in am65_cpsw_phy_init() gracefully

[Siddharth Vadapalli]

On Thu, Mar 28, 2024 at 07:29:10AM +0100, A. Sverdlin wrote:
> From: Alexander Sverdlin 
> 
> am65_cpsw_ofdata_parse_phy() tries to handle the case when PHY is not
> specified in DT gracefully:
> 
> am65_cpsw_nuss_port ethernet@800port@1: can't parse phy-handle port 1 (-2)
> 
> am65_cpsw_mdio_init() in turn is prepared for this, checks
> if priv->has_phy == 0 and bails out (leaving cpsw_common->bus == NULL).
> 
> am65_cpsw_phy_init() however is not prepared for this and calls
> phy_connect(cpsw_common->bus, ...) unconditionally, which leads to:
> 
> "Synchronous Abort" handler, esr 0x860d, far 0x0
> elr: 808ab000 lr : 8083bde4 (reloc)
> 
> where lr points to the instruction right after bus->read() in get_phy_id().
> 
> Fixes: 9d0dca1199d1 ("net: ethernet: ti: Introduce am654 gigabit eth switch 
> subsystem driver")
> Signed-off-by: Alexander Sverdlin 

Reviewed-by: Siddharth Vadapalli 

Regards,
Siddharth.

Re: [PATCH 1/5] net: eth-uclass: guard against reentrant eth_init()/eth_halt() calls

[Siddharth Vadapalli]

On Fri, Apr 26, 2024 at 10:02:24AM +0200, Matthias Schiffer wrote:
> With netconsole, any log message can result in an eth_init(), possibly
> causing an reentrant call into eth_init() if a driver's ops print
> anything:
> 
> eth_init() -> driver.start() -> printf() -> netconsole -> eth_init()
> eth_halt() -> driver.stop() -> printf() -> netconsole -> eth_init()
> 
> Rather than expecting every single Ethernet driver to handle this case,
> prevent the reentrant calls in eth_init() and eth_halt().
> 
> The issue was noticed on an AM62x board, where a bootm after
> simultaneous netconsole and TFTP would result in a crash.

Link: 
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1350550/sk-am62a-lp-am65_cpsw_nuss_port-error-in-u-boot-while-using-netconsole-functionality/

> 
> Signed-off-by: Matthias Schiffer 
> ---
>  net/eth-uclass.c | 40 
>  1 file changed, 32 insertions(+), 8 deletions(-)
> 
> diff --git a/net/eth-uclass.c b/net/eth-uclass.c
> index 3d0ec91dfa4..193218a328b 100644
> --- a/net/eth-uclass.c
> +++ b/net/eth-uclass.c
> @@ -48,6 +48,8 @@ struct eth_uclass_priv {
>  
>  /* eth_errno - This stores the most recent failure code from DM functions */
>  static int eth_errno;
> +/* Are we currently in eth_init() or eth_halt()? */
> +static bool in_init_halt;
>  
>  /* board-specific Ethernet Interface initializations. */
>  __weak int board_interface_eth_init(struct udevice *dev,
> @@ -285,11 +287,19 @@ U_BOOT_ENV_CALLBACK(ethaddr, on_ethaddr);
>  
>  int eth_init(void)
>  {
> - char *ethact = env_get("ethact");
> - char *ethrotate = env_get("ethrotate");
>   struct udevice *current = NULL;
>   struct udevice *old_current;
>   int ret = -ENODEV;
> + char *ethrotate;
> + char *ethact;
> +
> + if (in_init_halt)
> + return -EBUSY;
> +
> + in_init_halt = true;
> +
> + ethact = env_get("ethact");
> + ethrotate = env_get("ethrotate");
>  
>   /*
>* When 'ethrotate' variable is set to 'no' and 'ethact' variable
> @@ -298,8 +308,10 @@ int eth_init(void)
>   if ((ethrotate != NULL) && (strcmp(ethrotate, "no") == 0)) {
>   if (ethact) {
>   current = eth_get_dev_by_name(ethact);
> - if (!current)
> - return -EINVAL;
> + if (!current) {
> + ret = -EINVAL;
> + goto end;
> + }
>   }
>   }
>  
> @@ -307,7 +319,8 @@ int eth_init(void)
>   current = eth_get_dev();
>   if (!current) {
>   log_err("No ethernet found.\n");
> - return -ENODEV;
> + ret = -ENODEV;
> + goto end;
>   }
>   }
>  
> @@ -324,7 +337,8 @@ int eth_init(void)
>  
>   priv->state = ETH_STATE_ACTIVE;
>   priv->running = true;
> - return 0;
> + ret = 0;
> + goto end;
>   }
>   } else {
>   ret = eth_errno;
> @@ -344,6 +358,8 @@ int eth_init(void)
>   current = eth_get_dev();
>   } while (old_current != current);
>  
> +end:
> + in_init_halt = false;
>   return ret;
>  }
>  
> @@ -352,17 +368,25 @@ void eth_halt(void)
>   struct udevice *current;
>   struct eth_device_priv *priv;
>  
> + if (in_init_halt)
> + return;
> +
> + in_init_halt = true;
> +
>   current = eth_get_dev();
>   if (!current)
> - return;
> + goto end;
>  
>   priv = dev_get_uclass_priv(current);
>   if (!priv || !priv->running)
> - return;
> + goto end;
>  
>   eth_get_ops(current)->stop(current);
>   priv->state = ETH_STATE_PASSIVE;
>   priv->running = false;
> +
> +end:
> + in_init_halt = false;
>  }
>  
>  int eth_is_active(struct udevice *dev)
> -- 
> TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht München, HRB 105018
> Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> https://www.tq-group.com/
> 

[PATCH] dma: ti: k3-udma: Fix error handling for setup_resources() in udma_probe()

[Siddharth Vadapalli]

In udma_probe() the return value of setup_resources() is stored in the
u32 "ch_count" member of "struct udma_dev", due to which any negative
return value which indicates an error is masked.

Fix this by storing the return value of setup_resources() in the already
declared integer variable "ret", followed by assigning it to the "ch_count"
member of "struct udma_dev" in case of no error.

While at it, change the "return ret" at the end of udma_probe() to a
"return 0", to explicitly indicate that probe was successful.

Fixes: a8837cf43839 ("dma: ti: k3-udma: Query DMA channels allocated from 
Resource Manager")
Signed-off-by: Siddharth Vadapalli 
---

Hello,

This patch is based on commit
9e00b6993f Merge tag 'u-boot-dfu-20240215' of 
https://source.denx.de/u-boot/custodians/u-boot-dfu
of the master branch of U-Boot.

Regards,
Siddharth.

 drivers/dma/ti/k3-udma.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index eea9ec9659..8a6625f034 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -1770,9 +1770,11 @@ static int udma_probe(struct udevice *dev)
return PTR_ERR(ud->ringacc);
 
ud->dev = dev;
-   ud->ch_count = setup_resources(ud);
-   if (ud->ch_count <= 0)
-   return ud->ch_count;
+   ret = setup_resources(ud);
+   if (ret <= 0)
+   return ret;
+
+   ud->ch_count = ret;
 
for (i = 0; i < ud->bchan_cnt; i++) {
struct udma_bchan *bchan = &ud->bchans[i];
@@ -1831,7 +1833,7 @@ static int udma_probe(struct udevice *dev)
 
uc_priv->supported = DMA_SUPPORTS_MEM_TO_MEM | DMA_SUPPORTS_MEM_TO_DEV;
 
-   return ret;
+   return 0;
 }
 
 static int udma_push_to_ring(struct k3_nav_ring *ring, void *elem)
-- 
2.34.1

Re: [PATCH] dma: ti: k3-udma: Fix error handling for setup_resources() in udma_probe()

[Siddharth Vadapalli]

On 24/02/20 12:51PM, Dan Carpenter wrote:
> On Fri, Feb 16, 2024 at 04:11:05PM +0530, Siddharth Vadapalli wrote:
> > diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
> > index eea9ec9659..8a6625f034 100644
> > --- a/drivers/dma/ti/k3-udma.c
> > +++ b/drivers/dma/ti/k3-udma.c
> > @@ -1770,9 +1770,11 @@ static int udma_probe(struct udevice *dev)
> > return PTR_ERR(ud->ringacc);
> >  
> > ud->dev = dev;
> > -   ud->ch_count = setup_resources(ud);
> > -   if (ud->ch_count <= 0)
> > -   return ud->ch_count;
> > +   ret = setup_resources(ud);
> > +   if (ret <= 0)
> > +   return ret;
> 
> The code was like this originally, but setup_resources() can't actually
> return zero so it would be nicer to say:
>   ret = setup_resources(ud);
>   if (ret < 0)
>   return ret;

Thank you for reviewing the patch and pointing this out. I will fix it
and post the v2 patch.

Regards,
Siddharth.

[PATCH v2] dma: ti: k3-udma: Fix error handling for setup_resources() in udma_probe()

[Siddharth Vadapalli]

In udma_probe() the return value of setup_resources() is stored in the
u32 "ch_count" member of "struct udma_dev", due to which any negative
return value which indicates an error is masked.

Fix this by storing the return value of setup_resources() in the already
declared integer variable "ret", followed by assigning it to the "ch_count"
member of "struct udma_dev" in case of no error.

While at it, change the "return ret" at the end of udma_probe() to a
"return 0", to explicitly indicate that probe was successful.

Fixes: a8837cf43839 ("dma: ti: k3-udma: Query DMA channels allocated from 
Resource Manager")
Signed-off-by: Siddharth Vadapalli 
---

Hello,

This patch is based on commit
3e6f2a94bf Merge tag 'u-boot-imx-master-20240219' of 
https://gitlab.denx.de/u-boot/custodians/u-boot-imx
of the master branch of U-Boot.

v1:
https://patchwork.ozlabs.org/project/uboot/patch/20240216104105.494602-1-s-vadapa...@ti.com/
Changes since v1:
- Rebased patch on latest U-Boot tree.
- As pointed out by Dan in reply to the v1 patch, since the return value of
  setup_resources() cannot be zero, update the check performed on the
  return value accordingly.

Regards,
Siddharth.

 drivers/dma/ti/k3-udma.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index eea9ec9659..ed0a9bf487 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -1770,9 +1770,11 @@ static int udma_probe(struct udevice *dev)
return PTR_ERR(ud->ringacc);
 
ud->dev = dev;
-   ud->ch_count = setup_resources(ud);
-   if (ud->ch_count <= 0)
-   return ud->ch_count;
+   ret = setup_resources(ud);
+   if (ret < 0)
+   return ret;
+
+   ud->ch_count = ret;
 
for (i = 0; i < ud->bchan_cnt; i++) {
struct udma_bchan *bchan = &ud->bchans[i];
@@ -1831,7 +1833,7 @@ static int udma_probe(struct udevice *dev)
 
uc_priv->supported = DMA_SUPPORTS_MEM_TO_MEM | DMA_SUPPORTS_MEM_TO_DEV;
 
-   return ret;
+   return 0;
 }
 
 static int udma_push_to_ring(struct k3_nav_ring *ring, void *elem)
-- 
2.34.1

Re: [PATCH] dma: ti: k3-udma: Fix error handling for setup_resources() in udma_probe()

[Siddharth Vadapalli]

On 24/02/20 03:24PM, Siddharth Vadapalli wrote:
> On 24/02/20 12:51PM, Dan Carpenter wrote:
> > On Fri, Feb 16, 2024 at 04:11:05PM +0530, Siddharth Vadapalli wrote:
> > > diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
> > > index eea9ec9659..8a6625f034 100644
> > > --- a/drivers/dma/ti/k3-udma.c
> > > +++ b/drivers/dma/ti/k3-udma.c
> > > @@ -1770,9 +1770,11 @@ static int udma_probe(struct udevice *dev)
> > >   return PTR_ERR(ud->ringacc);
> > >  
> > >   ud->dev = dev;
> > > - ud->ch_count = setup_resources(ud);
> > > - if (ud->ch_count <= 0)
> > > - return ud->ch_count;
> > > + ret = setup_resources(ud);
> > > + if (ret <= 0)
> > > + return ret;
> > 
> > The code was like this originally, but setup_resources() can't actually
> > return zero so it would be nicer to say:
> > ret = setup_resources(ud);
> > if (ret < 0)
> > return ret;
> 
> Thank you for reviewing the patch and pointing this out. I will fix it
> and post the v2 patch.

I have posted the v2 patch at:
https://patchwork.ozlabs.org/project/uboot/patch/20240220100451.1053667-1-s-vadapa...@ti.com/

Regards,
Siddharth.

Re: [PATCH] cpsw_mdio.c: Use correct reg in cpsw_mdio_get_alive

[Siddharth Vadapalli]

Hello Ulf,

On 07/02/23 13:55, Ulf Samuelsson wrote:
> cpsw_mdio_get_alive reads the wrong register.
> See page 2316 in SPRUH73Q AM335x TRM
> 
> Signed-off-by: Ulf Samuelsson 
> Cc: Joe Hershberger 
> Cc: Ramon Fried 
> ---
>  drivers/net/ti/cpsw_mdio.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ti/cpsw_mdio.c b/drivers/net/ti/cpsw_mdio.c
> index a5ba73b739..ac791faa81 100644
> --- a/drivers/net/ti/cpsw_mdio.c
> +++ b/drivers/net/ti/cpsw_mdio.c
> @@ -51,7 +51,7 @@ struct cpsw_mdio_regs {
>  #define USERACCESS_PHY_REG_SHIFT (21)
>  #define USERACCESS_PHY_ADDR_SHIFT(16)
>  #define USERACCESS_DATA  GENMASK(15, 0)
> - } user[0];
> + } user[2];
>  };
>  
>  #define CPSW_MDIO_DIV_DEF0xff
> @@ -366,8 +366,8 @@ u32 cpsw_mdio_get_alive(struct mii_dev *bus)
>   struct cpsw_mdio *mdio = bus->priv;
>   u32 val;
>  
> - val = readl(&mdio->regs->control);
> - return val & GENMASK(15, 0);
> + val = readl(&mdio->regs->alive);
> + return val & GENMASK(7, 0);

Referring to the TRM for AM335x at [0], on page 2401, the MDIOALIVE register
reports the presence of Ethernet PHYs up to ADDR 31. Also, the cpsw driver:
drivers/net/ti/cpsw.c which uses the cpsw_mdio_get_alive() function, expects the
return value to be a 16 bit value. Therefore, I believe that the GENMASK should
retain the previous value of "GENMASK(15, 0)", while only the register being
read needs to be changed from "control" to "alive". Please let me know if I
misunderstood something regarding your implementation.

[0] https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf

Regards,
Siddharth.

>  }
>  
>  struct mii_dev *cpsw_mdio_init(const char *name, phys_addr_t mdio_base,

Re: [PATCH] cpsw_mdio.c: Use correct reg in cpsw_mdio_get_alive

[Siddharth Vadapalli]

On 09/02/23 14:56, Ulf Samuelsson wrote:
> 
> Den 2023-02-09 kl. 08:29, skrev Siddharth Vadapalli:
>> Hello Ulf,
>>
>> On 07/02/23 13:55, Ulf Samuelsson wrote:
>>> cpsw_mdio_get_alive reads the wrong register.
>>> See page 2316 in SPRUH73Q AM335x TRM
>>>
>>> Signed-off-by: Ulf Samuelsson 
>>> Cc: Joe Hershberger 
>>> Cc: Ramon Fried 
>>> ---
>>>   drivers/net/ti/cpsw_mdio.c | 6 +++---
>>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/ti/cpsw_mdio.c b/drivers/net/ti/cpsw_mdio.c
>>> index a5ba73b739..ac791faa81 100644
>>> --- a/drivers/net/ti/cpsw_mdio.c
>>> +++ b/drivers/net/ti/cpsw_mdio.c
>>> @@ -51,7 +51,7 @@ struct cpsw_mdio_regs {
>>>   #define USERACCESS_PHY_REG_SHIFT    (21)
>>>   #define USERACCESS_PHY_ADDR_SHIFT    (16)
>>>   #define USERACCESS_DATA    GENMASK(15, 0)
>>> -    } user[0];
>>> +    } user[2];
>>>   };
>>>     #define CPSW_MDIO_DIV_DEF    0xff
>>> @@ -366,8 +366,8 @@ u32 cpsw_mdio_get_alive(struct mii_dev *bus)
>>>   struct cpsw_mdio *mdio = bus->priv;
>>>   u32 val;
>>>   -    val = readl(&mdio->regs->control);
>>> -    return val & GENMASK(15, 0);
>>> +    val = readl(&mdio->regs->alive);
>>> +    return val & GENMASK(7, 0);
>>
>> Referring to the TRM for AM335x at [0], on page 2401, the MDIOALIVE register
>> reports the presence of Ethernet PHYs up to ADDR 31. Also, the cpsw driver:
>> drivers/net/ti/cpsw.c which uses the cpsw_mdio_get_alive() function, expects 
>> the
>> return value to be a 16 bit value. Therefore, I believe that the GENMASK 
>> should
>> retain the previous value of "GENMASK(15, 0)", while only the register being
>> read needs to be changed from "control" to "alive". Please let me know if I
>> misunderstood something regarding your implementation.
>>
> We had an unusual H/W where the PHY (actually a switch) was connected to the
> second Ethernet port. All boards I have seen have the PHY connected to the 
> first
> port or have both ports connected.
> 
> IIRC correctly (this patch is > 2 years old),
> we had bad data in the bits (15:8) and this is why only the 8 bits.
> Only bits [1:0] are used anyway.

Thank you for clarifying.

Reviewed-by: Siddharth Vadapalli 

Regards,
Siddharth.

[RFC PATCH 0/2] Add TI K3 PCIe Controller support for J7200

[Siddharth Vadapalli]

Hello,

This series adds support for the Cadence PCIe controller on TI's K3
family of SoCs which J7200 belongs to. The driver is an adaptation
of the Linux driver (drivers/pci/controller/cadence/pci-j721e.c)
and has been implemented specifically for Root-Complex mode of operation
on J7200. A minor set of changes will be sufficient to support other
K3 SoCs as well, which has been indicated with "TODO"s added in the
driver code.

Series is based on commit
d2067c3ea5 Merge tag 'u-boot-dfu-next-20240820' of 
https://source.denx.de/u-boot/custodians/u-boot-dfu into next
of the next branch of U-Boot.

I have posted this series as an RFC for feedback regarding the
implementation. I plan to implement the remaining changes to truly
support all K3 SoCs that are currently supported by the pci-j721e.c
driver in Linux in Root-Complex mode of operation. I have tested this
series with the following changes made to the device-tree for J7200:
https://gist.github.com/Siddharth-Vadapalli-at-TI/1a498722ebb332da6f88abe05a43f2c4

The device-tree changes are required since the "reg-mux" driver is not
currently implemented in U-Boot. I will work on porting the "reg-mux"
driver support from Linux.

The logs corresponding to validating PCI Root-Complex functionality with
an NVMe SSD connected to the PCIe Connector on J7200-EVM, with this series
and the aforementioned device-tree changes applied are:
https://gist.github.com/Siddharth-Vadapalli-at-TI/bbcbfa0b7d593795726c81fb41272823

Regards,
Siddharth.

Siddharth Vadapalli (2):
  pci: Add TI K3 Cadence PCIe Controller
  configs: j7200_evm_a72_defconfig: Enable configs for PCI support

 configs/j7200_evm_a72_defconfig |   4 +
 drivers/pci/Kconfig |   6 +
 drivers/pci/Makefile|   1 +
 drivers/pci/pcie_cdns_ti.c  | 645 
 4 files changed, 656 insertions(+)
 create mode 100644 drivers/pci/pcie_cdns_ti.c

-- 
2.40.1

[RFC PATCH 1/2] pci: Add TI K3 Cadence PCIe Controller

[Siddharth Vadapalli]

Add support for the Cadence PCIe Controller present on TI's K3 SoCs.
This driver is an adaptation of the Linux driver.

Signed-off-by: Siddharth Vadapalli 
---
 drivers/pci/Kconfig|   6 +
 drivers/pci/Makefile   |   1 +
 drivers/pci/pcie_cdns_ti.c | 645 +
 3 files changed, 652 insertions(+)
 create mode 100644 drivers/pci/pcie_cdns_ti.c

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 22a56f4ca3..876a5fa57e 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -137,6 +137,12 @@ config PCI_GT64120
bool "GT64120 PCI support"
depends on MIPS
 
+config PCIE_CDNS_TI
+   bool "TI K3 PCIe support"
+   help
+ Say Y here to enable support for the Cadence PCIe Controller
+ on TI's K3 SoCs.
+
 config PCI_PHYTIUM
bool "Phytium PCIe support"
help
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 5b2d296980..bf361cd0fb 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_PCI) += pci_auto_common.o pci_common.o
 obj-$(CONFIG_PCIE_ECAM_GENERIC) += pcie_ecam_generic.o
 obj-$(CONFIG_PCIE_ECAM_SYNQUACER) += pcie_ecam_synquacer.o
 obj-$(CONFIG_PCIE_APPLE) += pcie_apple.o
+obj-$(CONFIG_PCIE_CDNS_TI) += pcie_cdns_ti.o
 obj-$(CONFIG_PCI_FTPCI100) += pci_ftpci100.o
 obj-$(CONFIG_PCI_GT64120) += pci_gt64120.o
 obj-$(CONFIG_PCI_MPC85XX) += pci_mpc85xx.o
diff --git a/drivers/pci/pcie_cdns_ti.c b/drivers/pci/pcie_cdns_ti.c
new file mode 100644
index 00..2b9bba19b4
--- /dev/null
+++ b/drivers/pci/pcie_cdns_ti.c
@@ -0,0 +1,645 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com
+ *
+ * PCIe controller driver for TI's K3 SoCs with Cadence PCIe controller
+ *
+ * Ported from the Linux driver - drivers/pci/controller/cadence/pci-j721e.c
+ *
+ * Author: Siddharth Vadapalli 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define CDNS_PCIE_LM_BASE  0x0010
+#define CDNS_PCIE_LM_ID(CDNS_PCIE_LM_BASE + 0x0044)
+#define CDNS_PCIE_LTSSM_CTRL_CAP   (CDNS_PCIE_LM_BASE + 0x0054)
+#define CDNS_PCIE_LM_RC_BAR_CFG(CDNS_PCIE_LM_BASE + 0x0300)
+
+#define CDNS_PCIE_LM_ID_VENDOR_MASKGENMASK(15, 0)
+#define CDNS_PCIE_LM_ID_VENDOR_SHIFT   0
+#define CDNS_PCIE_LM_ID_VENDOR(vid) \
+   (((vid) << CDNS_PCIE_LM_ID_VENDOR_SHIFT) & CDNS_PCIE_LM_ID_VENDOR_MASK)
+#define CDNS_PCIE_LM_ID_SUBSYS_MASKGENMASK(31, 16)
+#define CDNS_PCIE_LM_ID_SUBSYS_SHIFT   16
+#define CDNS_PCIE_LM_ID_SUBSYS(sub) \
+   (((sub) << CDNS_PCIE_LM_ID_SUBSYS_SHIFT) & CDNS_PCIE_LM_ID_SUBSYS_MASK)
+
+#define CDNS_PCIE_LM_RC_BAR_CFG_BAR0_CTRL_MASK GENMASK(8, 6)
+#define CDNS_PCIE_LM_RC_BAR_CFG_BAR0_CTRL(c) \
+   (((c) << 6) & CDNS_PCIE_LM_RC_BAR_CFG_BAR0_CTRL_MASK)
+#define CDNS_PCIE_LM_RC_BAR_CFG_BAR1_CTRL_MASK GENMASK(16, 14)
+#define CDNS_PCIE_LM_RC_BAR_CFG_BAR1_CTRL(c) \
+   (((c) << 14) & CDNS_PCIE_LM_RC_BAR_CFG_BAR1_CTRL_MASK)
+#define CDNS_PCIE_LM_RC_BAR_CFG_PREFETCH_MEM_ENABLEBIT(17)
+#define CDNS_PCIE_LM_RC_BAR_CFG_PREFETCH_MEM_64BITSBIT(18)
+#define CDNS_PCIE_LM_RC_BAR_CFG_IO_ENABLE  BIT(19)
+#define CDNS_PCIE_LM_RC_BAR_CFG_IO_32BITS  BIT(20)
+
+#define CDNS_PCIE_LM_BAR_CFG_CTRL_DISABLED 0x0
+
+#define CDNS_PCIE_RP_BASE  0x0020
+
+/*
+ * Address Translation Registers
+ */
+#define CDNS_PCIE_AT_BASE  0x0040
+
+/* Region r Outbound AXI to PCIe Address Translation Register 0 */
+#define CDNS_PCIE_AT_OB_REGION_PCI_ADDR0(r) \
+   (CDNS_PCIE_AT_BASE + 0x + ((r) & 0x1f) * 0x0020)
+#define CDNS_PCIE_AT_OB_REGION_PCI_ADDR0_NBITS_MASKGENMASK(5, 0)
+#define CDNS_PCIE_AT_OB_REGION_PCI_ADDR0_NBITS(nbits) \
+   (((nbits) - 1) & CDNS_PCIE_AT_OB_REGION_PCI_ADDR0_NBITS_MASK)
+#define CDNS_PCIE_AT_OB_REGION_PCI_ADDR0_DEVFN_MASKGENMASK(19, 12)
+#define CDNS_PCIE_AT_OB_REGION_PCI_ADDR0_DEVFN(devfn) \
+   (((devfn) << 12) & CDNS_PCIE_AT_OB_REGION_PCI_ADDR0_DEVFN_MASK)
+#define CDNS_PCIE_AT_OB_REGION_PCI_ADDR0_BUS_MASK  GENMASK(27, 20)
+#define CDNS_PCIE_AT_OB_REGION_PCI_ADDR0_BUS(bus) \
+   (((bus) << 20) & CDNS_PCIE_AT_OB_REGION_PCI_ADDR0_BUS_MASK)
+
+/* Region r Outbound AXI to PCIe Address Translation Register 1 */
+#define CDNS_PCIE_AT_OB_REGION_PCI_ADDR1(r) \
+   (CDNS_PCIE_AT_BASE + 0x0004 + ((r) & 0x1f) * 0x0020)
+
+/* Region r Outbound PCIe Descriptor Register 0 */
+#define CDNS_PCIE_AT_OB_REGION_DESC0(r) \
+   (CDNS_PCIE_AT_BASE + 0x0008 + ((r) & 0x1f) * 0x0020)
+#define CDNS_PCIE_AT_OB_REGION_DESC0_TYPE_MEM  0x2
+#defin

[RFC PATCH 2/2] configs: j7200_evm_a72_defconfig: Enable configs for PCI support

[Siddharth Vadapalli]

TI's J7200 SoC has a single instance of PCIe Controller namely PCIe1 which
is a Cadence PCIe Controller. To support PCI functionality with the PCIe1
instance of PCIe, enable the corresponding configs.

Signed-off-by: Siddharth Vadapalli 
---
 configs/j7200_evm_a72_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig
index fcfa926599..5a8cc0e6a7 100644
--- a/configs/j7200_evm_a72_defconfig
+++ b/configs/j7200_evm_a72_defconfig
@@ -32,6 +32,7 @@ CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI=y
 # CONFIG_PSCI_RESET is not set
+CONFIG_PCI=y
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
@@ -72,6 +73,7 @@ CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_MTD=y
+CONFIG_CMD_PCI=y
 CONFIG_CMD_REMOTEPROC=y
 CONFIG_CMD_UFS=y
 CONFIG_CMD_USB=y
@@ -154,6 +156,8 @@ CONFIG_MUX_MMIO=y
 CONFIG_PHY_TI_DP83869=y
 CONFIG_PHY_FIXED=y
 CONFIG_TI_AM65_CPSW_NUSS=y
+CONFIG_PCI_CONFIG_HOST_BRIDGE=y
+CONFIG_PCIE_CDNS_TI=y
 CONFIG_PHY=y
 CONFIG_SPL_PHY=y
 CONFIG_PHY_CADENCE_TORRENT=y
-- 
2.40.1

Re: [RFC PATCH 1/2] pci: Add TI K3 Cadence PCIe Controller

[Siddharth Vadapalli]

On Wed, Aug 21, 2024 at 12:00:20PM -0600, Tom Rini wrote:
> On Wed, Aug 21, 2024 at 08:29:07PM +0530, Siddharth Vadapalli wrote:
> 

[...]

> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> Please audit this list to make sure you need everything because..
> 
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> 
> You don't reference gd in this code at all, so don't need this.

I missed dropping this. I had checked that the rest of the includes are
required, but I will re-check when I post the v2 patch.

> 
> So please also make sure the giant list of defines is needed.

During the development of this driver, I had committed the changes with
around 15 commits that had the defines added only when needed. Therefore
I am positive that they are required. I squashed those commits into a
single one which is this patch. Nevertheless, I will double check before
posting the v2 patch.

> > +#define usleep_range(a, b) udelay((b))
> 
> Per checkpatch.pl.conf:
> # Not Linux, so we don't recommend usleep_range() over udelay()

Sure, I will switch to udelay().

Thank you for reviewing this patch and providing feedback. I will implement
your suggestions in the v2 patch.

Regards,
Siddharth.

[PATCH v2] usb: gadget: cdns3: Fix cdns3_ep_config() by setting ep.maxpacket

[Siddharth Vadapalli]

The function cdns3_ep_config() calculates the maximum packet size based
on the Endpoint Type and the Gadget Speed and stores it in the variable
"max_packet_size". This value is then programmed in the USB Controller
for the corresponding Endpoint. This may result in a mismatch between
the maximum packet size programmed in the USB controller and the maximum
packet size seen by the UDC Core via "maxpacket" member of "struct usb_ep".
Additionally, since TD_SIZE is calculated in cdns3_ep_run_transfer() on the
basis of the maximum packet size stored in the "maxpacket" member of
"struct usb_ep", it may lead to an incorrect value of TD_SIZE when compared
with what the USB controller actually expects (max_packet_size).

Fix this.

Fixes: 7e91f6ccdc84 ("usb: Add Cadence USB3 host and gadget driver")
Signed-off-by: Siddharth Vadapalli 
---

Hello,

This patch is based on commit
dd4d130c8e clk: renesas: rcar-gen3: Fix SSCG caching replacement with MDSEL/PE 
caching
of the master branch of U-Boot.

v1:
https://patchwork.ozlabs.org/project/uboot/patch/20241007104239.1624430-1-s-vadapa...@ti.com/
Changes since v1:
- Based on Roger's feedback at:
  
https://patchwork.ozlabs.org/project/uboot/patch/20241007104239.1624430-1-s-vadapa...@ti.com/#3389960
  rather than using usb_ep_set_maxpacket_limit() which changes
  "maxpacket_limit" in addition to "maxpacket", only update the "maxpacket"
  member of usb_ep.

Regards,
Siddharth.

 drivers/usb/cdns3/gadget.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
index ac7e469469..a30c40ef80 100644
--- a/drivers/usb/cdns3/gadget.c
+++ b/drivers/usb/cdns3/gadget.c
@@ -1637,6 +1637,14 @@ void cdns3_ep_config(struct cdns3_endpoint *priv_ep)
else
priv_ep->trb_burst_size = 16;
 
+   /*
+* The Endpoint is configured to handle a maximum packet size of
+* max_packet_size. Hence, set priv_ep->endpoint.maxpacket to
+* max_packet_size. This is necessary to ensure that the TD_SIZE
+* is calculated correctly in cdns3_ep_run_transfer().
+*/
+   priv_ep->endpoint.maxpacket = max_packet_size;
+
ret = cdns3_ep_onchip_buffer_reserve(priv_dev, buffering + 1,
 !!priv_ep->dir);
if (ret) {
-- 
2.40.1

Re: [PATCH] usb: gadget: cdns3: Fix cdns3_ep_config() by setting ep.maxpacket

[Siddharth Vadapalli]

On Mon, Oct 07, 2024 at 05:37:52PM +0530, Siddharth Vadapalli wrote:
> On Mon, Oct 07, 2024 at 03:02:34PM +0300, Roger Quadros wrote:
> 
> Hello Roger,

[...]

> > from include/linux/usb/gadget.h
> > 
> >  * struct usb_ep - device side representation of USB endpoint
> > ...
> >  * @maxpacket:The maximum packet size used on this endpoint.  The initial
> >  *  value can sometimes be reduced (hardware allowing), according to
> >  *  the endpoint descriptor used to configure the endpoint.
> >  * @maxpacket_limit:The maximum packet size value which can be handled by 
> > this
> >  *  endpoint. It's set once by UDC driver when endpoint is initialized, 
> > and
> >  *  should not be changed. Should not be confused with maxpacket.
> > 
> > What you want to change is ep->maxpacket and not ep->maxpacket_limit as 
> > that is
> > fixed for a particular UDC.
> > 
> > how about?
> > priv-ep->endpoint.maxpacket = max_packet_size;
> 
> Yes, this is accurate. I will post the v2 patch with this change. Thank
> you for reviewing the patch.

I have implemented your feedback and have posted the v2 patch at:
https://patchwork.ozlabs.org/project/uboot/patch/20241007121927.1680039-1-s-vadapa...@ti.com

Regards,
Siddharth.

[PATCH v3 1/2] pci: Add TI K3 Cadence PCIe Controller

[Siddharth Vadapalli]

Add support for the Cadence PCIe Controller present on TI's K3 SoCs.
This driver is an adaptation of the Linux driver.

Signed-off-by: Siddharth Vadapalli 
---

v2:
https://patchwork.ozlabs.org/project/uboot/patch/20241011130258.3452687-2-s-vadapa...@ti.com/
Changes since v2:
- Addressed Tom's feedback at:
  
https://patchwork.ozlabs.org/project/uboot/patch/20241011130258.3452687-2-s-vadapa...@ti.com/#3393548
  by adding MAINTAINERS entry for pcie_cdns_ti.c and by fixing
  indentation for all macros.

v1:
https://patchwork.ozlabs.org/project/uboot/patch/20240821145908.3408573-2-s-vadapa...@ti.com/
Changes since v1:
- Addressed Tom's feedback at:
  
https://patchwork.ozlabs.org/project/uboot/patch/20240821145908.3408573-2-s-vadapa...@ti.com/#3365925
  by removing extra headers and replacing usleep_range() with udelay().
- Added inbound translation configuration thereby enabling support for
  NVMe devices.
- Added SoC specific quirks and the corresponding code to handle them.

Regards,
Siddharth.

 MAINTAINERS|   1 +
 drivers/pci/Kconfig|   6 +
 drivers/pci/Makefile   |   1 +
 drivers/pci/pcie_cdns_ti.c | 853 +
 4 files changed, 861 insertions(+)
 create mode 100644 drivers/pci/pcie_cdns_ti.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7aefda93d0..a43fddf9f2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -748,6 +748,7 @@ F:  drivers/gpio/omap_gpio.c
 F: drivers/memory/ti-aemif.c
 F: drivers/misc/k3_avs.c
 F: drivers/mailbox/k3-sec-procy.c
+F: drivers/pci/pcie_cdns_ti.c
 F: drivers/pci/pcie_dw_ti.c
 F: drivers/phy/keystone-usb-phy.c
 F: drivers/phy/omap-usb2-phy.c
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 22a56f4ca3..876a5fa57e 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -137,6 +137,12 @@ config PCI_GT64120
bool "GT64120 PCI support"
depends on MIPS
 
+config PCIE_CDNS_TI
+   bool "TI K3 PCIe support"
+   help
+ Say Y here to enable support for the Cadence PCIe Controller
+ on TI's K3 SoCs.
+
 config PCI_PHYTIUM
bool "Phytium PCIe support"
help
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 5b2d296980..bf361cd0fb 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_PCI) += pci_auto_common.o pci_common.o
 obj-$(CONFIG_PCIE_ECAM_GENERIC) += pcie_ecam_generic.o
 obj-$(CONFIG_PCIE_ECAM_SYNQUACER) += pcie_ecam_synquacer.o
 obj-$(CONFIG_PCIE_APPLE) += pcie_apple.o
+obj-$(CONFIG_PCIE_CDNS_TI) += pcie_cdns_ti.o
 obj-$(CONFIG_PCI_FTPCI100) += pci_ftpci100.o
 obj-$(CONFIG_PCI_GT64120) += pci_gt64120.o
 obj-$(CONFIG_PCI_MPC85XX) += pci_mpc85xx.o
diff --git a/drivers/pci/pcie_cdns_ti.c b/drivers/pci/pcie_cdns_ti.c
new file mode 100644
index 00..41469a186a
--- /dev/null
+++ b/drivers/pci/pcie_cdns_ti.c
@@ -0,0 +1,853 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com
+ *
+ * PCIe controller driver for TI's K3 SoCs with Cadence PCIe controller
+ *
+ * Ported from the Linux driver - drivers/pci/controller/cadence/pci-j721e.c
+ *
+ * Author: Siddharth Vadapalli 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CDNS_PCIE_LM_BASE  0x0010
+#define CDNS_PCIE_LM_ID(CDNS_PCIE_LM_BASE + 0x0044)
+#define CDNS_PCIE_LTSSM_CTRL_CAP   (CDNS_PCIE_LM_BASE + 0x0054)
+#define CDNS_PCIE_LM_RC_BAR_CFG(CDNS_PCIE_LM_BASE + 0x0300)
+
+#define CDNS_PCIE_LM_ID_VENDOR_MASKGENMASK(15, 0)
+#define CDNS_PCIE_LM_ID_VENDOR_SHIFT   0
+#define CDNS_PCIE_LM_ID_VENDOR(vid) \
+(((vid) << CDNS_PCIE_LM_ID_VENDOR_SHIFT) & CDNS_PCIE_LM_ID_VENDOR_MASK)
+#define CDNS_PCIE_LM_ID_SUBSYS_MASKGENMASK(31, 16)
+#define CDNS_PCIE_LM_ID_SUBSYS_SHIFT   16
+#define CDNS_PCIE_LM_ID_SUBSYS(sub) \
+(((sub) << CDNS_PCIE_LM_ID_SUBSYS_SHIFT) & CDNS_PCIE_LM_ID_SUBSYS_MASK)
+
+#define CDNS_PCIE_LM_RC_BAR_CFG_BAR0_CTRL_MASK GENMASK(8, 6)
+#define CDNS_PCIE_LM_RC_BAR_CFG_BAR0_CTRL(c) \
+(((c) << 6) & CDNS_PCIE_LM_RC_BAR_CFG_BAR0_CTRL_MASK)
+
+#define CDNS_PCIE_LM_RC_BAR_CFG_BAR1_CTRL_MASK GENMASK(16, 14)
+#define CDNS_PCIE_LM_RC_BAR_CFG_BAR1_CTRL(c) \
+(((c) << 14) & CDNS_PCIE_LM_RC_BAR_CFG_BAR1_CTRL_MASK)
+
+#define CDNS_PCIE_LM_RC_BAR_CFG_PREFETCH_MEM_ENABLEBIT(17)
+#define CDNS_PCIE_LM_RC_BAR_CFG_PREFETCH_MEM_64BITSBIT(18)
+#define CDNS_PCIE_LM_RC_BAR_CFG_IO_ENABLE  BIT(19)
+#define CDNS_PCIE_LM_RC_BAR_CFG_IO_32BITS  BIT(20)
+
+#define CDNS_PCIE_LM_BAR_CFG_CTRL_DISABLED 0x0
+#define CDNS_PCIE_LM_BAR_CFG_CTRL_MEM_32BITS   0x4
+#define CDNS_PCIE_LM_BAR_CFG_CTRL_PREFETCH_MEM_32BITS  0x5
+#define CDNS_PCIE_LM_BA

[PATCH v3 2/2] configs: j7200_evm_a72_defconfig: Enable configs for PCI support

[Siddharth Vadapalli]

TI's J7200 SoC has a single instance of PCIe Controller namely PCIe1 which
is a Cadence PCIe Controller. To support PCIe functionality with the PCIe1
instance of PCIe, enable the corresponding configs.

Signed-off-by: Siddharth Vadapalli 
---

v2:
https://patchwork.ozlabs.org/project/uboot/patch/20241011130258.3452687-3-s-vadapa...@ti.com/
No changes since v2.

v1:
https://patchwork.ozlabs.org/project/uboot/patch/20240821145908.3408573-3-s-vadapa...@ti.com/
Changes since v1:
- Updated j7200_evm_a72_defconfig to enable NVMe configs since NVMe is
  now supported with this series.

Regards,
Siddharth.

 configs/j7200_evm_a72_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig
index 2fbfda5cf8..12745a9adc 100644
--- a/configs/j7200_evm_a72_defconfig
+++ b/configs/j7200_evm_a72_defconfig
@@ -32,6 +32,7 @@ CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI=y
 # CONFIG_PSCI_RESET is not set
+CONFIG_PCI=y
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
@@ -71,6 +72,7 @@ CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_MTD=y
+CONFIG_CMD_PCI=y
 CONFIG_CMD_REMOTEPROC=y
 CONFIG_CMD_UFS=y
 CONFIG_CMD_USB=y
@@ -153,6 +155,9 @@ CONFIG_MUX_MMIO=y
 CONFIG_PHY_TI_DP83869=y
 CONFIG_PHY_FIXED=y
 CONFIG_TI_AM65_CPSW_NUSS=y
+CONFIG_NVME_PCI=y
+CONFIG_PCI_CONFIG_HOST_BRIDGE=y
+CONFIG_PCIE_CDNS_TI=y
 CONFIG_PHY=y
 CONFIG_SPL_PHY=y
 CONFIG_PHY_CADENCE_TORRENT=y
-- 
2.40.1

[PATCH v3 0/2] Add TI K3 PCIe Controller support for J7200

[Siddharth Vadapalli]

Hello,

This series adds support for the Cadence PCIe controller on TI's K3
family of SoCs to which the J7200 SoC belongs. The driver is an adaptation
of the Linux driver (drivers/pci/controller/cadence/pci-j721e.c) and has
been implemented specifically for Root-Complex mode of operation on the
J7200 SoC. A minor set of changes will be sufficient to support other K3
SoCs as well with plans to implement it in the near future.

Series is based on commit
580fb57736 Merge tag 'u-boot-imx-master-20241013' of 
https://gitlab.denx.de/u-boot/custodians/u-boot-imx
of the master branch of U-Boot.

v2:
https://patchwork.ozlabs.org/project/uboot/cover/20241011130258.3452687-1-s-vadapa...@ti.com/
Changes since v2:
- Addressed Tom's feedback at:
  
https://patchwork.ozlabs.org/project/uboot/patch/20241011130258.3452687-2-s-vadapa...@ti.com/#3393548
  by adding MAINTAINERS entry for pcie_cdns_ti.c and by fixing
  indentation for all macros.

v1 of this series was posted as an RFC at:
https://patchwork.ozlabs.org/project/uboot/cover/20240821145908.3408573-1-s-vadapa...@ti.com/
Changes since v1:
- Addressed Tom's feedback at:
  
https://patchwork.ozlabs.org/project/uboot/patch/20240821145908.3408573-2-s-vadapa...@ti.com/#3365925
  by removing extra headers and replacing usleep_range() with udelay().
- Added inbound translation configuration thereby enabling support for
  NVMe devices.
- Added SoC specific quirks and the corresponding code to handle them.
- Updated j7200_evm_a72_defconfig to enable NVMe configs since NVMe is
  now supported with this series.

The logs corresponding to validating PCI Root-Complex functionality with
an NVMe SSD connected to the PCIe Connector on J7200-EVM are at:
https://gist.github.com/Siddharth-Vadapalli-at-TI/c64a2defa6b5b59e2b734307ad57b2d8

Regards,
Siddharth.

Siddharth Vadapalli (2):
  pci: Add TI K3 Cadence PCIe Controller
  configs: j7200_evm_a72_defconfig: Enable configs for PCI support

 MAINTAINERS |   1 +
 configs/j7200_evm_a72_defconfig |   5 +
 drivers/pci/Kconfig |   6 +
 drivers/pci/Makefile|   1 +
 drivers/pci/pcie_cdns_ti.c  | 853 
 5 files changed, 866 insertions(+)
 create mode 100644 drivers/pci/pcie_cdns_ti.c

-- 
2.40.1

[PATCH v2 1/2] pci: Add TI K3 Cadence PCIe Controller

[Siddharth Vadapalli]

Add support for the Cadence PCIe Controller present on TI's K3 SoCs.
This driver is an adaptation of the Linux driver.

Signed-off-by: Siddharth Vadapalli 
---
 drivers/pci/Kconfig|   6 +
 drivers/pci/Makefile   |   1 +
 drivers/pci/pcie_cdns_ti.c | 851 +
 3 files changed, 858 insertions(+)
 create mode 100644 drivers/pci/pcie_cdns_ti.c

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 22a56f4ca3..876a5fa57e 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -137,6 +137,12 @@ config PCI_GT64120
bool "GT64120 PCI support"
depends on MIPS
 
+config PCIE_CDNS_TI
+   bool "TI K3 PCIe support"
+   help
+ Say Y here to enable support for the Cadence PCIe Controller
+ on TI's K3 SoCs.
+
 config PCI_PHYTIUM
bool "Phytium PCIe support"
help
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 5b2d296980..bf361cd0fb 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_PCI) += pci_auto_common.o pci_common.o
 obj-$(CONFIG_PCIE_ECAM_GENERIC) += pcie_ecam_generic.o
 obj-$(CONFIG_PCIE_ECAM_SYNQUACER) += pcie_ecam_synquacer.o
 obj-$(CONFIG_PCIE_APPLE) += pcie_apple.o
+obj-$(CONFIG_PCIE_CDNS_TI) += pcie_cdns_ti.o
 obj-$(CONFIG_PCI_FTPCI100) += pci_ftpci100.o
 obj-$(CONFIG_PCI_GT64120) += pci_gt64120.o
 obj-$(CONFIG_PCI_MPC85XX) += pci_mpc85xx.o
diff --git a/drivers/pci/pcie_cdns_ti.c b/drivers/pci/pcie_cdns_ti.c
new file mode 100644
index 00..19267ace4a
--- /dev/null
+++ b/drivers/pci/pcie_cdns_ti.c
@@ -0,0 +1,851 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com
+ *
+ * PCIe controller driver for TI's K3 SoCs with Cadence PCIe controller
+ *
+ * Ported from the Linux driver - drivers/pci/controller/cadence/pci-j721e.c
+ *
+ * Author: Siddharth Vadapalli 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CDNS_PCIE_LM_BASE  0x0010
+#define CDNS_PCIE_LM_ID(CDNS_PCIE_LM_BASE + 0x0044)
+#define CDNS_PCIE_LTSSM_CTRL_CAP   (CDNS_PCIE_LM_BASE + 0x0054)
+#define CDNS_PCIE_LM_RC_BAR_CFG(CDNS_PCIE_LM_BASE + 0x0300)
+
+#define CDNS_PCIE_LM_ID_VENDOR_MASKGENMASK(15, 0)
+#define CDNS_PCIE_LM_ID_VENDOR_SHIFT   0
+#define CDNS_PCIE_LM_ID_VENDOR(vid) \
+   (((vid) << CDNS_PCIE_LM_ID_VENDOR_SHIFT) & CDNS_PCIE_LM_ID_VENDOR_MASK)
+#define CDNS_PCIE_LM_ID_SUBSYS_MASKGENMASK(31, 16)
+#define CDNS_PCIE_LM_ID_SUBSYS_SHIFT   16
+#define CDNS_PCIE_LM_ID_SUBSYS(sub) \
+   (((sub) << CDNS_PCIE_LM_ID_SUBSYS_SHIFT) & CDNS_PCIE_LM_ID_SUBSYS_MASK)
+
+#define CDNS_PCIE_LM_RC_BAR_CFG_BAR0_CTRL_MASK GENMASK(8, 6)
+#define CDNS_PCIE_LM_RC_BAR_CFG_BAR0_CTRL(c) \
+   (((c) << 6) & CDNS_PCIE_LM_RC_BAR_CFG_BAR0_CTRL_MASK)
+#define CDNS_PCIE_LM_RC_BAR_CFG_BAR1_CTRL_MASK GENMASK(16, 14)
+#define CDNS_PCIE_LM_RC_BAR_CFG_BAR1_CTRL(c) \
+   (((c) << 14) & CDNS_PCIE_LM_RC_BAR_CFG_BAR1_CTRL_MASK)
+#define CDNS_PCIE_LM_RC_BAR_CFG_PREFETCH_MEM_ENABLEBIT(17)
+#define CDNS_PCIE_LM_RC_BAR_CFG_PREFETCH_MEM_64BITSBIT(18)
+#define CDNS_PCIE_LM_RC_BAR_CFG_IO_ENABLE  BIT(19)
+#define CDNS_PCIE_LM_RC_BAR_CFG_IO_32BITS  BIT(20)
+
+#define CDNS_PCIE_LM_BAR_CFG_CTRL_DISABLED 0x0
+#define  CDNS_PCIE_LM_BAR_CFG_CTRL_MEM_32BITS  0x4
+#define  CDNS_PCIE_LM_BAR_CFG_CTRL_PREFETCH_MEM_32BITS 0x5
+#define  CDNS_PCIE_LM_BAR_CFG_CTRL_MEM_64BITS  0x6
+#define  CDNS_PCIE_LM_BAR_CFG_CTRL_PREFETCH_MEM_64BITS 0x7
+
+#define LM_RC_BAR_CFG_CTRL_MEM_32BITS(bar) \
+   (CDNS_PCIE_LM_BAR_CFG_CTRL_MEM_32BITS << (((bar) * 8) + 6))
+#define LM_RC_BAR_CFG_CTRL_PREF_MEM_32BITS(bar)\
+   (CDNS_PCIE_LM_BAR_CFG_CTRL_PREFETCH_MEM_32BITS << (((bar) * 8) + 6))
+#define LM_RC_BAR_CFG_CTRL_MEM_64BITS(bar) \
+   (CDNS_PCIE_LM_BAR_CFG_CTRL_MEM_64BITS << (((bar) * 8) + 6))
+#define LM_RC_BAR_CFG_CTRL_PREF_MEM_64BITS(bar)\
+   (CDNS_PCIE_LM_BAR_CFG_CTRL_PREFETCH_MEM_64BITS << (((bar) * 8) + 6))
+#define LM_RC_BAR_CFG_APERTURE(bar, aperture)  \
+   (((aperture) - 2) << ((bar) * 8))
+
+#define CDNS_PCIE_RP_BASE  0x0020
+#define CDNS_PCIE_RP_CAP_OFFSET 0xc0
+
+/*
+ * Address Translation Registers
+ */
+#define CDNS_PCIE_AT_BASE  0x0040
+
+/* Region r Outbound AXI to PCIe Address Translation Register 0 */
+#define CDNS_PCIE_AT_OB_REGION_PCI_ADDR0(r) \
+   (CDNS_PCIE_AT_BASE + 0x + ((r) & 0x1f) * 0x0020)
+#define CDNS_PCIE_AT_OB_REGION_PCI_ADDR0_NBITS_MASKGENMASK(5, 0)
+#define CDNS_PCIE_AT_OB_REGION_PCI_ADDR0_NBITS(nbits) \
+   (((nbits) - 1

[PATCH v2 0/2] Add TI K3 PCIe Controller support for J7200

[Siddharth Vadapalli]

Hello,

This series adds support for the Cadence PCIe controller on TI's K3
family of SoCs to which the J7200 SoC belongs. The driver is an adaptation
of the Linux driver (drivers/pci/controller/cadence/pci-j721e.c) and has
been implemented specifically for Root-Complex mode of operation on the
J7200 SoC. A minor set of changes will be sufficient to support other K3
SoCs as well with plans to implement it in the near future.

Series is based on commit
a404065479 power: pmic: pca9450: Add missing newline
of the master branch of U-Boot.

v1 of this series was posted as an RFC at:
https://patchwork.ozlabs.org/project/uboot/cover/20240821145908.3408573-1-s-vadapa...@ti.com/
Changes since v1:
- Addressed Tom's feedback at:
  
https://patchwork.ozlabs.org/project/uboot/patch/20240821145908.3408573-2-s-vadapa...@ti.com/#3365925
  by removing extra headers and replacing usleep_range() with udelay().
- Added inbound translation configuration thereby enabling support for
  NVMe devices.
- Added SoC specific quirks and the corresponding code to handle them.
- Updated j7200_evm_a72_defconfig to enable NVMe configs since NVMe is
  now supported with this series.

The logs corresponding to validating PCI Root-Complex functionality with
an NVMe SSD connected to the PCIe Connector on J7200-EVM are at:
https://gist.github.com/Siddharth-Vadapalli-at-TI/18a64e0c258f74274d80c5871594f0dc

Regards,
Siddharth.

Siddharth Vadapalli (2):
  pci: Add TI K3 Cadence PCIe Controller
  configs: j7200_evm_a72_defconfig: Enable configs for PCI support

 configs/j7200_evm_a72_defconfig |   5 +
 drivers/pci/Kconfig |   6 +
 drivers/pci/Makefile|   1 +
 drivers/pci/pcie_cdns_ti.c  | 851 
 4 files changed, 863 insertions(+)
 create mode 100644 drivers/pci/pcie_cdns_ti.c

-- 
2.40.1

[PATCH v2 2/2] configs: j7200_evm_a72_defconfig: Enable configs for PCI support

[Siddharth Vadapalli]

TI's J7200 SoC has a single instance of PCIe Controller namely PCIe1 which
is a Cadence PCIe Controller. To support PCIe functionality with the PCIe1
instance of PCIe, enable the corresponding configs.

Signed-off-by: Siddharth Vadapalli 
---
 configs/j7200_evm_a72_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig
index 2fbfda5cf8..12745a9adc 100644
--- a/configs/j7200_evm_a72_defconfig
+++ b/configs/j7200_evm_a72_defconfig
@@ -32,6 +32,7 @@ CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI=y
 # CONFIG_PSCI_RESET is not set
+CONFIG_PCI=y
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
@@ -71,6 +72,7 @@ CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_MTD=y
+CONFIG_CMD_PCI=y
 CONFIG_CMD_REMOTEPROC=y
 CONFIG_CMD_UFS=y
 CONFIG_CMD_USB=y
@@ -153,6 +155,9 @@ CONFIG_MUX_MMIO=y
 CONFIG_PHY_TI_DP83869=y
 CONFIG_PHY_FIXED=y
 CONFIG_TI_AM65_CPSW_NUSS=y
+CONFIG_NVME_PCI=y
+CONFIG_PCI_CONFIG_HOST_BRIDGE=y
+CONFIG_PCIE_CDNS_TI=y
 CONFIG_PHY=y
 CONFIG_SPL_PHY=y
 CONFIG_PHY_CADENCE_TORRENT=y
-- 
2.40.1

[PATCH] usb: gadget: cdns3: Fix cdns3_ep_config() by setting ep.maxpacket

[Siddharth Vadapalli]

The function cdns3_ep_config() calculates the maximum packet size based
on the Endpoint Type and the Gadget Speed and stores it in the variable
"max_packet_size". This value is then programmed in the USB Controller
for the corresponding Endpoint. This may result in a mismatch between
the maximum packet size programmed in the USB controller and the maximum
packet size seen by the UDC Core via "maxpacket" member of "struct usb_ep".
Additionally, since TD_SIZE is calculated in cdns3_ep_run_transfer() on the
basis of the maximum packet size stored in the "maxpacket" member of
"struct usb_ep", it may lead to an incorrect value of TD_SIZE when compared
with what the USB controller actually expects (max_packet_size).

Fix this by using usb_ep_set_maxpacket_limit().

Fixes: 7e91f6ccdc84 ("usb: Add Cadence USB3 host and gadget driver")
Signed-off-by: Siddharth Vadapalli 
---

Hello,

This patch is based on commit
dd4d130c8e clk: renesas: rcar-gen3: Fix SSCG caching replacement with MDSEL/PE 
caching
of the master branch of U-Boot.

Patch has been tested on AM642-EVM.

Regards,
Siddharth.

 drivers/usb/cdns3/gadget.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
index ac7e469469..b0b08768d9 100644
--- a/drivers/usb/cdns3/gadget.c
+++ b/drivers/usb/cdns3/gadget.c
@@ -1637,6 +1637,14 @@ void cdns3_ep_config(struct cdns3_endpoint *priv_ep)
else
priv_ep->trb_burst_size = 16;
 
+   /*
+* The Endpoint is configured to handle a maximum packet size of
+* max_packet_size. Hence, set priv_ep->endpoint.maxpacket to
+* max_packet_size. This is necessary to ensure that the TD_SIZE
+* is calculated correctly in cdns3_ep_run_transfer().
+*/
+   usb_ep_set_maxpacket_limit(&priv_ep->endpoint, max_packet_size);
+
ret = cdns3_ep_onchip_buffer_reserve(priv_dev, buffering + 1,
 !!priv_ep->dir);
if (ret) {
-- 
2.40.1

[PATCH] usb: gadget: cdns3: Fix missing cache operations for non-zero Endpoints

[Siddharth Vadapalli]

Transfer initiation and completion for the non-zero Endpoints are
handled by cdns3_ep_run_transfer() and cdns3_transfer_completed()
respectively.

Failing to flush the cache associated with the TRB Pool within
cdns3_ep_run_transfer() results in the transfers never being initiated.
Similarly, failing to invalidate the cache associated with the TRB pool
within cdns3_transfer_completed() results in the transfers never being
completed.

Fix this.

Fixes: 7e91f6ccdc84 ("usb: Add Cadence USB3 host and gadget driver")
Signed-off-by: Siddharth Vadapalli 
---

Hello,

This patch is based on commit
56b47b8b6a Merge tag 'u-boot-stm32-20240926' of 
https://source.denx.de/u-boot/custodians/u-boot-stm
of the master branch of U-Boot.

This patch has been validated on AM642-EVM in the context of Fastboot.
Fastboot is non-functional without this patch. EP1 is configured in
Bulk Mode for Fastboot and is non-responsive. This patch addresses the
issue, thereby enabling Fastboot.

Regards,
Siddharth.

 drivers/usb/cdns3/gadget.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
index 32b2c41206..ac7e469469 100644
--- a/drivers/usb/cdns3/gadget.c
+++ b/drivers/usb/cdns3/gadget.c
@@ -965,6 +965,12 @@ int cdns3_ep_run_transfer(struct cdns3_endpoint *priv_ep,
if (priv_dev->dev_ver <= DEV_VER_V2)
cdns3_wa1_tray_restore_cycle_bit(priv_dev, priv_ep);
 
+   /* Flush TRBs */
+   flush_dcache_range((unsigned long)priv_ep->trb_pool,
+  (unsigned long)priv_ep->trb_pool +
+  ROUND(sizeof(struct cdns3_trb) * priv_ep->num_trbs,
+CONFIG_SYS_CACHELINE_SIZE));
+
trace_cdns3_prepare_trb(priv_ep, priv_req->trb);
 
/*
@@ -1153,6 +1159,13 @@ static void cdns3_transfer_completed(struct cdns3_device 
*priv_dev,
priv_ep->endpoint.desc->bEndpointAddress);
 #endif
 
+   /* Invalidate TRBs */
+   invalidate_dcache_range((unsigned long)priv_ep->trb_pool,
+   (unsigned long)priv_ep->trb_pool +
+   ROUND(sizeof(struct cdns3_trb) *
+ priv_ep->num_trbs,
+ CONFIG_SYS_CACHELINE_SIZE));
+
if (!cdns3_request_handled(priv_ep, priv_req))
goto prepare_next_td;
 
-- 
2.40.1

Re: [PATCH] usb: gadget: cdns3: Fix cdns3_ep_config() by setting ep.maxpacket

[Siddharth Vadapalli]

On Mon, Oct 07, 2024 at 03:02:34PM +0300, Roger Quadros wrote:

Hello Roger,

> On 07/10/2024 13:42, Siddharth Vadapalli wrote:
> > The function cdns3_ep_config() calculates the maximum packet size based
> > on the Endpoint Type and the Gadget Speed and stores it in the variable
> > "max_packet_size". This value is then programmed in the USB Controller
> > for the corresponding Endpoint. This may result in a mismatch between
> > the maximum packet size programmed in the USB controller and the maximum
> > packet size seen by the UDC Core via "maxpacket" member of "struct usb_ep".
> > Additionally, since TD_SIZE is calculated in cdns3_ep_run_transfer() on the
> > basis of the maximum packet size stored in the "maxpacket" member of
> > "struct usb_ep", it may lead to an incorrect value of TD_SIZE when compared
> > with what the USB controller actually expects (max_packet_size).
> > 

[...]

> > diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
> > index ac7e469469..b0b08768d9 100644
> > --- a/drivers/usb/cdns3/gadget.c
> > +++ b/drivers/usb/cdns3/gadget.c
> > @@ -1637,6 +1637,14 @@ void cdns3_ep_config(struct cdns3_endpoint *priv_ep)
> > else
> > priv_ep->trb_burst_size = 16;
> >  
> > +   /*
> > +* The Endpoint is configured to handle a maximum packet size of
> > +* max_packet_size. Hence, set priv_ep->endpoint.maxpacket to
> > +* max_packet_size. This is necessary to ensure that the TD_SIZE
> > +* is calculated correctly in cdns3_ep_run_transfer().
> > +*/
> > +   usb_ep_set_maxpacket_limit(&priv_ep->endpoint, max_packet_size);
> > +
> 
> from include/linux/usb/gadget.h
> 
>  * struct usb_ep - device side representation of USB endpoint
> ...
>  * @maxpacket:The maximum packet size used on this endpoint.  The initial
>  *  value can sometimes be reduced (hardware allowing), according to
>  *  the endpoint descriptor used to configure the endpoint.
>  * @maxpacket_limit:The maximum packet size value which can be handled by this
>  *  endpoint. It's set once by UDC driver when endpoint is initialized, 
> and
>  *  should not be changed. Should not be confused with maxpacket.
> 
> What you want to change is ep->maxpacket and not ep->maxpacket_limit as that 
> is
> fixed for a particular UDC.
> 
> how about?
>   priv-ep->endpoint.maxpacket = max_packet_size;

Yes, this is accurate. I will post the v2 patch with this change. Thank
you for reviewing the patch.

Regards,
Siddharth.

Re: [PATCH v2 1/2] pci: Add TI K3 Cadence PCIe Controller

[Siddharth Vadapalli]

On Fri, Oct 11, 2024 at 07:15:03PM -0600, Tom Rini wrote:

Hello Tom,

> On Fri, Oct 11, 2024 at 06:32:57PM +0530, Siddharth Vadapalli wrote:
> > Add support for the Cadence PCIe Controller present on TI's K3 SoCs.
> > This driver is an adaptation of the Linux driver.
> > 
> > Signed-off-by: Siddharth Vadapalli 
> > ---
> >  drivers/pci/Kconfig|   6 +
> >  drivers/pci/Makefile   |   1 +
> >  drivers/pci/pcie_cdns_ti.c | 851 +
> >  3 files changed, 858 insertions(+)
> >  create mode 100644 drivers/pci/pcie_cdns_ti.c
> 
> Please update MAINTAINERS somewhere for this.
> 
> > +#define CDNS_PCIE_LM_BAR_CFG_CTRL_DISABLED 0x0
> > +#define  CDNS_PCIE_LM_BAR_CFG_CTRL_MEM_32BITS  0x4
> > +#define  CDNS_PCIE_LM_BAR_CFG_CTRL_PREFETCH_MEM_32BITS 0x5
> > +#define  CDNS_PCIE_LM_BAR_CFG_CTRL_MEM_64BITS  0x6
> > +#define  CDNS_PCIE_LM_BAR_CFG_CTRL_PREFETCH_MEM_64BITS 0x7
> 
> Here and maybe elsewhere, why the inconsistent indentation?

Thank you for reviewing the patch. I will add the MAINTAINERS entry and
make the indentation consistent in the v3 series.

Regards,
Siddharth.

Re: [PATCH v2 2/5] board: ti: j721e: evm: Set "dfu_alt_info" only if interface is Serial Flash

[Siddharth Vadapalli]

On Mon, Nov 25, 2024 at 09:27:08AM +0530, Kumar, Udit wrote:
> Hi Siddharth

Hello Udit,

> 
> On 11/24/2024 12:37 PM, Siddharth Vadapalli wrote:
> > Commit 9bd6cc292fa8 ("board: j721e: Define capsule update firmware info")
> > updated the "dfu_alt_info" variable to support use-cases with Serial Flash.
> > However, this breaks use-cases where interface is not Serial Flash ("sf").
> > Fix this by setting "dfu_alt_info" only when the interface is "sf".
> 
> 
> I am not sure, if we are on same page.
> 
> Setting this dfu_alt_info on shell works for me
> 
> https://gist.github.com/uditkumarti/e5185838bcc32b47f5d9dae48eff72c9

The fix is for DFU Boot i.e. loading tiboot3.bin, tispl.bin and
u-boot.img via USB DFU Boot. Please refer to the cover letter for
details on the issue observed when attempting to boot AM625-SK via USB
DFU Boot.

Regards,
Siddharth.

Re: [PATCH v2 1/5] board: ti: am64x: evm: Set "dfu_alt_info" only if interface is Serial Flash

[Siddharth Vadapalli]

On Mon, Nov 25, 2024 at 09:27:50AM +0530, Kumar, Udit wrote:
> On 11/24/2024 12:37 PM, Siddharth Vadapalli wrote:
> > Commit 5b84d2de5e6c ("board: am64x: Define capsule update firmware info")
> > updated the "dfu_alt_info" variable to support use-cases with Serial Flash.
> > However, this breaks use-cases where interface is not Serial Flash ("sf").
> > Fix this by setting "dfu_alt_info" only when the interface is "sf".
> > 
> > Fixes: 5b84d2de5e6c ("board: am64x: Define capsule update firmware info")
> > Signed-off-by: Siddharth Vadapalli 
> > ---
> > 
> > v1:
> > https://patchwork.ozlabs.org/project/uboot/patch/20241124051545.382397-2-s-vadapa...@ti.com/
> > Changes since v1:
> > - Replaced "SPI Flash" with "Serial Flash" everywhere.
> > 
> > Regards,
> > Siddharth.
> > 
> >   board/ti/am64x/evm.c | 8 +++-
> >   1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
> > index 00b8317d6b..18f7770bc1 100644
> > --- a/board/ti/am64x/evm.c
> > +++ b/board/ti/am64x/evm.c
> > @@ -56,7 +56,13 @@ struct efi_capsule_update_info update_info = {
> >   #if IS_ENABLED(CONFIG_SET_DFU_ALT_INFO)
> >   void set_dfu_alt_info(char *interface, char *devstr)
> >   {
> > -   if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT))
> 
> Could you evaluate possibility of moving this function along with others to
> 
> board/ti/common/ area.

Sure, but that doesn't have to be tied to this fix. I will take a look
at it independent of this series.

Regards,
Siddharth.

Re: [PATCH v2 5/5] board: ti: j784s4: evm: Set "dfu_alt_info" only if interface is Serial Flash

[Siddharth Vadapalli]

On Mon, Nov 25, 2024 at 09:29:01AM +0530, Kumar, Udit wrote:
> Hi Siddharth
> 
> On 11/24/2024 12:37 PM, Siddharth Vadapalli wrote:
> > Commit a4d5e5daa847 ("board: sk-am69: Define capsule update firmware info")
> > updated the "dfu_alt_info" variable to support use-cases with Serial Flash.
> > However, this breaks use-cases where interface is not Serial Flash ("sf").
> > Fix this by setting "dfu_alt_info" only when the interface is "sf".
> > 
> > Fixes: a4d5e5daa847 ("board: sk-am69: Define capsule update firmware info")
> > Signed-off-by: Siddharth Vadapalli 
> 
> 
> AFAIR, DFU in general is not enabled on J784S4

Yes, it is not yet enabled.

> 
> Can i request to enable DFU along with this update.

This series is a pre-requisite for enabling/fixing USB DFU boot on
various devices. I will be enabling USB DFU boot on all TI K3 Boards,
but again, that doesn't have to be tied to this series and can be done
independently. This series is a fix, while enabling USB DFU boot on
devices is a new feature. So I don't think that the feature *has* to be
enabled along with this series.

Regards,
Siddharth.

Re: [PATCH 1/2] usb: dwc3-generic: set "mode" based on caller of dwc3_generic_probe()

[Siddharth Vadapalli]

Hello Roger,

On 28-11-2024 18:40, Roger Quadros wrote:
> 
> 
> On 26/11/2024 14:03, Siddharth Vadapalli wrote:
>> There are only two callers of "dwc3_generic_probe()", namely:
>> 1. dwc3_generic_peripheral_probe()
>> 2. dwc3_generic_host_probe()
>> Currently, the "mode" is set based on the device-tree node of the
>> platform device. Also, the DWC3 core doesn't support updating the "mode"
>> dynamically at runtime if it is set to "OTG", i.e. "OTG" is treated as a
>> separate mode in itself, rather than being treated as a mode which should
>> eventually lead to "host"/"peripheral".
>>
>> Given that the callers of "dwc3_generic_probe()" clarify the expected
>> "mode" of the USB Controller, use that "mode" instead of the one
>> specified in the device-tree. This shall allow the USB Controller to
>> function both as a "Host" and as a "Peripheral" when the "mode" is "otg"
>> in the device-tree, based on the caller of "dwc3_generic_probe()".
>>
>> Signed-off-by: Siddharth Vadapalli 
>> ---
>>  drivers/usb/dwc3/dwc3-generic.c | 9 +
> 
> TI AM62a is not even using this driver so how did you test this?
> Did I miss a DT patch?

USB DFU boot utilizes this driver when the "dr_mode" is set to "otg" in
the device-tree for AM62A. This driver is invoked both for the host and
device commands corresponding to USB. I came up with this patch while
trying to enable USB DFU boot on AM62A with "dr_mode" as "otg" in the
device-tree. Additionally, USB DFU boot works on AM62A with the change
made by this patch and it doesn't work without this change. I have
traced the call sequence to see that the driver is probed and have come
up with the change performed in this patch on the basis of this observation.

> 
>>  1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-generic.c 
>> b/drivers/usb/dwc3/dwc3-generic.c
>> index 2ab41cbae45..55e62b35c61 100644
>> --- a/drivers/usb/dwc3/dwc3-generic.c
>> +++ b/drivers/usb/dwc3/dwc3-generic.c
>> @@ -51,7 +51,8 @@ struct dwc3_generic_host_priv {
>>  };
>>  
>>  static int dwc3_generic_probe(struct udevice *dev,
>> -  struct dwc3_generic_priv *priv)
>> +  struct dwc3_generic_priv *priv,
>> +  enum usb_dr_mode mode)
>>  {
>>  int rc;
>>  struct dwc3_generic_plat *plat = dev_get_plat(dev);
>> @@ -62,7 +63,7 @@ static int dwc3_generic_probe(struct udevice *dev,
>>  
>>  dwc3->dev = dev;
>>  dwc3->maximum_speed = plat->maximum_speed;
>> -dwc3->dr_mode = plat->dr_mode;
>> +dwc3->dr_mode = mode;
> 
> if platform supported mode was "host" only or "peripheral" only
> then you shouldn't we prevent from using the other role?

Yes, but that check doesn't exist prior to this patch either. Platform
could support only "host" mode as specified by "dr_mode", but if the
user runs a command for device mode it will lead to
"dwc3_generic_peripheral_probe" in this driver. On the other hand, if
the check does exist outside this driver, then it doesn't have to be
checked within "dwc3_generic_probe". There are only two callers of
"dwc3_generic_probe", both of which are in this driver, and both of
which unconditionally invoke "dwc3_generic_probe".

However, I agree that having a check here will help. I will update this
patch to add the check to confirm if there is a conflict with what the
platform supports, though this doesn't seem to be the case with the
existing code.
> 
> In u-boot shell, if user starts Host driver first and then starts peripheral 
> driver
> how does it work?
> Did you test this case?

I didn't test the case where both are used. I validated that peripheral
mode works across various stages of boot with "otg" mode via USB DFU
boot. This isn't the case without this patch.

If we forget the reason that this patch is introduced and take a moment
to analyze the existing code prior to this patch, we see that:
1. Both dwc3_generic_peripheral_probe() and dwc3_generic_host_probe()
invoke dwc3_generic_probe().
2. dwc3_generic_probe() sets the role based on the role specified in the
device-tree and not what the caller wants the role to be.
This seems to be strange to me considering that dwc3_generic_probe()
simply proceeds to configure without comparing the role supported by the
platform with the role requested by the caller.

So even if we entire

Re: [PATCH 0/2] AM62A DWC3: Add support for USB DFU boot in OTG mode

[Siddharth Vadapalli]

Hello Roger,

On 28-11-2024 18:15, Roger Quadros wrote:
> 
> 
> On 26/11/2024 14:03, Siddharth Vadapalli wrote:
>> Hello,
>>
>> This series adds support for USB DFU boot on TI's AM62A SoC which has
>> two instances of DWC3 USB Controllers namely USB0 and USB1. The USB0
>> instance of the USB Controller supports USB DFU boot:
>> ROM => tiboot3.bin => tispl.bin => u-boot.img
>>
>> USB DFU Boot requires the USB Controller to be configured for Gadget
>> mode of operation. Since the USB0 instance of the DWC3 USB Controller
>> supports both Host and Gadget modes of operation via the Type-C interface
>> on the AM62A7-SK board, the device-tree specifies the "dr_mode" as "OTG".
>> However, there is currently no support for dynamically switching the "mode"
>> from Host to Gadget and vice-versa with the help of a state-machine.
>> The OTG mode is treated as a separate mode in itself rather than being
>> treated as an intermediate stage before assuming the Host/Gadget mode.
>> Due to this, USB DFU boot via the Type-C interface doesn't work as the
>> USB Controller hasn't been appropriately configured for Device/Gadget
>> mode of operation. One option is to change the device-tree to specify
>> "dr_mode" as "peripheral" and force the controller to assume the Device
>> role. This will imply that the U-Boot device-tree for AM62A diverges
>> from its Linux counterpart. Therefore, with the intent of keeping the
>> device-tree uniform across Linux and U-Boot, and at the same time, in
>> order to enable USB DFU boot in "OTG" mode with the DWC3 Controller,
>> the first patch in this series sets the "mode" on the basis of the
>> caller function, rather than using the "dr_mode" property in the
>> device-tree. There are only two callers of "dwc3_generic_probe()",
>> each of which clearly specify the expected mode of configuration.
>> This will enable both Host and Device mode of operation based on the
>> command executed by the user, thereby truly supporting "OTG"
>> functionality when the USB Controller supports it.
> 
> We don't really support OTG state machine. All you are supporting is
> user initiated role change.

I should have probably used the term "Dual Role" instead of "OTG". I
meant to say that the controller can be used both as Host and Device
based on the command executed by the user, if the controller's dr_mode
is "otg". I am aware that we don't support the OTG state machine in
U-Boot unlike Linux, which is why I have posted this series as a
workaround to utilize both Host and Device modes in the interim.

[...]

-- 
Regards,
Siddharth.

[PATCH v2 0/5] EFI Capsule "dfu_alt_info" fixes for TI Boards

[Siddharth Vadapalli]

Hello,

This series fixes the commits which introduced EFI Capsule support. The
blamed commits unconditionally updated "dfu_alt_info" with the
"dfu_string" corresponding to Serial Flash and therefore its associated
partitions. While this addresses use-cases where the interface is indeed
Serial Flash ("sf"), it breaks use-cases such as USB DFU Boot where the
interface is RAM ("ram").

As of commit
52c0e5f8a3 Merge branch '2024-11-22-assorted-fixes'
of the master branch of U-Boot, USB DFU Boot on AM625-SK is
non-functional. Logs:
https://gist.github.com/Siddharth-Vadapalli-at-TI/726854b49eb199f4acf79028212fabdc

In order to fix this, update "dfu_alt_info" only if the interface is "sf".

The patch for AM62x in this series has been tested and it fixes USB DFU
Boot on AM625-SK. Logs:
https://gist.github.com/Siddharth-Vadapalli-at-TI/feaed5b0a30aff752306d370531a4e10

Series is based on commit
52c0e5f8a3 Merge branch '2024-11-22-assorted-fixes'
of the master branch of U-Boot.

v1 of this series is at:
https://patchwork.ozlabs.org/project/uboot/list/?series=433959&state=%2A&archive=both
Changes since v1:
- Replaced "SPI Flash" with "Serial Flash" everywhere.

Regards,
Siddharth.

Siddharth Vadapalli (5):
  board: ti: am64x: evm: Set "dfu_alt_info" only if interface is Serial
Flash
  board: ti: j721e: evm: Set "dfu_alt_info" only if interface is Serial
Flash
  board: ti: am62x: evm: Set "dfu_alt_info" only if interface is Serial
Flash
  board: ti: am62px: evm: Set "dfu_alt_info" only if interface is Serial
Flash
  board: ti: j784s4: evm: Set "dfu_alt_info" only if interface is Serial
Flash

 board/ti/am62px/evm.c | 8 +++-
 board/ti/am62x/evm.c  | 8 +++-
 board/ti/am64x/evm.c  | 8 +++-
 board/ti/j721e/evm.c  | 8 +++-
 board/ti/j784s4/evm.c | 8 +++-
 5 files changed, 35 insertions(+), 5 deletions(-)

-- 
2.43.0

[PATCH v2 1/5] board: ti: am64x: evm: Set "dfu_alt_info" only if interface is Serial Flash

[Siddharth Vadapalli]

Commit 5b84d2de5e6c ("board: am64x: Define capsule update firmware info")
updated the "dfu_alt_info" variable to support use-cases with Serial Flash.
However, this breaks use-cases where interface is not Serial Flash ("sf").
Fix this by setting "dfu_alt_info" only when the interface is "sf".

Fixes: 5b84d2de5e6c ("board: am64x: Define capsule update firmware info")
Signed-off-by: Siddharth Vadapalli 
---

v1:
https://patchwork.ozlabs.org/project/uboot/patch/20241124051545.382397-2-s-vadapa...@ti.com/
Changes since v1:
- Replaced "SPI Flash" with "Serial Flash" everywhere.

Regards,
Siddharth.

 board/ti/am64x/evm.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
index 00b8317d6b..18f7770bc1 100644
--- a/board/ti/am64x/evm.c
+++ b/board/ti/am64x/evm.c
@@ -56,7 +56,13 @@ struct efi_capsule_update_info update_info = {
 #if IS_ENABLED(CONFIG_SET_DFU_ALT_INFO)
 void set_dfu_alt_info(char *interface, char *devstr)
 {
-   if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT))
+   /*
+* Since the EFI Capsule support is enabled only for Serial Flash,
+* update the "dfu_alt_info" environment variable only if the
+* interface happens to be "sf" (Serial Flash).
+*/
+   if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) &&
+   (strcmp(interface, "sf") == 0))
env_set("dfu_alt_info", update_info.dfu_string);
 }
 #endif
-- 
2.43.0

[PATCH v2 5/5] board: ti: j784s4: evm: Set "dfu_alt_info" only if interface is Serial Flash

[Siddharth Vadapalli]

Commit a4d5e5daa847 ("board: sk-am69: Define capsule update firmware info")
updated the "dfu_alt_info" variable to support use-cases with Serial Flash.
However, this breaks use-cases where interface is not Serial Flash ("sf").
Fix this by setting "dfu_alt_info" only when the interface is "sf".

Fixes: a4d5e5daa847 ("board: sk-am69: Define capsule update firmware info")
Signed-off-by: Siddharth Vadapalli 
---

v1:
https://patchwork.ozlabs.org/project/uboot/patch/20241124051545.382397-6-s-vadapa...@ti.com/
Changes since v1:
- Replaced "SPI Flash" with "Serial Flash" everywhere.

Regards,
Siddharth.

 board/ti/j784s4/evm.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/board/ti/j784s4/evm.c b/board/ti/j784s4/evm.c
index 548dbd5925..d915aee48f 100644
--- a/board/ti/j784s4/evm.c
+++ b/board/ti/j784s4/evm.c
@@ -42,7 +42,13 @@ struct efi_capsule_update_info update_info = {
 #if IS_ENABLED(CONFIG_SET_DFU_ALT_INFO)
 void set_dfu_alt_info(char *interface, char *devstr)
 {
-   if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT))
+   /*
+* Since the EFI Capsule support is enabled only for Serial Flash,
+* update the "dfu_alt_info" environment variable only if the
+* interface happens to be "sf" (Serial Flash).
+*/
+   if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) &&
+   (strcmp(interface, "sf") == 0))
env_set("dfu_alt_info", update_info.dfu_string);
 }
 #endif
-- 
2.43.0

[PATCH v2 3/5] board: ti: am62x: evm: Set "dfu_alt_info" only if interface is Serial Flash

[Siddharth Vadapalli]

Commit 2af879df86f8 ("board: am62x: Define capsule update firmware info")
updated the "dfu_alt_info" variable to support use-cases with Serial Flash.
However, this breaks use-cases where interface is not Serial Flash ("sf").
Fix this by setting "dfu_alt_info" only when the interface is "sf".

Fixes: 2af879df86f8 ("board: am62x: Define capsule update firmware info")
Signed-off-by: Siddharth Vadapalli 
---

v1:
https://patchwork.ozlabs.org/project/uboot/patch/20241124051545.382397-4-s-vadapa...@ti.com/
Changes since v1:
- Replaced "SPI Flash" with "Serial Flash" everywhere.

Regards,
Siddharth.

 board/ti/am62x/evm.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index 9075df01ca..1839ed206c 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -76,7 +76,13 @@ struct efi_capsule_update_info update_info = {
 #if IS_ENABLED(CONFIG_SET_DFU_ALT_INFO)
 void set_dfu_alt_info(char *interface, char *devstr)
 {
-   if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT))
+   /*
+* Since the EFI Capsule support is enabled only for Serial Flash,
+* update the "dfu_alt_info" environment variable only if the
+* interface happens to be "sf" (Serial Flash).
+*/
+   if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) &&
+   (strcmp(interface, "sf") == 0))
env_set("dfu_alt_info", update_info.dfu_string);
 }
 #endif
-- 
2.43.0

[PATCH v2 2/5] board: ti: j721e: evm: Set "dfu_alt_info" only if interface is Serial Flash

[Siddharth Vadapalli]

Commit 9bd6cc292fa8 ("board: j721e: Define capsule update firmware info")
updated the "dfu_alt_info" variable to support use-cases with Serial Flash.
However, this breaks use-cases where interface is not Serial Flash ("sf").
Fix this by setting "dfu_alt_info" only when the interface is "sf".

Fixes: 9bd6cc292fa8 ("board: j721e: Define capsule update firmware info")
Signed-off-by: Siddharth Vadapalli 
---

v1:
https://patchwork.ozlabs.org/project/uboot/patch/20241124051545.382397-3-s-vadapa...@ti.com/
Changes since v1:
- Replaced "SPI Flash" with "Serial Flash" everywhere.

Regards,
Siddharth.

 board/ti/j721e/evm.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index 6221be9dcf..ae24964ab9 100644
--- a/board/ti/j721e/evm.c
+++ b/board/ti/j721e/evm.c
@@ -67,7 +67,13 @@ struct efi_capsule_update_info update_info = {
 #if IS_ENABLED(CONFIG_SET_DFU_ALT_INFO)
 void set_dfu_alt_info(char *interface, char *devstr)
 {
-   if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT))
+   /*
+* Since the EFI Capsule support is enabled only for Serial Flash,
+* update the "dfu_alt_info" environment variable only if the
+* interface happens to be "sf" (Serial Flash).
+*/
+   if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) &&
+   (strcmp(interface, "sf") == 0))
env_set("dfu_alt_info", update_info.dfu_string);
 }
 #endif
-- 
2.43.0

[PATCH v2 4/5] board: ti: am62px: evm: Set "dfu_alt_info" only if interface is Serial Flash

[Siddharth Vadapalli]

Commit 0af78a1a729d ("board: am62px: Define capsule update firmware info")
updated the "dfu_alt_info" variable to support use-cases with Serial Flash.
However, this breaks use-cases where interface is not Serial Flash ("sf").
Fix this by setting "dfu_alt_info" only when the interface is "sf".

Fixes: 0af78a1a729d ("board: am62px: Define capsule update firmware info")
Signed-off-by: Siddharth Vadapalli 
---

v1:
https://patchwork.ozlabs.org/project/uboot/patch/20241124051545.382397-5-s-vadapa...@ti.com/
Changes since v1:
- Replaced "SPI Flash" with "Serial Flash" everywhere.

Regards,
Siddharth.

 board/ti/am62px/evm.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/board/ti/am62px/evm.c b/board/ti/am62px/evm.c
index 7362fa4520..3c3c58fb8f 100644
--- a/board/ti/am62px/evm.c
+++ b/board/ti/am62px/evm.c
@@ -43,7 +43,13 @@ struct efi_capsule_update_info update_info = {
 #if IS_ENABLED(CONFIG_SET_DFU_ALT_INFO)
 void set_dfu_alt_info(char *interface, char *devstr)
 {
-   if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT))
+   /*
+* Since the EFI Capsule support is enabled only for Serial Flash,
+* update the "dfu_alt_info" environment variable only if the
+* interface happens to be "sf" (Serial Flash).
+*/
+   if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) &&
+   (strcmp(interface, "sf") == 0))
env_set("dfu_alt_info", update_info.dfu_string);
 }
 #endif
-- 
2.43.0

[PATCH 0/5] EFI Capsule "dfu_alt_info" fixes for TI Boards

[Siddharth Vadapalli]

Hello,

This series fixes the commits which introduced EFI Capsule support. The
blamed commits unconditionally updated "dfu_alt_info" with the
"dfu_string" corresponding to SPI Flash and therefore its associated
partitions. While this addresses use-cases where the interface is indeed
SPI Flash ("sf"), it breaks use-cases such as USB DFU Boot where the
interface is RAM ("ram").

As of commit
52c0e5f8a3 Merge branch '2024-11-22-assorted-fixes'
of the master branch of U-Boot, USB DFU Boot on AM625-SK is
non-functional. Logs:
https://gist.github.com/Siddharth-Vadapalli-at-TI/726854b49eb199f4acf79028212fabdc

In order to fix this, update "dfu_alt_info" only if the interface is "sf".

The patch for AM62x in this series has been tested and it fixes USB DFU
Boot on AM625-SK. Logs:
https://gist.github.com/Siddharth-Vadapalli-at-TI/feaed5b0a30aff752306d370531a4e10

Series is based on commit
52c0e5f8a3 Merge branch '2024-11-22-assorted-fixes'
of the master branch of U-Boot.

Regards,
Siddharth.

Siddharth Vadapalli (5):
  board: ti: am64x: evm: Set "dfu_alt_info" only if interface is SPI
Flash
  board: ti: j721e: evm: Set "dfu_alt_info" only if interface is SPI
Flash
  board: ti: am62x: evm: Set "dfu_alt_info" only if interface is SPI
Flash
  board: ti: am62px: evm: Set "dfu_alt_info" only if interface is SPI
Flash
  board: ti: j784s4: evm: Set "dfu_alt_info" only if interface is SPI
Flash

 board/ti/am62px/evm.c | 8 +++-
 board/ti/am62x/evm.c  | 8 +++-
 board/ti/am64x/evm.c  | 8 +++-
 board/ti/j721e/evm.c  | 8 +++-
 board/ti/j784s4/evm.c | 8 +++-
 5 files changed, 35 insertions(+), 5 deletions(-)

-- 
2.43.0

[PATCH 3/5] board: ti: am62x: evm: Set "dfu_alt_info" only if interface is SPI Flash

[Siddharth Vadapalli]

Commit 2af879df86f8 ("board: am62x: Define capsule update firmware info")
updated the "dfu_alt_info" variable to support use-cases with SPI Flash.
However, this breaks use-cases where the interface is not SPI Flash ("sf").
Fix this by setting "dfu_alt_info" only when the interface is "sf".

Fixes: 2af879df86f8 ("board: am62x: Define capsule update firmware info")
Signed-off-by: Siddharth Vadapalli 
---
 board/ti/am62x/evm.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index 9075df01ca..3e5d6406ae 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -76,7 +76,13 @@ struct efi_capsule_update_info update_info = {
 #if IS_ENABLED(CONFIG_SET_DFU_ALT_INFO)
 void set_dfu_alt_info(char *interface, char *devstr)
 {
-   if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT))
+   /*
+* Since the EFI Capsule support is enabled only for SPI Flash,
+* update the "dfu_alt_info" environment variable only if the
+* interface happens to be "sf" (SPI Flash).
+*/
+   if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) &&
+   (strcmp(interface, "sf") == 0))
env_set("dfu_alt_info", update_info.dfu_string);
 }
 #endif
-- 
2.43.0