[Linaro-uefi,0/2] Platforms/AMD/Cello: implement MAC override

Message ID 20170627185619.21847-1-ard.biesheuvel@linaro.org
Headers show
Series
  • Platforms/AMD/Cello: implement MAC override
Related show

Message

Ard Biesheuvel June 27, 2017, 6:56 p.m.
Given that we're unlikely to ever see Cellos with the MAC programmed
correctly, implement a driver that programs a MAC in a volatile manner
instead. This still does not allow us to boot from the network, but at
least we no longer have to care about this at the OS level.

Ard Biesheuvel (2):
  Drivers/Net: add MAC override driver for Realtek 8169
  Platforms/AMD/Cello: add Realtek MAC override driver

 Drivers/Net/Realtek8169MacOverride/Realtek8169MacOverride.c   | 262 ++++++++++++++++++++
 Drivers/Net/Realtek8169MacOverride/Realtek8169MacOverride.inf |  44 ++++
 OpenPlatformPkg.dec                                           |   3 +
 Platforms/AMD/Styx/CelloBoard/CelloBoard.dsc                  |   7 +
 Platforms/AMD/Styx/CelloBoard/CelloBoard.fdf                  |   4 +
 5 files changed, 320 insertions(+)
 create mode 100644 Drivers/Net/Realtek8169MacOverride/Realtek8169MacOverride.c
 create mode 100644 Drivers/Net/Realtek8169MacOverride/Realtek8169MacOverride.inf

Comments

Leif Lindholm June 27, 2017, 7:42 p.m. | #1
On Tue, Jun 27, 2017 at 06:56:17PM +0000, Ard Biesheuvel wrote:
> Given that we're unlikely to ever see Cellos with the MAC programmed
> correctly, implement a driver that programs a MAC in a volatile manner
> instead. This still does not allow us to boot from the network, but at
> least we no longer have to care about this at the OS level.

For OpenPlatformPkg:
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>

But ... this does not fit well with the intent for edk2-platforms.
So I can't really migrate this across.
Hopefully, we can reach some sort of understanding over this sort of
not-quite-drivers (like the Renesas USB firmware loader) so that we
can get them into edk2. I'll bring it up at the next stewards sync,
next week.

/
    Leif

> Ard Biesheuvel (2):
>   Drivers/Net: add MAC override driver for Realtek 8169
>   Platforms/AMD/Cello: add Realtek MAC override driver
> 
>  Drivers/Net/Realtek8169MacOverride/Realtek8169MacOverride.c   | 262 ++++++++++++++++++++
>  Drivers/Net/Realtek8169MacOverride/Realtek8169MacOverride.inf |  44 ++++
>  OpenPlatformPkg.dec                                           |   3 +
>  Platforms/AMD/Styx/CelloBoard/CelloBoard.dsc                  |   7 +
>  Platforms/AMD/Styx/CelloBoard/CelloBoard.fdf                  |   4 +
>  5 files changed, 320 insertions(+)
>  create mode 100644 Drivers/Net/Realtek8169MacOverride/Realtek8169MacOverride.c
>  create mode 100644 Drivers/Net/Realtek8169MacOverride/Realtek8169MacOverride.inf
> 
> -- 
> 2.9.3
>
Ard Biesheuvel June 27, 2017, 8:06 p.m. | #2
On 27 June 2017 at 19:42, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> On Tue, Jun 27, 2017 at 06:56:17PM +0000, Ard Biesheuvel wrote:
>> Given that we're unlikely to ever see Cellos with the MAC programmed
>> correctly, implement a driver that programs a MAC in a volatile manner
>> instead. This still does not allow us to boot from the network, but at
>> least we no longer have to care about this at the OS level.
>
> For OpenPlatformPkg:
> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
>
> But ... this does not fit well with the intent for edk2-platforms.
> So I can't really migrate this across.
> Hopefully, we can reach some sort of understanding over this sort of
> not-quite-drivers (like the Renesas USB firmware loader) so that we
> can get them into edk2. I'll bring it up at the next stewards sync,
> next week.
>

Well, given how both these drivers are tightly coupled to Cello*, I'd
be perfectly happy making them a part of the platform in this case.

