public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Benjamin Doron" <benjamin.doron00@gmail.com>
To: Nate DeSimone <nathaniel.l.desimone@intel.com>,devel@edk2.groups.io
Subject: Re: [edk2-devel] MinPlatform Board port (GSoC 2021)
Date: Thu, 08 Apr 2021 10:32:40 -0700	[thread overview]
Message-ID: <823.1617903160144858033@groups.io> (raw)
In-Reply-To: <MWHPR1101MB21604CE6468F38C366C927DDCD769@MWHPR1101MB2160.namprd11.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 4182 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4184 bytes --]

  reply	other threads:[~2021-04-08 17:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-30 23:28 MinPlatform Board port (GSoC 2021) Benjamin Doron
2021-03-31 23:58 ` [edk2-devel] " Nate DeSimone
2021-04-04  4:45   ` Benjamin Doron
2021-04-06  8:54     ` Nate DeSimone
2021-04-08 17:32       ` Benjamin Doron [this message]
2021-04-09  8:01         ` Nate DeSimone
2021-04-12 18:34           ` Benjamin Doron
2021-04-13  0:46             ` Nate DeSimone
2021-05-19 23:44               ` Benjamin Doron
2021-05-20  1:13                 ` Oram, Isaac W
2021-05-22 15:32                   ` Benjamin Doron
     [not found] ` <167192C821638254.25167@groups.io>
2021-04-01 15:56   ` Nate DeSimone

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=823.1617903160144858033@groups.io \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox