SK-AM64B: ICSSG1 PRU firmware naming conflict in TI-SDK

Hello Ankush,

The default filesystem is working as expected - but the Linux devicetree is definitely wrong. I will file a bug against the devicetree.

First off, the Linux devicetree is definitely wrong in SDK 10.0. We use the same PRU firmware for AM65x Silicon Rev 2 and AM64x, hence the name "am65x-sr2". Even if we DID start using a different PRU firmware binary for AM64x, the name would be "am64x", NOT "AM64x-sr2":

https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-am642-evm.dts?h=ti-linux-6.6.y-cicd 

        icssg1_eth: icssg1-eth {
                compatible = "ti,am642-icssg-prueth";
                pinctrl-names = "default";
                pinctrl-0 = <&icssg1_rgmii1_pins_default>;
                sram = <&oc_sram>;
                ti,prus = <&pru1_0>, <&rtu1_0>, <&tx_pru1_0>, <&pru1_1>, <&rtu1_1>, <&tx_pru1_1>;
                firmware-name = "ti-pruss/am64x-sr2-pru0-prueth-fw.elf",
                                "ti-pruss/am64x-sr2-rtu0-prueth-fw.elf",
                                "ti-pruss/am64x-sr2-txpru0-prueth-fw.elf",
                                "ti-pruss/am64x-sr2-pru1-prueth-fw.elf",
                                "ti-pruss/am64x-sr2-rtu1-prueth-fw.elf",
                                "ti-pruss/am64x-sr2-txpru1-prueth-fw.elf";

With that said, the default filesystem is still working (i.e., it uses "am65x-sr2"). Off the top of my head, I am not sure WHY it works - I would expect it to be broken out-of-the-box.

I am running these tests on RT Linux 10.0:

root@am64xx-evm:/lib/firmware/ti-pruss# uname -a
Linux am64xx-evm 6.6.32-rt32-ti-rt-g04a9ad081f0f-dirty #1 SMP PREEMPT_RT Fri Jul 26 14:42:37 UTC 2024 aarch64 GNU/Linux

It looks like the firmware binaries are still named "am65x-sr2" in the filesystem:

root@am64xx-evm:/lib/firmware/ti-pruss# ls
...
am65x-sr2-pru0-prueth-fw.elf
etc

And when I bring the PRU Ethernet interface down and up, it is still correctly referencing the "am65x-sr2" binaries:

root@am64xx-evm:/lib/firmware/ti-pruss# ifconfig eth2 down
[1034928.484337] remoteproc remoteproc7: stopped remote processor 3008a000.txpru

root@am64xx-evm:/lib/firmware/ti-pruss# ifconfig eth2 192.168.1.164
[1034952.285849] remoteproc remoteproc15: powering up 300b4000.pru
[1034952.288340] remoteproc remoteproc15: Booting fw image ti-pruss/am65x-sr2-pru0-prueth-fw.elf, size 39464
[1034952.288381] remoteproc remoteproc15: unsupported resource 5
[1034952.288414] remoteproc remoteproc15: remote processor 300b4000.pru is now up
[1034952.288458] remoteproc remoteproc16: powering up 30084000.rtu
[1034952.288710] remoteproc remoteproc16: Booting fw image ti-pruss/am65x-sr2-rtu0-prueth-fw.elf, size 31140
[1034952.288752] remoteproc remoteproc16: remote processor 30084000.rtu is now up
[1034952.288786] remoteproc remoteproc7: powering up 3008a000.txpru
[1034952.297085] remoteproc remoteproc7: Booting fw image ti-pruss/am65x-sr2-txpru0-prueth-fw.elf, size 39068
[1034952.297154] remoteproc remoteproc7: remote processor 3008a000.txpru is now up
[1034952.301303] pps pps1: new PPS source ptp2

I will file a bug to fix this in SDK 10.1.

Regards,

Nick