AM6421: EtherNet IP adapter program execution failing through remote proc mechanism through linux.

Hi Ashwani,

       Thank you for the reply.

      The Link what you have given is for MCU+SDK 9.01.00 but we are using MCU+SDK V9.00.35

        Our issue is The Ethernet-IP Adaptor application is not working on R5F0_0 after remote boot from Linux using remoteproc. with board in SD-Boot mode.

       Whereas Same Ethernet-IP Adaptor application is working when we load through JTAG with board in NO-Boot mode.

      The logs from Linux are already shared in previous posts.

Hi Ashwani,

       Thank you for the reply.

      The Link what you have given is for MCU+SDK 9.01.00 but we are using MCU+SDK V9.00.35

        Our issue is The Ethernet-IP Adaptor application is not working on R5F0_0 after remote boot from Linux using remoteproc. with board in SD-Boot mode.

       Whereas Same Ethernet-IP Adaptor application is working when we load through JTAG with board in NO-Boot mode.

      The logs from Linux are already shared in previous posts.

Thank You

Hi Narasimha Rao,

We are working on this. Will get back as we get something to share.

Meanwhile, can you try some other MCU+SDK example using ICSSG-networking (example: A basic example for TCP server on ICSSG) and confirm whether ping is working correctly ?

software-dl.ti.com/.../EXAMPLES_ENET_LWIP_ICSSG_TCPSERVER.html

Best Regards

Ashwani

Sonu Kumar said:

[r5f0-0]    20.317481s : CUST_PHY_SPEED_DUPLEX_eCONFIG_10HD

You are working with EIP on 10M Half duplex ?

Best Regards

Ashwani

Hi Ashwani,

            After Auto negotiation this is what it is shown.

    And The same ethernet-ip Application is working well when we run from JTAG in no-boot mode.

   But in Linux Boot from sd card we are unable to communicate. we see that pru core remoteproc is not running.

  Logs are already given.

Thank You.

Hello Narasimha,

Double checking the board config settings

The am64x-evm.syscfg file you provided me was the wrong one again.
It looks like the unmodified one from the AM64x SDK 9.0, instead of the updated one I asked you to download from here: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1308689/faq-how-to-use-k3-resource-partitioning-tool-with-processor-sdk-v9-0-or-v9-1/4970549#4970549

I generated my own settings and compared against the rm-cfg.yaml file Nikhil attached to this response
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1314557/am6421-ethernet-ip-adapter-program-execution-failing-through-remote-proc-mechanism-through-linux/5023604#5023604

That YAML file looks the way I would expect (assuming you are using ICSSG1 with R5F0_0, and assuming you are NOT using ICSSG0 with R5F0_0). So as long as you used that file to generate your uboot files, I would expect the board config to be fine.

Regards,

Nick

Is there any other debug information we can see from the Linux side? 

Reviewing the output provided at 
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1314557/am6421-ethernet-ip-adapter-program-execution-failing-through-remote-proc-mechanism-through-linux/5041263#5041263 

There's not really anything helpful I can see of use. PRU_ICSSG0 is enabled in Linux, but that does not matter for your usecase since you are using PRU_ICSSG1 for the networking.

One of our team members mentioned that it is possible that the current PHY speed setting is 10MB half-duplex (HD) because the link negotiation failed at higher link speeds, NOT because that was specifically negotiated.

We are discussing other potential issues - e.g., perhaps something is different during PHY initialization between the SBL usecase and the Linux SPL usecase.

Regards,

Nick

Hi Nick,

              Thank you for the reply.

    We have posted the complete log from Linux side on FEB15 on this thread.

     If any further log required, please tell us.

     This Log is taken after implementing the suggestions from TI forum.

     We are able to start the Ethernet-IP Application, but it is not able to communicate with the external world.

     From the logs we see that the remoteproc fro pru are not running.

    so, We requested to tell us if we are missing anything. We are waiting for the reply.

Thank You.

Hi Nick,

Thank you for the reply.

   For your easy reference I am reposting the logs that was post on 15th Feb.

  Let me provide step by step information as of now.
        1. Resource allocation between A53 (Linux) and R5F done 
  2. DTS file changes done and reviewed by TI. 
  3. Based on all the information provide by TI SD Card was prepared
        4. Outcome of the above activity - Able to Remoteproc R5F cores and IPC is working
        5. EthernetIP Example was not working and on detailed debugging found that PRU not running.

 In short we are looking for solution for enabling boot from SD card, remoteproc R5F, IPC and EthernetIP working. Last part PRU enabling.
