Kernel 4.15

[Skateman]

Whoa.....

Are we realy going to see that X5000 onboard NIC working soon????

Would be great !

Keep it up

[JamieKrueger]

I made so new tests and extended this post - see MORE TEST RESULTS: below...

The RC6 with the QorIQ DPAA Ethernet driver: vmlinux-4.15-rc6-AmigaOne_X5000_with_QorIQ_DPAA_Ethernet_driver.tar.gz

I enabled the following options in the kernel config:

# common for arch/arm64 and arch/powerpc platforms
CONFIG_FSL_DPAA=y
CONFIG_FSL_FMAN=y
CONFIG_FSL_DPAA_ETH=y
CONFIG_FSL_XGMAC_MDIO=y

# for arch/powerpc only
CONFIG_FSL_PAMU=y

# common options needed for the PHYs used on the RDBs
CONFIG_VITESSE_PHY=y
CONFIG_REALTEK_PHY=y
CONFIG_AQUANTIA_PHY=y

In my point of view we need the Microchip PHY additionally because we have two Microchip KSZ9021RN PHY on the Cyrus board.

CONFIG_MICROCHIP_PHY=y

It seems the kernel has detected the QorIQ DPAA Ethernet but it can't get a mac address:

Code: Select all

[   11.657796] fsl_dpaa_mac ffe4e0000.ethernet: of_get_mac_address(/soc@ffe000000/fman@400000/ethernet@e0000) failed
[   11.658015] fsl_dpaa_mac: probe of ffe4e0000.ethernet failed with error -22
[   11.658191] fsl_dpaa_mac ffe4e2000.ethernet: of_get_mac_address(/soc@ffe000000/fman@400000/ethernet@e2000) failed
[   11.658396] fsl_dpaa_mac: probe of ffe4e2000.ethernet failed with error -22
[   11.658571] fsl_dpaa_mac ffe4e4000.ethernet: of_get_mac_address(/soc@ffe000000/fman@400000/ethernet@e4000) failed
[   11.658775] fsl_dpaa_mac: probe of ffe4e4000.ethernet failed with error -22
[   11.658960] fsl_dpaa_mac ffe4e6000.ethernet: of_get_mac_address(/soc@ffe000000/fman@400000/ethernet@e6000) failed
[   11.659164] fsl_dpaa_mac: probe of ffe4e6000.ethernet failed with error -22
[   11.659339] fsl_dpaa_mac ffe4e8000.ethernet: of_get_mac_address(/soc@ffe000000/fman@400000/ethernet@e8000) failed
[   11.659544] fsl_dpaa_mac: probe of ffe4e8000.ethernet failed with error -22
[   11.659715] fsl_dpaa_mac ffe4f0000.ethernet: of_get_mac_address(/soc@ffe000000/fman@400000/ethernet@f0000) failed
[   11.659920] fsl_dpaa_mac: probe of ffe4f0000.ethernet failed with error -22

Here are my findings in testing the latest 4.15-rc6 kernel with DPAA Ethernet enabled,
if we break this down a bit we can see another piece to the puzzle:

Code: Select all

[    4.725927] fsl_dpaa_mac ffe4e0000.ethernet: of_get_phy_mode() for /soc@ffe000000/fman@400000/ethernet@e0000 failed. Defaulting to SGMII
[    4.730627] fsl_dpaa_mac ffe4e0000.ethernet: FMan dTSEC version: 0x08240101
[    4.735239] fsl_dpaa_mac ffe4e0000.ethernet: FMan MAC address: 00:80:10:12:34:56  <---

[    4.739791] fsl_dpaa_mac ffe4e2000.ethernet: of_get_phy_mode() for /soc@ffe000000/fman@400000/ethernet@e2000 failed. Defaulting to SGMII
[    4.744409] fsl_dpaa_mac ffe4e2000.ethernet: FMan dTSEC version: 0x00000000
[    4.749250] fsl_dpaa_mac ffe4e2000.ethernet: FMan MAC address: 00:80:10:78:9a:bc  <---

Here the Linux driver *is* getting the MAC addresses from the U-Boot variables.
I know this because I set those MAC addresses myself (I made them up from old
Commodore 00:80:10 Manufacturer IDs), and on my machine they do not exist
in the Flash.

A NOTE about MAC addresses in the X5000/20:

