Project

General

Profile

Actions

Bug #579

open

MAC address programmed by coreboot to onboard RTL8111F does not persist

Added by Keith Hui about 1 month ago. Updated 12 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
chipset configuration
Target version:
Start date:
03/01/2025
Due date:
% Done:

0%

Estimated time:
Affected versions:
Needs backport to:
Affected hardware:
Asus P8Z77-V LE PLUS w/ RTL8111F
Affected OS:
Linux kernel 6.12.7

Description

I am producing a coreboot port on Asus P8Z77-V LE PLUS on which this issue is observed. It has a RTL8111F ethernet controller without EEPROM for vital product data.

I enabled the rtl8168 driver in coreboot so I can configure the LEDs and MAC address. Lights work great, but the MAC address always revert to 00:00:00:00:00:05 by the Linux r8169 kernel module. I would then have to reassign its proper MAC address using ip link change eno0 address <mac>.

The device appears to be taking the address I programmed, but r8169 reverts it both on init and teardown, insisting that 00:00:00:00:00:05 is its permanent MAC address.

Survival of coreboot programmed MAC address before r8169 driver is confirmed by a debug read back I inserted in the coreboot rtl81xx driver, as well as by temporarily blacklisting r8169.

Vendor firmware is unaffected.

Actions #1

Updated by Martin Roth 12 days ago

Do you have any boot logs from the linux driver that you could post? My first guess is that the NIC is getting reset, but I think we need more information about what's going on.
Maybe remove the driver and get a dump of the IO and full PCI config space of the chip with both coreboot and the OEM firmwareware to compare.

Maybe also verify the MAC address is still configured right before we jump to the payload.

Actions #2

Updated by Keith Hui 12 days ago

I didn't capture a boot log. Will have to try again.

But as I wrote in the initial issue, with r8169 kernel module blocked, the MAC address programmed by coreboot can survive the entire boot process - through payload, grub, kernel, to userspace. I got the I/O base of the device through lspci, then dumped the I/O port block via /dev/port and checked the contents.

Actions

Also available in: Atom PDF