DPAA Ethernet problems with mainstream Linux kernels

[Darren Stevens]

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 includes 'p5020si-pre.dtsi' and 'p5020si-post.dtsi' include files, which orginally 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 p5020si-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
>>       files with this email for comparison. Please let me know if you see
>>       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 shows 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=00000000
[  109.032808] fsl-pamu: pamu_av_isr: POES2=00000000
[  109.032809] fsl-pamu: pamu_av_isr: AVS1=002d0081
[  109.032811] fsl-pamu: pamu_av_isr: AVS2=00000081
[  109.032813] fsl-pamu: pamu_av_isr: AVA=00000001f1328000
[  109.032815] fsl-pamu: pamu_av_isr: UDAD=002d0001
[  109.032817] fsl-pamu: pamu_av_isr: POEA=0000000000000000

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

Regards
Darren