* the renesas driver requires an FV section with a certain GUID to be
present, and this driver depends on a PCD, which in both cases means
that the drivers cannot be built in a generic way anyway
Leif Lindholm June 28, 2017, 1:24 p.m. | #3
On Tue, Jun 27, 2017 at 08:06:58PM +0000, Ard Biesheuvel wrote:
> On 27 June 2017 at 19:42, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> > On Tue, Jun 27, 2017 at 06:56:17PM +0000, Ard Biesheuvel wrote:
> >> Given that we're unlikely to ever see Cellos with the MAC programmed
> >> correctly, implement a driver that programs a MAC in a volatile manner
> >> instead. This still does not allow us to boot from the network, but at
> >> least we no longer have to care about this at the OS level.
> >
> > For OpenPlatformPkg:
> > Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
> >
> > But ... this does not fit well with the intent for edk2-platforms.
> > So I can't really migrate this across.
> > Hopefully, we can reach some sort of understanding over this sort of
> > not-quite-drivers (like the Renesas USB firmware loader) so that we
> > can get them into edk2. I'll bring it up at the next stewards sync,
> > next week.
> 
> Well, given how both these drivers are tightly coupled to Cello*, I'd
> be perfectly happy making them a part of the platform in this case.

Well, they're not really.
Sure, that may be the only platform we have in the tree currently
using it, but the minnowboard max uses the same Realtek controller
(only it currently requires a separate binary driver, and probably
actually has a MAC address programmed).

> * the renesas driver requires an FV section with a certain GUID to be
> present, and this driver depends on a PCD, which in both cases means
> that the drivers cannot be built in a generic way anyway

Both that GUID and that PCD can live just as happily in an OptionRomPkg/
(or Drivers/) .dec as they can in an OpenPlatformPkg one.
Or am I missing something?

If we have something that is truly a one-off (or superseded), I agree
it makes sense to integrate it into the platform code. But as far as I
know, both of those components are still on the market, and some
manufacturers still fail to program on-device config areas.

/
    Leif
Ard Biesheuvel June 28, 2017, 9:12 p.m. | #4
On 28 June 2017 at 13:24, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> On Tue, Jun 27, 2017 at 08:06:58PM +0000, Ard Biesheuvel wrote:
>> On 27 June 2017 at 19:42, Leif Lindholm <leif.lindholm@linaro.org> wrote:
>> > On Tue, Jun 27, 2017 at 06:56:17PM +0000, Ard Biesheuvel wrote:
>> >> Given that we're unlikely to ever see Cellos with the MAC programmed
>> >> correctly, implement a driver that programs a MAC in a volatile manner
>> >> instead. This still does not allow us to boot from the network, but at
>> >> least we no longer have to care about this at the OS level.
>> >
>> > For OpenPlatformPkg:
>> > Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
>> >
>> > But ... this does not fit well with the intent for edk2-platforms.
>> > So I can't really migrate this across.
>> > Hopefully, we can reach some sort of understanding over this sort of
>> > not-quite-drivers (like the Renesas USB firmware loader) so that we
>> > can get them into edk2. I'll bring it up at the next stewards sync,
>> > next week.
>>
>> Well, given how both these drivers are tightly coupled to Cello*, I'd
>> be perfectly happy making them a part of the platform in this case.
>
> Well, they're not really.
> Sure, that may be the only platform we have in the tree currently
> using it, but the minnowboard max uses the same Realtek controller
> (only it currently requires a separate binary driver, and probably
> actually has a MAC address programmed).
>
>> * the renesas driver requires an FV section with a certain GUID to be
>> present, and this driver depends on a PCD, which in both cases means
>> that the drivers cannot be built in a generic way anyway
>
> Both that GUID and that PCD can live just as happily in an OptionRomPkg/
> (or Drivers/) .dec as they can in an OpenPlatformPkg one.
> Or am I missing something?
>

True. My point was rather that you can't build this driver from, say,
EmbeddedPkg/EmbeddedPkg.dsc in a generic manner, and deploy it as a
standalone binary.

> If we have something that is truly a one-off (or superseded), I agree
> it makes sense to integrate it into the platform code. But as far as I
> know, both of those components are still on the market, and some
> manufacturers still fail to program on-device config areas.
>

