cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
venkatakrishs
Observer
Observer
797 Views
Registered: ‎02-21-2021

of_phy_connect() failed using Xilinx Emaclite with embedded Linux on Arty 100T board

Hi,

I am currently on a project for enabling ethernet in arty 100t board with embedded linux 5.5.0-rc1 - RISCV-64. I am currently using Berkley Bootloader (BBL) for booting the Linux on the board. The probing for the Xilinx Emaclite is successful and the probe output is as follows:

 

[   49.643432] Device Tree Probing for EmacLite Started...
[   49.820343] The base address is 14000 
[   49.975799] libphy: Xilinx Emaclite MDIO: probed
[   50.155609] xilinx_emaclite 44000.ethernet: MAC address is now 00:0a:35:00:00:00
[   50.635192] xilinx_emaclite 44000.ethernet: Xilinx EmacLite at 0x00044000 mapped to 0x00014000, irq=31

 

After the probing is done and when the linux boots-up the ifconfig -a shows the eth0 interface. But when I try to start/up the eth0 interface I get this output :

 

$ ifconfig eth0 up
[ 1138.855346] net eth0: of_phy_connect() failed
ifconfig: SIOCSIFFLAGS: No such device

 

I have few questions along with this :

  • Why is the memory map base address getting remapped to 0x14000 rather than maintaining at 0x44000?
  • Is the phy number in the DTS file cause this error? If yes, what is the default value for arty-100t board.

Note: The interrupt for AXI Ethernet Emaclite is connected to PLIC with interrupt number as 31.

I have also attached the DTS file for reference.

0 Kudos
9 Replies
nanz
Moderator
Moderator
739 Views
Registered: ‎08-25-2009

Hi @venkatakrishs ,

Are you sure the PHY address is 0x1 which is connected to the MAC?

Can you please check in uboot and do a mii info to check? 


-------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs and our Versal Ethernet Sticky Note.

-------------------------------------------------------------------------------------------
0 Kudos
venkatakrishs
Observer
Observer
731 Views
Registered: ‎02-21-2021

Hi @nanz,

Thanks again for your reply.

I am currently using BBL as the bootloader which does not have "mii info" command support. Is there any other option by which we can check the PHY ID of the ethernet interface. Or is there any place we can specify the PHY address?

Thanks.

0 Kudos
nanz
Moderator
Moderator
716 Views
Registered: ‎08-25-2009

Hi @venkatakrishs , 

I am not sure in the case of BBL. But PHY addr should be hard strapped on the board that you have. You may refer to the board user guide and check if you can find the info. 

Btw, it seems your IRQ issue has been resolved? Appreciate if you could post your solution in another thread and mark it accepted solution so it could benefit also other forum users. Thank you!


-------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs and our Versal Ethernet Sticky Note.

-------------------------------------------------------------------------------------------
0 Kudos
venkatakrishs
Observer
Observer
661 Views
Registered: ‎02-21-2021

Hi @nanz,

I have enabled mii-diag support in the buildroot/busybox and have used in the kernel. The output of the command was

Using the default interface 'eth0'.
SIOCGMIIPHY on eth0 failed: Invalid argument

Also from the output it seems the PHY ID is the issue. As mentioned earlier I am using ARTY-7 100T board. As per the manual the PHY address is 0x1 at reset/startup. But with this dts I am not able to bring the interface up.

I have also tried to introduce delays as to let the transaction take time. But still the issue persists.

Thanks.

0 Kudos
venkatakrishs
Observer
Observer
569 Views
Registered: ‎02-21-2021

Hi @nanz,

The issue was on the dts compatible field for the mdio section. While I was going through the Xemaclite code and parsing through it to find an issues I found a section where the below comment was present.

 

 

/* The following is a list of PHY compatible strings which appear in
 * some DTBs. The compatible string is never matched against a PHY
 * driver, so is pointless. We only expect devices which are not PHYs
 * to have a compatible string, so they can be matched to an MDIO
 * driver.  Encourage users to upgrade their DT blobs to remove these.
 */
static const struct of_device_id whitelist_phys[] = {
        { .compatible = "brcm,40nm-ephy" },
        { .compatible = "broadcom,bcm5241" },
        { .compatible = "marvell,88E1111", },
        { .compatible = "marvell,88e1116", },
        { .compatible = "marvell,88e1118", },
        { .compatible = "marvell,88e1145", },
        { .compatible = "marvell,88e1149r", },
        { .compatible = "marvell,88e1310", },
        { .compatible = "marvell,88E1510", },
        { .compatible = "marvell,88E1514", },
        { .compatible = "moxa,moxart-rtl8201cp", },
        {}
};
/*
 * Return true if the child node is for a phy. It must either:
 * o Compatible string of "ethernet-phy-idX.X"
 * o Compatible string of "ethernet-phy-ieee802.3-c45"
 * o Compatible string of "ethernet-phy-ieee802.3-c22"
 * o In the white list above (and issue a warning)
 * o No compatibility string
 *
 * A device which is not a phy is expected to have a compatible string
 * indicating what sort of device it is.
 */

 

 

I think I have crossed the initialization part but after the kernel boots when I check for the interface by ifconfig I get

 

 

$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0A:35:00:00:00  
          UP BROADCAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:31 Memory:44000-47fff 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

 

 

After this when I add few lines in the /etc/network/interfaces for eth0 and say ifup eth0 the ip address and the netmask are assigned to eth0. But when I check in ethtool for that interface I get that "Link detected: no".

 

 

