RTL8111F MAC address not parsed correctly on new ASUS P8H77-M port

Hello,

I have been working on a port/variant for the ASUS P8H77-M, which I 
recently got from a friend.

At this point I have almost everything working, with the exception of 
the onboard Realtek RTL8111F ethernet NIC. Or at least, it does allow 
for network traffic, but the MAC address is set to 00:00:00:00:00:05. 
When I boot the vendor BIOS, the actual MAC address is shown when I run 
`ip link`.

I also have a P8Z77-M with coreboot, which has the same NIC and is 
overall a pretty similar board. On that board I do not have any issues 
with the MAC address.


Maybe I'm wrong, but I suspect the PCI subvendor and subdevice strings 
to potentially be the cause of this. When I run `hwinfo` with the vendor 
BIOS on the P8H77-M, the output shows:

     path = /devices/pci0000:00/0000:00:1c.4/0000:03:00.0
     modalias = "pci:v000010ECd00008168sv00001043sd00008505bc02sc00i00"
     class = 0x20000
     vendor = 0x10ec
     device = 0x8168
     subvendor = 0x1043
     subdevice = 0x8505

So the subvendor should be 1043 and the subdevice should be 8505.

When I do the same when running my WIP coreboot port on the P8H77-M, I 
get this:

   pci device: name = 0000:03:00.0
     path = /devices/pci0000:00/0000:00:1c.4/0000:03:00.0
     modalias = "pci:v000010ECd00008168sv000010ECsd00008168bc02sc00i00"
     class = 0x20000
     vendor = 0x10ec
     device = 0x8168
     subvendor = 0x10ec
     subdevice = 0x8168

Here the subvendor and the subdevice are equal to the vendor and the 
device, which I think is wrong and maybe causes this issue.

For reference, I also ran `hwinfo` on the P8Z77-M with coreboot:

   pci device: name = 0000:04:00.0
     path = /devices/pci0000:00/0000:00:1c.5/0000:04:00.0
     modalias = "pci:v000010ECd00008168sv00001043sd00008505bc02sc00i00"
     class = 0x20000
     vendor = 0x10ec
     device = 0x8168
     subvendor = 0x1043
     subdevice = 0x8505

This shows the same subvendor/subdevice as the vendor BIOS on the 
P8H77-M. (And this board does *not* have the MAC address issue in coreboot.)


So I figured that I could set the subsystemid in overridetree.cb to set 
these values correctly, but no matter what I try, I can't seem to get 
any other output than 0x10ec:0x8168.

First I tried this:

  device pci 1c.4 on
   subsystemid 0x1043 0x8505
   device pci 00.0 on end
  end

Then this:

  device pci 1c.4 on
   device pci 00.0 on
    subsystemid 0x1043 0x8505
   end
  end

And then this:

  device pci 1c.4 on
   subsystemid 0x1043 0x8505
   device pci 00.0 on
    subsystemid 0x1043 0x8505
   end
  end

But in all cases, `hwinfo` showed 0x10ec:0x8168 and `ip link` gave me 
00:00:00:00:00:05.


Interestingly, I did see the values I set reflected in the coreboot log:

[DEBUG]  PCI: 03:00.0 subsystem <- 1043/8505
[DEBUG]  PCI: 03:00.0 cmd <- 103

On the other hand, when I looked in the coreboot log of the P8Z77-M, it 
didn't set it to those values at all:

[DEBUG]  PCI: 04:00.0 subsystem <- 1043/84ca
[DEBUG]  PCI: 04:00.0 cmd <- 103

Yet, `hwinfo` still showed 1043:8505 on that board, and the MAC address 
was correct. So that made me doubt if these values were retrieved from 
devicetree.cb at all.


Anyway, I am kind of at a loss here.. I have two very similar boards 
with the same NIC. On one of them the MAC address is parsed correctly, 
and on the other one it is not. The only difference that I can see is 
the subdevice/subvendor, but I can't get coreboot to set it correctly, 
even though the vendor BIOS works fine.

As for the P8Z77-M board that doesn't have this issue, I can't even find 
the string "8505" anywhere when I recursively grep through 
src/mainboard/asus; yet it does seem to use that as the subdevice id 
somehow.

So where are the subvendor/subdevice strings for the NIC retrieved from 
then? Or could the MAC address issue be caused by something completely 
different?


-- 
With kind regards,

Kevin Keijzer
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]