PROCESSOR-SDK-AM64X: Loading R5 FW by Linux - SOC clock issue

Hello Dekel,

I assume you are talking about ti_power_clock_config.c, NOT ti_power_config.c (which I do not see in SysConfig).

I am looking to see if there are any TI examples where Linux loads the R5F firmware, AND the R5F firmware controls a peripheral.

1) What error behavior do you observe?

2) Are the peripherals that you are trying to access from R5F specifically disabled in the Linux devicetree? Remember that AM64x Linux devicetree nodes are enabled by default. If the peripherals are not explicitly disabled in Linux, I would expect issues when the R5F core tries to initialize them.

Regards,

Nick

Hello Dekel,

Followup from our offline discussion:

Making changes to Linux devicetree 

On AM64x & AM62x, the processor cores control a peripheral by requesting the peripheral from the SYSFW running on the DMSC core. SYSFW only allows a single core to control a peripheral. So if Linux requests a peripheral by enabling that peripheral in the Linux device tree, SYSFW will throw an error when an MCU+ core tries to request the same peripheral later.

If a Linux device tree node is defined, it is automatically enabled. That means if we want a peripheral to be controlled by an MCU+ core, we need to make sure that peripheral is explicitly disabled in the Linux device tree.

For getting started information about Linux development, reference the AM64x Linux Academy:
https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=AGqWQH5YSU6rleHcUT-o3w__7qm9DIS__LATEST
 Over time I'll add more pages to the Linux academy, including the information above.

The Linux devicetree files are in the Linux SDK under
board-support/linux-x.x.x/arch/arm64/boot/dts/ti

Let's say you are developing on the AM64x general purpose EVM. Then uboot will load k3-am642-evm.dtb (which is generated from k3-am642-evm.dts). k3-am642-evm.dts includes a bunch of other files, like k3-am64-main.dtsi. You want to make all your changes to k3-am642-evm.dts. That is because settings made in a .dtsi file can be overwritten by .dts files that include the .dtsi file. However, if you make your changes to the top-level .dts file, then you know that your settings will not be overwritten.

Based on your discussion above, you want to use ICSSG1, OSPI0, and i assume MCU domain UART0 (instead of MAIN domain UART0, which is used by Linux). If we look in k3-am642-evm.dts, we see that mcu_uart0 is disabled. However, both ICSSG1 and OSPI0 are used by Linux. For ospi0, set status = "disabled" just like mcu_uart0. For icssg1, change icssg1 and icssg1_mdio to disabled. (as of SDK 8.2, icssg0 is already disabled and can be used as a template. This may change in later SDK releases).

Once you make the Linux devicetree changes, rebuild the devicetree as documented in the Linux SDK docs:
https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/08_02_00_17/exports/docs/linux/Foundational_Components_Kernel_Users_Guide.html
You DO need to export the compiler and configure the kernel (the default kernel config should be fine for now), but I would expect that you do not need to build the kernel and the kernel modules - just the new devicetree file. The new devicetree file can be copied into the EVM's Linux filesystem in the /boot directory.

What if that does not work?  

1) attach your Linux devicetree changes so I can review them

2) provide the error logs.

For more information about MCU+ error logs, see https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_02_00_31/exports/docs/api_guide_am64x/KERNEL_DPL_DEBUG_PAGE.html

The Linux debugfs that the documentation mentioned can be seen here from the EVM's Linux terminal:
/sys/kernel/debug/remoteproc/remoteproc0/trace0 (where the remoteprocX number changes based on which remote core is used).

For more information about Linux remoteproc (including how to find the remoteproc number), reference the AM64x Linux Academy, section Evaluating Linux > Booting Remote Cores from Linux: https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=AGf47k0jnlMzDciz4huV1w__7qm9DIS__LATEST

Regards,

Nick

Hi Nick,

Thanks for your detailed answer.

I'm trying to disable, for R5 usage, the following peripherals -  ADC0, ICSSG1, UART0,  OSPI0 and SRAM addresses 0x70080000 – 0x701C0000.

1. ADC0, ICSSG1, UART0,  OSPI0 definitions are found at k3-am64-main.dtsi

Is it OK to disable them by changing their status to disabled  in the DTSI file, or there should be any reference in the DTS file as well?

2. Regarding to the SRAM, this is the reference in the DTSI file:

&cbass_main {

            oc_sram: sram@70000000 {

                        compatible = "mmio-sram";

                        reg = <0x00 0x70000000 0x00 0x200000>;

                        #address-cells = <1>;

                        #size-cells = <1>;

                        ranges = <0x0 0x00 0x70000000 0x200000>;

                        atf-sram@1c0000 {

                                    reg = <0x1c0000 0x20000>;

                        };

                        dmsc-sram@1e0000 {

                                    reg = <0x1e0000 0x1c000>;

                        };

                        sproxy-sram@1fc000 {

                                    reg = <0x1fc000 0x4000>;

                        };

            };

Please advise how to edit this section to let the R5 use addresses 0x70080000 – 0x701C0000. In this case we're changing the DTSI but again, is there any required change in the DTS file?

Thanks,

Dekel

Hello Dekel,

Allocating peripherals

For the peripherals, please disable them in Linux in the top-level .dts file, NOT the .dtsi include files. See my response above in https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1131974/processor-sdk-am64x-loading-r5-fw-by-linux---soc-clock-issue/4207015#4207015 , paragraph "Let's say you are developing on the AM64x general purpose EVM" for the reason why you should make all your changes to the top-level .dts file (i.e., the board dts file).

For example, let's make sure that ADC is disabled for the general purpose AM64x EVM board:

in k3-am642-evm.dts

Linux should already know to not use the ADC:

&tscadc0 {
        /* ADC is reserved for R5 usage */
        status = "reserved";
};

You could also set status = "disabled", like this:

&tscadc0 {
        /* ADC is reserved for R5 usage */
        status = "disabled";
};

As another example, let's disable the ospi. Remember, all of these changes are made in the board file k3-am642-evm.dts. By default, Linux expects to use OSPI0 to connect to a flash memory:

&ospi0 {
        pinctrl-names = "default";
        pinctrl-0 = <&ospi0_pins_default>;

        flash@0{
                compatible = "jedec,spi-nor";
                reg = <0x0>;
                spi-tx-bus-width = <8>;
                spi-rx-bus-width = <8>;
                spi-max-frequency = <25000000>;
                cdns,tshsl-ns = <60>;
                cdns,tsd2d-ns = <60>;
                cdns,tchsh-ns = <60>;
                cdns,tslch-ns = <60>;
                cdns,read-delay = <4>;
                cdns,phy-mode;
                #address-cells = <1>;
                #size-cells = <1>;
        };
};

We can disable OSPI in Linux by deleting the above code, and replacing it with code that looks like this:

&ospi0 {
        status = "disabled";
};

HOWEVER, there is one more thing to note! If you search for "ospi0", you will see that Linux is also setting the pinmux for ospi0:

        ospi0_pins_default: ospi0-pins-default {
                pinctrl-single,pins = <
                        AM64X_IOPAD(0x0000, PIN_OUTPUT, 0) /* (N20) OSPI0_CLK */
                        AM64X_IOPAD(0x002c, PIN_OUTPUT, 0) /* (L19) OSPI0_CSn0 */
                        AM64X_IOPAD(0x000c, PIN_INPUT, 0) /* (M19) OSPI0_D0 */
                        AM64X_IOPAD(0x0010, PIN_INPUT, 0) /* (M18) OSPI0_D1 */
                        AM64X_IOPAD(0x0014, PIN_INPUT, 0) /* (M20) OSPI0_D2 */
                        AM64X_IOPAD(0x0018, PIN_INPUT, 0) /* (M21) OSPI0_D3 */
                        AM64X_IOPAD(0x001c, PIN_INPUT, 0) /* (P21) OSPI0_D4 */
                        AM64X_IOPAD(0x0020, PIN_INPUT, 0) /* (P20) OSPI0_D5 */
                        AM64X_IOPAD(0x0024, PIN_INPUT, 0) /* (N18) OSPI0_D6 */
                        AM64X_IOPAD(0x0028, PIN_INPUT, 0) /* (M17) OSPI0_D7 */
                        AM64X_IOPAD(0x0008, PIN_INPUT, 0) /* (N19) OSPI0_DQS */
                >;
        };

We deleted "pinctrl-0 = <&ospi0_pins_default>;" from the &ospi0 node when we disabled it. That means Linux will not apply these pinmux settings, since the pinmux settings are no longer linked to the SPI driver for the OSPI0 peripheral. Delete the "ospi_pins_default" pinmux settings from k3-am642-evm.dts.

Each core sets the pinmux for itself. Since the R5F core is using the OSPI0 peripheral, that means you will need to make sure that the ospi pinmux settings are set properly in your R5F project's SysConfig settings.

Regards,

Nick

Hello Dekel,

Allocating memory

I started working on this response today, but ran out of time. To get started, take a look at https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/08_02_00_17/exports/docs/linux/Foundational_Components_IPC64x.html#dma-memory-carveouts.

This section in the MCU+ SDK also discusses a bit about allocating memory: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_03_00_18/exports/docs/api_guide_am64x/IPC_GUIDE.html#autotoc_md296

I will provide more information tomorrow.

Also, remind me: Are you only using R5F? Or are you also using the M4F?

Regards,

Nick

Hi Nick,

Thanks for the quick response.

I'm working on R5.

Dekel

Hello Dekel,

Allocating memory in SRAM: (EDITED September 26 2022: the information in this SRAM section is out of date. Please reference the next reply)

From the Linux side:

I do not think we need to make any changes to the Linux devicetree. It looks like the first 0x80000 of SRAM is reserved for DMSC as per https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_03_00_18/exports/docs/api_guide_am64x/MEMORY_MAP.html. However, Linux does not explicitly reserve that memory, so I assume that Linux does not use the SRAM by default. I am double-checking with the developers.

From the MCU+ side: 

The linker.cmd file must be updated to reserve the SRAM memory section. The examples mentioned in the MEMORY_MAP link above are here in the AM64x MCU+ SDK:
examples/industrial_comms/ethercat_slave_demo/simple/am64x-evm/r5fss0-0_freertos/ti-arm-clang/linker.cmd
examples/motor_control/benchmark_demo/am64x-evm/r5fss0-0_nortos/ti-arm-clang/linker.cmd

You can see in the ethercat slave demo, multiple parts of the program are stored in SRAM. The motor control benchmark reserves SRAM, but I am not totally sure about how the SRAM is used by the benchmark demo. I am double-checking with the developers.

Allocating memory in DDR: 

From the Linux side, the DDR memory sections that will be used by the remote cores must be reserved as described in the links in my previous response: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1131974/processor-sdk-am64x-loading-r5-fw-by-linux---soc-clock-issue/4217825#4217825 

Regards,

Nick

Edited Oct 4 2022: I have heard back from the MCU+ developers on SRAM usage. Updates are in the next reply. Sections in this reply with an update are indicated in RED.

Hello Dekel,

Ok, I have spent a bit more time looking into SRAM allocation on AM64x.

Allocating memory in SRAM (UPDATED): 

Linux: SRAM during Uboot:

The SRAM allocation in Uboot during R5 SPL is shown here:
https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/08_02_00_17/exports/docs/linux/Foundational_Components/U-Boot/UG-General-Info.html#sram-memory-layout-in-am64-during-r5-spl-bootloader-stage (scroll down to the bullet that starts with "In SDK 08.01 release").

However, after R5 SPL ends, the R5 SPL stops using the SRAM. The ATF & DMSC allocations continue to be used.

You can see a diagram of when R5 SPL runs in the boot process here:
https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/08_02_00_17/exports/docs/linux/Foundational_Components/U-Boot/UG-General-Info.html#boot-flow

Linux: SRAM during Linux boot time:

Linux reserves the SRAM from 0x701C0000 to 0x701FFFFF for ATF & DMSC. You can see the default memory allocations in the include file k3-am64x-main.dtsi:

	oc_sram: sram@70000000 {
		compatible = "mmio-sram";
		reg = <0x00 0x70000000 0x00 0x200000>;
		#address-cells = <1>;
		#size-cells = <1>;
		ranges = <0x0 0x00 0x70000000 0x200000>;

		atf-sram@1c0000 {
			reg = <0x1c0000 0x20000>;
		};

		dmsc-sram@1e0000 {
			reg = <0x1e0000 0x1c000>;
		};

		sproxy-sram@1fc000 {
			reg = <0x1fc000 0x4000>;
		};
	};

If we look in the board devicetree file k3-am642-evm.dts, we actually see that PRU Ethernet is using whatever parts of SRAM have not been reserved for other usecases:

	icssg1_eth: icssg1-eth {
		...
		sram = <&oc_sram>;
		...
	};

The memory allocations CANNOT overlap. It could cause problems if both the PRU Ethernet and a separate R5F program try to use the same memory. That means that the SRAM that will be allocated for remote cores should be defined in the board devicetree file.

Let us use the AM64x benchmark demo as an example:

Documentation at https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/08_02_00_17/exports/docs/system/Demo_User_Guides/Benchmark_Demo_User_Guide.html and https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_03_00_18/exports/docs/api_guide_am64x/EXAMPLE_MOTORCONTROL_BENCHMARKDEMO.html 

MCU+ code in the MCU+ SDK under examples/motor_control/benchmark_demo

In order to update k3-am642-evm.dts to match the SRAM allocations in the MCU+ SDK linker command files, add this code:

/ {
    ...
    /* DDR Definition */
    memory@80000000 {
        device_type = "memory";
        /* 2G RAM */
        reg = <0x00000000 0x80000000 0x00000000 0x80000000>;
 
    };
 
    /* DDR Allocation */
    reserved-memory {
        ...
    };
    ...
};
 
/* SRAM Allocation */
&oc_sram {
    r5f0-0-sram@80000 {
        reg = <0x80000 0x40000>;
    };
    
    r5f0-1-sram@c0000 {
        reg = <0xc0000 0x40000>;
    };
    
    r5f1-0-sram@100000 {
        reg = <0x100000 0x40000>;
    };
    
    r5f1-1-sram@140000 {
        reg = <0x140000 0x40000>;
    };
};

I am not sure if that leaves enough SRAM for ICSSG PRU Ethernet to function properly. PRU Ethernet SRAM requirements are not documented anywhere I can find, so I have filed a ticket to get that clarified in a future release.

MCU+: Allocating memory in SRAM (see October 4 2022 update in the next reply)

I am still checking with developers on the details here.

The linker.cmd file must be updated to reserve the SRAM memory section. The examples mentioned in the MEMORY_MAP link above are here in the AM64x MCU+ SDK:
examples/industrial_comms/ethercat_slave_demo/simple/am64x-evm/r5fss0-0_freertos/ti-arm-clang/linker.cmd
examples/motor_control/benchmark_demo/am64x-evm/r5fss0-0_nortos/ti-arm-clang/linker.cmd

You can see in the ethercat slave demo, multiple parts of the program are stored in SRAM. The motor control benchmark reserves SRAM, but I am not totally sure about how the SRAM is used by the benchmark demo. I am still double-checking with the developers.

What about SRAM usage when SBL is used? (see October 4 2022 update in the next reply)

At this point in time, I am not sure. I am checking with the developers.

The boot flow I have tested is:

1) Linux is loaded by uboot, as described here: https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/08_02_00_17/exports/docs/linux/Foundational_Components/U-Boot/UG-General-Info.html#boot-flow

