Hello Madalin-cristian

On 15/01/2018, Madalin-cristian Bucur wrote:

quoted

quoted

The device tree that you mention, cyrus_p5020.eth.dts is not found in
the Linux kernel sources. The cyrus_p5020.dts file from the fsl ppc
device tree folder does not include the PHY information for the DPAA
interfaces. The problems that you experience may be caused by some
issues with the PHY configuration (i.e. internal delay).

The cyrus_p5020.eth.dts is a modified version of the cyrus_p5020.dts,
which of course was based off the original p5020ds.dts file. As you
noted, the current cyrus_p5020.dts file is incomplete, and does not
map the Ethernet connections properly.

This is because the current linux kernel version of cyrus_p5020.dts includ=
es 'p5020si-pre.dtsi' and 'p5020si-post.dtsi' include files, which orginal=
ly gave us working ethernet (when we used the SDK kernel) However at some =
point you moved the ethernet aliases from the board dts file to the p5020s=
i-pre.dtsi file breaking the linkages for our board.

cyrus-pre.dtsi is simply p5020si-pre.dtsi with only the correct aliases in=
.

quoted

** I have attached both the cyrus_p5020.eth.dts and cyrus-pre.dtsi
 =A0=A0=A0=A0 files with this email for comparison. Please let me know =

if you see

quoted

 =A0=A0=A0=A0 any corrections that should be made to either file.

At a first glance they look fine to me.

That's good to know.

quoted

I have started testing along that line, using Wireshark to view the
traffic on the X5000/20 itself, and from another machine connected
on the same subnet. So far (as indicated by some details of in my
initial email), I can see outgoing broadcast requests (for DHCP)
being sent out from the X5000/20, and these requests are correctly
constructed and visible outside the X5000/20.
=

quoted

However, no responses to the DHCP broadcasts appear to reach
to X5000/20's DPAA Ethernet. I will need to setup some further
tests to determine if the DHCP server saw the requests and responded
to them. (I assume the DHCP server is getting them, and responding,
as I can always get a successful DHCP response to the X5000/20
when using an add-on Ethernet PICe card on the same subnet).

This matches what I see, the interface I have connected to the network sho=
ws an increasing number of transmitted packets, but no received ones.

Jamie also noticed the following error in dmesg (right after the ethernet =
port becomes active)

[    4.112165] fsl_dpa dpaa-ethernet.0 eth0: Probed interface eth0
[    4.116616] fsl_dpa dpaa-ethernet.1 eth1: Probed interface eth1
[ ... ]
[  106.501055] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[  106.570944] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[  106.605044] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[  106.674918] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[  108.702771] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[  109.032798] fsl-pamu: pamu_av_isr: access violation interrupt
[  109.032806] fsl-pamu: pamu_av_isr: POES1=3D00000000
[  109.032808] fsl-pamu: pamu_av_isr: POES2=3D00000000
[  109.032809] fsl-pamu: pamu_av_isr: AVS1=3D002d0081
[  109.032811] fsl-pamu: pamu_av_isr: AVS2=3D00000081
[  109.032813] fsl-pamu: pamu_av_isr: AVA=3D00000001f1328000
[  109.032815] fsl-pamu: pamu_av_isr: UDAD=3D002d0001
[  109.032817] fsl-pamu: pamu_av_isr: POEA=3D0000000000000000

I haven't seen this anywhere else, and wondered if it is relevant.

Regards
Darren