[PATCH 0/3] Enable ICSSG Driver for AM64x

MD Danish Anwar

22 May 2024 22 May '24

8:36 a.m.

This series adds device-tree changes (specific to u-boot only), config changes and env changes to enable ICSSG Ethernet Driver on AM64x.

Patch 1/3 adds remoteproc-name property to the pru cores in k3-am642-evm-u-boot.dtsi file. This property is not needed in Linux thus it's not part of the PRU nodes in k3-am64x-main.dtsi. Adding this in *u-boot.dtsi as it is only needed for u-boot. Without this different PRU nodes can have same remoteproc-name which results into probe failure. For example the node "pru0_0: pru@34000" and "pru1_0: pru@34000" both will have remoteproc-name as "pru@34000" without this patch, resulting in probe failure because of non-unique name (_rproc_name_is_unique() API) of PRU core.

Patch 2/3 Enables necessary configs for AM64x to enable ICSSG driver Patch 3/3 Sets env variables needed for ICSSG driver

Thanks and Regards, MD Danish Anwar

MD Danish Anwar (3): arm: dts: k3-am642-evm-u-boot: Add remoteproc-name for PRU cores configs: am64x_evm_a53: Enable ICSSG Driver board: ti: am64x: Set storage_interface and fw_dev_part ENVs

arch/arm/dts/k3-am642-evm-u-boot.dtsi | 44 +++++++++++++++++++++++++++ board/ti/am64x/am64x.env | 5 +++ configs/am64x_evm_a53_defconfig | 5 +++ 3 files changed, 54 insertions(+)

base-commit: 7d24c3e06fa9a3b53cea593d4579886ef0eb4fe8

-- 2.34.1

Show replies by date

MD Danish Anwar

22 May 22 May

8:36 a.m.

New subject: [PATCH 1/3] arm: dts: k3-am642-evm-u-boot: Add remoteproc-name for PRU cores

Add remoteproc-name property for PRU cores.

Signed-off-by: MD Danish Anwar danishanwar@ti.com --- arch/arm/dts/k3-am642-evm-u-boot.dtsi | 44 +++++++++++++++++++++++++++ 1 file changed, 44 insertions(+)

diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi b/arch/arm/dts/k3-am642-evm-u-boot.dtsi index 705b3baa81..25ddace74e 100644 --- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi +++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi @@ -11,6 +11,50 @@ }; };

+&pru0_0 { + remoteproc-name = "pru0_0"; +}; + +&rtu0_0 { + remoteproc-name = "rtu0_0"; +}; + +&tx_pru0_0 { + remoteproc-name = "tx_pru0_0"; +}; + +&pru0_1 { + remoteproc-name = "pru0_1"; +}; + +&rtu0_1 { + remoteproc-name = "rtu0_1"; +}; + +&tx_pru0_1 { + remoteproc-name = "tx_pru0_1"; +}; + +&pru1_0 { + remoteproc-name = "pru1_0"; +}; + +&rtu1_0 { + remoteproc-name = "rtu1_0"; +}; + +&tx_pru1_0 { + remoteproc-name = "tx_pru1_0"; +}; + +&pru1_1 { + remoteproc-name = "pru1_1"; +}; + +&rtu1_1 { + remoteproc-name = "rtu1_1"; +}; + &main_timer0 { clock-frequency = <200000000>; };

-- 2.34.1

Andrew Davis

6:08 p.m.

New subject: [PATCH 1/3] arm: dts: k3-am642-evm-u-boot: Add remoteproc-name for PRU cores

On 5/22/24 1:36 AM, MD Danish Anwar wrote:

...

Add remoteproc-name property for PRU cores.

Signed-off-by: MD Danish Anwar danishanwar@ti.com

arch/arm/dts/k3-am642-evm-u-boot.dtsi | 44 +++++++++++++++++++++++++++ 1 file changed, 44 insertions(+)

diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi b/arch/arm/dts/k3-am642-evm-u-boot.dtsi index 705b3baa81..25ddace74e 100644 --- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi +++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi @@ -11,6 +11,50 @@ }; };

+&pru0_0 {

remoteproc-name = "pru0_0";

Why do we need all these? Looks like we fallback to using `dev->name` if these are not set, does that not work for us here?

Andrew

...

+};

+&rtu0_0 {

remoteproc-name = "rtu0_0";

+};

+&tx_pru0_0 {

remoteproc-name = "tx_pru0_0";

+};

+&pru0_1 {

remoteproc-name = "pru0_1";

+};

+&rtu0_1 {

remoteproc-name = "rtu0_1";

+};

+&tx_pru0_1 {

remoteproc-name = "tx_pru0_1";

+};

+&pru1_0 {

remoteproc-name = "pru1_0";

+};

+&rtu1_0 {

remoteproc-name = "rtu1_0";

+};

+&tx_pru1_0 {

remoteproc-name = "tx_pru1_0";

+};

+&pru1_1 {

remoteproc-name = "pru1_1";

+};

+&rtu1_1 {

remoteproc-name = "rtu1_1";

+};

&main_timer0 { clock-frequency = <200000000>; };

Anwar, Md Danish

23 May 23 May

8:33 a.m.

New subject: [PATCH 1/3] arm: dts: k3-am642-evm-u-boot: Add remoteproc-name for PRU cores

Hi Andrew,

On 5/22/2024 9:38 PM, Andrew Davis wrote:

...

On 5/22/24 1:36 AM, MD Danish Anwar wrote:

...
Add remoteproc-name property for PRU cores.

Signed-off-by: MD Danish Anwar danishanwar@ti.com

arch/arm/dts/k3-am642-evm-u-boot.dtsi | 44 +++++++++++++++++++++++++++ 1 file changed, 44 insertions(+)

diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi b/arch/arm/dts/k3-am642-evm-u-boot.dtsi index 705b3baa81..25ddace74e 100644 --- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi +++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi @@ -11,6 +11,50 @@ }; }; +&pru0_0 { + remoteproc-name = "pru0_0";

Why do we need all these? Looks like we fallback to using `dev->name` if these are not set, does that not work for us here?

Yes we will fallback to `dev->name` if `remoteproc-name` is not set but in our case two different PRU cores will have same `dev->name`. As a result the API rproc_name_is_unique() will return false and as a result the probe will fail for the PRU cores.

Example: In k3-am64-main.dtsi, both pru0_0 [1] and pru1_0 [2] will have dev->name as "pru@34000" same goes for rtu and txpru as well.

pru0_0: pru@34000 { compatible = "ti,am642-pru"; reg = <0x34000 0x3000>, <0x22000 0x100>, <0x22400 0x100>; reg-names = "iram", "control", "debug"; firmware-name = "am64x-pru0_0-fw"; };

pru1_0: pru@34000 { compatible = "ti,am642-pru"; reg = <0x34000 0x4000>, <0x22000 0x100>, <0x22400 0x100>; reg-names = "iram", "control", "debug"; firmware-name = "am64x-pru1_0-fw"; };

To avoid this, we are setting the "remoteproc-name" property in -u-boot.dtsi. Same is done for AM65x as well [3].

[1] https://elixir.bootlin.com/u-boot/v2024.07-rc3/source/dts/upstream/src/arm64... [2] https://elixir.bootlin.com/u-boot/v2024.07-rc3/source/dts/upstream/src/arm64... [3] https://elixir.bootlin.com/u-boot/v2024.07-rc3/source/arch/arm/dts/k3-am654-...

...

Andrew

...
+};

+&rtu0_0 { +    remoteproc-name = "rtu0_0"; +};

+&tx_pru0_0 { +    remoteproc-name = "tx_pru0_0"; +};

+&pru0_1 { +    remoteproc-name = "pru0_1"; +};