2) the Linux remoteproc driver loads remote cores, as described here: https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__AE-Uk9kkw7.12iZKI12KZg__linux_academy_am64x__7qm9DIS__LATEST 

As of SDK 8.2, we have not enabled the remoteproc driver in Uboot for AM64x. If the system needs the remote cores to boot earlier in the process, the system can use a secondary boot loader (SBL) to load Linux and the remote cores at the same time: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_03_00_18/exports/docs/api_guide_am64x/EXAMPLES_DRIVERS_SBL_OSPI_LINUX.html 

Regards,

Nick

Hello Dekel,

This is the final update from my side until I hear back from you.

MCU+: Allocating memory in SRAM (update)

Updated information in RED.

The linker.cmd file must be updated to reserve the SRAM memory section. The examples mentioned in the MEMORY_MAP link above are here in the AM64x MCU+ SDK:
examples/industrial_comms/ethercat_slave_demo/simple/am64x-evm/r5fss0-0_freertos/ti-arm-clang/linker.cmd
examples/motor_control/benchmark_demo/am64x-evm/r5fss0-0_nortos/ti-arm-clang/linker.cmd

You can see in the ethercat slave demo, multiple parts of the program are stored in SRAM. The motor control benchmark demo reserves SRAM, but it does not actually place any parts of the program into the SRAM. That means that the SRAM section will remain unused unless the R5F code specifically writes to the SRAM (e.g., in a multicore "shared memory" usecase, where data to be passed between cores is placed in that location in SRAM).

What about SRAM usage when SBL is used? (update)

Updated information in RED.

I have only tested a bootflow that does NOT use SBL:

1) Linux is loaded by uboot, as described here: https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/08_02_00_17/exports/docs/linux/Foundational_Components/U-Boot/UG-General-Info.html#boot-flow

2) the Linux remoteproc driver loads remote cores, as described here: https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__AE-Uk9kkw7.12iZKI12KZg__linux_academy_am64x__7qm9DIS__LATEST 

As of SDK 8.4, we have not enabled the remoteproc driver in Uboot for AM64x. If the system needs the remote cores to boot earlier in the process, the system can use a secondary boot loader (SBL) to load Linux and the remote cores at the same time: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_03_00_18/exports/docs/api_guide_am64x/EXAMPLES_DRIVERS_SBL_OSPI_LINUX.html 

