• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 102 subscribers
  • Views 136 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.

AM6548: SR1.0 GPEVM PRU_ICSSG2 - U-boot Network Errors

Benjamin Roytburd
Intellectual 260 points
Part Number: AM6548
Other Parts Discussed in Thread: TMDX654IDKEVM

Hello,

I am using a AM65x_GP_EVM with SR1.0, I am attempting to use PRU ICSSG2 port 0 to use the PRU/RTU firmware binaries to load data over U-boot. I am following a similar process to this: 

https://software-dl.ti.com/processor-sdk-linux/esd/AM65X/latest/exports/docs/linux/Foundational_Components/U-Boot/UG-Network.html#sample-script-for-am65-sr1

Except what I do, is I load the PRU/RTU firmware over ethernet, and place them into flash, then on a power cycle I load them from flash onto the remote processors. 

Something like this:

Connected over CPSW, I load the eth-fw binaries into flash memory:

sf probe

tftp $loadaddr am65x-pru0-prueth-fw.elf
setenv pru0_prueth_size 0x${filesize}
sf update $loadaddr 0x3500000 $pru0_prueth_size 

tftp $loadaddr am65x-rtu0-prueth-fw.elf
setenv rtu0_prueth_size 0x${filesize}
sf update $loadaddr 0x3700000 $rtu0_prueth_size 

saveenv


I then reboot, and connect to ICSSG port 0, and run the following to load the eth-fw over rproc:

sf probe
rproc init

sf read $loadaddr 0x3500000 $pru0_prueth_size 
rproc load 10 $loadaddr $pru0_prueth_size 
rproc start 10

sf read $loadaddr 0x3700000 $rtu0_prueth_size 
rproc load 11 $loadaddr $rtu0_prueth_size 
rproc start 11

setenv ipaddr 192.168.20.20
setenv netmask 255.255.255.0
setenv serverip 192.168.20.1

ping 192.168.20.19

I then get the following when I ping:

=> ping 192.168.20.20
am65_cpsw_nuss_port ethernet@46000000port@1: K3 CPSW: rflow_id_base: 2
ethernet@46000000port@1 Waiting for PHY auto negotiation to complete......... TIMEOUT !
am65_cpsw_nuss_port ethernet@46000000port@1: phy_startup failed
am65_cpsw_nuss_port ethernet@46000000port@1: am65_cpsw_start end error
prueth icssg2-eth: RX dma flow id bad, expected 0, actual 2
prueth icssg2-eth: RX mgm dma flow id bad, expected 1, actual 3
prueth icssg2-eth: Error or no response from firmware 0
prueth icssg2-eth: Error sending port speed/duplex cmd
link up on port 0, speed 100, full duplex
Using icssg2-eth device

ARP Retry count exceeded; starting again
prueth icssg2-eth: Error or no response from firmware 0
prueth icssg2-eth: Error executing firmware shutdown cmd
ping failed; host 192.168.20.20 is not alive

Over Wireshark is see ARP broadcasts even coming from the PHY, and my PC replies, but it still just errors out. I have seen on other posts that this works with SR1.0, why am I getting these "no response" errors and ARP failures?