At the AmiWest show this year we determined that while the beta test
run of X5000/20 boards had their MAC addresses set in flash, (and hence
U-Boot would pick them up if the two U-Boot variables 'ethaddr' and
'eth1addr' were blank), this is not the case with production versions
of the Cyrus board. Therefore if blanking your MAC addresses in
U-Boot does not bring up a set from the Flash, then you need to set
the ethaddr and eth1addr variables in U-Boot yourself.

(And if they are already set, then by all means write them down,
as you may have to reprogram them yourself after a U-Boot upgrade.
Do not trust that they will return on their own).

Code: Select all

[    4.754019] fsl_dpaa_mac ffe4e4000.ethernet: of_get_mac_address(/soc@ffe000000/fman@400000/ethernet@e4000) failed
[    4.758787] fsl_dpaa_mac: probe of ffe4e4000.ethernet failed with error -22

[    4.763563] fsl_dpaa_mac ffe4e6000.ethernet: of_get_mac_address(/soc@ffe000000/fman@400000/ethernet@e6000) failed
[    4.768474] fsl_dpaa_mac: probe of ffe4e6000.ethernet failed with error -22

[    4.773464] fsl_dpaa_mac ffe4e8000.ethernet: of_get_mac_address(/soc@ffe000000/fman@400000/ethernet@e8000) failed
[    4.778584] fsl_dpaa_mac: probe of ffe4e8000.ethernet failed with error -22

However, while it is getting both MAC addresses, Linux is setting them for the *wrong*
set of dTSECs. On the Cyrus board, only dTSEC4 (ffe4e6000) and dTSEC5 (ffe4e8000)
are actually wired externally to the Microchip KSZ9021RN PHYs.

The programming of the all the PHYs is done through dTSEC1 (ffe4e0000)'s configuration
space within the Frame Manager (FMAN); so dTSEC1 needs to remain enabled, while
dTSECs 2 and 3 could be disabled (and are under U-Boot).

Code: Select all

[    4.783798] fsl_dpaa_mac ffe4f0000.ethernet: of_get_mac_address(/soc@ffe000000/fman@400000/ethernet@f0000) failed
[    4.789177] fsl_dpaa_mac: probe of ffe4f0000.ethernet failed with error -22

[    4.796633] fsl_dpaa_mac ffe4e0000.ethernet eth0: Probed interface eth0
[    4.804002] fsl_dpaa_mac ffe4e2000.ethernet eth1: Probed interface eth1

[   29.206219] fsl_dpaa_mac ffe4e0000.ethernet eth0: init_phy() failed
[   29.240677] fsl_dpaa_mac ffe4e2000.ethernet eth1: init_phy() failed

Finally, having a MAC address configured for dTSEC1 and dTSEC2 and
failing to find any others for dTSECs 2-5, the Linux driver tries to init
the PHYs under eth0 and eth1. It fails of course because there is no
PHYs wired to those ports.

So what we need is to get the DPAA code for the Cyrus set to target
and configure the correct dTSECs (4 & 5), and setup to talk to them
using RGMII mode (since that is the way these PHYs are configured
by default).

Another note:

Looking at the config file for this build,
only DPAA and DPAA_ETH, and not DPAA2 and
DPAA2_ETH have been enabled. It is my understanding
that the p5020 supports DPAA version 2, specifically
it supports; FMan 3.0, QMan 1.2, BMan 1.0, SEC 4.2, PME 2.1, RMan 1.0, and RE 1.0.

EDIT: I recall seeing a chart of the QorIQ processors which noted the p5020 having
DPAA 2.x, however I am still trying to track that down to verify it. So as of right now,
the requirement for DPAA2 and DPAA2_ETH flags in the kernel build for the
p5020 have not been verified.

MORE TEST RESULTS:

Looking at the way the Linux driver was picking up the MAC addresses for
dTSEC1 and dTSEC2 from the U-Boot variables 'ethaddr' and 'eth1addr',
it appeared to be scanning for 'eth<n>addr' environment variable names
where <n> was the based on the enumeration of each dTSEC.

So, I tested this by expanding the set of environment variables within
U-Boot as follows (again making up some MAC addresses based on
the old Commodore IDs):

Code: Select all

setenv eth2addr 00:80:10:11:22:33
setenv eth3addr 00:80:10:44:55:66
setenv eth4addr 00:80:10:77:88:99
saveenv

Upon booting into Linux again (vmlinux-4.15-rc6-AmigaOne_X5000_with_QorIQ_DPAA_Ethernet_driver)
I got the following results:

Code: Select all

