On 01/12/2018 08:22 AM, Madalin-cristian Bucur wrote:
-Original Message-
From: Linuxppc-dev [mailto:linuxppc-dev-
bounces+madalin.bucur=nxp@lists.ozlabs.org] On Behalf Of Jamie Krueger
Sent: Wednesday, January 10, 2018 5:57 PM
To: linuxppc-dev@lists.ozlabs.org
Subject: DPAA Ethernet problems with mainstream Linux kernels
Hello all @ linuxppc-dev,
I have been working with a team of people maintaining PowerPC
Linux for the new AmigaONE X5000/20 (a Freescale p5020 SoC based
machine).
We are trying to determine why the submitted Data Path Acceleration
Architecture (DPAA) Ethernet Driver is not fully functional with
the mainstream Linux kernels.
Hi Jamie,
Hi Madalin,
We are testing the DPAA driver on several DS and RDB platforms and it
is working properly. The issues you encounter with it on the X5000/20
are likely caused by some issues specific to that particular platform.
It is good to hear that the DPAA driver is functioning correctly
on the reference platforms. I am positive you are correct that
the issue is the difference in implementation on the X5000/20
(Cyrus) motherboard, as compared to the reference boards.
Can you verify which Linux Kernel sources your tests are being
performed on? We have been testing using the mainstream
Linux sources up to linux-4.15-rc6 thus far.
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.
The cyrus_p5020.eth.dts file, along with it's cyrus-pre.dtsi dependent
file, are an attempt to correctly define the Ethernet hardware, as it is
implemented on the X5000/20.
** 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.
I am not sure what PHY hardware/configuration you are using on the
DS and RDB platforms, but I can confirm that AmigaONE X5000/20
(Cyrus Motherboard with p5020 SoC), has dTSEC 4 and dTSEC 5
wired to two Micrel KSZ9021RN Gigabit Ethernet PHYs, using the
RGMII protocol.
I suggest
that you connect the DPAA interface to a traffic analyzer or directly
to another device on which you can capture the incoming traffic and
check that the received frames are correct.
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).
I will setup some more direct machine-to-machine testing to
see what else I can glean from the network traffic.
Please have a look at the attached dts files, maybe there is something
obvious there we are not seeing.
Also, given that the X5000/20 uses Micrel KSZ9021RN PHYs in RGMII
mode, what changes to the DPAA hardware configuration should we
expect to see so that the DPAA is configured to talk to them?
Madalin
--
Best Regards,
Jamie Krueger
BITbyBIT Software Group LLC
Here is the results from my latest tests. They were performed using
the linux-4.10.17 ppc64, since that represents when the DPAA Ethernet
code was introduced.
Similar tests, with similar results, were also performed
using the latest Linux kernels:
linux-4.15-rc5
linux-4.15-rc6
linux-4.15-rc7
(Hence the reason for falling back to test the kernel right
after the introduction of the DPAA Ethernet driver sources)
---
All Kernel builds had the DPAA Ethernet enabled in the kernel,
and are using the correct cyrus_p5020.eth.dtb device tree file
(for use on the X5000/20).
The results are quite similar for all kernels in regards to the DPAA
Ethernet.
All tested kernels setup the two Ethernet interfaces correctly
as eth0 and eth1, and pull the correct MAC addresses from U-Boot
environment variables ethaddr and eth1addr respectively.
So at this point Linux has what it believes is fully configured
hardware, waiting to have an IP Address/Netmask/Gateway
to be set and to bring the interface online