Thanks,
Ben

  • 0
    TI__Guru* 76425 points

    Hello Ben,

    What SDK version are you using?

    Please keep in mind that in general, we are only shipping AM65x SR2.0 for production designs. Feel free to have your TI field engineer reach out to me if you think you need specifically the SR1.0 version of silicon.

    The reason that matters for PRU Ethernet is that the PRU_ICSSG was one of the peripherals that received the most updates between SR1.0 and SR2.0. So in general, if you are developing for production, I would suggest developing on an EVM with AM65x SR2.0 silicon on it.

    I am double-checking with the developer on whether LCPD-28436 was actually addressed in SDK 9.1. I thought it was resolved (i.e., PRU Ethernet now working in uboot on AM65x SR2.0), but it still shows up in the uboot known issues section of the release notes: https://software-dl.ti.com/processor-sdk-linux/esd/AM65X/09_01_00_01/exports/docs/devices/AM65X/linux/Release_Specific_Release_Notes.html#u-boot-known-issues

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 260 points

    I am using the Linux SDK version 8.02.00.02, the reason I am using the SR1.0 is because this is just the GPEVM and it is what it came with. 

    It seems the LCPD-28436 is unique to the IDK though, and I have the GPEVM. . 

    Do you think I should still try with the SDK 9.1 ? Should I just use the newly built prueth elf files, or rebuild U-boot entirely and use the new U-boot?

  • 0 in reply to Benjamin Roytburd
    TI__Guru* 76425 points

    Hello Ben,

    Here's feedback from the developer:

    Q: When was the last release where AM65x SR1.0 PRU Ethernet in Uboot was verified as working?

    A: I am not sure. We have discontinued AM65x SR1.0 development for a while

    Q: I thought that LCPD-28436 was resolved for AM65x SDK 9.1, but it is still listed as a “known issue” in the SDK release notes. Can you help me understand what is going on?

    A: Thes issue is resolved and prueth is working in uboot for both AM64x and AM65x, but the code was not merged to ti-u-boot in time to get into SDK 9.1. We can provide the patches to customers to unblock them. I am currently upstreaming this series [1], so PRU Ethernet in Uboot will probably be added as a part of AM64x SDK 9.2 and AM65x SDK 10.x

    [1] https://lore.kernel.org/all/20240124064930.1787929-1-danishanwar@ti.com/

    Based on that, what would I suggest? 

    Hardware

    I would suggest using an EVM with AM65x SR2.0 silicon on it. We don't know the last time AM65x SR1.0 PRU Ethernet in Uboot was tested as working, so I cannot tell you whether we would expect it to work on your board for SDK 8.2. The important thing is the version of PRU_ICSSG that is on the processor (among other things, the firmware code is totally different because AM65x SR1.0 has 4 cores per ICSSG, while AM65x SR2.0 has 6 cores per ICSSG), not the board.

    So then the question is, what silicon version is on TMDX654GPEVM and TMDX654IDKEVM?
    The IDK that is currently for sale on ti.com has SR2.0 silicon
    The GPEVM might still be shipped with SR1.0 silicon... I am checking with the EVM team now.

    Software 

    I would suggest using SDK 9.1, and patching it either with code patches that we can provide, or with the updated driver & firmware in the AM64x SDK 9.2. the PRU_ICSSG drivers & firmware is the same for AM64x & AM65x.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 260 points

    Thank you for following up on this! The EVMs I have definitely have SR1.0 on them. Regardless of what will be used in the future, I would like a way to at least test with the GPEVMs if possible. 

    Should I just use the prueth firmware from 9.1 then? Or do I also need to use U-boot from 9.1 as well? I would like to keep my current version of U-boot from 8.02 if possible. 

    Do you know when AM65x SDK 10.x will be released? In the future our board designs will use SR2.0, but in the meantime for software development we have SR1.0, so having that at least working would be ideal for dev. 

  • 0 in reply to Benjamin Roytburd
    Intellectual 260 points

    FYI it seems the binaries from 9.1. also yield the same issues, should I use the new U-boot as well?

  • 0 in reply to Benjamin Roytburd
    TI__Expert 6450 points

    Hi Ben,

    Nick is Out of Office today and will respond later this week.

  • 0 in reply to Anshu Madwesh
    TI__Guru* 76425 points

    Hello Ben,

    I got confirmation from the hardware team:

    TMDX654GPEVM - Silicon v1.0. The team meant to deprecate these a year ago but then other stuff popped up and that email chain got lost. We are re-starting the process of deprecating these EVMs.

    TMDX654IDKEVM - Silicon v2.0

    Can you use SR1.0 to test PRU Ethernet features? 

    Unfortunately no. The current PRU Ethernet Linux developer started working on the code about a year and a half ago, and as far as I can tell he never tested SR1.0, only AM65x SR2.0 & AM64x. As far as I can tell, SDK 8.6 and later PRU Ethernet features were definitely not tested on SR1.0, SDK 8.2 PRU Ethernet features were probably not tested on SR1.0, and I cannot comment on earlier SDKs than that.

    I would expect that most of the other AM65x features could be tested on GP silicon - just make sure you have reviewed the differences between SR1.0 and 2.0 to see where the other changes are.

    Regards,

    Nick