[    4.756682] fsl_dpaa_mac ffe4e0000.ethernet: of_get_phy_mode() for /soc@ffe000000/fman@400000/ethernet@e0000 failed. Defaulting to SGMII
[    4.761407] fsl_dpaa_mac ffe4e0000.ethernet: FMan dTSEC version: 0x08240101
[    4.766518] fsl_dpaa_mac ffe4e0000.ethernet: FMan MAC address: 00:80:10:12:34:56
[    4.771128] fsl_dpaa_mac ffe4e2000.ethernet: of_get_phy_mode() for /soc@ffe000000/fman@400000/ethernet@e2000 failed. Defaulting to SGMII
[    4.775786] fsl_dpaa_mac ffe4e2000.ethernet: FMan dTSEC version: 0x00000000
[    4.780641] fsl_dpaa_mac ffe4e2000.ethernet: FMan MAC address: 00:80:10:78:9a:bc
[    4.785472] fsl_dpaa_mac ffe4e4000.ethernet: of_get_phy_mode() for /soc@ffe000000/fman@400000/ethernet@e4000 failed. Defaulting to SGMII
[    4.790418] fsl_dpaa_mac ffe4e4000.ethernet: FMan dTSEC version: 0x00000000
[    4.795432] fsl_dpaa_mac ffe4e4000.ethernet: FMan MAC address: 00:80:10:11:22:33
[    4.800466] fsl_dpaa_mac ffe4e6000.ethernet: of_get_phy_mode() for /soc@ffe000000/fman@400000/ethernet@e6000 failed. Defaulting to SGMII
[    4.805795] fsl_dpaa_mac ffe4e6000.ethernet: FMan dTSEC version: 0x08240101
[    4.811009] fsl_dpaa_mac ffe4e6000.ethernet: FMan MAC address: 00:80:10:44:55:66
[    4.816198] fsl_dpaa_mac ffe4e8000.ethernet: of_get_phy_mode() for /soc@ffe000000/fman@400000/ethernet@e8000 failed. Defaulting to SGMII
[    4.821783] fsl_dpaa_mac ffe4e8000.ethernet: FMan dTSEC version: 0x08240101
[    4.827225] fsl_dpaa_mac ffe4e8000.ethernet: FMan MAC address: 00:80:10:77:88:99

As predicted the Linux driver proceeded to pick up the MAC addresses set using
the eth<n>addr format. So this gives us a way to set the MAC addresses for the
two dTSECs we actually need; using 'eth3addr' and 'eth4addr' to set dTSEC4
and dTSEC5 respectively.

Code: Select all

[    4.832489] fsl_dpaa_mac ffe4f0000.ethernet: of_get_mac_address(/soc@ffe000000/fman@400000/ethernet@f0000) failed
[    4.837809] fsl_dpaa_mac: probe of ffe4f0000.ethernet failed with error -22
[    4.845259] fsl_dpaa_mac ffe4e0000.ethernet eth0: Probed interface eth0
[    4.852648] fsl_dpaa_mac ffe4e2000.ethernet eth1: Probed interface eth1
[    4.860011] fsl_dpaa_mac ffe4e4000.ethernet eth2: Probed interface eth2
[    4.867349] fsl_dpaa_mac ffe4e6000.ethernet eth3: Probed interface eth3
[    4.874654] fsl_dpaa_mac ffe4e8000.ethernet eth4: Probed interface eth4
[   30.820058] fsl_dpaa_mac ffe4e2000.ethernet eth1: init_phy() failed
[   30.843447] fsl_dpaa_mac ffe4e8000.ethernet eth4: init_phy() failed
[   30.870990] fsl_dpaa_mac ffe4e4000.ethernet eth2: init_phy() failed
[   31.169444] fsl_dpaa_mac ffe4e0000.ethernet eth0: init_phy() failed
[   31.197328] fsl_dpaa_mac ffe4e6000.ethernet eth3: init_phy() failed

The problem of the Linux driver not knowing which PHYs to connect
to the respective interfaces still exists however, as you can see the
init_phy() calls still fail for all interfaces (even those with actual PHYs).

Code: Select all

$ ifconfig -a

eth0      Link encap:Ethernet  HWaddr 00:80:10:12:34:56  
          BROADCAST MULTICAST  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)
          Memory:fe4e0000-fe4e0fff 

eth1      Link encap:Ethernet  HWaddr 00:80:10:78:9a:bc  
          BROADCAST MULTICAST  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)
          Memory:fe4e2000-fe4e2fff 

eth2      Link encap:Ethernet  HWaddr 00:80:10:11:22:33  
          BROADCAST MULTICAST  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)
          Memory:fe4e4000-fe4e4fff 

