U-Boot Driver for Ethernet Controller

Does U-Boot use the driver /u-boot/drivers/net/p1000.c (and corresponding header file) for the Ethernet controller “Intel I210-AT”?

No, as can be seen from e.g. the following commit it is drivers/net/e1000.c.

BTW: Why exactly are you enquiring about this? Is there anything not working as expected for you?

The physical link is not established under random, not reproducible circumstances. We had this behaviour when powering off/on the SOMs and when pci enum (the ethernet controller is accessed by the TK1 via PCIe) like described below. (As we had the behaviour with the Apalis Dev Board and our custom PCB it seems like it has its root cause w.r.t. to the ethernet controller “Intel i210-AT” on the TK1 SOM or the drivers for the ethernet controller in u-boot. We had the behaviour also with different switches.)

configuration:

  • switch (Netgear GS108 or Netgear GS108E, connected to intranet, provides leds for indication of link, required because leds of apalis eval board do not indicate the link status)
  • Apalis Evaluation Board v1.1A
  • Apalis TK1 2GB v1.1A (Is the serial number relevant for you?)
  • Apalis_TK1_LinuxImageV2.7Beta1+_20170113.tar.bz2

setup:

  • connect eval board to switch via ethernet
  • connect eval board to host pc via serial interface
  • start serial console like minicom

execution:

  • poweron board with poweron button
  • abort the autoboot over the serial interface by hitting any key
  • enter setenv autoload false; if env exists ethaddr; then; else setenv ethaddr 00:14:2d:00:00:00; fi; pci enum; in the u-boot command prompt

expected behavior:

  • link led on switch lights up (usually after 3 seconds or so)

observed behavior (randomly):

  • link led on switch does not light up (assumed max waiting time: 30 seconds)

(also observable in u-boot when executing dhcp after pci enum:slight_smile:

Apalis TK1 # setenv autoload false; if env exists ethaddr; then; else setenv ethaddr 00:14:2d:00:00:00; fi; pci enum; dhcp;
e1000: no NVM
e1000: e1000#0: ERROR: Valid Link not detected: -8

(BTW: Typo, you are right. it is e1000.)

I’ve seen this behavior off and on only on one particular managed HPE switch and after upgrading that switch’s configuration/firmware it did not ever happen again. However from a technical point of few the Linux integration of the Apalis TK1 i210 is somewhat more sophisticated than the U-Boot one. So I see some room for improvement along the following lines.

I tried to reproduce the behaviour (no physical ethernet link) when connecting the dev board to a laptop. Within 20 tries I was not able to reproduce the behaviour. It took approximately 8-9 seconds until the link led lights up. (When connecting the dev board to a switch in the good case the link led lights up after 3-4 seconds.)

Have you any idea what configuration values could have change when you upgraded the switch firmware?

Unfortunately I do not know. And as no customer ever reported anything like that before I did not really think much about it.

I upgrade the switch firmware right now. If that does not help I have to investigate the switch configuration…

What kind of a switch is it? Not one of them crappy HPE ones as well, isn’t it?

It is a Netgear GS108Ev3 (the other switch is GS108v4, but not manage-able).

OK, we may have some of those laying around somewhere. So I will give those a try. The first step will really be to get a half way consistent reproduction scenario to further investigate whether or not certain of my proposed changes would actually work or not.

The firmware version on the switch GS108E is v2.00.08

Apalis TK1 BSP v2.7b1+

Seems like the latest igb driver (which should be relevant for the i210-at ethernet controller) from source force is in use but there is a newer version on the intel website, see above…

Apalis TK1 BSP v2.7b1+

Please note that that release is long since unsupported as we only support stable and the latest beta release. At the time of this writing that would be 2.7b3.

Linux kernel version: 3.10.40 used http://developer.toradex.com/files/toradex-dev/uploads/media/Colibri/Linux/Images/Apalis_TK1_LinuxReleaseNotesV2.x.txt

Please note that that release notes text file is deprecated and the following should be consulted:

http://developer.toradex.com/software/linux/linux-software/release-details

Linux kernel igb driver: igb-5.3.5.4.tar.gz http://git.toradex.com/cgit/linux-toradex.git/commit/?h=toradex_tk1_l4t_r21.5&id=1fad13a736449ee7f41a405ab586642ab753764f

Yes.

Latest Linux kernel igb driver: igb-5.3.5.4 https://sourceforge.net/projects/e1000/files/igb%20stable/

Yes.

Seems like the latest igb driver (which should be relevant for the i210-at ethernet controller) is in use…

Yes, but please note that as often the case on Embedded systems often more than just a single driver may be responsible for the stability of a certain feature. In this particular case the PCIe driver on the TK1 side and the clocking thereof is definitely another player. Please also note them various erratas both on the TK1 as well as the i210 side.

Ok, I understand. I will have a look into the erratas.

Have you seen my update w.r.t. to the latest Linux kernel igb driver? The one on the Intel website (igb-5.3.5.7) is newer than the one from the sourceforce website (igb-5.3.5.4). I could not find info in the release notes if this could have an impact and the behavior does not relate to known limitations… What do you think?

W.r.t. to clocking and PCIe: Can I help you out somehow in getting info about their versions and comparing possible newer versions or something like that?

Ok, I understand. I will have a look into the erratas.

Have you seen my update w.r.t. to the latest Linux kernel igb driver? The one on the Intel website (igb-5.3.5.7) is newer than the one from the sourceforce website (igb-5.3.5.4). I could not find info in the release notes if this could have an impact and the behavior does not relate to known limitations… What do you think?

No, I have not noticed that.

W.r.t. to clocking and PCIe: Can I help you out somehow in getting info about their versions and comparing possible newer versions or something like that?

One thing I am not exactly clear about is whether or not you are having issues only in U-Boot or also running Embedded Linux as well. So far we are not aware of any issues outside of running U-Boot.

We observed this issue in u-boot and embedded linux. But I did not check if the issue occured in linux only if it already occured in u-boot or not (means: if the root cause “propagates” from u-boot to linux or if the root cause is existing in u-boot and linux separately).

Could you please provide log files then from occurrence in Linux.

Plus as mentioned before we recommend running our latest BSP which would be 2.7b3 at the time of this writing.

Ok. I try to reproduce it again in linux with BSP v2.7b1+ and provide the log files to you then.

Have you not been able to reproduce the behaviour with v2.7b3 as well or not?