On Tue, Apr 6, 2021 at 04:54 AM, Nate DeSimone wrote:

> 
> 
>> ...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.

Sorry, I meant that the specifics of flashing might not be relevant if no TianoCore mentor/developer will have one of these boards.

Regarding the various board models produced per generation, I see your point. For instance, the schematics and boardview I have for this board apply to all VN7-572 models (VN7-572, VN7-572G, VN7-572TG) and could somewhat describe the so-called "Black Edition" (VN7-592 boards). However, those have a Skylake PCH-H, so perhaps some GPIO/HSIO/memory configuration differs.

If anyone wants to know, the specific model I have is the Aspire VN7-572G-72NB.

> 
> 
>> 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.

Okay, nice! I suppose within EDK2, dispatch mode is more intuitive/natural. In other system firmware, well, the "Firmware Support Package" still has API mode, so it's not really my concern.

I've shared a draft of the project proposal, feel free to take a look at it at your convenience. I'd appreciate any feedback.

Best regards,
Benjamin Doron