eth3      Link encap:Ethernet  HWaddr 00:80:10:44:55:66  
          BROADCAST MULTICAST  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)
          Memory:fe4e6000-fe4e6fff 

eth4      Link encap:Ethernet  HWaddr 00:80:10:77:88:99  
          BROADCAST MULTICAST  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)
          Memory:fe4e8000-fe4e8fff 

To further demonstrate that Linux is in fact setting up the
interfaces, I did a 'ifconfig -a' output (above), and you can
see we now have a full set of interfaces (eth0 - eth4).

Since the PHY connections are still not there, if you try
to put one of the interfaces online you see the following:

Code: Select all

$ sudo ifconfig eth3 192.168.1.10/24 up

SIOCSIFFLAGS: No such device
SIOCSIFFLAGS: No such device

So we still need to get the Linux driver to configure and use the installed
PHYs on the Cyrus board, but it would appear we can assign MAC addresses
to be used to get the interface itself setup.

[daz]

I made so new tests and extended this post - see MORE TEST RESULTS: below...

Here the Linux driver *is* getting the MAC addresses from the U-Boot variables.
I know this because I set those MAC addresses myself (I made them up from old
Commodore 00:80:10 Manufacturer IDs), and on my machine they do not exist
in the Flash.

A NOTE about MAC addresses in the X5000/20:

At the AmiWest show this year we determined that while the beta test
run of X5000/20 boards had their MAC addresses set in flash, (and hence
U-Boot would pick them up if the two U-Boot variables 'ethaddr' and
'eth1addr' were blank), this is not the case with production versions
of the Cyrus board. Therefore if blanking your MAC addresses in
U-Boot does not bring up a set from the Flash, then you need to set
the ethaddr and eth1addr variables in U-Boot yourself.

(And if they are already set, then by all means write them down,
as you may have to reprogram them yourself after a U-Boot upgrade.
Do not trust that they will return on their own).

Partially correct, there is an serial eeprom on the board with the MAC addresses in(IIRC), this is separate to the uboot SD card, but it seems wasn't programmed with MAC addresses on end user boards. This is where U-Boot gets its MAC addresses from if you haven't programmed the U-Boot variables.

View the contents of the rom by the U-Boot 'MAC' command.

There should be 2 entrys 'Eth0' and 'Eth1' just before the CRC line.

The help seems to indicate you can set them from the U-Boot console (help mac)

However, while it is getting both MAC addresses, Linux is setting them for the *wrong*
set of dTSECs. On the Cyrus board, only dTSEC4 (ffe4e6000) and dTSEC5 (ffe4e8000)
are actually wired externally to the Microchip KSZ9021RN PHYs.

The programming of the all the PHYs is done through dTSEC1 (ffe4e0000)'s configuration
space within the Frame Manager (FMAN); so dTSEC1 needs to remain enabled, while
dTSECs 2 and 3 could be disabled (and are under U-Boot).

Linux looks in the device tree to see which ethernet ports to attach. On the earlier kernels (based on the SDK) we had no problems, as the aliases used to link dTSEC's to eth ports was in the board description file, however at some point Freescale moved the p5020 board aliases to the p5020si-pre.dtsi file, which messes up our system as we include that too meaning conflicts.

I did try and replace the aliasa, but still had problems getting the ethernet to work.

Finally, having a MAC address configured for dTSEC1 and dTSEC2 and
failing to find any others for dTSECs 2-5, the Linux driver tries to init
the PHYs under eth0 and eth1. It fails of course because there is no
PHYs wired to those ports.

So what we need is to get the DPAA code for the Cyrus set to target
and configure the correct dTSECs (4 & 5), and setup to talk to them
using RGMII mode (since that is the way these PHYs are configured
by default).

We need to get the device tree fixed, that's where the problem is. I have more spare time now, and hope to have another look.

Looking at the config file for this build,
only DPAA and DPAA_ETH, and not DPAA2 and
DPAA2_ETH have been enabled. It is my understanding
that the p5020 supports DPAA version 2, specifically
it supports; FMan 3.0, QMan 1.2, BMan 1.0, SEC 4.2, PME 2.1, RMan 1.0, and RE 1.0.

I've never seen DPAA2 in any kernel config, I always just enabled DPAA, which as I've mentioned back around 3.12 or so were working.

I've just checked my 4.11 tree, and can only find DPAA ethernet under network drivers.

I will see if I can get time to find a way of making them work in the next couple of weeks..

Ask if there is anything else I can help with.

