• State Resolved
  • Locked Locked
  • Replies 78 replies
  • Answers 1 answer
  • Subscribers 104 subscribers
  • Views 2744 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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

Sonu Kumar
Prodigy 140 points
Part Number: AM6421
Other Parts Discussed in Thread: SYSCONFIG,

Dear All,

We are working on EtherNet/IP adapter program. We need to execute EtherNet/IP adapter program from sd card through linux remoteproc mechanism.

Also to be cautious on resource management, We removed uart,ospi,i2c & eeprom from sysconfig to avoid conflict between A53 and R5F conflict. We tested through JTAG.Its working.We are able to see EtherNet/IP logs . We were expecting same behaviour when we boot from Linux but code executing and its getting stuck on below part.

root@am64xx-evm:~# cat /sys/kernel/debug/remoteproc/remoteproc1/trace0
[unknown]     0.000000s : Before CMN_OS_init
[unknown]     0.000000s : Before System_init

Note – We did workaround mention in e2e forum 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

I'd appreciate any help.

 

Sincerely,

Sonu Kumar

  • 0 in reply to Nick Saulnier
    Prodigy 140 points

    Hi Nick,

    Thanks for the response.

    We went through the thread you mentioned We already taken care of IPC & Linker_Script File.

    Only the added action we have done is following.linker_comand_file.docx

    we’ve done resource management by removing peripheral already utilised by R5F in the dts PRU0 & PRU1 from dts file.

    We are able to execute but Still we are getting same output.

         root@am64xx-evm:~# cat /sys/kernel/debug/remoteproc/remoteproc1/trace0
         [unknown]     0.000000s : Before CMN_OS_init
         [unknown]     0.000000s : Before System_init

    Please have a look at our attached  linker_comand file .

    Any help will be highly appreciated.

     

    Sincerely,

    Sonu kumar

  • 0 in reply to Sonu Kumar
    Prodigy 140 points

    Please have a look at our linker_command file and dts file.8357.linker_comand_file.docx

    dts_file.docx

  • 0 in reply to Sonu Kumar
    TI__Guru* 94480 points

    Hello Sonu,

    I am running out of time today, so I will not be able to review your files until next week. In the meantime, could you please add additional debug print statements in your R5F firmware and isolate exactly where your program is halting? 

    Reference AM64x academy, multicore module, Application Development on Remote Cores > How to debug a remote core while Linux is running
    https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__AeMVTHckwFDmFoNkRHpRPw__AM64-ACADEMY__WI1KRXP__LATEST

    For example, if the R5F is requesting a specific peripheral from SYSFW and then never returning, that would tell you that you probably have a resource conflict around that specific peripheral.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 140 points

    Hi Nick,

    We cannot put Debug Print statements in driver_file.

    We are going through the link you provided.

    Also we tried Industrial SDK 9.1 to bring up EtherNet IP adapter demo program  but it is failing when we add IPC in sysconfig.

    Awaiting your response on linker_command & dts file.

    Sincerely,

    Sonu kumar

  • 0 in reply to Ashwani Goel
    TI__Guru* 94480 points

    Ok, so after reviewing the Linux devicetree changes:

    I don't see any obvious issues.

    icssgX_eth and all the subnodes can just be removed instead of setting status = "disabled"
    note that this node is being defined for the first time in the board-level file, instead of using an ampersand (&) to reference a devicetree node that was defined earlier.

    Both R5F subsystems seem to be set to single core mode properly. To make it cleaner, I would just delete the references &main_r5fss0_core1 and &main_r5fss1_core1 from the board level file (they'll still be defined and "enabled" in the lower level .dtsi file where they are initially defined, which is what we want).

    The linker.cmd file changes 

    I am only going to check the resource table part of your linker.cmd file. DDR_0 location and size look fine. FYI, if using something OTHER than MCU+ SDK 9.0, you should be able to set DDR_0 to 4kB, like you see in SDK 8.6: 
    DDR_0 : ORIGIN = 0xA0100000 , LENGTH = 0x1000

    I will let Ashwani comment on modifying the EtherNet program in your other e2e thread here:
    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1315585/am6421-ethernet-ip-adapter-program-from-industrial-sdk-9-1-not-compiling-when-ipc-is-added-in-sysconfig/5004271#5004271 

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 140 points

    Hi Nick,

    We are still having challenges to remote boot EtherNet IP adapter program on R5F from linux A53 .

    We are using Industrial communication SDK 9.00.00.03.

    Any help would be greatly appreciated.

    Best regards,

    Sonu

  • 0 in reply to Sonu Kumar
    Prodigy 140 points

    Hi Nick,

    It seems to be board configuration issue , where R5F need to access the ICSSG DMA. Can you  provide us readily available 'tiboot3.bin' which works with Ethernet/IP code.

    It will be very much helpful.

    Regards,

    Sonu

  • 0 in reply to Sonu Kumar
    TI__Guru* 94480 points

    Hello Sonu,

    I can try to get an example running on my side, but it might take me a couple of days. Can you please clarify exactly which SDK versions (Linux, MCU+, Industrial comms) you are looking at?

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 140 points

    Hi Nick,

    Industrial communication SDK 9.00.00.03

    Processor SDK LINUX -RT-AM64x  version 9.00.00.03

    MCU plus SDK 9.00.00.35

    Additionally there is pre-planned Demo by our customer by end of this month.

    Would appreciate if solution can be arrived at earlier.  

    Regards,

    Sonu

  • 0 in reply to Sonu Kumar
    TI__Guru* 94480 points

    Hello Sonu,

    Thanks for confirming. I will start running experiments tomorrow. If I don't have things fully working by the end of the day, I'll at least provide a partial update.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Guru* 94480 points

    Hello Sonu,

    Partial update: I have started creating a new FAQ page as I work through this process:
    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1318459/faq-am6442-how-to-get-r5f-pru-ethernet-working-alongside-linux-a53

    As I make my code changes, I will upload them there as git patches so you can see exactly what I am doing. At the moment, I am partway through modifying the peripheral and memory allocation. The next step will be to look into the board configuration.

    If you need to try to make more progress now before I am able to catch up to you, please refer to these links: 

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1313771/am6442-industrial-communication-sdk-application-and-linux-a53-using-remote-proc-checklist/4995372#4995372 < this has updated information about how the resource settings are applied in uboot

    This specific reply is the last time I looked deeply into the board config settings:
    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1206420/processor-sdk-am64x-enet-open-failure-from-r5-when-a53-is-running/4596608#4596608

    and this thread also might be helpful:
    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1290012/am6442-running-enet_icssg_layer2-example-on-r5f-in-combination-with-linux

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 140 points

    Hi Nick,

    We went through the link you shared above, was not helpful.

    Hope the patch you are working on is progressing well.

    Please keep us informed as we are under pressure to respond to our customer.

    Regards

    Sonu

  • 0 in reply to Sonu Kumar
    TI__Guru* 94480 points

    Hello Sonu,

    Peripheral allocation

    Most of the peripheral allocation is done. I'm double-checking with the hardware designers about the best way to allocate I2C1 between Linux and R5F (not sure if Linux can use the SD card while R5F uses the EMMC if both mmc interfaces are controlled through I2C1, but I'm verifying), and with the networking team about what I2C0, I2C1, and EMMC are used for from the MCU+ side.

    Resource allocation 

    Here are the tools you want to use:
    K3 Resource Partition tool: use the version in Linux SDK 9.0, board-support/k3-respart-tool
    SysConfig: use version 1.15 (this is NOT the latest version - I couldn't get v1.17, 1.18, or 1.19 working with the AM64x config from that SDK)

    These are the steps you want to follow to update the resource allocation:
    Read SPECIFICALLY my reply that was updated 4.19.2023:
    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1206420/processor-sdk-am64x-enet-open-failure-from-r5-when-a53-is-running/4596608#4596608

    Once you update the resource allocation, information about how to take the output file and put it into uboot is here:
    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1308689/faq-how-to-use-resource-partitioning-tool-with-processor-sdk-v9-1

    More info about building uboot is here:
    https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/09_01_00_08/exports/docs/linux/Foundational_Components/U-Boot/UG-General-Info.html

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 410 points

    I'm part of Sonu team. We appreciate your thorough explanation and attention to every aspect in a single thread. Could you please share your tiboot3.bin with us? This would greatly accelerate the process on my end, and it would also provide assurance that we are using a working tiboot3.bin. Thank you for your cooperation; we are currently on a tight schedule

  • 0 in reply to Nikhil Jarande
    Intellectual 410 points

    Will the tiboot3.bin provided by you be compatible with Am6421? Simultaneously We are trying to do resource allocation with Am6421 with 9.00.00.03 Linux RT SDK and sysconfig 1.15.

    These are the steps you want to follow to update the resource allocation:
    Read SPECIFICALLY my reply that was updated 4.19.2023:
    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1206420/processor-sdk-am64x-enet-open-failure-from-r5-when-a53-is-running/4596608#4596608

    • As we are working with Am6421. we have kept resources MAIN_0_R5_1 R5F

    MAIN_0_R5_1 R5F means subsystem 0 core 0 – Present
    MAIN_0_R5_3 R5F means subsystem 0 core 1 – Not Present in Am6421
    MAIN_1_R5_1 R5F means subsystem 1 core 0 - Present
    MAIN_1_R5_3 R5F means subsystem 1 core 1 – Not Present in Am6421

    • We can see files  rm-cfg.c , not rm-cfg.yaml file.
    • We have followed steps as you mentioned link up to step 4. As per my understanding, we need to only update tiboot3.bin. We don’t need to touch MCU + SDK part. So we have skip step 5 and 6. Now we need to move to Link 2.

    Once you update the resource allocation, information about how to take the output file and put it into uboot is here:
    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1308689/faq-how-to-use-resource-partitioning-tool-with-processor-sdk-v9-1

    We stuck at this step because we have rm-cfg.c file not rm-cfg.yaml file

  • 0 in reply to Nikhil Jarande
    Intellectual 410 points

    I apologize for the inconvenience caused by multiple comments. We are currently under significant pressure due to delivery commitments. Could you kindly inform us of the expected date when the complete tested solution will be available? Your support is greatly appreciated. Thank you.

  • 0 in reply to Nikhil Jarande
    TI__Guru* 94480 points

    Hello Nikhil,

    Where you can help me

    Are yall using the AM64x EVM, or are you using a custom board? If you are using the AM64x EVM, have you noticed a drop in SD card throughput after commenting out the GPIO?

    Fullscreen
    1
    2
    3
    4
    5
    vdd_mmc1: fixed-regulator-sd {
    /* TPS2051BD */
    ...
    //gpio = <&exp1 6 GPIO_ACTIVE_HIGH>; //commented by user
    };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Can I get yall to give me the output of 
    dmesg | grep mmc

    The reason I ask about the SD card performance is that if Linux needs I2C1 for normal SD card function, I will probably leave that peripheral with Linux in my demo, and assume that neither core gets to use the Ethernet port that is controlled by the MDIO mux (which is controlled through the I2C1 GPIO expander). But if the SD card still runs at an acceptable rate, perhaps I can give I2C1 to the R5F, and that might make the design easier.

    Setting expectations for a full example from my side

    I am still working through the design constraints of the AM64x, so I probably will not have a fully working example until sometime next week. But I will try to enable you to move faster than that.

    Board config settings 

    I apologize for how complicated this process is. I am taking a closer look now to see what we can do to get that yaml file output for you.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Guru* 94480 points

    Hello Nikhil,

    At this point in time, I don't see a way to generate the yaml file

    I'm sorry, at this point I cannot get the tool to generate a yaml file output for you. That means we are going to have to manually modify the .yaml file. I am following up with my team to figure out what went wrong with the tooling, and to get it fixed ASAP.

    We can still make your yaml file changes! But it will take some manual work.

    Please make all your changes to the allocations in the K3 Resource Configuration tool, as documented in my reply on 4/19/2023. Generate the rm-cfg.c file.

    You should also generate an unmodified rm-cfg.c file (using the default configuration settings).

    Step 1: notice the structure of rm-cfg.c and rm-cfg.yaml are the same  

    Both documents are formatted the exact same:

    Fullscreen
    1
    2
    3
    4
    5
    6
    rm-cfg:
    rm_boardcfg:
    reg:
    host_cfg:
    resarg:
    resarg_entries:
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    The main difference is that rm-cfg.c uses human-readable variable names, while rm-cfg.yaml uses the unique type IDs.

    We can double-check that with the host_cfg entries. We can check the TISCI documentation to confirm that they all match:
    https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am64x/hosts.html

    entry #1 is HOST_ID_A53_2 for rm-cfg.c and 12 for rm-cfg.yaml
    entry #3 is HOST_ID_MAIN_0_R5_1 for rm-cfg.c and 36 for rm-cfg.yaml
    etc

    So every place where rm-cfg.c got updated, we know we need to edit that exact location for rm-cfg.yaml as well.

    Step 2: for every line that got updated in rm-cfg.c, also update rm-cfg.yaml

    Start by opening the two rm-cfg.c files in a diff program of your choice (Meld, beyondCompare, etc).

    Let's say we are looking at this section:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    /* Packet DMA ICSSG1 Rx channel */
    ...
    {
    .start_resource = 25,
    .num_resource = 4,
    .type = RESASG_UTYPE (AM64X_DEV_DMASS0_PKTDMA_0,
    RESASG_SUBTYPE_PKTDMA_ICSSG_1_RX_CHAN),
    .host_id = HOST_ID_MAIN_0_R5_1,
    },
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    The diff program tells me that .host_id was updated from HOST_ID_ALL (128) to HOST_ID_MAIN_0_R5_1 (36). So let's find that section in the .yaml file.

    We need to look up the Unique Type ID of the subtype here:
    https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am64x/resasg_types.html

    the subtype is the second entry in ".type = RESARG_UTYPE()".

    So for this example, search for RESASG_SUBTYPE_PKTDMA_ICSSG_1_RX_CHAN in the URL above:

    The type ID = 0x07B7 = 1975

    Ok, now I can search for "1975" in the rm-cfg.yaml file:

    Fullscreen
    1
    2
    3
    4
    5
    6
    -
    start_resource: 25
    num_resource: 4
    type: 1975
    host_id: 12
    reserved: 0
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    So now we just need to update host_id: to be 36.

    Once you are done, build the uboot and see if your system works now 

    If you are running into issues with the rm-cfg.yaml file, feel free to attach your generated rm-cfg.c file and your modified rm-cfg.yaml file, and I can double-check your work.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 410 points

    Thank you, Nick, for providing the steps to generate the YAML file. We are currently working with the AM6421 custom board.

    As we are using AM6421 SOC, we have allocated resources for MAIN_0_R5_1 R5F

    MAIN_0_R5_1 R5F means subsystem 0 core 0 – Present
    MAIN_0_R5_3 R5F means subsystem 0 core 1 – Not Present in Am6421
    MAIN_1_R5_1 R5F means subsystem 1 core 0 - Present
    MAIN_1_R5_3 R5F means subsystem 1 core 1 – Not Present in Am6421

    I have successfully created the YAML file and built the tiboot3.bin. Unfortunately, there is no success. Following are logs.

    root@am64xx-evm:~# cat /sys/kernel/debug/remoteproc/remoteproc1/trace0
    [unknown]     0.000000s : Before CMN_OS_init
    [unknown]     0.000000s : Before System_init

     For your review, I have added the files rm-cfg.c and rm-cfg.yaml (Added in txt format as not able to upload in yaml format

    rm-cfg_yaml.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    # SPDX-License-Identifier: GPL-2.0+
    # Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
    #
    # Resource management configuration for AM64x
    #
    ---
    rm-cfg:
    rm_boardcfg:
    rev:
    boardcfg_abi_maj : 0x0
    boardcfg_abi_min : 0x1
    host_cfg:
    subhdr:
    magic: 0x4C41
    size : 356
    host_cfg_entries:
    - #1
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    ). Additionally, I have prepared a Diff document to expedite the review process.

    RM_Engineering_Notes.pdf

    4403.rm-cfg.c
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    /*
    * K3 System Firmware Resource Management Configuration Data
    * Auto generated from K3 Resource Partitioning tool
    *
    * Copyright (C) 2019-2021 Texas Instruments Incorporated - https://www.ti.com/
    *
    * Redistribution and use in source and binary forms, with or without
    * modification, are permitted provided that the following conditions
    * are met:
    *
    * Redistributions of source code must retain the above copyright
    * notice, this list of conditions and the following disclaimer.
    *
    * Redistributions in binary form must reproduce the above copyright
    * notice, this list of conditions and the following disclaimer in the
    * documentation and/or other materials provided with the
    * distribution.
    *
    * Neither the name of Texas Instruments Incorporated nor the names of
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Nikhil Jarande
    TI__Guru* 94480 points

    Hello Nikhil,

    I have some good news and bad news. Bad news, I did not have time today to review your file updates.

    Good news, I managed to get K3 Resource Partition tool to generate a .yaml file output for you!

    First step: please make the board config changes again, and this time the tool will generate the .yaml file for you

    You need to use the updated version of the K3 Resource Partition tool I attached here, as well as SysConfig v1.18 or v1.19:
    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

    Next step: if the system still doesn't work, please provide your modified am64x-evm.sysconfig so that I can review your changes on my side in the K3 Resource Partition tool 

    The other "next step": step through your code until you find the exact place where the code is halting 

    I'll include more information about this in the next post.

    Just so you know, I will be on vacation Saturday - Monday, and back in the office on Tuesday.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Guru* 94480 points

    How to debug exactly where in the MCU+ code the system is freezing 

    You will need to use Code composer studio to step through your code one line at a time until you get to the spot where the code is breaking.

    First, create an infinite while loop 

    That way, the code will stay at the exact same spot until you connect the CCS debugger to the core:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    int main()
    {
    int infiniteLoop = 1;
    while (infiniteLoop) {
    /* not sure if we need to put something here to keep from being optimized out? */
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Follow the steps here to attach CCS to the core and load symbols so you can step through the code:
    AM64x academy, multicore module, Application Development on Remote Cores > "Debug the remote core program from CCS while Linux is running"
    https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__AeMVTHckwFDmFoNkRHpRPw__AM64-ACADEMY__WI1KRXP__LATEST

    Once you have attached to the core, you can manually change the value of variable infiniteLoop to 0, and then start stepping into and over functions.

    If you run into any issues (e.g., if you don't know how to step through code, if you get a message like "Can't find a source file at ", etc), this other page might be useful:
    https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__AOPZf90FClNuBEeBrNlZIQ__com.ti.MCU_PLUS_ACADEMY_AM64X__n6QeJt5__LATEST

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 410 points

    Thanks Nick for providing steps for automatic generation of .yaml file.

    I’m able to generate .yaml  file with help of Sysconfig v1.19 and new K3 resource partitioning tool.

    Only the change what I am able to see with manual entries and automatic is following.

    Automatic: resasg_entries_size: 1328 , Manual:resasg_entries_size: 1288

    Nevertheless , Again I build tiboot3.bin with new .yaml file but result is same "no success".

    Note - I’m only replacing following files from SD Card.

    tiboot3.bin

    tiboot3-am64x_sr2-hs-evm.bin

    tiboot3-am64x_sr2-hs-fs-evm.bin

    tiboot3-am64x-gp-evm.bin

    Suggestion on R5 binaries building process:

    • SDK 9.x should have K3 resource partitioning tool which should generate .yaml file.
    • There is no error generated after resasg_entries_size mismatch
    • Also is there way to find .yaml changes are in cooperated in R5 binaries?

    Note – For testing purpose we have removed most of peripheral dependency.

    Logs with SD Card

    root@am64xx-evm:~# cat /sys/kernel/debug/remoteproc/remoteproc1/trace0
    [unknown]     0.000000s : Before CMN_OS_init
    [unknown]     0.000000s : Before System_init

    Logs with Jtag

    [MAIN_Cortex_R5_0_0]
    DMSC Firmware Version 9.0.7--v09.00.07 (Kool Koala)
    DMSC Firmware revision 0x9
    DMSC ABI revision 3.1
    [SCICLIENT] ABI check PASSED
    [SCICLIENT] Board Configuration with Debug enabled ...
    [SCICLIENT] Common Board Configuration PASSED
    [SCICLIENT] PM Board Configuration PASSED
    [SCICLIENT] RM Board Configuration PASSED
    [SCICLIENT] Security Board Configuration PASSED

    DMSC Firmware Version 9.0.7--v09.00.07 (Kool Koala)
    DMSC Firmware revision 0x9
    DMSC ABI revision 3.1

    Starting SOC Initialization ...
    Resetting self cluster ...
    Before CMN_OS_init
    Before System_init
    After System_init
    after CMN_OS_init
    Pruicss max =3 selected PRU:3

    The data is corrupted, write default values.

    Did Map 0x30080000 len 0x2000 to 0x30080000 (dram0)

    Did Map 0x30082000 len 0x2000 to 0x30082000 (dram1)

    Did Map 0x300b4000 len 0x4000 to 0x300b4000 (iram0)

    Did Map 0x300b8000 len 0x4000 to 0x300b8000 (iram1)

    Did Map 0x30090000 len 0x10000 to 0x30090000 (shdram)

    Did Map 0x300a2000 len 0x400 to 0x300a2000 (control0)

    Did Map 0x300a4000 len 0x400 to 0x300a4000 (control1)

    Did Map 0x300a0000 len 0x2000 to 0x300a0000 (intc)

    Did Map 0x300a6000 len 0x2000 to 0x300a6000 (cfg)

    Did Map 0x300a8000 len 0x2000 to 0x300a8000 (uart0)

    Did Map 0x300ae000 len 0x2000 to 0x300ae000 (iep)

    Did Map 0x300b0000 len 0x2000 to 0x300b0000 (ecap0)

    Did Map 0x300b2000 len 0x400 to 0x300b2000 (mii_rt)

    Did Map 0x300b2000 len 0x1c00 to 0x300b2000 (mdio)

    Did Map 0x3008a000 len 0x2000 to 0x3008a000 (txPru0Iram)

    Did Map 0x3008c000 len 0x2000 to 0x3008c000 (txPru1Iram)

    Did Map 0x300a5000 len 0x100 to 0x300a5000 (txPru0CtlReg)

    Did Map 0x300a5000 len 0x100 to 0x300a5000 (txPru1CtlReg)

    DP83822 detected

    DP83822 detected

    Local interface IP is 192.168.1.10

    CUST_PHY_SPEED_DUPLEX_eCONFIG_10HD

    EI_API_ADP_getMacAddr: 34:08:e1:84:a9:e9

    We already given lot of RND time for this. We are hoping your solution/tested example will arrive in Next week.

    We need your support to review .yaml file and Sysconfig file for any error. Not able upload file original format.

    8738.rm-cfg_yaml.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    # SPDX-License-Identifier: GPL-2.0+
    # Copyright (C) 2022-2023 Texas Instruments Incorporated - https://www.ti.com/
    #
    # Resource management configuration for AM64X
    #
    ---
    rm-cfg:
    rm_boardcfg:
    rev:
    boardcfg_abi_maj : 0x0
    boardcfg_abi_min : 0x1
    host_cfg:
    subhdr:
    magic: 0x4C41
    size : 356
    host_cfg_entries:
    - #1
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Ethernetip_Adapter_Sysconfig.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    /**
    * These arguments were used when this file was generated. They will be automatically applied on subsequent loads
    * via the GUI or CLI. Run CLI with '--help' for additional information on how to override these arguments.
    * @cliArgs --device "AM64x" --package "ALV" --part "Default" --context "r5fss0-0" --product "INDUSTRIAL_COMMUNICATIONS_SDK_AM64x@09.00.00"
    * @versions {"tool":"1.18.0+3266"}
    */
    /**
    * Import the modules used in this configuration.
    */
    const ipc = scripting.addModule("/drivers/ipc/ipc");
    const pruicss = scripting.addModule("/drivers/pruicss/pruicss", {}, false);
    const pruicss1 = pruicss.addInstance();
    const ethernetip = scripting.addModule("/industrial_comms/ethernetip/ethernetip", {}, false);
    const ethernetip1 = ethernetip.addInstance();
    const debug_log = scripting.addModule("/kernel/dpl/debug_log");
    const mpu_armv7 = scripting.addModule("/kernel/dpl/mpu_armv7", {}, false);
    const mpu_armv71 = mpu_armv7.addInstance();
    const mpu_armv72 = mpu_armv7.addInstance();
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Nikhil Jarande
    TI__Guru* 94480 points

    Hello Nikhil,

    I have reassigned your thread to another team member to work with you on understanding exactly how far your R5F code is getting during initialization, to see if we can get any clues about where things stop working.

    Good to know that it doesn't sound like there were any copy-paste errors when generating the first .yaml file. The first time I tried to open your sysconfig file it didn't open, and I ran out of time today. I am continuing to work on the TI-side example in parallel to try to make sure we have a "known good" example to work off of. I'll provide another update next week once I'm back from vacation.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Guru 59851 points

    Hello Nikhil,

    In most probability, the PRU ICSS is the root cause of the issue. So, I enabled the PRU ICSS in the original Hello World example & loaded through the Linux remoteproc driver. The resulting traces are:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    root@am64xx-evm:~# cat /sys/class/remoteproc/remoteproc1/name
    78000000.r5f
    root@am64xx-evm:~# cat /sys/kernel/debug/remoteproc/remoteproc1/trace0
    [unknown] 0.000000s : Before System_init
    root@am64xx-evm:~# dmesg | grep "remoteproc.*pru"
    [ 10.548996] remoteproc remoteproc5: 3000a000.txpru is available
    [ 10.642042] remoteproc remoteproc6: 3000c000.txpru is available
    [ 10.936350] remoteproc remoteproc7: 3008a000.txpru is available
    [ 10.996185] remoteproc remoteproc8: 3008c000.txpru is available
    [ 14.364536] remoteproc remoteproc10: 300b4000.pru is available
    [ 14.388829] remoteproc remoteproc12: 30038000.pru is available
    [ 14.414428] remoteproc remoteproc14: 30034000.pru is available
    [ 14.445392] remoteproc remoteproc16: 300b8000.pru is available
    [ 25.864584] remoteproc remoteproc10: powering up 300b4000.pru
    [ 25.875233] remoteproc remoteproc10: Booting fw image ti-pruss/am65x-sr2-pru0-prueth-fw.elf, size 40936
    [ 25.890361] remoteproc remoteproc10: remote processor 300b4000.pru is now up
    [ 25.904382] remoteproc remoteproc11: Booting fw image ti-pruss/am65x-sr2-rtu0-prueth-fw.elf, size 30884
    [ 25.921078] remoteproc remoteproc7: powering up 3008a000.txpru
    [ 25.928040] remoteproc remoteproc7: Booting fw image ti-pruss/am65x-sr2-txpru0-prueth-fw.elf, size 36672
    [ 25.937604] remoteproc remoteproc7: remote processor 3008a000.txpru is now up
    root@am64xx-evm:~#
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    To see what is up the example, I directly connect to the R5FSS0-0 core via the CCS & finds it stuck like shown

    What is probably happening here is the default Linux filesystem boots the PRU core and so when the R5F example boots up and tries to again initialize the PRU core, the System Firmware NACKs the requests & because of DebugP_assertNoLog macro the control just gets stuck in an infinite loop without any traces.

    Can you check on your side if this indeed is the root cause here? In case it is, you can disable the initialization of the PRU cores by the Linux remoteproc driver by doing the necessary changes in the device tree & try again. The issue then should be resolved.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    TI__Guru 59851 points

    If I instead disable the PRU cores in the Hello World, I get the expected output from the example

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    root@am64xx-evm:~# head -n-0 /sys/kernel/debug/remoteproc/remoteproc1/trace0
    [unknown] 0.000000s : Before System_init
    [r5f0-0] 0.000143s : After System_init
    [r5f0-0] 0.000343s : Hello World!
    [r5f0-0] 0.000351s : Hello World!
    [r5f0-0] 0.000357s : Hello World!
    [r5f0-0] 0.000363s : Hello World!
    [r5f0-0] 0.000368s : Hello World!
    [r5f0-0] 0.000374s : Hello World!
    [r5f0-0] 0.000380s : Hello World!
    [r5f0-0] 0.000386s : Hello World!
    [r5f0-0] 0.000392s : Hello World!
    [r5f0-0] 0.000398s : Hello World!
    root@am64xx-evm:~# dmesg | grep "remoteproc.*pru"
    [ 10.509795] remoteproc remoteproc5: 3000a000.txpru is available
    [ 10.569770] remoteproc remoteproc6: 3000c000.txpru is available
    [ 10.615318] remoteproc remoteproc7: 3008a000.txpru is available
    [ 10.767550] remoteproc remoteproc8: 3008c000.txpru is available
    [ 14.320087] remoteproc remoteproc10: 300b4000.pru is available
    [ 14.341963] remoteproc remoteproc12: 300b8000.pru is available
    [ 14.428392] remoteproc remoteproc14: 30038000.pru is available
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Prashant Shivhare
    Intellectual 410 points

    Hi Prashant ,

    Thanks for your support. Nick Saulnier already checked DTS file once. Can re-check anything missing?  

    Also, if you can mention changes of DTS file here. Everyone in forum will help to understand.

    8308.dts_file.docx

  • 0 in reply to Nikhil Jarande
    TI__Guru 59851 points

    Hi Nikhil,

    The following changes worked for me

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
    index 671c62bfc..c51cb0dc7 100644
    --- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
    +++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
    @@ -713,6 +713,10 @@
    <&mcu_m4fss_memory_region>;
    };
    +&icssg0 {
    + status = "disabled";
    +};
    +
    &serdes_ln_ctrl {
    idle-states = <AM64_SERDES0_LANE0_PCIE0>;
    };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    After these changes, the Hello World example with PRU enabled in the Sysconfig is booting successfully

    Fullscreen
    1
    2
    3
    4
    5
    6
    root@am64xx-evm:~# cat /sys/kernel/debug/remoteproc/remoteproc1/name
    78000000.r5f
    root@am64xx-evm:~# cat /sys/kernel/debug/remoteproc/remoteproc1/trace0
    [unknown] 0.000000s : Before System_init
    [r5f0-0] 0.002292s : After System_init
    [r5f0-0] 0.002492s : Hello World!
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Intellectual 410 points

    Hi Prashant,

    Thanks for update. We already taken care of “Disabling” PRU (icssg1_emac1 & icssg1_emac0) in dts. DTS file already validated by Nick. Maybe you will not encounter same problem as we are working with different code base. Can you check ethernet/ip code? Then only we can come to conclusion. Thanks for your support.

  • 0 in reply to Nikhil Jarande
    TI__Guru 59851 points

    Hi Nikhil,

    If your code is not getting past the System_init function call, then the control is mostly stuck in PowerClock_init function while trying to power up one of the IP. Have you tried debugging via CCS to see exactly where the control is stuck? I have already demonstrated this in my previous replies.

    Also, the PRU module uses ICSSG0 unless changed. So, you need to disable the ICSSG0 in the DTS

    Fullscreen
    1
    2
    3
    &icssg0 {
    status = "disabled";
    };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    TI__Guru* 94480 points

    I'm back, though Prashant will continue to drive support for now.

    The next step is on you. We cannot provide additional support until you find exactly where the code is freezing.

    Please start by following the steps I gave you here:
    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/5022546#5022546

    Then follow Prashant's guidance to get to the exact place where the R5F stops.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 410 points

    Sure, we will come with exact freezing point. Thanks for your support and time.

  • 0 in reply to Nikhil Jarande
    Intellectual 410 points

    Hi Prashant, Nick,

    We followed procedure mention by you. Its getting stuck at "PowerClock_init();" function. 

    Thanks,

    Nikhil

  • 0 in reply to Nikhil Jarande
    TI__Guru 59851 points

    Hi Nikhil,

    In that case, can you share the arrays `gSocModules` & gSocModulesClockFrequency` defined in the Sysconfig autogenerated file `ti_power_clock_config.c` of your application.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 140 points

    Hi Prashant,

    Thanks for the quick response.

    Here is the array defined in sysconfig auto generated file.

    uint32_t gSocModules[] = {
    TISCI_DEV_PRU_ICSSG1,

    SOC_MODULES_END,
    };

    SOC_ModuleClockFrequency gSocModulesClockFrequency[] = {
    { TISCI_DEV_PRU_ICSSG1, TISCI_DEV_PRU_ICSSG1_CORE_CLK, 200000000 },
    { TISCI_DEV_PRU_ICSSG1, TISCI_DEV_PRU_ICSSG1_UCLK_CLK, 192000000 },
    { TISCI_DEV_PRU_ICSSG1, TISCI_DEV_PRU_ICSSG1_IEP_CLK, 200000000 },

    { SOC_MODULES_END, SOC_MODULES_END, SOC_MODULES_END },
    };

    Regards,

    Sonu

  • 0 in reply to Sonu Kumar
    TI__Guru 59851 points

    Hi Sonu,

    The only module enabled here is ICSSG1. So, you need to disable the ICSSG1 in the DTS file also. Please add the following in your DTS and try again. The control should not get stuck at least in PowerClock_init.

    Fullscreen
    1
    2
    3
    &icssg1 {
    status = "disabled";
    };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 140 points

    Hi Prashant,

    We looked into our dts file, status of ICSSG1 is already disabled.

    Nevertheless, if there is anything which we are missing or need to be changed in dts and dtsi file, please do let us know.

    Please find  attached dts and dtsi file.

    k3-am642-evm.zip

    Any feedback would be highly appreciated.

    Regards,

    Sonu

  • 0 in reply to Sonu Kumar
    TI__Guru 59851 points

    Hi Sonu,

    The correct node that needs to be disabled here is named `icssg1`

    Fullscreen
    1
    2
    3
    &icssg1 {
    status = "disabled";
    };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    TI__Guru* 94480 points

    Hello Sonu,

    To add a bit more background:

    It was good that you disabled the PRU Ethernet driver node, icssg1-eth. However, the PRU Ethernet node is not the driver that actually loads firmware into the PRU_ICSSG and initializes the PRU subsystem - the PRU initialization is done by the PRU remoteproc driver.

    So if you want to make sure that the Linux PRU remoteproc driver is not grabbing the PRU_ICSSG subsystem, you need to disable that icssg1 node as well. Make sure to format it like Prashant did in his response here: 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/5025879#5025879

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 140 points

    Hi,

    Thanks for the response.

    We disabled icssg1 as suggested by Prashant.

    We are able to run the Ethernet-ip Ad.apter Application.

    But we are not able do any communication with the Ethernet-IP application running on R5F0_0.

    Even Ping command does not work with ip 192.168.1.10.

    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

    Please suggest the procedure to solve this isuue.

    Thank You.

  • 0 in reply to Sonu Kumar
    TI__Guru 59851 points

    Hi Sonu,

    Glad to know you are now past the initial blocker. I will now move the thread back to Nick for further support.

    While Nick gets back to you, can you help us with the following questions that probably will be of help:

    1) Are these logs from the R5F firwmare booting via remoteproc expected? That is, these are the logs you would have gotten if you had booted the R5F using purely MCU+ SDK.

    2) If you boot this R5F firmware with purely MCU+ SDK, are you able to ping?

    3) Have you made sure your host PC on which you are running ping command is connected to the same network as your board?

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 140 points

    Hi Prashant,

    Thanks for the quick response.

    1)Are these logs from the R5F firwmare booting via remoteproc expected? That is, these are the logs you would have gotten if you had booted the R5F using purely MCU+ SDK.

    yes,  The Logs are same.

    2) If you boot this R5F firmware with purely MCU+ SDK, are you able to ping?

    Yes we are able to ping when we run using purely MCU+SDK.

     3)Have you made sure your host PC on which you are running ping command is connected to the same network as your board?

    Yes host PC is connected to the same network.

    Quick response is appreciated.

    Thank You.

  • 0 in reply to Sonu Kumar
    TI__Guru* 94480 points

    Hello Sonu,

    Glad to hear that you have gotten to the next debug step! Prashant was helping us with MCU+ side debug. Now I'm sending your thread to a team member more familiar with PRU networking. I'll continue watching the thread, and I'll hop in as needed.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Guru* 94480 points

    Also, I realized that the last time I asked for your .sysconfig file, you attached the .sysconfig file for the industrial SDK project. If you want me to double-check your resource allocation, please attach your modified version of the .sysconfig file that is within the K3 Resource Partition tool (the original file was in k3-respart-tool/out/am64x-evm.syscfg), and I'll double-check it.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 595 points

    Hi Nick,

              Thank you for the response.

    please find attached the

    1) sysconfig file that is within the K3 Resource Partition tool.

    and

    2) our modified sysconfig file used Ethernet adapter MCU application.

    Any feedback would be highly appreciated.

    sysconfig.zip

  • 0 in reply to Narasimha Rao
    Intellectual 595 points

    Hi Nick,

        Can you please update on the issue requested.

        Any feedback would be highly appreciated.

    Thank You.

  • 0 in reply to Narasimha Rao
    TI__Mastermind 26430 points

    Hi ,

    Thanks for follow-up.

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

    As per our understanding you have working Linux + MCU (RemoteProc) setup. Just ping is not working. correct ?

    If yes. Below is a basic example for TCP server on ICSSG where ping is working correctly.

    You can try it on your setup and update the results.

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

    Best Regards

    Ashwani

  • 0 in reply to Ashwani Goel
    Intellectual 595 points

    Hi Ashwani,

                 Thank you for the response.

               Our customer is waiting for the release.

                 Quick response would be appreciated.

    Thank You.

  • 0 in reply to Narasimha Rao
    TI__Mastermind 26430 points

    Hi ,

    Did you try the the suggestion ?

    Ashwani Goel said:
    You can try it on your setup and update the results.

    Best Regards

    Ashwani

1 2