Looking forward of quick solution for the above.

Logs captured from Linux. 

Below are the logs we are getting 

1) Remoteproc available

root@am64xx-evm:~# head /sys/class/remoteproc/remoteproc*/name
==> /sys/class/remoteproc/remoteproc0/name <==
5000000.m4fss

==> /sys/class/remoteproc/remoteproc1/name <==
78000000.r5f

==> /sys/class/remoteproc/remoteproc2/name <==
78400000.r5f

==> /sys/class/remoteproc/remoteproc3/name <==
3000a000.txpru

==> /sys/class/remoteproc/remoteproc4/name <==
3000c000.txpru

==> /sys/class/remoteproc/remoteproc5/name <==
30034000.pru

==> /sys/class/remoteproc/remoteproc6/name <==
30004000.rtu

==> /sys/class/remoteproc/remoteproc7/name <==
30038000.pru

==> /sys/class/remoteproc/remoteproc8/name <==
30006000.rtu

2)Running Status of Remoteproc

root@am64xx-evm:~# cat /sys/class/remoteproc/remoteproc1/state
running
root@am64xx-evm:~# cat /sys/class/remoteproc/remoteproc2/state
running
root@am64xx-evm:~# cat /sys/class/remoteproc/remoteproc3/state
offline
root@am64xx-evm:~# cat /sys/class/remoteproc/remoteproc4/state
offline
root@am64xx-evm:~# cat /sys/class/remoteproc/remoteproc5/state
offline
root@am64xx-evm:~# cat /sys/class/remoteproc/remoteproc6/state
offline
root@am64xx-evm:~# cat /sys/class/remoteproc/remoteproc7/state
offline
root@am64xx-evm:~# cat /sys/class/remoteproc/remoteproc8/state
offline

3) PRU Firmware shown 

root@am64xx-evm:~# ls -l /lib/firmware/
total 17044
-rw-r--r-- 1 root root 2040 Mar 9 2018 LICENCE.ibt_firmware
-rw-r--r-- 1 root root 2046 Mar 9 2018 LICENCE.iwlwifi_firmware
lrwxrwxrwx 1 root root 55 Mar 9 2018 am64-main-r5f0_0-fw -> /lib/firmware/mcusdk-benchmark_demo/am64-main-r5f0_0-fw
lrwxrwxrwx 1 root root 55 Mar 9 2018 am64-main-r5f0_1-fw -> /lib/firmware/mcusdk-benchmark_demo/am64-main-r5f0_1-fw
lrwxrwxrwx 1 root root 55 Mar 9 2018 am64-main-r5f1_0-fw -> /lib/firmware/mcusdk-benchmark_demo/am64-main-r5f1_0-fw
lrwxrwxrwx 1 root root 55 Mar 9 2018 am64-main-r5f1_1-fw -> /lib/firmware/mcusdk-benchmark_demo/am64-main-r5f1_1-fw
lrwxrwxrwx 1 root root 68 Mar 9 2018 am64-mcu-m4f0_0-fw -> /lib/firmware/ti-ipc/am64xx/ipc_echo_test_mcu3_0_release_strip.xer5f
lrwxrwxrwx 1 root root 49 Mar 9 2018 am64x-pru0_0-fw -> /lib/firmware/pru/PRU_RPMsg_Echo_Interrupt0_0.out
lrwxrwxrwx 1 root root 49 Mar 9 2018 am64x-pru0_1-fw -> /lib/firmware/pru/PRU_RPMsg_Echo_Interrupt0_1.out
lrwxrwxrwx 1 root root 49 Mar 9 2018 am64x-pru1_0-fw -> /lib/firmware/pru/PRU_RPMsg_Echo_Interrupt1_0.out
lrwxrwxrwx 1 root root 49 Mar 9 2018 am64x-pru1_1-fw -> /lib/firmware/pru/PRU_RPMsg_Echo_Interrupt1_1.out
lrwxrwxrwx 1 root root 49 Mar 9 2018 am64x-rtu0_0-fw -> /lib/firmware/pru/RTU_RPMsg_Echo_Interrupt0_0.out
lrwxrwxrwx 1 root root 49 Mar 9 2018 am64x-rtu0_1-fw -> /lib/firmware/pru/RTU_RPMsg_Echo_Interrupt0_1.out
lrwxrwxrwx 1 root root 49 Mar 9 2018 am64x-rtu1_0-fw -> /lib/firmware/pru/RTU_RPMsg_Echo_Interrupt1_0.out
lrwxrwxrwx 1 root root 49 Mar 9 2018 am64x-rtu1_1-fw -> /lib/firmware/pru/RTU_RPMsg_Echo_Interrupt1_1.out
lrwxrwxrwx 1 root root 35 Mar 9 2018 am64x-txpru0_0-fw -> /lib/firmware/pru/TX_PRU_Halt_0.out
lrwxrwxrwx 1 root root 35 Mar 9 2018 am64x-txpru0_1-fw -> /lib/firmware/pru/TX_PRU_Halt_1.out
lrwxrwxrwx 1 root root 35 Mar 9 2018 am64x-txpru1_0-fw -> /lib/firmware/pru/TX_PRU_Halt_0.out
lrwxrwxrwx 1 root root 35 Mar 9 2018 am64x-txpru1_1-fw -> /lib/firmware/pru/TX_PRU_Halt_1.out

