From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] MinPlatform Board port (GSoC 2021) To: Nate DeSimone ,devel@edk2.groups.io From: "Benjamin Doron" X-Originating-Location: Concord, Ontario, CA (24.52.200.135) X-Originating-Platform: Linux Firefox 87 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Thu, 08 Apr 2021 10:32:40 -0700 References: In-Reply-To: Message-ID: <823.1617903160144858033@groups.io> Content-Type: multipart/alternative; boundary="saesoMNCnt20gzKIMff7" --saesoMNCnt20gzKIMff7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 6, 2021 at 04:54 AM, Nate DeSimone wrote: >=20 >=20 >> ...but this might not be relevant to anyone after all. :-) >>=20 >> Is that how this normally works? Who would organise it? (It sounds >> needlessly expensive, for someone... *shrug*) >=20 > 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 thos= e > 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 focus= ed > 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. >=20 > To be completely honest with you, this is the first time I have done GSo= C > 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 poi= nt. 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 des= cribe 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. >=20 >=20 >> Thanks for these pointers and references, I will look at them more. >>=20 >> 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 boa= rd >> initialisation perspective, they're probably the same, so this can be >> figured out later. >=20 > 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. Howeve= r, > by far the biggest goal was to make FSP integrate nicely with EDK II bas= ed > firmware. There are two ways to use dispatch mode actually. The first wa= y > as you mention uses the PeiCore included with FSP-M. The other method us= es > 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 understandin= g > 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 UP= Ds > 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 i= t at your convenience. I'd appreciate any feedback. Best regards, Benjamin Doron --saesoMNCnt20gzKIMff7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 i= s that while there may be ~100 Acer laptop designs with Sky Lake, they are = all mostly identical. They differ in screen sizes, keyboards, colors, amoun= t of RAM, etc. but they are all built on common templates. A typical OEM wi= ll 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 sh= ow 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 ext= remely likely that your work would be 95% of what is needed to get 30-50% o= f 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 se= cond 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.

Regard= ing 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 t= he so-called "Black Edition" (VN7-592 boards). However, those have a Skylak= e 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 b= oard 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 defin= itively say that yes those were all goals for dispatch mode. However, by fa= r the biggest goal was to make FSP integrate nicely with EDK II based firmw= are. 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 PeiC= ore provided by the platform firmware. This method is described in Section = 7.2.3 - "Alternate Boot Flow Description" of the FSP v2.2 specification. Wh= ile it does result in 2 copies of PeiCore, it keeps PeiCore updatable. It i= s still better than API mode because even though there are 2 copies of PeiC= ore, 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 a= re mostly the same but there are some differences. Specifically, in dispatc= h mode one does not use FSP UPDs at all. Instead, one passes the native con= figuration 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 --saesoMNCnt20gzKIMff7--