$ ethtool eth0
Settings for eth0:
	Supported ports: [ ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     10000baseT/Full 
	                                     2500baseT/Full 
	                                     5000baseT/Full 
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 100Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 1
	Transceiver: internal
	Auto-negotiation: on
	Link detected: no

 

 

And when I do a ping or wget test it says "No route to host". But when I disable loopback and try the same command (say wget) I get Connection timed out. But still the ethtool returns Link detected : no.

I have attached the latest dts file.

Thanks.

0 Kudos
nanz
Moderator
Moderator
555 Views
Registered: ‎08-25-2009

Hi @venkatakrishs ,

You have mentioned loopback above. Have you tried to put the axi_ethernetlite IP or the PHY in loopback mode for testing? 

If so, I would expect when you do ifconfig you will see tx/rx counter increments as in looping back mode. If you have not tried it, I would first try loopback mode in the IP as well as in the PHY to see if this works. Please refer to PG135 on how to set the IP in loopback mode. For PHY loopback, you will need to check the PHY register. 


-------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs and our Versal Ethernet Sticky Note.

-------------------------------------------------------------------------------------------
0 Kudos
venkatakrishs
Observer
Observer
542 Views
Registered: ‎02-21-2021

Hi @nanz,

I tried to read the register values from the BMCR and BMSR which basically showed ffff.

$ phytool print eth0␛[J/0
ieee-phy: id:0xffffffff

   ieee-phy: reg:BMCR(0x00) val:0xffff
      flags:          ␛[1m+reset␛[0m ␛[1m+loopback␛[0m ␛[1m+aneg-enable␛[0m ␛[1m+power-down␛[0m ␛[1m+isolate␛[0m ␛[1m+aneg-restart␛[0m ␛[1m+collision-test␛[0m
      speed:          1000-full

   ieee-phy: reg:BMSR(0x01) val:0xffff
      capabilities:   ␛[1m+100-b4␛[0m ␛[1m+100-f␛[0m ␛[1m+100-h␛[0m ␛[1m+10-f␛[0m ␛[1m+10-h␛[0m ␛[1m+100-t2-f␛[0m ␛[1m+100-t2-h␛[0m
      flags:          ␛[1m+ext-status␛[0m ␛[1m+aneg-complete␛[0m ␛[1m+remote-fault␛[0m ␛[1m+aneg-capable␛[0m ␛[1m+link␛[0m ␛[1m+jabber␛[0m ␛[1m+ext-register␛[0m

I forced the mii-diag to report the registers and the log showed as follows.

$ mii-diag ␛[J --force
Using the default interface 'eth0'.
Basic registers of MII PHY #1:  ffff ffff ffff ffff ffff ffff ffff ffff.
  No MII transceiver present!.
 The autonegotiated capability is 03e0.
The autonegotiated media type is 100baseTx-FD.
 Basic mode control register 0xffff: Auto-negotiation enabled.
  Internal Collision-Test enabled!
  Restarted auto-negotiation in progress!
  Transceiver isolated from the MII!
  Transceiver powered down!
  Transceiver in loopback mode!
  Transceiver currently being reset!
 Basic mode status register 0xffff ... ffff.
   Link status: established.
 Remote fault detected!
   *** Link Jabber! ***
 Your link partner advertised ffff: Flow-control 100baseT4 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control.
   End of basic transceiver information.

 I also tried to enable loopback(lo) interface and tried to wget an address while the ifconfig reported an increase in 7 packets(both tx and rx) per wget command issued.

I guess that the PHY communication is not working. Is there a way to check if the communication with the PHY is done correctly.

Thanks.

0 Kudos
nanz
Moderator
Moderator
430 Views
Registered: ‎08-25-2009

Hi @venkatakrishs ,

Are you able to read the PHY registers through management interface correctly? If so, could you dump all PHY registers and take a look at it?

This may give us some hint to narrow down the issue.


-------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs and our Versal Ethernet Sticky Note.

-------------------------------------------------------------------------------------------
0 Kudos
venkatakrishs
Observer
Observer
314 Views
Registered: ‎02-21-2021

Hi @nanz,

I was not able to read the correct values before and found the issue in the SoC design. The issue was that the SoC had a connection missing to take the MDIO in. After fixing that issue, I am now able to read the MDIO CONTROL and STATUS registers.

# phytool eth0/1
ieee-phy: id:0x20005c90

   ieee-phy: reg:BMCR(0x00) val:0x3100
      flags:          -reset -loopback +aneg-enable -power-down -isolate -aneg-restart -collision-test
      speed:          100-full

   ieee-phy: reg:BMSR(0x01) val:0x786d
      capabilities:   -100-b4 +100-f +100-h +10-f +10-h -100-t2-f -100-t2-h
      flags:          -ext-status +aneg-complete -remote-fault +aneg-capable +link -jabber +ext-register

With this value and the manual I was able to verify that the register values are correct and the PHY detects a link when a ethernet cable is connected to it.

But, after the MDIO registers are readable still I am not able to ping to another device in the network. There was a socket issue which showed denied permission, for which I edited the /proc/sys/net/ipv4/ping_group_range to "0 65535" and then the socket was assigned when called. Soon after the ping, it calls the ping_error function which says

[43040.769073] Error on socket...
[43040.844329] ICMP_DEST_UNREACH

I checked the physical memory by using devmem in buildroot busybox and found the values at the control registers are all valid and correct. Also, i checked the phy memory of the PLIC for the interrupt enable, priority threshold and interrupt pending and found that all of the registers have values while the interrupt pending and the interrupt complete/claim register have value 0x0.

Any ideas on what may have caused this is appreciated.

Thanks.

0 Kudos