Hello,
I've been trying to figure out how predictable interface naming works, especially the "on-board index number", that the firmware apparently passes(?)
I'm currently working on a port for the ASRock B75M-ITX, which has a Realtek NIC as PCI device 03:00.0. The Linux kernel calls this device enp3s0, which makes sense and works fine. However, on my ASUS P8Z77-V and my Lenovo X230, the Intel NIC is called eno0, which makes more sense, because it's "ethernet onboard 0" and not a physical network card stuck in a PCI Express slot.
At first I thought that maybe this was an e1000e-specific way of naming interfaces, but at the office I have an old Gigabyte GA-G41M-ES2L-based file server, running coreboot, also with a Realtek NIC, also being PCI device 03:00.0, which is called eno0 by the kernel as well, with enp3s0 as altname. (So it's not that.)
I ended up reading about the interface (re)naming process, which seems to be handled by systemd-udevd [1]:
--- The following different naming schemes for network interfaces are now supported by udev natively:
1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1) 2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1) 3. Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0) 4. Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da) 5. Classic, unpredictable kernel-native ethX naming (example: eth0) ---
It looks like my B75M-ITX currently uses option 3, while I want it to use option 1, like all my other machines do. So according to the documentation, interfaces called enoX or ensX use index numbers provided by the firmware. However, I have no idea how or where this is defined. I would expect something to be in devicetree.cb, but I can't see anything seemingly related anywhere.
So my question is: how does coreboot pass "index numbers for on-board devices" to the kernel / udev, and how can I define them properly on boards where this is not working the way it should?
[1] https://systemd.io/PREDICTABLE_INTERFACE_NAMES/
On Mon, Mar 06, 2023 at 03:05:42PM +0100, Kevin Keijzer via coreboot wrote:
Hello,
I've been trying to figure out how predictable interface naming works, especially the "on-board index number", that the firmware apparently passes(?)
I'm currently working on a port for the ASRock B75M-ITX, which has a Realtek NIC as PCI device 03:00.0. The Linux kernel calls this device enp3s0, which makes sense and works fine. However, on my ASUS P8Z77-V and my Lenovo X230, the Intel NIC is called eno0, which makes more sense, because it's "ethernet onboard 0" and not a physical network card stuck in a PCI Express slot.
At first I thought that maybe this was an e1000e-specific way of naming interfaces, but at the office I have an old Gigabyte GA-G41M-ES2L-based file server, running coreboot, also with a Realtek NIC, also being PCI device 03:00.0, which is called eno0 by the kernel as well, with enp3s0 as altname. (So it's not that.)
I ended up reading about the interface (re)naming process, which seems to be handled by systemd-udevd [1]:
~~~~
It looks like my B75M-ITX currently uses option 3, while I want it to use option 1, like all my other machines do. So according to the documentation, interfaces called enoX or ensX use index numbers provided by the firmware. However, I have no idea how or where this is defined. I would expect something to be in devicetree.cb, but I can't see anything seemingly related anywhere.
So my question is: how does coreboot pass "index numbers for on-board devices" to the kernel / udev, and how can I define them properly on boards where this is not working the way it should?
I think you simply need to explicitly list the device in the device tree, and a SMBIOS type 41 entry will be generated automatically. See https://github.com/coreboot/coreboot/blob/73e9ac66ad8ff8f4b15389b5685f808ac2...
And for instance
https://github.com/coreboot/coreboot/blob/b5df65a9aaee50421913ace6d7a4b35e0d...
https://github.com/coreboot/coreboot/blob/b5df65a9aaee50421913ace6d7a4b35e0d...
Seems with CONFIG_SMBIOS_TYPE41_PROVIDED_BY_DEVTREE you can even control which NIC gets what index if you have more than one.
Op 06-03-2023 om 19:50 schreef Jonathan A. Kollasch:
I think you simply need to explicitly list the device in the device tree, and a SMBIOS type 41 entry will be generated automatically.
The NIC is defined in the device tree like this:
https://github.com/coreboot/coreboot/blob/master/src/mainboard/asrock/b75m-i...
I don't see anything wildly different to other boards I have, which do show their onboard NIC as eno0 instead of enpXsX.
Seems with CONFIG_SMBIOS_TYPE41_PROVIDED_BY_DEVTREE you can even control which NIC gets what index if you have more than one.
But this does not seem to be set for any board by default. So I don't think it's a requirement for this to work; more like a hard override.
As stated, on my X230, P8Z77-V and GA-G41M-ES2L, the onboard NIC is called eno0 (as it should be). On my B75M-ITX it's called enp3s0, and on my B75 Pro3-M it's called enp4s0.
So coreboot doesn't seem to pass the "this device is onboard and its index is 0" message properly.
I can see `if (!dev->on_mainboard)` in smbios.c, but I can't find where that flag is set.
Hi
The NIC device needs to be in the devicetree.cb for on_board to be set to 1 (done by sconfig).
On the GA-G41M-ES2L you see the onboard nic as a child device below a PCIe port: device pci 1c.1 on # PCIe 2 (NIC) device pci 00.0 on # PCI 10ec:8168 subsystemid 0x1458 0xe000 end end
If you add the proper child device below the right pcie port in the devicetree an smbios entry41 will be added and the naming will be persistent.
Kind regards
Arthur
On Mon, Mar 6, 2023 at 9:43 PM Kevin Keijzer via coreboot < coreboot@coreboot.org> wrote:
Op 06-03-2023 om 19:50 schreef Jonathan A. Kollasch:
I think you simply need to explicitly list the device in the device
tree, and a
SMBIOS type 41 entry will be generated automatically.
The NIC is defined in the device tree like this:
https://github.com/coreboot/coreboot/blob/master/src/mainboard/asrock/b75m-i...
I don't see anything wildly different to other boards I have, which do show their onboard NIC as eno0 instead of enpXsX.
Seems with CONFIG_SMBIOS_TYPE41_PROVIDED_BY_DEVTREE you can even control which NIC gets what index if you have more than one.
But this does not seem to be set for any board by default. So I don't think it's a requirement for this to work; more like a hard override.
As stated, on my X230, P8Z77-V and GA-G41M-ES2L, the onboard NIC is called eno0 (as it should be). On my B75M-ITX it's called enp3s0, and on my B75 Pro3-M it's called enp4s0.
So coreboot doesn't seem to pass the "this device is onboard and its index is 0" message properly.
I can see `if (!dev->on_mainboard)` in smbios.c, but I can't find where that flag is set.
-- With kind regards,
Kevin Keijzer _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Arthur,
Op 06-03-2023 om 22:27 schreef Arthur Heymans:
If you add the proper child device below the right pcie port in the devicetree an smbios entry41 will be added and the naming will be persistent.
I'm currently trying this:
device pci 1c.5 on # PCIe Port #6, Realtek PCIe GbE Controller device pci 00.0 on subsystemid 0x1849 0x1e1a end end
But that doesn't seem to work. The device still shows up as enp3s0. Am I missing something?
I already found the problem. The comment in devicetree.cb was wrong. Device 1c.5 was not the NIC, but instead it's 1c.3.
I'm now using this:
device pci 1c.3 on # PCIe Port #4, Realtek PCIe GbE Controller device pci 00.0 on subsystemid 0x1849 0x1e16 end end
And that works fine:
eno0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 altname enp3s0
I've uploaded the patch to gerrit: https://review.coreboot.org/c/coreboot/+/73516
-
Arthur Heymans -
Jonathan A. Kollasch -
Kevin Keijzer