On 08/23/2016 10:16 AM, Ard Biesheuvel wrote:
On 23 August 2016 at 17:06, Alan Ott alan@softiron.co.uk wrote:
On 08/23/2016 08:57 AM, Daniil Egranov wrote:
Are you using PCD variable or configuration protocol to set MAC address?
I used a PCD, exactly as you had written it. I put the PCD in my .dsc file.
Maybe I misunderstand why that's bad. It seems like the right kind of thing for a PCD. It's the same way the Seattle on-board 10Gbe ports work. From OverdriveBoard.dsc:
[PcdsDynamicDefault.common] gAmdStyxTokenSpaceGuid.PcdEthMacA|0x02A1A2A3A4A5 gAmdStyxTokenSpaceGuid.PcdEthMacB|0x02B1B2B3B4B5
In what way is this different than the Marvell?
The Marvell MAC address specified backwards. It may look a bit strange but I think it's done this way because it simplifies parsing of the value before pushing it to registers. The MAC address 0002F80161A7 will be gEmbeddedTokenSpaceGuid.PcdYukonMacAddress|0x0000A76101F80200. It can be fix to a more natural way but I'll wait for Leif's decision on how MAC address should be handled for Marvell case.
Dynamic PCDs will only work correctly with modules that are built from the same .DSC. The MarvellYukonDxe driver, being a standalone driver that can even be built as EBC, this means we're stuck with fixed PCDs, which means the MAC becomes a property of the driver binary rather than of the platform it executes on.