Linux - Embedded & Single-board computerThis forum is for the discussion of Linux on both embedded devices and single-board computers (such as the Raspberry Pi, BeagleBoard and PandaBoard). Discussions involving Arduino, plug computers and other micro-controller like devices are also welcome.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I'm trying to get ethernet working on a Build-root based embedded system using an AT91SAM9X25 SoC. Using the manufacturer-provided linux image, the ethernet connection works fine, getting an IP via DHCP. However, I am building my own kernel and rootfs using buildroot, and unfortunately, I cannot seem to get the ethernet to work.
After a fresh boot, I bring the interface up using the following:
Code:
ifconfig eth0 up
I then run tcpdump in the background:
Code:
tcpdump -i eth0 &
I then try to get an IP via DHCP:
Code:
udhcpc -i eth0 > /dev/null
The output of tcpdump seems to imply that packets are being broadcast:
Code:
12:05:28.621929 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 70:b3:d5:ba:b8:90 (oui Unknown), length 300
12:05:31.625962 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 70:b3:d5:ba:b8:90 (oui Unknown), length 300
12:05:34.633663 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 70:b3:d5:ba:b8:90 (oui Unknown), length 300
Yet despite this, I don't seem to get any response back from the DHCP server, and the ethernet does not function. In comparison, running tcpdump while running the factory provided linux image and using dhclient results in the following dump:
There is likely to be some other traffic in there, but at least you can see that the DHCP server is responding to the DHCP discover packet (highlighted in bold).
So, I know that the hardware, the ethernet cable, the router, etc are working fine. The issue seems to be in the rootfs image/kernel that I'm compiling. What could cause this issue?
What is the MAC address of eth0 once it is booted up? I am wondering this because I have seen a number of cases where the initial boot and install of a machine will have one ethernet device as eth0, but once the machine is up and running on the installed image from a harddrive, your ethernet devices will get scrambled and you will be trying to DHCP out of a different port.
Another thing to look at is which ethernet devices have link (perhaps a quick scan through dmesg output)
However, I am building my own kernel and rootfs using buildroot, and unfortunately, I cannot seem to get the ethernet to work.
...
So, I know that the hardware, the ethernet cable, the router, etc are working fine. The issue seems to be in the rootfs image/kernel that I'm compiling.
I would test using a static IP address before worrying about DHCP.
In actuality you don't even know if Ethernet frames are hitting the wire. You would need to examine the actual output (e.g. Wireshark on an external host), rather than an internal tcpdump.
Quote:
Originally Posted by amrbekhit
What could cause this issue?
The most common cause I've seen has been a misconfiguration of the MII/RMII interface between the EMAC and PHY.
@wells: The manufacturer of the board I'm using happens to store the MAC address as a u-boot environment variable. I've compared the environment variable and the MAC address reported by ifconfig eth0 and they are identical, so it doesn't look like there's an issue with the MAC address.
@blue_z: I can't event get static IP working. I'm using u-boot and tftp to transfer files from my host development PC and the device, so I've got the host PC ethernet port set up using static IP (192.168.100.100, netmask 255.255.255.0), and in u-boot the device is configured to use 192.168.100.200. This link works fine, so I'm happy that physically, there's nothing wrong. When I boot into Linux, I then try and configure the unit to use the same static IP address:
Code:
ifconfig eth0 192.168.100.200
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
# macb f802c000.ethernet eth0: link up (100/Full)
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
ifconfig eth0
eth0 Link encap:Ethernet HWaddr 70:B3:D5:BA:B8:90
inet addr:192.168.100.200 Bcast:192.168.100.255 Mask:255.255.255.0
inet6 addr: fe80::72b3:d5ff:feba:b890%3068699416/64 Scope:Link
UP BROADCAST RUNNING 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)
Interrupt:39 Base address:0xc000
Yet, I cannot ping the host computer at 192.168.100.100 at all. Running wireshark on the host computer on that network interface doesn't show any packets originating from the embedded device.
Quote:
In actuality you don't even know if Ethernet frames are hitting the wire
I agree - I suspect that this might be the issue here. You mentioned that perhaps there might be a a misconfiguration of the MII/RMII interface between the EMAC and PHY.
I've opened up the embedded device and had a look at the PHY chip. It's a DAVICOM DM9162IEP. I've had a look at the PHY Device support and infrastructure menu in the kernel menuconfig and the "Drivers for Davicom PHYs" options is enabled (CONFIG_DAVICOM_PHY). However, looking at the help text for that option shows that it only supports the dm9161e and dm9131 - I don't know whether the DM9162I is backwards compatible with any of these. This may be the cause of the issue - perhaps the manufacturer-provided kernel had a custom patch enabling support for that chip. I certainly couldn't find anything online that would indicate whether or not that particular chip is supported in the mainline kernel, or even a patch for it.
Other than this potential issue, is there anything else I can check to determine if there is a problem between the MAC and PHY?
I agree - I suspect that this might be the issue here.
Why the tentative opinion?
Why can't you make a definitive conclusion, and proceed from there?
Didn't you sanity check your Wireshark test?
Since you claim there's an "original" kernel and U-Boot that have functional networking, this should be trivial to confirm, and probably not that difficult to solve.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.