AM57x PRU-ICSS Ethernet network unreachable

Hi user4205571,

It seems that the eth2 configuration is applied properly. I suggest you to check the network cable and device port. Also check the Linux kernel log "dmesg" command output. If all seems correct make the following test:
Connect the AM57xx board network cable to PC. Configure the PC ethernet interface to be in same subnet with the board. Install on the PC Wireshark and start a capture. Ping the PC from the board. Save and attach the capture.
Wireshark can be downloaded from: www.wireshark.org/download.html


BR
Tsvetolin Shulev

Can you verify that you have 'ti,am5728-idk' or 'ti,am5718-idk' in the compatibility string of your device tree? E.g:

compatible = "ti,am5718-idk", "ti,am5718", "ti,dra722", "ti,dra72", "ti,dra7";

Also, can you post the output of the following command:

ls /dev/ | grep pru

Jason Reeder

From the log above it looks like the PRU Ethernet firmwares are being loaded into PRUSS2 PRU0 and PRUSS2 PRU 1 now:

[ 7.107566] remoteproc7: Booting fw image ti-pruss/am57xx-pru1-prueth-fw.elf, size 3645

[ 7.193149] remoteproc6: Booting fw image ti-pruss/am57xx-pru0-prueth-fw.elf, size 3645

Are you able to get an IP address and ping now?

Jason Reeder

PS. /dev/rpmsg_pru30 and /dev/rpmsg_pru31 are coming from the out-of-box generic PRU firmwares that are being loaded into PRUSS1 PRU0 and PRUSS1 PRU1. This should not interfere with PRUSS2 performing its Ethernet responsibilities in any way.

Can you confirm that you configured the pin mux correctly for the PRU Ethernet pins? In the example provided in the Linux Processor SDK on the IDK boards this is accomplished during U-Boot. This might explain why you don't see signals on all of the Ethernet pins.

Check out the '{u-boot directory}/board/ti/am57xx/board.c' and '{u-boot directory}/board/ti/am57xx/mux_data.h' files.

Jason Reeder

I spoke with the driver developers about your issue and they had the following questions:

• What do you mean when you say 'we use beagle's power management program'?
  • If you are using power management we will need to be sure that the SRAM usage of the PRU Ethernet does not overlap with your power management.
• Did you make any changes to the schematics on your board for the PRU Ethernet section when compared to our AM572x IDK board?
  • Would you be able to provide the PRU Ethernet portion of your schematic and the full DTS source?
  • Are you using the same Ethernet PHY that was on the IDK board and is it being bootstrapped correctly?
  • Are the PHY link and speed LEDs lighting up correctly on the RJ-45 connector?
• You are using the kernel and file system provided in v3.0.0.4 of the Linux Processor SDK correct?
• Can you provide your code where you are configuring your pin muxing of the PRU Ethernet pins?

Jason Reeder

Hi jason

    The following is the schematic diagram of our board， We are not using the network port rj45 We are using HR911205C。the other part of the same IDK schematics 

I am using the kernel and file system provided in v3.0.0.4 of the Linux Processor SDK 

Attachment package contains the device tree source code, pin multiplexing configuration, the schematic diagram

  am728_igh.tar.gz