The SBL on AM64x places some of its data in SRAM. The parts of SRAM that are used by SBL are shown in the AM64x memory map: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_04_00_17/exports/docs/api_guide_am64x/MEMORY_MAP.html

The SBL ONLY uses memory and peripherals while the SBL is running. Once the firmware is running on an R5 or Linux is starting to boot on the A53, you know that the SBL has completed. If the SBL SRAM memory is modified during the SBL, the processor will crash.

What does that mean?

Other cores can use the parts of SRAM that are used by the SBL, but only AFTER the SBL finishes. Since the SBL is loading the R5F in this usecase, that means that R5F can only put NOLOAD data in the part of SRAM used by SBL ("no load" memory sections include BSS, and other "runtime" memory stacks). If the R5F tries to put initialized data in the part of SRAM used by SBL (e.g., .text, .rodata, .data), then when the SBL loads the R5F, the SBL will overwrite its own SRAM with the R5F data and crash.

Regards,

Nick

Hi Nick Saulnier

I am working with Dekel on the AM64x GP EVM board.

Thank you for the very informative replies. They are very hopeful.

I have a follow up question regarding modifications to the DTS.
The AM64x GP-EVM board has 3 ethernet ports. We would like to do the following reservation:

1. Two ethernet ports used by A53 core (Linux system)
2. One gigabit ethernet port reserved and used by R5F core.

I saw that ICSSG device is used to define configuration values for ethernet ports in the device tree.
However modifying the DTS to edit the ICSSG devices to accomplish the task above is not a trivial matter for us.

How can we modify the device tree source file to achieve the distribution of ethernet ports?

Thanks,
Ben S.

Hello Ben,

There are two kinds of Ethernet peripherals on the AM64x: The CPSW (which can have 2 external Ethernet ports), and the PRU Ethernet (Each PRU_ICSSG can have 2 external Ethernet ports, and there are 2 PRU_ICSSGs in the processor). Note that there is some overlap between pinmuxing, so AM64x cannot have all 6 Ethernet ports enabled at the same time. See this thread for more: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1018412/am6442-ethernet-ports

Each peripheral can only be controlled by one core. So either Linux or R5 could control the CPSW, or PRU_ICSSG0, or PRU_ICSSG1. So first you need to decide which core is going to control which peripheral.

The AM64x GP-EVM actually allows you to switch which whether Linux is using 1 CPSW port and 2 PRU Ethernet ports, or 2 CPSW ports and 1 PRU Ethernet port. See this post for more information on how to switch between the two settings for Linux: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1137215/tmds64gpevm-eth1-port-is-cpsw-instead-of-prueth

Regards,

Nick

Thank you Nick. I will try that and update soon.

Hello Ben & Dekel,

Someone in your group wanted a notification when the IPC shared memory example was published (I cannot remember who). That example is now live at https://git.ti.com/cgit/rpmsg/rpmsg_char_zerocopy/

I am still working on publishing additional documentation for the example sometime over the next couple of months. If there is any feedback or questions, please create a new thread where I can provide support.

Regards,

Nick

Hi Nick, Thanks for the update, I will notify the relevant team members about the rpmsg example.

I completed the changes you specified for the device tree.
I was unsure if setting status to disabled is enough in some cases, or if I have to delete the pinmux configurations in some areas, even though no section uses it. I went with your example to delete the configurations that are unused.

I also used your oc_sram example, also it seems from the discussion these values may not be accurate because of lack of documentation on sram usage.

Here the the git diff file, I can also share the complete DTS file if necessary.
I have created a Linux image with this DTB and passed it on for further testing.

diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index 145e4e6e038c..b27dc1a594d0 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -21,11 +21,6 @@ chosen {
                bootargs = "console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000";
        };

-       aliases {
-               ethernet2 = &icssg1_emac0;
-               ethernet3 = &icssg1_emac1;
-       };
-
        memory@80000000 {
                device_type = "memory";
                /* 2G RAM */
@@ -217,65 +212,7 @@ transceiver2: can-phy1 {
        };

        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/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>;
-
-               mii-g-rt = <&icssg1_mii_g_rt>;
-               mii-rt = <&icssg1_mii_rt>;
-               iep = <&icssg1_iep0>,  <&icssg1_iep1>;
-
-               interrupt-parent = <&icssg1_intc>;
-               interrupts = <24 0 2>, <25 1 3>;
-               interrupt-names = "tx_ts0", "tx_ts1";
-
-               dmas = <&main_pktdma 0xc200 15>, /* egress slice 0 */
-                      <&main_pktdma 0xc201 15>, /* egress slice 0 */
-                      <&main_pktdma 0xc202 15>, /* egress slice 0 */
-                      <&main_pktdma 0xc203 15>, /* egress slice 0 */
-                      <&main_pktdma 0xc204 15>, /* egress slice 1 */
-                      <&main_pktdma 0xc205 15>, /* egress slice 1 */
-                      <&main_pktdma 0xc206 15>, /* egress slice 1 */
-                      <&main_pktdma 0xc207 15>, /* egress slice 1 */
-                      <&main_pktdma 0x4200 15>, /* ingress slice 0 */
-                      <&main_pktdma 0x4201 15>, /* ingress slice 1 */
-                      <&main_pktdma 0x4202 0>, /* mgmnt rsp slice 0 */
-                      <&main_pktdma 0x4203 0>; /* mgmnt rsp slice 1 */
-               dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
-                           "tx1-0", "tx1-1", "tx1-2", "tx1-3",
-                           "rx0", "rx1",
-                           "rxmgm0", "rxmgm1";
-
-               icssg1_emac0: ethernet-mii0 {
-                       phy-handle = <&icssg1_phy1>;
-                       phy-mode = "rgmii-rxid";
-                       syscon-rgmii-delay = <&main_conf 0x4110>;
-                       /* Filled in by bootloader */
-                       local-mac-address = [00 00 00 00 00 00];
-               };
-
-               icssg1_emac1: ethernet-mii1 {
-                       syscon-rgmii-delay = <&main_conf 0x4114>;
-                       /* Filled in by bootloader */
-                       local-mac-address = [00 00 00 00 00 00];
-                       status = "disabled";
-               };
+               status = "disabled";
        };
 };

