IMX8 EVK DHCP not working

[russell_coy]

Hello,

I am trying to create an image for an i.MX8 EVK using Yocto and my own image recipe to add features and packages. I have created my own Yocto layer. The image recipe inherits the core-image and adds standard features and packages plus some customised additions. I am basing this on the NXP i.MX8 Yocto 'Morty'  BSP (fsl-yocto-L4.9.51_mx8mq-ga) i.MX_Yocto_Project_User's_Guide. Initially, I wanted to have a static IP address and so added into the image the init-ifupdown package with a customised interfaces file configured with the static IP address as per the guidance here:

Yocto Setting the Default Ethernet address and disable DHCP on boot. 

Following bitbake of the image and copying to an sd card, the eth0 interface could be brought up with the desired static IP address. I wanted the eth0 interface to be configured at start-up, so I added a recipe to enable this through systemd.

Having got this working, the requirements have now changed such that the eth0 interface needs to obtain it's IP automatically via DHCP, so I have changed the custom /etc/network/interfaces file to remove the static IP settings and revert to the default i.e.

# Wired or wireless interfaces

auto eth0

iface eth0 inet dhcp

Following a re-build of the image to incorporate the changes, the eth0 interface starts up at boot, however it does not get an ipv4 IP address via DHCP, it only gets an ipv6 address.

Bringing the interface down and then up using ifdown eth0 and ifup eth0 results in the following:

root@imx8mqevk:~# ifup eth0
[   34.113147] Atheros 8031 ethernet 30be0000.etherne:00: attached PHY driver [Atheros 8031 ethernet] (mii_bus:phy_addr=30be0000.etherne:00, irq=-1)
[   34.126526] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
udhcpc (v1.24.1) started
Sending discover...
Sending discover...
[   38.236282] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[   38.243947] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Sending discover...
No lease, forking to background

Is there something that I am missing from my image recipe that will allow DHCP to be run sucessfully to obtain an ipv4 IP address automatically?

If I create an sd card with the NXP test image (fsl-image-qt5-validation-imx-xwayland-imx8mqevk.sdcard.bz2), then this will boot with the eth0 interface correctly obtaining an ipv4 IP address. What functionality is included in this image to enable this?

Any advice on what the correct steps are to get DHCP to work in my custom image recipe?

Thanks in advance

[thiago_machado]

Hello,

is there any updates in this issue. I've followed all the steps here, including adding connman and connman-client to my image. The boot occurs, but no IPv4 is set.

Also, there's no /etc/network/interface file.

[russell_coy]

OK, I think I have found a solution.

It appears that to get the eth0 port to work I also need to run "udhcpc -i eth0" after "ifup eth0".

So I have modified the script that starts eth0 to include this. Following a re-build of the image with the new systemd start-up services script, eth0 correctly obtains an IP address and I can ping servers OK.

To set-up the systemd start-up service, I followed the method described in this post:

[yocto] Issue creating systemd service recipe 

Although I had to add RDEPENDS_${PN} += "bash" and change the permissions for the .service file to 0644.

I don't know if this is the preferred/correct method, but it works on my set-up.

With regard to the NXP validation image (fsl-image-qt5-validation-imx-xwayland-imx8mqevk.sdcard.bz2), looking at the manifest file for the image (from the download L4.9.51-ga_images_mx8mq.tar), it appears that "connman" is used. I beleive that "connman" will automatically manage wired connections nad connect at boot. This certainly seems to be the case, as this image starts up with eth0 correctly configured with no other intervention. Hence an alternative solution would be to add the connman package to the image recipe.

Regards,

Russell

[russell_coy · Accepted solution]

Hello again,

The best solution seems to be to add connman and connman-client to the image.

Previous solution stopped working after moving device to different location/connection.

Regards,

Russell