On 22.03.2025 09:50, Paul Menzel wrote:
Keith Hui reported the issue *MAC address programmed by coreboot
to onboard RTL8111F does not persist* [1] below when using
coreboot:
Why do you consider this a bug? IOW: Where is it specified otherwise?
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>.
r8169 in a first place reads the factory-programmed MAC from the chip.
If this is 00:00:00:00:00:05, then this seems to be an issue with your
board.
What do you mean with this? What vendor firmware are you referring to?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.
Do you have an idea, where in the Linux driver that happens?
See rtl_init_mac_address() in r8169, and rtl8168_get_mac_address()
in Realtek's r8168 driver.
On mainboard/asus/p8z77-v_le_plus, programmed MAC address is being
reverted with controller resets done at loading and unloading of Linux
r8169 kernel module.
Ghidra examination of vendor BIOS reveals an additional sequence to
program the MAC address into its ERI register block. This patch
adds code to replicate that sequence, gated by a Kconfig so it's
only included where necessary.
[2]: https://review.coreboot.org/c/coreboot/+/87436[1]: https://ticket.coreboot.org/issues/579#change-2029