@@ -396,22 +333,6 @@ AM64X_IOPAD(0x02a8, PIN_OUTPUT, 0) /* (E19) USB0_DRVVBUS */
                >;
        };

-       ospi0_pins_default: ospi0-pins-default {
-               pinctrl-single,pins = <
-                       AM64X_IOPAD(0x0000, PIN_OUTPUT, 0) /* (N20) OSPI0_CLK */
-                       AM64X_IOPAD(0x002c, PIN_OUTPUT, 0) /* (L19) OSPI0_CSn0 */
-                       AM64X_IOPAD(0x000c, PIN_INPUT, 0) /* (M19) OSPI0_D0 */
-                       AM64X_IOPAD(0x0010, PIN_INPUT, 0) /* (M18) OSPI0_D1 */
-                       AM64X_IOPAD(0x0014, PIN_INPUT, 0) /* (M20) OSPI0_D2 */
-                       AM64X_IOPAD(0x0018, PIN_INPUT, 0) /* (M21) OSPI0_D3 */
-                       AM64X_IOPAD(0x001c, PIN_INPUT, 0) /* (P21) OSPI0_D4 */
-                       AM64X_IOPAD(0x0020, PIN_INPUT, 0) /* (P20) OSPI0_D5 */
-                       AM64X_IOPAD(0x0024, PIN_INPUT, 0) /* (N18) OSPI0_D6 */
-                       AM64X_IOPAD(0x0028, PIN_INPUT, 0) /* (M17) OSPI0_D7 */
-                       AM64X_IOPAD(0x0008, PIN_INPUT, 0) /* (N19) OSPI0_DQS */
-               >;
-       };
-
        main_mcan0_pins_default: main-mcan0-pins-default {
                pinctrl-single,pins = <
                        AM64X_IOPAD(0x0254, PIN_INPUT, 0) /* (B17) MCAN0_RX */
@@ -426,13 +347,6 @@ AM64X_IOPAD(0x0258, PIN_OUTPUT, 0) /* (C17) MCAN1_TX */
                >;
        };

