[edk2-devel] MinPlatform Board port (GSoC 2021)

[Nate DeSimone]

On Sat, Apr 3, 2021 at 09:45 PM, Benjamin Doron wrote:

> Yes, Boot Guard is disabled on this laptop (and fused, which is a slight shame). While SPI PRRs cover most of flash and BIOS control bits are partially enabled by the vendor firmware (perhaps the lock wasn't set by default, defeating the point), after one modification to the setup's (HII) IFR, these can be disabled. Flashing externally is fairly straightforward - after the keyboard comes off the flash chip is visible - but I try to avoid it because I've started having issues with the keyboard connector. It's fine once it's in and closed again...

As long as Boot Guard is disabled we can do work on it! As far as laptop designs go, sounds like one of the more straightforward ones which is great.

> ...but this might not be relevant to anyone after all. :-)
> 
> Is that how this normally works? Who would organise it? (It sounds needlessly expensive, for someone... *shrug*)

I think it is a little harsh to say this is not a relevant project. Sure, not many people have an exact Acer Aspire VN7-572G. In fact, the large OEMs like Acer on average produce 60 new laptop designs every 6 months. So yes it is true that keeping up with every single laptop design out there in the wild isn't really feasible. However, the important thing to keep in mind is that while there may be ~100 Acer laptop designs with Sky Lake, they are all mostly identical. They differ in screen sizes, keyboards, colors, amount of RAM, etc. but they are all built on common templates. A typical OEM will make maybe 1-5 motherboard designs for a given chipset (say Sky Lake-U) and then ship a ton of minor variations. Sometimes those variations will show up with different brand names on the lid. The important thing to keep in mind is that while you may be currently focused on the VN7-572G, it is extremely likely that your work would be 95% of what is needed to get 30-50% of Acer's Sky Lake laptops working.

To be completely honest with you, this is the first time I have done GSoC as well so this is a learning experience for me as well. I'll look into the feasibility of acquiring a second VN7-572G.

> Thanks for these pointers and references, I will look at them more.
> 
> As I understand it, the objective of dispatch mode was to remove code duplication in flash and possibly save boot time by minimising phase transitions. But it makes the PeiCore module non-updateable. From a board initialisation perspective, they're probably the same, so this can be figured out later.

You are talking to the guy that invented FSP dispatch mode, so I can definitively say that yes those were all goals for dispatch mode. However, by far the biggest goal was to make FSP integrate nicely with EDK II based firmware. There are two ways to use dispatch mode actually. The first way as you mention uses the PeiCore included with FSP-M. The other method uses a PeiCore provided by the platform firmware. This method is described in Section 7.2.3 - "Alternate Boot Flow Description" of the FSP v2.2 specification. While it does result in 2 copies of PeiCore, it keeps PeiCore updatable. It is still better than API mode because even though there are 2 copies of PeiCore, only 1 of them is actually used. So you only have a single instance of PEI at runtime, whereas in API mode you have two separate instances of PEI in memory at runtime. My understanding is that most OEMs choose to use FSP dispatch mode in this way. From a board initialization perspective, they are mostly the same but there are some differences. Specifically, in dispatch mode one does not use FSP UPDs at all. Instead, one passes the native configuration policy data structures that FSP uses internally, in the case of Kaby Lake that is Config Blocks stored inside a PPI.

> Understood. So, there will be two similar commits of board initialisation? I doubt I can truly dual-license the code, "BSD+GPL" might be a contradiction. However, I'm not a lawyer.

Actually I have talked with some lawyers about this very subject. So the BSD+Patent license is considered "GPL compatible" from a legal standpoint. What that means is that if you release some code under BSD+Patent, then anyone else can take that code and re-license it under the GPL without having to ask you. So in effect, BSD+Patent is already a BSD+GPL dual-license! My guess is there will be two commits of board initialization for technical reasons, but if one licenses their code under BSD+Patent then there are zero legal barriers to using that code in both projects.

> Regarding your second email, yes, that makes sense. I was just nervous about getting it wrong.

Completely understand, thanks for double checking!

With Best Regards,
Nate

> 
> Best regards,
> Benjamin Doron


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73713): https://edk2.groups.io/g/devel/message/73713
Mute This Topic: https://groups.io/mt/81738382/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-