Regards
Darren

[JamieKrueger]

Partially correct, there is an serial eeprom on the board with the MAC addresses in(IIRC), this is separate to the uboot SD card, but it seems wasn't programmed with MAC addresses on end user boards. This is where U-Boot gets its MAC addresses from if you haven't programmed the U-Boot variables.

That was my understanding as well, that the MACs are supposed to be programmed
into static storage outside of the SD card that contains U-Boot, etc. but in the case of
production machines like mine, the programming step was omitted for unknown reasons.
Perhaps I did not explain myself clearly enough. Anyway, thanks for clarifying the point.

View the contents of the rom by the U-Boot 'MAC' command.

There should be 2 entrys 'Eth0' and 'Eth1' just before the CRC line.

The help seems to indicate you can set them from the U-Boot console (help mac)

Yes, I have looked at the MAC command before as it would seem
to be the answer to setting the MAC addresses outside of the U-Boot
variables. However I have not had much success in using it.

Here is what I get on my X5000/20 from the MAC command

Code: Select all

X5000> mac
ID: NXID v0
SN: 116340024
UID: 4429431001910051acd0a080a0800000
Errata: ����� '�
Build date: 2015/07/20 16:27:16 
CRC: 66ff2e89

As you noted, there should be two entries (Eth0 & Eth1)
listed before the CRC, but of course they are missing.

Now, perhaps even more frustrating, is that fact I have
had zero success in actually programming the MACs
(and having them stick that is).

A 'help mac' command output looks like this:

Code: Select all

X5000> help mac
mac - display and program the system ID and MAC addresses in EEPROM

Usage:
mac [read|save|id|num|errata|date|ports|0|1|2|3|4|5|6|7]
mac read
    - read EEPROM content into memory
mac save
    - save to the EEPROM
mac id
    - program system id
mac num
    - program system serial number
mac errata
    - program errata data
mac date
    - program date
mac ports
    - program the number of ports
mac X
    - program the MAC address for port X [X=0...7]

Now following this command template, I found the
key was to first program the number of ports
to reflect what this machine has:

Code: Select all

X5000> mac ports 2

Now echoing out the MAC again I get the following:

Code: Select all

X5000> mac
ID: NXID v0
SN: 116340024
UID: 4429431001910051acd0a080a0800000
Errata: ����� '�
Build date: 2015/07/20 16:27:16 
Eth0: ff:ff:ff:ff:ff:ff
Eth1: ff:ff:ff:ff:ff:ff
CRC: d9255de6

Now, the missing Eth0 and Eth1 are back,
so I proceed to program them to something:

Code: Select all

X5000> mac 0 00:80:10:11:11:11
X5000> mac 1 00:80:10:22:22:22

..and echo the MAC again:

Code: Select all

X5000> mac
ID: NXID v0
SN: 116340024
UID: 4429431001910051acd0a080a0800000
Errata: ����� '�
Build date: 2015/07/20 16:27:16 
Eth0: 00:80:10:11:11:11
Eth1: 00:80:10:22:22:22
CRC: b5ec1b2a

Great, we now have some MAC addresses set,
so let's try to save them back to the EEPROM:

Code: Select all

X5000> mac save
Programming failed.

Here is where it all falls apart of course, the new values
are never saved back to the EEPROM, and so the U-Boot
initialization has nothing to pickup and set it's 'ethaddr'
and 'eth1addr' variables to.

Assuming the EEPROM write code within U-Boot's MAC
command is functional, then I figure something else is blocking
the writes.

Is there a jumper on the motherboard that needs to be set
to allow writes back to the EEPROM (for example)?

Does anyone know how to get 'mac save' to work, I have
not found anything in the X5000 Reference Manual that
talks about setting this EEPROM.

Linux looks in the device tree to see which ethernet ports to attach. On the earlier kernels (based on the SDK) we had no problems, as the aliases used to link dTSEC's to eth ports was in the board description file, however at some point Freescale moved the p5020 board aliases to the p5020si-pre.dtsi file, which messes up our system as we include that too meaning conflicts.

I did try and replace the aliasa, but still had problems getting the ethernet to work.

We need to get the device tree fixed, that's where the problem is. I have more spare time now, and hope to have another look.

Thanks for the insight. I would like to help fix the problem, or at the very least to
understand what the Linux driver system needs to have to align the use of
DPAA Ethernet on the Cyrus board.

So if you fix it, please share the exact changes you made to the configuration
and or linux sources to get the 4.15-rc6 kernel working. Thanks.