-       icssg1_mdio1_pins_default: icssg1-mdio1-pins-default {
-               pinctrl-single,pins = <
-                       AM64X_IOPAD(0x015c, PIN_OUTPUT, 0) /* (Y6) PRG1_MDIO0_MDC */
-                       AM64X_IOPAD(0x0158, PIN_INPUT, 0) /* (AA6) PRG1_MDIO0_MDIO */
-               >;
-       };
-
        icssg1_rgmii1_pins_default: icssg1-rgmii1-pins-default {
                pinctrl-single,pins = <
                        AM64X_IOPAD(0x00b8, PIN_INPUT, 2) /* (Y7) PRG1_PRU0_GPO0.PRG1_RGMII1_RD0 */
@@ -720,24 +634,7 @@ &tscadc0 {
 };

 &ospi0 {
-       pinctrl-names = "default";
-       pinctrl-0 = <&ospi0_pins_default>;
-
-       flash@0{
-               compatible = "jedec,spi-nor";
-               reg = <0x0>;
-               spi-tx-bus-width = <8>;
-               spi-rx-bus-width = <8>;
-               spi-max-frequency = <25000000>;
-               cdns,tshsl-ns = <60>;
-               cdns,tsd2d-ns = <60>;
-               cdns,tchsh-ns = <60>;
-               cdns,tslch-ns = <60>;
-               cdns,read-delay = <4>;
-               cdns,phy-mode;
-               #address-cells = <1>;
-               #size-cells = <1>;
-       };
+    status = "disabled";
 };

 &main_mcan0 {
@@ -752,17 +649,40 @@ &main_mcan1 {
        phys = <&transceiver2>;
 };

+/* Modify sram label present in k3-am64-main.dtsi */
+&oc_sram {
+    r5f0-0-sram@80000 {
+        reg = <0x80000 0x40000>;
+    };
+
+    r5f0-1-sram@c0000 {
+        reg = <0xc0000 0x40000>;
+    };
+
+    r5f1-0-sram@100000 {
+        reg = <0x100000 0x40000>;
+    };
+
+    r5f1-1-sram@140000 {
+        reg = <0x140000 0x40000>;
+    };
+};
+
+/* Disabled as i have seen in k3-am642-sk.dts */
+&icssg0 {
+        status = "disabled";
+};
+
+&icssg1 {
+        status = "disabled";
+};
+
 &icssg0_mdio {
        status = "disabled";
 };

 &icssg1_mdio {
-       pinctrl-names = "default";
-       pinctrl-0 = <&icssg1_mdio1_pins_default>;
-
-       icssg1_phy1: ethernet-phy@0 {
-               reg = <0xf>;
-       };
+       status = "disabled";
 };

 &ecap0 {

Hello Ben,

The diff file looks pretty good. I would expect it to work for preventing Linux from using either PRU_ICSSG instance.

You should also be able to just delete the icssg1_eth node entirely if you want. (notice that nodes that begin with an ampersand (&) like &icssg1_mdio are already defined in another device tree file, so those need to get set to "disabled". But if the node is defined for the first time in the board dts file, then you can just delete the node)

As far as defining SRAM allocations, it looks like you also want to reference the sram carveout within the R5 node. I was able to find an example of this usage in an older version of the Linux SDK (AM64x SDK 8.0, file k3-am642-evm.dts).

&oc_sram {
...
        main_r5fss1_core0_sram: r5f-sram@c0000 {
                reg = <0xc0000 0x40000>;
        };
...
};

...

&main_r5fss1_core0 {
        mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core0>;
        memory-region = <&main_r5fss1_core0_dma_memory_region>,
                        <&main_r5fss1_core0_memory_region>;
        sram = <&main_r5fss1_core0_sram>;
};
...

Regards,

Nick

Hi Nick, Thank you for the feedback so far.

We have made the relevant changes in the DTB like you specified:

+/* Modify sram label present in k3-am64-main.dtsi */
+&oc_sram {
+    main_r5fss0_core0_sram: r5f-sram@80000 {
+        reg = <0x80000 0x40000>;
+    };
+    
+    main_r5fss0_core1_sram: r5f-sram@c0000 {
+        reg = <0xc0000 0x40000>;
+    };
+    
+    main_r5fss1_core0_sram: r5f-sram@100000 {
+        reg = <0x100000 0x40000>;
+    };
+    
+    main_r5fss1_core1_sram: r5f-sram@140000 {
+        reg = <0x140000 0x40000>;
+    };
+};


@ -283,24 +220,28 @@ &main_r5fss0_core0 {
 	mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core0>;
 	memory-region = <&main_r5fss0_core0_dma_memory_region>,
 			<&main_r5fss0_core0_memory_region>;
+	sram = <&main_r5fss0_core0_sram>;
 };
 
 &main_r5fss0_core1 {
 	mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core1>;
 	memory-region = <&main_r5fss0_core1_dma_memory_region>,
 			<&main_r5fss0_core1_memory_region>;
+	sram = <&main_r5fss0_core1_sram>;
 };
 
 &main_r5fss1_core0 {
 	mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core0>;
 	memory-region = <&main_r5fss1_core0_dma_memory_region>,
 			<&main_r5fss1_core0_memory_region>;
+	sram = <&main_r5fss1_core0_sram>;
 };
 
 &main_r5fss1_core1 {
 	mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core1>;
 	memory-region = <&main_r5fss1_core1_dma_memory_region>,
 			<&main_r5fss1_core1_memory_region>;
+	sram = <&main_r5fss1_core1_sram>;
 };

We are still getting a memory access error when trying to load the firmware:

[    6.162010] k3-m4-rproc 5000000.m4fss: assigned reserved memory node m4f-dma-memory@a4000000
[    6.270308] k3-m4-rproc 5000000.m4fss: configured M4 for remoteproc mode
[    6.307840] k3-m4-rproc 5000000.m4fss: local reset is deasserted for device
[    6.310855] rti-wdt bus@f4000:watchdog@e000000: invalid resource
[    6.390531] rti-wdt: probe of bus@f4000:watchdog@e000000 failed with error -22
[    6.398329] platform 78000000.r5f: configured R5F for remoteproc mode
[    6.405542] remoteproc remoteproc0: 5000000.m4fss is available
[    6.444272] rti-wdt bus@f4000:watchdog@e010000: invalid resource
[    6.464976] platform 78000000.r5f: assigned reserved memory node r5f-dma-memory@a0000000
[    6.479640] remoteproc remoteproc0: powering up 5000000.m4fss
[    6.485520] remoteproc remoteproc0: Booting fw image am64-mcu-m4f0_0-fw, size 2968680
[    6.498949] remoteproc remoteproc0: bad phdr da 0x70080400 mem 0x40
[    6.505437] remoteproc remoteproc0: Failed to load program segments: -22
[    6.523205] remoteproc remoteproc1: 78000000.r5f is available
[    6.533987] remoteproc remoteproc1: powering up 78000000.r5f
[    6.540981] remoteproc remoteproc1: Booting fw image am64-main-r5f0_0-fw, size 2968680
[    6.547475] platform 78200000.r5f: configured R5F for remoteproc mode
[    6.566486] remoteproc remoteproc1: bad phdr da 0x70080440 mem 0xa5fc0
[    6.568135] rti-wdt: probe of bus@f4000:watchdog@e010000 failed with error -22
[    6.573170] remoteproc remoteproc1: Failed to load program segments: -22
[    6.734954] platform 78200000.r5f: assigned reserved memory node r5f-dma-memory@a1000000
[    6.769304] m_can_platform 20701000.can: m_can device registered (irq=35, version=32)
[    6.785744] m_can_platform 20711000.can: m_can device registered (irq=37, version=32)
[    6.952494] remoteproc remoteproc2: 78200000.r5f is available
[    7.032090] remoteproc remoteproc2: Direct firmware load for am64-main-r5f0_1-fw failed with error -2
[    7.046492] remoteproc remoteproc2: powering up 78200000.r5f
[    7.052325] remoteproc remoteproc2: Direct firmware load for am64-main-r5f0_1-fw failed with error -2
[    7.065115] remoteproc remoteproc2: request_firmware failed: -2
[    7.114501] platform 78400000.r5f: configured R5F for remoteproc mode
[    7.198946] platform 78400000.r5f: assigned reserved memory node r5f-dma-memory@a2000000
[    7.303052] remoteproc remoteproc3: 78400000.r5f is available
[    7.394531] remoteproc remoteproc3: Direct firmware load for am64-main-r5f1_0-fw failed with error -2
[    7.404904] platform 78600000.r5f: configured R5F for remoteproc mode
[    7.411494] remoteproc remoteproc3: powering up 78400000.r5f
[    7.417395] remoteproc remoteproc3: Direct firmware load for am64-main-r5f1_0-fw failed with error -2
[    7.426732] remoteproc remoteproc3: request_firmware failed: -2
[    7.438988] platform 78600000.r5f: assigned reserved memory node r5f-dma-memory@a3000000
[    7.467130] remoteproc remoteproc4: 78600000.r5f is available
[    7.486075] remoteproc remoteproc4: Direct firmware load for am64-main-r5f1_1-fw failed with error -2
[    7.498750] remoteproc remoteproc4: powering up 78600000.r5f
[    7.504747] remoteproc remoteproc4: Direct firmware load for am64-main-r5f1_1-fw failed with error -2
[    7.518546] remoteproc remoteproc4: request_firmware failed: -2

Only one firmware is loaded - am64-main-r5f0_0-fw
We get the errors while the firmware is being loaded:

1. bad phdr da 0x70080400 mem 0x40
2.  bad phdr da 0x70080440 mem 0xa5fc0

I have looked over the map file output of our firmware AM64_APP.out:

OUTPUT FILE NAME:   <AM64_APP.out>
ENTRY POINT SYMBOL: "_vectors"  address: 00000000


MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
PAGE 0:
  R5F_VECS              00000000   00000040  00000040  00000000  RWIX
  R5F_TCMA              00000040   00007fc0  000014d4  00006aec  RWIX
  R5F_TCMB0             41010000   00008000  00000000  00008000  RWIX
  FLASH                 60100000   00080000  00000000  00080000  RWIX
  NON_CACHE_MEM         70060000   00008000  00000000  00008000  RWIX
  MSRAM                 70080000   00140000  00112358  0002dca8  RWIX
  DDR                   80000000   00fe3800  00000000  00fe3800  RWIX
  DDR_ICSS_FW           80fe3800   0001c800  0000c7a8  00010058  RWIX
  LINUX_IPC_SHM_MEM     a0000000   00100000  00000000  00100000  RWIX
  DDR_0                 a0100000   00001000  00001000  00000000  RWIX
  DDR_1                 a0101000   00eff000  00000000  00eff000  RWIX
  USER_SHM_MEM          a5000000   00000080  00000000  00000080  RWIX
  LOG_SHM_MEM           a5000080   00003f80  00000000  00003f80  RWIX
  RTOS_NORTOS_IPC_SHM_M a5004000   0000c000  00001140  0000aec0  RWIX

PAGE 1:
  DDR_ICSS_FW_OVERLAY_M 80fe3800   0001c800  0001c800  00000000  RWIX


SEGMENT ALLOCATION MAP

run origin  load origin   length   init length attrs members
----------  ----------- ---------- ----------- ----- -------
00000000    00000000    00000040   00000040    r-x
  00000000    00000000    00000040   00000040    r-x .vectors
00000568    00000568    00000fb0   00000fb0    r--
  00000568    00000568    00000fb0   00000fb0    r-- .cinit
70080400    70080400    00000040   00000000    rw-
  70080400    70080400    00000040   00000000    rw- .TI.bound:gProxSig
70080440    70080440    000a5fc0   000a5fc0    r-x
  70080440    70080440    00090c20   00090c20    r-x .text
  70111060    70111060    000153a0   000153a0    r-- .rodata
70126400    70126400    000536a0   00000000    rw-
  70126400    70126400    00046a00   00000000    rw- .bss
  7016ce00    7016ce00    00008ca0   00000000    rw- .sysmem
  70175aa0    70175aa0    00004000   00000000    rw- .stack
70179ac0    70179ac0    00014f80   00000000    rw-
  70179ac0    70179ac0    00014f80   00000000    rw- .data
7018ea40    7018ea40    00003d38   00001b38    r-x
  7018ea40    7018ea40    00001090   00001090    r-x .text.hwi
  7018fad0    7018fad0    00000550   00000550    r-x .text.cache
  70190020    70190020    000003f0   000003f0    r-x .text.mpu
  70190410    70190410    00000160   00000160    r-x .text.boot
  70190570    70190570    00000008   00000008    r-x .text:abort
  70190578    70190578    00000800   00000000    r-- .irqstack
  70190d78    70190d78    00000800   00000000    r-- .fiqstack
  70191578    70191578    00001000   00000000    r-- .svcstack
  70192578    70192578    00000100   00000000    r-- .abortstack
  70192678    70192678    00000100   00000000    r-- .undefinedstack
80fe3800    80fe3800    0000c7a8   0000c7a8    r--
  80fe3800    80fe3800    0000c7a8   0000c7a8    r-- .icssfw
a0100000    a0100000    00001000   00001000    r--
  a0100000    a0100000    00001000   00001000    r-- .resource_table
  

I have noticed that the 0x40 first bytes are for the vector handling, and it already fails at that stage, and presumable continues to try and load the firmware file and fails again later.

Some things to note are:

According to our map file, the total area used by SRAM is 0x00112358
This is within the allowed limit of 0x140000 

According to the memory map specified in:
https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/latest/exports/docs/api_guide_am64x/MEMORY_MAP.html

Where memory for all R5 cores + Unallocated memory is total 0x140000

Since there are no other firmwares loaded, i assume it is ok to use the entire region for R5F0_0.

Here is part of procfs directory tree on linux, where we can see the DTB is parsed correctly:

root@am64xx-evm:/proc/device-tree/bus@f4000/sram@70000000# ll
-r--r--r--    1 root     root             4 Dec  6 15:53 #address-cells
-r--r--r--    1 root     root             4 Dec  6 15:53 #size-cells
drwxr-xr-x    9 root     root             0 Dec  6 15:53 .
drwxr-xr-x   69 root     root             0 Dec  6 15:53 ..
drwxr-xr-x    2 root     root             0 Dec  6 15:53 atf-sram@1c0000
-r--r--r--    1 root     root            10 Dec  6 15:53 compatible
drwxr-xr-x    2 root     root             0 Dec  6 15:53 dmsc-sram@1e0000
-r--r--r--    1 root     root             5 Dec  6 15:53 name
drwxr-xr-x    2 root     root             0 Dec  6 15:53 r5f-sram@100000
drwxr-xr-x    2 root     root             0 Dec  6 15:53 r5f-sram@140000
drwxr-xr-x    2 root     root             0 Dec  6 15:53 r5f-sram@80000
drwxr-xr-x    2 root     root             0 Dec  6 15:53 r5f-sram@c0000
-r--r--r--    1 root     root            16 Dec  6 15:53 ranges
-r--r--r--    1 root     root            16 Dec  6 15:53 reg
drwxr-xr-x    2 root     root             0 Dec  6 15:53 sproxy-sram@1fc000

root@am64xx-evm:/proc/device-tree/bus@f4000/sram@70000000/r5f-sram@80000# ll
drwxr-xr-x    2 root     root             0 Dec  6 15:53 .
drwxr-xr-x    9 root     root             0 Dec  6 15:53 ..
-r--r--r--    1 root     root             9 Dec  6 15:53 name
-r--r--r--    1 root     root             4 Dec  6 15:53 phandle
-r--r--r--    1 root     root             8 Dec  6 15:53 reg

The sections we added for r5f-sram are visible in the directory tree.

What should we do next to solve the bad phdr memory issue?

Hi Nick,

I just wanted to add to the above post -

I have also tried modified the DTB to give the entire range of SRAM memory allocated to the first R5F

/* Modify sram label present in k3-am64-main.dtsi */
&oc_sram {
    main_r5fss0_core0_sram: r5f-sram@80000 {
        reg = <0x80000 0x1C0000>;
    };
};

/* r5f0_0 uses the entire 0x1c0000 memory range, and the other cores do not use any */
&main_r5fss0_core0 {
        mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core0>;
        memory-region = <&main_r5fss0_core0_dma_memory_region>,
                        <&main_r5fss0_core0_memory_region>;
        sram = <&main_r5fss0_core0_sram>;
};

&main_r5fss0_core1 {
        mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core1>;
        memory-region = <&main_r5fss0_core1_dma_memory_region>,
                        <&main_r5fss0_core1_memory_region>;
};

&main_r5fss1_core0 {
        mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core0>;
        memory-region = <&main_r5fss1_core0_dma_memory_region>,
                        <&main_r5fss1_core0_memory_region>;
};

&main_r5fss1_core1 {
        mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core1>;
        memory-region = <&main_r5fss1_core1_dma_memory_region>,
                        <&main_r5fss1_core1_memory_region>;
};

However, this did not resolve the issue either.

I have also noticed the WDT is failing, in a different area of SRAM.
Maybe it's an unrelated issue:

[    6.568135] rti-wdt: probe of bus@f4000:watchdog@e010000 failed with error -22

The WD error specified here also happens when using the default DTB file k3-am642-evm.dtb

Hello Ben & Dekel,

Hmm. Linux error code 2 is "ENOENT - No such file or directory". I wonder if the firmware is located in the location that the Linux RemoteProc driver is looking for.

Can I get you to double-check that the firmware is in the expected place? (or that there is a link with the right name in the expected place, and the link is pointing to the firmware?) Please reference https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__ANKEb6LZY6VAX.9xvGwQ-g__linux_academy_am64x__7qm9DIS__LATEST

Regards,

Nick

R5F0_0 - Firmware is present, and fails to load segments with error -22
R5F0_1 - Firmware not present (error -2)
R5F1_0 - Firmware not present (error -2)
R5F1_1 - Firmware not present (error -2)

We only want to test R5F0_0 right now.
The missing firmware error is intentional for the other cores.

First: make sure there are no oc_sram allocation conflicts 

If you are allocating this to R5F0_0:

reg = <0x80000 0x1C0000>;

then you are going to overlap with these reserved portions of SRAM from k3-am64-main.dtsi:

atf-sram@1c0000 {
reg = <0x1c0000 0x20000>;
};

dmsc-sram@1e0000 {
reg = <0x1e0000 0x1c000>;
};

sproxy-sram@1fc000 {
reg = <0x1fc000 0x4000>;
};

So first, change your allocation and retest. Does it work now?

Second: if you are still seeing issues after resolving the oc_sram allocation conflicts, let's make sure the SRAM allocation itself is not causing the issues

Steps to test: 

1) set all unused R5 cores to status = "disabled" in the Linux devicetree

2) comment out all the SRAM allocations you added other than the one for R5F0

3) in the R50 firmware, remove all dependencies on SRAM.
i.e.,
in the linker.cmd file don't put any data sections in SRAM
in the R5F0 code, don't read or write anything to SRAM