+&rtu0_1 { +    remoteproc-name = "rtu0_1"; +};

+&tx_pru0_1 { +    remoteproc-name = "tx_pru0_1"; +};

+&pru1_0 { +    remoteproc-name = "pru1_0"; +};

+&rtu1_0 { +    remoteproc-name = "rtu1_0"; +};

+&tx_pru1_0 { +    remoteproc-name = "tx_pru1_0"; +};

+&pru1_1 { +    remoteproc-name = "pru1_1"; +};

+&rtu1_1 { +    remoteproc-name = "rtu1_1"; +};

&main_timer0 {       clock-frequency = <200000000>; };

-- Thanks and Regards, Md Danish Anwar

Andrew Davis

7 Jun 7 Jun

8:54 p.m.

New subject: [PATCH 1/3] arm: dts: k3-am642-evm-u-boot: Add remoteproc-name for PRU cores

On 5/23/24 1:33 AM, Anwar, Md Danish wrote:

...

Hi Andrew,

On 5/22/2024 9:38 PM, Andrew Davis wrote:

...
On 5/22/24 1:36 AM, MD Danish Anwar wrote:

...
Add remoteproc-name property for PRU cores.

Signed-off-by: MD Danish Anwar danishanwar@ti.com

arch/arm/dts/k3-am642-evm-u-boot.dtsi | 44 +++++++++++++++++++++++++++ 1 file changed, 44 insertions(+)

diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi b/arch/arm/dts/k3-am642-evm-u-boot.dtsi index 705b3baa81..25ddace74e 100644 --- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi +++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi @@ -11,6 +11,50 @@ }; }; +&pru0_0 { + remoteproc-name = "pru0_0";

Why do we need all these? Looks like we fallback to using `dev->name` if these are not set, does that not work for us here?

Yes we will fallback to `dev->name` if `remoteproc-name` is not set but in our case two different PRU cores will have same `dev->name`. As a result the API rproc_name_is_unique() will return false and as a result the probe will fail for the PRU cores.

If `dev->name` is not unique, then combine it with something that is, or remove the requirement for the name to be unique. Right now this looks like just a hack around a framework requirement and a driver problem.

If you really think this is something that should be solved in DT then go convince the DT maintainers and get it into the kernel DT. We should be reducing the deltas we carry in -u-boot.dtsi files, not adding more workarounds.

Andrew

...

Example: In k3-am64-main.dtsi, both pru0_0 [1] and pru1_0 [2] will have dev->name as "pru@34000" same goes for rtu and txpru as well.
pru0_0: pru@34000 {
	compatible = "ti,am642-pru";
	reg = <0x34000 0x3000>,
	      <0x22000 0x100>,
	      <0x22400 0x100>;
	reg-names = "iram", "control", "debug";
	firmware-name = "am64x-pru0_0-fw";
};

pru1_0: pru@34000 {
	compatible = "ti,am642-pru";
	reg = <0x34000 0x4000>,
	      <0x22000 0x100>,
	      <0x22400 0x100>;
	reg-names = "iram", "control", "debug";
	firmware-name = "am64x-pru1_0-fw";
};
To avoid this, we are setting the "remoteproc-name" property in -u-boot.dtsi. Same is done for AM65x as well [3].

[1] https://elixir.bootlin.com/u-boot/v2024.07-rc3/source/dts/upstream/src/arm64... [2] https://elixir.bootlin.com/u-boot/v2024.07-rc3/source/dts/upstream/src/arm64... [3] https://elixir.bootlin.com/u-boot/v2024.07-rc3/source/arch/arm/dts/k3-am654-...

...
Andrew

...
+};

+&rtu0_0 { +    remoteproc-name = "rtu0_0"; +};

+&tx_pru0_0 { +    remoteproc-name = "tx_pru0_0"; +};

+&pru0_1 { +    remoteproc-name = "pru0_1"; +};

+&rtu0_1 { +    remoteproc-name = "rtu0_1"; +};