One thing that stands out is that you are boot strapping both of your PRU_ETH PHYs to address 0x01 on the PR2_MDIO bus. Table 5-1 in section 5.1.1 of the TLK105L datasheet (http://www.ti.com/lit/gpn/tlk105l) shows that the COL pin is the boot strap pin for PHYAD0. Both of your COL pins on your TLK105L connections are being set HIGH at reset which would make both of your PHYs respond to MDIO data sent to address 0x01.

From your labels in your schematic it looks like you wanted to mimic the addressing on the IDK board where PR2_ETH0 is address 0x00 and PR2_ETH1 is address 0x01. See the differences in the COL pin strapping in the IDK schematic (http://www.ti.com/lit/pdf/tidrlh4) on pages 13 and 14. PR2_ETH0 has a 2.2k pull down resistor on the COL line that sets its address as 0x00 where PR2_ETH1 matches your schematic (no pull down) and gets set to address 0x01.

Let me know if this helps.

Jason Reeder

Hi jason

    As shown in our schematic section, the PR2_ETH0 has a pull-down on the COL pin with the 2.2K resistor set to address 0x00. PR2_ETH1 is the pull-up 2.2K resistor set address 0x01,

   I also made the following changes to ensure that the schematic diagram and IDK consistent：

     1,  Replace the L12 and L13 inductors with 0 ohm resistors  （pin 14）
     2,  the MDIO pull-up 2.2K resistor （pin 19）
     3,  the C367 and C368 capacitor removed （pin 18）

   Where is the PRU_ETH PHYs address set in the software section?

HI Jason

IDK and EVM hardware GU found in the IDK board on the VDD_CORE set voltage is 1.15V, Beagle board VDD_CORE set voltage is 1.06V.This will have an impact on the PRU it?

http://www.ti.com.cn/tool/cn/tmdxidk5728?keyMatch=AM5728%20IDK&tisearch=Search-CN-Everything

         http://processors.wiki.ti.com/index.php/AM572x_General_Purpose_EVM_HW_User_Guide

My mistake, I had missed your pull down resistor on PR2_ETH0. This looks correct.

My question about the power management was a misunderstanding. We thought you were talking about power management firmware that might be sharing SRAM space with the PRU Ethernet driver. But, it is now clear that you are talking about the Power Management IC on the board.

I've got a few more request from the driver developers:

• Please apply the attached patch (/cfs-file/__key/communityserver-discussions-components-files/791/0001_2D00_debug_2D00_phy_2D00_spit_2D00_out_2D00_some_2D00_phy_2D00_registers.patch) and then provide the PHY register dump that appears in the kernel log. This is the dump from a working am572x-idk:

  • [   10.437566] ==== PHY regs ===

    [   10.437693] BMCR(0x0): 0x3100

    [   10.437823] BMSR(0x1): 0x7849

    [   10.437953] PHYIDR1(0x2): 0x2000

    [   10.438083] PHYIDR2(0x3): 0xa212

    [   10.438213] CR1(0x9): 0x7800

    [   10.438343] PHYSCR(0x11): 0x108

    [   10.438473] RCSR(0x17): 0x41

    [   10.438603] LEDCR(0x18): 0x400

    [   10.438733] PHYCR(0x19): 0x8000

    [   10.438734] =================

    [   10.517581] ==== PHY regs ===

    [   10.517708] BMCR(0x0): 0x3100

    [   10.517838] BMSR(0x1): 0x7849

    [   10.517968] PHYIDR1(0x2): 0x2000

    [   10.518098] PHYIDR2(0x3): 0xa212

    [   10.518228] CR1(0x9): 0x7800

    [   10.518358] PHYSCR(0x11): 0x108

    [   10.518488] RCSR(0x17): 0x41

    [   10.518620] LEDCR(0x18): 0x400

    [   10.518748] PHYCR(0x19): 0x8001

    [   10.518749] =================

• Looking at the mux_data.h file we still can't tell which list is being selected on your board. Can you share your board.c file as well?
• We would like to check if you are using the correct firmware blobs. Can you post the md5sum of the two .elf files in your file system?
  • md5sum /lib/firmware/ti-pruss/am57xx-pru0-prueth-fw.elf
    
    • af69f8d9bd5cf1b5fa7fede2e7be2f56  /lib/firmware/ti-pruss/am57xx-pru0-prueth-fw.elf
  • md5sum /lib/firmware/ti-pruss/am57xx-pru1-prueth-fw.elf
    • e0dd15996b60a72b7578fa536d988b13  /lib/firmware/ti-pruss/am57xx-pru1-prueth-fw.elf

Jason Reeder