On Tue, Apr 6, 2021 at 04:54 AM, Nate DeSimone wrote: <blockquote> <blockquote>...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*)</blockquote> 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.</blockquote> 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. <blockquote> <blockquote>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.</blockquote> 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.</blockquote> 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 <div width="1" style="color:white;clear:both">_._,_._,_</div> <hr> Groups.io Links: You receive all messages sent to this group. <a target="_blank" href="https://edk2.groups.io/g/devel/message/73873">View/Reply Online (#73873)</a> | | <a target="_blank" href="https://groups.io/mt/81738382/1813853">Mute This Topic</a> | <a href="https://edk2.groups.io/g/devel/post">New Topic</a> <a href="https://edk2.groups.io/g/devel/editsub/1813853">Your Subscription</a> | <a href="mailto:devel+owner@edk2.groups.io">Contact Group Owner</a> | <a href="https://edk2.groups.io/g/devel/unsub">Unsubscribe</a> [edk2-devel-archive@redhat.com] <div width="1" style="color:white;clear:both">_._,_._,_</div>