Kernel 4.15
Re: Kernel 4.15
Ok.... the RC7 is up and running...
First test without any Uboot editing... so no MAC adresses set, this is the output..
As expected no ethernet adapters probed...
After Uboot editing setenv ethaddr (mac adress) and setenv eth1addr (mac adress) this is the output.
The ETH0 and ETH1 are probed, and appear in Ubuntu. They still have the disconnected status but progress is being made
First test without any Uboot editing... so no MAC adresses set, this is the output..
As expected no ethernet adapters probed...
After Uboot editing setenv ethaddr (mac adress) and setenv eth1addr (mac adress) this is the output.
The ETH0 and ETH1 are probed, and appear in Ubuntu. They still have the disconnected status but progress is being made
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
A little bit more info.
ETH0 connected by setting up the ip manualy.. the interface seems to do nothing with DHCP.
Unable to ping any machine in the network.
DMESG gives me the following information.
Few things i dont understand yet...
Why is the onboard Cyrus nic seen as a dual NIC ??
In the screenschot fsl_dpaa_mac probes that fail go to ffe4e0000.ethernet ffe4e2000.ethernet ffe4e4000.ethernet and again ffe4f0000.ethernet..
Should these not be something like ffe4e6000 and ffe4e8000 ??
ETH0 connected by setting up the ip manualy.. the interface seems to do nothing with DHCP.
Unable to ping any machine in the network.
DMESG gives me the following information.
Few things i dont understand yet...
Why is the onboard Cyrus nic seen as a dual NIC ??
In the screenschot fsl_dpaa_mac probes that fail go to ffe4e0000.ethernet ffe4e2000.ethernet ffe4e4000.ethernet and again ffe4f0000.ethernet..
Should these not be something like ffe4e6000 and ffe4e8000 ??
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
- caseycullen
- Posts: 521
- Joined: Sat Dec 17, 2016 7:12 am
- Location: Madison, WI USA
- Contact:
Re: Kernel 4.15
Hi Christian!
I was able to successfully test 4.15-RC7. I did not try the onboard Ethernet driver.
Did you try to compile NetSurf with video support? I have not been able to since they utilize depreciated gstreamer dependencies. I don't think they're interested in fixing it because it looks like it has been broken since 2013. It would be good to have another browser with video support though. http://bugs.netsurf-browser.org/mantis/ ... ug_id=1872
Thanks for releasing RC7!
---Casey
I was able to successfully test 4.15-RC7. I did not try the onboard Ethernet driver.
Did you try to compile NetSurf with video support? I have not been able to since they utilize depreciated gstreamer dependencies. I don't think they're interested in fixing it because it looks like it has been broken since 2013. It would be good to have another browser with video support though. http://bugs.netsurf-browser.org/mantis/ ... ug_id=1872
Thanks for releasing RC7!
---Casey
xeno74 wrote:Hi All,
I released the RC7 for the X5000 and X1000 today.
New:
Download: vmlinux-4.15-rc7-AmigaOne_X1000_X5000.tar.gz
- 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
Re: Kernel 4.15
Hi Skateman,
Hi Casey,
Many thanks for testing the RC7 on your X5000.
FYI: Cyrus Plus Block Diagram:
We haven't modified the DPAA Ethernet driver yet. I just added it to the default 4.15 kernel for testing. I figured out that the DPAA Ethernet driver has only been available since kernel 4.10. This driver isn't available for older kernels like 4.9, 4.8, etc. Maybe they didn't test it after the integration. I don't know. Maybe we have to compile the first kernel with DPAA Ethernet support and test it if this works. Maybe the issue is only present in newer kernels.
Cheers,
Christian
Hi Casey,
Many thanks for testing the RC7 on your X5000.
I thought that it only probes two network interfaces because of the new Cyrus eth dtb.Skateman wrote: Why is the onboard Cyrus nic seen as a dual NIC ??
In the screenschot fsl_dpaa_mac probes that fail go to ffe4e0000.ethernet ffe4e2000.ethernet ffe4e4000.ethernet and again ffe4f0000.ethernet..
Should these not be something like ffe4e6000 and ffe4e8000 ??
FYI: Cyrus Plus Block Diagram:
We haven't modified the DPAA Ethernet driver yet. I just added it to the default 4.15 kernel for testing. I figured out that the DPAA Ethernet driver has only been available since kernel 4.10. This driver isn't available for older kernels like 4.9, 4.8, etc. Maybe they didn't test it after the integration. I don't know. Maybe we have to compile the first kernel with DPAA Ethernet support and test it if this works. Maybe the issue is only present in newer kernels.
No, I didn't but it sounds interesting.caseycullen wrote:Hi Christian!
Did you try to compile NetSurf with video support?
Cheers,
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.
Re: Kernel 4.15
I have tried to get the Ethernet interface working but somehow it refuses to ping other machines in my network.
I have used the ethtool en mii-tool and all seems working.
I can use several commands like adjusting the speed, duplex and so on. The interface seems to listen to these commands.
Are the latest drivers present in the kernel?
Will continue to do some more digging tomorrow.
I have used the ethtool en mii-tool and all seems working.
I can use several commands like adjusting the speed, duplex and so on. The interface seems to listen to these commands.
Are the latest drivers present in the kernel?
Will continue to do some more digging tomorrow.
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
So far I have tested the following (All tests done on X5000/20):
linux-4.9.70
linux-4.10.17
linux-4.15-rc5
linux-4.15-rc6
linux-4.15-rc7
All with the DPAA Ethernet enabled in the kernel,
and using the correct cyrus_p5020.eth.dtb device
tree file (also known as cyrus.eth.dtb in the latest
public test builds --same file.)
The results are quite similar in regards to the DPAA Ethernet.
With the exception of 4.9.70 which is missing support in the kernel,
all other 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.
However, all attempts to communicate with the outside world
do not make it out the physical (PHY) hardware - or do they?
When I bring the interface up using a static address, in this case
192.168.1.21, I see the following (NOTE TX bytes says 154.0 KB,
while RX bytes says 0.0 B):
Checking the routing table, everything looks fine there:
Attempting to PING the interface itself works:
However, attempts to PING the gateway (192.168.1.1) fail as unreachable:
In order to take a closer look at what is going on I installed Wireshark
both on my test X5000/20 Linux install (Ubuntu 16.04.3 LTS), and on
another Linux box connected to the same network switch (in this case
at IP address 192.168.1.210)
In this test I start the capture on eth0 (X5000/20) before it is put online,
and attempt to bring it up using DHCP to obtain it's address.
What I found was that network traffic *was* being attempted over eth0.
Here is a plain text export of the transmit side (the X5000/20) that
was captured using Wireshark.
(There were more network packets being sent from the X5000/20,
however, I am only showing DHCP traffic to save space in this post):
Now, over on the external Linux machine (192.168.1.210), I setup a Wireshark capture
which filtered for any traffic to/from the MAC address of the X5000/20's eth0, in this case
shown as Commodor_11:11:11 (00:80:10:11:11:11) below:
This export shows only the DHCP traffic seen from outside the X5000/20,
and as you can see, a matching set of DHCP requests *do in fact* make
it to the outside network.
The odd thing here is that while the DHCP requests were broadcast to the
outside network (confirming that at least the transmit to the PHY is working),
I could see no responses from my network's DHCP server to answer these
requests.
It is not a physical networking or routing issue, as I always get a successful
DHCP response to the X5000/20 when I enable the Realtek 8169 interface.
Since initial outgoing traffic *appears* to be working from the DPAA Ethernet
on the X5000/20, is it possible we are missing an interrupt mapping from the
Frame Manager to catch the received data?
linux-4.9.70
linux-4.10.17
linux-4.15-rc5
linux-4.15-rc6
linux-4.15-rc7
All with the DPAA Ethernet enabled in the kernel,
and using the correct cyrus_p5020.eth.dtb device
tree file (also known as cyrus.eth.dtb in the latest
public test builds --same file.)
The results are quite similar in regards to the DPAA Ethernet.
With the exception of 4.9.70 which is missing support in the kernel,
all other 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.
However, all attempts to communicate with the outside world
do not make it out the physical (PHY) hardware - or do they?
** The following results were captured under linux-4.10.17 **Skateman wrote: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 ?
When I bring the interface up using a static address, in this case
192.168.1.21, I see the following (NOTE TX bytes says 154.0 KB,
while RX bytes says 0.0 B):
Code: Select all
jamie@X5000-Linux:$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:80:10:11:11:11
inet addr:192.168.1.21 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::280:10ff:fe11:1111/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:1428 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:154066 (154.0 KB)
Memory:fe4e6000-fe4e6fff
eth1 Link encap:Ethernet HWaddr 00:80:10:22:22:22
UP 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
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:1869 errors:0 dropped:0 overruns:0 frame:0
TX packets:1869 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:156932 (156.9 KB) TX bytes:156932 (156.9 KB)
Code: Select all
jamie@X5000-Linux:$ netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
link-local * 255.255.0.0 U 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
Code: Select all
jamie@X5000-Linux:$ ping 192.168.1.21
PING 192.168.1.21 (192.168.1.21) 56(84) bytes of data.
64 bytes from 192.168.1.21: icmp_seq=1 ttl=64 time=0.037 ms
64 bytes from 192.168.1.21: icmp_seq=2 ttl=64 time=0.045 ms
64 bytes from 192.168.1.21: icmp_seq=3 ttl=64 time=0.033 ms
^C
--- 192.168.1.21 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2043ms
Code: Select all
jamie@X5000-Linux:$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
From 192.168.1.21 icmp_seq=1 Destination Host Unreachable
From 192.168.1.21 icmp_seq=2 Destination Host Unreachable
From 192.168.1.21 icmp_seq=3 Destination Host Unreachable
^C
--- 192.168.1.1 ping statistics ---
7 packets transmitted, 0 received, +3 errors, 100% packet loss, time 6077ms
both on my test X5000/20 Linux install (Ubuntu 16.04.3 LTS), and on
another Linux box connected to the same network switch (in this case
at IP address 192.168.1.210)
In this test I start the capture on eth0 (X5000/20) before it is put online,
and attempt to bring it up using DHCP to obtain it's address.
What I found was that network traffic *was* being attempted over eth0.
Here is a plain text export of the transmit side (the X5000/20) that
was captured using Wireshark.
(There were more network packets being sent from the X5000/20,
however, I am only showing DHCP traffic to save space in this post):
Code: Select all
No. Time Source Destination Protocol Length Info
2 0.042259843 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x655d91e8
Frame 2: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
16 3.830001152 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x655d91e8
Frame 16: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
21 9.308914533 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x655d91e8
Frame 21: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
23 18.906405343 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x655d91e8
Frame 23: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
25 36.390926450 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x655d91e8
Frame 25: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
26 44.048328412 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x655d91e8
Frame 26: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
30 44.889049203 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x421bade3
Frame 30: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
44 48.254495304 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x421bade3
Frame 44: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
49 54.299052732 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x421bade3
Frame 49: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
51 62.672007482 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x421bade3
Frame 51: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
52 77.485896202 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x421bade3
Frame 52: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
56 89.895304152 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x5df47c84
Frame 56: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
71 93.828837008 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x5df47c84
Frame 71: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
74 97.948453158 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x5df47c84
Frame 74: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
which filtered for any traffic to/from the MAC address of the X5000/20's eth0, in this case
shown as Commodor_11:11:11 (00:80:10:11:11:11) below:
This export shows only the DHCP traffic seen from outside the X5000/20,
and as you can see, a matching set of DHCP requests *do in fact* make
it to the outside network.
Code: Select all
No. Time Source Destination Protocol Length Info
39 5.671762509 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x655d91e8
Frame 39: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: Commodor_11:11:11 (00:80:10:11:11:11)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
73 9.451895404 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x655d91e8
Frame 73: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: Commodor_11:11:11 (00:80:10:11:11:11)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
154 14.919944480 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x655d91e8
Frame 154: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: Commodor_11:11:11 (00:80:10:11:11:11)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
269 24.498335996 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x655d91e8
Frame 269: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: Commodor_11:11:11 (00:80:10:11:11:11)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
630 41.948018648 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x655d91e8
Frame 630: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: Commodor_11:11:11 (00:80:10:11:11:11)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
701 49.590211264 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x655d91e8
Frame 701: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: Commodor_11:11:11 (00:80:10:11:11:11)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
706 50.429265938 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x421bade3
Frame 706: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: Commodor_11:11:11 (00:80:10:11:11:11)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
744 53.788035317 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x421bade3
Frame 744: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: Commodor_11:11:11 (00:80:10:11:11:11)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
797 59.820568614 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x421bade3
Frame 797: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: Commodor_11:11:11 (00:80:10:11:11:11)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
852 68.176833686 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x421bade3
Frame 852: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: Commodor_11:11:11 (00:80:10:11:11:11)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
990 82.961224895 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x421bade3
Frame 990: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: Commodor_11:11:11 (00:80:10:11:11:11)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
3827 95.345964418 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x5df47c84
Frame 3827: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: Commodor_11:11:11 (00:80:10:11:11:11)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
3887 99.271668572 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x5df47c84
Frame 3887: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: Commodor_11:11:11 (00:80:10:11:11:11)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
No. Time Source Destination Protocol Length Info
3943 103.383072429 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x5df47c84
Frame 3943: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Commodor_11:11:11 (00:80:10:11:11:11), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: Commodor_11:11:11 (00:80:10:11:11:11)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
outside network (confirming that at least the transmit to the PHY is working),
I could see no responses from my network's DHCP server to answer these
requests.
It is not a physical networking or routing issue, as I always get a successful
DHCP response to the X5000/20 when I enable the Realtek 8169 interface.
Since initial outgoing traffic *appears* to be working from the DPAA Ethernet
on the X5000/20, is it possible we are missing an interrupt mapping from the
Frame Manager to catch the received data?
Best Regards,
Jamie Krueger
BITbyBIT Software Group LLC
Jamie Krueger
BITbyBIT Software Group LLC
Re: Kernel 4.15
Hi Jamie,
Like Xeno said " I figured out that the DPAA Ethernet driver has only been available since kernel 4.10." is correct like your test show!
I experience exactly the same issues as you.
I am also able to ping the interface itself, and even the ethtool en mii-tool do make me believe all is fine.
Your routing table is similair to mine.. its not a routing issue..
What i did find odd is the following:
In Uboot i set the Ipadress and all is working fine. I can ping my gateway.
When i boot up linux its seems disconnected. I have to bring up ETH0 first and then reattach the UTP cable to get the Connected stage within linux.
I have done some reading and the KSZ9021RN can be a real pain. Nevertheless i think we are getting closer.
To be continiued...
Like Xeno said " I figured out that the DPAA Ethernet driver has only been available since kernel 4.10." is correct like your test show!
I experience exactly the same issues as you.
I am also able to ping the interface itself, and even the ethtool en mii-tool do make me believe all is fine.
Your routing table is similair to mine.. its not a routing issue..
What i did find odd is the following:
In Uboot i set the Ipadress and all is working fine. I can ping my gateway.
When i boot up linux its seems disconnected. I have to bring up ETH0 first and then reattach the UTP cable to get the Connected stage within linux.
I have done some reading and the KSZ9021RN can be a real pain. Nevertheless i think we are getting closer.
To be continiued...
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 Jamie,
Hi Skateman,
Many thanks for testing!
The result is, that the driver doesn't work since the beginning. No one has notice it because the NXP guys always uses their own kernels from the Freescale tree.
Could you please post your results on the linuxppc-dev mailing list? Link: https://lists.ozlabs.org/listinfo/linuxppc-dev
In my point of view, this is a support case for the Linux ppc developers because the DPAA Ethernet driver is already integrated in the official mainline vanilla kernel. I think it isn't a special Cyrus problem.
Thanks,
Christian
Hi Skateman,
Many thanks for testing!
The result is, that the driver doesn't work since the beginning. No one has notice it because the NXP guys always uses their own kernels from the Freescale tree.
Could you please post your results on the linuxppc-dev mailing list? Link: https://lists.ozlabs.org/listinfo/linuxppc-dev
In my point of view, this is a support case for the Linux ppc developers because the DPAA Ethernet driver is already integrated in the official mainline vanilla kernel. I think it isn't a special Cyrus problem.
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.
- JamieKrueger
- Beta Tester
- Posts: 13
- Joined: Mon Dec 20, 2010 7:15 pm
Re: Kernel 4.15
Hi Skateman,
Ethernet driver. It loads a block of microcode to configure the
Frame Manager (FMan), and then configures the Ethernet in
"Independent Mode", which was designed for early boot loaders
where you need to access the Ethernet before bringing up all
of the hardware.
the Ethernet. Just fine for U-Boot, but we are looking for a full featured DPAA based
Ethernet driver running in "Normal Mode".
This is because U-Boot is using a special "Independent Mode" for it'sSkateman wrote: Hi Jamie,
What i did find odd is the following:
In Uboot i set the Ipadress and all is working fine. I can ping my gateway.
Ethernet driver. It loads a block of microcode to configure the
Frame Manager (FMan), and then configures the Ethernet in
"Independent Mode", which was designed for early boot loaders
where you need to access the Ethernet before bringing up all
of the hardware.
- From: QorIQ Data Path Acceleration Architecture (DPAA) Reference Manual, Rev. 2; 8-5
Independent Ethernet mode
— Does not use QMan and BMan for enqueueing and buffer allocation (i.e. ‘independent’)
— Use of Ethernet native interface
— Buffer descriptor (BD) ring programming model
— Up to 100-Mbps rates
the Ethernet. Just fine for U-Boot, but we are looking for a full featured DPAA based
Ethernet driver running in "Normal Mode".
Best Regards,
Jamie Krueger
BITbyBIT Software Group LLC
Jamie Krueger
BITbyBIT Software Group LLC
- JamieKrueger
- Beta Tester
- Posts: 13
- Joined: Mon Dec 20, 2010 7:15 pm
Re: Kernel 4.15
I have joined the linuxppc-dev mailing list, and I just sent off a (slightly reformatted) version of the results I posted here.xeno74 wrote: Hi Jamie,
Could you please post your results on the linuxppc-dev mailing list? Link: https://lists.ozlabs.org/listinfo/linuxppc-dev
Thanks,
Christian
@Christian, I sent you a copy directly in case you wanted to add any further notes.
Best Regards,
Jamie Krueger
BITbyBIT Software Group LLC
Jamie Krueger
BITbyBIT Software Group LLC