+&tx_pru0_1 { +    remoteproc-name = "tx_pru0_1"; +};

+&pru1_0 { +    remoteproc-name = "pru1_0"; +};

+&rtu1_0 { +    remoteproc-name = "rtu1_0"; +};

+&tx_pru1_0 { +    remoteproc-name = "tx_pru1_0"; +};

+&pru1_1 { +    remoteproc-name = "pru1_1"; +};

+&rtu1_1 { +    remoteproc-name = "rtu1_1"; +};

&main_timer0 {       clock-frequency = <200000000>; };

MD Danish Anwar

22 May 22 May

8:36 a.m.

New subject: [PATCH 2/3] configs: am64x_evm_a53: Enable ICSSG Driver

Enable ICSSG driver, DP83869 phy driver, REMOTEPROC and PRU_REMOTEPROC in am64x_evm_a53_defconfig. All these configs are needed for ICSSG driver.

Signed-off-by: MD Danish Anwar danishanwar@ti.com --- configs/am64x_evm_a53_defconfig | 5 +++++ 1 file changed, 5 insertions(+)

diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig index e000549d6d..6063286798 100644 --- a/configs/am64x_evm_a53_defconfig +++ b/configs/am64x_evm_a53_defconfig @@ -126,8 +126,10 @@ CONFIG_SPI_FLASH_MTD=y CONFIG_MULTIPLEXER=y CONFIG_MUX_MMIO=y CONFIG_PHY_TI_DP83867=y +CONFIG_PHY_TI_DP83869=y CONFIG_PHY_FIXED=y CONFIG_TI_AM65_CPSW_NUSS=y +CONFIG_TI_ICSSG_PRUETH=y CONFIG_PHY=y CONFIG_SPL_PHY=y CONFIG_PHY_CADENCE_TORRENT=y @@ -143,6 +145,8 @@ CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_TPS65219=y CONFIG_K3_SYSTEM_CONTROLLER=y CONFIG_REMOTEPROC_TI_K3_ARM64=y +CONFIG_REMOTEPROC_TI_PRU=y +CONFIG_CMD_REMOTEPROC=y CONFIG_RESET_TI_SCI=y CONFIG_DM_RTC=y CONFIG_RTC_EMULATION=y @@ -150,6 +154,7 @@ CONFIG_DM_SERIAL=y CONFIG_SOC_DEVICE=y CONFIG_SOC_DEVICE_TI_K3=y CONFIG_SOC_TI=y +CONFIG_TI_PRUSS=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_CADENCE_QSPI=y

-- 2.34.1

MD Danish Anwar

8:36 a.m.

New subject: [PATCH 3/3] board: ti: am64x: Set storage_interface and fw_dev_part ENVs

When ICSSG driver is enabled (CONFIG_TI_ICSSG_PRUETH=y) set storage_interface and fw_dev_part env variables.

These variables need be set appropriately in order to load different ICSSG firmwares needed for ICSSG driver. By default the storage interface is mmc and the partition is 1:2. User can modify this based on their needs.

Signed-off-by: MD Danish Anwar danishanwar@ti.com --- board/ti/am64x/am64x.env | 5 +++++ 1 file changed, 5 insertions(+)

diff --git a/board/ti/am64x/am64x.env b/board/ti/am64x/am64x.env index 9a8812d4ee..8ad805a613 100644 --- a/board/ti/am64x/am64x.env +++ b/board/ti/am64x/am64x.env @@ -39,3 +39,8 @@ usbboot=setenv boot usb; run get_kern_usb; run get_fdt_usb; run run_kern; + +#if CONFIG_TI_ICSSG_PRUETH +storage_interface=mmc +fw_dev_part=1:2 +#endif

-- 2.34.1

340

Age (days ago)

356

Last active (days ago)

List overview

Download

6 comments

3 participants

tags (0)

participants (3)

Andrew Davis
Anwar, Md Danish
MD Danish Anwar