4)DTS file details

&icssg1 {
status = "disabled"; 
};

above is suggested by you.

icssg1_eth: icssg1-eth {

compatible = "ti,am642-icssg-prueth";
pinctrl-names = "default";
//pinctrl-0 = <&icssg1_rgmii1_pins_default>; commented by us

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>;

ti,mii-g-rt = <&icssg1_mii_g_rt>;
ti,mii-rt = <&icssg1_mii_rt>;
ti,pa-stats = <&icssg1_pa_stats>;
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";

ethernet-ports {
#address-cells = <1>;
#size-cells = <0>;
icssg1_emac0: port@0 {
reg = <0>;
//phy-handle = <&icssg1_phy1>; //commented by us
phy-mode = "rgmii-id";
ti,syscon-rgmii-delay = <&main_conf 0x4110>;
/* Filled in by bootloader */
local-mac-address = [00 00 00 00 00 00];

status = "disabled"; //added by us

};
icssg1_emac1: port@1 {
reg = <1>;
ti,syscon-rgmii-delay = <&main_conf 0x4114>;
/* Filled in by bootloader */
local-mac-address = [00 00 00 00 00 00];
status = "disabled"; //added by us
};
};
};

};

5) Below is the trace log we are getting from R5F0_0 CORE running ethernet -ip adapter application.

