Kernel 4.15
Re: Kernel 4.15
Whoa.....
Are we realy going to see that X5000 onboard NIC working soon????
Would be great !
Keep it up
Are we realy going to see that X5000 onboard NIC working soon????
Would be great !
Keep it up
AmigaOne X5000 -> 2GHz / 16GB RAM / Radeon RX 570 / Radeon X1950 / M-Audio 5.1 -> AmigaOS / Linux
Amiga 1200 -> Recapped / 68ec020 ACA 1221ec / CF HDD / RetroNET connected to the world
Vampire 4SA - RPi4 Running AmiKitXE Full
Amiga 1200 -> Recapped / 68ec020 ACA 1221ec / CF HDD / RetroNET connected to the world
Vampire 4SA - RPi4 Running AmiKitXE Full
- JamieKrueger
- Beta Tester
- Posts: 13
- Joined: Mon Dec 20, 2010 7:15 pm
Re: Kernel 4.15
I made so new tests and extended this post - see MORE TEST RESULTS: below...
if we break this down a bit we can see another piece to the puzzle:
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).
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).
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):
Upon booting into Linux again (vmlinux-4.15-rc6-AmigaOne_X5000_with_QorIQ_DPAA_Ethernet_driver)
I got the following results:
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.
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).
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:
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.
Here are my findings in testing the latest 4.15-rc6 kernel with DPAA Ethernet enabled,xeno74 wrote: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
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 <---
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
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
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
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
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
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
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
PHYs on the Cyrus board, but it would appear we can assign MAC addresses
to be used to get the interface itself setup.
Best Regards,
Jamie Krueger
BITbyBIT Software Group LLC
Jamie Krueger
BITbyBIT Software Group LLC
Re: Kernel 4.15
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.JamieKrueger wrote: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).
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)
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.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).
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.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).
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.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 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
- Beta Tester
- Posts: 13
- Joined: Mon Dec 20, 2010 7:15 pm
Re: Kernel 4.15
That was my understanding as well, that the MACs are supposed to be programmedPartially 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.
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.
Yes, I have looked at the MAC command before as it would seemView 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)
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
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]
key was to first program the number of ports
to reflect what this machine has:
Code: Select all
X5000> mac ports 2
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
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
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
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.
Thanks for the insight. I would like to help fix the problem, or at the very least toLinux 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.
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.
In the linux-4.15-rc6 sources you can find CONFIG_FSL_DPAA2_ETH used to bring inI'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.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 just checked my 4.11 tree, and can only find DPAA ethernet under network drivers.
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.
Thanks.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
Best Regards,
Jamie Krueger
BITbyBIT Software Group LLC
Jamie Krueger
BITbyBIT Software Group LLC
Re: Kernel 4.15
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.
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.
AmigaOne X5000 -> 2GHz / 16GB RAM / Radeon RX 570 / Radeon X1950 / M-Audio 5.1 -> AmigaOS / Linux
Amiga 1200 -> Recapped / 68ec020 ACA 1221ec / CF HDD / RetroNET connected to the world
Vampire 4SA - RPi4 Running AmiKitXE Full
Amiga 1200 -> Recapped / 68ec020 ACA 1221ec / CF HDD / RetroNET connected to the world
Vampire 4SA - RPi4 Running AmiKitXE Full
- JamieKrueger
- Beta Tester
- Posts: 13
- Joined: Mon Dec 20, 2010 7:15 pm
Re: Kernel 4.15
The U-Boot environment variables (ethaddr and eth1addr) are setSkateman wrote: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.
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?
Best Regards,
Jamie Krueger
BITbyBIT Software Group LLC
Jamie Krueger
BITbyBIT Software Group LLC
Re: Kernel 4.15
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 ?
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 ?
AmigaOne X5000 -> 2GHz / 16GB RAM / Radeon RX 570 / Radeon X1950 / M-Audio 5.1 -> AmigaOS / Linux
Amiga 1200 -> Recapped / 68ec020 ACA 1221ec / CF HDD / RetroNET connected to the world
Vampire 4SA - RPi4 Running AmiKitXE Full
Amiga 1200 -> Recapped / 68ec020 ACA 1221ec / CF HDD / RetroNET connected to the world
Vampire 4SA - RPi4 Running AmiKitXE Full
Re: Kernel 4.15
Hi All,
I released the RC7 for the X5000 and X1000 today.
New:
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
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
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
Last edited by xeno74 on Mon Jan 08, 2018 7:56 pm, edited 1 time in total.
http://www.amigalinux.org
http://www.supertuxkart-amiga.de
Running Linux on AmigaONEs can require some tinkering.
http://www.supertuxkart-amiga.de
Running Linux on AmigaONEs can require some tinkering.
Re: Kernel 4.15
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.
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.
AmigaOne X5000 -> 2GHz / 16GB RAM / Radeon RX 570 / Radeon X1950 / M-Audio 5.1 -> AmigaOS / Linux
Amiga 1200 -> Recapped / 68ec020 ACA 1221ec / CF HDD / RetroNET connected to the world
Vampire 4SA - RPi4 Running AmiKitXE Full
Amiga 1200 -> Recapped / 68ec020 ACA 1221ec / CF HDD / RetroNET connected to the world
Vampire 4SA - RPi4 Running AmiKitXE Full
Re: Kernel 4.15
Hi Skateman,Skateman wrote: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.
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
http://www.amigalinux.org
http://www.supertuxkart-amiga.de
Running Linux on AmigaONEs can require some tinkering.
http://www.supertuxkart-amiga.de
Running Linux on AmigaONEs can require some tinkering.