Re: [PATCH v2 4/8] usb: cdns: starfive: Add cdns USB driver
On 04/07/2024 08:50, Minda Chen wrote:
> Add cdns USB3 wrapper driver.
>
> Signed-off-by: Minda Chen
> ---
> drivers/usb/cdns3/Kconfig | 7 ++
> drivers/usb/cdns3/Makefile | 2 +
> drivers/usb/cdns3/cdns3-starfive.c | 183 +
> 3 files changed, 192 insertions(+)
> create mode 100644 drivers/usb/cdns3/cdns3-starfive.c
>
> diff --git a/drivers/usb/cdns3/Kconfig b/drivers/usb/cdns3/Kconfig
> index 35b61497d9..f8f363982b 100644
> --- a/drivers/usb/cdns3/Kconfig
> +++ b/drivers/usb/cdns3/Kconfig
> @@ -55,4 +55,11 @@ config USB_CDNS3_TI
> help
> Say 'Y' here if you are building for Texas Instruments
> platforms that contain Cadence USB3 controller core. E.g.: J721e.
> +
> +config USB_CDNS3_STARFIVE
> + tristate "Cadence USB3 support on Starfive platforms"
> + default USB_CDNS3
> + help
> + Say 'Y' here if you are building for Starfive platforms
> + that contain Cadence USB3 controller core. E.g.: JH7110.
> endif
> diff --git a/drivers/usb/cdns3/Makefile b/drivers/usb/cdns3/Makefile
> index 18d7190755..03d1eadb2f 100644
> --- a/drivers/usb/cdns3/Makefile
> +++ b/drivers/usb/cdns3/Makefile
> @@ -9,3 +9,5 @@ cdns3-$(CONFIG_$(SPL_)USB_CDNS3_GADGET) += gadget.o
> ep0.o
> cdns3-$(CONFIG_$(SPL_)USB_CDNS3_HOST)+= host.o
>
> obj-$(CONFIG_USB_CDNS3_TI) += cdns3-ti.o
> +
> +obj-$(CONFIG_USB_CDNS3_STARFIVE) += cdns3-starfive.o
> diff --git a/drivers/usb/cdns3/cdns3-starfive.c
> b/drivers/usb/cdns3/cdns3-starfive.c
> new file mode 100644
> index 00..660833fb5b
> --- /dev/null
> +++ b/drivers/usb/cdns3/cdns3-starfive.c
> @@ -0,0 +1,183 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * cdns3-starfive.c - StarFive specific Glue layer for Cadence USB Controller
> + *
> + * Copyright (C) 2024 StarFive Technology Co., Ltd.
> + *
> + * Author: Minda Chen
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "core.h"
> +
> +#define USB_STRAP_HOST BIT(17)
> +#define USB_STRAP_DEVICE BIT(18)
> +#define USB_STRAP_MASK GENMASK(18, 16)
> +
> +#define USB_SUSPENDM_HOSTBIT(19)
> +#define USB_SUSPENDM_MASKBIT(19)
> +
> +#define USB_MISC_CFG_MASKGENMASK(23, 20)
> +#define USB_SUSPENDM_BYPSBIT(20)
> +#define USB_PLL_EN BIT(22)
> +#define USB_REFCLK_MODE BIT(23)
> +
> +struct cdns_starfive {
> + struct udevice *dev;
> + struct regmap *stg_syscon;
> + struct reset_ctl_bulk resets;
> + struct clk_bulk clks;
> + u32 stg_usb_mode;
> + enum usb_dr_mode mode;
> +};
> +
> +static void cdns_mode_init(struct cdns_starfive *data, enum usb_dr_mode mode)
> +{
> + unsigned int strap, suspendm;
> +
> + regmap_update_bits(data->stg_syscon, data->stg_usb_mode,
> +USB_MISC_CFG_MASK,
> +USB_SUSPENDM_BYPS | USB_PLL_EN | USB_REFCLK_MODE);
> +
> + switch (mode) {
> + case USB_DR_MODE_HOST:
> + strap = USB_STRAP_HOST;
> + suspendm = USB_SUSPENDM_HOST;
> + break;
> +
> + case USB_DR_MODE_PERIPHERAL:
> + strap = USB_STRAP_DEVICE;
> + suspendm = 0;
> + break;
> + default:
> + return;
> + }
> +
> + regmap_update_bits(data->stg_syscon, data->stg_usb_mode,
> +USB_STRAP_MASK, strap);
> + regmap_update_bits(data->stg_syscon, data->stg_usb_mode,
> +USB_SUSPENDM_MASK, suspendm);
> +}
> +
> +static void cdns_clk_rst_deinit(struct cdns_starfive *data)
> +{
> + reset_assert_bulk(>resets);
> + clk_disable_bulk(>clks);
> +}
> +
> +static int cdns_clk_rst_init(struct cdns_starfive *data)
> +{
> + int ret;
> +
> + ret = clk_get_bulk(data->dev, >clks);
> + if (ret)
> + return ret;
> +
> + ret = reset_get_bulk(data->dev, >resets);
> + if (ret)
> + goto err_clk;
> +
> + ret = clk_enable_bulk(>clks);
> + if (ret)
> + goto err_en_clk;
> +
> + ret = reset_deassert_bulk(>resets);
> + if (ret)
> + goto err_reset;
> +
> + return 0;
> +
> +err_reset:
> + clk_disable_bulk(>clks);
> +err_en_clk:
> + reset_release_bulk(>resets);
> +err_clk:
> + clk_release_bulk(>clks);
> +
> + return ret;
> +}
> +
> +static int cdns_starfive_get_syscon(struct cdns_starfive *data)
> +{
> + struct ofnode_phandle_args phandle;
> + int ret;
> +
> + ret = dev_read_phandle_with_args(data->dev, "starfive,stg-syscon",
> NULL, 1, 0,
> + );
> +
unnecessary blank line
> + if (ret < 0) {
> + dev_err(data->dev, "Can't get stg cfg phandle: %d\n", ret);
> + return ret;
> + }
> +
> + data->stg_syscon =
Re: [PATCH v2 3/8] phy: starfive: Add Starfive JH7110 PCIe 2.0 PHY driver
On 04/07/2024 08:50, Minda Chen wrote:
> Add Starfive JH7110 PCIe 2.0 PHY driver, which is generic
> PHY driver and can be used as USB 3.0 driver.
>
> Signed-off-by: Minda Chen
> ---
> drivers/phy/starfive/Kconfig | 7 +
> drivers/phy/starfive/Makefile | 1 +
> drivers/phy/starfive/phy-jh7110-pcie.c | 202 +
> 3 files changed, 210 insertions(+)
> create mode 100644 drivers/phy/starfive/phy-jh7110-pcie.c
>
> diff --git a/drivers/phy/starfive/Kconfig b/drivers/phy/starfive/Kconfig
> index 11a819f8b2..5d49684bc7 100644
> --- a/drivers/phy/starfive/Kconfig
> +++ b/drivers/phy/starfive/Kconfig
> @@ -4,6 +4,13 @@
>
> menu "Starfive PHY driver"
>
> +config PHY_STARFIVE_JH7110_PCIE
> +bool "Starfive JH7110 PCIe 2.0 PHY driver"
> +select PHY
> +help
> + Enable this to support the Starfive JH7110 PCIE 2.0/USB 3.0 PHY.
> + Generic PHY driver JH7110 USB 3.0/ PCIe 2.0.
> +
> config PHY_STARFIVE_JH7110_USB2
> bool "Starfive JH7110 USB 2.0 PHY driver"
> select PHY
> diff --git a/drivers/phy/starfive/Makefile b/drivers/phy/starfive/Makefile
> index a405a75e34..82f25aa21b 100644
> --- a/drivers/phy/starfive/Makefile
> +++ b/drivers/phy/starfive/Makefile
> @@ -3,4 +3,5 @@
> # Copyright (C) 2023 Starfive
> #
>
> +obj-$(CONFIG_PHY_STARFIVE_JH7110_PCIE) += phy-jh7110-pcie.o
> obj-$(CONFIG_PHY_STARFIVE_JH7110_USB2) += phy-jh7110-usb2.o
> diff --git a/drivers/phy/starfive/phy-jh7110-pcie.c
> b/drivers/phy/starfive/phy-jh7110-pcie.c
> new file mode 100644
> index 00..57d5d8bf53
> --- /dev/null
> +++ b/drivers/phy/starfive/phy-jh7110-pcie.c
> @@ -0,0 +1,202 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * StarFive JH7110 PCIe 2.0 PHY driver
> + *
> + * Copyright (C) 2024 StarFive Technology Co., Ltd.
> + * Author: Minda Chen
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define PCIE_KVCO_LEVEL_OFF 0x28
> +#define PCIE_USB3_PHY_PLL_CTL_OFF0x7c
> +#define PCIE_USB3_PHY_SS_MODEBIT(4)
> +#define PCIE_KVCO_TUNE_SIGNAL_OFF0x80
> +#define PHY_KVCO_FINE_TUNE_LEVEL 0x91
> +#define PHY_KVCO_FINE_TUNE_SIGNALS 0xc
> +
> +#define USB_PDRSTN_SPLIT BIT(17)
> +
> +#define PCIE_USB3_PHY_MODE BIT(20)
> +#define PCIE_PHY_MODE_MASK GENMASK(21, 20)
> +#define PCIE_USB3_BUS_WIDTH_MASK GENMASK(3, 2)
> +#define PCIE_BUS_WIDTH BIT(3)
> +#define PCIE_USB3_RATE_MASK GENMASK(6, 5)
> +#define PCIE_USB3_RX_STANDBY_MASKBIT(7)
> +#define PCIE_USB3_PHY_ENABLE BIT(4)
> +
> +struct jh7110_pcie_phy {
> + struct phy *phy;
> + struct regmap *stg_syscon;
> + struct regmap *sys_syscon;
> + void __iomem *regs;
> + u32 sys_phy_connect;
> + u32 stg_pcie_mode;
> + u32 stg_pcie_usb;
> + enum phy_mode mode;
> +};
> +
> +static int phy_pcie_mode_set(struct jh7110_pcie_phy *data, bool usb_mode)
> +{
> + unsigned int phy_mode, width, usb3_phy, ss_mode;
> +
> + /* default is PCIe mode */
> + if (!data->stg_syscon || !data->sys_syscon) {
> + if (usb_mode) {
> + dev_err(data->phy->dev, "doesn't support usb3 mode\n");
> + return -EINVAL;
> + }
> + return 0;
> + }
> +
> + if (usb_mode) {
> + phy_mode = PCIE_USB3_PHY_MODE;
> + width = 0;
> + usb3_phy = PCIE_USB3_PHY_ENABLE;
> + ss_mode = PCIE_USB3_PHY_SS_MODE;
> + } else {
> + phy_mode = 0;
> + width = PCIE_BUS_WIDTH;
> + usb3_phy = 0;
> + ss_mode = 0;
> + }
> +
> + regmap_update_bits(data->stg_syscon, data->stg_pcie_mode,
> +PCIE_PHY_MODE_MASK, phy_mode);
> + regmap_update_bits(data->stg_syscon, data->stg_pcie_usb,
> +PCIE_USB3_BUS_WIDTH_MASK, width);
> + regmap_update_bits(data->stg_syscon, data->stg_pcie_usb,
> +PCIE_USB3_PHY_ENABLE, usb3_phy);
> + clrsetbits_le32(data->regs + PCIE_USB3_PHY_PLL_CTL_OFF,
> + PCIE_USB3_PHY_SS_MODE, ss_mode);
> +
> + regmap_update_bits(data->sys_syscon, data->sys_phy_connect,
> +USB_PDRSTN_SPLIT, 0);
> +
> + return 0;
> +}
> +
> +static void phy_kvco_gain_set(struct jh7110_pcie_phy *phy)
> +{
> + /* PCIe Multi-PHY PLL KVCO Gain fine tune settings: */
> + writel(PHY_KVCO_FINE_TUNE_LEVEL, phy->regs + PCIE_KVCO_LEVEL_OFF);
> + writel(PHY_KVCO_FINE_TUNE_SIGNALS, phy->regs +
> PCIE_KVCO_TUNE_SIGNAL_OFF);
> +}
> +
> +static int jh7110_pcie_phy_set_mode(struct phy *_phy,
> + enum phy_mode mode, int submode)
> +{
> + struct udevice *dev = _phy->dev;
> + struct jh7110_pcie_phy *phy = dev_get_priv(dev);
> + int ret;
> +
> + if
Re: [PATCH v2 3/8] phy: starfive: Add Starfive JH7110 PCIe 2.0 PHY driver
On 04/07/2024 08:50, Minda Chen wrote:
> Add Starfive JH7110 PCIe 2.0 PHY driver, which is generic
> PHY driver and can be used as USB 3.0 driver.
>
> Signed-off-by: Minda Chen
> ---
> drivers/phy/starfive/Kconfig | 7 +
> drivers/phy/starfive/Makefile | 1 +
> drivers/phy/starfive/phy-jh7110-pcie.c | 202 +
> 3 files changed, 210 insertions(+)
> create mode 100644 drivers/phy/starfive/phy-jh7110-pcie.c
>
> diff --git a/drivers/phy/starfive/Kconfig b/drivers/phy/starfive/Kconfig
> index 11a819f8b2..5d49684bc7 100644
> --- a/drivers/phy/starfive/Kconfig
> +++ b/drivers/phy/starfive/Kconfig
> @@ -4,6 +4,13 @@
>
> menu "Starfive PHY driver"
>
> +config PHY_STARFIVE_JH7110_PCIE
> +bool "Starfive JH7110 PCIe 2.0 PHY driver"
> +select PHY
> +help
> + Enable this to support the Starfive JH7110 PCIE 2.0/USB 3.0 PHY.
> + Generic PHY driver JH7110 USB 3.0/ PCIe 2.0.
Should be aligned to previous line.
> +
> config PHY_STARFIVE_JH7110_USB2
> bool "Starfive JH7110 USB 2.0 PHY driver"
> select PHY
> diff --git a/drivers/phy/starfive/Makefile b/drivers/phy/starfive/Makefile
> index a405a75e34..82f25aa21b 100644
> --- a/drivers/phy/starfive/Makefile
> +++ b/drivers/phy/starfive/Makefile
> @@ -3,4 +3,5 @@
> # Copyright (C) 2023 Starfive
> #
>
> +obj-$(CONFIG_PHY_STARFIVE_JH7110_PCIE) += phy-jh7110-pcie.o
> obj-$(CONFIG_PHY_STARFIVE_JH7110_USB2) += phy-jh7110-usb2.o
> diff --git a/drivers/phy/starfive/phy-jh7110-pcie.c
> b/drivers/phy/starfive/phy-jh7110-pcie.c
> new file mode 100644
> index 00..57d5d8bf53
> --- /dev/null
> +++ b/drivers/phy/starfive/phy-jh7110-pcie.c
> @@ -0,0 +1,202 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * StarFive JH7110 PCIe 2.0 PHY driver
> + *
> + * Copyright (C) 2024 StarFive Technology Co., Ltd.
> + * Author: Minda Chen
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define PCIE_KVCO_LEVEL_OFF 0x28
> +#define PCIE_USB3_PHY_PLL_CTL_OFF0x7c
> +#define PCIE_USB3_PHY_SS_MODEBIT(4)
extra tab?
> +#define PCIE_KVCO_TUNE_SIGNAL_OFF0x80
> +#define PHY_KVCO_FINE_TUNE_LEVEL 0x91
> +#define PHY_KVCO_FINE_TUNE_SIGNALS 0xc
> +
> +#define USB_PDRSTN_SPLIT BIT(17)
> +
> +#define PCIE_USB3_PHY_MODE BIT(20)
> +#define PCIE_PHY_MODE_MASK GENMASK(21, 20)
> +#define PCIE_USB3_BUS_WIDTH_MASK GENMASK(3, 2)
> +#define PCIE_BUS_WIDTH BIT(3)
> +#define PCIE_USB3_RATE_MASK GENMASK(6, 5)
> +#define PCIE_USB3_RX_STANDBY_MASKBIT(7)
> +#define PCIE_USB3_PHY_ENABLE BIT(4)
Why not use define and use regmap_fields? You are already using regmap.
> +
> +struct jh7110_pcie_phy {
> + struct phy *phy;
> + struct regmap *stg_syscon;
> + struct regmap *sys_syscon;
> + void __iomem *regs;
> + u32 sys_phy_connect;
> + u32 stg_pcie_mode;
> + u32 stg_pcie_usb;
> + enum phy_mode mode;
> +};
> +
> +static int phy_pcie_mode_set(struct jh7110_pcie_phy *data, bool usb_mode)
> +{
> + unsigned int phy_mode, width, usb3_phy, ss_mode;
> +
> + /* default is PCIe mode */
> + if (!data->stg_syscon || !data->sys_syscon) {
> + if (usb_mode) {
> + dev_err(data->phy->dev, "doesn't support usb3 mode\n");
> + return -EINVAL;
> + }
> + return 0;
> + }
> +
> + if (usb_mode) {
> + phy_mode = PCIE_USB3_PHY_MODE;
> + width = 0;
> + usb3_phy = PCIE_USB3_PHY_ENABLE;
> + ss_mode = PCIE_USB3_PHY_SS_MODE;
> + } else {
> + phy_mode = 0;
> + width = PCIE_BUS_WIDTH;
> + usb3_phy = 0;
> + ss_mode = 0;
> + }
> +
> + regmap_update_bits(data->stg_syscon, data->stg_pcie_mode,
> +PCIE_PHY_MODE_MASK, phy_mode);
> + regmap_update_bits(data->stg_syscon, data->stg_pcie_usb,
> +PCIE_USB3_BUS_WIDTH_MASK, width);
> + regmap_update_bits(data->stg_syscon, data->stg_pcie_usb,
> +PCIE_USB3_PHY_ENABLE, usb3_phy);
> + clrsetbits_le32(data->regs + PCIE_USB3_PHY_PLL_CTL_OFF,
> + PCIE_USB3_PHY_SS_MODE, ss_mode);
> +
> + regmap_update_bits(data->sys_syscon, data->sys_phy_connect,
> +USB_PDRSTN_SPLIT, 0);
> +
> + return 0;
> +}
> +
> +static void phy_kvco_gain_set(struct jh7110_pcie_phy *phy)
> +{
> + /* PCIe Multi-PHY PLL KVCO Gain fine tune settings: */
> + writel(PHY_KVCO_FINE_TUNE_LEVEL, phy->regs + PCIE_KVCO_LEVEL_OFF);
> + writel(PHY_KVCO_FINE_TUNE_SIGNALS, phy->regs +
> PCIE_KVCO_TUNE_SIGNAL_OFF);
> +}
> +
> +static int jh7110_pcie_phy_set_mode(struct phy *_phy,
> + enum phy_mode mode, int submode)
> +{
> +
Re: [PATCH v2 2/8] phy: starfive: Add Starfive JH7110 USB 2.0 PHY driver
> + ret = clk_set_rate(phy->usb_125m_clk, USB_PHY_CLK_RATE);
> + if (ret < 0) {
> + dev_err(dev, "Failed to set 125m clock\n");
> + return ret;
> + }
> +
> + return clk_prepare_enable(phy->app_125m);
> +}
> +
> +static int jh7110_usb2_phy_exit(struct phy *_phy)
> +{
> + struct udevice *dev = _phy->dev;
> + struct jh7110_usb2_phy *phy = dev_get_priv(dev);
> +
> + clk_disable_unprepare(phy->app_125m);
> +
> + return 0;
> +}
> +
> +struct phy_ops jh7110_usb2_phy_ops = {
> + .init = jh7110_usb2_phy_init,
> + .exit = jh7110_usb2_phy_exit,
> + .set_mode = usb2_phy_set_mode,
> +};
> +
> +int jh7110_usb2_phy_probe(struct udevice *dev)
> +{
> + struct jh7110_usb2_phy *phy = dev_get_priv(dev);
> +
> + phy->regs = dev_read_addr_ptr(dev);
> + if (!phy->regs)
> + return -EINVAL;
> +
> + phy->usb_125m_clk = devm_clk_get(dev, "125m");
> + if (IS_ERR(phy->usb_125m_clk)) {
> + dev_err(dev, "Failed to get 125m clock\n");
> + return PTR_ERR(phy->usb_125m_clk);
> + }
> +
> + phy->app_125m = devm_clk_get(dev, "app_125m");
> + if (IS_ERR(phy->app_125m)) {
> + dev_err(dev, "Failed to get app 125m clock\n");
> + return PTR_ERR(phy->app_125m);
> + }
> +
> + return 0;
> +}
> +
> +static const struct udevice_id jh7110_usb2_phy[] = {
> + { .compatible = "starfive,jh7110-usb-phy"},
> + {},
> +};
> +
> +U_BOOT_DRIVER(jh7110_usb2_phy) = {
> + .name = "jh7110_usb2_phy",
> + .id = UCLASS_PHY,
> + .of_match = jh7110_usb2_phy,
> + .probe = jh7110_usb2_phy_probe,
> + .ops = _usb2_phy_ops,
> + .priv_auto = sizeof(struct jh7110_usb2_phy),
how about space instead of tab?
> +};
Reviewed-by: Roger Quadros
--
cheers,
-roger
Re: [PATCH v2 1/8] usb: cdns3: Set USB PHY mode in cdns3_core_init_role()
Hi,
On 04/07/2024 08:50, Minda Chen wrote:
> USB PHY maybe need to set PHY mode in different USB
> dr mode. So translate to generic PHY mode and call
> generic_phy_set_mode().
>
> Signed-off-by: Minda Chen
> ---
> drivers/usb/cdns3/core.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
> index 12a741c6ea..1e863bed89 100644
> --- a/drivers/usb/cdns3/core.c
> +++ b/drivers/usb/cdns3/core.c
> @@ -107,6 +107,7 @@ static int cdns3_core_init_role(struct cdns3 *cdns)
> {
> struct udevice *dev = cdns->dev;
> enum usb_dr_mode best_dr_mode;
> + int mode = PHY_MODE_INVALID;
> enum usb_dr_mode dr_mode;
> int ret = 0;
>
> @@ -173,6 +174,30 @@ static int cdns3_core_init_role(struct cdns3 *cdns)
>
> cdns->dr_mode = dr_mode;
>
> + if (cdns->dr_mode == USB_DR_MODE_HOST) {
> + mode = PHY_MODE_USB_HOST;
> + } else if (cdns->dr_mode == USB_DR_MODE_PERIPHERAL) {
> + mode = PHY_MODE_USB_DEVICE;
> + } else if (cdns->dr_mode == USB_DR_MODE_OTG) {
> + mode = PHY_MODE_USB_OTG;
> + } else {
> + dev_err(dev, "Unknown dr mode %d\n", cdns->dr_mode);
> + ret = -EINVAL;
> + goto err;
> + }
> +
> + ret = generic_phy_set_mode(>usb2_phy, mode, 0);
> + if (ret) {
> + dev_err(dev, "Set usb 2.0 PHY mode failed %d\n", ret);
> + goto err;
> + }
> +
> + ret = generic_phy_set_mode(>usb3_phy, mode, 0);
> + if (ret) {
> + dev_err(dev, "Set usb 3.0 PHY mode failed %d\n", ret);
> + goto err;
> + }
> +
Should we be doing the above inside cdns3_drd_update_mode() so that the
PHY can be put in the correct state even during role switches?
> ret = cdns3_drd_update_mode(cdns);
> if (ret)
> goto err;
--
cheers,
-roger
Re: [PATCH] usb: cdns3: continue probe even when USB PHY device does not exist
On 02/07/2024 16:36, Siddharth Vadapalli wrote:
> 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
Earlier it was clearly wrong to warn for everything.
> 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, );
>> if (!list)
>> return -ENOENT;
>
> The PHY phandle is present, but it isn't the one being used by U-Boot.
OK. commit cd295286c786 was only addressing the case if USB PHY node is
not present (-ENOENT case). So there is no regression there right?
> 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.
If the device tree contains the PHY then it should be initialized and
any error initializing it is an error condition we cannot ignore.
>
>>
>> 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
uclass_find_device_by_ofnode()
...
ret = uclass_get(id, );
if (ret)
return ret;
uclass_foreach_dev(dev, uc) {
log(LOGC_DM, LOGL_DEBUG_CONTENT, " - checking %s\n",
dev->name);
if (ofnode_equal(dev_ofnode(dev), node)) {
*devp = dev;
goto done;
}
}
ret = -ENODEV;
This means the class driver was not registered yet?
Do you know why that might be the case?
Was the SERDES PHY driver enabled? Are there any error there?
>
> 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.
Ideally we would want u-boot to behave like Linux. If USB3 can be supported
it should be made to work on u-boot as well.
Any reason why USB3 cannot work on u-boot?
> 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.
Let's not assume error codes can be acceptable.
There is patch on Linux to not re-initialize SERDES if it was already configured
by previous stage. Maybe we could use something similar on u-boot?
--
cheers,
-roger
Re: [PATCH] usb: cdns3: continue probe even when USB PHY device does not exist
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.
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, );
if (!list)
return -ENOENT;
Can you please check and point where the -ENODEV error is coming from?
> 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;
> }
--
cheers,
-roger
[PATCH] configs: am64x_evm_a53_defconfig: Enable I2C GPIO drivers
The board has the TCA9554 I2C GPIO expander chip for expansion board presence detection logic. Enable the relevant I2C GPIO drivers. Signed-off-by: Roger Quadros --- configs/am64x_evm_a53_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig index e000549d6d0..8411a29a2ae 100644 --- a/configs/am64x_evm_a53_defconfig +++ b/configs/am64x_evm_a53_defconfig @@ -103,7 +103,11 @@ CONFIG_SYS_DFU_MAX_FILE_SIZE=0x80 CONFIG_DMA_CHANNELS=y CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_TI_SCI_PROTOCOL=y +CONFIG_DM_PCA953X=y +CONFIG_SPL_DM_PCA953X=y CONFIG_DM_I2C=y +CONFIG_I2C_SET_DEFAULT_BUS_NUM=y +CONFIG_DM_I2C_GPIO=y CONFIG_SYS_I2C_OMAP24XX=y CONFIG_DM_MAILBOX=y CONFIG_K3_SEC_PROXY=y --- base-commit: fe2ce09a0753634543c32cafe85eb87a625f76ca change-id: 20240623-for-2023-10-am64-nand-cdec8003ca80 Best regards, -- Roger Quadros
Re: [PATCH v2 0/3] arm: dts: am62-beagleplay: Fix Beagleplay Ethernet
On 31/05/2024 19:47, Tom Rini wrote: > On Fri, May 31, 2024 at 07:32:37PM +0300, Roger Quadros wrote: >> Hi Tom, >> >> On 20/05/2024 18:56, Tom Rini wrote: >>> On Mon, 13 May 2024 15:13:53 +0300, Roger Quadros wrote: >>> >>>> Sync AM62 device tree files with Linux v6.9 and >>>> add in the missing bits in -u-boot.dtsi to get CPSW >>>> Ethernet working. >>>> >>>> CI testing >>>> https://github.com/u-boot/u-boot/pull/534 >>>> >>>> [...] >>> >>> Applied to u-boot/next, thanks! >>> >> >> I see that this series was applied to u-boot master as well >> and then later reverted by commit d678a59d2d719da9e807495b4b021501f2836ca5 >> as it was based on u-boot/next >> >> Can I re-send this series based on u-boot/master so it can be still applied >> to master? >> Without this Ethernet is broken on beagleplay. > > Was ethernet working on v2024.04? > Ah, probably not. -- cheers, -roger
Re: [PATCH v2 0/3] arm: dts: am62-beagleplay: Fix Beagleplay Ethernet
Tom, On 31/05/2024 19:32, Roger Quadros wrote: > Hi Tom, > > On 20/05/2024 18:56, Tom Rini wrote: >> On Mon, 13 May 2024 15:13:53 +0300, Roger Quadros wrote: >> >>> Sync AM62 device tree files with Linux v6.9 and >>> add in the missing bits in -u-boot.dtsi to get CPSW >>> Ethernet working. >>> >>> CI testing >>> https://github.com/u-boot/u-boot/pull/534 >>> >>> [...] >> >> Applied to u-boot/next, thanks! >> > > I see that this series was applied to u-boot master as well > and then later reverted by commit d678a59d2d719da9e807495b4b021501f2836ca5 > as it was based on u-boot/next > > Can I re-send this series based on u-boot/master so it can be still applied > to master? > Without this Ethernet is broken on beagleplay. > This series apply cleanly on u-boot/master so no need to resend. I've created a pull request for CI loop testing on u-boot/master. https://github.com/u-boot/u-boot/pull/572 -- cheers, -roger
Re: [PATCH v2 0/3] arm: dts: am62-beagleplay: Fix Beagleplay Ethernet
Hi Tom, On 20/05/2024 18:56, Tom Rini wrote: > On Mon, 13 May 2024 15:13:53 +0300, Roger Quadros wrote: > >> Sync AM62 device tree files with Linux v6.9 and >> add in the missing bits in -u-boot.dtsi to get CPSW >> Ethernet working. >> >> CI testing >> https://github.com/u-boot/u-boot/pull/534 >> >> [...] > > Applied to u-boot/next, thanks! > I see that this series was applied to u-boot master as well and then later reverted by commit d678a59d2d719da9e807495b4b021501f2836ca5 as it was based on u-boot/next Can I re-send this series based on u-boot/master so it can be still applied to master? Without this Ethernet is broken on beagleplay. -- cheers, -roger
Re: [PATCH v2 06/10] arm: mach-k3: am625_init: Probe AM65 CPSW NUSS
On 21/05/2024 08:34, Chintan Vankar wrote:
>
>
> On 20/05/24 17:42, Roger Quadros wrote:
>>
>>
>> On 25/04/2024 15:59, Chintan Vankar wrote:
>>>
>>>
>>> On 25/04/24 17:57, Roger Quadros wrote:
>>>>
>>>>
>>>> On 25/04/2024 15:08, Chintan Vankar wrote:
>>>>> 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
>>>>> Signed-off-by: Chintan Vankar
>>>>> ---
>>>>>
>>>>> Link to v1:
>>>>> https://lore.kernel.org/r/20240112064759.1801600-8-s-vadapa...@ti.com/
>>>>>
>>>>> Changes from v1 to v2:
>>>>> - No changes.
>>>>>
>>>>> 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 668f9a51ef..9bf61b1e83 100644
>>>>> --- a/arch/arm/mach-k3/am625_init.c
>>>>> +++ b/arch/arm/mach-k3/am625_init.c
>>>>> @@ -277,6 +277,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),
>>>>> + ))
>>>>> + printf("Failed to probe am65_cpsw_nuss driver\n");
>>>>> + }
>>>>> +
>>>>
>>>> This looks like a HACK.
>>>> The network driver should be probed only when the networking feature is
>>>> actually required.
>>>>
>>>
>>> Driver is probed only when the condition above
>>> "spl_boot_device() == BOOT_DEVICE_ETHERNET" is true, which says Boot
>>> device is Ethernet, and here we are booting with Ethernet so driver is
>>> getting probed.
>>
>> I think you misunderstood what I was saying as am625_init.c is not using
>> any Ethernet function it should not cause the Ethernet driver to probe.
>>
>> Instead it should be probed by the networking use case.
>>
>> What happens if you don't use this patch? Where is it failing?
>>
>
> You are correct that it should be probed by the networking use case and
> we are using networking functionality of "Booting via Ethernet".
> Regarding its probing, I already had discussion that why do I have to
> probe it explicitly at here:
> https://lore.kernel.org/r/ee1d16fd-b99b-4b07-97bb-a896e1791...@ti.com/
>
> Now if I don't use this patch then Ethernet will not get initialized at
> SPL stage, and in "spl_net_load_image()" function, there will be an
> error saying "No Ethernet Found", and since we selected booting via
> Ethernet it will fail to boot.
OK Now I see the problem.
in am65-cpsw-nuss.c the following is defined:
> U_BOOT_DRIVER(am65_cpsw_nuss) = {
> .name = "am65_cpsw_nuss",
> .id = UCLASS_MISC,
> .of_match = am65_cpsw_nuss_ids,
> .probe = am65_cpsw_probe_nuss,
> .priv_auto = sizeof(struct am65_cpsw_common),
> };
>
> U_BOOT_DRIVER(am65_cpsw_nuss_port) = {
> .name = "am65_cpsw_nuss_port",
> .id = UCLASS_ETH,
> .probe = am65_cpsw_port_probe,
> .ops= _cpsw_ops,
> .priv_auto = sizeof(struct am65_cpsw_priv),
> .plat_auto = sizeof(struct eth_pdata),
> .flags = DM_FLAG_ALLOC_PRIV_DMA | DM_FLAG_OS_PREPARE,
> };
Now I suppose spl_net_load_image() tries to probe all UCLASS_ETH devices
which should call am65_cpsw_port_probe() but it fails to probe
am65_cpsw_probe_nuss().
This limitation was introduced by commit
38922b1f4acc ("net: ti: am65-cpsw: Add support for multi port independent MAC
mode")
which says "Since top level driver is now UCLASS_MISC, board
files would need to instantiate this driver explicitly.
I wonder if there can be a better solution to this?
--
cheers,
-roger
Re: [PATCH v2 10/10] arch: arm: dts: k3-am62-sk-u-boot: Add missing "bootph-all" property to phy_gmii_sel node
On 20/05/2024 09:04, Chintan Vankar wrote:
>
>
> On 25/04/24 18:06, Chintan Vankar wrote:
>>
>>
>> On 25/04/24 18:01, Roger Quadros wrote:
>>>
>>>
>>> On 25/04/2024 15:08, Chintan Vankar wrote:
>>>> Add "bootph-all" property to CPSW MAC's PHY node phy_gmii_sel.
>>>>
>>>> Signed-off-by: Chintan Vankar
>>>> ---
>>>>
>>>> Changes from v1 to v2:
>>>> - This patch is newly added in this series to enable CPSW MAC's PHY
>>>> node "phy_gmii_sel". As per discussion at here:
>>>> https://lore.kernel.org/r/20240112130127.rvvrhz7p4vmlyalh@smother/
>>>> changes made by this patch can be dropped in the future when the
>>>> DT-Sync is performed with am62-main.dtsi containing this change in
>>>> the Linux DT which will match U-Boot's DT.
>>>
>>> I don't think bootph-all exists in am62-main.dtsi. It should come from
>>> board.dts
>>>
>>
>> Yes, I am having the same discussion at here:
>> https://lore.kernel.org/all/c13ac165-7cbd-4e53-914e-8c6bc2825...@ti.com/
>>
>
> Since I have posted patch which adds bootph-all property to
> "k3-am62x-sk-common.dtsi" at here:
> https://lore.kernel.org/r/20240430085048.3143665-1-c-van...@ti.com/
> and it has no open comments and this series
> also does not have any open comments, so can it be merged ?
Since bootph-all is being added to k3-am62x-sk-common.dtsi don't you have to
drop patch 10
from this series?
>
>>>>
>>>> arch/arm/dts/k3-am625-sk-u-boot.dtsi | 4
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>>>> b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>>>> index fa778b0ff4..e9a1afde95 100644
>>>> --- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>>>> +++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>>>> @@ -46,3 +46,7 @@
>>>> _port2 {
>>>> status = "disabled";
>>>> };
>>>> +
>>>> +_gmii_sel {
>>>> + bootph-all;
>>>> +};
>>>
--
cheers,
-roger
Re: [PATCH v2 06/10] arm: mach-k3: am625_init: Probe AM65 CPSW NUSS
On 25/04/2024 15:59, Chintan Vankar wrote:
>
>
> On 25/04/24 17:57, Roger Quadros wrote:
>>
>>
>> On 25/04/2024 15:08, Chintan Vankar wrote:
>>> 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
>>> Signed-off-by: Chintan Vankar
>>> ---
>>>
>>> Link to v1:
>>> https://lore.kernel.org/r/20240112064759.1801600-8-s-vadapa...@ti.com/
>>>
>>> Changes from v1 to v2:
>>> - No changes.
>>>
>>> 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 668f9a51ef..9bf61b1e83 100644
>>> --- a/arch/arm/mach-k3/am625_init.c
>>> +++ b/arch/arm/mach-k3/am625_init.c
>>> @@ -277,6 +277,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),
>>> + ))
>>> + printf("Failed to probe am65_cpsw_nuss driver\n");
>>> + }
>>> +
>>
>> This looks like a HACK.
>> The network driver should be probed only when the networking feature is
>> actually required.
>>
>
> Driver is probed only when the condition above
> "spl_boot_device() == BOOT_DEVICE_ETHERNET" is true, which says Boot
> device is Ethernet, and here we are booting with Ethernet so driver is
> getting probed.
I think you misunderstood what I was saying as am625_init.c is not using
any Ethernet function it should not cause the Ethernet driver to probe.
Instead it should be probed by the networking use case.
What happens if you don't use this patch? Where is it failing?
>
>>> spl_enable_cache();
>>> fixup_a53_cpu_freq_by_speed_grade();
>>
--
cheers,
-roger
[PATCH] memory: ti-gpmc: use printf to dump settings/timings
pr_info() depends on CONFIG_LOGLEVEL > 6. If user has
enabled CONFIG_TI_GPMC_DEBUG then we should print the
GPMC settings/timings regardless of CONFIG_LOGLEVEL.
So use printf() instead of pr_info().
Signed-off-by: Roger Quadros
---
drivers/memory/ti-gpmc.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/memory/ti-gpmc.c b/drivers/memory/ti-gpmc.c
index 8af48e199a7..e979c431e33 100644
--- a/drivers/memory/ti-gpmc.c
+++ b/drivers/memory/ti-gpmc.c
@@ -242,20 +242,20 @@ static int get_gpmc_timing_reg(/* timing specifiers */
if (l)
time_ns_min = gpmc_clk_ticks_to_ns(l - 1, cs, cd) + 1;
time_ns = gpmc_clk_ticks_to_ns(l, cs, cd);
- pr_info("gpmc,%s = <%u>; /* %u ns - %u ns; %i ticks%s*/\n",
- name, time_ns, time_ns_min, time_ns, l,
- invalid ? "; invalid " : " ");
+ printf("gpmc,%s = <%u>; /* %u ns - %u ns; %i ticks%s*/\n",
+ name, time_ns, time_ns_min, time_ns, l,
+ invalid ? "; invalid " : " ");
} else {
/* raw format */
- pr_info("gpmc,%s = <%u>;%s\n", name, l,
- invalid ? " /* invalid */" : "");
+ printf("gpmc,%s = <%u>;%s\n", name, l,
+ invalid ? " /* invalid */" : "");
}
return l;
}
#define GPMC_PRINT_CONFIG(cs, config) \
- pr_info("CS%i %s: 0x%08x\n", cs, #config, \
+ printf("CS%i %s: 0x%08x\n", cs, #config, \
gpmc_cs_read_reg(cs, config))
#define GPMC_GET_RAW(reg, st, end, field) \
get_gpmc_timing_reg(cs, (reg), (st), (end), 0, field, GPMC_CD_FCLK, 0,
1, 0)
@@ -274,7 +274,7 @@ static int get_gpmc_timing_reg(/* timing specifiers */
static void gpmc_show_regs(int cs, const char *desc)
{
- pr_info("gpmc cs%i %s:\n", cs, desc);
+ printf("gpmc cs%i %s:\n", cs, desc);
GPMC_PRINT_CONFIG(cs, GPMC_CS_CONFIG1);
GPMC_PRINT_CONFIG(cs, GPMC_CS_CONFIG2);
GPMC_PRINT_CONFIG(cs, GPMC_CS_CONFIG3);
@@ -291,7 +291,7 @@ static void gpmc_cs_show_timings(int cs, const char *desc)
{
gpmc_show_regs(cs, desc);
- pr_info("gpmc cs%i access configuration:\n", cs);
+ printf("gpmc cs%i access configuration:\n", cs);
GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG1, 4, 4, "time-para-granularity");
GPMC_GET_RAW(GPMC_CS_CONFIG1, 8, 9, "mux-add-data");
GPMC_GET_RAW_SHIFT_MAX(GPMC_CS_CONFIG1, 12, 13, 1,
@@ -318,7 +318,7 @@ static void gpmc_cs_show_timings(int cs, const char *desc)
GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG6, 7, 7, "cycle2cycle-samecsen");
GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG6, 6, 6, "cycle2cycle-diffcsen");
- pr_info("gpmc cs%i timings configuration:\n", cs);
+ printf("gpmc cs%i timings configuration:\n", cs);
GPMC_GET_TICKS(GPMC_CS_CONFIG2, 0, 3, "cs-on-ns");
GPMC_GET_TICKS(GPMC_CS_CONFIG2, 8, 12, "cs-rd-off-ns");
GPMC_GET_TICKS(GPMC_CS_CONFIG2, 16, 20, "cs-wr-off-ns");
@@ -409,9 +409,9 @@ static int set_gpmc_timing_reg(int cs, int reg, int st_bit,
int end_bit, int max
l = gpmc_cs_read_reg(cs, reg);
if (IS_ENABLED(CONFIG_TI_GPMC_DEBUG)) {
- pr_info("GPMC CS%d: %-17s: %3d ticks, %3lu ns (was %3i ticks)
%3d ns\n",
- cs, name, ticks, gpmc_get_clk_period(cs, cd) * ticks /
1000,
- (l >> st_bit) & mask, time);
+ printf("GPMC CS%d: %-17s: %3d ticks, %3lu ns (was %3i ticks)
%3d ns\n",
+ cs, name, ticks, gpmc_get_clk_period(cs, cd) * ticks /
1000,
+ (l >> st_bit) & mask, time);
}
l &= ~(mask << st_bit);
@@ -618,8 +618,8 @@ static int gpmc_cs_set_timings(int cs, const struct
gpmc_timings *t,
return -ENXIO;
if (IS_ENABLED(CONFIG_TI_GPMC_DEBUG)) {
- pr_info("GPMC CS%d CLK period is %lu ns (div %d)\n",
- cs, (div * gpmc_get_fclk_period()) / 1000, div);
+ printf("GPMC CS%d CLK period is %lu ns (div %d)\n",
+ cs, (div * gpmc_get_fclk_period()) / 1000, div);
}
gpmc_cs_bool_timings(cs, >bool_timings);
---
base-commit: e7992828adcd5fad75bce9e6c41dfa9277ab93b0
change-id: 20240515-for-2024-10-gpmc-printf-dcd5f446d951
Best regards,
--
Roger Quadros
[PATCH v2 3/3] arm: dts: k3-am625-beagleplay: Fix Ethernet PHY reset GPIO
Move GPIO pinmux to MDIO node. Add GB Ethernet reset GPIO.
Add PIN_INPUT to Fix SPE ethernet reset gpio so that
reading the GPIO can give correct status.
Signed-off-by: Roger Quadros
---
Commit 0b1133ee36ecbf3b02f69cc4e8a169f1b6019e40 on linux-next
---
arch/arm/dts/k3-am625-beagleplay.dts | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/k3-am625-beagleplay.dts
b/arch/arm/dts/k3-am625-beagleplay.dts
index a34e0df2ab8..8ab838f1697 100644
--- a/arch/arm/dts/k3-am625-beagleplay.dts
+++ b/arch/arm/dts/k3-am625-beagleplay.dts
@@ -292,6 +292,8 @@
pinctrl-single,pins = <
AM62X_IOPAD(0x0160, PIN_OUTPUT, 0) /* (AD24) MDIO0_MDC
*/
AM62X_IOPAD(0x015c, PIN_INPUT, 0) /* (AB22) MDIO0_MDIO
*/
+ AM62X_IOPAD(0x003c, PIN_INPUT, 7) /* (M25)
GPMC0_AD0.GPIO0_15 */
+ AM62X_IOPAD(0x018c, PIN_INPUT, 7) /* (AC21)
RGMII2_RD2.GPIO1_5 */
>;
};
@@ -383,7 +385,6 @@
AM62X_IOPAD(0x016c, PIN_INPUT, 1) /* (Y18)
RGMII2_TD0.RMII2_TXD0 */
AM62X_IOPAD(0x0170, PIN_INPUT, 1) /* (AA18)
RGMII2_TD1.RMII2_TXD1 */
AM62X_IOPAD(0x0164, PIN_INPUT, 1) /* (AA19)
RGMII2_TX_CTL.RMII2_TX_EN */
- AM62X_IOPAD(0x018c, PIN_OUTPUT, 7) /* (AC21)
RGMII2_RD2.GPIO1_5 */
AM62X_IOPAD(0x0190, PIN_INPUT, 7) /* (AE22)
RGMII2_RD3.GPIO1_6 */
AM62X_IOPAD(0x01f0, PIN_OUTPUT, 5) /* (A18)
EXT_REFCLK1.CLKOUT0 */
>;
@@ -597,6 +598,9 @@
cpsw3g_phy0: ethernet-phy@0 {
reg = <0>;
+ reset-gpios = <_gpio0 15 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <1>;
+ reset-deassert-us = <5>;
};
cpsw3g_phy1: ethernet-phy@1 {
@@ -615,7 +619,7 @@
"USR0", "USR1", "USR2", "USR3", "", "", "USR4", /* 3-9 */
"EEPROM_WP",/* 10 */
"CSI2_CAMERA_GPIO1", "CSI2_CAMERA_GPIO2", /* 11-12 */
- "CC1352P7_BOOT", "CC1352P7_RSTN", "", "", "", /* 13-17 */
+ "CC1352P7_BOOT", "CC1352P7_RSTN", "GBE_RSTN", "", "", /*
13-17 */
"USR_BUTTON", "", "", "", "", "", "", "", "", /* 18-26 */
"", "", "", "", "", "", "", "", "", "HDMI_INT", /* 27-36 */
"", "VDD_WLAN_EN", "", "", "WL_IRQ", "GBE_INTN",/* 37-42 */
--
2.34.1
[PATCH v2 2/3] arm: dts: k3-am625-beagleplay: get CPSW Ethernet to work
Add missing bits in -u-boot.dtsi to get CPSW Ethernet working.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 63
1 file changed, 63 insertions(+)
diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
index fb2032068d1..54a7702037d 100644
--- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
@@ -206,3 +206,66 @@
};
};
#endif
+
+_bcdma {
+ reg = <0x00 0x485c0100 0x00 0x100>,
+ <0x00 0x4c00 0x00 0x2>,
+ <0x00 0x4a82 0x00 0x2>,
+ <0x00 0x4aa4 0x00 0x2>,
+ <0x00 0x4bc0 0x00 0x10>,
+ <0x00 0x4860 0x00 0x8000>,
+ <0x00 0x484a4000 0x00 0x2000>,
+ <0x00 0x484c2000 0x00 0x2000>;
+ reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
+ "cfg", "tchan", "rchan";
+};
+
+_pktdma {
+ reg = <0x00 0x485c 0x00 0x100>,
+ <0x00 0x4a80 0x00 0x2>,
+ <0x00 0x4aa0 0x00 0x4>,
+ <0x00 0x4b80 0x00 0x40>,
+ <0x00 0x485e 0x00 0x2>,
+ <0x00 0x484a 0x00 0x4000>,
+ <0x00 0x484c 0x00 0x2000>,
+ <0x00 0x4843 0x00 0x4000>;
+ reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt", "cfg",
+ "tchan", "rchan", "rflow";
+ bootph-all;
+};
+
+_pins_default {
+ bootph-all;
+};
+
+_mdio {
+ bootph-all;
+};
+
+_phy0 {
+ bootph-all;
+};
+
+_pins_default {
+ bootph-all;
+};
+
+ {
+ bootph-all;
+
+ ethernet-ports {
+ bootph-all;
+ };
+};
+
+_gmii_sel {
+ bootph-all;
+};
+
+_port1 {
+ bootph-all;
+};
+
+_port2 {
+ status = "disabled";
+};
--
2.34.1
[PATCH v2 1/3] arm: dts: k3-am62*: sync with Linux v6.9
Update k3-am62 DT files from Linux v6.9
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am62-main.dtsi | 126 ++
arch/arm/dts/k3-am62-mcu.dtsi| 4 +-
arch/arm/dts/k3-am62-thermal.dtsi| 5 +-
arch/arm/dts/k3-am62-wakeup.dtsi | 38 +--
arch/arm/dts/k3-am62.dtsi| 4 +-
arch/arm/dts/k3-am625-beagleplay.dts | 58 --
arch/arm/dts/k3-am625-sk.dts | 4 +-
arch/arm/dts/k3-am625.dtsi | 4 +-
arch/arm/dts/k3-am62a-main.dtsi | 201 ---
arch/arm/dts/k3-am62a-mcu.dtsi | 4 +-
arch/arm/dts/k3-am62a-thermal.dtsi | 5 +-
arch/arm/dts/k3-am62a-wakeup.dtsi| 4 +-
arch/arm/dts/k3-am62a.dtsi | 4 +-
arch/arm/dts/k3-am62a7-sk.dts| 162 +++-
arch/arm/dts/k3-am62a7.dtsi | 4 +-
arch/arm/dts/k3-am62x-sk-common.dtsi | 24 -
16 files changed, 552 insertions(+), 99 deletions(-)
diff --git a/arch/arm/dts/k3-am62-main.dtsi b/arch/arm/dts/k3-am62-main.dtsi
index e5c64c86d1d..e9cffca073e 100644
--- a/arch/arm/dts/k3-am62-main.dtsi
+++ b/arch/arm/dts/k3-am62-main.dtsi
@@ -1,8 +1,8 @@
-// SPDX-License-Identifier: GPL-2.0
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
/*
* Device Tree Source for AM625 SoC Family Main Domain peripherals
*
- * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2020-2024 Texas Instruments Incorporated - https://www.ti.com/
*/
_main {
@@ -42,9 +42,8 @@
};
};
- main_conf: syscon@10 {
- compatible = "syscon", "simple-mfd";
- reg = <0x00 0x0010 0x00 0x2>;
+ main_conf: bus@10 {
+ compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x00 0x0010 0x2>;
@@ -121,8 +120,13 @@
<0x00 0x4c00 0x00 0x2>,
<0x00 0x4a82 0x00 0x2>,
<0x00 0x4aa4 0x00 0x2>,
- <0x00 0x4bc0 0x00 0x10>;
- reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt",
"ringrt";
+ <0x00 0x4bc0 0x00 0x10>,
+ <0x00 0x4860 0x00 0x8000>,
+ <0x00 0x484a4000 0x00 0x2000>,
+ <0x00 0x484c2000 0x00 0x2000>,
+ <0x00 0x4842 0x00 0x2000>;
+ reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt",
"ringrt",
+ "ring", "tchan", "rchan", "bchan";
msi-parent = <_main_dmss>;
#dma-cells = <3>;
@@ -138,8 +142,13 @@
reg = <0x00 0x485c 0x00 0x100>,
<0x00 0x4a80 0x00 0x2>,
<0x00 0x4aa0 0x00 0x4>,
- <0x00 0x4b80 0x00 0x40>;
- reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
+ <0x00 0x4b80 0x00 0x40>,
+ <0x00 0x485e 0x00 0x1>,
+ <0x00 0x484a 0x00 0x2000>,
+ <0x00 0x484c 0x00 0x2000>,
+ <0x00 0x4843 0x00 0x1000>;
+ reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
+ "ring", "tchan", "rchan", "rflow";
msi-parent = <_main_dmss>;
#dma-cells = <2>;
@@ -502,6 +511,9 @@
main_gpio0: gpio@60 {
compatible = "ti,am64-gpio", "ti,keystone-gpio";
reg = <0x0 0x0060 0x0 0x100>;
+ gpio-ranges = <_pmx0 0 0 32>,
+ <_pmx0 32 33 38>,
+ <_pmx0 70 72 22>;
gpio-controller;
#gpio-cells = <2>;
interrupt-parent = <_gpio_intr>;
@@ -520,6 +532,10 @@
compatible = "ti,am64-gpio", "ti,keystone-gpio";
reg = <0x0 0x00601000 0x0 0x100>;
gpio-controller;
+ gpio-ranges = <_pmx0 0 94 41>,
+ <_pmx0 41 136 6>,
+
[PATCH v2 0/3] arm: dts: am62-beagleplay: Fix Beagleplay Ethernet
Sync AM62 device tree files with Linux v6.9 and add in the missing bits in -u-boot.dtsi to get CPSW Ethernet working. CI testing https://github.com/u-boot/u-boot/pull/534 Signed-off-by: Roger Quadros --- --- Changes in v2: - rebase on u-boot/next 13th May 2024 - drop 'not-for-merge' comment for patch 3 as it can now be merged - Link to v1: https://lore.kernel.org/r/20240425-for-2024-07-beagleplay-eth-v1-0-6c985de1c...@kernel.org --- Roger Quadros (3): arm: dts: k3-am62*: sync with Linux v6.9 arm: dts: k3-am625-beagleplay: get CPSW Ethernet to work arm: dts: k3-am625-beagleplay: Fix Ethernet PHY reset GPIO arch/arm/dts/k3-am62-main.dtsi | 126 ++--- arch/arm/dts/k3-am62-mcu.dtsi| 4 +- arch/arm/dts/k3-am62-thermal.dtsi| 5 +- arch/arm/dts/k3-am62-wakeup.dtsi | 38 +++-- arch/arm/dts/k3-am62.dtsi| 4 +- arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 63 + arch/arm/dts/k3-am625-beagleplay.dts | 66 - arch/arm/dts/k3-am625-sk.dts | 4 +- arch/arm/dts/k3-am625.dtsi | 4 +- arch/arm/dts/k3-am62a-main.dtsi | 201 +-- arch/arm/dts/k3-am62a-mcu.dtsi | 4 +- arch/arm/dts/k3-am62a-thermal.dtsi | 5 +- arch/arm/dts/k3-am62a-wakeup.dtsi| 4 +- arch/arm/dts/k3-am62a.dtsi | 4 +- arch/arm/dts/k3-am62a7-sk.dts| 162 - arch/arm/dts/k3-am62a7.dtsi | 4 +- arch/arm/dts/k3-am62x-sk-common.dtsi | 24 +++- 17 files changed, 621 insertions(+), 101 deletions(-) --- base-commit: c67199962b2a819a4b0ae8d57dc68b7cadee0c9e change-id: 20240305-for-2024-07-beagleplay-eth-f82a51197937 Best regards, -- Roger Quadros
Re: [PATCH 0/3] arm: dts: am62-beagleplay: Fix Beagleplay Ethernet
On 10/05/2024 16:08, Tom Rini wrote: > On Fri, May 10, 2024 at 12:55:15PM +0300, Roger Quadros wrote: >> Tom, >> >> On 25/04/2024 15:20, Roger Quadros wrote: >>> Sync AM62 device tree files with Linux v6.9-rc5 and >>> add in the missing bits in -u-boot.dtsi to get CPSW >>> Ethernet working. >>> >>> The last patch is marked [not-for-merge] as it is not yet >>> applied to Linux device tree. >>> >>> CI testing >>> https://github.com/u-boot/u-boot/pull/527 >> >> While the checks have passed, there are some recent conflicts introduced >> >> Conflicting files >> arch/arm/dts/k3-am62-phycore-som.dtsi >> arch/arm/dts/k3-am625-phyboard-lyra-rdk.dts >> >> Those files have been removed. >> >> Do you want me to rebase and resend this series? > > Since part 3 was a do not merge I wasn't sure what the end goal of this > series was. > Goal was to show what is required to get Ethernet working and DT synced with kernel.org. part 3 can now be merged as the commit is now in linux-next. [1] Maybe it is best if I rebase and send this as v2 and drop the do-not-merge for patch 3? [1] arm64: dts: ti: beagleplay: Fix Ethernet PHY RESET GPIOs commit: 0b1133ee36ecbf3b02f69cc4e8a169f1b6019e40 -- cheers, -roger
Re: [PATCH 0/3] arm: dts: am62-beagleplay: Fix Beagleplay Ethernet
Tom, On 25/04/2024 15:20, Roger Quadros wrote: > Sync AM62 device tree files with Linux v6.9-rc5 and > add in the missing bits in -u-boot.dtsi to get CPSW > Ethernet working. > > The last patch is marked [not-for-merge] as it is not yet > applied to Linux device tree. > > CI testing > https://github.com/u-boot/u-boot/pull/527 While the checks have passed, there are some recent conflicts introduced Conflicting files arch/arm/dts/k3-am62-phycore-som.dtsi arch/arm/dts/k3-am625-phyboard-lyra-rdk.dts Those files have been removed. Do you want me to rebase and resend this series? > > Signed-off-by: Roger Quadros > --- > > --- > Roger Quadros (3): > arm: dts: k3-am62*: sync with Linux v6.9-rc5 > arm: dts: k3-am625-beagleplay: get CPSW Ethernet to work > [not-for-merge] arm: dts: k3-am625-beagleplay: Fix Ethernet PHY reset > GPIO > > arch/arm/dts/k3-am62-main.dtsi | 126 ++--- > arch/arm/dts/k3-am62-mcu.dtsi| 4 +- > arch/arm/dts/k3-am62-phycore-som.dtsi| 5 +- > arch/arm/dts/k3-am62-thermal.dtsi| 5 +- > arch/arm/dts/k3-am62-wakeup.dtsi | 38 +++-- > arch/arm/dts/k3-am62.dtsi| 4 +- > arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 63 + > arch/arm/dts/k3-am625-beagleplay.dts | 66 - > arch/arm/dts/k3-am625-phyboard-lyra-rdk.dts | 104 +- > arch/arm/dts/k3-am625-sk.dts | 4 +- > arch/arm/dts/k3-am625.dtsi | 4 +- > arch/arm/dts/k3-am62a-main.dtsi | 201 > +-- > arch/arm/dts/k3-am62a-mcu.dtsi | 4 +- > arch/arm/dts/k3-am62a-thermal.dtsi | 5 +- > arch/arm/dts/k3-am62a-wakeup.dtsi| 4 +- > arch/arm/dts/k3-am62a.dtsi | 4 +- > arch/arm/dts/k3-am62a7-sk.dts| 162 - > arch/arm/dts/k3-am62a7.dtsi | 4 +- > arch/arm/dts/k3-am62x-sk-common.dtsi | 24 +++- > 19 files changed, 722 insertions(+), 109 deletions(-) > --- > base-commit: 38ea74d6d5c05224acdb03f799897c1bdd56f8cc > change-id: 20240305-for-2024-07-beagleplay-eth-f82a51197937 > > Best regards, -- cheers, -roger
Re: [PATCH] net: ti: am65-cpsw-nuss: don't touch DMA after stop
Hi Alexander,
On 08/05/2024 21:36, A. Sverdlin wrote:
> From: Alexander Sverdlin
>
> Contrary to doc/develop/driver-model/ethernet.rst contract, eth_ops
> .free_pkt can be called after .stop, there are several error paths in TFTP,
> for instance:
Doesn't this mean we need to fix TFTP instead of patching the Ethernet
driver? I'm sure the issue is present for all Ethernet drivers as none
of them are checking if Ethernet is stopped. Just that most of them
don't print any error message so it goes unnoticed.
>
> eth_halt() <= tftp_handler() <= net_process_received_packet() <= eth_rx()
> ...
> am65_cpsw_free_pkt() <= eth_rx()>
> Which results in (deliberately "tftpboot"ing non-existing file):
>
> TFTP error: 'File not found' (1)
> Not retrying...
> am65_cpsw_nuss_port ethernet@800port@1: RX dma free_pkt failed -22
>
> Avoid the error message by checking that the interface is still not stopped
> in am65_cpsw_free_pkt().
>
> 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 65ade1afd05..646f618afcf 100644
> --- a/drivers/net/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ti/am65-cpsw-nuss.c
> @@ -523,6 +523,9 @@ static int am65_cpsw_free_pkt(struct udevice *dev, uchar
> *packet, int length)
> struct am65_cpsw_common *common = priv->cpsw_common;
> int ret;
>
> + if (!common->started)
> + return -ENETDOWN;
> +
> if (length > 0) {
> u32 pkt = common->rx_next % UDMA_RX_DESC_NUM;
>
--
cheers,
-roger
Re: [PATCH 2/2] soc: ti: pruss: Add support for AM64x
On 30/04/2024 13:46, MD Danish Anwar wrote: > Add support for AM64x by adding it's compatible in pruss driver. > > Signed-off-by: MD Danish Anwar Reviewed-by: Roger Quadros
Re: [PATCH 1/2] remoteproc: pru: Add support for AM64x PRU / RTU cores
On 30/04/2024 13:46, MD Danish Anwar wrote: > Add support for AM64x PRU cores by adding compatibles for AM64x. > > Signed-off-by: MD Danish Anwar Reviewed-by: Roger Quadros
Re: [PATCH v2 10/10] arch: arm: dts: k3-am62-sk-u-boot: Add missing "bootph-all" property to phy_gmii_sel node
On 25/04/2024 15:08, Chintan Vankar wrote:
> Add "bootph-all" property to CPSW MAC's PHY node phy_gmii_sel.
>
> Signed-off-by: Chintan Vankar
> ---
>
> Changes from v1 to v2:
> - This patch is newly added in this series to enable CPSW MAC's PHY
> node "phy_gmii_sel". As per discussion at here:
> https://lore.kernel.org/r/20240112130127.rvvrhz7p4vmlyalh@smother/
> changes made by this patch can be dropped in the future when the
> DT-Sync is performed with am62-main.dtsi containing this change in
> the Linux DT which will match U-Boot's DT.
I don't think bootph-all exists in am62-main.dtsi. It should come from
board.dts
>
> arch/arm/dts/k3-am625-sk-u-boot.dtsi | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> index fa778b0ff4..e9a1afde95 100644
> --- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> @@ -46,3 +46,7 @@
> _port2 {
> status = "disabled";
> };
> +
> +_gmii_sel {
> + bootph-all;
> +};
--
cheers,
-roger
Re: [PATCH v2 06/10] arm: mach-k3: am625_init: Probe AM65 CPSW NUSS
On 25/04/2024 15:08, Chintan Vankar wrote:
> 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
> Signed-off-by: Chintan Vankar
> ---
>
> Link to v1:
> https://lore.kernel.org/r/20240112064759.1801600-8-s-vadapa...@ti.com/
>
> Changes from v1 to v2:
> - No changes.
>
> 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 668f9a51ef..9bf61b1e83 100644
> --- a/arch/arm/mach-k3/am625_init.c
> +++ b/arch/arm/mach-k3/am625_init.c
> @@ -277,6 +277,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),
> + ))
> + printf("Failed to probe am65_cpsw_nuss driver\n");
> + }
> +
This looks like a HACK.
The network driver should be probed only when the networking feature is
actually required.
> spl_enable_cache();
>
> fixup_a53_cpu_freq_by_speed_grade();
--
cheers,
-roger
[PATCH not-for-merge 3/3] arm: dts: k3-am625-beagleplay: Fix Ethernet PHY reset GPIO
Move GPIO pinmux to MDIO node. Add GB Ethernet reset GPIO.
Add PIN_INPUT to Fix SPE ethernet reset gpio so that
reading the GPIO can give correct status.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am625-beagleplay.dts | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/k3-am625-beagleplay.dts
b/arch/arm/dts/k3-am625-beagleplay.dts
index a34e0df2ab8..8ab838f1697 100644
--- a/arch/arm/dts/k3-am625-beagleplay.dts
+++ b/arch/arm/dts/k3-am625-beagleplay.dts
@@ -292,6 +292,8 @@
pinctrl-single,pins = <
AM62X_IOPAD(0x0160, PIN_OUTPUT, 0) /* (AD24) MDIO0_MDC
*/
AM62X_IOPAD(0x015c, PIN_INPUT, 0) /* (AB22) MDIO0_MDIO
*/
+ AM62X_IOPAD(0x003c, PIN_INPUT, 7) /* (M25)
GPMC0_AD0.GPIO0_15 */
+ AM62X_IOPAD(0x018c, PIN_INPUT, 7) /* (AC21)
RGMII2_RD2.GPIO1_5 */
>;
};
@@ -383,7 +385,6 @@
AM62X_IOPAD(0x016c, PIN_INPUT, 1) /* (Y18)
RGMII2_TD0.RMII2_TXD0 */
AM62X_IOPAD(0x0170, PIN_INPUT, 1) /* (AA18)
RGMII2_TD1.RMII2_TXD1 */
AM62X_IOPAD(0x0164, PIN_INPUT, 1) /* (AA19)
RGMII2_TX_CTL.RMII2_TX_EN */
- AM62X_IOPAD(0x018c, PIN_OUTPUT, 7) /* (AC21)
RGMII2_RD2.GPIO1_5 */
AM62X_IOPAD(0x0190, PIN_INPUT, 7) /* (AE22)
RGMII2_RD3.GPIO1_6 */
AM62X_IOPAD(0x01f0, PIN_OUTPUT, 5) /* (A18)
EXT_REFCLK1.CLKOUT0 */
>;
@@ -597,6 +598,9 @@
cpsw3g_phy0: ethernet-phy@0 {
reg = <0>;
+ reset-gpios = <_gpio0 15 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <1>;
+ reset-deassert-us = <5>;
};
cpsw3g_phy1: ethernet-phy@1 {
@@ -615,7 +619,7 @@
"USR0", "USR1", "USR2", "USR3", "", "", "USR4", /* 3-9 */
"EEPROM_WP",/* 10 */
"CSI2_CAMERA_GPIO1", "CSI2_CAMERA_GPIO2", /* 11-12 */
- "CC1352P7_BOOT", "CC1352P7_RSTN", "", "", "", /* 13-17 */
+ "CC1352P7_BOOT", "CC1352P7_RSTN", "GBE_RSTN", "", "", /*
13-17 */
"USR_BUTTON", "", "", "", "", "", "", "", "", /* 18-26 */
"", "", "", "", "", "", "", "", "", "HDMI_INT", /* 27-36 */
"", "VDD_WLAN_EN", "", "", "WL_IRQ", "GBE_INTN",/* 37-42 */
--
2.34.1
[PATCH 2/3] arm: dts: k3-am625-beagleplay: get CPSW Ethernet to work
Add missing bits in -u-boot.dtsi to get CPSW Ethernet working.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 63
1 file changed, 63 insertions(+)
diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
index fb2032068d1..54a7702037d 100644
--- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
@@ -206,3 +206,66 @@
};
};
#endif
+
+_bcdma {
+ reg = <0x00 0x485c0100 0x00 0x100>,
+ <0x00 0x4c00 0x00 0x2>,
+ <0x00 0x4a82 0x00 0x2>,
+ <0x00 0x4aa4 0x00 0x2>,
+ <0x00 0x4bc0 0x00 0x10>,
+ <0x00 0x4860 0x00 0x8000>,
+ <0x00 0x484a4000 0x00 0x2000>,
+ <0x00 0x484c2000 0x00 0x2000>;
+ reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
+ "cfg", "tchan", "rchan";
+};
+
+_pktdma {
+ reg = <0x00 0x485c 0x00 0x100>,
+ <0x00 0x4a80 0x00 0x2>,
+ <0x00 0x4aa0 0x00 0x4>,
+ <0x00 0x4b80 0x00 0x40>,
+ <0x00 0x485e 0x00 0x2>,
+ <0x00 0x484a 0x00 0x4000>,
+ <0x00 0x484c 0x00 0x2000>,
+ <0x00 0x4843 0x00 0x4000>;
+ reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt", "cfg",
+ "tchan", "rchan", "rflow";
+ bootph-all;
+};
+
+_pins_default {
+ bootph-all;
+};
+
+_mdio {
+ bootph-all;
+};
+
+_phy0 {
+ bootph-all;
+};
+
+_pins_default {
+ bootph-all;
+};
+
+ {
+ bootph-all;
+
+ ethernet-ports {
+ bootph-all;
+ };
+};
+
+_gmii_sel {
+ bootph-all;
+};
+
+_port1 {
+ bootph-all;
+};
+
+_port2 {
+ status = "disabled";
+};
--
2.34.1
[PATCH 1/3] arm: dts: k3-am62*: sync with Linux v6.9-rc5
Update k3-am62 DT files from Linux v6.9-rc5
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am62-main.dtsi | 126 ++---
arch/arm/dts/k3-am62-mcu.dtsi | 4 +-
arch/arm/dts/k3-am62-phycore-som.dtsi | 5 +-
arch/arm/dts/k3-am62-thermal.dtsi | 5 +-
arch/arm/dts/k3-am62-wakeup.dtsi| 38 --
arch/arm/dts/k3-am62.dtsi | 4 +-
arch/arm/dts/k3-am625-beagleplay.dts| 58
arch/arm/dts/k3-am625-phyboard-lyra-rdk.dts | 104 +-
arch/arm/dts/k3-am625-sk.dts| 4 +-
arch/arm/dts/k3-am625.dtsi | 4 +-
arch/arm/dts/k3-am62a-main.dtsi | 201 ++--
arch/arm/dts/k3-am62a-mcu.dtsi | 4 +-
arch/arm/dts/k3-am62a-thermal.dtsi | 5 +-
arch/arm/dts/k3-am62a-wakeup.dtsi | 4 +-
arch/arm/dts/k3-am62a.dtsi | 4 +-
arch/arm/dts/k3-am62a7-sk.dts | 162 +-
arch/arm/dts/k3-am62a7.dtsi | 4 +-
arch/arm/dts/k3-am62x-sk-common.dtsi| 24 +++-
18 files changed, 653 insertions(+), 107 deletions(-)
diff --git a/arch/arm/dts/k3-am62-main.dtsi b/arch/arm/dts/k3-am62-main.dtsi
index e5c64c86d1d..e9cffca073e 100644
--- a/arch/arm/dts/k3-am62-main.dtsi
+++ b/arch/arm/dts/k3-am62-main.dtsi
@@ -1,8 +1,8 @@
-// SPDX-License-Identifier: GPL-2.0
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
/*
* Device Tree Source for AM625 SoC Family Main Domain peripherals
*
- * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2020-2024 Texas Instruments Incorporated - https://www.ti.com/
*/
_main {
@@ -42,9 +42,8 @@
};
};
- main_conf: syscon@10 {
- compatible = "syscon", "simple-mfd";
- reg = <0x00 0x0010 0x00 0x2>;
+ main_conf: bus@10 {
+ compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x00 0x0010 0x2>;
@@ -121,8 +120,13 @@
<0x00 0x4c00 0x00 0x2>,
<0x00 0x4a82 0x00 0x2>,
<0x00 0x4aa4 0x00 0x2>,
- <0x00 0x4bc0 0x00 0x10>;
- reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt",
"ringrt";
+ <0x00 0x4bc0 0x00 0x10>,
+ <0x00 0x4860 0x00 0x8000>,
+ <0x00 0x484a4000 0x00 0x2000>,
+ <0x00 0x484c2000 0x00 0x2000>,
+ <0x00 0x4842 0x00 0x2000>;
+ reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt",
"ringrt",
+ "ring", "tchan", "rchan", "bchan";
msi-parent = <_main_dmss>;
#dma-cells = <3>;
@@ -138,8 +142,13 @@
reg = <0x00 0x485c 0x00 0x100>,
<0x00 0x4a80 0x00 0x2>,
<0x00 0x4aa0 0x00 0x4>,
- <0x00 0x4b80 0x00 0x40>;
- reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
+ <0x00 0x4b80 0x00 0x40>,
+ <0x00 0x485e 0x00 0x1>,
+ <0x00 0x484a 0x00 0x2000>,
+ <0x00 0x484c 0x00 0x2000>,
+ <0x00 0x4843 0x00 0x1000>;
+ reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
+ "ring", "tchan", "rchan", "rflow";
msi-parent = <_main_dmss>;
#dma-cells = <2>;
@@ -502,6 +511,9 @@
main_gpio0: gpio@60 {
compatible = "ti,am64-gpio", "ti,keystone-gpio";
reg = <0x0 0x0060 0x0 0x100>;
+ gpio-ranges = <_pmx0 0 0 32>,
+ <_pmx0 32 33 38>,
+ <_pmx0 70 72 22>;
gpio-controller;
#gpio-cells = <2>;
interrupt-parent = <_gpio_intr>;
@@ -520,6 +532,10 @@
compatible = "ti,am64-gpio", "ti,keystone-gpio";
[PATCH 0/3] arm: dts: am62-beagleplay: Fix Beagleplay Ethernet
Sync AM62 device tree files with Linux v6.9-rc5 and add in the missing bits in -u-boot.dtsi to get CPSW Ethernet working. The last patch is marked [not-for-merge] as it is not yet applied to Linux device tree. CI testing https://github.com/u-boot/u-boot/pull/527 Signed-off-by: Roger Quadros --- --- Roger Quadros (3): arm: dts: k3-am62*: sync with Linux v6.9-rc5 arm: dts: k3-am625-beagleplay: get CPSW Ethernet to work [not-for-merge] arm: dts: k3-am625-beagleplay: Fix Ethernet PHY reset GPIO arch/arm/dts/k3-am62-main.dtsi | 126 ++--- arch/arm/dts/k3-am62-mcu.dtsi| 4 +- arch/arm/dts/k3-am62-phycore-som.dtsi| 5 +- arch/arm/dts/k3-am62-thermal.dtsi| 5 +- arch/arm/dts/k3-am62-wakeup.dtsi | 38 +++-- arch/arm/dts/k3-am62.dtsi| 4 +- arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 63 + arch/arm/dts/k3-am625-beagleplay.dts | 66 - arch/arm/dts/k3-am625-phyboard-lyra-rdk.dts | 104 +- arch/arm/dts/k3-am625-sk.dts | 4 +- arch/arm/dts/k3-am625.dtsi | 4 +- arch/arm/dts/k3-am62a-main.dtsi | 201 +-- arch/arm/dts/k3-am62a-mcu.dtsi | 4 +- arch/arm/dts/k3-am62a-thermal.dtsi | 5 +- arch/arm/dts/k3-am62a-wakeup.dtsi| 4 +- arch/arm/dts/k3-am62a.dtsi | 4 +- arch/arm/dts/k3-am62a7-sk.dts| 162 - arch/arm/dts/k3-am62a7.dtsi | 4 +- arch/arm/dts/k3-am62x-sk-common.dtsi | 24 +++- 19 files changed, 722 insertions(+), 109 deletions(-) --- base-commit: 38ea74d6d5c05224acdb03f799897c1bdd56f8cc change-id: 20240305-for-2024-07-beagleplay-eth-f82a51197937 Best regards, -- Roger Quadros
Re: [PATCH v3 02/19] board: am64x: Define capsule update firmware info
On 19/04/2024 23:56, Jonathan Humphreys wrote:
> Define the firmware components updatable via EFI capsule update, including
> defining capsule GUIDs for the various firmware components for the AM64x SK.
>
> Signed-off-by: Jonathan Humphreys
> ---
> board/ti/am64x/evm.c| 33 +
> include/configs/am64x_evm.h | 24
> 2 files changed, 57 insertions(+)
>
> diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
> index b8de69da06c..83df75a6911 100644
> --- a/board/ti/am64x/evm.c
> +++ b/board/ti/am64x/evm.c
> @@ -7,6 +7,7 @@
> *
> */
>
> +#include
> #include
> #include
> #include
> @@ -27,6 +28,38 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +#if IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT)
Checkpatch warns:
WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where
possible
#31: FILE: board/ti/am64x/evm.c:31:
+#if IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT)
How about we drop the #if here and instead see possible solution below.
> +struct efi_fw_image fw_images[] = {
> + {
> + .image_type_id = AM64X_SK_TIBOOT3_IMAGE_GUID,
> + .fw_name = u"AM64X_SK_TIBOOT3",
> + .image_index = 1,
> + },
> + {
> + .image_type_id = AM64X_SK_SPL_IMAGE_GUID,
> + .fw_name = u"AM64X_SK_SPL",
> + .image_index = 2,
> + },
> + {
> + .image_type_id = AM64X_SK_UBOOT_IMAGE_GUID,
> + .fw_name = u"AM64X_SK_UBOOT",
> + .image_index = 3,
> + }
> +};
> +
> +struct efi_capsule_update_info update_info = {
> + .dfu_string = "sf 0:0=tiboot3.bin raw 0 10;tispl.bin raw 10
> 20;u-boot.img raw 30 40",
> + .num_images = ARRAY_SIZE(fw_images),
> + .images = fw_images,
> +};
> +
> +void set_dfu_alt_info(char *interface, char *devstr)
> +{
set the environment variable only if relevant config is enabled.
if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT))
> + env_set("dfu_alt_info", update_info.dfu_string);
> +}
> +
> +#endif /* EFI_HAVE_CAPSULE_SUPPORT */
> +
> int board_init(void)
> {
> return 0;
> diff --git a/include/configs/am64x_evm.h b/include/configs/am64x_evm.h
> index f9f8c7bc2f6..9db83621ea8 100644
> --- a/include/configs/am64x_evm.h
> +++ b/include/configs/am64x_evm.h
> @@ -9,6 +9,30 @@
> #ifndef __CONFIG_AM642_EVM_H
> #define __CONFIG_AM642_EVM_H
>
> +/**
> + * define AM64X_SK_TIBOOT3_IMAGE_GUID - firmware GUID for AM64X sk
> tiboot3.bin
> + * define AM64X_SK_SPL_IMAGE_GUID - firmware GUID for AM64X sk SPL
> + * define AM64X_SK_UBOOT_IMAGE_GUID - firmware GUID for AM64X sk UBOOT
> + *
> + * These GUIDs are used in capsules updates to identify the corresponding
> + * firmware object.
> + *
> + * Board developers using this as a starting reference should
> + * define their own GUIDs to ensure that firmware repositories (like
> + * LVFS) do not confuse them.
> + */
> +#define AM64X_SK_TIBOOT3_IMAGE_GUID \
> + EFI_GUID(0xede0a0d5, 0x9116, 0x4bfb, 0xaa, 0x54, \
> + 0x09, 0xe9, 0x7b, 0x5a, 0xfe, 0x1a)
> +
> +#define AM64X_SK_SPL_IMAGE_GUID \
> + EFI_GUID(0x77678f5c, 0x64d4, 0x4910, 0xad, 0x75, \
> + 0x52, 0xc9, 0xd9, 0x5c, 0xdb, 0x1d)
> +
> +#define AM64X_SK_UBOOT_IMAGE_GUID \
> + EFI_GUID(0xc6ad43a9, 0x7d31, 0x4f5d, 0x83, 0xe9, \
> + 0xb8, 0xef, 0xec, 0xae, 0x05, 0xbf)
> +
> /* Now for the remaining common defines */
> #include
>
--
cheers,
-roger
Re: [PATCH v3 03/19] configs: am64x: Enable EFI capsule update
Checkpatch warns: WARNING: Missing commit description - Add an appropriate one On 19/04/2024 23:56, Jonathan Humphreys wrote: > Signed-off-by: Jonathan Humphreys > --- > configs/am64x_evm_a53_defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig > index e000549d6d0..c9bdd7b54cc 100644 > --- a/configs/am64x_evm_a53_defconfig > +++ b/configs/am64x_evm_a53_defconfig > @@ -178,3 +178,5 @@ CONFIG_USB_FUNCTION_MASS_STORAGE=y > CONFIG_SPL_DFU=y > CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 > CONFIG_EFI_SET_TIME=y > +CONFIG_EFI_CAPSULE_ON_DISK=y > +CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y -- cheers, -roger
Re: [PATCH 0/5] net: mdio-uclass: probe generic Ethernet PHY driver & Fix Beagleplay Ethernet
Hi Tom / Joe, On 05/03/2024 15:24, Roger Quadros wrote: > Currently, the GPIO Reset Device Tree properties of the > PHY node are ignored when the PHY is probed via mdio-uclass driver [1]. > > To resolve this, for each child of the MDIO bus node, bind and probe > the generic Ethernet PHY driver if CONFIG_DM_ETH_PHY is enabled. > > This should now show the generic_phy_driver in "dm tree" > and also apply the GPIO reset before the MDIO bus driver scans the bus > for the PHYs. > > ethernet 0 [ + ] am65_cpsw_nuss_port | |-- > ethernet@800port@1 > bootdev 3 [ ] eth_bootdev | | `-- port@1.bootdev > mdio 0 [ + ] cpsw_mdio | `-- mdio@f00 > eth_phy_ge0 [ + ] eth_phy_generic_drv | |-- ethernet-phy@0 > eth_phy_ge1 [ + ] eth_phy_generic_drv | `-- ethernet-phy@1 > > To test this on Beagleplay, the following series is required > > [1] Switch am65-cpsw to DM MDIO > > https://lore.kernel.org/all/20240228-for-2024-07-am65-cpsw-mdio-v2-0-f74f972ea...@kernel.org/ > > The last 3 patches are marked [not-for-merge]. They are to show how the > whole solution can work to fix Ethernet on Beagleplay, which has been broken > so far. Those DT patches will be sent once the device tree changes are merged > into Linux tree. > > Signed-off-by: Roger Quadros > --- > Roger Quadros (5): > net: mdio-uclass: Bind and probe generic Ethernet PHY driver > configs/am62x_beagleplay_a53_defconfig: enable DM_ETH_PHY Any comments to the first 2 patches in this series? > [not-for-merge] arm: dts: k3-am62*: sync with linux-next-20240229 > [not-for-merge] k3-am625-beagleplay-u-boot: get CPSW Ethernet to work > [not-for-merge] arm: dts: k3-am625-beagleplay: Fix Ethernet PHY reset > GPIO > > arch/arm/dts/k3-am62-main.dtsi | 126 ++--- > arch/arm/dts/k3-am62-mcu.dtsi| 4 +- > arch/arm/dts/k3-am62-phycore-som.dtsi| 5 +- > arch/arm/dts/k3-am62-thermal.dtsi| 5 +- > arch/arm/dts/k3-am62-verdin-dev.dtsi | 4 +- > arch/arm/dts/k3-am62-verdin-wifi.dtsi| 1 - > arch/arm/dts/k3-am62-verdin.dtsi | 76 +++--- > arch/arm/dts/k3-am62-wakeup.dtsi | 38 +++-- > arch/arm/dts/k3-am62.dtsi| 4 +- > arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 63 + > arch/arm/dts/k3-am625-beagleplay.dts | 66 - > arch/arm/dts/k3-am625-phyboard-lyra-rdk.dts | 104 +- > arch/arm/dts/k3-am625-sk.dts | 4 +- > arch/arm/dts/k3-am625.dtsi | 4 +- > arch/arm/dts/k3-am62a-main.dtsi | 201 > +-- > arch/arm/dts/k3-am62a-mcu.dtsi | 4 +- > arch/arm/dts/k3-am62a-thermal.dtsi | 5 +- > arch/arm/dts/k3-am62a-wakeup.dtsi| 4 +- > arch/arm/dts/k3-am62a.dtsi | 4 +- > arch/arm/dts/k3-am62a7-sk.dts| 162 - > arch/arm/dts/k3-am62a7.dtsi | 4 +- > arch/arm/dts/k3-am62x-sk-common.dtsi | 24 +++- > configs/am62x_beagleplay_a53_defconfig | 2 +- > net/mdio-uclass.c| 41 ++ > 24 files changed, 825 insertions(+), 130 deletions(-) > --- > base-commit: 84f5bb0be0ec9fbf98f8f3317b578dfc114cf44e > change-id: 20240305-for-2024-07-beagleplay-eth-f82a51197937 > > Best regards, -- cheers, -roger
Re: [PATCH 0/5] net: mdio-uclass: probe generic Ethernet PHY driver & Fix Beagleplay Ethernet
On 08/03/2024 10:22, Roger Quadros wrote:
>
>
> On 05/03/2024 15:24, Roger Quadros wrote:
>> Currently, the GPIO Reset Device Tree properties of the
>> PHY node are ignored when the PHY is probed via mdio-uclass driver [1].
>>
>> To resolve this, for each child of the MDIO bus node, bind and probe
>> the generic Ethernet PHY driver if CONFIG_DM_ETH_PHY is enabled.
>>
>> This should now show the generic_phy_driver in "dm tree"
>> and also apply the GPIO reset before the MDIO bus driver scans the bus
>> for the PHYs.
>>
>> ethernet 0 [ + ] am65_cpsw_nuss_port | |--
>> ethernet@800port@1
>> bootdev 3 [ ] eth_bootdev | | `--
>> port@1.bootdev
>> mdio 0 [ + ] cpsw_mdio | `-- mdio@f00
>> eth_phy_ge0 [ + ] eth_phy_generic_drv | |--
>> ethernet-phy@0
>> eth_phy_ge1 [ + ] eth_phy_generic_drv | `--
>> ethernet-phy@1
>>
>> To test this on Beagleplay, the following series is required
>>
>> [1] Switch am65-cpsw to DM MDIO
>>
>> https://lore.kernel.org/all/20240228-for-2024-07-am65-cpsw-mdio-v2-0-f74f972ea...@kernel.org/
>>
>> The last 3 patches are marked [not-for-merge]. They are to show how the
>> whole solution can work to fix Ethernet on Beagleplay, which has been broken
>> so far. Those DT patches will be sent once the device tree changes are merged
>> into Linux tree.
>>
>> Signed-off-by: Roger Quadros
>
> Some CI tests failed. I will fix and send v2.
> https://github.com/u-boot/u-boot/pull/495
I'm unsure if the failure is due to this series or not.
https://dev.azure.com/u-boot/u-boot/_build/results?buildId=8023=logs=a1270dec-081b-5c65-5cd5-5e915a842596=69f6cf72-86f3-551a-807d-f28f62a1426f=530
Are these known issues?
=== FAILURES ===
___ test_tpm2_sandbox_self_test_full ___
test/py/tests/test_tpm2.py:115: in test_tpm2_sandbox_self_test_full
output = u_boot_console.run_command('echo $?')
test/py/u_boot_console_base.py:256: in run_command
m = self.p.expect([chunk] + self.bad_patterns)
test/py/u_boot_spawn.py:193: in expect
raise Timeout()
E u_boot_spawn.Timeout
- Captured stdout call -
/u-boot
sandbox_serial serial: pinctrl_select_state_full:
uclass_get_device_by_phandle_id: err=-19
TestEfiSignedImage.test_efi_signed_image_auth5
test/py/tests/test_efi_secboot/test_signed.py:162: in
test_efi_signed_image_auth5
output = u_boot_console.run_command_list([
test/py/u_boot_console_base.py:297: in run_command_list
output.append(self.run_command(cmd))
test/py/u_boot_console_base.py:256: in run_command
m = self.p.expect([chunk] + self.bad_patterns)
test/py/u_boot_spawn.py:193: in expect
raise Timeout()
E u_boot_spawn.Timeout
- Captured stdout call -
/u-boot
sandbox_serial serial: pinctrl_select_state_full:
uclass_get_device_by_phandle_id: err=-19
>
>> ---
>> Roger Quadros (5):
>> net: mdio-uclass: Bind and probe generic Ethernet PHY driver
>> configs/am62x_beagleplay_a53_defconfig: enable DM_ETH_PHY
>> [not-for-merge] arm: dts: k3-am62*: sync with linux-next-20240229
>> [not-for-merge] k3-am625-beagleplay-u-boot: get CPSW Ethernet to work
>> [not-for-merge] arm: dts: k3-am625-beagleplay: Fix Ethernet PHY reset
>> GPIO
>>
>> arch/arm/dts/k3-am62-main.dtsi | 126 ++---
>> arch/arm/dts/k3-am62-mcu.dtsi| 4 +-
>> arch/arm/dts/k3-am62-phycore-som.dtsi| 5 +-
>> arch/arm/dts/k3-am62-thermal.dtsi| 5 +-
>> arch/arm/dts/k3-am62-verdin-dev.dtsi | 4 +-
>> arch/arm/dts/k3-am62-verdin-wifi.dtsi| 1 -
>> arch/arm/dts/k3-am62-verdin.dtsi | 76 +++---
>> arch/arm/dts/k3-am62-wakeup.dtsi | 38 +++--
>> arch/arm/dts/k3-am62.dtsi| 4 +-
>> arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 63 +
>> arch/arm/dts/k3-am625-beagleplay.dts | 66 -
>> arch/arm/dts/k3-am625-phyboard-lyra-rdk.dts | 104 +-
>> arch/arm/dts/k3-am625-sk.dts | 4 +-
>> arch/arm/dts/k3-am625.dtsi | 4 +-
>> arch/arm/dts/k3-am62a-main.dtsi | 201
>> +--
>> arch/arm/dts/k3-am62a-mcu.dtsi | 4 +-
>> arch/arm/dts/k3-am62a-thermal.dtsi | 5 +-
>&
Re: [PATCH 0/5] net: mdio-uclass: probe generic Ethernet PHY driver & Fix Beagleplay Ethernet
On 05/03/2024 15:24, Roger Quadros wrote: > Currently, the GPIO Reset Device Tree properties of the > PHY node are ignored when the PHY is probed via mdio-uclass driver [1]. > > To resolve this, for each child of the MDIO bus node, bind and probe > the generic Ethernet PHY driver if CONFIG_DM_ETH_PHY is enabled. > > This should now show the generic_phy_driver in "dm tree" > and also apply the GPIO reset before the MDIO bus driver scans the bus > for the PHYs. > > ethernet 0 [ + ] am65_cpsw_nuss_port | |-- > ethernet@800port@1 > bootdev 3 [ ] eth_bootdev | | `-- port@1.bootdev > mdio 0 [ + ] cpsw_mdio | `-- mdio@f00 > eth_phy_ge0 [ + ] eth_phy_generic_drv | |-- ethernet-phy@0 > eth_phy_ge1 [ + ] eth_phy_generic_drv | `-- ethernet-phy@1 > > To test this on Beagleplay, the following series is required > > [1] Switch am65-cpsw to DM MDIO > > https://lore.kernel.org/all/20240228-for-2024-07-am65-cpsw-mdio-v2-0-f74f972ea...@kernel.org/ > > The last 3 patches are marked [not-for-merge]. They are to show how the > whole solution can work to fix Ethernet on Beagleplay, which has been broken > so far. Those DT patches will be sent once the device tree changes are merged > into Linux tree. > > Signed-off-by: Roger Quadros Some CI tests failed. I will fix and send v2. https://github.com/u-boot/u-boot/pull/495 > --- > Roger Quadros (5): > net: mdio-uclass: Bind and probe generic Ethernet PHY driver > configs/am62x_beagleplay_a53_defconfig: enable DM_ETH_PHY > [not-for-merge] arm: dts: k3-am62*: sync with linux-next-20240229 > [not-for-merge] k3-am625-beagleplay-u-boot: get CPSW Ethernet to work > [not-for-merge] arm: dts: k3-am625-beagleplay: Fix Ethernet PHY reset > GPIO > > arch/arm/dts/k3-am62-main.dtsi | 126 ++--- > arch/arm/dts/k3-am62-mcu.dtsi| 4 +- > arch/arm/dts/k3-am62-phycore-som.dtsi| 5 +- > arch/arm/dts/k3-am62-thermal.dtsi| 5 +- > arch/arm/dts/k3-am62-verdin-dev.dtsi | 4 +- > arch/arm/dts/k3-am62-verdin-wifi.dtsi| 1 - > arch/arm/dts/k3-am62-verdin.dtsi | 76 +++--- > arch/arm/dts/k3-am62-wakeup.dtsi | 38 +++-- > arch/arm/dts/k3-am62.dtsi| 4 +- > arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 63 + > arch/arm/dts/k3-am625-beagleplay.dts | 66 - > arch/arm/dts/k3-am625-phyboard-lyra-rdk.dts | 104 +- > arch/arm/dts/k3-am625-sk.dts | 4 +- > arch/arm/dts/k3-am625.dtsi | 4 +- > arch/arm/dts/k3-am62a-main.dtsi | 201 > +-- > arch/arm/dts/k3-am62a-mcu.dtsi | 4 +- > arch/arm/dts/k3-am62a-thermal.dtsi | 5 +- > arch/arm/dts/k3-am62a-wakeup.dtsi| 4 +- > arch/arm/dts/k3-am62a.dtsi | 4 +- > arch/arm/dts/k3-am62a7-sk.dts| 162 - > arch/arm/dts/k3-am62a7.dtsi | 4 +- > arch/arm/dts/k3-am62x-sk-common.dtsi | 24 +++- > configs/am62x_beagleplay_a53_defconfig | 2 +- > net/mdio-uclass.c| 41 ++ > 24 files changed, 825 insertions(+), 130 deletions(-) > --- > base-commit: 84f5bb0be0ec9fbf98f8f3317b578dfc114cf44e > change-id: 20240305-for-2024-07-beagleplay-eth-f82a51197937 > > Best regards, -- cheers, -roger
[PATCH not-for-merge 5/5] arm: dts: k3-am625-beagleplay: Fix Ethernet PHY reset GPIO
Move GPIO pinmux to MDIO node. Add GB Ethernet reset GPIO.
Add PIN_INPUT to Fix SPE ethernet reset gpio so that
reading the GPIO can give correct status.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am625-beagleplay.dts | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/k3-am625-beagleplay.dts
b/arch/arm/dts/k3-am625-beagleplay.dts
index a34e0df2ab..8ab838f169 100644
--- a/arch/arm/dts/k3-am625-beagleplay.dts
+++ b/arch/arm/dts/k3-am625-beagleplay.dts
@@ -292,6 +292,8 @@
pinctrl-single,pins = <
AM62X_IOPAD(0x0160, PIN_OUTPUT, 0) /* (AD24) MDIO0_MDC
*/
AM62X_IOPAD(0x015c, PIN_INPUT, 0) /* (AB22) MDIO0_MDIO
*/
+ AM62X_IOPAD(0x003c, PIN_INPUT, 7) /* (M25)
GPMC0_AD0.GPIO0_15 */
+ AM62X_IOPAD(0x018c, PIN_INPUT, 7) /* (AC21)
RGMII2_RD2.GPIO1_5 */
>;
};
@@ -383,7 +385,6 @@
AM62X_IOPAD(0x016c, PIN_INPUT, 1) /* (Y18)
RGMII2_TD0.RMII2_TXD0 */
AM62X_IOPAD(0x0170, PIN_INPUT, 1) /* (AA18)
RGMII2_TD1.RMII2_TXD1 */
AM62X_IOPAD(0x0164, PIN_INPUT, 1) /* (AA19)
RGMII2_TX_CTL.RMII2_TX_EN */
- AM62X_IOPAD(0x018c, PIN_OUTPUT, 7) /* (AC21)
RGMII2_RD2.GPIO1_5 */
AM62X_IOPAD(0x0190, PIN_INPUT, 7) /* (AE22)
RGMII2_RD3.GPIO1_6 */
AM62X_IOPAD(0x01f0, PIN_OUTPUT, 5) /* (A18)
EXT_REFCLK1.CLKOUT0 */
>;
@@ -597,6 +598,9 @@
cpsw3g_phy0: ethernet-phy@0 {
reg = <0>;
+ reset-gpios = <_gpio0 15 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <1>;
+ reset-deassert-us = <5>;
};
cpsw3g_phy1: ethernet-phy@1 {
@@ -615,7 +619,7 @@
"USR0", "USR1", "USR2", "USR3", "", "", "USR4", /* 3-9 */
"EEPROM_WP",/* 10 */
"CSI2_CAMERA_GPIO1", "CSI2_CAMERA_GPIO2", /* 11-12 */
- "CC1352P7_BOOT", "CC1352P7_RSTN", "", "", "", /* 13-17 */
+ "CC1352P7_BOOT", "CC1352P7_RSTN", "GBE_RSTN", "", "", /*
13-17 */
"USR_BUTTON", "", "", "", "", "", "", "", "", /* 18-26 */
"", "", "", "", "", "", "", "", "", "HDMI_INT", /* 27-36 */
"", "VDD_WLAN_EN", "", "", "WL_IRQ", "GBE_INTN",/* 37-42 */
--
2.34.1
[PATCH not-for-merge 4/5] k3-am625-beagleplay-u-boot: get CPSW Ethernet to work
Add missing bits to get CPSW Ethernet working.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 63
1 file changed, 63 insertions(+)
diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
index a723caa580..fc05121ccc 100644
--- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
@@ -213,3 +213,66 @@
};
};
#endif
+
+_bcdma {
+ reg = <0x00 0x485c0100 0x00 0x100>,
+ <0x00 0x4c00 0x00 0x2>,
+ <0x00 0x4a82 0x00 0x2>,
+ <0x00 0x4aa4 0x00 0x2>,
+ <0x00 0x4bc0 0x00 0x10>,
+ <0x00 0x4860 0x00 0x8000>,
+ <0x00 0x484a4000 0x00 0x2000>,
+ <0x00 0x484c2000 0x00 0x2000>;
+ reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
+ "cfg", "tchan", "rchan";
+};
+
+_pktdma {
+ reg = <0x00 0x485c 0x00 0x100>,
+ <0x00 0x4a80 0x00 0x2>,
+ <0x00 0x4aa0 0x00 0x4>,
+ <0x00 0x4b80 0x00 0x40>,
+ <0x00 0x485e 0x00 0x2>,
+ <0x00 0x484a 0x00 0x4000>,
+ <0x00 0x484c 0x00 0x2000>,
+ <0x00 0x4843 0x00 0x4000>;
+ reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt", "cfg",
+ "tchan", "rchan", "rflow";
+ bootph-all;
+};
+
+_pins_default {
+ bootph-all;
+};
+
+_mdio {
+ bootph-all;
+};
+
+_phy0 {
+ bootph-all;
+};
+
+_pins_default {
+ bootph-all;
+};
+
+ {
+ bootph-all;
+
+ ethernet-ports {
+ bootph-all;
+ };
+};
+
+_gmii_sel {
+ bootph-all;
+};
+
+_port1 {
+ bootph-all;
+};
+
+_port2 {
+ status = "disabled";
+};
--
2.34.1
[PATCH not-for-merge 3/5] arm: dts: k3-am62*: sync with linux-next-20240229
Update k3-am62 DT files from linux-next-20240229.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am62-main.dtsi | 126 ++---
arch/arm/dts/k3-am62-mcu.dtsi | 4 +-
arch/arm/dts/k3-am62-phycore-som.dtsi | 5 +-
arch/arm/dts/k3-am62-thermal.dtsi | 5 +-
arch/arm/dts/k3-am62-verdin-dev.dtsi| 4 +-
arch/arm/dts/k3-am62-verdin-wifi.dtsi | 1 -
arch/arm/dts/k3-am62-verdin.dtsi| 76 ---
arch/arm/dts/k3-am62-wakeup.dtsi| 38 --
arch/arm/dts/k3-am62.dtsi | 4 +-
arch/arm/dts/k3-am625-beagleplay.dts| 58
arch/arm/dts/k3-am625-phyboard-lyra-rdk.dts | 104 +-
arch/arm/dts/k3-am625-sk.dts| 4 +-
arch/arm/dts/k3-am625.dtsi | 4 +-
arch/arm/dts/k3-am62a-main.dtsi | 201 ++--
arch/arm/dts/k3-am62a-mcu.dtsi | 4 +-
arch/arm/dts/k3-am62a-thermal.dtsi | 5 +-
arch/arm/dts/k3-am62a-wakeup.dtsi | 4 +-
arch/arm/dts/k3-am62a.dtsi | 4 +-
arch/arm/dts/k3-am62a7-sk.dts | 162 +-
arch/arm/dts/k3-am62a7.dtsi | 4 +-
arch/arm/dts/k3-am62x-sk-common.dtsi| 24 +++-
21 files changed, 714 insertions(+), 127 deletions(-)
diff --git a/arch/arm/dts/k3-am62-main.dtsi b/arch/arm/dts/k3-am62-main.dtsi
index e5c64c86d1..e9cffca073 100644
--- a/arch/arm/dts/k3-am62-main.dtsi
+++ b/arch/arm/dts/k3-am62-main.dtsi
@@ -1,8 +1,8 @@
-// SPDX-License-Identifier: GPL-2.0
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
/*
* Device Tree Source for AM625 SoC Family Main Domain peripherals
*
- * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2020-2024 Texas Instruments Incorporated - https://www.ti.com/
*/
_main {
@@ -42,9 +42,8 @@
};
};
- main_conf: syscon@10 {
- compatible = "syscon", "simple-mfd";
- reg = <0x00 0x0010 0x00 0x2>;
+ main_conf: bus@10 {
+ compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x00 0x0010 0x2>;
@@ -121,8 +120,13 @@
<0x00 0x4c00 0x00 0x2>,
<0x00 0x4a82 0x00 0x2>,
<0x00 0x4aa4 0x00 0x2>,
- <0x00 0x4bc0 0x00 0x10>;
- reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt",
"ringrt";
+ <0x00 0x4bc0 0x00 0x10>,
+ <0x00 0x4860 0x00 0x8000>,
+ <0x00 0x484a4000 0x00 0x2000>,
+ <0x00 0x484c2000 0x00 0x2000>,
+ <0x00 0x4842 0x00 0x2000>;
+ reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt",
"ringrt",
+ "ring", "tchan", "rchan", "bchan";
msi-parent = <_main_dmss>;
#dma-cells = <3>;
@@ -138,8 +142,13 @@
reg = <0x00 0x485c 0x00 0x100>,
<0x00 0x4a80 0x00 0x2>,
<0x00 0x4aa0 0x00 0x4>,
- <0x00 0x4b80 0x00 0x40>;
- reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
+ <0x00 0x4b80 0x00 0x40>,
+ <0x00 0x485e 0x00 0x1>,
+ <0x00 0x484a 0x00 0x2000>,
+ <0x00 0x484c 0x00 0x2000>,
+ <0x00 0x4843 0x00 0x1000>;
+ reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
+ "ring", "tchan", "rchan", "rflow";
msi-parent = <_main_dmss>;
#dma-cells = <2>;
@@ -502,6 +511,9 @@
main_gpio0: gpio@60 {
compatible = "ti,am64-gpio", "ti,keystone-gpio";
reg = <0x0 0x0060 0x0 0x100>;
+ gpio-ranges = <_pmx0 0 0 32>,
+ <_pmx0 32 33 38>,
+ <_pmx0 70 72 22>;
gpio-controller;
#gpio-cells = <2>;
[PATCH 2/5] configs/am62x_beagleplay_a53_defconfig: enable DM_ETH_PHY
Reset GPIO handling is done in ETH PHY Class driver. Enable DM_ETH_PHY. We don't use Fixed PHY so disable PHY_FIXED. Signed-off-by: Roger Quadros --- configs/am62x_beagleplay_a53_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/am62x_beagleplay_a53_defconfig b/configs/am62x_beagleplay_a53_defconfig index 1f43891d10..a8925e4dcf 100644 --- a/configs/am62x_beagleplay_a53_defconfig +++ b/configs/am62x_beagleplay_a53_defconfig @@ -90,9 +90,9 @@ CONFIG_SPL_MMC_SDHCI_ADMA=y CONFIG_MMC_SDHCI_AM654=y CONFIG_PHY_REALTEK=y CONFIG_PHY_TI=y -CONFIG_PHY_FIXED=y CONFIG_TI_AM65_CPSW_NUSS=y CONFIG_PHY=y +CONFIG_DM_ETH_PHY=y CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y CONFIG_PINCTRL_SINGLE=y -- 2.34.1
[PATCH 1/5] net: mdio-uclass: Bind and probe generic Ethernet PHY driver
If DM_ETH_PHY is enabled then try to bind and probe the
generic Ethernet PHY driver for each child of MDIO bus.
This is to ensure that GPIO reset handling is done if available
before MDIO bus driver scans for the PHYs.
Signed-off-by: Roger Quadros
---
net/mdio-uclass.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/net/mdio-uclass.c b/net/mdio-uclass.c
index 6fc7034111..0ebfb2f134 100644
--- a/net/mdio-uclass.c
+++ b/net/mdio-uclass.c
@@ -6,6 +6,8 @@
#include
#include
+#include
+#include
#include
#include
#include
@@ -121,6 +123,42 @@ static int mdio_reset(struct mii_dev *mii_bus)
return dm_mdio_reset(mii_bus->priv);
}
+static int mdio_bind_phy_nodes(struct udevice *mdio_dev)
+{
+ ofnode mdio_node, phy_node;
+ struct udevice *phy_dev;
+ const char *node_name;
+ int ret;
+
+ mdio_node = dev_ofnode(mdio_dev);
+ if (!ofnode_valid(mdio_node)) {
+ dev_dbg(mdio_dev, "invalid ofnode for mdio_dev\n");
+ return -ENXIO;
+ }
+
+ ofnode_for_each_subnode(phy_node, mdio_node) {
+ node_name = ofnode_get_name(phy_node);
+ dev_dbg(mdio_dev, "* Found child node: '%s'\n", node_name);
+ ret = device_bind_driver_to_node(mdio_dev,
+"eth_phy_generic_drv",
+node_name, phy_node, _dev);
+ if (ret) {
+ dev_dbg(mdio_dev, " - Eth phy binding error: %d\n",
ret);
+ continue;
+ }
+
+ dev_dbg(mdio_dev, " - bound phy device: '%s'\n", node_name);
+ ret = device_probe(phy_dev);
+ if (ret) {
+ dev_dbg(mdio_dev, "Device '%s' probe failed\n",
phy_dev->name);
+ device_unbind(phy_dev);
+ continue;
+ }
+ }
+
+ return 0;
+}
+
static int dm_mdio_post_probe(struct udevice *dev)
{
struct mdio_perdev_priv *pdata = dev_get_uclass_priv(dev);
@@ -154,6 +192,9 @@ static int dm_mdio_post_probe(struct udevice *dev)
}
}
+ if (CONFIG_IS_ENABLED(DM_ETH_PHY))
+ mdio_bind_phy_nodes(dev);
+
return mdio_register(pdata->mii_bus);
}
--
2.34.1
[PATCH 0/5] net: mdio-uclass: probe generic Ethernet PHY driver & Fix Beagleplay Ethernet
Currently, the GPIO Reset Device Tree properties of the PHY node are ignored when the PHY is probed via mdio-uclass driver [1]. To resolve this, for each child of the MDIO bus node, bind and probe the generic Ethernet PHY driver if CONFIG_DM_ETH_PHY is enabled. This should now show the generic_phy_driver in "dm tree" and also apply the GPIO reset before the MDIO bus driver scans the bus for the PHYs. ethernet 0 [ + ] am65_cpsw_nuss_port | |-- ethernet@800port@1 bootdev 3 [ ] eth_bootdev | | `-- port@1.bootdev mdio 0 [ + ] cpsw_mdio | `-- mdio@f00 eth_phy_ge0 [ + ] eth_phy_generic_drv | |-- ethernet-phy@0 eth_phy_ge1 [ + ] eth_phy_generic_drv | `-- ethernet-phy@1 To test this on Beagleplay, the following series is required [1] Switch am65-cpsw to DM MDIO https://lore.kernel.org/all/20240228-for-2024-07-am65-cpsw-mdio-v2-0-f74f972ea...@kernel.org/ The last 3 patches are marked [not-for-merge]. They are to show how the whole solution can work to fix Ethernet on Beagleplay, which has been broken so far. Those DT patches will be sent once the device tree changes are merged into Linux tree. Signed-off-by: Roger Quadros --- Roger Quadros (5): net: mdio-uclass: Bind and probe generic Ethernet PHY driver configs/am62x_beagleplay_a53_defconfig: enable DM_ETH_PHY [not-for-merge] arm: dts: k3-am62*: sync with linux-next-20240229 [not-for-merge] k3-am625-beagleplay-u-boot: get CPSW Ethernet to work [not-for-merge] arm: dts: k3-am625-beagleplay: Fix Ethernet PHY reset GPIO arch/arm/dts/k3-am62-main.dtsi | 126 ++--- arch/arm/dts/k3-am62-mcu.dtsi| 4 +- arch/arm/dts/k3-am62-phycore-som.dtsi| 5 +- arch/arm/dts/k3-am62-thermal.dtsi| 5 +- arch/arm/dts/k3-am62-verdin-dev.dtsi | 4 +- arch/arm/dts/k3-am62-verdin-wifi.dtsi| 1 - arch/arm/dts/k3-am62-verdin.dtsi | 76 +++--- arch/arm/dts/k3-am62-wakeup.dtsi | 38 +++-- arch/arm/dts/k3-am62.dtsi| 4 +- arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 63 + arch/arm/dts/k3-am625-beagleplay.dts | 66 - arch/arm/dts/k3-am625-phyboard-lyra-rdk.dts | 104 +- arch/arm/dts/k3-am625-sk.dts | 4 +- arch/arm/dts/k3-am625.dtsi | 4 +- arch/arm/dts/k3-am62a-main.dtsi | 201 +-- arch/arm/dts/k3-am62a-mcu.dtsi | 4 +- arch/arm/dts/k3-am62a-thermal.dtsi | 5 +- arch/arm/dts/k3-am62a-wakeup.dtsi| 4 +- arch/arm/dts/k3-am62a.dtsi | 4 +- arch/arm/dts/k3-am62a7-sk.dts| 162 - arch/arm/dts/k3-am62a7.dtsi | 4 +- arch/arm/dts/k3-am62x-sk-common.dtsi | 24 +++- configs/am62x_beagleplay_a53_defconfig | 2 +- net/mdio-uclass.c| 41 ++ 24 files changed, 825 insertions(+), 130 deletions(-) --- base-commit: 84f5bb0be0ec9fbf98f8f3317b578dfc114cf44e change-id: 20240305-for-2024-07-beagleplay-eth-f82a51197937 Best regards, -- Roger Quadros
Re: [PATCH v6] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc
On 28/02/2024 14:06, MD Danish Anwar wrote: > Add APIs to set a firmware_name to a rproc and boot the rproc with the > same firmware. > > Clients can call rproc_set_firmware() API to set firmware_name for a rproc > whereas rproc_boot() will load the firmware set by rproc_set_firmware() to > a buffer by calling request_firmware_into_buf(). rproc_boot() will then > load the firmware file to the remote processor and start the remote > processor. > > Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in > Kconfig so that we can call request_firmware_into_buf() from remoteproc > driver. > > Signed-off-by: MD Danish Anwar > Acked-by: Ravi Gunasekaran Reviewed-by: Roger Quadros
Re: [PATCH v5] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc
On 28/02/2024 12:35, MD Danish Anwar wrote:
>
>
> On 28/02/24 3:30 pm, Roger Quadros wrote:
>>
>>
>> On 17/02/2024 14:26, MD Danish Anwar wrote:
>>> Add APIs to set a firmware_name to a rproc and boot the rproc with the
>>> same firmware.
>>>
>>> Clients can call rproc_set_firmware() API to set firmware_name for a rproc
>>> whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
>>> a buffer by calling request_firmware_into_buf(). rproc_boot() will then
>>> load the firmware file to the remote processor and start the remote
>>> processor.
>>>
>>> Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
>>> Kconfig so that we can call request_firmware_into_buf() from remoteproc
>>> driver.
>>>
>>> Signed-off-by: MD Danish Anwar
>>> ---
>>> Changes from v4 to v5:
>>> *) Added Kconfig option REMOTEPROC_MAX_FW_SIZE to set max firmware size
>>>that can be loaded to a rproc.
>>> *) Added freeing of address in rproc_boot() as pointed out by Ravi.
>>> *) Allocating the address at a later point in rproc_boot()
>>> *) Rebased on latest u-boot/master [commit
>>>9e00b6993f724da9699ef12573307afea8c19284]
>>>
>>> Changes from v3 to v4:
>>> *) No functional change. Splitted the patch out of the series as suggested
>>>by Nishant.
>>> *) Droppped the RFC tag.
>>>
>>> v4: https://lore.kernel.org/all/20240130063322.2345057-1-danishan...@ti.com/
>>> v3: https://lore.kernel.org/all/20240124064930.1787929-4-danishan...@ti.com/
>>>
>>> drivers/remoteproc/Kconfig| 8 +++
>>> drivers/remoteproc/rproc-uclass.c | 100 ++
>>> include/remoteproc.h | 34 ++
>>> 3 files changed, 142 insertions(+)
>>>
>>> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
>>> index 781de530af..759d21437a 100644
>>> --- a/drivers/remoteproc/Kconfig
>>> +++ b/drivers/remoteproc/Kconfig
>>> @@ -10,6 +10,7 @@ menu "Remote Processor drivers"
>>> # All users should depend on DM
>>> config REMOTEPROC
>>> bool
>>> + select FS_LOADER
>>> depends on DM
>>>
>>> # Please keep the configuration alphabetically sorted.
>>> @@ -102,4 +103,11 @@ config REMOTEPROC_TI_IPU
>>> help
>>> Say 'y' here to add support for TI' K3 remoteproc driver.
>>>
>>> +config REMOTEPROC_MAX_FW_SIZE
>>> + hex "Maximum size of firmware that needs to be loaded to rproc"
>>
>> firmware file?
>>
>> /rproc/the remote processor
>>
>>> + default 0x1
>>> + help
>>> + Maximum size of the firmware file (elf, binary) that needs to be
>>> + loaded to th rproc core.
>>
>> s/th/the
>> s/rproc/remote processor
>>
>
> Will fix these typos.
>
>>> +
>>> endmenu
>>> diff --git a/drivers/remoteproc/rproc-uclass.c
>>> b/drivers/remoteproc/rproc-uclass.c
>>> index 28b362c887..784361cef9 100644
>>> --- a/drivers/remoteproc/rproc-uclass.c
>>> +++ b/drivers/remoteproc/rproc-uclass.c
>>> @@ -13,6 +13,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -961,3 +962,102 @@ unsigned long rproc_parse_resource_table(struct
>>> udevice *dev, struct rproc *cfg)
>>>
>>> return 1;
>>> }
>>> +
>>> +int rproc_set_firmware(struct udevice *rproc_dev, const char *fw_name)
>>> +{
>>> + struct dm_rproc_uclass_pdata *uc_pdata;
>>> + int len;
>>> + char *p;
>>> +
>>> + if (!rproc_dev || !fw_name)
>>> + return -EINVAL;
>>> +
>>> + uc_pdata = dev_get_uclass_plat(rproc_dev);
>>> + if (!uc_pdata)
>>> + return -EINVAL;
>>> +
>>> + len = strcspn(fw_name, "\n");
>>> + if (!len) {
>>> + debug("invalid firmware name\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + p = strndup(fw_name, len);
>>> + if (!p)
>>> + return -ENOMEM;
>>
>> Aren't we leaking memory if rproc_set_firmware() is called multiple times?
>> Can we check if uc_pdata->fw_name exists and free it before the str
[PATCH v2 2/2] net: am65-cpsw: cpsw_mdio: Switch to proper DM_MDIO framework
Add a new Kconfig symbol MDIO_TI_CPSW for the CPSW MDIO
driver and build it with proper DM support if enabled.
If MDIO_TI_CPSW is not enabled then we continue to
behave like before.
Clean up MDIO custom handling in am65-cpsw and use
dm_eth_phy_connect() to get the PHY.
Signed-off-by: Roger Quadros
---
Changelog:
v2: no change
---
drivers/net/ti/Kconfig | 8 ++
drivers/net/ti/Makefile | 3 +-
drivers/net/ti/am65-cpsw-nuss.c | 190 ++
drivers/net/ti/cpsw_mdio.c | 198 +++-
drivers/net/ti/cpsw_mdio.h | 2 +
5 files changed, 196 insertions(+), 205 deletions(-)
diff --git a/drivers/net/ti/Kconfig b/drivers/net/ti/Kconfig
index c75f418628..72eccc99e5 100644
--- a/drivers/net/ti/Kconfig
+++ b/drivers/net/ti/Kconfig
@@ -45,7 +45,15 @@ config TI_AM65_CPSW_NUSS
imply MISC_INIT_R
imply MISC
imply SYSCON
+ imply MDIO_TI_CPSW
select PHYLIB
help
This driver supports TI K3 MCU CPSW Nuss Ethernet controller
in Texas Instruments K3 AM65x SoCs.
+
+config MDIO_TI_CPSW
+ bool "TI CPSW MDIO interface support"
+ depends on DM_MDIO
+ help
+ This driver supports the TI CPSW MDIO interface found in various
+ TI SoCs.
diff --git a/drivers/net/ti/Makefile b/drivers/net/ti/Makefile
index 0ce0cf2828..30c4c4b6d5 100644
--- a/drivers/net/ti/Makefile
+++ b/drivers/net/ti/Makefile
@@ -5,4 +5,5 @@
obj-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o cpsw-common.o cpsw_mdio.o
obj-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o
obj-$(CONFIG_DRIVER_TI_KEYSTONE_NET) += keystone_net.o cpsw_mdio.o
-obj-$(CONFIG_TI_AM65_CPSW_NUSS) += am65-cpsw-nuss.o cpsw_mdio.o
+obj-$(CONFIG_TI_AM65_CPSW_NUSS) += am65-cpsw-nuss.o
+obj-$(CONFIG_MDIO_TI_CPSW) += cpsw_mdio.o
diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 6da018c0f9..d68ed67183 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -31,8 +31,6 @@
#include
#include
-#include "cpsw_mdio.h"
-
#define AM65_CPSW_CPSWNU_MAX_PORTS 9
#define AM65_CPSW_SS_BASE 0x0
@@ -113,7 +111,6 @@ struct am65_cpsw_common {
struct udevice *dev;
fdt_addr_t ss_base;
fdt_addr_t cpsw_base;
- fdt_addr_t mdio_base;
fdt_addr_t ale_base;
struct clk fclk;
@@ -122,13 +119,8 @@ struct am65_cpsw_common {
u32 port_num;
struct am65_cpsw_port ports[AM65_CPSW_CPSWNU_MAX_PORTS];
- 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;
@@ -140,13 +132,7 @@ struct am65_cpsw_priv {
struct udevice *dev;
struct am65_cpsw_common *cpsw_common;
u32 port_id;
-
struct phy_device *phydev;
- boolhas_phy;
- ofnode phy_node;
- u32 phy_addr;
-
- boolmdio_manual_mode;
};
#ifdef PKTSIZE_ALIGN
@@ -622,111 +608,15 @@ static const struct eth_ops am65_cpsw_ops = {
.read_rom_hwaddr = am65_cpsw_read_rom_hwaddr,
};
-static const struct soc_attr k3_mdio_soc_data[] = {
- { .family = "AM62X", .revision = "SR1.0" },
- { .family = "AM64X", .revision = "SR1.0" },
- { .family = "AM64X", .revision = "SR2.0" },
- { .family = "AM65X", .revision = "SR1.0" },
- { .family = "AM65X", .revision = "SR2.0" },
- { .family = "J7200", .revision = "SR1.0" },
- { .family = "J7200", .revision = "SR2.0" },
- { .family = "J721E", .revision = "SR1.0" },
- { .family = "J721E", .revision = "SR1.1" },
- { .family = "J721S2", .revision = "SR1.0" },
- { /* 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(md
[PATCH v2 1/2] net: mdio: Handle bus level GPIO Reset
Some platforms have bus level Reset controlled
by a GPIO line. If available then handle bus reset
via GPIO.
Signed-off-by: Roger Quadros
---
Changelog:
v2:
- Fix build if DM_GPIO not set
- Fix build on platforms that don't have
by using
---
include/phy.h | 7 +++
net/mdio-uclass.c | 37 -
2 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/include/phy.h b/include/phy.h
index e02cbdb58c..ae23814bbf 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -9,6 +9,7 @@
#ifndef _PHY_H
#define _PHY_H
+#include
#include
#include
#include
@@ -76,6 +77,12 @@ struct mii_dev {
int (*reset)(struct mii_dev *bus);
struct phy_device *phymap[PHY_MAX_ADDR];
u32 phy_mask;
+ /** @reset_delay_us: Bus GPIO reset pulse width in microseconds */
+ int reset_delay_us;
+ /** @reset_post_delay_us: Bus GPIO reset deassert delay in microseconds
*/
+ int reset_post_delay_us;
+ /** @reset_gpiod: Bus Reset GPIO descriptor pointer */
+ struct gpio_desc reset_gpiod;
};
/* struct phy_driver: a structure which defines PHY behavior
diff --git a/net/mdio-uclass.c b/net/mdio-uclass.c
index e758cc66d7..6fc7034111 100644
--- a/net/mdio-uclass.c
+++ b/net/mdio-uclass.c
@@ -14,6 +14,9 @@
#include
#include
#include
+#include
+
+#define DEFAULT_GPIO_RESET_DELAY 10 /* in microseconds */
void dm_mdio_probe_devices(void)
{
@@ -80,6 +83,16 @@ int dm_mdio_write(struct udevice *mdio_dev, int addr, int
devad, int reg,
int dm_mdio_reset(struct udevice *mdio_dev)
{
struct mdio_ops *ops = mdio_get_ops(mdio_dev);
+ struct mdio_perdev_priv *pdata = dev_get_uclass_priv(mdio_dev);
+ struct mii_dev *mii_bus = pdata->mii_bus;
+
+ if (CONFIG_IS_ENABLED(DM_GPIO) &&
dm_gpio_is_valid(_bus->reset_gpiod)) {
+ dm_gpio_set_value(_bus->reset_gpiod, 1);
+ udelay(mii_bus->reset_delay_us);
+ dm_gpio_set_value(_bus->reset_gpiod, 0);
+ if (mii_bus->reset_post_delay_us > 0)
+ udelay(mii_bus->reset_post_delay_us);
+ }
if (!ops->reset)
return 0;
@@ -111,14 +124,36 @@ static int mdio_reset(struct mii_dev *mii_bus)
static int dm_mdio_post_probe(struct udevice *dev)
{
struct mdio_perdev_priv *pdata = dev_get_uclass_priv(dev);
+ struct mii_dev *mii_bus;
+ int ret;
- pdata->mii_bus = mdio_alloc();
+ mii_bus = mdio_alloc();
+ if (!mii_bus) {
+ dev_err(dev, "couldn't allocate mii_bus\n");
+ return -ENOMEM;
+ }
+ pdata->mii_bus = mii_bus;
pdata->mii_bus->read = mdio_read;
pdata->mii_bus->write = mdio_write;
pdata->mii_bus->reset = mdio_reset;
pdata->mii_bus->priv = dev;
strlcpy(pdata->mii_bus->name, dev->name, MDIO_NAME_LEN);
+ if (IS_ENABLED(CONFIG_DM_GPIO)) {
+ /* Get bus level PHY reset GPIO details */
+ mii_bus->reset_delay_us = dev_read_u32_default(dev,
"reset-delay-us",
+
DEFAULT_GPIO_RESET_DELAY);
+ mii_bus->reset_post_delay_us = dev_read_u32_default(dev,
+
"reset-post-delay-us",
+ 0);
+ ret = gpio_request_by_name(dev, "reset-gpios", 0,
_bus->reset_gpiod,
+ GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
+ if (ret && ret != -ENOENT) {
+ dev_err(dev, "couldn't get reset-gpios: %d\n", ret);
+ return ret;
+ }
+ }
+
return mdio_register(pdata->mii_bus);
}
--
2.34.1
[PATCH v2 0/2] net: ti: am65-cpsw / cpsw-mdio: Switch to DM MDIO
Hi, This converts cpsw-mdio into a proper Driver Model driver and introduces the new Config symbol CONFIG_MDIO_TI_CPSW. It also cleans up the am65-cpsw driver so it porperly uses the DM PHY interface. It does not convert the legacy cpsw and keystone-net drivers. Tested on SK-AM62, SK-AM64, j721e_beagleboneai64 and AM335x BeagleBone. CI tests: https://github.com/u-boot/u-boot/pull/493 Signed-off-by: Roger Quadros --- Changes in v2: - Fix build if DM_GPIO not set. - Fix build on platforms that don't define - Link to v1: https://lore.kernel.org/r/20240219-for-2024-07-am65-cpsw-mdio-v1-0-afe9aaba5...@kernel.org --- Roger Quadros (2): net: mdio: Handle bus level GPIO Reset net: am65-cpsw: cpsw_mdio: Switch to proper DM_MDIO framework drivers/net/ti/Kconfig | 8 ++ drivers/net/ti/Makefile | 3 +- drivers/net/ti/am65-cpsw-nuss.c | 190 ++ drivers/net/ti/cpsw_mdio.c | 198 +++- drivers/net/ti/cpsw_mdio.h | 2 + include/phy.h | 7 ++ net/mdio-uclass.c | 37 +++- 7 files changed, 239 insertions(+), 206 deletions(-) --- base-commit: d49fa3defa50c6d3f04acbb52fd486c13c14ab6a change-id: 20240216-for-2024-07-am65-cpsw-mdio-e3c15b297442 Best regards, -- Roger Quadros
Re: [PATCH v5] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc
On 17/02/2024 14:26, MD Danish Anwar wrote:
> Add APIs to set a firmware_name to a rproc and boot the rproc with the
> same firmware.
>
> Clients can call rproc_set_firmware() API to set firmware_name for a rproc
> whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
> a buffer by calling request_firmware_into_buf(). rproc_boot() will then
> load the firmware file to the remote processor and start the remote
> processor.
>
> Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
> Kconfig so that we can call request_firmware_into_buf() from remoteproc
> driver.
>
> Signed-off-by: MD Danish Anwar
> ---
> Changes from v4 to v5:
> *) Added Kconfig option REMOTEPROC_MAX_FW_SIZE to set max firmware size
>that can be loaded to a rproc.
> *) Added freeing of address in rproc_boot() as pointed out by Ravi.
> *) Allocating the address at a later point in rproc_boot()
> *) Rebased on latest u-boot/master [commit
>9e00b6993f724da9699ef12573307afea8c19284]
>
> Changes from v3 to v4:
> *) No functional change. Splitted the patch out of the series as suggested
>by Nishant.
> *) Droppped the RFC tag.
>
> v4: https://lore.kernel.org/all/20240130063322.2345057-1-danishan...@ti.com/
> v3: https://lore.kernel.org/all/20240124064930.1787929-4-danishan...@ti.com/
>
> drivers/remoteproc/Kconfig| 8 +++
> drivers/remoteproc/rproc-uclass.c | 100 ++
> include/remoteproc.h | 34 ++
> 3 files changed, 142 insertions(+)
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 781de530af..759d21437a 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -10,6 +10,7 @@ menu "Remote Processor drivers"
> # All users should depend on DM
> config REMOTEPROC
> bool
> + select FS_LOADER
> depends on DM
>
> # Please keep the configuration alphabetically sorted.
> @@ -102,4 +103,11 @@ config REMOTEPROC_TI_IPU
> help
> Say 'y' here to add support for TI' K3 remoteproc driver.
>
> +config REMOTEPROC_MAX_FW_SIZE
> + hex "Maximum size of firmware that needs to be loaded to rproc"
firmware file?
/rproc/the remote processor
> + default 0x1
> + help
> + Maximum size of the firmware file (elf, binary) that needs to be
> + loaded to th rproc core.
s/th/the
s/rproc/remote processor
> +
> endmenu
> diff --git a/drivers/remoteproc/rproc-uclass.c
> b/drivers/remoteproc/rproc-uclass.c
> index 28b362c887..784361cef9 100644
> --- a/drivers/remoteproc/rproc-uclass.c
> +++ b/drivers/remoteproc/rproc-uclass.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -961,3 +962,102 @@ unsigned long rproc_parse_resource_table(struct udevice
> *dev, struct rproc *cfg)
>
> return 1;
> }
> +
> +int rproc_set_firmware(struct udevice *rproc_dev, const char *fw_name)
> +{
> + struct dm_rproc_uclass_pdata *uc_pdata;
> + int len;
> + char *p;
> +
> + if (!rproc_dev || !fw_name)
> + return -EINVAL;
> +
> + uc_pdata = dev_get_uclass_plat(rproc_dev);
> + if (!uc_pdata)
> + return -EINVAL;
> +
> + len = strcspn(fw_name, "\n");
> + if (!len) {
> + debug("invalid firmware name\n");
> + return -EINVAL;
> + }
> +
> + p = strndup(fw_name, len);
> + if (!p)
> + return -ENOMEM;
Aren't we leaking memory if rproc_set_firmware() is called multiple times?
Can we check if uc_pdata->fw_name exists and free it before the strndup?
> +
> + uc_pdata->fw_name = p;
> +
> + return 0;
> +}
> +
> +int rproc_boot(struct udevice *rproc_dev)
> +{
> + struct dm_rproc_uclass_pdata *uc_pdata;
> + struct udevice *fs_loader;
> + int core_id, ret = 0;
> + char *firmware;
> + void *addr;
> +
> + if (!rproc_dev)
> + return -EINVAL;
> +
> + uc_pdata = dev_get_uclass_plat(rproc_dev);
> + if (!uc_pdata)
> + return -EINVAL;
> +
> + core_id = dev_seq(rproc_dev);
> + firmware = uc_pdata->fw_name;
> +
unnecessary blank line.
> + if (!firmware) {
> + debug("No firmware set for rproc core %d\n", core_id);
No firmware name...
> + return -EINVAL;
> + }
> +
> + /* Initialize all rproc cores */
> + if (!rproc_is_initialized()) {
> + ret = rproc_init();
> + if (ret) {
> + debug("rproc_init() failed: %d\n", ret);
> + return ret;
> + }
> + }
> +
> + /* Loading firmware to a given address */
> + ret = get_fs_loader(_loader);
> + if (ret) {
> + debug("could not get fs loader: %d\n", ret);
> + return ret;
> + }
> +
> + if (CONFIG_REMOTEPROC_MAX_FW_SIZE) {
if (defined(CONFIG_REMOTEPROC_MAX_FW_SIZE)) {
> + addr = malloc(CONFIG_REMOTEPROC_MAX_FW_SIZE);
> +
Re: [PATCH v5] misc: fs-loader: Use fw_storage_interface instead of storage_interface
On 28/02/2024 11:02, MD Danish Anwar wrote: > > On 27/02/24 7:33 pm, Sean Anderson wrote: >> Hi Danish, >> >> On 2/27/24 05:26, MD Danish Anwar wrote: >>> On 09/02/24 3:38 pm, MD Danish Anwar wrote: The fs-loader driver reads env storage_interface and uses it to load firmware file into memory using the medium set by env. Update the driver to use env fw_storage_interface as this variable is only used to load firmwares. This is to keep all variables used by fs-loader driver with 'fw_' prefix. All other variables have 'fw_' prefix except for storage_interface. The env storage_interface will act as fallback so that the existing implementations do not break. Also update the FS Loader documentation accordingly. Signed-off-by: MD Danish Anwar --- >>> >>> Hi Tom / Sean, can you please pick this patch if there is no pending >>> comments to address. >>> >> >> Sorry, I forgot to respond to this earlier. >> >> To be honest, I'm not really convinced. We have plenty of environmental >> variables which are inconsistent (e.g. ethaddr, eth2addr, eth3addr) and it >> doesn't cause any issues. While fixing code has no cost, the environment >> is an ABI which we can't break. So we'd have to support both of these >> variables forever. I'm not really a fan of doing that without good reason, >> and I think aesthetics of the variable name isn't really compelling. >> > > Roger, should I keep the env variable name as it is and don't rename it? > Sean's concern seems valid, can you please comment here. Sure. -- cheers, -roger
Re: [PATCH 1/2] net: mdio: Handle bus level GPIO Reset
On 19/02/2024 17:33, Roger Quadros wrote:
> Some platforms have bus level Reset controlled
> by a GPIO line. If available then handle bus reset
> via GPIO.
>
> Signed-off-by: Roger Quadros
> ---
> include/phy.h | 7 +++
> net/mdio-uclass.c | 37 -
> 2 files changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/include/phy.h b/include/phy.h
> index e02cbdb58c..90a595cae4 100644
> --- a/include/phy.h
> +++ b/include/phy.h
> @@ -9,6 +9,7 @@
> #ifndef _PHY_H
> #define _PHY_H
>
> +#include
azure pipeline failed for some platforms with this error
+In file included from include/net/ncsi.h:8,
+ from cmd/net.c:24:
+include/phy.h:12:10: fatal error: asm/gpio.h: No such file or directory
+ 12 | #include
+ | ^~~~
+compilation terminated.
+make[2]: *** [scripts/Makefile.build:256: cmd/net.o] Error 1
+make[1]: *** [Makefile:1859: cmd] Error 2
+make: *** [Makefile:177: sub-make] Error 2
I'll fix this in v2
> #include
> #include
> #include
> @@ -76,6 +77,12 @@ struct mii_dev {
> int (*reset)(struct mii_dev *bus);
> struct phy_device *phymap[PHY_MAX_ADDR];
> u32 phy_mask;
> + /** @reset_delay_us: Bus GPIO reset pulse width in microseconds */
> + int reset_delay_us;
> + /** @reset_post_delay_us: Bus GPIO reset deassert delay in microseconds
> */
> + int reset_post_delay_us;
> + /** @reset_gpiod: Bus Reset GPIO descriptor pointer */
> + struct gpio_desc reset_gpiod;
> };
>
> /* struct phy_driver: a structure which defines PHY behavior
> diff --git a/net/mdio-uclass.c b/net/mdio-uclass.c
> index e758cc66d7..4500c50430 100644
> --- a/net/mdio-uclass.c
> +++ b/net/mdio-uclass.c
> @@ -14,6 +14,9 @@
> #include
> #include
> #include
> +#include
> +
> +#define DEFAULT_GPIO_RESET_DELAY 10 /* in microseconds */
>
> void dm_mdio_probe_devices(void)
> {
> @@ -80,6 +83,16 @@ int dm_mdio_write(struct udevice *mdio_dev, int addr, int
> devad, int reg,
> int dm_mdio_reset(struct udevice *mdio_dev)
> {
> struct mdio_ops *ops = mdio_get_ops(mdio_dev);
> + struct mdio_perdev_priv *pdata = dev_get_uclass_priv(mdio_dev);
> + struct mii_dev *mii_bus = pdata->mii_bus;
> +
> + if (dm_gpio_is_valid(_bus->reset_gpiod)) {
> + dm_gpio_set_value(_bus->reset_gpiod, 1);
> + udelay(mii_bus->reset_delay_us);
> + dm_gpio_set_value(_bus->reset_gpiod, 0);
> + if (mii_bus->reset_post_delay_us > 0)
> + udelay(mii_bus->reset_post_delay_us);
> + }
>
> if (!ops->reset)
> return 0;
> @@ -111,14 +124,36 @@ static int mdio_reset(struct mii_dev *mii_bus)
> static int dm_mdio_post_probe(struct udevice *dev)
> {
> struct mdio_perdev_priv *pdata = dev_get_uclass_priv(dev);
> + struct mii_dev *mii_bus;
> + int ret;
>
> - pdata->mii_bus = mdio_alloc();
> + mii_bus = mdio_alloc();
> + if (!mii_bus) {
> + dev_err(dev, "couldn't allocate mii_bus\n");
> + return -ENOMEM;
> + }
> + pdata->mii_bus = mii_bus;
> pdata->mii_bus->read = mdio_read;
> pdata->mii_bus->write = mdio_write;
> pdata->mii_bus->reset = mdio_reset;
> pdata->mii_bus->priv = dev;
> strlcpy(pdata->mii_bus->name, dev->name, MDIO_NAME_LEN);
>
> + if (IS_ENABLED(CONFIG_DM_GPIO)) {
> + /* Get bus level PHY reset GPIO details */
> + mii_bus->reset_delay_us = dev_read_u32_default(dev,
> "reset-delay-us",
> +
> DEFAULT_GPIO_RESET_DELAY);
> + mii_bus->reset_post_delay_us = dev_read_u32_default(dev,
> +
> "reset-post-delay-us",
> + 0);
> + ret = gpio_request_by_name(dev, "reset-gpios", 0,
> _bus->reset_gpiod,
> +GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
> + if (ret && ret != -ENOENT) {
> + dev_err(dev, "couldn't get reset-gpios: %d\n", ret);
> + return ret;
> + }
> + }
> +
> return mdio_register(pdata->mii_bus);
> }
>
>
--
cheers,
-roger
Re: [PATCH 1/2] net: mdio: Handle bus level GPIO Reset
On 22/02/2024 08:59, Ravi Gunasekaran wrote:
>
>
> On 2/19/24 9:03 PM, Roger Quadros wrote:
>> Some platforms have bus level Reset controlled
>> by a GPIO line. If available then handle bus reset
>> via GPIO.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> include/phy.h | 7 +++
>> net/mdio-uclass.c | 37 -
>> 2 files changed, 43 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/phy.h b/include/phy.h
>> index e02cbdb58c..90a595cae4 100644
>> --- a/include/phy.h
>> +++ b/include/phy.h
>> @@ -9,6 +9,7 @@
>> #ifndef _PHY_H
>> #define _PHY_H
>>
>> +#include
>> #include
>> #include
>> #include
>> @@ -76,6 +77,12 @@ struct mii_dev {
>> int (*reset)(struct mii_dev *bus);
>> struct phy_device *phymap[PHY_MAX_ADDR];
>> u32 phy_mask;
>> +/** @reset_delay_us: Bus GPIO reset pulse width in microseconds */
>> +int reset_delay_us;
>> +/** @reset_post_delay_us: Bus GPIO reset deassert delay in microseconds
>> */
>> +int reset_post_delay_us;
>> +/** @reset_gpiod: Bus Reset GPIO descriptor pointer */
>> +struct gpio_desc reset_gpiod;
>> };
>>
>> /* struct phy_driver: a structure which defines PHY behavior
>> diff --git a/net/mdio-uclass.c b/net/mdio-uclass.c
>> index e758cc66d7..4500c50430 100644
>> --- a/net/mdio-uclass.c
>> +++ b/net/mdio-uclass.c
>> @@ -14,6 +14,9 @@
>> #include
>> #include
>> #include
>> +#include
>> +
>> +#define DEFAULT_GPIO_RESET_DELAY10 /* in microseconds */
>>
>> void dm_mdio_probe_devices(void)
>> {
>> @@ -80,6 +83,16 @@ int dm_mdio_write(struct udevice *mdio_dev, int addr, int
>> devad, int reg,
>> int dm_mdio_reset(struct udevice *mdio_dev)
>> {
>> struct mdio_ops *ops = mdio_get_ops(mdio_dev);
>> +struct mdio_perdev_priv *pdata = dev_get_uclass_priv(mdio_dev);
>> +struct mii_dev *mii_bus = pdata->mii_bus;
>> +
>> +if (dm_gpio_is_valid(_bus->reset_gpiod)) {
>> +dm_gpio_set_value(_bus->reset_gpiod, 1);
>
> undefined reference to `dm_gpio_set_value'
> Build fails for configs that don't have CONFIG_DM_GPIO defined.
>
> We can have this under "if (IS_ENABLED(CONFIG_DM_GPIO))"
Thanks. I'll check this.
>
>> +udelay(mii_bus->reset_delay_us);
>> +dm_gpio_set_value(_bus->reset_gpiod, 0);
>> +if (mii_bus->reset_post_delay_us > 0)
>> +udelay(mii_bus->reset_post_delay_us);
>> +}
>>
>> if (!ops->reset)
>> return 0;
>> @@ -111,14 +124,36 @@ static int mdio_reset(struct mii_dev *mii_bus)
>> static int dm_mdio_post_probe(struct udevice *dev)
>> {
>> struct mdio_perdev_priv *pdata = dev_get_uclass_priv(dev);
>> +struct mii_dev *mii_bus;
>> +int ret;
>>
>> -pdata->mii_bus = mdio_alloc();
>> +mii_bus = mdio_alloc();
>> +if (!mii_bus) {
>> +dev_err(dev, "couldn't allocate mii_bus\n");
>> +return -ENOMEM;
>> +}
>> +pdata->mii_bus = mii_bus;
>> pdata->mii_bus->read = mdio_read;
>> pdata->mii_bus->write = mdio_write;
>> pdata->mii_bus->reset = mdio_reset;
>> pdata->mii_bus->priv = dev;
>> strlcpy(pdata->mii_bus->name, dev->name, MDIO_NAME_LEN);
>>
>> +if (IS_ENABLED(CONFIG_DM_GPIO)) {
>> +/* Get bus level PHY reset GPIO details */
>> +mii_bus->reset_delay_us = dev_read_u32_default(dev,
>> "reset-delay-us",
>> +
>> DEFAULT_GPIO_RESET_DELAY);
>> +mii_bus->reset_post_delay_us = dev_read_u32_default(dev,
>> +
>> "reset-post-delay-us",
>> +0);
>> +ret = gpio_request_by_name(dev, "reset-gpios", 0,
>> _bus->reset_gpiod,
>> + GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
>> +if (ret && ret != -ENOENT) {
>> +dev_err(dev, "couldn't get reset-gpios: %d\n", ret);
>> +return ret;
>> +}
>> +}
>> +
>> return mdio_register(pdata->mii_bus);
>> }
>>
>>
>
--
cheers,
-roger
[PATCH 2/2] net: am65-cpsw: cpsw_mdio: Switch to proper DM_MDIO framework
Add a new Kconfig symbol MDIO_TI_CPSW for the CPSW MDIO
driver and build it with proper DM support if enabled.
If MDIO_TI_CPSW is not enabled then we continue to
behave like before.
Clean up MDIO custom handling in am65-cpsw and use
dm_eth_phy_connect() to get the PHY.
Signed-off-by: Roger Quadros
---
drivers/net/ti/Kconfig | 8 ++
drivers/net/ti/Makefile | 3 +-
drivers/net/ti/am65-cpsw-nuss.c | 190 ++
drivers/net/ti/cpsw_mdio.c | 198 +++-
drivers/net/ti/cpsw_mdio.h | 2 +
5 files changed, 196 insertions(+), 205 deletions(-)
diff --git a/drivers/net/ti/Kconfig b/drivers/net/ti/Kconfig
index c75f418628..72eccc99e5 100644
--- a/drivers/net/ti/Kconfig
+++ b/drivers/net/ti/Kconfig
@@ -45,7 +45,15 @@ config TI_AM65_CPSW_NUSS
imply MISC_INIT_R
imply MISC
imply SYSCON
+ imply MDIO_TI_CPSW
select PHYLIB
help
This driver supports TI K3 MCU CPSW Nuss Ethernet controller
in Texas Instruments K3 AM65x SoCs.
+
+config MDIO_TI_CPSW
+ bool "TI CPSW MDIO interface support"
+ depends on DM_MDIO
+ help
+ This driver supports the TI CPSW MDIO interface found in various
+ TI SoCs.
diff --git a/drivers/net/ti/Makefile b/drivers/net/ti/Makefile
index 0ce0cf2828..30c4c4b6d5 100644
--- a/drivers/net/ti/Makefile
+++ b/drivers/net/ti/Makefile
@@ -5,4 +5,5 @@
obj-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o cpsw-common.o cpsw_mdio.o
obj-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o
obj-$(CONFIG_DRIVER_TI_KEYSTONE_NET) += keystone_net.o cpsw_mdio.o
-obj-$(CONFIG_TI_AM65_CPSW_NUSS) += am65-cpsw-nuss.o cpsw_mdio.o
+obj-$(CONFIG_TI_AM65_CPSW_NUSS) += am65-cpsw-nuss.o
+obj-$(CONFIG_MDIO_TI_CPSW) += cpsw_mdio.o
diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 6da018c0f9..d68ed67183 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -31,8 +31,6 @@
#include
#include
-#include "cpsw_mdio.h"
-
#define AM65_CPSW_CPSWNU_MAX_PORTS 9
#define AM65_CPSW_SS_BASE 0x0
@@ -113,7 +111,6 @@ struct am65_cpsw_common {
struct udevice *dev;
fdt_addr_t ss_base;
fdt_addr_t cpsw_base;
- fdt_addr_t mdio_base;
fdt_addr_t ale_base;
struct clk fclk;
@@ -122,13 +119,8 @@ struct am65_cpsw_common {
u32 port_num;
struct am65_cpsw_port ports[AM65_CPSW_CPSWNU_MAX_PORTS];
- 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;
@@ -140,13 +132,7 @@ struct am65_cpsw_priv {
struct udevice *dev;
struct am65_cpsw_common *cpsw_common;
u32 port_id;
-
struct phy_device *phydev;
- boolhas_phy;
- ofnode phy_node;
- u32 phy_addr;
-
- boolmdio_manual_mode;
};
#ifdef PKTSIZE_ALIGN
@@ -622,111 +608,15 @@ static const struct eth_ops am65_cpsw_ops = {
.read_rom_hwaddr = am65_cpsw_read_rom_hwaddr,
};
-static const struct soc_attr k3_mdio_soc_data[] = {
- { .family = "AM62X", .revision = "SR1.0" },
- { .family = "AM64X", .revision = "SR1.0" },
- { .family = "AM64X", .revision = "SR2.0" },
- { .family = "AM65X", .revision = "SR1.0" },
- { .family = "AM65X", .revision = "SR2.0" },
- { .family = "J7200", .revision = "SR1.0" },
- { .family = "J7200", .revision = "SR2.0" },
- { .family = "J721E", .revision = "SR1.0" },
- { .family = "J721E", .revision = "SR1.1" },
- { .family = "J721S2", .revision = "SR1.0" },
- { /* 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;
[PATCH 1/2] net: mdio: Handle bus level GPIO Reset
Some platforms have bus level Reset controlled
by a GPIO line. If available then handle bus reset
via GPIO.
Signed-off-by: Roger Quadros
---
include/phy.h | 7 +++
net/mdio-uclass.c | 37 -
2 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/include/phy.h b/include/phy.h
index e02cbdb58c..90a595cae4 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -9,6 +9,7 @@
#ifndef _PHY_H
#define _PHY_H
+#include
#include
#include
#include
@@ -76,6 +77,12 @@ struct mii_dev {
int (*reset)(struct mii_dev *bus);
struct phy_device *phymap[PHY_MAX_ADDR];
u32 phy_mask;
+ /** @reset_delay_us: Bus GPIO reset pulse width in microseconds */
+ int reset_delay_us;
+ /** @reset_post_delay_us: Bus GPIO reset deassert delay in microseconds
*/
+ int reset_post_delay_us;
+ /** @reset_gpiod: Bus Reset GPIO descriptor pointer */
+ struct gpio_desc reset_gpiod;
};
/* struct phy_driver: a structure which defines PHY behavior
diff --git a/net/mdio-uclass.c b/net/mdio-uclass.c
index e758cc66d7..4500c50430 100644
--- a/net/mdio-uclass.c
+++ b/net/mdio-uclass.c
@@ -14,6 +14,9 @@
#include
#include
#include
+#include
+
+#define DEFAULT_GPIO_RESET_DELAY 10 /* in microseconds */
void dm_mdio_probe_devices(void)
{
@@ -80,6 +83,16 @@ int dm_mdio_write(struct udevice *mdio_dev, int addr, int
devad, int reg,
int dm_mdio_reset(struct udevice *mdio_dev)
{
struct mdio_ops *ops = mdio_get_ops(mdio_dev);
+ struct mdio_perdev_priv *pdata = dev_get_uclass_priv(mdio_dev);
+ struct mii_dev *mii_bus = pdata->mii_bus;
+
+ if (dm_gpio_is_valid(_bus->reset_gpiod)) {
+ dm_gpio_set_value(_bus->reset_gpiod, 1);
+ udelay(mii_bus->reset_delay_us);
+ dm_gpio_set_value(_bus->reset_gpiod, 0);
+ if (mii_bus->reset_post_delay_us > 0)
+ udelay(mii_bus->reset_post_delay_us);
+ }
if (!ops->reset)
return 0;
@@ -111,14 +124,36 @@ static int mdio_reset(struct mii_dev *mii_bus)
static int dm_mdio_post_probe(struct udevice *dev)
{
struct mdio_perdev_priv *pdata = dev_get_uclass_priv(dev);
+ struct mii_dev *mii_bus;
+ int ret;
- pdata->mii_bus = mdio_alloc();
+ mii_bus = mdio_alloc();
+ if (!mii_bus) {
+ dev_err(dev, "couldn't allocate mii_bus\n");
+ return -ENOMEM;
+ }
+ pdata->mii_bus = mii_bus;
pdata->mii_bus->read = mdio_read;
pdata->mii_bus->write = mdio_write;
pdata->mii_bus->reset = mdio_reset;
pdata->mii_bus->priv = dev;
strlcpy(pdata->mii_bus->name, dev->name, MDIO_NAME_LEN);
+ if (IS_ENABLED(CONFIG_DM_GPIO)) {
+ /* Get bus level PHY reset GPIO details */
+ mii_bus->reset_delay_us = dev_read_u32_default(dev,
"reset-delay-us",
+
DEFAULT_GPIO_RESET_DELAY);
+ mii_bus->reset_post_delay_us = dev_read_u32_default(dev,
+
"reset-post-delay-us",
+ 0);
+ ret = gpio_request_by_name(dev, "reset-gpios", 0,
_bus->reset_gpiod,
+ GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
+ if (ret && ret != -ENOENT) {
+ dev_err(dev, "couldn't get reset-gpios: %d\n", ret);
+ return ret;
+ }
+ }
+
return mdio_register(pdata->mii_bus);
}
--
2.34.1
[PATCH 0/2] net: ti: am65-cpsw / cpsw-mdio: Switch to DM MDIO
Hi, This converts cpsw-mdio into a proper Driver Model driver and introduces the new Config symbol CONFIG_MDIO_TI_CPSW. It also cleans up the am65-cpsw driver so it porperly uses the DM PHY interface. It does not convert the legacy cpsw and keystone-net drivers. Tested on AM64-EVM and AM335x BeagleBone. AM64-EVM network doesn't work at 1G but only at 100M. This limitation exists prior to this patch. CI tests: https://github.com/u-boot/u-boot/pull/491 Signed-off-by: Roger Quadros --- Roger Quadros (2): net: mdio: Handle bus level GPIO Reset net: am65-cpsw: cpsw_mdio: Switch to proper DM_MDIO framework drivers/net/ti/Kconfig | 8 ++ drivers/net/ti/Makefile | 3 +- drivers/net/ti/am65-cpsw-nuss.c | 190 ++ drivers/net/ti/cpsw_mdio.c | 198 +++- drivers/net/ti/cpsw_mdio.h | 2 + include/phy.h | 7 ++ net/mdio-uclass.c | 37 +++- 7 files changed, 239 insertions(+), 206 deletions(-) --- base-commit: e4013bcb10f604ec1dfe955634d57e1fc336b15f change-id: 20240216-for-2024-07-am65-cpsw-mdio-e3c15b297442 Best regards, -- Roger Quadros
Re: [PATCH v4] misc: fs-loader: Use fw_storage_interface instead of storage_interface
On 08/02/2024 07:19, MD Danish Anwar wrote: > Hi Sean, > > On 07/02/24 11:14 pm, Sean Anderson wrote: >> On 1/30/24 01:26, MD Danish Anwar wrote: >>> The fs-loader driver reads env storage_interface and uses it to load >>> firmware file into memory using the medium set by env. Update the driver >>> to use env fw_storage_interface as this variable is only used to load >>> firmwares. The env storage_interface will act as fallback so that the >>> existing implementations do not break. >>> >>> Also update the FS Loader documentation accordingly. >> >> So why do you want to do this? I don't see what the point of renaming the >> variable is, since you are not e.g. adding any new functionality, and we >> have to pay for the rename in code size. >> > > I am upstreaming TI's ICSSG driver for u-boot and during code review > Roger Quadros commented asking to rename this > variable [1]. I think the motive here was to keep all variables used by > fs-loader driver with 'fw_' prefix. All other variables had 'fw_' prefix > except for storage_interface. Can you please mention this motive in the Commit message? > > [1] > https://lore.kernel.org/all/4721f3b9-f823-47f3-b4f3-ed40002af...@kernel.org/ > >> --Sean > -- cheers, -roger
Re: [PATCH v4] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc
On 07/02/2024 09:15, MD Danish Anwar wrote:
> Hi Roger
>
> On 06/02/24 7:11 pm, Roger Quadros wrote:
>>
>>
>> On 06/02/2024 07:31, MD Danish Anwar wrote:
>>>
>>>
>>> On 05/02/24 6:07 pm, Roger Quadros wrote:
>>>>
>>>>
>>>> On 05/02/2024 12:20, MD Danish Anwar wrote:
>>>>>
>>>>>
>>>>> On 05/02/24 3:36 pm, Roger Quadros wrote:
>>>>>>
>>>>>>
>>>>>> On 02/02/2024 18:40, Anwar, Md Danish wrote:
>>>>>>> Hi Roger,
>>>>>>>
>>>>>>> On 2/2/2024 4:49 PM, Roger Quadros wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 30/01/2024 08:33, MD Danish Anwar wrote:
>>>>>>>>> Add APIs to set a firmware_name to a rproc and boot the rproc with the
>>>>>>>>> same firmware.
>>>>>>>>>
>>>
>>>
>>>
>>>>>>>
>>>>>>>> How does caller know what firmware size to set to?
>>>>>>>> This should already be private to the rproc as it knows
>>>>>>>> how large is its program memory.
>>>>>>>>
>>>>>>>
>>>>>>> Caller is trying to boot the rproc with a firmware binary. Caller should
>>>>>>> know the size of binary that it wants to load to rproc core. Caller will
>>>>>>> specify the binary size to rproc_boot(). Based on the size provided by
>>>>>>> caller, rproc_boot() will then allocate that much memory and call
>>>>>>> request_firmware_into_buf() with the size and allocated buffer. If the
>>>>>>> caller doesn't provide minimum size rproc_load() will fail.
>>>>>>
>>>>>> Caller only knows the filename. It need not know more details.
>>>>>
>>>>> Caller is trying to load a file of it's choice to a rproc. Caller should
>>>>> know the size of file it is trying to load or atleast the max size that
>>>>> the firmware file could be of.
>>>>>
>>>>>
>>>>>> Also see my comment below about rproc_boot() API.
>>>>>>
>>>>>>>
>>>>>>> rproc_load() calls respective driver ops, for example: pru_load().
>>>>>>> pru_load() [1] API checks the required size of firmware to load by
>>>>>>> casting the buffer into Elf32_Ehdr and Elf32_Phdr and returns error if
>>>>>>> size provided by caller is less than this.
>>>>>>>
>>>>>>>
>>>>>>> if (offset + filesz > size) {
>>>>>>> dev_dbg(dev, "truncated fw: need 0x%x avail 0x%zx\n",
>>>>>>> offset + filesz, size);
>>>>>>> ret = -EINVAL;
>>>>>>> break;
>>>>>>> }
>>>>>>>
>>>>>>>>> + *
>>>>>>>>> + * Boot a remote processor (i.e. load its firmware, power it on,
>>>>>>>>> ...).
>>>>>>>>> + *
>>>>>>>>> + * This function first loads the firmware set in the uclass pdata of
>>>>>>>>> Remote
>>>>>>>>> + * processor to a buffer and then loads firmware to the remote
>>>>>>>>> processor
>>>>>>>>> + * using rproc_load().
>>>>>>>>> + *
>>>>>>>>> + * Return: 0 on success, and an appropriate error value otherwise
>>>>>>>>> + */
>>>>>>>>> +int rproc_boot(struct udevice *rproc_dev, size_t fw_size);
>>>>>>>>
>>>>>>>> Was wondering if you need separate API for rproc_set_firmware or we
>>>>>>>> can just
>>>>>>>> pass firmware name as argument to rproc_boot()?
>>>>>>>>
>>>>>>>
>>>>>>> Technically we can. But when we discussed this approach first in v1, you
>>>>>>> had asked to keep the APIs similar to upstream linux. Upstream linux has
>>>>>>> these two APIs so I kept it that way. If you want I can drop the first
>>>>>>> API. Please let me
[PATCH] memory: ti-gpmc: Fix lock up at A53 SPL during NAND boot on AM64-EVM
AM64 ES2.0 bootrom seems to enable WAIT0EDGEDETECTION interrupt. This causes a lockup at A53 SPL when accessing NAND controller or ELM registers. A good option would be to softrest GPMC block at probe but this cannot be done for AM64 as SOFTRESET bit is marked as reserved in SYSCONFIG register. Fix the issue by disabling all IRQs at probe. Signed-off-by: Roger Quadros --- drivers/memory/ti-gpmc.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/memory/ti-gpmc.c b/drivers/memory/ti-gpmc.c index 0b8674339e..8877b8f438 100644 --- a/drivers/memory/ti-gpmc.c +++ b/drivers/memory/ti-gpmc.c @@ -1196,6 +1196,12 @@ static int gpmc_probe(struct udevice *dev) gpmc_cfg = (struct gpmc *)priv->base; gpmc_base = priv->base; + /* +* Disable all IRQs as some bootroms might leave them enabled +* and that will cause a lock-up later +*/ + gpmc_write_reg(GPMC_IRQENABLE, 0); + priv->l3_clk = devm_clk_get(dev, "fck"); if (IS_ERR(priv->l3_clk)) return PTR_ERR(priv->l3_clk); base-commit: 28760ce8640ff6266bd1c1c568a4a231576f3919 -- 2.34.1
Re: [PATCH v4] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc
On 06/02/2024 07:31, MD Danish Anwar wrote:
>
>
> On 05/02/24 6:07 pm, Roger Quadros wrote:
>>
>>
>> On 05/02/2024 12:20, MD Danish Anwar wrote:
>>>
>>>
>>> On 05/02/24 3:36 pm, Roger Quadros wrote:
>>>>
>>>>
>>>> On 02/02/2024 18:40, Anwar, Md Danish wrote:
>>>>> Hi Roger,
>>>>>
>>>>> On 2/2/2024 4:49 PM, Roger Quadros wrote:
>>>>>>
>>>>>>
>>>>>> On 30/01/2024 08:33, MD Danish Anwar wrote:
>>>>>>> Add APIs to set a firmware_name to a rproc and boot the rproc with the
>>>>>>> same firmware.
>>>>>>>
>
>
>
>>>>>
>>>>>> How does caller know what firmware size to set to?
>>>>>> This should already be private to the rproc as it knows
>>>>>> how large is its program memory.
>>>>>>
>>>>>
>>>>> Caller is trying to boot the rproc with a firmware binary. Caller should
>>>>> know the size of binary that it wants to load to rproc core. Caller will
>>>>> specify the binary size to rproc_boot(). Based on the size provided by
>>>>> caller, rproc_boot() will then allocate that much memory and call
>>>>> request_firmware_into_buf() with the size and allocated buffer. If the
>>>>> caller doesn't provide minimum size rproc_load() will fail.
>>>>
>>>> Caller only knows the filename. It need not know more details.
>>>
>>> Caller is trying to load a file of it's choice to a rproc. Caller should
>>> know the size of file it is trying to load or atleast the max size that
>>> the firmware file could be of.
>>>
>>>
>>>> Also see my comment below about rproc_boot() API.
>>>>
>>>>>
>>>>> rproc_load() calls respective driver ops, for example: pru_load().
>>>>> pru_load() [1] API checks the required size of firmware to load by
>>>>> casting the buffer into Elf32_Ehdr and Elf32_Phdr and returns error if
>>>>> size provided by caller is less than this.
>>>>>
>>>>>
>>>>> if (offset + filesz > size) {
>>>>> dev_dbg(dev, "truncated fw: need 0x%x avail 0x%zx\n",
>>>>> offset + filesz, size);
>>>>> ret = -EINVAL;
>>>>> break;
>>>>> }
>>>>>
>>>>>>> + *
>>>>>>> + * Boot a remote processor (i.e. load its firmware, power it on, ...).
>>>>>>> + *
>>>>>>> + * This function first loads the firmware set in the uclass pdata of
>>>>>>> Remote
>>>>>>> + * processor to a buffer and then loads firmware to the remote
>>>>>>> processor
>>>>>>> + * using rproc_load().
>>>>>>> + *
>>>>>>> + * Return: 0 on success, and an appropriate error value otherwise
>>>>>>> + */
>>>>>>> +int rproc_boot(struct udevice *rproc_dev, size_t fw_size);
>>>>>>
>>>>>> Was wondering if you need separate API for rproc_set_firmware or we can
>>>>>> just
>>>>>> pass firmware name as argument to rproc_boot()?
>>>>>>
>>>>>
>>>>> Technically we can. But when we discussed this approach first in v1, you
>>>>> had asked to keep the APIs similar to upstream linux. Upstream linux has
>>>>> these two APIs so I kept it that way. If you want I can drop the first
>>>>> API. Please let me know.
>>>>
>>>> Sure you can keep it as it is in Linux, but there, rproc_boot doesn't
>>>> take fw_size argument. So wondering why you should have it in u-boot.
>>>>
>>>
>>> For loading firmware to a rproc core in u-boot, it's first neccassry to
>>> load the firmware into buffer and then load that buffer into rproc core
>>> using rproc_load() API. Now to load the firmware to a buffer ther is an
>>> API request_firmware_into_buf(). This API takes size of firmware as one
>>> of it's argument. So in order to call this API from rproc_boot() we need
>>> to pass fw_size to rproc_boot()
>>>
>>> Other u-boot drivers using request_firmware_into_buf() are also passing
>>> size of firmware from their driver.
>>
>> But in your driver you di
Re: [PATCH v4] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc
On 05/02/2024 12:20, MD Danish Anwar wrote:
>
>
> On 05/02/24 3:36 pm, Roger Quadros wrote:
>>
>>
>> On 02/02/2024 18:40, Anwar, Md Danish wrote:
>>> Hi Roger,
>>>
>>> On 2/2/2024 4:49 PM, Roger Quadros wrote:
>>>>
>>>>
>>>> On 30/01/2024 08:33, MD Danish Anwar wrote:
>>>>> Add APIs to set a firmware_name to a rproc and boot the rproc with the
>>>>> same firmware.
>>>>>
>>>>> Clients can call rproc_set_firmware() API to set firmware_name for a rproc
>>>>> whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
>>>>> a buffer by calling request_firmware_into_buf(). rproc_boot() will then
>>>>> load the firmware file to the remote processor and start the remote
>>>>> processor.
>>>>>
>>>>> Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
>>>>> Kconfig so that we can call request_firmware_into_buf() from remoteproc
>>>>> driver.
>>>>>
>>>>> Signed-off-by: MD Danish Anwar
>>>>> ---
>>>>> Changes from v3 to v4:
>>>>> *) No functional change. Splitted the patch out of the series as suggested
>>>>>by Nishant.
>>>>> *) Droppped the RFC tag.
>>>>>
>>>>> v3:
>>>>> https://lore.kernel.org/all/20240124064930.1787929-4-danishan...@ti.com/
>>>>>
>>>>> drivers/remoteproc/Kconfig| 1 +
>>>>> drivers/remoteproc/rproc-uclass.c | 85 +++
>>>>> include/remoteproc.h | 35 +
>>>>> 3 files changed, 121 insertions(+)
>>>>>
>>>>> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
>>>>> index 781de530af..0fdf1b38ea 100644
>>>>> --- a/drivers/remoteproc/Kconfig
>>>>> +++ b/drivers/remoteproc/Kconfig
>>>>> @@ -10,6 +10,7 @@ menu "Remote Processor drivers"
>>>>> # All users should depend on DM
>>>>> config REMOTEPROC
>>>>> bool
>>>>> + select FS_LOADER
>>>>> depends on DM
>>>>>
>>>>> # Please keep the configuration alphabetically sorted.
>>>>> diff --git a/drivers/remoteproc/rproc-uclass.c
>>>>> b/drivers/remoteproc/rproc-uclass.c
>>>>> index 28b362c887..76db4157f7 100644
>>>>> --- a/drivers/remoteproc/rproc-uclass.c
>>>>> +++ b/drivers/remoteproc/rproc-uclass.c
>>>>> @@ -13,6 +13,7 @@
>>>>> #include
>>>>> #include
>>>>> #include
>>>>> +#include
>>>>> #include
>>>>> #include
>>>>> #include
>>>>> @@ -961,3 +962,87 @@ unsigned long rproc_parse_resource_table(struct
>>>>> udevice *dev, struct rproc *cfg)
>>>>>
>>>>> return 1;
>>>>> }
>>>>> +
>>>>> +int rproc_set_firmware(struct udevice *rproc_dev, const char *fw_name)
>>>>> +{
>>>>> + struct dm_rproc_uclass_pdata *uc_pdata;
>>>>> + int len;
>>>>> + char *p;
>>>>> +
>>>>> + if (!rproc_dev || !fw_name)
>>>>> + return -EINVAL;
>>>>> +
>>>>> + uc_pdata = dev_get_uclass_plat(rproc_dev);
>>>>
>>>> This can return NULL and you shuould error out if it does.
>>>>
>>>
>>> Sure.
>>>
>>>>> +
>>>>> + len = strcspn(fw_name, "\n");
>>>>> + if (!len) {
>>>>> + debug("can't provide empty string for firmware name\n");
>>>>
>>>> how about "invalid filename" ?
>>>>
>>>
>>> Sure.
>>>
>>>>> + return -EINVAL;
>>>>> + }
>>>>> +
>>>>> + p = strndup(fw_name, len);
>>>>> + if (!p)
>>>>> + return -ENOMEM;
>>>>> +
>>>>> + uc_pdata->fw_name = p;
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> +int rproc_boot(struct udevice *rproc_dev, size_t fw_size)
>>>>> +{
>>>>> + struct dm_rproc_uclass_pdata *uc_pdata;
>>>>> + struct udevice *fs_loader;
>
Re: [PATCH v4] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc
On 02/02/2024 18:40, Anwar, Md Danish wrote:
> Hi Roger,
>
> On 2/2/2024 4:49 PM, Roger Quadros wrote:
>>
>>
>> On 30/01/2024 08:33, MD Danish Anwar wrote:
>>> Add APIs to set a firmware_name to a rproc and boot the rproc with the
>>> same firmware.
>>>
>>> Clients can call rproc_set_firmware() API to set firmware_name for a rproc
>>> whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
>>> a buffer by calling request_firmware_into_buf(). rproc_boot() will then
>>> load the firmware file to the remote processor and start the remote
>>> processor.
>>>
>>> Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
>>> Kconfig so that we can call request_firmware_into_buf() from remoteproc
>>> driver.
>>>
>>> Signed-off-by: MD Danish Anwar
>>> ---
>>> Changes from v3 to v4:
>>> *) No functional change. Splitted the patch out of the series as suggested
>>>by Nishant.
>>> *) Droppped the RFC tag.
>>>
>>> v3: https://lore.kernel.org/all/20240124064930.1787929-4-danishan...@ti.com/
>>>
>>> drivers/remoteproc/Kconfig| 1 +
>>> drivers/remoteproc/rproc-uclass.c | 85 +++
>>> include/remoteproc.h | 35 +
>>> 3 files changed, 121 insertions(+)
>>>
>>> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
>>> index 781de530af..0fdf1b38ea 100644
>>> --- a/drivers/remoteproc/Kconfig
>>> +++ b/drivers/remoteproc/Kconfig
>>> @@ -10,6 +10,7 @@ menu "Remote Processor drivers"
>>> # All users should depend on DM
>>> config REMOTEPROC
>>> bool
>>> + select FS_LOADER
>>> depends on DM
>>>
>>> # Please keep the configuration alphabetically sorted.
>>> diff --git a/drivers/remoteproc/rproc-uclass.c
>>> b/drivers/remoteproc/rproc-uclass.c
>>> index 28b362c887..76db4157f7 100644
>>> --- a/drivers/remoteproc/rproc-uclass.c
>>> +++ b/drivers/remoteproc/rproc-uclass.c
>>> @@ -13,6 +13,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -961,3 +962,87 @@ unsigned long rproc_parse_resource_table(struct
>>> udevice *dev, struct rproc *cfg)
>>>
>>> return 1;
>>> }
>>> +
>>> +int rproc_set_firmware(struct udevice *rproc_dev, const char *fw_name)
>>> +{
>>> + struct dm_rproc_uclass_pdata *uc_pdata;
>>> + int len;
>>> + char *p;
>>> +
>>> + if (!rproc_dev || !fw_name)
>>> + return -EINVAL;
>>> +
>>> + uc_pdata = dev_get_uclass_plat(rproc_dev);
>>
>> This can return NULL and you shuould error out if it does.
>>
>
> Sure.
>
>>> +
>>> + len = strcspn(fw_name, "\n");
>>> + if (!len) {
>>> + debug("can't provide empty string for firmware name\n");
>>
>> how about "invalid filename" ?
>>
>
> Sure.
>
>>> + return -EINVAL;
>>> + }
>>> +
>>> + p = strndup(fw_name, len);
>>> + if (!p)
>>> + return -ENOMEM;
>>> +
>>> + uc_pdata->fw_name = p;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +int rproc_boot(struct udevice *rproc_dev, size_t fw_size)
>>> +{
>>> + struct dm_rproc_uclass_pdata *uc_pdata;
>>> + struct udevice *fs_loader;
>>> + void *addr = malloc(fw_size);
>>
>> I will suggest to do malloc just before you need the buffer.
>> You need to free up the buffer an all return paths after that.
>>
>
> That is correct. I will do malloc just before calling
> request_firmware_into_buf() API.
>
>>> + int core_id, ret = 0;
>>> + char *firmware;
>>> + ulong rproc_addr;
>>
>> do you really need rproc_addr? You could use addr itself.
>>
>
> Sure.
>
>>> +
>>> + if (!rproc_dev)
>>> + return -EINVAL;
>>> +
>>> + if (!addr)
>>> + return -ENOMEM;
>>> +
>>> + uc_pdata = dev_get_uclass_plat(rproc_dev);
>>> + core_id = dev_seq(rproc_dev);
>>> + firmware = uc_pdata->fw_name;
>>> +
>>> + if (!firmware) {
>>> + d
Re: [PATCH v2 1/1] net: ti: am65-cpsw-nuss: Remove incorrect RGMII_ID bit functionality
On 01/02/2024 22:17, Ken Sloat wrote: > The CPSW implementations on the AM6x platforms do not support the > selectable RGMII TX clk delay functionality via the RGMII_ID_MODE bit as > the earlier platforms did. While it is possible to write the bit, > according to various TI AM6x datasheets, reference manuals, hardware > design guides and TI forum posts from TI, this bit is "not timed, tested > or characterized. RGMII_ID is enabled by default." > > The driver implementation today however, will incorrectly set this bit > whenever the interface mode is in RGMII_ID or RGMII_TXID. Since > disabling the delay (bit=1) is not supported by TI, this bit should > always be written as 0. > > See: > https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1211306/am625-enet1_ctrl_rgmii_id-_mode > https://www.ti.com/lit/pdf/spruiv7 (Rev. B Figure 14-1717) > https://www.ti.com/lit/gpn/am625 (Rev. B Figure 7-31 Note A) > https://www.ti.com/lit/an/sprad05b/sprad05b.pdf (Rev. B Section 7.4) > > Signed-off-by: Ken Sloat Reviewed-by: Roger Quadros
Re: [PATCH v4] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc
On 30/01/2024 08:33, MD Danish Anwar wrote:
> Add APIs to set a firmware_name to a rproc and boot the rproc with the
> same firmware.
>
> Clients can call rproc_set_firmware() API to set firmware_name for a rproc
> whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
> a buffer by calling request_firmware_into_buf(). rproc_boot() will then
> load the firmware file to the remote processor and start the remote
> processor.
>
> Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
> Kconfig so that we can call request_firmware_into_buf() from remoteproc
> driver.
>
> Signed-off-by: MD Danish Anwar
> ---
> Changes from v3 to v4:
> *) No functional change. Splitted the patch out of the series as suggested
>by Nishant.
> *) Droppped the RFC tag.
>
> v3: https://lore.kernel.org/all/20240124064930.1787929-4-danishan...@ti.com/
>
> drivers/remoteproc/Kconfig| 1 +
> drivers/remoteproc/rproc-uclass.c | 85 +++
> include/remoteproc.h | 35 +
> 3 files changed, 121 insertions(+)
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 781de530af..0fdf1b38ea 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -10,6 +10,7 @@ menu "Remote Processor drivers"
> # All users should depend on DM
> config REMOTEPROC
> bool
> + select FS_LOADER
> depends on DM
>
> # Please keep the configuration alphabetically sorted.
> diff --git a/drivers/remoteproc/rproc-uclass.c
> b/drivers/remoteproc/rproc-uclass.c
> index 28b362c887..76db4157f7 100644
> --- a/drivers/remoteproc/rproc-uclass.c
> +++ b/drivers/remoteproc/rproc-uclass.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -961,3 +962,87 @@ unsigned long rproc_parse_resource_table(struct udevice
> *dev, struct rproc *cfg)
>
> return 1;
> }
> +
> +int rproc_set_firmware(struct udevice *rproc_dev, const char *fw_name)
> +{
> + struct dm_rproc_uclass_pdata *uc_pdata;
> + int len;
> + char *p;
> +
> + if (!rproc_dev || !fw_name)
> + return -EINVAL;
> +
> + uc_pdata = dev_get_uclass_plat(rproc_dev);
This can return NULL and you shuould error out if it does.
> +
> + len = strcspn(fw_name, "\n");
> + if (!len) {
> + debug("can't provide empty string for firmware name\n");
how about "invalid filename" ?
> + return -EINVAL;
> + }
> +
> + p = strndup(fw_name, len);
> + if (!p)
> + return -ENOMEM;
> +
> + uc_pdata->fw_name = p;
> +
> + return 0;
> +}
> +
> +int rproc_boot(struct udevice *rproc_dev, size_t fw_size)
> +{
> + struct dm_rproc_uclass_pdata *uc_pdata;
> + struct udevice *fs_loader;
> + void *addr = malloc(fw_size);
I will suggest to do malloc just before you need the buffer.
You need to free up the buffer an all return paths after that.
> + int core_id, ret = 0;
> + char *firmware;
> + ulong rproc_addr;
do you really need rproc_addr? You could use addr itself.
> +
> + if (!rproc_dev)
> + return -EINVAL;
> +
> + if (!addr)
> + return -ENOMEM;
> +
> + uc_pdata = dev_get_uclass_plat(rproc_dev);
> + core_id = dev_seq(rproc_dev);
> + firmware = uc_pdata->fw_name;
> +
> + if (!firmware) {
> + debug("No firmware set for rproc core %d\n", core_id);
> + return -EINVAL;
> + }
> +
> + /* Initialize all rproc cores */
> + rproc_init();
if (!rproc_is_initialized()) {
ret = rproc_init()
if (ret) {
debug("rproc_init() failed: %d\n", ret);
return ret;
}
}
> +
> + /* Loading firmware to a given address */
> + ret = get_fs_loader(_loader);
> + if (ret) {
> + debug("could not get fs loader: %d\n", ret);
> + return ret;
> + }
> +
> + ret = request_firmware_into_buf(fs_loader, firmware, addr, fw_size, 0);
> + if (ret < 0) {
> + debug("could not request %s: %d\n", firmware, ret);
> + return ret;
> + }
> +
> + rproc_addr = (ulong)addr;
> +
> + ret = rproc_load(core_id, rproc_addr, ret);
ret = rproc_load(coare_id, (ulong)addr, ret);
> + if (ret) {
> + debug("failed to load %s to rproc core %d from addr 0x%08lX err
> %d\n",
> + uc_pdata->fw_name, core_id, rproc_addr, ret);
> + return ret;
> + }
> +
> + ret = rproc_start(core_id);
> + if (ret) {
> + debug("failed to start rproc core %d\n", core_id);
> + return ret;
> + }
> +
> + return ret;
return 0;
> +}
> diff --git a/include/remoteproc.h b/include/remoteproc.h
> index 91a88791a4..e53f85ba51 100644
> --- a/include/remoteproc.h
> +++ b/include/remoteproc.h
> @@ -403,6 +403,7 @@ enum
[PATCH 2/3] arm: dts: k3-u-boot: Drop usage of "u-boot, mux-autoprobe"
MUX driver should autoprobe if the device tree has "idle-states"
property. Drop using the custom "u-boot,mux-autoprobe" property.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am642-sk-u-boot.dtsi| 4
arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi| 2 --
arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi | 8
arch/arm/dts/k3-j721e-sk-u-boot.dtsi| 8
4 files changed, 22 deletions(-)
diff --git a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
index 2eb227c1d0..f3ed376ab7 100644
--- a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
@@ -184,10 +184,6 @@
bootph-all;
};
-_ln_ctrl {
- u-boot,mux-autoprobe;
-};
-
{
bootph-all;
};
diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
index 017a5a722e..f83caf7998 100644
--- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
@@ -165,7 +165,6 @@
_ln_ctrl {
bootph-all;
- u-boot,mux-autoprobe;
};
_usb_link {
@@ -174,7 +173,6 @@
_serdes_mux {
bootph-all;
- u-boot,mux-autoprobe;
};
_wiz2 {
diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
index 7ae7cf3d4c..b77f8d92de 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
@@ -93,14 +93,6 @@
bootph-all;
};
-_ln_ctrl {
- u-boot,mux-autoprobe;
-};
-
-_serdes_mux {
- u-boot,mux-autoprobe;
-};
-
_usbss0_pins_default {
bootph-all;
};
diff --git a/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
b/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
index 479b7bcd6f..370fe5190b 100644
--- a/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
@@ -89,14 +89,6 @@
bootph-all;
};
-_ln_ctrl {
- u-boot,mux-autoprobe;
-};
-
-_serdes_mux {
- u-boot,mux-autoprobe;
-};
-
_usbss0_pins_default {
bootph-all;
};
--
2.34.1
[PATCH 3/3] arm: dts: k3-u-boot: Add missing "bootph-all" property to MUX nodes.
As it is present for USB and USB won't work without the MUX
initialized correctly, add "bootph-all" property to MUX nodes.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am642-sk-u-boot.dtsi| 4
arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi | 8
arch/arm/dts/k3-j721e-sk-u-boot.dtsi| 8
3 files changed, 20 insertions(+)
diff --git a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
index f3ed376ab7..ea200a1ee1 100644
--- a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
@@ -184,6 +184,10 @@
bootph-all;
};
+_ln_ctrl {
+ bootph-all;
+};
+
{
bootph-all;
};
diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
index b77f8d92de..9433f3bafa 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
@@ -93,6 +93,14 @@
bootph-all;
};
+_ln_ctrl {
+ bootph-all;
+};
+
+_serdes_mux {
+ bootph-all;
+};
+
_usbss0_pins_default {
bootph-all;
};
diff --git a/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
b/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
index 370fe5190b..fff447094a 100644
--- a/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
@@ -89,6 +89,14 @@
bootph-all;
};
+_ln_ctrl {
+ bootph-all;
+};
+
+_serdes_mux {
+ bootph-all;
+};
+
_usbss0_pins_default {
bootph-all;
};
--
2.34.1
[PATCH 1/3] mux: autoprobe if "idle-states" present in device tree
Some platforms need the MUX state to be auto initialized at
boot time even if there are no explicit users for the MUX.
In these cases, the MUX device tree has "idle-states" property
which specifies what state the MUX should be initialized to.
So far we were relying on custom u-boot property "u-boot,mux-autoprobe"
to autoprobe such MUXes. This patch causes the MUX to autoprobe
if it has "idle-states" property in device tree.
This should allow us to stop using the custom "u-boot,mux-autoprobe"
property.
Signed-off-by: Roger Quadros
---
drivers/mux/mux-uclass.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mux/mux-uclass.c b/drivers/mux/mux-uclass.c
index c98576ceb8..8833888ded 100644
--- a/drivers/mux/mux-uclass.c
+++ b/drivers/mux/mux-uclass.c
@@ -318,7 +318,8 @@ int dm_mux_init(void)
return ret;
}
uclass_foreach_dev(dev, uc) {
- if (dev_read_bool(dev, "u-boot,mux-autoprobe")) {
+ if (dev_read_bool(dev, "u-boot,mux-autoprobe") ||
+ dev_read_bool(dev, "idle-states")) {
ret = device_probe(dev);
if (ret)
log_debug("unable to probe device %s\n",
--
2.34.1
[PATCH 0/3] mux: Drop usage of "u-boot,mux-autoprobe"
Hi, MUX driver should autoprobe if the device tree has "idle-states" property. Drop using the custom "u-boot,mux-autoprobe" property in TI device trees. cheers, -roger Roger Quadros (3): mux: autoprobe if "idle-states" present in device tree arm: dts: k3-u-boot: Drop usage of "u-boot,mux-autoprobe" arm: dts: k3-u-boot: Add missing "bootph-all" property to MUX nodes. arch/arm/dts/k3-am642-sk-u-boot.dtsi| 2 +- arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi| 2 -- arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi | 4 ++-- arch/arm/dts/k3-j721e-sk-u-boot.dtsi| 4 ++-- drivers/mux/mux-uclass.c| 3 ++- 5 files changed, 7 insertions(+), 8 deletions(-) base-commit: 28760ce8640ff6266bd1c1c568a4a231576f3919 -- 2.34.1
Re: [PATCH v8 13/16] arm: dts: Introduce am69-sk u-boot dts files
On 19/01/2024 19:50, Apurva Nandan wrote:
> From: Dasnavis Sabiya
>
> 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: Dasnavis Sabiya
> Signed-off-by: Apurva Nandan
> ---
> arch/arm/dts/Makefile | 1 +
> arch/arm/dts/k3-am69-r5-sk.dts | 105
> arch/arm/dts/k3-am69-sk-u-boot.dtsi | 48 +
> board/ti/j784s4/MAINTAINERS | 2 +
> 4 files changed, 156 insertions(+)
> create mode 100644 arch/arm/dts/k3-am69-r5-sk.dts
> create mode 100644 arch/arm/dts/k3-am69-sk-u-boot.dtsi
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 876802b88e..1c5a6662f6 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1412,6 +1412,7 @@ dtb-$(CONFIG_SOC_K3_J721S2) +=
> k3-am68-sk-base-board.dtb\
> k3-j721s2-r5-common-proc-board.dtb
>
> dtb-$(CONFIG_SOC_K3_J784S4) += k3-am69-sk.dtb \
> +k3-am69-r5-sk.dtb \
> k3-j784s4-evm.dtb \
> k3-j784s4-r5-evm.dtb
>
> diff --git a/arch/arm/dts/k3-am69-r5-sk.dts b/arch/arm/dts/k3-am69-r5-sk.dts
> new file mode 100644
> index 00..d2e73bd1bf
> --- /dev/null
> +++ b/arch/arm/dts/k3-am69-r5-sk.dts
> @@ -0,0 +1,105 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2022-2023 Texas Instruments Incorporated -
> https://www.ti.com/
> + */
> +
> +/dts-v1/;
> +
> +#include "k3-am69-sk.dts"
> +#include "k3-j784s4-ddr-evm-lp4-4266.dtsi"
> +#include "k3-j784s4-ddr.dtsi"
> +#include "k3-am69-sk-u-boot.dtsi"
> +
> +/ {
> + chosen {
> + tick-timer = _timer0;
> + };
> +
> + aliases {
> + remoteproc0 =
> + remoteproc1 = _0;
> + };
> +
> + a72_0: a72@0 {
> + compatible = "ti,am654-rproc";
> + reg = <0x0 0x00a9 0x0 0x10>;
> + power-domains = <_pds 61 TI_SCI_PD_EXCLUSIVE>,
> + <_pds 202 TI_SCI_PD_EXCLUSIVE>;
> + resets = <_reset 202 0>;
> + clocks = <_clks 61 0>;
> + assigned-clocks = <_clks 61 0>, <_clks 202 0>;
> + assigned-clock-parents = <_clks 61 2>;
> + assigned-clock-rates = <2>, <20>;
> + ti,sci = <>;
> + ti,sci-proc-id = <32>;
> + ti,sci-host-id = <10>;
> + bootph-pre-ram;
> + };
> +
> + dm_tifs: dm-tifs {
> + compatible = "ti,j721e-dm-sci";
> + ti,host-id = <3>;
> + ti,secure-host;
> + mbox-names = "rx", "tx";
> + mboxes= <_proxy_mcu 21>, <_proxy_mcu 23>;
> + bootph-pre-ram;
> + };
> +};
> +
> +_timer0 {
> + status = "okay";
> + clock-frequency = <25000>;
> + bootph-pre-ram;
> +};
> +
> +_proxy_sa3 {
> + status = "okay";
> + bootph-pre-ram;
> +};
> +
> +_proxy_mcu {
> + status = "okay";
> + bootph-pre-ram;
> +};
> +
> +_mcu_wakeup {
> + sysctrler: sysctrler {
> + compatible = "ti,am654-system-controller";
> + mboxes= <_proxy_mcu 4>,
> + <_proxy_mcu 5>,
> + <_proxy_sa3 5>;
> + mbox-names = "tx", "rx", "boot_notify";
> + bootph-pre-ram;
> + };
> +};
> +
> + {
> + mboxes= <_proxy_mcu 8>, <_proxy_mcu 6>,
> <_proxy_mcu 5>;
> + mbox-names = "tx", "rx", "notify";
> + ti,host-id = <4>;
> + ti,secure-host;
> + bootph-pre-ram;
> +};
> +
> +_uart0 {
> + bootph-pre-ram;
> + status = "okay";
In k3-am69-sk.dts this is marked as reserved. Why do you need to enable it here?
Maybe a comment would help readers.
> +};
> +
> + {
> + reg = <0x0 0x4704 0x0 0x100>,
> + <0x0 0x5000 0x0 0x800>;
> +};
> +
> + {
> + reg = <0x0 0x4705 0x0 0x100>,
> + <0x0 0x5800 0x0 0x800>;
> +};
> +
> +_ringacc {
> + ti,sci = <_tifs>;
> +};
> +
> +_udmap {
> + ti,sci = <_tifs>;
> +};
> diff --git a/arch/arm/dts/k3-am69-sk-u-boot.dtsi
> b/arch/arm/dts/k3-am69-sk-u-boot.dtsi
> new file mode 100644
> index 00..4f8c99a1e6
> --- /dev/null
> +++ b/arch/arm/dts/k3-am69-sk-u-boot.dtsi
> @@ -0,0 +1,48 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2022-2023 Texas Instruments Incorporated -
> https://www.ti.com/
> + */
> +
> +#include "k3-j784s4-binman.dtsi"
> +
> +_udmap {
> + reg = <0x0 0x285c 0x0 0x100>,
> + <0x0 0x284c 0x0 0x4000>,
> + <0x0 0x2a80 0x0 0x4>,
> + <0x0 0x284a 0x0 0x4000>,
> + <0x0 0x2aa0 0x0 0x4>,
> + <0x0 0x2840 0x0 0x2000>;
> + reg-names = "gcfg", "rchan", "rchanrt", "tchan",
> + "tchanrt", "rflow";
> + bootph-pre-ram;
> +};
> +
> + {
> + k3_sysreset: sysreset-controller {
> +
Re: [PATCH v8 08/16] drivers: dma: Add support for J784S4 SoC
_num = 32,
> + },
> + /* TX channels */
> + {
> + .dev_id = 329,
> + .subtype = 13,
> + .range_start = 40,
> + .range_num = 3,
> + },
> + /* RX channels */
> + {
> + .dev_id = 329,
> + .subtype = 10,
> + .range_start = 40,
> + .range_num = 3,
> + },
> + /* RX Free flows */
> + {
> + .dev_id = 329,
> + .subtype = 0,
> + .range_start = 84,
> + .range_num = 8,
> + },
> + { },
> +};
> +#endif /* CONFIG_SOC_K3_J784S4 */
> +
> #else
> static struct ti_sci_resource_static_data rm_static_data[] = {
> { },
> diff --git a/drivers/ram/Kconfig b/drivers/ram/Kconfig
> index 5b07e92030..8e9e53cbb0 100644
> --- a/drivers/ram/Kconfig
> +++ b/drivers/ram/Kconfig
> @@ -62,7 +62,7 @@ choice
> depends on K3_DDRSS
> prompt "K3 DDRSS Arch Support"
>
> - default K3_J721E_DDRSS if SOC_K3_J721E || SOC_K3_J721S2
> + default K3_J721E_DDRSS if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4
Should DDR support patch be independent of DMA support?
This change should have gone in patch 2 "arm: mach-k3: Add basic support for
J784S4 SoC definition"
> default K3_AM64_DDRSS if SOC_K3_AM642
> default K3_AM64_DDRSS if SOC_K3_AM625
> default K3_AM62A_DDRSS if SOC_K3_AM62A7
Reviewed-by: Roger Quadros
--
cheers,
-roger
Re: [PATCH v8 07/16] arm: mach-k3: j784s4: Add clk and power support
On 19/01/2024 19:50, Apurva Nandan wrote: > Add clk and device data which can be used by respective drivers > to configure clocks and PSC. > > Signed-off-by: Hari Nagalla > Signed-off-by: Apurva Nandan > Reviewed-by: Sean Anderson > Reviewed-by: Nishanth Menon > Reviewed-by: Bryan Brattlof Reviewed-by: Roger Quadros
Re: [PATCH v8 06/16] soc: ti: k3-socinfo: Add entry for J784S4 SoC
On 19/01/2024 19:50, Apurva Nandan wrote: > Add support for J784S4 SoC Identification. > > Signed-off-by: Hari Nagalla > Signed-off-by: Apurva Nandan > Reviewed-by: Nishanth Menon Reviewed-by: Roger Quadros
Re: [PATCH v8 05/16] arm: mach-k3: Sort SoC JTAG_ID entries
On 19/01/2024 19:50, Apurva Nandan wrote: > Sort JTAG_IDs for K3 SoCs in hardware.h in alphabetical order. > > Signed-off-by: Apurva Nandan > Reviewed-by: Nishanth Menon Reviewed-by: Roger Quadros
Re: [PATCH v8 01/16] arm: mach-k3: Kconfig: Sort SOC_K3 config entries
On 19/01/2024 19:50, Apurva Nandan wrote: > Sort SOC_K3 config entries in alphabetical order > for clean up. > > Signed-off-by: Apurva Nandan Reviewed-by: Roger Quadros
Re: [PATCH 4/5] arm: dts: k3-j721e-beagleboneai64: Fix USB operation
On 20/01/2024 18:50, Tom Rini wrote:
> On Mon, Jan 15, 2024 at 01:40:00PM +0200, Roger Quadros wrote:
>>
>>
>> On 12/01/2024 15:21, Tom Rini wrote:
>>> On Fri, Jan 12, 2024 at 07:14:50AM -0600, Nishanth Menon wrote:
>>>> On 15:06-20240112, Roger Quadros wrote:
>>>>>
>>>>>
>>>>> On 12/01/2024 15:02, Nishanth Menon wrote:
>>>>>> On 14:49-20240112, Roger Quadros wrote:
>>>>>>> Without correct SERDES MUX and Lane control settings
>>>>>>> USB0 will be broken. Set the MUX and Lane control devices
>>>>>>> to be auto probed so they are configured correctly.
>>>>>>>
>>>>>>> Signed-off-by: Roger Quadros
>>>>>>> ---
>>>>>>> arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi | 2 ++
>>>>>>> 1 file changed, 2 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
>>>>>>> b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
>>>>>>> index f83caf7998..017a5a722e 100644
>>>>>>> --- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
>>>>>>> +++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
>>>>>>> @@ -165,6 +165,7 @@
>>>>>>>
>>>>>>> _ln_ctrl {
>>>>>>> bootph-all;
>>>>>>> + u-boot,mux-autoprobe;
>>>>>>> };
>>>>>>>
>>>>>>> _usb_link {
>>>>>>> @@ -173,6 +174,7 @@
>>>>>>>
>>>>>>> _serdes_mux {
>>>>>>> bootph-all;
>>>>>>> + u-boot,mux-autoprobe;
>>>>>>> };
>>>>>>>
>>>>>>> _wiz2 {
>>>
>>> OK, so both of these are compatible = "mmio-mux", is the problem they
>>> aren't probed in time or something else?
>>>
>>
>> That's correct. They aren't probed ever. But that is because there are no
>> explicit consumers for them. Since this is a platform wide configuration,
>> we have been relying on the "idle-states" property and that they are
>> auto-probed.
>
> OK. Could we borrow the "wrap" logic that drivers/led/led_gpio.c for
> example does to get the probe to happen inside drivers/mux/mmio.c
> instead? I feel like there might have been assumptions about grander
> needs back when the framework for muxers was done that has not panned
> out since.
>
We only need the MUX driver to probe if the MUX node contains the "idle-states"
property.
So maybe the MUX UCLASS code should be checking for that instead of/along with
the custom u-boot,mux-autoprobe property?
How does this look?
diff --git a/drivers/mux/mux-uclass.c b/drivers/mux/mux-uclass.c
index c98576ceb8..8833888ded 100644
--- a/drivers/mux/mux-uclass.c
+++ b/drivers/mux/mux-uclass.c
@@ -318,7 +318,8 @@ int dm_mux_init(void)
return ret;
}
uclass_foreach_dev(dev, uc) {
- if (dev_read_bool(dev, "u-boot,mux-autoprobe")) {
+ if (dev_read_bool(dev, "u-boot,mux-autoprobe") ||
+ dev_read_bool(dev, "idle-states")) {
ret = device_probe(dev);
if (ret)
log_debug("unable to probe device %s\n",
--
cheers,
-roger
Re: [PATCH v1 1/1] net: ti: am65-cpsw-nuss: Remove incorrect RGMII_ID bit functionality
Hi Ken,
On 16/01/2024 22:01, Ken Sloat wrote:
> The CPSW implementations on the AM6x platforms do not support the
> selectable RGMII TX clk delay functionality via the RGMII_ID_MODE bit as
> the earlier platforms did. According to various TI datasheets, reference
> manuals, hardware design guides and TI forum posts from TI, this bit is
> "not timed, tested, or characterized. RGMII_ID is enabled by default and
> the register bit reserved."
>
> The driver implementation today however, will incorrectly set this bit
> whenever the interface mode is in RGMII_ID or RGMII_TXID.
>
> To fix this, remove any statement setting this bit, and moreover, mask
> bits 31:4 as these are all reserved.
>
> See:
> https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1211306/am625-enet1_ctrl_rgmii_id-_mode
> https://www.ti.com/lit/pdf/spruiv7 (Rev. B Figure 14-1717>
> https://www.ti.com/lit/gpn/am625 (Rev. B Figure 7-31 Note A)
> https://www.ti.com/lit/an/sprad05b/sprad05b.pdf (Rev. B Section 7.4)
>
Thanks for the patch. Some comments below.
> Signed-off-by: Ken Sloat
> ---
> drivers/net/ti/am65-cpsw-nuss.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
> index 18a33c4c0e..51c432408f 100644
> --- a/drivers/net/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ti/am65-cpsw-nuss.c
> @@ -256,7 +256,6 @@ static int am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv
> *priv,
> {
> struct udevice *dev = priv->dev;
> u32 offset, reg, phandle;
> - bool rgmii_id = false;
> fdt_addr_t gmii_sel;
> u32 mode = 0;
> ofnode node;
> @@ -296,7 +295,6 @@ static int am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv
> *priv,
> case PHY_INTERFACE_MODE_RGMII_ID:
> case PHY_INTERFACE_MODE_RGMII_TXID:
> mode = AM65_GMII_SEL_MODE_RGMII;
> - rgmii_id = true;
> break;
>
> case PHY_INTERFACE_MODE_SGMII:
> @@ -313,15 +311,13 @@ static int am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv
> *priv,
> break;
> };
>
> - if (rgmii_id)
> - mode |= AM65_GMII_SEL_RGMII_IDMODE;
> -
> - reg = mode;
> + /* bits 31:4 are reserved */
Updated documentation is still wrong. Reserved bits should be Read only and
should
always read 0. In updated TRM it doesn't show reserved bits as read-only and
states
read value is 1.
Bit 4 is clearly read/write so it cannot be treated as reserved. But setting it
to 1 is not supported.
If bootROM or some other software set it to 1 then it will remain 1 and we
cannot
rely on it to be always 0. That's why it shouldn't be treated as reserved.
On AM65 bits 31:5 and 3:2 are reserved (read only 0).
Bit 4 is still r/w but setting 1 is not supported.
> + reg = (GENMASK(31, 4) & reg) | mode;
As reserved bits will always read 0 this mask is not required.
What we do need to do is always clear bit 4.
So
#define AM6X_GMII_SEL_MODE_SEL_MASK GENMASK(2:0)
/* RGMII_ID_MODE = 1 is not supported */
reg &= ~AM65_GMII_SEL_RGMII_IDMODE;
reg &= ~AM6X_GMII_SEL_MODE_SEL_MASK;
reg |= mode;
Or simply this would have worked as we don't really set bit 4 in mode.
reg = mode;
> dev_dbg(dev, "gmii_sel PHY mode: %u, new gmii_sel: %08x\n",
> phy_mode, reg);
> writel(reg, gmii_sel);
>
> - reg = readl(gmii_sel);
> + reg = GENMASK(3, 0) & readl(gmii_sel);
should be GENMASK(2, 0);
but now we can use AM6X_GMII_SEL_MODE_SEL_MASK here instead.
> if (reg != mode) {
> dev_err(dev,
> "gmii_sel PHY mode NOT SET!: requested: %08x, gmii_sel:
> %08x\n",
--
cheers,
-roger
Re: [PATCH 03/10] soc: ti: k3-navss-ringacc: Initialize base address of ring cfg registers
Hi,
On 12/01/2024 08:47, Siddharth Vadapalli wrote:
> 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);
> +
Should this be restricted only for R5 SPL case? else we conflict with
Device Manager services?
> 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 = >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;
--
cheers,
-roger
Re: [PATCH v4 2/7] usb: dwc3: Switch to device mode on gadget start
On 12/01/2024 16:18, Sjoerd Simons wrote: > On Fri, 2024-01-12 at 14:56 +0200, Roger Quadros wrote: >> >> >> On 12/01/2024 13:06, Sjoerd Simons wrote: >>> On Fri, 2024-01-12 at 12:39 +0200, Roger Quadros wrote: >>>> >>>> >>>> On 12/01/2024 10:52, Sjoerd Simons wrote: >>>>> When dr_mode is "otg" the dwc3 is initially configured in _OTG >>>>> mode; >>>>> However in this mode the gadget functionality doesn't work >>>>> without >>>>> further configuration. To resolve that on gadget start switch >>>>> to >>>>> _DEVICE >>>>> mode globally and go back to _OTG on stop again. >>>>> >>>>> For this the dwc3_set_mode is renamed to dwc3_core_set_mode to >>>>> avoid a >>>>> conflict with the same function exposed by xhci-dwc3 >>>> >>>> Aren't they both doing the same thing? I'd rather define them at >>>> one >>>> place >>>> i.e. dwc3/core.c. >>> >>> They twiddle the same registers afaict indeed; but the way to get >>> there >>> is rather different. So having just one for both really needs a >>> bigger >>> amount of rework. >>> >>>> The driver model design for dwc3 looks really broken in u-boot. >>>> >>>> "snps,dwc3" is claimed by xhci-dwc3.c instead of being claimed by >>>> dwc3/core.c. >>>> This is probably because at the time USB host was the more needed >>>> use >>>> case at u-boot. >>>> >>>> Ideally dwc3/core.c should claim "snps,dwc3" device and >>>> instantiate >>>> the respective Host/Device/OTG device based on the provided otg >>>> mode. >>>> >>>> For Host/Device mode it is straight forwa >>>> dwc3/core.c does dwc3_set_mode() depending on the mode and: >>>> for host mode -> register xhci-usb driver. >>>> for device mode -> register UDC device driver. >>>> >>>> For dual-role mode, the solution is not very clear as I don't >>>> think >>>> there is a role switch framework present >>>> >>>> To begin with, we could probably restrict it to just device mode >>>> as most platforms were forcing it to device mode in any case as >>>> they >>>> usually have a 2nd USB port that is host only. >>> >>> Right we don't have role switching; And if we had we'd have to add >>> support of the Type-C controller on the SK boards which determines >>> the >>> roles for this. >>> >>> This one more minimal patch was modelled after the discussion last >>> year >>> around otg mode[0]. And similar to how the cdns3 driver handles it. >>> Essentially letting host/gadget mode be determined by the usage >>> rather >>> then the cables plugged, which is not pretty but works. >>> >>> While I agree with you this could all be a lot nicer of u-boot did >>> "proper" OTG/role-switching; I unfortunately don't have the >>> bandwidth >>> to introduce all of that and it seems a shame to block DFU support >>> on >>> it. For reference my previous series just set the peripheral role >>> in >>> the dts which reflects your suggestion of forcing device mode. I'd >>> be >>> wary to do so in the driver because i would hope the OTG handling >>> in >>> dwc3 is there for a reason :) >>> >>> >>> 0: https://lists.denx.de/pipermail/u-boot/2023-August/527709.html >>> >>> >> >> In your current series, how does it work? >> What happens if user starts both host and device controllers? > > Testing host functionality on the same port as used for DFU (the only > one that's otg) doesn't seem to work at all, not sure why that is. host > on usb1 (usb-a port, host only) works fine ofcourse. > > practically however once the user has used a gadget it's likely they'd > have to reset the host side (or at least do a rescan) though as likely > they'll have also switched around the cable :). > >> >> e.g. >>> usb start >>> dfu 0 > > That seems to work fine, modulo usb0 not seeing attached devices, but > that's not a regression introduced by this patch. am62-sk USB0 was never tested in host mode at u-boot. Let me try out and see if I can get it to work. -- cheers, -roger
Re: [PATCH 4/5] arm: dts: k3-j721e-beagleboneai64: Fix USB operation
On 12/01/2024 15:21, Tom Rini wrote:
> On Fri, Jan 12, 2024 at 07:14:50AM -0600, Nishanth Menon wrote:
>> On 15:06-20240112, Roger Quadros wrote:
>>>
>>>
>>> On 12/01/2024 15:02, Nishanth Menon wrote:
>>>> On 14:49-20240112, Roger Quadros wrote:
>>>>> Without correct SERDES MUX and Lane control settings
>>>>> USB0 will be broken. Set the MUX and Lane control devices
>>>>> to be auto probed so they are configured correctly.
>>>>>
>>>>> Signed-off-by: Roger Quadros
>>>>> ---
>>>>> arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi | 2 ++
>>>>> 1 file changed, 2 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
>>>>> b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
>>>>> index f83caf7998..017a5a722e 100644
>>>>> --- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
>>>>> +++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
>>>>> @@ -165,6 +165,7 @@
>>>>>
>>>>> _ln_ctrl {
>>>>> bootph-all;
>>>>> + u-boot,mux-autoprobe;
>>>>> };
>>>>>
>>>>> _usb_link {
>>>>> @@ -173,6 +174,7 @@
>>>>>
>>>>> _serdes_mux {
>>>>> bootph-all;
>>>>> + u-boot,mux-autoprobe;
>>>>> };
>>>>>
>>>>> _wiz2 {
>
> OK, so both of these are compatible = "mmio-mux", is the problem they
> aren't probed in time or something else?
>
That's correct. They aren't probed ever. But that is because there are no
explicit consumers for them. Since this is a platform wide configuration,
we have been relying on the "idle-states" property and that they are
auto-probed.
>>>>> --
>>>>> 2.34.1
>>>>>
>>>>
>>>> Is this a u-boot thing? or a driver limitation?
>>>>
>>>
>>> u-boot specific. We just want the mux driver to probe
>>> and apply the settings.
>>>
>>> from drivers/mux/mux-uclass.c
>>>
>>> int dm_mux_init(void)
>>> {
>>> struct uclass *uc;
>>> struct udevice *dev;
>>> int ret;
>>>
>>> ret = uclass_get(UCLASS_MUX, );
>>> if (ret < 0) {
>>> log_debug("unable to get MUX uclass\n");
>>> return ret;
>>> }
>>> uclass_foreach_dev(dev, uc) {
>>> if (dev_read_bool(dev, "u-boot,mux-autoprobe")) {
>>> ret = device_probe(dev);
>>> if (ret)
>>> log_debug("unable to probe device %s\n",
>>> dev->name);
>>> }
>>> }
>>>
>>> return 0;
>>> }
>>>
>>>
>>
>> Uggh.. We need to see eventually how to get rid of this.
>> This makes
>> https://lore.kernel.org/u-boot/20240110103547.719757-1-sumit.g...@linaro.org/#t
>> harder now?
>
> No, it should be fine, Sumit's series handles -u-boot.dtsi files.
>
--
cheers,
-roger
Re: [PATCH 4/5] arm: dts: k3-j721e-beagleboneai64: Fix USB operation
On 12/01/2024 15:02, Nishanth Menon wrote:
> On 14:49-20240112, Roger Quadros wrote:
>> Without correct SERDES MUX and Lane control settings
>> USB0 will be broken. Set the MUX and Lane control devices
>> to be auto probed so they are configured correctly.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
>> b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
>> index f83caf7998..017a5a722e 100644
>> --- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
>> +++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
>> @@ -165,6 +165,7 @@
>>
>> _ln_ctrl {
>> bootph-all;
>> +u-boot,mux-autoprobe;
>> };
>>
>> _usb_link {
>> @@ -173,6 +174,7 @@
>>
>> _serdes_mux {
>> bootph-all;
>> +u-boot,mux-autoprobe;
>> };
>>
>> _wiz2 {
>> --
>> 2.34.1
>>
>
> Is this a u-boot thing? or a driver limitation?
>
u-boot specific. We just want the mux driver to probe
and apply the settings.
from drivers/mux/mux-uclass.c
int dm_mux_init(void)
{
struct uclass *uc;
struct udevice *dev;
int ret;
ret = uclass_get(UCLASS_MUX, );
if (ret < 0) {
log_debug("unable to get MUX uclass\n");
return ret;
}
uclass_foreach_dev(dev, uc) {
if (dev_read_bool(dev, "u-boot,mux-autoprobe")) {
ret = device_probe(dev);
if (ret)
log_debug("unable to probe device %s\n",
dev->name);
}
}
return 0;
}
--
cheers,
-roger
Re: [PATCH v4 2/7] usb: dwc3: Switch to device mode on gadget start
On 12/01/2024 13:06, Sjoerd Simons wrote: > On Fri, 2024-01-12 at 12:39 +0200, Roger Quadros wrote: >> >> >> On 12/01/2024 10:52, Sjoerd Simons wrote: >>> When dr_mode is "otg" the dwc3 is initially configured in _OTG >>> mode; >>> However in this mode the gadget functionality doesn't work without >>> further configuration. To resolve that on gadget start switch to >>> _DEVICE >>> mode globally and go back to _OTG on stop again. >>> >>> For this the dwc3_set_mode is renamed to dwc3_core_set_mode to >>> avoid a >>> conflict with the same function exposed by xhci-dwc3 >> >> Aren't they both doing the same thing? I'd rather define them at one >> place >> i.e. dwc3/core.c. > > They twiddle the same registers afaict indeed; but the way to get there > is rather different. So having just one for both really needs a bigger > amount of rework. > >> The driver model design for dwc3 looks really broken in u-boot. >> >> "snps,dwc3" is claimed by xhci-dwc3.c instead of being claimed by >> dwc3/core.c. >> This is probably because at the time USB host was the more needed use >> case at u-boot. >> >> Ideally dwc3/core.c should claim "snps,dwc3" device and instantiate >> the respective Host/Device/OTG device based on the provided otg mode. >> >> For Host/Device mode it is straight forwa >> dwc3/core.c does dwc3_set_mode() depending on the mode and: >> for host mode -> register xhci-usb driver. >> for device mode -> register UDC device driver. >> >> For dual-role mode, the solution is not very clear as I don't think >> there is a role switch framework present >> >> To begin with, we could probably restrict it to just device mode >> as most platforms were forcing it to device mode in any case as they >> usually have a 2nd USB port that is host only. > > Right we don't have role switching; And if we had we'd have to add > support of the Type-C controller on the SK boards which determines the > roles for this. > > This one more minimal patch was modelled after the discussion last year > around otg mode[0]. And similar to how the cdns3 driver handles it. > Essentially letting host/gadget mode be determined by the usage rather > then the cables plugged, which is not pretty but works. > > While I agree with you this could all be a lot nicer of u-boot did > "proper" OTG/role-switching; I unfortunately don't have the bandwidth > to introduce all of that and it seems a shame to block DFU support on > it. For reference my previous series just set the peripheral role in > the dts which reflects your suggestion of forcing device mode. I'd be > wary to do so in the driver because i would hope the OTG handling in > dwc3 is there for a reason :) > > > 0: https://lists.denx.de/pipermail/u-boot/2023-August/527709.html > > In your current series, how does it work? What happens if user starts both host and device controllers? e.g. > usb start > dfu 0 -- cheers, -roger
[PATCH 5/5] configs/j721e_beagleboneai64_a72_defconfig: Enable Sierra PHY
This is required for USB Super-Speed operation. Signed-off-by: Roger Quadros --- configs/j721e_beagleboneai64_a72_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/j721e_beagleboneai64_a72_defconfig b/configs/j721e_beagleboneai64_a72_defconfig index 959f86844d..f66206f6e3 100644 --- a/configs/j721e_beagleboneai64_a72_defconfig +++ b/configs/j721e_beagleboneai64_a72_defconfig @@ -127,6 +127,8 @@ CONFIG_PHY_TI_DP83867=y CONFIG_PHY_FIXED=y CONFIG_TI_AM65_CPSW_NUSS=y CONFIG_PHY=y +CONFIG_PHY_J721E_WIZ=y +CONFIG_PHY_CADENCE_SIERRA=y CONFIG_SPL_PHY=y CONFIG_PINCTRL=y # CONFIG_PINCTRL_GENERIC is not set -- 2.34.1
[PATCH 4/5] arm: dts: k3-j721e-beagleboneai64: Fix USB operation
Without correct SERDES MUX and Lane control settings
USB0 will be broken. Set the MUX and Lane control devices
to be auto probed so they are configured correctly.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
index f83caf7998..017a5a722e 100644
--- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
@@ -165,6 +165,7 @@
_ln_ctrl {
bootph-all;
+ u-boot,mux-autoprobe;
};
_usb_link {
@@ -173,6 +174,7 @@
_serdes_mux {
bootph-all;
+ u-boot,mux-autoprobe;
};
_wiz2 {
--
2.34.1
[PATCH 3/5] arm: dts: k3-j721e: Fix USB0 operation
Without correct SERDES MUX and Lane control settings
USB0 will be broken. Set the MUX and Lane control devices
to be auto probed so they are configured correctly.
Fixes: 69b19ca67bcb ("arm: dts: k3-j721e: Sync with v6.6-rc1")
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi | 8
arch/arm/dts/k3-j721e-sk-u-boot.dtsi| 8
2 files changed, 16 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
index b77f8d92de..7ae7cf3d4c 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
@@ -93,6 +93,14 @@
bootph-all;
};
+_ln_ctrl {
+ u-boot,mux-autoprobe;
+};
+
+_serdes_mux {
+ u-boot,mux-autoprobe;
+};
+
_usbss0_pins_default {
bootph-all;
};
diff --git a/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
b/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
index 370fe5190b..479b7bcd6f 100644
--- a/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
@@ -89,6 +89,14 @@
bootph-all;
};
+_ln_ctrl {
+ u-boot,mux-autoprobe;
+};
+
+_serdes_mux {
+ u-boot,mux-autoprobe;
+};
+
_usbss0_pins_default {
bootph-all;
};
--
2.34.1
[PATCH 2/5] usb: cdns3: avoid error messages if phys don't exist
The phys property is optional so don't complain
if it doesn't exist in device tree.
Signed-off-by: Roger Quadros
---
drivers/usb/cdns3/core.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
index 644a9791b9..12a741c6ea 100644
--- a/drivers/usb/cdns3/core.c
+++ b/drivers/usb/cdns3/core.c
@@ -333,20 +333,28 @@ static int cdns3_probe(struct cdns3 *cdns)
mutex_init(>mutex);
ret = generic_phy_get_by_name(dev, "cdns3,usb2-phy", >usb2_phy);
- if (ret)
- dev_warn(dev, "Unable to get USB2 phy (ret %d)\n", ret);
-
- ret = generic_phy_init(>usb2_phy);
- if (ret)
+ if (!ret) {
+ ret = generic_phy_init(>usb2_phy);
+ if (ret) {
+ dev_err(dev, "USB2 PHY init failed: %d\n", ret);
+ return ret;
+ }
+ } else if (ret != -ENOENT && ret != -ENODATA) {
+ dev_err(dev, "Couldn't get USB2 PHY: %d\n", ret);
return ret;
+ }
ret = generic_phy_get_by_name(dev, "cdns3,usb3-phy", >usb3_phy);
- if (ret)
- dev_warn(dev, "Unable to get USB3 phy (ret %d)\n", ret);
-
- ret = generic_phy_init(>usb3_phy);
- if (ret)
+ if (!ret) {
+ ret = generic_phy_init(>usb3_phy);
+ if (ret) {
+ dev_err(dev, "USB3 PHY init failed: %d\n", ret);
+ return ret;
+ }
+ } else if (ret != -ENOENT && ret != -ENODATA) {
+ dev_err(dev, "Couldn't get USB3 PHY: %d\n", ret);
return ret;
+ }
ret = generic_phy_power_on(>usb2_phy);
if (ret)
--
2.34.1
[PATCH 1/5] board: ti: j721e: Drop SERDES PHY init from board file
Since commit 69b19ca67bcb ("arm: dts: k3-j721e: Sync with v6.6-rc1"),
the following error message is seen at u-boot
"Sierra init failed:-19"
Probing and initializing the SERDES PHY from
board file is not a clean solution so drop it.
Proper use case should be via PHY_UCLASS APIs.
Signed-off-by: Roger Quadros
---
board/ti/j721e/evm.c | 77
1 file changed, 77 deletions(-)
diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index c541880107..b77cffc5ef 100644
--- a/board/ti/j721e/evm.c
+++ b/board/ti/j721e/evm.c
@@ -352,77 +352,6 @@ static int probe_daughtercards(void)
}
#endif
-void configure_serdes_torrent(void)
-{
- struct udevice *dev;
- struct phy serdes;
- int ret;
-
- if (!IS_ENABLED(CONFIG_PHY_CADENCE_TORRENT))
- return;
-
- ret = uclass_get_device_by_driver(UCLASS_PHY,
- DM_DRIVER_GET(torrent_phy_provider),
- );
- if (ret) {
- printf("Torrent init failed:%d\n", ret);
- return;
- }
-
- serdes.dev = dev;
- serdes.id = 0;
-
- ret = generic_phy_init();
- if (ret) {
- printf("phy_init failed!!: %d\n", ret);
- return;
- }
-
- ret = generic_phy_power_on();
- if (ret) {
- printf("phy_power_on failed!!: %d\n", ret);
- return;
- }
-}
-
-void configure_serdes_sierra(void)
-{
- struct udevice *dev, *link_dev;
- struct phy link;
- int ret, count, i;
- int link_count = 0;
-
- if (!IS_ENABLED(CONFIG_PHY_CADENCE_SIERRA))
- return;
-
- ret = uclass_get_device_by_driver(UCLASS_MISC,
- DM_DRIVER_GET(sierra_phy_provider),
- );
- if (ret) {
- printf("Sierra init failed:%d\n", ret);
- return;
- }
-
- count = device_get_child_count(dev);
- for (i = 0; i < count; i++) {
- ret = device_get_child(dev, i, _dev);
- if (ret) {
- printf("probe of sierra child node %d failed: %d\n", i,
ret);
- return;
- }
- if (link_dev->driver->id == UCLASS_PHY) {
- link.dev = link_dev;
- link.id = link_count++;
-
- ret = generic_phy_power_on();
- if (ret) {
- printf("phy_power_on failed!!: %d\n", ret);
- return;
- }
- }
- }
-}
-
#ifdef CONFIG_BOARD_LATE_INIT
static void setup_board_eeprom_env(void)
{
@@ -476,12 +405,6 @@ int board_late_init(void)
probe_daughtercards();
}
- if (board_is_j7200_som())
- configure_serdes_torrent();
-
- if (board_is_j721e_som())
- configure_serdes_sierra();
-
return 0;
}
#endif
--
2.34.1
[PATCH 0/5] k3-j721e: beagleboneai: Fix USB
Hi, This series fixes USB operation on k3-j721e based boards. CI testing: https://github.com/u-boot/u-boot/pull/468 cheers, -roger Roger Quadros (5): board: ti: j721e: Drop SERDES PHY init from board file usb: cdns3: avoid error messages if phys don't exist arm: dts: k3-j721e: Fix USB0 operation arm: dts: k3-j721e-beagleboneai64: Fix USB operation configs/j721e_beagleboneai64_a72_defconfig: Enable Sierra PHY .../dts/k3-j721e-beagleboneai64-u-boot.dtsi | 2 + .../k3-j721e-common-proc-board-u-boot.dtsi| 8 ++ arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 8 ++ board/ti/j721e/evm.c | 77 --- configs/j721e_beagleboneai64_a72_defconfig| 2 + drivers/usb/cdns3/core.c | 28 --- 6 files changed, 38 insertions(+), 87 deletions(-) base-commit: f28a77589e7505535a4eebdc7269df98f67dbe68 -- 2.34.1
Re: [PATCH v4 5/7] configs: am62x_evm_*: Enable USB and DFU support
On 12/01/2024 12:44, Sjoerd Simons wrote: > On Fri, 2024-01-12 at 11:58 +0200, Roger Quadros wrote: >> Hi Sjoerd, >> >> On 12/01/2024 10:52, Sjoerd Simons wrote: >>> Enable USB host as well as USB gadget and DFU support for a53; For >>> the >>> r5 due to the smaller available size create a config fragment for >>> DFU >>> supports which disables support for persistent storage to free up >>> space >>> for USB support >>> >>> Signed-off-by: Sjoerd Simons >>> >>> --- >>> >>> Changes in v4: >>> - Move R5 dfu config to a config fragment rather then a full >>> defconfig >>> - Don't enable XHCI for the R5 SPL, unneeded >>> >>> Changes in v3: >>> - Run savedefconfig to adjust to more recent u-boot >>> >>> Changes in v2: >>> - Create a seperate defconfig for R5 >>> >>> configs/am62x_evm_a53_defconfig | 30 >>> ++ >>> configs/am62x_r5_usbdfu.config | 28 >>> 2 files changed, 58 insertions(+) >>> create mode 100644 configs/am62x_r5_usbdfu.config >>> >>> diff --git a/configs/am62x_evm_a53_defconfig >>> b/configs/am62x_evm_a53_defconfig >>> index aa96c1b3125..f335eb11e63 100644 >>> --- a/configs/am62x_evm_a53_defconfig >>> +++ b/configs/am62x_evm_a53_defconfig >>> @@ -1,5 +1,6 @@ >>> CONFIG_ARM=y >>> CONFIG_ARCH_K3=y >>> +CONFIG_SYS_MALLOC_LEN=0x200 >>> CONFIG_SYS_MALLOC_F_LEN=0x8000 >>> CONFIG_SPL_LIBCOMMON_SUPPORT=y >>> CONFIG_SPL_LIBGENERIC_SUPPORT=y >>> @@ -41,16 +42,23 @@ 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_ENV_SUPPORT=y >>> CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img" >>> CONFIG_SPL_DM_MAILBOX=y >>> CONFIG_SPL_DM_SPI_FLASH=y >>> CONFIG_SPL_POWER_DOMAIN=y >>> +CONFIG_SPL_RAM_SUPPORT=y >>> +CONFIG_SPL_RAM_DEVICE=y >>> # CONFIG_SPL_SPI_FLASH_TINY is not set >>> CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y >>> CONFIG_SPL_SPI_LOAD=y >>> CONFIG_SYS_SPI_U_BOOT_OFFS=0x28 >>> +CONFIG_SPL_USB_GADGET=y >>> +CONFIG_SPL_DFU=y >>> CONFIG_SPL_YMODEM_SUPPORT=y >>> +CONFIG_CMD_DFU=y >>> CONFIG_CMD_MMC=y >>> +CONFIG_CMD_USB=y >>> CONFIG_OF_CONTROL=y >>> CONFIG_SPL_OF_CONTROL=y >>> CONFIG_MULTI_DTB_FIT=y >>> @@ -61,10 +69,17 @@ CONFIG_SPL_DM=y >>> CONFIG_SPL_DM_SEQ_ALIAS=y >>> CONFIG_REGMAP=y >>> CONFIG_SPL_REGMAP=y >>> +CONFIG_SYSCON=y >>> +CONFIG_SPL_SYSCON=y >>> CONFIG_SPL_OF_TRANSLATE=y >>> CONFIG_CLK=y >>> CONFIG_SPL_CLK=y >>> CONFIG_CLK_TI_SCI=y >>> +CONFIG_DFU_MMC=y >>> +CONFIG_DFU_RAM=y >>> +CONFIG_DFU_SF=y >>> +CONFIG_SYS_DFU_DATA_BUF_SIZE=0x5000 >>> +CONFIG_SYS_DFU_MAX_FILE_SIZE=0x80 >>> CONFIG_DMA_CHANNELS=y >>> CONFIG_TI_K3_NAVSS_UDMA=y >>> CONFIG_TI_SCI_PROTOCOL=y >>> @@ -103,4 +118,19 @@ CONFIG_CADENCE_QSPI=y >>> CONFIG_SYSRESET=y >>> CONFIG_SPL_SYSRESET=y >>> CONFIG_SYSRESET_TI_SCI=y >>> +CONFIG_USB=y >>> +CONFIG_DM_USB_GADGET=y >>> +CONFIG_SPL_DM_USB_GADGET=y >>> +CONFIG_USB_XHCI_HCD=y >>> +CONFIG_USB_XHCI_DWC3=y >>> +CONFIG_USB_DWC3=y >>> +CONFIG_USB_DWC3_GENERIC=y >>> +CONFIG_SPL_USB_DWC3_GENERIC=y >>> +CONFIG_SPL_USB_DWC3_AM62=y >>> +CONFIG_USB_DWC3_AM62=y >>> +CONFIG_USB_GADGET=y >>> +CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" >>> +CONFIG_USB_GADGET_VENDOR_NUM=0x0451 >>> +CONFIG_USB_GADGET_PRODUCT_NUM=0x6165 >>> +CONFIG_USB_GADGET_DOWNLOAD=y >>> CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 >>> diff --git a/configs/am62x_r5_usbdfu.config >>> b/configs/am62x_r5_usbdfu.config >>> new file mode 100644 >>> index 000..772bb2ab935 >>> --- /dev/null >>> +++ b/configs/am62x_r5_usbdfu.config >>> @@ -0,0 +1,28 @@ >>> +CONFIG_SPL_ENV_SUPPORT=y >>> +CONFIG_SYSCON=y >>> +CONFIG_SPL_SYSCON=y >>> +CONFIG_SYS_DFU_DATA_BUF_SIZE=0x5000 >>> +CONFIG_MISC=y >>> +CONFIG_USB=y >>> +CONFIG_DM_USB_GADGET=y >>> +CONFIG_SPL_DM_USB_GADGET=y >>> +CONFIG_USB_DWC3=y >>> +CONFIG_USB_DWC3_GENERIC=y >>> +CONFIG_SPL_USB_DWC3_GENERIC=y >>> +CONFIG_SPL_USB_DWC3_AM62=y >>> +CONFIG_USB_GADGET=y >>> +CONFIG_SPL_USB_GADGET=y >>> +CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" >>> +CONFIG_USB_GADGET_VENDOR_NUM=0x0451 >>> +CONFIG_USB_GADGET_PRODUCT_NUM=0x6165 >>> +CONFIG_USB_GADGET_DOWNLOAD=y >>> +CONFIG_SPL_DFU=y >> >> Why do we need USB DFU support at R5 SPL stage? >> What is the use case? > > So we can load the A53 SPL over DFU ? There is no way to get a full DFU > bootchain without the R5 also taking part > > Got it. I should have read the documentation in patch 7 before asking. ;) -- cheers, -roger
Re: [PATCH v4 6/7] beagleplay: Add DFU support
On 12/01/2024 10:52, Sjoerd Simons wrote:
> DFU mode on a beagleplay can be used via the Type-C connector by holding
> the USR switch while powering on.
>
> Configuration is only added for the A53 u-boot parts, for R5 the
> am62x_r5_usbdfu.config fragment should be used.
>
> Signed-off-by: Sjoerd Simons
>
> ---
>
> Changes in v4:
> - New patch
>
> arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 8 ++
> board/beagle/beagleplay/beagleplay.env | 1 +
> configs/am62x_beagleplay_a53_defconfig | 30
> 3 files changed, 39 insertions(+)
>
> diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
> b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
> index a723caa5805..0b1e5e70fe2 100644
> --- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
> @@ -61,6 +61,14 @@
> >;
> };
>
> + {
> + bootph-all;
> +};
> +
> + {
> + bootph-all;
> +};
> +
> #ifdef CONFIG_TARGET_AM625_A53_BEAGLEPLAY
>
> #define SPL_NODTB "spl/u-boot-spl-nodtb.bin"
> diff --git a/board/beagle/beagleplay/beagleplay.env
> b/board/beagle/beagleplay/beagleplay.env
> index 4f0a94a8113..85c94856017 100644
> --- a/board/beagle/beagleplay/beagleplay.env
> +++ b/board/beagle/beagleplay/beagleplay.env
> @@ -1,6 +1,7 @@
> #include
> #include
> #include
> +#include
>
> name_kern=Image
> console=ttyS2,115200n8
> diff --git a/configs/am62x_beagleplay_a53_defconfig
> b/configs/am62x_beagleplay_a53_defconfig
> index 0be20045a97..dfe04b71810 100644
> --- a/configs/am62x_beagleplay_a53_defconfig
> +++ b/configs/am62x_beagleplay_a53_defconfig
> @@ -1,5 +1,6 @@
> CONFIG_ARM=y
> CONFIG_ARCH_K3=y
> +CONFIG_SYS_MALLOC_LEN=0x200
> CONFIG_SYS_MALLOC_F_LEN=0x8000
> CONFIG_SPL_GPIO=y
> CONFIG_SPL_LIBCOMMON_SUPPORT=y
> @@ -43,15 +44,20 @@ 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_ENV_SUPPORT=y
> CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img"
> CONFIG_SPL_I2C=y
> CONFIG_SPL_DM_MAILBOX=y
> CONFIG_SPL_POWER_DOMAIN=y
> +CONFIG_SPL_RAM_SUPPORT=y
> +CONFIG_SPL_RAM_DEVICE=y
> CONFIG_SPL_YMODEM_SUPPORT=y
> +CONFIG_CMD_DFU=y
> CONFIG_CMD_GPIO=y
> CONFIG_CMD_GPIO_READ=y
> CONFIG_CMD_I2C=y
> CONFIG_CMD_MMC=y
> +CONFIG_CMD_USB=y
> CONFIG_CMD_PMIC=y
> CONFIG_CMD_REGULATOR=y
> CONFIG_OF_CONTROL=y
> @@ -68,6 +74,10 @@ CONFIG_SPL_OF_TRANSLATE=y
> CONFIG_CLK=y
> CONFIG_SPL_CLK=y
> CONFIG_CLK_TI_SCI=y
> +CONFIG_DFU_MMC=y
> +CONFIG_DFU_RAM=y
> +CONFIG_SYS_DFU_DATA_BUF_SIZE=0x5000
> +CONFIG_SYS_DFU_MAX_FILE_SIZE=0x80
> CONFIG_DMA_CHANNELS=y
> CONFIG_TI_K3_NAVSS_UDMA=y
> CONFIG_TI_SCI_PROTOCOL=y
> @@ -113,6 +123,26 @@ CONFIG_SOC_TI=y
> CONFIG_SYSRESET=y
> CONFIG_SPL_SYSRESET=y
> CONFIG_SYSRESET_TI_SCI=y
> +CONFIG_USB=y
> +CONFIG_DM_USB_GADGET=y
> +CONFIG_SPL_DM_USB_GADGET=y
> +CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_XHCI_DWC3=y
XHCI features are really not required for DFU
but now I see that we depend on XHCI driver to get
probed even for device mode. lol.
> +CONFIG_USB_DWC3=y
> +CONFIG_USB_DWC3_GENERIC=y
> +CONFIG_SPL_USB_DWC3_GENERIC=y
> +CONFIG_SPL_USB_DWC3_AM62=y
> +CONFIG_USB_DWC3_AM62=y
> +CONFIG_USB_GADGET=y
> +CONFIG_SPL_USB_GADGET=y
> +CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
> +CONFIG_USB_GADGET_VENDOR_NUM=0x0451
> +CONFIG_USB_GADGET_PRODUCT_NUM=0x6165
> +CONFIG_USB_GADGET_DOWNLOAD=y
> +CONFIG_SPL_DFU=y
> CONFIG_EXT4_WRITE=y
> CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
> CONFIG_LZO=y
> +CONFIG_SYSCON=y
> +CONFIG_SPL_SYSCON=y
> +
--
cheers,
-roger
Re: [PATCH v4 2/7] usb: dwc3: Switch to device mode on gadget start
On 12/01/2024 10:52, Sjoerd Simons wrote:
> When dr_mode is "otg" the dwc3 is initially configured in _OTG mode;
> However in this mode the gadget functionality doesn't work without
> further configuration. To resolve that on gadget start switch to _DEVICE
> mode globally and go back to _OTG on stop again.
>
> For this the dwc3_set_mode is renamed to dwc3_core_set_mode to avoid a
> conflict with the same function exposed by xhci-dwc3
Aren't they both doing the same thing? I'd rather define them at one place
i.e. dwc3/core.c.
The driver model design for dwc3 looks really broken in u-boot.
"snps,dwc3" is claimed by xhci-dwc3.c instead of being claimed by dwc3/core.c.
This is probably because at the time USB host was the more needed use
case at u-boot.
Ideally dwc3/core.c should claim "snps,dwc3" device and instantiate
the respective Host/Device/OTG device based on the provided otg mode.
For Host/Device mode it is straight forward.
dwc3/core.c does dwc3_set_mode() depending on the mode and:
for host mode -> register xhci-usb driver.
for device mode -> register UDC device driver.
For dual-role mode, the solution is not very clear as I don't think
there is a role switch framework present.
To begin with, we could probably restrict it to just device mode
as most platforms were forcing it to device mode in any case as they
usually have a 2nd USB port that is host only.
A better solution would be to introduce a role switch mechanism
like it exists in Linux so user can choose what mode he wants to
operate. That could wait till someone really wants such a feature.
>
> Signed-off-by: Sjoerd Simons
>
> ---
>
> Changes in v4:
> - New patch
>
> drivers/usb/dwc3/core.c | 10 +-
> drivers/usb/dwc3/core.h | 1 +
> drivers/usb/dwc3/gadget.c | 6 ++
> 3 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 4b4fcd8a22e..d22d4c4bb6a 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -42,7 +42,7 @@
> static LIST_HEAD(dwc3_list);
> /*
> -- */
>
> -static void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
> +void dwc3_core_set_mode(struct dwc3 *dwc, u32 mode)
> {
> u32 reg;
>
> @@ -736,7 +736,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
>
> switch (dwc->dr_mode) {
> case USB_DR_MODE_PERIPHERAL:
> - dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
> + dwc3_core_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
> ret = dwc3_gadget_init(dwc);
> if (ret) {
> dev_err(dwc->dev, "failed to initialize gadget\n");
> @@ -744,7 +744,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
> }
> break;
> case USB_DR_MODE_HOST:
> - dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
> + dwc3_core_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
> ret = dwc3_host_init(dwc);
> if (ret) {
> dev_err(dwc->dev, "failed to initialize host\n");
> @@ -752,7 +752,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
> }
> break;
> case USB_DR_MODE_OTG:
> - dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
> + dwc3_core_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
> ret = dwc3_host_init(dwc);
> if (ret) {
> dev_err(dwc->dev, "failed to initialize host\n");
> @@ -810,7 +810,7 @@ static void dwc3_core_exit_mode(struct dwc3 *dwc)
>* switch back to peripheral mode
>* This enables the phy to enter idle and then, if enabled, suspend.
>*/
> - dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
> + dwc3_core_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
> dwc3_gadget_run(dwc);
> }
>
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 4162a682298..1e7eda89a34 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -1057,6 +1057,7 @@ int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc);
> void dwc3_of_parse(struct dwc3 *dwc);
> int dwc3_init(struct dwc3 *dwc);
> void dwc3_remove(struct dwc3 *dwc);
> +void dwc3_core_set_mode(struct dwc3 *dwc, u32 mode);
>
> static inline int dwc3_host_init(struct dwc3 *dwc)
> { return 0; }
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 406d36ceafe..69d9fe40e2f 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1468,6 +1468,9 @@ static int dwc3_gadget_start(struct usb_gadget *g,
>
> dwc->gadget_driver = driver;
>
> + if (dwc->dr_mode == DWC3_GCTL_PRTCAP_OTG)
> + dwc3_core_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
> +
> reg = dwc3_readl(dwc->regs, DWC3_DCFG);
> reg &= ~(DWC3_DCFG_SPEED_MASK);
>
> @@ -1559,6 +1562,9 @@ static int dwc3_gadget_stop(struct usb_gadget *g)
>
Re: [PATCH v4 5/7] configs: am62x_evm_*: Enable USB and DFU support
Hi Sjoerd, On 12/01/2024 10:52, Sjoerd Simons wrote: > Enable USB host as well as USB gadget and DFU support for a53; For the > r5 due to the smaller available size create a config fragment for DFU > supports which disables support for persistent storage to free up space > for USB support > > Signed-off-by: Sjoerd Simons > > --- > > Changes in v4: > - Move R5 dfu config to a config fragment rather then a full defconfig > - Don't enable XHCI for the R5 SPL, unneeded > > Changes in v3: > - Run savedefconfig to adjust to more recent u-boot > > Changes in v2: > - Create a seperate defconfig for R5 > > configs/am62x_evm_a53_defconfig | 30 ++ > configs/am62x_r5_usbdfu.config | 28 > 2 files changed, 58 insertions(+) > create mode 100644 configs/am62x_r5_usbdfu.config > > diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig > index aa96c1b3125..f335eb11e63 100644 > --- a/configs/am62x_evm_a53_defconfig > +++ b/configs/am62x_evm_a53_defconfig > @@ -1,5 +1,6 @@ > CONFIG_ARM=y > CONFIG_ARCH_K3=y > +CONFIG_SYS_MALLOC_LEN=0x200 > CONFIG_SYS_MALLOC_F_LEN=0x8000 > CONFIG_SPL_LIBCOMMON_SUPPORT=y > CONFIG_SPL_LIBGENERIC_SUPPORT=y > @@ -41,16 +42,23 @@ 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_ENV_SUPPORT=y > CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img" > CONFIG_SPL_DM_MAILBOX=y > CONFIG_SPL_DM_SPI_FLASH=y > CONFIG_SPL_POWER_DOMAIN=y > +CONFIG_SPL_RAM_SUPPORT=y > +CONFIG_SPL_RAM_DEVICE=y > # CONFIG_SPL_SPI_FLASH_TINY is not set > CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y > CONFIG_SPL_SPI_LOAD=y > CONFIG_SYS_SPI_U_BOOT_OFFS=0x28 > +CONFIG_SPL_USB_GADGET=y > +CONFIG_SPL_DFU=y > CONFIG_SPL_YMODEM_SUPPORT=y > +CONFIG_CMD_DFU=y > CONFIG_CMD_MMC=y > +CONFIG_CMD_USB=y > CONFIG_OF_CONTROL=y > CONFIG_SPL_OF_CONTROL=y > CONFIG_MULTI_DTB_FIT=y > @@ -61,10 +69,17 @@ CONFIG_SPL_DM=y > CONFIG_SPL_DM_SEQ_ALIAS=y > CONFIG_REGMAP=y > CONFIG_SPL_REGMAP=y > +CONFIG_SYSCON=y > +CONFIG_SPL_SYSCON=y > CONFIG_SPL_OF_TRANSLATE=y > CONFIG_CLK=y > CONFIG_SPL_CLK=y > CONFIG_CLK_TI_SCI=y > +CONFIG_DFU_MMC=y > +CONFIG_DFU_RAM=y > +CONFIG_DFU_SF=y > +CONFIG_SYS_DFU_DATA_BUF_SIZE=0x5000 > +CONFIG_SYS_DFU_MAX_FILE_SIZE=0x80 > CONFIG_DMA_CHANNELS=y > CONFIG_TI_K3_NAVSS_UDMA=y > CONFIG_TI_SCI_PROTOCOL=y > @@ -103,4 +118,19 @@ CONFIG_CADENCE_QSPI=y > CONFIG_SYSRESET=y > CONFIG_SPL_SYSRESET=y > CONFIG_SYSRESET_TI_SCI=y > +CONFIG_USB=y > +CONFIG_DM_USB_GADGET=y > +CONFIG_SPL_DM_USB_GADGET=y > +CONFIG_USB_XHCI_HCD=y > +CONFIG_USB_XHCI_DWC3=y > +CONFIG_USB_DWC3=y > +CONFIG_USB_DWC3_GENERIC=y > +CONFIG_SPL_USB_DWC3_GENERIC=y > +CONFIG_SPL_USB_DWC3_AM62=y > +CONFIG_USB_DWC3_AM62=y > +CONFIG_USB_GADGET=y > +CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" > +CONFIG_USB_GADGET_VENDOR_NUM=0x0451 > +CONFIG_USB_GADGET_PRODUCT_NUM=0x6165 > +CONFIG_USB_GADGET_DOWNLOAD=y > CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 > diff --git a/configs/am62x_r5_usbdfu.config b/configs/am62x_r5_usbdfu.config > new file mode 100644 > index 000..772bb2ab935 > --- /dev/null > +++ b/configs/am62x_r5_usbdfu.config > @@ -0,0 +1,28 @@ > +CONFIG_SPL_ENV_SUPPORT=y > +CONFIG_SYSCON=y > +CONFIG_SPL_SYSCON=y > +CONFIG_SYS_DFU_DATA_BUF_SIZE=0x5000 > +CONFIG_MISC=y > +CONFIG_USB=y > +CONFIG_DM_USB_GADGET=y > +CONFIG_SPL_DM_USB_GADGET=y > +CONFIG_USB_DWC3=y > +CONFIG_USB_DWC3_GENERIC=y > +CONFIG_SPL_USB_DWC3_GENERIC=y > +CONFIG_SPL_USB_DWC3_AM62=y > +CONFIG_USB_GADGET=y > +CONFIG_SPL_USB_GADGET=y > +CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" > +CONFIG_USB_GADGET_VENDOR_NUM=0x0451 > +CONFIG_USB_GADGET_PRODUCT_NUM=0x6165 > +CONFIG_USB_GADGET_DOWNLOAD=y > +CONFIG_SPL_DFU=y Why do we need USB DFU support at R5 SPL stage? What is the use case? > +# CONFIG_SPL_MMC is not set > +# CONFIG_SPL_FS_FAT is not set > +# CONFIG_SPL_LIBDISK_SUPPORT is not set > +# CONFIG_SPL_SPI is not set > +# CONFIG_SPL_SYS_MALLOC is not set > +# CONFIG_CMD_GPT is not set > +# CONFIG_CMD_MMC is not set > +# CONFIG_CMD_FAT is not set > +# CONFIG_MMC_SDHCI is not set -- cheers, -roger
Re: [RFC PATCH 2/2] board: ti: am65x: Move to using Extension framework
Hi Köry, On 06/10/2023 19:47, Simon Glass wrote: > Hi Köry, > > On Fri, 6 Oct 2023 at 07:26, Köry Maincent wrote: >> >> On Wed, 4 Oct 2023 15:39:23 +0300 >> Roger Quadros wrote: >> >> Hello, >> Thanks for adding me in cc. Also it seems I forgot to add myself to >> MAINTAINERS >> for the extension_board.c file. >> >>>>>> Before this goes too far I think this should move to using a linker >>>>>> list to declare the driver (or a driver-model driver if you prefer, >>>>>> but that might be overkill). >>> >>> So I've been working on this on the side and got linker list way working >>> with custom script booting but as soon as I move to standard boot flow >>> it no longer works. This is because there is no code in place to >>> apply the overlay and pass it to next stage e.g. EFI. >>> >>> I see the following note at >>> https://elixir.bootlin.com/u-boot/latest/source/boot/bootmeth_efi.c#L304 >>> >>> " >>> /* >>> * TODO: Apply extension overlay >>> * >>> * Here we need to load and apply the extension overlay. >>> This >>> is >>> * not implemented. See do_extension_apply(). The extension >>> * stuff needs an implementation in boot/extension.c so it >>> is >>> * separate from the command code. Really the extension >>> stuff >>> * should use the device tree and a uclass / driver >>> interface >>> * rather than implementing its own list >>> */ >>> " >> >> I agreed that the extension implementation should move in boot/extension.c or >> common for general use. I am wondering what the advantage of creating an >> uclass >> interface? >> I am not an uclass expert but there is no per driver ops and usage. What do >> you >> dislike about using its own list? > > I looked at this briefly for bootstd and left it alone, partly for this > reason. > > The operations I know about are: > - scan for extension boards to produce a list: needs to happen at > start of 'bootflow scan' I think) > - applying relevant overlays: needs to happen in the read_bootflow() > method perhaps > - listing available extensions > > I think a uclass makes sense, along with separating out the > 'extension' command from the actual functionality. What do you think about this? OK to move extension card driver to uclass? > >> >>> Another note at >>> https://elixir.bootlin.com/u-boot/latest/source/cmd/extension_board.c#L198 >>> >>> "/* extensions should have a uclass - for now we use UCLASS_SIMPLE_BUS >>> uclass >>> */" >>> >>> So are we better off implementing a class driver for extension stuff? >> >> I think the first point should be to move it in common or boot and makes it >> generic for using the extension function everywhere. I will let Simon answer >> about the uclass part. > > I believe this relates to boot/ > >> >> Regards, > > Regards, > Simon -- cheers, -roger
[PATCH v2 4/4] arm: mach-k3: am642: Define NAND boot device
AM642 SoC supports booting from GPMC NAND device. Define boot device for it. Signed-off-by: Roger Quadros --- Notes: v2: No change arch/arm/mach-k3/am642_init.c| 3 +++ arch/arm/mach-k3/include/mach/am64_spl.h | 1 + 2 files changed, 4 insertions(+) diff --git a/arch/arm/mach-k3/am642_init.c b/arch/arm/mach-k3/am642_init.c index 6085379f1d..ddf47ef0a9 100644 --- a/arch/arm/mach-k3/am642_init.c +++ b/arch/arm/mach-k3/am642_init.c @@ -348,6 +348,9 @@ static u32 __get_primary_bootmedia(u32 main_devstat) case BOOT_DEVICE_EMMC: return BOOT_DEVICE_MMC1; + case BOOT_DEVICE_NAND: + return BOOT_DEVICE_NAND; + case BOOT_DEVICE_MMC: if ((bootmode_cfg & MAIN_DEVSTAT_PRIMARY_MMC_PORT_MASK) >> MAIN_DEVSTAT_PRIMARY_MMC_PORT_SHIFT) diff --git a/arch/arm/mach-k3/include/mach/am64_spl.h b/arch/arm/mach-k3/include/mach/am64_spl.h index b4f396b2c0..a0a517019c 100644 --- a/arch/arm/mach-k3/include/mach/am64_spl.h +++ b/arch/arm/mach-k3/include/mach/am64_spl.h @@ -22,6 +22,7 @@ #define BOOT_DEVICE_USB0x2A #define BOOT_DEVICE_DFU0x0A +#define BOOT_DEVICE_NAND 0x0B #define BOOT_DEVICE_GPMC_NOR 0x0C #define BOOT_DEVICE_PCIE 0x0D #define BOOT_DEVICE_XSPI 0x0E -- 2.34.1
[PATCH v2 0/4] mtd: omap_gpmc: Fix GPMC & NAND drivers
Hi, When testing the driver with K3 platform, build and functional issues were found in the ti-gpmc and omap_gpmc NAND driver. Fix those. cheers, -roger Changelog: v2: - Added "mtd: rawnand: omap_gpmc: fix OF based partition parsing for NAND". - Dropped defconfig patch. CI test results: https://github.com/u-boot/u-boot/pull/467 v1: https://lore.kernel.org/all/20240109122605.51951-1-rog...@kernel.org/ Roger Quadros (4): memory: ti-gpmc: Fix build mtd: rawnand: omap_gpmc: Use DT provided IO address mtd: rawnand: omap_gpmc: fix OF based partition parsing for NAND arm: mach-k3: am642: Define NAND boot device arch/arm/mach-k3/am642_init.c| 3 +++ arch/arm/mach-k3/include/mach/am64_spl.h | 1 + drivers/memory/ti-gpmc.c | 2 +- drivers/mtd/nand/raw/omap_gpmc.c | 21 - 4 files changed, 21 insertions(+), 6 deletions(-) base-commit: c2c598e87cfe56f5991730762c00733c5aa9a994 prerequisite-patch-id: e0465f3e924302d1c4bd47f2129b4eb3bd9faead -- 2.34.1
[PATCH v2 3/4] mtd: rawnand: omap_gpmc: fix OF based partition parsing for NAND
Set NAND chip ofnode and device so OF based partition parsing can work. Signed-off-by: Roger Quadros --- Notes: v2: initial commit drivers/mtd/nand/raw/omap_gpmc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mtd/nand/raw/omap_gpmc.c b/drivers/mtd/nand/raw/omap_gpmc.c index f827c578d9..b36b6fabae 100644 --- a/drivers/mtd/nand/raw/omap_gpmc.c +++ b/drivers/mtd/nand/raw/omap_gpmc.c @@ -1226,6 +1226,8 @@ static int gpmc_nand_probe(struct udevice *dev) base = devm_ioremap(dev, res.start, resource_size()); gpmc_nand_init(nand, base); + mtd->dev = dev; + nand_set_flash_node(nand, dev_ofnode(dev)); ret = nand_scan(mtd, CONFIG_SYS_NAND_MAX_CHIPS); if (ret) -- 2.34.1
[PATCH v2 2/4] mtd: rawnand: omap_gpmc: Use DT provided IO address
For DM case we can get the NAND chip's IO address from DT
so we don't need to rely on CFG_SYS_NAND_BASE.
Signed-off-by: Roger Quadros
---
Notes:
v2: no change
drivers/mtd/nand/raw/omap_gpmc.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/raw/omap_gpmc.c b/drivers/mtd/nand/raw/omap_gpmc.c
index 0e25bd5dc2..f827c578d9 100644
--- a/drivers/mtd/nand/raw/omap_gpmc.c
+++ b/drivers/mtd/nand/raw/omap_gpmc.c
@@ -8,13 +8,15 @@
#include
#include
#include
-#include
+#include
#include
#ifdef CONFIG_ARCH_OMAP2PLUS
#include
#endif
+#include
+#include
#include
#include
#include
@@ -1124,7 +1126,7 @@ int __maybe_unused omap_nand_switch_ecc(uint32_t
hardware, uint32_t eccstrength)
* nand_scan about special functionality. See the defines for further
* explanation
*/
-int gpmc_nand_init(struct nand_chip *nand)
+int gpmc_nand_init(struct nand_chip *nand, void __iomem *nand_base)
{
int32_t gpmc_config = 0;
int cs = cs_next++;
@@ -1164,7 +1166,7 @@ int gpmc_nand_init(struct nand_chip *nand)
info->control = NULL;
info->cs = cs;
info->ws = wscfg[cs];
- info->fifo = (void __iomem *)CFG_SYS_NAND_BASE;
+ info->fifo = nand_base;
nand_set_controller_data(nand, _nand_info[cs]);
nand->cmd_ctrl = omap_nand_hwcontrol;
nand->options |= NAND_NO_PADDING | NAND_CACHEPRG;
@@ -1214,9 +1216,16 @@ static int gpmc_nand_probe(struct udevice *dev)
{
struct nand_chip *nand = dev_get_priv(dev);
struct mtd_info *mtd = nand_to_mtd(nand);
+ struct resource res;
+ void __iomem *base;
int ret;
- gpmc_nand_init(nand);
+ ret = dev_read_resource(dev, 0, );
+ if (ret)
+ return ret;
+
+ base = devm_ioremap(dev, res.start, resource_size());
+ gpmc_nand_init(nand, base);
ret = nand_scan(mtd, CONFIG_SYS_NAND_MAX_CHIPS);
if (ret)
@@ -1270,7 +1279,7 @@ void board_nand_init(void)
int board_nand_init(struct nand_chip *nand)
{
- return gpmc_nand_init(nand);
+ return gpmc_nand_init(nand, (void __iomem *)CFG_SYS_NAND_BASE);
}
#endif /* CONFIG_SYS_NAND_SELF_INIT */
--
2.34.1
[PATCH v2 1/4] memory: ti-gpmc: Fix build
sys_proto.h no longer exists for K3 platform so drop it.
Include sizes.h to so SZ_16M is visible.
Signed-off-by: Roger Quadros
---
Notes:
v2: no change
drivers/memory/ti-gpmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/ti-gpmc.c b/drivers/memory/ti-gpmc.c
index 775e78c9a5..0b8674339e 100644
--- a/drivers/memory/ti-gpmc.c
+++ b/drivers/memory/ti-gpmc.c
@@ -6,7 +6,6 @@
*/
#include
-#include
#include
#include
#include
@@ -17,6 +16,7 @@
#include
#include
#include
+#include
#include "ti-gpmc.h"
enum gpmc_clk_domain {
--
2.34.1
Re: [PATCH v2 0/2] mtd: nand: omap_gpmc: Fix NAND for AM335x
Hi, On 11/12/2023 13:45, Roger Quadros wrote: > Hi, > > These patches fix NAND and ELM for AM335x and related legacy platforms > that use HW BCH and ELM modules. > > All CI tests pass: https://github.com/u-boot/u-boot/pull/453 > > Changelog: > > v2: > - added __maybe_unused to omap_calculate_ecc_bch. fixes CI tests > - Added Tested-by Tags > - Explained about omap_elm single sector support in commit log > > cheers, > -roger > > Roger Quadros (2): > mtd: nand: omap_gpmc: Fix NAND in SPL for AM335x > mtd: rawnand: omap_elm: Fix elm_init definition > > drivers/mtd/nand/raw/omap_elm.c | 4 +- > drivers/mtd/nand/raw/omap_elm.h | 6 -- > drivers/mtd/nand/raw/omap_gpmc.c | 95 ++-- > 3 files changed, 31 insertions(+), 74 deletions(-) > > > base-commit: 2f0282922b2c458eea7f85c500a948a587437b63 If no objections can this be Acked and picked up please? Without these NAND is broken on some TI platforms. Thanks! -- cheers, -roger
Re: [PATCH v7 15/17] configs: Add am69_sk_* defconfig fragments
On 19/12/2023 21:15, Apurva Nandan wrote: > From: Dasnavis Sabiya > > Add config fragments for am69_sk A72 and R5 configuration. > > This applies on to: > j784s4_evm_a72_defconfig -> am69_sk_a72.config > j784s4_evm_r5_defconfig -> am69_sk_r5.config > > The usage model (with the fragment) would be: > make j784s4_evm_a72_defconfig am69_sk_a72.config > make > > OR > > make j784s4_evm_r5_defconfig am69_sk_r5.config > make > > Signed-off-by: Dasnavis Sabiya > Signed-off-by: Apurva Nandan > --- > configs/am69_sk_a72.config | 3 +++ > configs/am69_sk_r5.config | 3 +++ Shouldn't the config fragments lie in the board//configs directory? Else we will just keep polluting the configs directory. e.g. u-boot$ find . -name "*.config" ./tools/env/fw_env.config ./board/asus/transformer-t30/configs/tf300tl.config ./board/asus/transformer-t30/configs/tf300tg.config ./board/asus/transformer-t30/configs/tf201.config ./board/asus/transformer-t30/configs/tf300t.config ./board/asus/transformer-t30/configs/p1801-t.config ./board/asus/transformer-t30/configs/tf600t.config ./board/asus/transformer-t30/configs/tf700t.config ./board/asus/grouper/configs/grouper_PM269.config ./board/asus/grouper/configs/grouper_E1565.config ./board/asus/grouper/configs/tilapia.config ./board/lg/x3-t30/configs/p880.config ./board/lg/x3-t30/configs/p895.config > 2 files changed, 6 insertions(+) > create mode 100644 configs/am69_sk_a72.config > create mode 100644 configs/am69_sk_r5.config > > diff --git a/configs/am69_sk_a72.config b/configs/am69_sk_a72.config > new file mode 100644 > index 00..5668e23b37 > --- /dev/null > +++ b/configs/am69_sk_a72.config > @@ -0,0 +1,3 @@ > +# Defconfig fragment to apply on top of j784s4_evm_a72_defconfig > + > +CONFIG_DEFAULT_DEVICE_TREE="k3-am69-sk" > diff --git a/configs/am69_sk_r5.config b/configs/am69_sk_r5.config > new file mode 100644 > index 00..9194694393 > --- /dev/null > +++ b/configs/am69_sk_r5.config > @@ -0,0 +1,3 @@ > +# Defconfig fragment to apply on top of j784s4_evm_r5_defconfig > + > +CONFIG_DEFAULT_DEVICE_TREE="k3-am69-r5-sk" -- cheers, -roger
Re: [PATCH 0/4] arm: mach-k3: am64: Add NAND configuration
On 09/01/2024 21:17, Nishanth Menon wrote: > On 14:26-20240109, Roger Quadros wrote: >> Hi, >> >> AM64-EVM [1] supports NAND via expansion card. >> >> This series fixes the GPMC memory and NAND drivers >> and provides NAND configuration for AM642 platform. >> >> The extension card support and NAND DT overlay is >> still missing so NAND is not yet functional just with >> this series. >> >> It was tested with NAND overlay [2] manually applied to base >> AM64-EVM DT. >> >> CI test results are available at >> https://github.com/u-boot/u-boot/pull/460 >> >> [1] https://www.ti.com/tool/TMDS64EVM >> [2] https://lore.kernel.org/all/20230923080046.5373-2-rog...@kernel.org/ >> >> Roger Quadros (4): >> memory: ti-gpmc: Fix build >> mtd: rawnand: omap_gpmc: Use DT provided IO address >> arm: mach-k3: am642: Define NAND boot device >> configs: am64x_evm_a53_defconfig: Enable NAND >> >> arch/arm/mach-k3/am642_init.c| 3 +++ >> arch/arm/mach-k3/include/mach/am64_spl.h | 1 + >> configs/am64x_evm_a53_defconfig | 32 >> drivers/memory/ti-gpmc.c | 2 +- >> drivers/mtd/nand/raw/omap_gpmc.c | 19 ++ >> 5 files changed, 51 insertions(+), 6 deletions(-) > > Please update am64x documentation as well. People will need to know > how to actually build, flash and use it. As NAND is not yet functional till we implement the extension card support and add the NAND overlay. I'll limit this series to platform & driver fixes and leave the defconfig and documentation out for now. > >> >> >> base-commit: c2c598e87cfe56f5991730762c00733c5aa9a994 >> prerequisite-patch-id: e0465f3e924302d1c4bd47f2129b4eb3bd9faead >> -- >> 2.34.1 >> > -- cheers, -roger
Re: [PATCH V2 00/10] board/ti: k3 boards: Stop using findfdt
On 09/01/2024 21:14, Nishanth Menon wrote: > This is a wide cleanup to switch to setting fdtfile using env_set > instead of scripted magic. 'fdtfile' is expected to be set by default. > This allows the stdboot triggered efi loaders to find the correct OS > device tree file even if regular boot process is interrupted by user > intervention. > > This is a refresh of > https://lore.kernel.org/all/86le9dwz4d@udb0321960.dhcp.ti.com/ which > was the wrong approach. > > Updates from V1: > * Renames of variables and macros for various review comments. > * Commit message updates in some patches for clarity. > > Bootlogs: https://gist.github.com/nmenon/843e343cde645ec4aa57b60cece5256a > > based on master: c5e461fbf7cc Merge tag 'u-boot-imx-master-20240108' of > https://gitlab.denx.de/u-boot/custodians/u-boot-imx > > NOTE: There are a couple of checkpatch WARN (around LATE_INIT) and > CHECK (fdt_ops #ifdeffery) that on closer inspection looks fine and > consistent with other similar usage. > > V1: https://lore.kernel.org/all/20240108173301.2692332-1...@ti.com/ > > Nishanth Menon (10): > board: ti: common: Introduce a common fdt ops library > board: ti: am62ax: Set fdtfile from C code instead of findfdt script > board: ti: am62x: Set fdtfile from C code instead of findfdt script > board: ti: am64x: Set fdtfile from C code instead of findfdt script > board: ti: am65x: Set fdtfile from C code instead of findfdt script > board: ti: j721e: Set fdtfile from C code instead of findfdt script > board: ti: j721s2: Set fdtfile from C code instead of findfdt script > board: beagle: beagleboneai64: Set fdtfile from C code instead of > findfdt script > board: beagle: beagleplay: Set fdtfile from C code instead of findfdt > script > include: env: ti: Drop default_findfdt For this series: Reviewed-by: Roger Quadros -- cheers, -roger
Re: [PATCH V2 10/10] include: env: ti: Drop default_findfdt
On 09/01/2024 21:15, Nishanth Menon wrote:
> We shouldn't need finfdt anymore. Drop the env script.
>
> Signed-off-by: Nishanth Menon
> ---
> Changes from V1: None.
>
> V1: https://lore.kernel.org/r/20240108173301.2692332-11...@ti.com
> include/env/ti/default_findfdt.env | 12
> 1 file changed, 12 deletions(-)
> delete mode 100644 include/env/ti/default_findfdt.env
>
> diff --git a/include/env/ti/default_findfdt.env
> b/include/env/ti/default_findfdt.env
> deleted file mode 100644
> index a2b51dd923bb..
> --- a/include/env/ti/default_findfdt.env
> +++ /dev/null
> @@ -1,12 +0,0 @@
> -default_device_tree=CONFIG_DEFAULT_DEVICE_TREE
> -default_device_tree_arch=ti
> -#ifdef CONFIG_ARM64
> -findfdt=
> - setenv name_fdt ${default_device_tree_arch}/${default_device_tree}.dtb;
> - setenv fdtfile ${name_fdt}
> -#else
> -default_device_tree_subarch=omap
> -findfdt=
> - setenv name_fdt
> ${default_device_tree_arch}/${default_device_tree_subarch}/${default_device_tree}.dtb;
> - setenv fdtfile ${name_fdt}
> -#endif
FYI. findfdt is still used in:
am335x_baltos_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run usbboot;run
mmcboot;setenv mmcdev 1; setenv bootpart 1:2; run mmcboot;run nandboot;"
am335x_boneblack_vboot_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run
init_console; run finduuid; run distro_bootcmd"
am335x_evm_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run init_console; run
finduuid; run distro_bootcmd"
am335x_evm_spiboot_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run init_console;
run finduuid; run distro_bootcmd"
am335x_hs_evm_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run init_console; run
finduuid; run distro_bootcmd"
am335x_hs_evm_uart_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run init_console;
run finduuid; run distro_bootcmd"
am335x_igep003x_defconfig:CONFIG_BOOTCOMMAND="run findfdt;run mmcboot;run
nandboot;run netboot;"
am43xx_evm_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run
distro_bootcmd"
am43xx_evm_qspiboot_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run finduuid;
run distro_bootcmd"
am43xx_evm_rtconly_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run
distro_bootcmd"
am43xx_evm_usbhost_boot_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run
finduuid; run distro_bootcmd"
am43xx_hs_evm_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run
distro_bootcmd"
am43xx_hs_evm_qspi_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run
distro_bootcmd"
am57xx_evm_defconfig:CONFIG_BOOTCOMMAND="if test ${dofastboot} -eq 1; then echo
Boot fastboot requested, resetting dofastboot ...;setenv dofastboot 0;
saveenv;echo Booting into fastboot ...; fastboot 1;fi;if test ${boot_fit} -eq
1; then run update_to_fit;fi;run findfdt; run finduuid; run distro_bootcmd;run
emmc_android_boot; "
am57xx_hs_evm_defconfig:CONFIG_BOOTCOMMAND="if test ${dofastboot} -eq 1; then
echo Boot fastboot requested, resetting dofastboot ...;setenv dofastboot 0;
saveenv;echo Booting into fastboot ...; fastboot 1;fi;if test ${boot_fit} -eq
1; then run update_to_fit;fi;run findfdt; run finduuid; run distro_bootcmd;run
emmc_android_boot; "
am57xx_hs_evm_usb_defconfig:CONFIG_BOOTCOMMAND="if test ${dofastboot} -eq 1;
then echo Boot fastboot requested, resetting dofastboot ...;setenv dofastboot
0; saveenv;echo Booting into fastboot ...; fastboot 1;fi;if test ${boot_fit}
-eq 1; then run update_to_fit;fi;run findfdt; run finduuid; run
distro_bootcmd;run emmc_android_boot; "
am65x_evm_a53_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run distro_bootcmd;
run init_${boot}; run boot_rprocs; if test ${boot_fit} -eq 1; then run
get_fit_${boot}; run get_overlaystring; run run_fit; else; run
get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern;
fi;"
dra7xx_evm_defconfig:CONFIG_BOOTCOMMAND="if test ${dofastboot} -eq 1; then echo
Boot fastboot requested, resetting dofastboot ...;setenv dofastboot 0;
saveenv;echo Booting into fastboot ...; fastboot 1;fi;if test ${boot_fit} -eq
1; then run update_to_fit;fi;run findfdt; run finduuid; run distro_bootcmd;run
emmc_android_boot; "
dra7xx_hs_evm_defconfig:CONFIG_BOOTCOMMAND="if test ${dofastboot} -eq 1; then
echo Boot fastboot requested, resetting dofastboot ...;setenv dofastboot 0;
saveenv;echo Booting into fastboot ...; fastboot 1;fi;if test ${boot_fit} -eq
1; then run update_to_fit;fi;run findfdt; run finduuid; run distro_bootcmd;run
emmc_android_boot; "
dra7xx_hs_evm_usb_defconfig:CONFIG_BOOTCOMMAND="if test ${dofastboot} -eq 1;
then echo Boot fastboot requested, resetting dofastboot ...;setenv dofastboot
0; saveenv;echo Booting into fastboot ...; fastboot 1;fi;if test ${boot_fit}
-eq 1; then run update_to_fit;fi;run findfdt; run finduuid; run
distro_bootcmd;run emmc_android_boot; "
k2g_evm_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run envboot; run
init_${boot}; run get_mon_${boot} run_mon; run set_name_pmmc get_pmmc_${boot}
run_pmmc; run get_kern_${boot}; run
Re: [PATCH 4/4] configs: am64x_evm_a53_defconfig: Enable NAND
+Lukasz & Mattijs On 10/01/2024 11:34, Roger Quadros wrote: > > > On 09/01/2024 22:00, Francesco Dolcini wrote: >> On Tue, Jan 09, 2024 at 02:54:00PM -0500, Tom Rini wrote: >>> On Tue, Jan 09, 2024 at 01:18:59PM -0600, Nishanth Menon wrote: >>>> On 14:26-20240109, Roger Quadros wrote: >>>>> CONFIG_CMD_PMIC=y >>>>> CONFIG_CMD_REGULATOR=y >>>>> +CONFIG_CMD_MTDPARTS=y >>>>> +CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0" >>>>> +CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:2m(NAND.tiboot3),2m(NAND.tispl),2m(NAND.tiboot3.backup),4m(NAND.u-boot),256k(NAND.u-boot-env),256k(NAND.u-boot-env.backup),-(NAND.file-system)" >>>> >>>> Why not handle this as device tree partitions? >>> >>> I honestly forget what the preferred way of defining and passing NAND >>> partition information is these days. It might even be the funny case >>> that passing as cmdline args is "best" rather than fixed-partitions >>> binding? >> >> According to past discussions [1] doing the fixup in U-Boot is not advised. >> >> Using the command line or having the partition fixed in the DT are both >> valid options. >> >> [1] https://lore.kernel.org/all/20230206224838.75963-1-france...@dolcini.it/ >> >> Francesco >> > > This was not about passing mtdparts to kernel but about getting 'mtdparts' > command > to work at u-boot. I need to figure out why OF partition parser didn't work > here. > > For a start I didn't have CONFIG_MTD_PARTITIONS set. Maybe I'm missing > something more. > The issue was the NAND driver was not setting chip->dev and chip->ofnode correctly. Now 'mtd list' shows partitions from the DT. But, 'dfu 0 nand list' still fails like so. "mtdparts variable not set, see 'help mtdparts'" Looks like dfu_nand driver doesn't fall back to OF partitions if mtdparts environment is not defined. Should we add OF partitions support to dfu_nand driver or is it deprecated in favor of dfu_mtd driver? -- cheers, -roger