root@am64xx-evm:~# cat /sys/kernel/debug/remoteproc/remoteproc1/trace0
[r5f0-0]     0.002609s : Pruicss  max =3 selected PRU:3
[r5f0-0]     0.002656s : 
[r5f0-0]     0.003198s : The data is corrupted, write default values.
[r5f0-0]     0.003235s : 
[r5f0-0]     0.003385s : Did Map 0x30080000 len 0x2000 to 0x30080000 (dram0)
[r5f0-0]     0.003422s : 
[r5f0-0]     0.003454s : Did Map 0x30082000 len 0x2000 to 0x30082000 (dram1)
[r5f0-0]     0.003482s : 
[r5f0-0]     0.003508s : Did Map 0x300b4000 len 0x4000 to 0x300b4000 (iram0)
[r5f0-0]     0.003537s : 
[r5f0-0]     0.003563s : Did Map 0x300b8000 len 0x4000 to 0x300b8000 (iram1)
[r5f0-0]     0.003591s : 
[r5f0-0]     0.003614s : Did Map 0x30090000 len 0x10000 to 0x30090000 (shdram)
[r5f0-0]     0.003643s : 
[r5f0-0]     0.003668s : Did Map 0x300a2000 len 0x400 to 0x300a2000 (control0)
[r5f0-0]     0.003696s : 
[r5f0-0]     0.003719s : Did Map 0x300a4000 len 0x400 to 0x300a4000 (control1)
[r5f0-0]     0.003747s : 
[r5f0-0]     0.003772s : Did Map 0x300a0000 len 0x2000 to 0x300a0000 (intc)
[r5f0-0]     0.003799s : 
[r5f0-0]     0.003823s : Did Map 0x300a6000 len 0x2000 to 0x300a6000 (cfg)
[r5f0-0]     0.003849s : 
[r5f0-0]     0.003872s : Did Map 0x300a8000 len 0x2000 to 0x300a8000 (uart0)
[r5f0-0]     0.003900s : 
[r5f0-0]     0.003923s : Did Map 0x300ae000 len 0x2000 to 0x300ae000 (iep)
[r5f0-0]     0.003950s : 
[r5f0-0]     0.003973s : Did Map 0x300b0000 len 0x2000 to 0x300b0000 (ecap0)
[r5f0-0]     0.004005s : 
[r5f0-0]     0.004034s : Did Map 0x300b2000 len 0x400 to 0x300b2000 (mii_rt)
[r5f0-0]     0.004062s : 
[r5f0-0]     0.004085s : Did Map 0x300b2000 len 0x1c00 to 0x300b2000 (mdio)
[r5f0-0]     0.004112s : 
[r5f0-0]     0.004136s : Did Map 0x3008a000 len 0x2000 to 0x3008a000 (txPru0Iram)
[r5f0-0]     0.004165s : 
[r5f0-0]     0.004190s : Did Map 0x3008c000 len 0x2000 to 0x3008c000 (txPru1Iram)
[r5f0-0]     0.004218s : 
[r5f0-0]     0.004242s : Did Map 0x300a5000 len 0x100 to 0x300a5000 (txPru0CtlReg)
[r5f0-0]     0.004271s : 
[r5f0-0]     0.004296s : Did Map 0x300a5000 len 0x100 to 0x300a5000 (txPru1CtlReg)
[r5f0-0]     0.004325s : 
[r5f0-0]     0.009044s : DP83822 detected
[r5f0-0]     0.009067s : 
[r5f0-0]     0.009146s : DP83822 detected
[r5f0-0]     0.009162s : 
[r5f0-0]    20.316850s : Local interface IP is 192.168.1.10
[r5f0-0]    20.316894s : 
[r5f0-0]    20.317481s : CUST_PHY_SPEED_DUPLEX_eCONFIG_10HD
[r5f0-0]    20.317518s : 
[r5f0-0]    20.318422s : EI_API_ADP_getMacAddr:  34:08:e1:84:ab:0f

Hi TI Team,

  Can this be resolved ,as this is not getting resolved for more than a month.

  Customer is very unhappy about the progress, appreciate if this can be accelerated to closure.

  Just for your quick reference booting from SD card, Linux is unable to Remote proc to bring PRU to run state this is based on our investigation. 

 the CIP is in run state, however due to PRU not in run state we are unable to communicate with Ethernet-ip.

   Expecting quicker reply.

Thank You

Hi Narasimha Rao ,

Narasimha Rao said:

[r5f0-0]    20.317481s : CUST_PHY_SPEED_DUPLEX_eCONFIG_10HD

Can you please check why PHY is negotiated in 10M Half Duplex ? which is currently not supported in EIP.

software-dl.ti.com/.../eip_datasheet.html

Best Regards

Ashwani

Hello Narasimha,

QUESTION

when you say this:

"Our issue is The Ethernet-IP Adaptor application is not working on R5F0_0 after remote boot from Linux using remoteproc... Whereas Same Ethernet-IP Adaptor application is working when we load through JTAG with board in NO-Boot mode."

Are you using the EXACT SAME R5F project when booting from Linux as when booting from JTAG? Or are you doing something else, like booting the modified R5F project from Linux, but booting an UNMODIFIED project from JTAG?

The reason I ask 

I see different peripherals enabled in the SysConfig project you attached here than in the default project. If your modified project successfully loads and runs over JTAG (but not Linux), that tells us something different than if it does not load and run over JTAG or over Linux.

Regards,

Nick

Hi,

   Below is the state of remoteproc we observed and posted earlier.

root@am64xx-evm:~# cat /sys/class/remoteproc/remoteproc1/state
running
root@am64xx-evm:~# cat /sys/class/remoteproc/remoteproc2/state
running
root@am64xx-evm:~# cat /sys/class/remoteproc/remoteproc3/state
offline
root@am64xx-evm:~# cat /sys/class/remoteproc/remoteproc4/state
offline
root@am64xx-evm:~# cat /sys/class/remoteproc/remoteproc5/state
offline
root@am64xx-evm:~# cat /sys/class/remoteproc/remoteproc6/state
offline
root@am64xx-evm:~# cat /sys/class/remoteproc/remoteproc7/state
offline
root@am64xx-evm:~# cat /sys/class/remoteproc/remoteproc8/state
offline

  May we know when we can get the solution for running the PRU core from Linux, for the ethernet-ip Application to work.