It is my understanding that the p5020 supports DPAA version 2, specifically
it supports; FMan 3.0, QMan 1.2, BMan 1.0, SEC 4.2, PME 2.1, RMan 1.0, and RE 1.0.

I've never seen DPAA2 in any kernel config, I always just enabled DPAA, which as I've mentioned back around 3.12 or so were working.

I've just checked my 4.11 tree, and can only find DPAA ethernet under network drivers.

In the linux-4.15-rc6 sources you can find CONFIG_FSL_DPAA2_ETH used to bring in
drivers/staging/fsl-dpaa2/ethernet/fsl-dpaa2-eth.o

However, I have not been able to confirm that the p5020 makes use of DPAA v2.x as
yet, which is why I edited my original post.

I am sure the Ethernet would be functional on the Cyrus under the DPAA 1.x code;
as you say, it was working before.

I will see if I can get time to find a way of making them work in the next couple of weeks..

Ask if there is anything else I can help with.

Regards
Darren

Thanks.

[Skateman]

Mabey it just needs to be included in the ENV like shown below...
I found this example in an NXP community.

e.g. :
=> setenv eth1addr xx:xx:xx:xx
=> saveenv
Change the number in eth1 according to the
interface number you are trying to set the mac
for.

[JamieKrueger]

Mabey it just needs to be included in the ENV like shown below...
I found this example in an NXP community.

e.g. :
=> setenv eth1addr xx:xx:xx:xx
=> saveenv
Change the number in eth1 according to the
interface number you are trying to set the mac
for.

The U-Boot environment variables (ethaddr and eth1addr) are set
successfully, and they do get picked up by the Linux Ethernet
driver as well. I have tested setting eth3addr, eth4addr, etc. and
they do get picked up and assigned to dTSEC3, 4, ... as
to eth2, eth3, respectively within Linux.

Unfortunately, on the X5000/20 at least, this does not entirely
solve the problem. Something else is still not aligned correctly to
enable the Data Path Acceleration Architecture (DPAA) Ethernet
driver to work on the X5000/20 (using the mainstream Linux kernels).

I have been testing with the p5020.eth.dtb file that Darren put
together, which more properly instructs Linux to map dTSEC 4
and dTSEC 5 (the only two external ports on the machine),
as eth0 and eth1 within Linux (and ignoring the other Ethernet
controllers which are not wired to the outside). This also allows
Linux to map the MAC Addresses for 'eth0' and 'eth1' from
'ethaddr' and 'eth1addr' (the only two the U-Boot expects to
see -- and displays on the sysinfo page).

Again, while the new .dtb file fixes the MAC-to-Interface
mapping issues, something else is still wrong, as I can
place the interface(s) online, but no network traffic is
reaching the outside world. It would appear that something
is still not mapped or configure correctly, or maybe we are
still missing the proper PHY code pieces?

[Skateman]

but no network traffic is
reaching the outside world

Is there local network traffic ? Not reaching the outside world could be a routing issue.
Or are there just no packets going through the ethernet adapter ?

[xeno74]

Hi All,

I released the RC7 for the X5000 and X1000 today.

New:

• X5000: Cyrus eth dtb added - Thanks to Darren
• X5000: QorIQ DPAA Ethernet driver added
• PowerPC fix 4.15-6
• Linux 4.15-rc7 Kernel Released --phoronix
• Linus Torvalds release announcement
• Linux Git log
• Phoronix articles, reviews and news stories covering Linux 4.15

Download: vmlinux-4.15-rc7-AmigaOne_X1000_X5000.tar.gz

BTW, I was able to compile the new NetSurf 3.7 today. Screenshot of ubuntu MATE 16.04.3 LTS PowerPC with the new kernel 4.15-rc7 and with the new NetSurf 3.7:



Please test the RC7.

Edit: If you want to test the QorIQ DPAA Ethernet then please use the Cyrus eth dtb instead of the default Cyrus dtb file.

Thanks,
Christian

[Skateman]

Just a question..

Do i use the cyrus.eth.dtb instead of the cyrus_p5020.dtb or do i just add the cyrus.eth.dtb extra ?
Looking forward to test this build.

[xeno74]

Just a question..

Do i use the cyrus.eth.dtb instead of the cyrus_p5020.dtb or do i just add the cyrus.eth.dtb extra ?
Looking forward to test this build.

Hi Skateman,

If you want to test the QorIQ DPAA Ethernet then please use the Cyrus eth dtb instead of the default Cyrus dtb file.

Thanks,
Christian