Hi,

I am upgrading my custom board which uses a Cyclone V SoCFPGA from linux 3.10-ltsi to linux 4.14.73-ltsi and I am having difficulties in getting it connected to the internet.

It seems to be a network configuration issue and that's why I am writing on this forum. (The official support is also extremely slow/close to non-existent).

I get the message "failed to bring up eth0" when dhcp tries to assign an IP to the unit.

It only works in one case as described below. Also some other observations are written below;

NOTE: we have 2 sectors on the flash memory where we can store images.

a) If we boot from the 1st sector (containing kernel version 3.10-ltsi), ethernet connection and access to the internet is established successfully. If we do a warm reboot (i.e rebooting just the SoC) and boot to sector 2 (containing the linux kernel version 4.14.73-ltsi) the ethernet connection and access to the internet is established successfully.

b) if we keep warm rebooting the unit with kernel 4.14, the internet connection is always established properly.

c) If we do a cold reset (i.e resetting the EMAC, QSPI etc… just like a pulling the power plug) and boot straight to the linux kernel 4.14.73-ltsi then the ethernet connection is established but when dhcp runs we get the error message “Failed to bring up eth0”. Setting a static IP does not work either. So no packets get out!

d) Putting down eth0 by using commands like (ifconfig eth0 down or ifdown --force eth0) will cause the system to immediately COLD RESET! which is very strange.

Here is my dmesg log https://0bin.net/paste/PkLJgwlBFOuAz...OXVJJuNdFLD2Qn

I would be really grateful if someone could point me to what could be the issue. I have been struggling with this for a while now.

According to dmesg, it finds eth0, loads the module after giving out about it, and then loses it.

1st guess: firmware. That is a binary blob the manufacturers can update. It is not locally compiled and not kernel-version dependent, so if you find it in kernel 3.10, you can copy it to /lib/firmware in 4.14. /var/log/messages or other long log files usually record firmware errors, but you're probably not keeping those.

Otherwise, what's the story behind the module?

1 members found this post helpful.

Is the same network driver and options being used in the working 3.10 kernel as 4.14?
If DHCP is failing, then how is ifconfig reporting an address when you bring eth0 up?

I am thinking the wrong driver module might be getting loaded, or it is missing an option.

Thanks for your replies;

@business_kid
You are correct about loading the module, finding eth0 and losing it. If I make the driver as a loadable module, it is not possible to find eth0 after loading the driver modules during run time.

We use the Micrel KSZ9021 chip as PHY and they do not have any binary blobs that we can add to our firmware. We have also not used that in kernel 3.10. We are building our firmware with buildroot.

I am not sure what you mean by the story behind the module, could you please elaborate?

@uteck
Yes they are the same drivers albeit the updated one.

We have a script that assign a static ip address in case DHCP fails but if we remove the script, eth0 will be up without an IP address.

we have also enabled all options possible and made a lot of combinations with the options. Also I think if the driver was wrong, it should not have worked at all.

Surely - that's poor help. In kernel versions,3.x.x -->4.x.x signals a compatibility break, so it's quite possible that the module that works in 3.10.x will not work in 4.14.x. Is it an external module, or one from the kernel tree?

The usual way I go about this is to get the pci id with lspci, and then google for a module that supports it. Is your 4.14 module prepared for a 4.x.x kernel?

The module is from the kernel tree and I am pretty sure it is prepared for kernel 4.x.x.

Our EMAC is connected to the MDIO bus and not pci. We have also tried from the mainline kernel but nothing seems to work yet

Maybe we can bothget back to basics. If your nic module is in the United, there's a script in mzny distros to load them. If the module is not in the United, it will be loaded probably with firmware. Your logs should note that for 3.x & 4.x kernels. Why not Clare what happens?

Hi business_kid,

I am not too sure what you meant but if I understood correctly, You want me to use the mainline kernel of 3 and 4 and try to load the modules manually and see what happens.

We have already tried that and the results are the same, unfortunately. We also build our own firmware with Buildroot. It is not a generic one that we use.

I get it that the 3.x kernel module works, but the 4.x doesn't. We need to see logs of the module, kernel, & card talking during the boot sequence. Does the module recognise the card, load firmware, assign I/O or throw a strop?.

Check files like dmesg, /var/log/messages or any other you think has info of value.

The critical bit that tells you why is the card/kernel/module negotiation. To give you an example, one nic wouldn't work because it got the wrong IRQ, and I had to configure it to land jammy side up.

EDIT: The fact that the buildroot and the project behave the same to my mind validates the behaviour of the buildroot here.

The fact that the 4.x kernel doesn't work is yielding information you are missing. But it's in the logs of the kernel boot, and you need to post the relevant section. Don't paste in 1G like some guys try.