Thank You.

Hi Nick,

   Please find attached the sysconfig file which we are using when booting from linux.

   In which all pheripherals are removed except what is required.

3348.Ethernetip_Adapter.zip

We clearly see that the PRU remoteproc are not in run state.

 Please tell us how to make the pru remoteproc run in linux .

Thank You.

Hi,

    Customer is waiting for the release with this solution.

   Kindly address this on priority .Lookng forward for your support to resolve this challenge.

 Thank You.

Hello Narasimha,

You never answered my question in this post. Please answer it:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1314557/am6421-ethernet-ip-adapter-program-execution-failing-through-remote-proc-mechanism-through-linux/5058710#5058710

If there is a difference between your "working" and "not working" code, that tells us something totally different than if you are using the exact same R5F code in both the "working" and "not working" situations.

Regards,

Nick

Linux remoteproc can only see the PRU_ICSSG instance that you enabled in the Linux devicetree (i.e., ICSSG0, NOT ICSSG1). You can verify by checking the addresses of the PRU cores:

head /sys/class/remoteproc/remoteproc*/name

So those PRU cores reported by Linux remoteproc have nothing to do with your usecase.

Regards,

Nick

Hello Nick,

It's a pleasure to reconnect with you. I will endeavor to progress this matter further.

Are you using the EXACT SAME R5F project when booting from Linux as when booting from JTAG? Or are you doing something else, like booting the modified R5F project from Linux, but booting an UNMODIFIED project from JTAG?
We are using exact same project when booting for Jtag and Linux.

Furthermore, would you kindly update me on any additional progress regarding the execution of the industrial example from Linux? My recollection from our previous discussion is that you were also considering exploring this aspect.

Thanks for your support.

Hi Nick,

     Can you please update.

 Thank You.

Hi Nick,

We are able to run and test Ethernet/IP  code through remote proc mechanism through Linux. Also able to ping device. We had same code base but we are changing linker script as well as MPU ARMv7 for below mention part

Jtag

/* shared memories that is used between ICCS and this core. MARK as non-cache or cache+sharable */
ICSS_PKT_BUF_MEM : ORIGIN = 0x70000000, LENGTH = 0x00010000

Linux

/* shared memories that is used between ICCS and this core. MARK as non-cache or cache+sharable */
ICSS_PKT_BUF_MEM : ORIGIN = 0xA3100000, LENGTH = 0x00010000

The reason behind this is that when we run the code through JTAG, we can use the MSRAM section. However, when running the code through Linux, we need to use the DDR section. Therefore, we opted to utilize the main_rfss1_core_1_memory region (0xA3100000) for ICSS_PKT_BUF_MEM. Additionally, it's important to note that we are using the AM6421 variant, so this section remains unused.

However, surprisingly, when we use the DDR memory section for ICSS_PKT_BUF_MEM in the Ethernet/IP code, it does not function properly. Conversely, when we employ the MSRAM section for ICSS_PKT_BUF_MEM, it works seamlessly with Linux. We have initiated the transition of data to DDR due to a bug in Linux that prevents the initialization of MSRAM. Let me know your thoughts.

Thank you, TI team, for your invaluable support.

Hello Nikhil,

Behind-the-scenes information

I am grabbing your thread back, since this looks like more of a multicore challenge now than a PHY related challenge. Thank you for your patience as we've been passing you back and forth between team members.

We are still working on getting a different Linux + R5F & PRUETH example running on the AM64x EVM! For now a couple of my team members have taken over direct development of that project, and I'm acting more in an advisory role. Once we get everything working on that example, I will be working with them to document and publish that example.

Ok, let's talk about your design! 

Thank you for the status update. That is useful information.

Let's see what we can do about getting SRAM working for you. SRAM has lower latency accesses than DDR, and I assume the software was designed to use SRAM instead of DDR for performance reasons (if not to prevent code breakages).

It does look like the default Ethernet IP example places data into SRAM:
https://dev.ti.com/tirex/explore/node?node=A__AK.T7eITyrVEaV55E9J4Ng__INDUSTRIAL-COMMUNICATIONS-SDK-AM64X__wljCT77__LATEST

