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