At this point, Linux should just be allocating SRAM to the R5f0_0, but not actually doing anything with the memory. Do you still see the error?

Now don't change anything except the Linux devicetree. Remote the SRAM allocation and test again. Has the error gone away?

Regards,

Nick

Hi Nick,

I Updated the allocation for R5f0_0 to the correct size. This seemed to help as now the error happens on loading for a different segment.
remoteproc remoteproc0: bad phdr da 0x80fe3800 mem 0xc7a8

I will ask Dekel to investigate this new error a bit before we proceed.

I also wanted to note that setting status = "disabled" for the other cores (R5F0_1 R5F1_0 R5F1_1), seemed to also prevent R5F0_0 core from loading the firmware. Meaning, it did not even attempt to load firmware, maybe a sanity checked stopped it from even attempting to load an FW.

So the solution I am using right now is allocating the entire memory 0x70080000 - 0x701C0000 (total length 0x140000) to R5F0_0 core.
The other cores are still active, however I commented out their SRAM mappings.

I will update when I have more information. Thanks.

Hello Ben,

Disabling other remote cores

Hmm, the status = "disabled" behavior is surprising to me. At the very least, disabling the cores in R5F1 should not impact the cores in R5F0. Maybe single-CPU mode is required to be used instead of split mode if only Core0 of an R5F cluster is used. Something like this:

&main_r5fss0 {
    ti,cluster-mode = <2>;
}

and then I would assume that you would also need to set core1 to disabled.

double-checking: PRU Ethernet is disabled, right?

Just to verify, The PRU_ICSSG instances are no longer loading PRU Ethernet in the devicetree file, right?

What we are trying to do above is statically allocate SRAM to the R5F core. The Linux PRU Ethernet driver also requests SRAM with a dynamic allocation (you can see the sram request in k3-am642-evm.dts in the icssg1_eth node). So if PRU Ethernet is still getting probed during Linux boot time, that might also be causing issues.

Regards,

Nick

More details about single-CPU mode vs split mode are in the bindings documentation:
Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml