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
Re: [RFC PATCH 12/16] arm: dts: k3-am65x-binman: Add ICSSG2 overlay and configuration
On 10/01/2024 11:02, MD Danish Anwar wrote:
>
>
> On 10/01/24 2:24 pm, Roger Quadros wrote:
>> On 10/01/2024 08:50, MD Danish Anwar wrote:
>>> Hi Roger,
>>>
>>> On 27/12/23 3:49 pm, MD Danish Anwar wrote:
>>>> On 20/12/23 4:10 pm, Roger Quadros wrote:
>>>>>
>>>>>
>>>>> On 19/12/2023 12:34, MD Danish Anwar wrote:
>>>>>> Add ICSSG2 overlay and configuration to tispl and u-boot images.
>>>>>>
>>>>>> Signed-off-by: MD Danish Anwar
>>>>>> ---
>>>>>> arch/arm/dts/k3-am65x-binman.dtsi | 85 +++
>>>>>> 1 file changed, 85 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/dts/k3-am65x-binman.dtsi
>>>>>> b/arch/arm/dts/k3-am65x-binman.dtsi
>>>>>> index 8cc24da1f3..9a0c0fca47 100644
>>>>>> --- a/arch/arm/dts/k3-am65x-binman.dtsi
>>>>>> +++ b/arch/arm/dts/k3-am65x-binman.dtsi
>>>>>> @@ -98,6 +98,8 @@
>>>>>> #define SPL_AM654_EVM_DTB "spl/dts/k3-am654-base-board.dtb"
>>>>>> #define AM654_EVM_DTB "u-boot.dtb"
>>>>>>
>>>>>> +#define AM654_EVM_ICSSG2_DTBO "arch/arm/dts/k3-am654-icssg2.dtbo"
>>>>>> +
>>>>>> {
>>>>>> ti-spl {
>>>>>> insert-template = <_spl_template>;
>>>>>> @@ -124,6 +126,20 @@
>>>>>> filename =
>>>>>> SPL_AM654_EVM_DTB;
>>>>>> };
>>>>>> };
>>>>>> +
>>>>>> +fdt-1 {
>>>>>> +description = "k3-am654-icssg2
>>>>>> overlay";
>>>>>> +type = "flat_dt";
>>>>>> +arch = "arm";
>>>>>> +compression = "none";
>>>>>> +ti-secure {
>>>>>> +content =
>>>>>> <_am65x_evm_icssg2_dtb>;
>>>>>> +keyfile = "custMpk.pem";
>>>>>> +};
>>>>>> +spl_am65x_evm_icssg2_dtb:
>>>>>> blob-ext {
>>>>>> +filename =
>>>>>> AM654_EVM_ICSSG2_DTBO;
>>>>>> +};
>>>>>
>>>>> This is wrong.
>>>>>
>>>>> ICSSG2 Ethernet should be part of the fdt-0 configuration as the 2
>>>>> Ethernet ports
>>>>> on the board are hardwired to ICSSG2. Not having them working by default
>>>>> is an invalid configuration.
>>>>>
>>>>
>>>> ICSSG2 ethernet ports should be enabled by default. But the ICSSG2 nodes
>>>> is added in the overlay file (k3-am654-icssg2.dtso) in kernel so they
>>>> are added in same overlay file in u-boot as well.
>>>>
>>>> I am keeping,
>>>> fdt-0 as k3-am654-base-board dtb,
>>>> fdt-1 as k3-am654-icssg2 dtbo,
>>>> conf-0 as k3-am654-base-board and
>>>> conf-1 as k3-am654-icssg2.
>>>>
>>>> Do you want me to keep k3-am654-icssg2 dtbo as fdt-0 and
>>>> k3-am654-base-board as fdt-1? I tried doing this but this results into
>>>> u-boot getting stuck. The tispl and u-boot images are not able to load
>>>> if I swap fdt-0 and fdt-1 , and conf-0 and conf-1.
>>>>
>>>> If the current combination doesn't look OK, please let me know what
>>>> should be the correct combinations for fdt-0, fdt-1, conf-0 and conf-1.
>>>>
>>>
>>> Can you please comment on this. I'll send v2 with all the suggested
>>> changes once you confirm the correct fdt and configurations.
>>>
>> Sorry, I missed this.
>>
>> fdt-0 = k3-am654-base-board dtb
>> fdt-1 = k3-am654-icssg2 dtbo
>>
>> conf-0 = fdt-0 and ftd-1
>>
>
> What about conf-1? Should I leave it as it is(currently conf-1 is fdt-0
> and fdt-1)?
I don't think we need conf-1.
>
>> as icssg2 ethernet is present on the base board, and should be part of the
>> base board configuration.
>>
>
--
cheers,
-roger
Re: [PATCH 4/4] configs: am64x_evm_a53_defconfig: Enable NAND
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. -- cheers, -roger
Re: [RFC PATCH 12/16] arm: dts: k3-am65x-binman: Add ICSSG2 overlay and configuration
On 10/01/2024 08:50, MD Danish Anwar wrote:
> Hi Roger,
>
> On 27/12/23 3:49 pm, MD Danish Anwar wrote:
>> On 20/12/23 4:10 pm, Roger Quadros wrote:
>>>
>>>
>>> On 19/12/2023 12:34, MD Danish Anwar wrote:
>>>> Add ICSSG2 overlay and configuration to tispl and u-boot images.
>>>>
>>>> Signed-off-by: MD Danish Anwar
>>>> ---
>>>> arch/arm/dts/k3-am65x-binman.dtsi | 85 +++
>>>> 1 file changed, 85 insertions(+)
>>>>
>>>> diff --git a/arch/arm/dts/k3-am65x-binman.dtsi
>>>> b/arch/arm/dts/k3-am65x-binman.dtsi
>>>> index 8cc24da1f3..9a0c0fca47 100644
>>>> --- a/arch/arm/dts/k3-am65x-binman.dtsi
>>>> +++ b/arch/arm/dts/k3-am65x-binman.dtsi
>>>> @@ -98,6 +98,8 @@
>>>> #define SPL_AM654_EVM_DTB "spl/dts/k3-am654-base-board.dtb"
>>>> #define AM654_EVM_DTB "u-boot.dtb"
>>>>
>>>> +#define AM654_EVM_ICSSG2_DTBO "arch/arm/dts/k3-am654-icssg2.dtbo"
>>>> +
>>>> {
>>>>ti-spl {
>>>>insert-template = <_spl_template>;
>>>> @@ -124,6 +126,20 @@
>>>>filename = SPL_AM654_EVM_DTB;
>>>>};
>>>>};
>>>> +
>>>> + fdt-1 {
>>>> + description = "k3-am654-icssg2 overlay";
>>>> + type = "flat_dt";
>>>> + arch = "arm";
>>>> + compression = "none";
>>>> + ti-secure {
>>>> + content =
>>>> <_am65x_evm_icssg2_dtb>;
>>>> + keyfile = "custMpk.pem";
>>>> + };
>>>> + spl_am65x_evm_icssg2_dtb: blob-ext {
>>>> + filename =
>>>> AM654_EVM_ICSSG2_DTBO;
>>>> + };
>>>
>>> This is wrong.
>>>
>>> ICSSG2 Ethernet should be part of the fdt-0 configuration as the 2 Ethernet
>>> ports
>>> on the board are hardwired to ICSSG2. Not having them working by default
>>> is an invalid configuration.
>>>
>>
>> ICSSG2 ethernet ports should be enabled by default. But the ICSSG2 nodes
>> is added in the overlay file (k3-am654-icssg2.dtso) in kernel so they
>> are added in same overlay file in u-boot as well.
>>
>> I am keeping,
>> fdt-0 as k3-am654-base-board dtb,
>> fdt-1 as k3-am654-icssg2 dtbo,
>> conf-0 as k3-am654-base-board and
>> conf-1 as k3-am654-icssg2.
>>
>> Do you want me to keep k3-am654-icssg2 dtbo as fdt-0 and
>> k3-am654-base-board as fdt-1? I tried doing this but this results into
>> u-boot getting stuck. The tispl and u-boot images are not able to load
>> if I swap fdt-0 and fdt-1 , and conf-0 and conf-1.
>>
>> If the current combination doesn't look OK, please let me know what
>> should be the correct combinations for fdt-0, fdt-1, conf-0 and conf-1.
>>
>
> Can you please comment on this. I'll send v2 with all the suggested
> changes once you confirm the correct fdt and configurations.
>
Sorry, I missed this.
fdt-0 = k3-am654-base-board dtb
fdt-1 = k3-am654-icssg2 dtbo
conf-0 = fdt-0 and ftd-1
as icssg2 ethernet is present on the base board, and should be part of the base
board configuration.
--
cheers,
-roger
Re: [PATCH 06/10] board: ti: j721e: Set fdtfile from C code instead of findfdt script
On 08/01/2024 19:32, Nishanth Menon wrote:
> We now can provide a map and have the standard fdtfile variable set from
> code itself. This allows for bootstd to "just work".
>
> While at this, replace findfdt in environment with a warning as it is no
> longer needed.
>
> Signed-off-by: Nishanth Menon
> ---
> board/ti/j721e/evm.c | 8
> board/ti/j721e/j721e.env | 10 --
> 2 files changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
> index c541880107ec..ad6ef4553e04 100644
> --- a/board/ti/j721e/evm.c
> +++ b/board/ti/j721e/evm.c
> @@ -16,6 +16,7 @@
> #include
>
> #include "../common/board_detect.h"
> +#include "../common/fdt_ops.h"
>
> #define board_is_j721e_som() (board_ti_k3_is("J721EX-PM1-SOM") || \
>board_ti_k3_is("J721EX-PM2-SOM"))
> @@ -424,6 +425,12 @@ void configure_serdes_sierra(void)
> }
>
> #ifdef CONFIG_BOARD_LATE_INIT
> +static struct ti_fdt_map ti_j721e_evm_fdt_map[] = {
> + {"j721e", "k3-j721e-common-proc-board.dtb"},
> + {"j721e-sk", "k3-j721e-sk.dtb"},
You missed "j721e-eaik"
> + {"j7200", "k3-j7200-common-proc-board.dtb"},
> + { /* Sentinel. */ }
> +};
> static void setup_board_eeprom_env(void)
> {
> char *name = "j721e";
> @@ -443,6 +450,7 @@ static void setup_board_eeprom_env(void)
>
> invalid_eeprom:
> set_board_info_env_am6(name);
> + ti_set_fdt_env(name, ti_j721e_evm_fdt_map);
> }
>
> static void setup_serial(void)
> diff --git a/board/ti/j721e/j721e.env b/board/ti/j721e/j721e.env
> index cb27bf5e2b24..38bfd7d49634 100644
> --- a/board/ti/j721e/j721e.env
> +++ b/board/ti/j721e/j721e.env
> @@ -7,16 +7,6 @@
> #include
> #endif
>
> -default_device_tree=ti/k3-j721e-common-proc-board.dtb
> -findfdt=
> - setenv name_fdt ${default_device_tree};
> - if test $board_name = j721e; then
> - setenv name_fdt ti/k3-j721e-common-proc-board.dtb; fi;
> - if test $board_name = j7200; then
> - setenv name_fdt ti/k3-j7200-common-proc-board.dtb; fi;
> - if test $board_name = j721e-eaik || test $board_name = j721e-sk; then
> - setenv name_fdt ti/k3-j721e-sk.dtb; fi;
> - setenv fdtfile ${name_fdt}
> name_kern=Image
> console=ttyS2,115200n8
> args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280
--
cheers,
-roger
Re: [PATCH 01/10] board: ti: common: Introduce a common fdt ops library
On 08/01/2024 19:32, Nishanth Menon wrote:
> Introduce a common fdt operations library for basic device tree
> operations that are common between various boards.
>
> The first library to introduce here is the capability to set up
> fdtfile as a standard variable as part of board identification rather
> than depend on scripted ifdeffery.
>
> Signed-off-by: Nishanth Menon
> ---
> board/ti/common/Kconfig | 12
> board/ti/common/Makefile | 1 +
> board/ti/common/fdt_ops.c | 65 +++
> board/ti/common/fdt_ops.h | 41
> 4 files changed, 119 insertions(+)
> create mode 100644 board/ti/common/fdt_ops.c
> create mode 100644 board/ti/common/fdt_ops.h
>
> diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
> index 49edd98014ab..06a8a36aa1cd 100644
> --- a/board/ti/common/Kconfig
> +++ b/board/ti/common/Kconfig
> @@ -49,3 +49,15 @@ config TI_COMMON_CMD_OPTIONS
> imply CMD_SPI
> imply CMD_TIME
> imply CMD_USB if USB
> +
> +config TI_EVM_FDT_FOLDER_PATH
> + string "Location of Folder path where dtb is present"
> + default "ti/davinci" if ARCH_DAVINCI
> + default "ti/keystone" if ARCH_KEYSTONE
> + default "ti/omap" if ARCH_OMAP2PLUS
> + default "ti" if ARCH_K3
> + depends on ARCH_DAVINCI || ARCH_KEYSTONE || ARCH_OMAP2PLUS || ARCH_K3
> + help
> +Folder path for kernel device tree default.
> +This is used along with fdtfile path to locate the kernel
> +device tree blob.
> diff --git a/board/ti/common/Makefile b/board/ti/common/Makefile
> index 26bf12e2e6d5..5ac361ba7fcf 100644
> --- a/board/ti/common/Makefile
> +++ b/board/ti/common/Makefile
> @@ -3,3 +3,4 @@
>
> obj-${CONFIG_TI_I2C_BOARD_DETECT} += board_detect.o
> obj-${CONFIG_CMD_EXTENSION} += cape_detect.o
> +obj-${CONFIG_OF_LIBFDT} += fdt_ops.o
> diff --git a/board/ti/common/fdt_ops.c b/board/ti/common/fdt_ops.c
> new file mode 100644
> index ..f8770cae4a54
> --- /dev/null
> +++ b/board/ti/common/fdt_ops.c
> @@ -0,0 +1,65 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Library to support FDT file operations which are common
> + *
> + * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +#include
> +#include
> +#include "fdt_ops.h"
> +
> +void ti_set_fdt_env(const char *name_fdt, struct ti_fdt_map *fdt_map)
> +{
> + char *fdt_file_name = NULL;
> + char fdtfile[TI_FDT_FILE_MAX];
> +
> + if (name_fdt) {
> + while (fdt_map) {
> + /* Check for NULL terminator in the list */
> + if (!fdt_map->name_fdt)
> + break;
> + if (!strncmp(fdt_map->name_fdt, name_fdt,
> TI_NAME_FDT_MAX)) {
> + fdt_file_name = fdt_map->fdt_file_name;
> + break;
> + }
> + fdt_map++;
> + }
> + }
> +
> + /* match not found OR null name_fdt */
> + if (!fdt_file_name) {
> + /*
> + * Prioritize CONFIG_DEFAULT_FDT_FILE - if that is not defined,
> + * or is empty, then use CONFIG_DEFAULT_DEVICE_TREE
> + */
> +#ifdef CONFIG_DEFAULT_FDT_FILE
> + if (strlen(CONFIG_DEFAULT_FDT_FILE)) {
> + snprintf(fdtfile, sizeof(fdtfile), "%s/%s",
> + CONFIG_TI_EVM_FDT_FOLDER_PATH,
> CONFIG_DEFAULT_FDT_FILE);
> + } else
> +#endif
> + {
> + snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
> + CONFIG_TI_EVM_FDT_FOLDER_PATH,
> + CONFIG_DEFAULT_DEVICE_TREE);
> + }
> + } else {
> + snprintf(fdtfile, sizeof(fdtfile), "%s/%s",
> CONFIG_TI_EVM_FDT_FOLDER_PATH,
> + fdt_file_name);
> + }
> +
> + env_set("fdtfile", fdtfile);
> +
> + /*
> + * XXX: DEPRECATION WARNING: 2 u-boot versions.
> + *
> + * Maintain compatibility with downstream scripts that may be using
> + * name_fdt
> + */
> + if (name_fdt)
> + env_set("name_fdt", name_fdt);
> + /* Also set the findfdt legacy script to warn users to stop using this
> */
> + env_set("findfdt",
> + "echo WARN: fdtfile already set. Stop using findfdt in script");
> +}
> diff --git a/board/ti/common/fdt_ops.h b/board/ti/common/fdt_ops.h
> new file mode 100644
> index ..c01697bed28f
> --- /dev/null
> +++ b/board/ti/common/fdt_ops.h
> @@ -0,0 +1,41 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Library to support common device tree manipulation for TI EVMs
> + *
> + * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com
> + */
> +
> +#ifndef __FDT_OPS_H
> +#define __FDT_OPS_H
> +
> +#define TI_NAME_FDT_MAX 20
> +#define TI_FDT_FILE_MAX 200
> +
> +/**
> + * struct
Re: [PATCH 04/10] board: ti: am64x: Set fdtfile from C code instead of findfdt script
On 08/01/2024 19:32, Nishanth Menon wrote:
> We now can provide a map and have the standard fdtfile variable set from
> code itself. This allows for bootstd to "just work".
>
> While at this, replace findfdt in environment with a warning as it is no
> longer needed.
>
> Signed-off-by: Nishanth Menon
> ---
> board/ti/am64x/am64x.env | 9 -
> board/ti/am64x/evm.c | 8
> 2 files changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/board/ti/am64x/am64x.env b/board/ti/am64x/am64x.env
> index efd736b99be4..9a8812d4ee54 100644
> --- a/board/ti/am64x/am64x.env
> +++ b/board/ti/am64x/am64x.env
> @@ -2,14 +2,6 @@
> #include
> #include
>
> -findfdt=
> - if test $board_name = am64x_gpevm; then
> - setenv name_fdt ti/k3-am642-evm.dtb; fi;
> - if test $board_name = am64x_skevm; then
> - setenv name_fdt ti/k3-am642-sk.dtb; fi;
> - if test $name_fdt = undefined; then
> - echo WARNING: Could not determine device tree to use; fi;
> - setenv fdtfile ${name_fdt}
> name_kern=Image
> console=ttyS2,115200n8
> args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280 ${mtdparts}
> @@ -43,7 +35,6 @@ get_fit_usb=load usb ${bootpart} ${addr_fit}
> usbboot=setenv boot usb;
> setenv bootpart 0:2;
> usb start;
> - run findfdt;
> run init_usb;
> run get_kern_usb;
> run get_fdt_usb;
> diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
> index a6dcff2eb434..e2f506d2c6ea 100644
> --- a/board/ti/am64x/evm.c
> +++ b/board/ti/am64x/evm.c
> @@ -16,6 +16,7 @@
> #include
>
> #include "../common/board_detect.h"
> +#include "../common/fdt_ops.h"
>
> #define board_is_am64x_gpevm() (board_ti_k3_is("AM64-GPEVM") || \
> board_ti_k3_is("AM64-HSEVM"))
> @@ -180,6 +181,12 @@ int checkboard(void)
> }
>
> #ifdef CONFIG_BOARD_LATE_INIT
> +static struct ti_fdt_map ti_am64_evm_fdt_map[] = {
> + {"am64x_gpevm", "k3-am642-evm.dtb"},
> + {"am64x_skevm", "k3-am642-sk.dtb"},
"am64x_gpevm" and "am64x_skevm" strings are used multiple times in this file.
see setup_board_eeprom_env()
Please use a MACRO for them.
What is the logic of choosing this name and can it be updated at this point?
e.g."gp" is misleading in the board name as the boards are now shipped with
HS-FS chip and are no longer GP.
> + { /* Sentinel. */ }
> +};
> +
> static void setup_board_eeprom_env(void)
> {
> char *name = "am64x_gpevm";
> @@ -197,6 +204,7 @@ static void setup_board_eeprom_env(void)
>
> invalid_eeprom:
> set_board_info_env_am6(name);
> + ti_set_fdt_env(name, ti_am64_evm_fdt_map);
> }
>
> static void setup_serial(void)
--
cheers,
-roger
Re: [RFC PATCH 00/16] Introduce ICSSG Ethernet driver
On 09/01/2024 11:49, MD Danish Anwar wrote: > > > On 09/01/24 2:56 pm, Roger Quadros wrote: >> >> >> On 08/01/2024 12:25, MD Danish Anwar wrote: >>> On 08/01/24 3:00 pm, Roger Quadros wrote: >>>> >>>> >>>> On 05/01/2024 12:15, Anwar, Md Danish wrote: >>>>> >>>>> >>>>> On 1/5/2024 1:49 PM, Roger Quadros wrote: >>>>>> >>>>>> >>>>>> On 03/01/2024 12:27, MD Danish Anwar wrote: >>>>>>> >>>>>>> >>>>>>> On 02/01/24 7:26 pm, Andrew Davis wrote: >>>>>>>> On 12/27/23 12:56 AM, MD Danish Anwar wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 22/12/23 6:13 pm, Roger Quadros wrote: >>>>>>>>>> >>>>>>>>>> On 22/12/2023 12:26, MD Danish Anwar wrote: >>>>>>>>>>> Hi Roger, >>>>>>>>>>> >>>>>>>>>>> On 20/12/23 3:29 pm, Roger Quadros wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> On 19/12/2023 12:11, MD Danish Anwar wrote: >>>>>>>>>>>>> Introduce ICSSG PRUETH support in uboot. The ICSSG driver is used >>>>>>>>>>>>> in TI >>>>>>>>>>>>> AM654 SR2.0. >>>>>>>>>>>>> >>>>>>>>>>>>> The ICSSG PRU Sub-system runs on EMAC firmware. This series >>>>>>>>>>>>> Introduces >>>>>>>>>>>>> support for ICSSG driver in uboot. This series also adds the >>>>>>>>>>>>> driver's >>>>>>>>>>>>> dependencies. >>>>>>>>>>>>> >>>>>>>>>>>>> The ICSSG2 node is added in device tree overlay so that it >>>>>>>>>>>>> remains in >>>>>>>>>>>>> sync with linux kernel. >>>>>>>>>>>>> >>>>>>>>>>>>> The series introduces device tree and config changes and AM65x >>>>>>>>>>>>> to enable ICSSG driver. The series also enables >>>>>>>>>>>>> SPL_LOAD_FIT_APPLY_OVERLAY >>>>>>>>>>>>> for AM65x in order to load overlay over spl. >>>>>>>>>>>>> >>>>>>>>>>>>> This series has been tested on AM65x SR2.0, and the ICSSG >>>>>>>>>>>>> interface is >>>>>>>>>>>>> able to ping / dhcp and boot kernel using tftp in uboot. >>>>>>>>>>>>> >>>>>>>>>>>>> To use ICSSG2 ethernet, the ICSSG firmware needs to be loaded to >>>>>>>>>>>>> PRU RPROC >>>>>>>>>>>>> cores and RPROC cores need to be booted with the firmware. This >>>>>>>>>>>>> step is >>>>>>>>>>>>> done inside driver in kernel as kernel supports APIs like >>>>>>>>>>>>> rproc_set_firmware() and rproc_fw_boot(). But as u-boot doesn't >>>>>>>>>>>>> have these >>>>>>>>>>>>> APIs, the same needs to be done via u-boot cmds. >>>>>>>>>>>>> >>>>>>>>>>>>> To make sure icssg-eth works we need to do below steps. >>>>>>>>>>>>> >>>>>>>>>>>>> 1. Initialize rproc cores i.e. rproc_init() >>>>>>>>>>>>> 2. Load $firmware_file from partition '1:2' (root) on device (mmc >>>>>>>>>>>>> in this >>>>>>>>>>>>> example) >>>>>>>>>>>>> 3. Load the firmware file to rproc cores passing. i.e. >>>>>>>>>>>>> rproc_load() >>>>>>>>>>>>> taking rproc_id, loadaddr and file size as arguments. >>>>>>>>>>>>> 4. Start rproc cores. i.e. rproc_start() taking rproc_id as
[PATCH 4/4] configs: am64x_evm_a53_defconfig: Enable NAND
Enables configuration required for NAND in SPL and u-boot. Enable MTD Driver model and MTD + UBI command line utilities. Add mtdids/mtdparts for NAND as it is required for u-boot's MTD subsystem commands to recognize NAND partitions. Add u-boot partition location. Signed-off-by: Roger Quadros --- configs/am64x_evm_a53_defconfig | 32 1 file changed, 32 insertions(+) diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig index 05e35a8db6..e22153a958 100644 --- a/configs/am64x_evm_a53_defconfig +++ b/configs/am64x_evm_a53_defconfig @@ -66,10 +66,15 @@ CONFIG_CMD_DFU=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_MTD=y CONFIG_CMD_USB=y CONFIG_CMD_TIME=y 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)" +CONFIG_CMD_UBI=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y CONFIG_OF_LIST="k3-am642-evm k3-am642-sk" @@ -107,6 +112,9 @@ CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ADMA=y CONFIG_SPL_MMC_SDHCI_ADMA=y CONFIG_MMC_SDHCI_AM654=y +CONFIG_MTD=y +CONFIG_SPL_MTD=y +CONFIG_DM_MTD=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y @@ -161,3 +169,27 @@ CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_USB_FUNCTION_MASS_STORAGE=y CONFIG_SPL_DFU=y CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 +CONFIG_MEMORY=y +CONFIG_SPL_MEMORY=y +CONFIG_TI_GPMC=y +CONFIG_MTD_RAW_NAND=y +CONFIG_NAND_OMAP_GPMC=y +CONFIG_CMD_NAND=y +CONFIG_NAND_OMAP_ELM=y +CONFIG_NAND_OMAP_ECCSCHEME_BCH8_CODE_HW=y +CONFIG_SYS_NAND_BLOCK_SIZE=0x4 +CONFIG_SYS_NAND_ONFI_DETECTION=y +CONFIG_SYS_NAND_PAGE_SIZE=0x1000 +CONFIG_SYS_NAND_PAGE_COUNT=0x40 +CONFIG_SYS_NAND_OOBSIZE=0x100 +CONFIG_SPL_NAND_SUPPORT=y +CONFIG_SPL_NAND_DRIVERS=y +CONFIG_SPL_NAND_BASE=y +CONFIG_SPL_NAND_IDENT=y +CONFIG_SPL_NAND_ECC=y +CONFIG_SYS_NAND_MAX_CHIPS=1 +CONFIG_SYS_MAX_NAND_DEVICE=1 +# CONFIG_SPL_NAND_AM33XX_BCH is not set +CONFIG_SPL_MTD_SUPPORT=y +CONFIG_SYS_NAND_U_BOOT_LOCATIONS=y +CONFIG_SYS_NAND_U_BOOT_OFFS=0x60 -- 2.34.1
[PATCH 3/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 --- 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 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
---
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 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
---
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
[PATCH 0/4] arm: mach-k3: am64: Add NAND configuration
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(-) base-commit: c2c598e87cfe56f5991730762c00733c5aa9a994 prerequisite-patch-id: e0465f3e924302d1c4bd47f2129b4eb3bd9faead -- 2.34.1
Re: [RFC PATCH 00/16] Introduce ICSSG Ethernet driver
On 08/01/2024 12:25, MD Danish Anwar wrote: > On 08/01/24 3:00 pm, Roger Quadros wrote: >> >> >> On 05/01/2024 12:15, Anwar, Md Danish wrote: >>> >>> >>> On 1/5/2024 1:49 PM, Roger Quadros wrote: >>>> >>>> >>>> On 03/01/2024 12:27, MD Danish Anwar wrote: >>>>> >>>>> >>>>> On 02/01/24 7:26 pm, Andrew Davis wrote: >>>>>> On 12/27/23 12:56 AM, MD Danish Anwar wrote: >>>>>>> >>>>>>> >>>>>>> On 22/12/23 6:13 pm, Roger Quadros wrote: >>>>>>>> >>>>>>>> On 22/12/2023 12:26, MD Danish Anwar wrote: >>>>>>>>> Hi Roger, >>>>>>>>> >>>>>>>>> On 20/12/23 3:29 pm, Roger Quadros wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On 19/12/2023 12:11, MD Danish Anwar wrote: >>>>>>>>>>> Introduce ICSSG PRUETH support in uboot. The ICSSG driver is used >>>>>>>>>>> in TI >>>>>>>>>>> AM654 SR2.0. >>>>>>>>>>> >>>>>>>>>>> The ICSSG PRU Sub-system runs on EMAC firmware. This series >>>>>>>>>>> Introduces >>>>>>>>>>> support for ICSSG driver in uboot. This series also adds the >>>>>>>>>>> driver's >>>>>>>>>>> dependencies. >>>>>>>>>>> >>>>>>>>>>> The ICSSG2 node is added in device tree overlay so that it remains >>>>>>>>>>> in >>>>>>>>>>> sync with linux kernel. >>>>>>>>>>> >>>>>>>>>>> The series introduces device tree and config changes and AM65x >>>>>>>>>>> to enable ICSSG driver. The series also enables >>>>>>>>>>> SPL_LOAD_FIT_APPLY_OVERLAY >>>>>>>>>>> for AM65x in order to load overlay over spl. >>>>>>>>>>> >>>>>>>>>>> This series has been tested on AM65x SR2.0, and the ICSSG >>>>>>>>>>> interface is >>>>>>>>>>> able to ping / dhcp and boot kernel using tftp in uboot. >>>>>>>>>>> >>>>>>>>>>> To use ICSSG2 ethernet, the ICSSG firmware needs to be loaded to >>>>>>>>>>> PRU RPROC >>>>>>>>>>> cores and RPROC cores need to be booted with the firmware. This >>>>>>>>>>> step is >>>>>>>>>>> done inside driver in kernel as kernel supports APIs like >>>>>>>>>>> rproc_set_firmware() and rproc_fw_boot(). But as u-boot doesn't >>>>>>>>>>> have these >>>>>>>>>>> APIs, the same needs to be done via u-boot cmds. >>>>>>>>>>> >>>>>>>>>>> To make sure icssg-eth works we need to do below steps. >>>>>>>>>>> >>>>>>>>>>> 1. Initialize rproc cores i.e. rproc_init() >>>>>>>>>>> 2. Load $firmware_file from partition '1:2' (root) on device (mmc >>>>>>>>>>> in this >>>>>>>>>>> example) >>>>>>>>>>> 3. Load the firmware file to rproc cores passing. i.e. rproc_load() >>>>>>>>>>> taking rproc_id, loadaddr and file size as arguments. >>>>>>>>>>> 4. Start rproc cores. i.e. rproc_start() taking rproc_id as >>>>>>>>>>> arguments >>>>>>>>>>> >>>>>>>>>>> The above steps are done by running the below commands at u-boot >>>>>>>>>>> prompt. >>>>>>>>>>> >>>>>>>>>>> => setenv start_icssg2 'rproc start 14; rproc start 15; rproc >>>>>>>>>>> start 16; rproc start 17; rproc start 18; rproc start 19' >>>>>>>>>>> => setenv stop_icssg2 'rproc stop 14; rproc stop 15; rproc stop >>>>>>>>>>> 16; rproc stop 17; rproc sto
[PATCH] board: ti: am64: Support TMDS64EVM
The TMDS64EVM [1] ships with AM64X SR2.0 HS-FS chip
and a slightly different board name in the board information
EEPROM header. Support this board.
[1] https://www.ti.com/tool/TMDS64EVM
Gets rid of below message at boot
"Unidentified board claims AM64-EVM in eeprom header"
Signed-off-by: Roger Quadros
---
board/ti/am64x/evm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
index a6dcff2eb4..a7ca6be436 100644
--- a/board/ti/am64x/evm.c
+++ b/board/ti/am64x/evm.c
@@ -18,6 +18,7 @@
#include "../common/board_detect.h"
#define board_is_am64x_gpevm() (board_ti_k3_is("AM64-GPEVM") || \
+ board_ti_k3_is("AM64-EVM") || \
board_ti_k3_is("AM64-HSEVM"))
#define board_is_am64x_skevm() (board_ti_k3_is("AM64-SKEVM") || \
base-commit: c2c598e87cfe56f5991730762c00733c5aa9a994
--
2.34.1
Re: [RFC PATCH 00/16] Introduce ICSSG Ethernet driver
On 05/01/2024 12:15, Anwar, Md Danish wrote:
>
>
> On 1/5/2024 1:49 PM, Roger Quadros wrote:
>>
>>
>> On 03/01/2024 12:27, MD Danish Anwar wrote:
>>>
>>>
>>> On 02/01/24 7:26 pm, Andrew Davis wrote:
>>>> On 12/27/23 12:56 AM, MD Danish Anwar wrote:
>>>>>
>>>>>
>>>>> On 22/12/23 6:13 pm, Roger Quadros wrote:
>>>>>>
>>>>>> On 22/12/2023 12:26, MD Danish Anwar wrote:
>>>>>>> Hi Roger,
>>>>>>>
>>>>>>> On 20/12/23 3:29 pm, Roger Quadros wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 19/12/2023 12:11, MD Danish Anwar wrote:
>>>>>>>>> Introduce ICSSG PRUETH support in uboot. The ICSSG driver is used
>>>>>>>>> in TI
>>>>>>>>> AM654 SR2.0.
>>>>>>>>>
>>>>>>>>> The ICSSG PRU Sub-system runs on EMAC firmware. This series
>>>>>>>>> Introduces
>>>>>>>>> support for ICSSG driver in uboot. This series also adds the driver's
>>>>>>>>> dependencies.
>>>>>>>>>
>>>>>>>>> The ICSSG2 node is added in device tree overlay so that it remains in
>>>>>>>>> sync with linux kernel.
>>>>>>>>>
>>>>>>>>> The series introduces device tree and config changes and AM65x
>>>>>>>>> to enable ICSSG driver. The series also enables
>>>>>>>>> SPL_LOAD_FIT_APPLY_OVERLAY
>>>>>>>>> for AM65x in order to load overlay over spl.
>>>>>>>>>
>>>>>>>>> This series has been tested on AM65x SR2.0, and the ICSSG
>>>>>>>>> interface is
>>>>>>>>> able to ping / dhcp and boot kernel using tftp in uboot.
>>>>>>>>>
>>>>>>>>> To use ICSSG2 ethernet, the ICSSG firmware needs to be loaded to
>>>>>>>>> PRU RPROC
>>>>>>>>> cores and RPROC cores need to be booted with the firmware. This
>>>>>>>>> step is
>>>>>>>>> done inside driver in kernel as kernel supports APIs like
>>>>>>>>> rproc_set_firmware() and rproc_fw_boot(). But as u-boot doesn't
>>>>>>>>> have these
>>>>>>>>> APIs, the same needs to be done via u-boot cmds.
>>>>>>>>>
>>>>>>>>> To make sure icssg-eth works we need to do below steps.
>>>>>>>>>
>>>>>>>>> 1. Initialize rproc cores i.e. rproc_init()
>>>>>>>>> 2. Load $firmware_file from partition '1:2' (root) on device (mmc
>>>>>>>>> in this
>>>>>>>>> example)
>>>>>>>>> 3. Load the firmware file to rproc cores passing. i.e. rproc_load()
>>>>>>>>> taking rproc_id, loadaddr and file size as arguments.
>>>>>>>>> 4. Start rproc cores. i.e. rproc_start() taking rproc_id as arguments
>>>>>>>>>
>>>>>>>>> The above steps are done by running the below commands at u-boot
>>>>>>>>> prompt.
>>>>>>>>>
>>>>>>>>> => setenv start_icssg2 'rproc start 14; rproc start 15; rproc
>>>>>>>>> start 16; rproc start 17; rproc start 18; rproc start 19'
>>>>>>>>> => setenv stop_icssg2 'rproc stop 14; rproc stop 15; rproc stop
>>>>>>>>> 16; rproc stop 17; rproc stop 18; rproc stop 19'
>>>>>>>>> => setenv firmware_dir '/lib/firmware/ti-pruss'
>>>>>>>>> => setenv get_firmware_mmc 'load mmc ${bootpart} ${loadaddr}
>>>>>>>>> ${firmware_dir}/${firmware_file}'
>>>>>>>>>
>>>>>>>>> => setenv init_icssg2 'setenv ethact icssg2-eth; setenv autoload
>>>>>>>>> no; rproc init; setenv loadaddr 0x8000; \
>>>>>>>>> setenv firmware_file am65x-sr2-pru0-prueth-fw.elf; run
>>>>>>>>> get_firmware_mmc; rproc load 14 0x8000 ${filesize}; \
>>>>>>>>> setenv loadaddr 0x8900; setenv firmware_file
>>>
Re: [RFC PATCH 00/16] Introduce ICSSG Ethernet driver
On 03/01/2024 12:27, MD Danish Anwar wrote:
>
>
> On 02/01/24 7:26 pm, Andrew Davis wrote:
>> On 12/27/23 12:56 AM, MD Danish Anwar wrote:
>>>
>>>
>>> On 22/12/23 6:13 pm, Roger Quadros wrote:
>>>>
>>>> On 22/12/2023 12:26, MD Danish Anwar wrote:
>>>>> Hi Roger,
>>>>>
>>>>> On 20/12/23 3:29 pm, Roger Quadros wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 19/12/2023 12:11, MD Danish Anwar wrote:
>>>>>>> Introduce ICSSG PRUETH support in uboot. The ICSSG driver is used
>>>>>>> in TI
>>>>>>> AM654 SR2.0.
>>>>>>>
>>>>>>> The ICSSG PRU Sub-system runs on EMAC firmware. This series
>>>>>>> Introduces
>>>>>>> support for ICSSG driver in uboot. This series also adds the driver's
>>>>>>> dependencies.
>>>>>>>
>>>>>>> The ICSSG2 node is added in device tree overlay so that it remains in
>>>>>>> sync with linux kernel.
>>>>>>>
>>>>>>> The series introduces device tree and config changes and AM65x
>>>>>>> to enable ICSSG driver. The series also enables
>>>>>>> SPL_LOAD_FIT_APPLY_OVERLAY
>>>>>>> for AM65x in order to load overlay over spl.
>>>>>>>
>>>>>>> This series has been tested on AM65x SR2.0, and the ICSSG
>>>>>>> interface is
>>>>>>> able to ping / dhcp and boot kernel using tftp in uboot.
>>>>>>>
>>>>>>> To use ICSSG2 ethernet, the ICSSG firmware needs to be loaded to
>>>>>>> PRU RPROC
>>>>>>> cores and RPROC cores need to be booted with the firmware. This
>>>>>>> step is
>>>>>>> done inside driver in kernel as kernel supports APIs like
>>>>>>> rproc_set_firmware() and rproc_fw_boot(). But as u-boot doesn't
>>>>>>> have these
>>>>>>> APIs, the same needs to be done via u-boot cmds.
>>>>>>>
>>>>>>> To make sure icssg-eth works we need to do below steps.
>>>>>>>
>>>>>>> 1. Initialize rproc cores i.e. rproc_init()
>>>>>>> 2. Load $firmware_file from partition '1:2' (root) on device (mmc
>>>>>>> in this
>>>>>>> example)
>>>>>>> 3. Load the firmware file to rproc cores passing. i.e. rproc_load()
>>>>>>> taking rproc_id, loadaddr and file size as arguments.
>>>>>>> 4. Start rproc cores. i.e. rproc_start() taking rproc_id as arguments
>>>>>>>
>>>>>>> The above steps are done by running the below commands at u-boot
>>>>>>> prompt.
>>>>>>>
>>>>>>> => setenv start_icssg2 'rproc start 14; rproc start 15; rproc
>>>>>>> start 16; rproc start 17; rproc start 18; rproc start 19'
>>>>>>> => setenv stop_icssg2 'rproc stop 14; rproc stop 15; rproc stop
>>>>>>> 16; rproc stop 17; rproc stop 18; rproc stop 19'
>>>>>>> => setenv firmware_dir '/lib/firmware/ti-pruss'
>>>>>>> => setenv get_firmware_mmc 'load mmc ${bootpart} ${loadaddr}
>>>>>>> ${firmware_dir}/${firmware_file}'
>>>>>>>
>>>>>>> => setenv init_icssg2 'setenv ethact icssg2-eth; setenv autoload
>>>>>>> no; rproc init; setenv loadaddr 0x8000; \
>>>>>>> setenv firmware_file am65x-sr2-pru0-prueth-fw.elf; run
>>>>>>> get_firmware_mmc; rproc load 14 0x8000 ${filesize}; \
>>>>>>> setenv loadaddr 0x8900; setenv firmware_file
>>>>>>> am65x-sr2-rtu0-prueth-fw.elf; run get_firmware_mmc; rproc load 15
>>>>>>> 0x8900 ${filesize}; \
>>>>>>> setenv loadaddr 0x9000; setenv firmware_file
>>>>>>> am65x-sr2-txpru0-prueth-fw.elf; run get_firmware_mmc; rproc load
>>>>>>> 16 0x9000 ${filesize}; \
>>>>>>> setenv loadaddr 0x8000; setenv firmware_file
>>>>>>> am65x-sr2-pru1-prueth-fw.elf; run get_firmware_mmc; rproc load 17
>>>>>>> 0x8000 ${filesize}; \
>>>>>>> setenv loadaddr 0x8900; setenv fi
Re: [RFC PATCH 00/16] Introduce ICSSG Ethernet driver
On 22/12/2023 12:26, MD Danish Anwar wrote:
> Hi Roger,
>
> On 20/12/23 3:29 pm, Roger Quadros wrote:
>> Hi,
>>
>> On 19/12/2023 12:11, MD Danish Anwar wrote:
>>> Introduce ICSSG PRUETH support in uboot. The ICSSG driver is used in TI
>>> AM654 SR2.0.
>>>
>>> The ICSSG PRU Sub-system runs on EMAC firmware. This series Introduces
>>> support for ICSSG driver in uboot. This series also adds the driver's
>>> dependencies.
>>>
>>> The ICSSG2 node is added in device tree overlay so that it remains in
>>> sync with linux kernel.
>>>
>>> The series introduces device tree and config changes and AM65x
>>> to enable ICSSG driver. The series also enables SPL_LOAD_FIT_APPLY_OVERLAY
>>> for AM65x in order to load overlay over spl.
>>>
>>> This series has been tested on AM65x SR2.0, and the ICSSG interface is
>>> able to ping / dhcp and boot kernel using tftp in uboot.
>>>
>>> To use ICSSG2 ethernet, the ICSSG firmware needs to be loaded to PRU RPROC
>>> cores and RPROC cores need to be booted with the firmware. This step is
>>> done inside driver in kernel as kernel supports APIs like
>>> rproc_set_firmware() and rproc_fw_boot(). But as u-boot doesn't have these
>>> APIs, the same needs to be done via u-boot cmds.
>>>
>>> To make sure icssg-eth works we need to do below steps.
>>>
>>> 1. Initialize rproc cores i.e. rproc_init()
>>> 2. Load $firmware_file from partition '1:2' (root) on device (mmc in this
>>>example)
>>> 3. Load the firmware file to rproc cores passing. i.e. rproc_load()
>>>taking rproc_id, loadaddr and file size as arguments.
>>> 4. Start rproc cores. i.e. rproc_start() taking rproc_id as arguments
>>>
>>> The above steps are done by running the below commands at u-boot prompt.
>>>
>>> => setenv start_icssg2 'rproc start 14; rproc start 15; rproc start 16;
>>> rproc start 17; rproc start 18; rproc start 19'
>>> => setenv stop_icssg2 'rproc stop 14; rproc stop 15; rproc stop 16; rproc
>>> stop 17; rproc stop 18; rproc stop 19'
>>> => setenv firmware_dir '/lib/firmware/ti-pruss'
>>> => setenv get_firmware_mmc 'load mmc ${bootpart} ${loadaddr}
>>> ${firmware_dir}/${firmware_file}'
>>>
>>> => setenv init_icssg2 'setenv ethact icssg2-eth; setenv autoload no; rproc
>>> init; setenv loadaddr 0x8000; \
>>> setenv firmware_file am65x-sr2-pru0-prueth-fw.elf; run
>>> get_firmware_mmc; rproc load 14 0x8000 ${filesize}; \
>>> setenv loadaddr 0x8900; setenv firmware_file
>>> am65x-sr2-rtu0-prueth-fw.elf; run get_firmware_mmc; rproc load 15
>>> 0x8900 ${filesize}; \
>>> setenv loadaddr 0x9000; setenv firmware_file
>>> am65x-sr2-txpru0-prueth-fw.elf; run get_firmware_mmc; rproc load 16
>>> 0x9000 ${filesize}; \
>>> setenv loadaddr 0x8000; setenv firmware_file
>>> am65x-sr2-pru1-prueth-fw.elf; run get_firmware_mmc; rproc load 17
>>> 0x8000 ${filesize}; \
>>> setenv loadaddr 0x8900; setenv firmware_file
>>> am65x-sr2-rtu1-prueth-fw.elf; run get_firmware_mmc; rproc load 18
>>> 0x8900 ${filesize}; \
>>> setenv loadaddr 0x9000; setenv firmware_file
>>> am65x-sr2-txpru1-prueth-fw.elf; run get_firmware_mmc; rproc load 19
>>> 0x9000 ${filesize}; \
>>> run start_icssg2;'
>>
>> A whole bunch of commands are required to get ethernet functional.
>> This is not at all user friendly and will be a maintenance nightmare.
>> What worries me is tracking the 6 different rproc cores and the 6 different
>> firmware files to start 1 ethernet device.
>> This will get even more interesting when we have to deal with different
>> ICSSG instances on different boards.
>>
>> What is preventing the driver from starting the rproc cores it needs so user
>> doesn't need to care about it?
>> All the necessary information is in the Device tree. At least this is how it
>> is done on Linux.
>>
>
> I tried removing the need for these commands and implementing them
> inside the driver only. I am able to load the firmware from driver using
> the fs_loader API request_firmware_into_buf(). It requires changes to
> dt. A DT node called fs-loader needs to be added also CONFIG_FS_LOADER
> needs to enabled. In the DT node we need to specify the storage media
> that we are using i.e. mmc, ospi, usb. It's upto user to modify the
> storage media, the driver will take
Re: [RFC PATCH 12/16] arm: dts: k3-am65x-binman: Add ICSSG2 overlay and configuration
On 19/12/2023 12:34, MD Danish Anwar wrote:
> Add ICSSG2 overlay and configuration to tispl and u-boot images.
>
> Signed-off-by: MD Danish Anwar
> ---
> arch/arm/dts/k3-am65x-binman.dtsi | 85 +++
> 1 file changed, 85 insertions(+)
>
> diff --git a/arch/arm/dts/k3-am65x-binman.dtsi
> b/arch/arm/dts/k3-am65x-binman.dtsi
> index 8cc24da1f3..9a0c0fca47 100644
> --- a/arch/arm/dts/k3-am65x-binman.dtsi
> +++ b/arch/arm/dts/k3-am65x-binman.dtsi
> @@ -98,6 +98,8 @@
> #define SPL_AM654_EVM_DTB "spl/dts/k3-am654-base-board.dtb"
> #define AM654_EVM_DTB "u-boot.dtb"
>
> +#define AM654_EVM_ICSSG2_DTBO "arch/arm/dts/k3-am654-icssg2.dtbo"
> +
> {
> ti-spl {
> insert-template = <_spl_template>;
> @@ -124,6 +126,20 @@
> filename = SPL_AM654_EVM_DTB;
> };
> };
> +
> + fdt-1 {
> + description = "k3-am654-icssg2 overlay";
> + type = "flat_dt";
> + arch = "arm";
> + compression = "none";
> + ti-secure {
> + content =
> <_am65x_evm_icssg2_dtb>;
> + keyfile = "custMpk.pem";
> + };
> + spl_am65x_evm_icssg2_dtb: blob-ext {
> + filename =
> AM654_EVM_ICSSG2_DTBO;
> + };
This is wrong.
ICSSG2 Ethernet should be part of the fdt-0 configuration as the 2 Ethernet
ports
on the board are hardwired to ICSSG2. Not having them working by default
is an invalid configuration.
> + };
> };
>
> configurations {
> @@ -135,6 +151,13 @@
> loadables = "tee", "dm", "spl";
> fdt = "fdt-0";
> };
> +
> + conf-1 {
> + description = "k3-am654-icssg2";
> + firmware = "atf";
> + loadables = "tee", "dm", "spl";
> + fdt = "fdt-0", "fdt-1";
> + };
> };
> };
> };
> @@ -168,6 +191,24 @@
> };
> };
>
> + fdt-1 {
> + description = "k3-am654-icssg2 overlay";
> + type = "flat_dt";
> + arch = "arm";
> + compression = "none";
> + ti-secure {
> + content =
> <_evm_icssg2_dtb>;
> + keyfile = "custMpk.pem";
> +
> + };
> + am65x_evm_icssg2_dtb: blob-ext {
> + filename =
> AM654_EVM_ICSSG2_DTBO;
> + };
> + hash {
> + algo = "crc32";
> + };
> + };
> +
> };
>
> configurations {
> @@ -179,6 +220,13 @@
> loadables = "uboot";
> fdt = "fdt-0";
> };
> +
> + conf-1 {
> + description = "k3-am654-icssg2";
> + firmware = "uboot";
> + loadables = "uboot";
> + fdt = "fdt-0", "fdt-1";
> + };
> };
> };
> };
> @@ -205,6 +253,16 @@
> filename = SPL_AM654_EVM_DTB;
> };
> };
> +
> + fdt-1 {
> + description = "k3-am654-icssg2 overlay";
> + type = "flat_dt";
> + arch = "arm";
> + compression = "none";
> + blob {
> + filename =
> AM654_EVM_ICSSG2_DTBO;
> + };
> + };
> };
>
>
Re: [RFC PATCH 11/16] arm: dts: k3-am654-base-board: Add ICSSG2 Ethernet support
On 19/12/2023 12:34, MD Danish Anwar wrote:
> ICSSG2 provides dual Gigabit Ethernet support.
> Add ICSSG2 ethernet node to an overlay k3-am654-icssg2.dtso
>
> Signed-off-by: MD Danish Anwar
> ---
> arch/arm/dts/Makefile | 3 +-
> arch/arm/dts/k3-am654-icssg2.dtso | 145 ++
> 2 files changed, 147 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/k3-am654-icssg2.dtso
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index e9e58c5478..2bc53fba89 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1396,7 +1396,8 @@ dtb-$(CONFIG_SOC_K3_AM654) += \
> k3-am6548-iot2050-advanced-pg2.dtb \
> k3-am6548-iot2050-advanced-m2.dtb \
> k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dtbo \
> - k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtbo
> + k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtbo \
> + k3-am654-icssg2.dtbo
> dtb-$(CONFIG_SOC_K3_J721E) += k3-j721e-common-proc-board.dtb \
> k3-j721e-r5-common-proc-board.dtb \
> k3-j7200-common-proc-board.dtb \
> diff --git a/arch/arm/dts/k3-am654-icssg2.dtso
> b/arch/arm/dts/k3-am654-icssg2.dtso
> new file mode 100644
> index 00..faefa2febc
> --- /dev/null
> +++ b/arch/arm/dts/k3-am654-icssg2.dtso
Why is this an overlay file? Isn't ICSSG2 part of base board?
> @@ -0,0 +1,145 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/**
> + * DT overlay for enabling ICSSG2 on AM654 EVM
> + *
> + * Copyright (C) 2018-2023 Texas Instruments Incorporated -
> https://www.ti.com/
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include
> +#include "k3-pinctrl.h"
> +
> +&{/} {
> + aliases {
> + ethernet1 = "/icssg2-eth/ethernet-ports/port@0";
> + ethernet2 = "/icssg2-eth/ethernet-ports/port@1";
> + };
> +
> + /* Ethernet node on PRU-ICSSG2 */
> + icssg2_eth: icssg2-eth {
> + compatible = "ti,am654-icssg-prueth";
> + pinctrl-names = "default";
> + pinctrl-0 = <_rgmii_pins_default>;
> + sram = <_ram>;
> + ti,prus = <_0>, <_0>, <_pru2_0>,
> + <_1>, <_1>, <_pru2_1>;
> + firmware-name = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
> + "ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
> + "ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
> + "ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
> + "ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
> + "ti-pruss/am65x-sr2-txpru1-prueth-fw.elf";
> +
> + ti,pruss-gp-mux-sel = <2>, /* MII mode */
> + <2>,
> + <2>,
> + <2>, /* MII mode */
> + <2>,
> + <2>;
> +
> + ti,mii-g-rt = <_mii_g_rt>;
> + ti,mii-rt = <_mii_rt>;
> + ti,iep = <_iep0>, <_iep1>;
> +
> + interrupt-parent = <_intc>;
> + interrupts = <24 0 2>, <25 1 3>;
> + interrupt-names = "tx_ts0", "tx_ts1";
> +
> + dmas = <_udmap 0xc300>, /* egress slice 0 */
> +<_udmap 0xc301>, /* egress slice 0 */
> +<_udmap 0xc302>, /* egress slice 0 */
> +<_udmap 0xc303>, /* egress slice 0 */
> +<_udmap 0xc304>, /* egress slice 1 */
> +<_udmap 0xc305>, /* egress slice 1 */
> +<_udmap 0xc306>, /* egress slice 1 */
> +<_udmap 0xc307>, /* egress slice 1 */
> +<_udmap 0x4300>, /* ingress slice 0 */
> +<_udmap 0x4301>; /* ingress slice 1 */
> +
> + dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
> + "tx1-0", "tx1-1", "tx1-2", "tx1-3",
> + "rx0", "rx1";
> + ethernet-ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + icssg2_emac0: port@0 {
> + reg = <0>;
> + phy-handle = <_phy0>;
> + phy-mode = "rgmii-id";
> + ti,syscon-rgmii-delay = <_conf 0x4120>;
> + /* Filled in by bootloader */
> + local-mac-address = [00 00 00 00 00 00];
> + };
> + icssg2_emac1: port@1 {
> + reg = <1>;
> + phy-handle = <_phy1>;
> + phy-mode = "rgmii-id";
> + ti,syscon-rgmii-delay = <_conf 0x4124>;
> + /* Filled in by bootloader */
> + local-mac-address = [00 00
Re: [RFC PATCH 14/16] configs: am65x_evm_a53_defconfig: add SPL_LOAD_FIT_APPLY_OVERLAY
On 19/12/2023 12:34, MD Danish Anwar wrote: > We want SPL to apply DTB overlays (e.g. NAND card overlay) so > enable SPL_LOAD_FIT_APPLY_OVERLAY. > Increase SPL_LOAD_FIT_APPLY_OVERLAY_BUF_SZ and > SPL_STACK_R_MALLOC_SIMPLE_LEN. Without this SPL hangs. > > Signed-off-by: MD Danish Anwar > --- > configs/am65x_evm_a53_defconfig | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig > index e79a961317..2755d7082f 100644 > --- a/configs/am65x_evm_a53_defconfig > +++ b/configs/am65x_evm_a53_defconfig > @@ -70,6 +70,9 @@ CONFIG_CMD_I2C=y > CONFIG_CMD_MMC=y > CONFIG_CMD_PCI=y > CONFIG_CMD_REMOTEPROC=y > +CONFIG_SPL_LOAD_FIT_APPLY_OVERLAY=y > +CONFIG_SPL_LOAD_FIT_APPLY_OVERLAY_BUF_SZ=0x10 > +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x100 This change to 16MB is not required. I suppose default is 4MB. Did you face issues with it? > CONFIG_CMD_USB=y > CONFIG_CMD_TIME=y > CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0" -- cheers, -roger
Re: [RFC PATCH 00/16] Introduce ICSSG Ethernet driver
Hi,
On 19/12/2023 12:11, MD Danish Anwar wrote:
> Introduce ICSSG PRUETH support in uboot. The ICSSG driver is used in TI
> AM654 SR2.0.
>
> The ICSSG PRU Sub-system runs on EMAC firmware. This series Introduces
> support for ICSSG driver in uboot. This series also adds the driver's
> dependencies.
>
> The ICSSG2 node is added in device tree overlay so that it remains in
> sync with linux kernel.
>
> The series introduces device tree and config changes and AM65x
> to enable ICSSG driver. The series also enables SPL_LOAD_FIT_APPLY_OVERLAY
> for AM65x in order to load overlay over spl.
>
> This series has been tested on AM65x SR2.0, and the ICSSG interface is
> able to ping / dhcp and boot kernel using tftp in uboot.
>
> To use ICSSG2 ethernet, the ICSSG firmware needs to be loaded to PRU RPROC
> cores and RPROC cores need to be booted with the firmware. This step is
> done inside driver in kernel as kernel supports APIs like
> rproc_set_firmware() and rproc_fw_boot(). But as u-boot doesn't have these
> APIs, the same needs to be done via u-boot cmds.
>
> To make sure icssg-eth works we need to do below steps.
>
> 1. Initialize rproc cores i.e. rproc_init()
> 2. Load $firmware_file from partition '1:2' (root) on device (mmc in this
>example)
> 3. Load the firmware file to rproc cores passing. i.e. rproc_load()
>taking rproc_id, loadaddr and file size as arguments.
> 4. Start rproc cores. i.e. rproc_start() taking rproc_id as arguments
>
> The above steps are done by running the below commands at u-boot prompt.
>
> => setenv start_icssg2 'rproc start 14; rproc start 15; rproc start 16; rproc
> start 17; rproc start 18; rproc start 19'
> => setenv stop_icssg2 'rproc stop 14; rproc stop 15; rproc stop 16; rproc
> stop 17; rproc stop 18; rproc stop 19'
> => setenv firmware_dir '/lib/firmware/ti-pruss'
> => setenv get_firmware_mmc 'load mmc ${bootpart} ${loadaddr}
> ${firmware_dir}/${firmware_file}'
>
> => setenv init_icssg2 'setenv ethact icssg2-eth; setenv autoload no; rproc
> init; setenv loadaddr 0x8000; \
> setenv firmware_file am65x-sr2-pru0-prueth-fw.elf; run get_firmware_mmc;
> rproc load 14 0x8000 ${filesize}; \
> setenv loadaddr 0x8900; setenv firmware_file
> am65x-sr2-rtu0-prueth-fw.elf; run get_firmware_mmc; rproc load 15 0x8900
> ${filesize}; \
> setenv loadaddr 0x9000; setenv firmware_file
> am65x-sr2-txpru0-prueth-fw.elf; run get_firmware_mmc; rproc load 16
> 0x9000 ${filesize}; \
> setenv loadaddr 0x8000; setenv firmware_file
> am65x-sr2-pru1-prueth-fw.elf; run get_firmware_mmc; rproc load 17 0x8000
> ${filesize}; \
> setenv loadaddr 0x8900; setenv firmware_file
> am65x-sr2-rtu1-prueth-fw.elf; run get_firmware_mmc; rproc load 18 0x8900
> ${filesize}; \
> setenv loadaddr 0x9000; setenv firmware_file
> am65x-sr2-txpru1-prueth-fw.elf; run get_firmware_mmc; rproc load 19
> 0x9000 ${filesize}; \
> run start_icssg2;'
A whole bunch of commands are required to get ethernet functional.
This is not at all user friendly and will be a maintenance nightmare.
What worries me is tracking the 6 different rproc cores and the 6 different
firmware files to start 1 ethernet device.
This will get even more interesting when we have to deal with different ICSSG
instances on different boards.
What is preventing the driver from starting the rproc cores it needs so user
doesn't need to care about it?
All the necessary information is in the Device tree. At least this is how it is
done on Linux.
>
> => run init_icssg2
> => dhcp
> k3-navss-ringacc ringacc@3c00: Ring Accelerator probed rings:818,
> gp-rings[304,100] sci-dev-id:187
> k3-navss-ringacc ringacc@3c00: dma-ring-reset-quirk: disabled
> prueth icssg2-eth: K3 ICSSG: rflow_id_base: 8, chn_name = rx0
> link up on port 0, speed 1000, full duplex
> BOOTP broadcast 1
> BOOTP broadcast 2
> BOOTP broadcast 3
> DHCP client bound to address 192.168.4.58 (1020 ms)
>
What about shutting down the interface?
I believe this has to be done manually too?
> Thanks and Regards,
> MD Danish Anwar
>
> MD Danish Anwar (16):
> net: ti: icssg: Add Firmware Interface for ICSSG Ethernet driver.
> net: ti: icssg: Add Firmware config and classification APIs.
> net: ti: icssg: Add icssg queues APIs and macros
> net: ti: icssg: Add ICSSG ethernet driver
> net: ti: icssg: Add support sending FDB command to update rx_flow_id
> net: ti: icssg: Enforce pinctrl state on the MDIO child node
> arm: dts: k3-am65: Add additional regs for DMA components
> arm: dts: k3-am65: Add cfg reg region to ringacc node
> arm: dts: k3-am65-main: Add ICSSG IEP nodes
> arm: dts: k3-am654-base-board: Add ICSSG2 Ethernet support
> arm: dts: k3-am65x-binman: Add ICSSG2 overlay and configuration
> configs: am65x_evm_a53: Enable ICSSG Driver
> configs: am65x_evm_a53_defconfig: add SPL_LOAD_FIT_APPLY_OVERLAY
> tools/fdtgrep: Include __symbols__ table
> board: ti:
Re: [PATCH v3 1/4] usb: dwc3: Add dwc3 glue driver for am62
Hi Sjoerd,
On 12/12/2023 23:02, Sjoerd Simons wrote:
> Add glue code for TI AM62 to the dwc3 driver; Most code adopted from
> TI vendor u-boot code.
>
> Signed-off-by: Sjoerd Simons
> Reviewed-by: Mattijs Korpershoek
>
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - Switch dwc3 glue to a seperate driver rather then in dwc-generic
>
> drivers/usb/dwc3/Kconfig | 14
> drivers/usb/dwc3/Makefile| 1 +
> drivers/usb/dwc3/dwc3-am62.c | 125 +++
> 3 files changed, 140 insertions(+)
> create mode 100644 drivers/usb/dwc3/dwc3-am62.c
>
> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> index c0c8c16fd9c..26a1e1770c5 100644
> --- a/drivers/usb/dwc3/Kconfig
> +++ b/drivers/usb/dwc3/Kconfig
> @@ -37,6 +37,20 @@ config SPL_USB_DWC3_GENERIC
> Select this for Xilinx ZynqMP and similar Platforms.
> This wrapper supports Host and Peripheral operation modes.
>
> +config SPL_USB_DWC3_AM62
> + bool "TI AM62 USB wrapper"
> + depends on SPL_DM_USB && SPL_USB_DWC3_GENERIC
> + help
> + Select this for TI AM62 Platforms.
> + This wrapper supports Host and Peripheral operation modes.
> +
> +config USB_DWC3_AM62
> + bool "TI AM62 USB wrapper"
> + depends on DM_USB && USB_DWC3_GENERIC
> + help
> + Select this for TI AM62 Platforms.
> + This wrapper supports Host and Peripheral operation modes.
> +
> config USB_DWC3_MESON_G12A
> bool "Amlogic Meson G12A USB wrapper"
> depends on DM_USB && USB_DWC3 && ARCH_MESON
> diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
> index 97b4f7191ca..a46b6824ab7 100644
> --- a/drivers/usb/dwc3/Makefile
> +++ b/drivers/usb/dwc3/Makefile
> @@ -6,6 +6,7 @@ dwc3-y:= core.o
>
> obj-$(CONFIG_USB_DWC3_GADGET)+= gadget.o ep0.o
>
> +obj-$(CONFIG_$(SPL_)USB_DWC3_AM62) += dwc3-am62.o
> obj-$(CONFIG_USB_DWC3_OMAP) += dwc3-omap.o
> obj-$(CONFIG_USB_DWC3_MESON_G12A)+= dwc3-meson-g12a.o
> obj-$(CONFIG_USB_DWC3_MESON_GXL) += dwc3-meson-gxl.o
> diff --git a/drivers/usb/dwc3/dwc3-am62.c b/drivers/usb/dwc3/dwc3-am62.c
> new file mode 100644
> index 000..56c3b26a531
> --- /dev/null
> +++ b/drivers/usb/dwc3/dwc3-am62.c
> @@ -0,0 +1,125 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * TI AM62 specific glue layer for DWC3
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "dwc3-generic.h"
> +
> +static void dwc3_ti_am62_glue_configure(struct udevice *dev, int index,
> + enum usb_dr_mode mode)
> +{
> +#define USBSS_MODE_CONTROL 0x1c
> +#define USBSS_PHY_CONFIG 0x8
> +#define USBSS_PHY_VBUS_SEL_MASK GENMASK(2, 1)
> +#define USBSS_PHY_VBUS_SEL_SHIFT 1
> +#define USBSS_MODE_VALID BIT(0)
> +#define PHY_PLL_REFCLK_MASK GENMASK(3, 0)
> +static const int dwc3_ti_am62_rate_table[] = { /* in KHZ */
> + 9600,
> + 1,
> + 12000,
> + 19200,
> + 2,
> + 24000,
> + 25000,
> + 26000,
> + 38400,
> + 4,
> + 58000,
> + 5,
> + 52000,
> +};
Can we please move these defines and dwc3_ti_am62_rate_table outside the
function?
> +
> + struct clk usb2_refclk;
> + int rate_code, i, ret;
> + unsigned long rate;
> + u32 reg;
> + void *usbss;
> + bool vbus_divider;
> + struct regmap *syscon;
> + struct ofnode_phandle_args args;
> +
> + usbss = dev_remap_addr_index(dev, 0);
> + if (IS_ERR(usbss)) {
> + dev_err(dev, "can't map IOMEM resource\n");
> + return;
> + }
> +
> + ret = clk_get_by_name(dev, "ref", _refclk);
> + if (ret) {
> + dev_err(dev, "can't get usb2_refclk\n");
> + return;
> + }
> +
> + /* Calculate the rate code */
> + rate = clk_get_rate(_refclk);
> + rate /= 1000; /* To KHz */
> + for (i = 0; i < ARRAY_SIZE(dwc3_ti_am62_rate_table); i++) {
> + if (dwc3_ti_am62_rate_table[i] == rate)
> + break;
> + }
> +
> + if (i == ARRAY_SIZE(dwc3_ti_am62_rate_table)) {
> + dev_err(dev, "unsupported usb2_refclk rate: %lu KHz\n", rate);
> + return;
> + }
> +
> + rate_code = i;
> +
> + /* Read the syscon property */
> + syscon = syscon_regmap_lookup_by_phandle(dev,
> "ti,syscon-phy-pll-refclk");
> + if (IS_ERR(syscon)) {
> + dev_err(dev, "unable to get ti,syscon-phy-pll-refclk regmap\n");
> + return;
> + }
> +
> + ret = ofnode_parse_phandle_with_args(dev_ofnode(dev),
> "ti,syscon-phy-pll-refclk", NULL, 1,
> + 0, );
> + if (ret)
> + return;
> +
> + /* Program PHY PLL refclk by reading syscon property */
> + ret = regmap_update_bits(syscon, args.args[0], PHY_PLL_REFCLK_MASK,
> rate_code);
> +
Re: [PATCH v3 4/4] configs: am62x_evm_*: Enable USB and DFU support
On 12/12/2023 23:02, 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 new config just for > DFU support > > Signed-off-by: Sjoerd Simons > > --- > > 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 | 31 ++- > configs/am62x_evm_r5_usbdfu_defconfig | 111 ++ > 2 files changed, 141 insertions(+), 1 deletion(-) > create mode 100644 configs/am62x_evm_r5_usbdfu_defconfig > > diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig > index df2511546ea..1bd8f0fd9ec 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 > @@ -40,17 +41,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_SYS_BOOTM_LEN=0x80 > +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 +68,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 +117,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_evm_r5_usbdfu_defconfig > b/configs/am62x_evm_r5_usbdfu_defconfig > new file mode 100644 > index 000..14bc08f60a4 > --- /dev/null > +++ b/configs/am62x_evm_r5_usbdfu_defconfig > @@ -0,0 +1,111 @@ > +CONFIG_ARM=y > +CONFIG_ARCH_K3=y > +CONFIG_SYS_MALLOC_LEN=0x0800 > +CONFIG_SYS_MALLOC_F_LEN=0x9000 > +CONFIG_SPL_LIBCOMMON_SUPPORT=y > +CONFIG_SPL_LIBGENERIC_SUPPORT=y > +CONFIG_NR_DRAM_BANKS=2 > +CONFIG_SOC_K3_AM625=y > +CONFIG_TARGET_AM625_R5_EVM=y > +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x43c3a7f0 > +CONFIG_ENV_SIZE=0x2 > +CONFIG_DM_GPIO=y > +CONFIG_DEFAULT_DEVICE_TREE="k3-am625-r5-sk" > +CONFIG_SPL_TEXT_BASE=0x43c0 > +CONFIG_DM_RESET=y > +CONFIG_SPL_SERIAL=y > +CONFIG_SPL_DRIVERS_MISC=y > +CONFIG_SPL_STACK_R_ADDR=0x8200 > +CONFIG_SPL_SYS_MALLOC_F_LEN=0x7000 > +CONFIG_SPL_SIZE_LIMIT=0x3A7F0 > +CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x3500 > +CONFIG_SPL_LOAD_FIT=y > +CONFIG_SPL_LOAD_FIT_ADDRESS=0x8008 > +# CONFIG_DISPLAY_CPUINFO is not set > +CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y > +CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y > +CONFIG_SPL_MAX_SIZE=0x3B000 > +CONFIG_SPL_PAD_TO=0x0 > +CONFIG_SPL_HAS_BSS_LINKER_SECTION=y > +CONFIG_SPL_BSS_START_ADDR=0x43c3b000 > +CONFIG_SPL_BSS_MAX_SIZE=0x3000 > +CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y > +CONFIG_SPL_SYS_MALLOC_SIMPLE=y > +CONFIG_SPL_STACK_R=y > +CONFIG_SPL_SEPARATE_BSS=y > +CONFIG_SPL_EARLY_BSS=y > +CONFIG_SPL_ENV_SUPPORT=y > +CONFIG_SPL_DM_MAILBOX=y > +CONFIG_SPL_DM_RESET=y > +CONFIG_SPL_POWER_DOMAIN=y > +CONFIG_SPL_RAM_SUPPORT=y > +CONFIG_SPL_RAM_DEVICE=y > +CONFIG_SPL_REMOTEPROC=y > +CONFIG_SPL_YMODEM_SUPPORT=y > +CONFIG_HUSH_PARSER=y > +CONFIG_CMD_ASKENV=y > +CONFIG_CMD_DFU=y > +CONFIG_CMD_REMOTEPROC=y > +# CONFIG_CMD_SETEXPR is not set > +CONFIG_CMD_TIME=y > +CONFIG_OF_CONTROL=y > +CONFIG_SPL_OF_CONTROL=y > +CONFIG_SPL_MULTI_DTB_FIT=y > +CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y > +CONFIG_SYS_RELOC_GD_ENV_ADDR=y > +CONFIG_SPL_DM=y > +CONFIG_SPL_DM_SEQ_ALIAS=y > +CONFIG_REGMAP=y > +CONFIG_SPL_REGMAP=y > +CONFIG_SYSCON=y > +CONFIG_SPL_SYSCON=y >
Re: [PATCH v3 3/4] arm: dts: k3-am625-sk: Enable usb ports in u-boot
On 12/12/2023 23:02, Sjoerd Simons wrote:
> Enable both usb0 as a peripheral for use with DFU and
>
> Signed-off-by: Sjoerd Simons
>
> ---
>
> Changes in v3:
> - Enable usb nodes in all boot phases
>
> Changes in v2:
> - Only enable usb port 0 DFU in SPL
>
> arch/arm/dts/k3-am625-sk-u-boot.dtsi | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> index fa778b0ff4c..1fc0d407cbf 100644
> --- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> @@ -46,3 +46,12 @@
> _port2 {
> status = "disabled";
> };
> +
> + {
> + bootph-all;
> +};
> +
> + {
> + dr_mode = "peripheral";
There was a series [1] just to undo this.
Can we make it auto-magically work even when mode is "otg"
Can we address anything missing at the driver level?
> + bootph-all;
> +};
[1]
https://lore.kernel.org/all/20230706-handle-otg-as-periph-v3-0-27e24fa17...@baylibre.com/
--
cheers,
-roger
