Re: DPAA Ethernet problems with mainstream Linux kernels

[Darren Stevens <darren@stevens-zone.net>]

Hello Madalin-cristian

On 15/01/2018, Madalin-cristian Bucur wrote:
>> > 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=
.

>> ** 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
>>  =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.

>> 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.
>> =

>> 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