When I look at the version of your devicetree file from two weeks ago, it looks like the sram allocation for main_r5fss0_core0 had been commented out.
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1314557/am6421-ethernet-ip-adapter-program-execution-failing-through-remote-proc-mechanism-through-linux/5035822#5035822 

Assuming that your SRAM allocation is still commented out in Linux, the next step is to go ahead and decide where you want to put your code in MSRAM. Remember that we still need to work around the other allocations in Linux:

k3-am64-main.dtsi

&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>;

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

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

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

If you want to double-check exactly how much SRAM your R5F application is ACTUALLY using, reference
AM64x academy, multicore module, page "How to allocate memory", section "Optimizing Memory Usage"
https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__AbwqjEswy38Z6lZWYQC-5g__AM64-ACADEMY__WI1KRXP__LATEST

Since you are using SPL boot, I suspect that you do not actually need to reserve the first 0x7FFFF of SRAM like the comment in this linker file says:
https://dev.ti.com/tirex/explore/node?node=A__AK.T7eITyrVEaV55E9J4Ng__INDUSTRIAL-COMMUNICATIONS-SDK-AM64X__wljCT77__LATEST

    // MSRAM     : ORIGIN = 0x70020000 , LENGTH = 0x001b0000
    MSRAM     : ORIGIN = 0x70080000 , LENGTH = 0x00150000 /* OSPI Bootloader uses till 0x7007FFFF */

So I would probably

1) check the map file to see if the Ethernet IP example really needs a full 1.5MB of SRAM (i.e., LENGTH = 0x00150000) - if not, you could reduce the memory allocation.

2) move the MSRAM in the linker.cmd file to be between ICSS_PKT_BUF_MEM and offset 0x001C0000 (where all the existing Linux SRAM allocations begin)

3) update the Linux devicetree file to allocate the address range used for ICSS_PKT_BUF_MEM and MSRAM to the R5F core in the sram entry

Regards,

Nick

Hi Nick,

Thanks for giving workaround for getting SRAM working. But Moving data from MSRAM to DDR exercise started because there is bug in Remoteproc driver for initializing data in MSRAM.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1289532/am6442-problems-loading-demo-project-into-r5f-from-linux/4895067?tisearch=e2e-sitesearch&keymatch=remoteproc%252520remoteproc1%25253A%252520bad%252520phdr%252520da%2525200x70080000%252520mem%2525200xf180#4895067

Now we are good on Ethernet/ip part as it is working through Linux Remoteproc driver. We will be waiting for your sample industrial example code which can be loaded by Remoteproc driver. (In case if we missed something from our end) and Also hoping that MRAM bug will be resolved in next SDK release that is 9.2

Aprart from that A shared memory region between CPU and PRU-ICSS allocated for queues follows static allocation in PRU-ICSS firmware !!!

uint8_t gIcssEmacPktBufMem1[ICSS_EMAC_PKT_BUF_1_MEM_SIZE] __attribute__((aligned(128), section(".bss. icss_emac_pktbuf_mem")));

Regards,

Nikhil Jarande

Hello Nikhil,

I misspoke in that e2e thread you linked earlier: Linux loading M4F with SRAM did not work (but will start working in the upcoming AM64x SDK 9.2 release, probably late March or April). However, Linux loading R5F with SRAM should work fine:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1289532/am6442-problems-loading-demo-project-into-r5f-from-linux/4944245#4944245

The patches that fix the M4F SRAM issue are here if you want to grab them early:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1326236/am625-problem-when-remote-core-uses-oc_sram/5048813#5048813

and the AM64x test code I provided to the developer to validate is here:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1326236/am625-problem-when-remote-core-uses-oc_sram/5051160#5051160 

Regards,

Nick

Hi Nick,

I have downloaded test code. But I don't see source code. Can you attach here.

Regards,

Nikhil

Hello Nikhil,

Here's the patch for the AM64x MCU+ SDK 9.1 that I used to generate the above binaries:

0001-AM64x-IPC-Echo-data-instructions-to-SRAM.patch

Regards,

Nick

Hi Nick ,

Thank you for the patch. The real-time core's booting process via SD card is meeting our expectations. We have decided not to transfer data from DDR to SRAM for now. Consequently, we will be closing this issue. 

Its been nice to working with you.

Regards,

Nikhil Jarande

Hi ,

We are able to resolve sd card issue .

Thanks for all your support.