I will let you fight this battle, if you don't mind. I do agree with
the reasoning, but it is not something I care deeply about, and I sure
as hell don't intend to get involved with other boards that use these
parts. The devboard market is not cost driven, so it makes no sense
whatsoever to get the cheapest variant of the part, like they did with
the XHCI controller. And for an on-board PCI NIC, we're better off
using a Marvell Yukon like SoftIron did.
Leif Lindholm June 28, 2017, 9:48 p.m. | #5
On Wed, Jun 28, 2017 at 09:12:04PM +0000, Ard Biesheuvel wrote:
> >> Well, given how both these drivers are tightly coupled to Cello*, I'd
> >> be perfectly happy making them a part of the platform in this case.
> >
> > Well, they're not really.
> > Sure, that may be the only platform we have in the tree currently
> > using it, but the minnowboard max uses the same Realtek controller
> > (only it currently requires a separate binary driver, and probably
> > actually has a MAC address programmed).
> >
> >> * the renesas driver requires an FV section with a certain GUID to be
> >> present, and this driver depends on a PCD, which in both cases means
> >> that the drivers cannot be built in a generic way anyway
> >
> > Both that GUID and that PCD can live just as happily in an OptionRomPkg/
> > (or Drivers/) .dec as they can in an OpenPlatformPkg one.
> > Or am I missing something?
> 
> True. My point was rather that you can't build this driver from, say,
> EmbeddedPkg/EmbeddedPkg.dsc in a generic manner, and deploy it as a
> standalone binary.

Oh, indeed.
Hmm. Is there any way to express such a thing?
Dummy Pcd dependency or Depex or something?

> > If we have something that is truly a one-off (or superseded), I agree
> > it makes sense to integrate it into the platform code. But as far as I
> > know, both of those components are still on the market, and some
> > manufacturers still fail to program on-device config areas.
> 
> I will let you fight this battle, if you don't mind. I do agree with
> the reasoning, but it is not something I care deeply about, and I sure
> as hell don't intend to get involved with other boards that use these
> parts.

Yeah, this one is mine.
I just don't see this kind of thing not happening again (and again),
so having a precedent with regards to how we upstream it would be
useful.

> The devboard market is not cost driven, so it makes no sense
> whatsoever to get the cheapest variant of the part, like they did with
> the XHCI controller. And for an on-board PCI NIC, we're better off
> using a Marvell Yukon like SoftIron did.

/
    Leif
Ard Biesheuvel June 28, 2017, 9:50 p.m. | #6
On 28 June 2017 at 21:48, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> On Wed, Jun 28, 2017 at 09:12:04PM +0000, Ard Biesheuvel wrote:
>> >> Well, given how both these drivers are tightly coupled to Cello*, I'd
>> >> be perfectly happy making them a part of the platform in this case.
>> >
>> > Well, they're not really.
>> > Sure, that may be the only platform we have in the tree currently
>> > using it, but the minnowboard max uses the same Realtek controller
>> > (only it currently requires a separate binary driver, and probably
>> > actually has a MAC address programmed).
>> >
>> >> * the renesas driver requires an FV section with a certain GUID to be
>> >> present, and this driver depends on a PCD, which in both cases means
>> >> that the drivers cannot be built in a generic way anyway
>> >
>> > Both that GUID and that PCD can live just as happily in an OptionRomPkg/
>> > (or Drivers/) .dec as they can in an OpenPlatformPkg one.
>> > Or am I missing something?
>>
>> True. My point was rather that you can't build this driver from, say,
>> EmbeddedPkg/EmbeddedPkg.dsc in a generic manner, and deploy it as a
>> standalone binary.
>
> Oh, indeed.
> Hmm. Is there any way to express such a thing?
> Dummy Pcd dependency or Depex or something?
>

I don't think so. PCDs simply assume their default values if the DSC
does not specify a value for them.

>> > If we have something that is truly a one-off (or superseded), I agree
>> > it makes sense to integrate it into the platform code. But as far as I
>> > know, both of those components are still on the market, and some
>> > manufacturers still fail to program on-device config areas.
>>
>> I will let you fight this battle, if you don't mind. I do agree with
>> the reasoning, but it is not something I care deeply about, and I sure
>> as hell don't intend to get involved with other boards that use these
>> parts.
>
> Yeah, this one is mine.
> I just don't see this kind of thing not happening again (and again),
> so having a precedent with regards to how we upstream it would be
> useful.
>
>> The devboard market is not cost driven, so it makes no sense
>> whatsoever to get the cheapest variant of the part, like they did with
>> the XHCI controller. And for an on-board PCI NIC, we're better off
>> using a Marvell Yukon like SoftIron did.
>
> /
>     Leif