MinPlatform Board port (GSoC 2021)

MinPlatform Board port (GSoC 2021)

[Benjamin Doron]

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

Hi all,
This may be my first time participating in GSoC and contributing to TianoCore. I'm looking to complete the MinPlatform board port task for an Acer Aspire VN7-572G laptop, which is a Skylake-U platform supported by the Kabylake FSP.

I have previously written a coreboot port for the same board, still pending review. I hope the fact that some of the board-level understanding is complete does not preclude me from participating, but many implementation details don't seem to transfer. Also, I'm looking to learn more about firmware and produce something new. I've made some other contributions to coreboot as well.

I've also previously worked on an EDK2 fork, adding and developing features for UefiPayloadPkg on coreboot (I can link it if anyone wants to see and possibly work on upstreaming my commits a different time).
I have some knowledge of C programming.

Some questions:
* Regarding the project proposal, Google recommends to avoid copying the prompt. I can write briefly about MinPlatform, but the task outline doesn't leave much room for flexibility. How do I outline this properly?
* My legal name does not match my email/preferred name. How do I resolve this (without, for example, the form being rejected because my email and first name don't match)?

I have a technical question or two as well, but they can wait.

Looking forward to working on TianoCore!

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

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

[Nate DeSimone]

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

Hi Benjamin,

Great to meet you and welcome to the TianoCore project! Glad you hear you are interested! Doing a board port to the Acer Aspire VN7-572G laptop sounds like a great GSoC project! I presume that since you already did a coreboot port that boot guard is disabled on this laptop and you have figured out how to flash images onto it 😊.

The only thing that might be a little challenging is getting a 2nd copy of that laptop for your mentor, so the possibility exists that when it comes to debugging problems you might be a little more on your own than you would be otherwise. I’m not too worried about that looking at your CB:35523, it seems like you know what you are doing.

For sure our conventions and infrastructure are different, but there are more parallels between MinPlatform and coreboot than might initially meet the eye. For example:

BoardInitBeforeMemoryInit() is roughly equivalent to bootblock_mainboard_init().
BoardInitBeforeSiliconInit() is roughly equivalent to mainboard_init().
SiliconPolicyUpdatePreMem() is roughly equivalent to mainboard_memory_init_params().

https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardInitLib/PeiBoardInitPreMemLib.c
https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardInitLib/PeiBoardInitPostMemLib.c
FSP Dispatch Mode Policy Init: https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.c
FSP API Mode Policy Init: https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiFspPolicyUpdateLib.c

I’d recommend only implementing dispatch mode for new boards. We only had the API mode version because we were busy making a version of Kaby Lake FSP that supports dispatch mode (aka AmberLakeFspBinPkg) at the same time we were developing KabyLakeOpenBoardPkg back in 2019.

One difference is we group our board ports based on the SOC they use. So your new board port would go under Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G for example.

I will give you the same caution that I gave Pedro that you will need to be careful about IP cross-contamination. Since coreboot is a GPL project and TianoCore is a BSD+Patent project, we can’t use any of their code. So you need to be careful to NOT read the coreboot Kaby Lake code (with the one exception being your patch to add the VN7-572G, since you are the exclusive author of that work you can choose to re-license it as BSD.) In general, on the days you are doing TianoCore work don’t look at any coreboot code. That way the cycle of sleep and dreams clears your head of influence.

As to your questions:


  1.  I wrote the prompt to be a bit more general. I’d recommend talking about your specific project to get MinPlatform working on the Acer Aspire VN7-572G. What specific additions or changes are you planning to make to KabylakeOpenBoardPkg to get the VN7-572G working for example? Also, talk a bit about timeline. The GSoC program breaks the summer up into two half’s: June 7 – July 16 and July 16 – August 16. What should your mentor expect to be done on July 16th? What should your mentor to expect to be done on August 16th?
  2.  I’m not 100% sure, but my guess is your email address can be whatever you want. But the application form should contain your full legal name for tax purposes. That doesn’t mean we won’t use your preferred nickname when conversing.

Hope this helps and welcome to the project!

With Best Regards,
Nate

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Benjamin Doron
Sent: Tuesday, March 30, 2021 4:28 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] MinPlatform Board port (GSoC 2021)

Hi all,
This may be my first time participating in GSoC and contributing to TianoCore. I'm looking to complete the MinPlatform board port task for an Acer Aspire VN7-572G laptop, which is a Skylake-U platform supported by the Kabylake FSP.

I have previously written a coreboot port for the same board, still pending review. I hope the fact that some of the board-level understanding is complete does not preclude me from participating, but many implementation details don't seem to transfer. Also, I'm looking to learn more about firmware and produce something new. I've made some other contributions to coreboot as well.

I've also previously worked on an EDK2 fork, adding and developing features for UefiPayloadPkg on coreboot (I can link it if anyone wants to see and possibly work on upstreaming my commits a different time).
I have some knowledge of C programming.

Some questions:

  1.  Regarding the project proposal, Google recommends to avoid copying the prompt. I can write briefly about MinPlatform, but the task outline doesn't leave much room for flexibility. How do I outline this properly?
  2.  My legal name does not match my email/preferred name. How do I resolve this (without, for example, the form being rejected because my email and first name don't match)?

I have a technical question or two as well, but they can wait.

Looking forward to working on TianoCore!


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

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

[Nate DeSimone]

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

Hi Benjamin,

I sent an email to Google on your #2 question and got the following response:

Email address, preferred name and legal name are different things. The legal name is what should match the proof of enrollment. The preferred name is what is public (what mentors will see and will be on the program site if their project is accepted) and preferred name can be whatever the student wishes it to be. This is described on the registration form as well for folks.

Feel free to direct students to our support email gsoc-support@google.com<mailto:gsoc-support@google.com> for these types of questions as well.

Hope that helps.

Thanks,
Nate

From: <devel@edk2.groups.io> on behalf of Nate DeSimone <nathaniel.l.desimone@intel.com>
Reply-To: "devel@edk2.groups.io" <devel@edk2.groups.io>, "Desimone, Nathaniel L" <nathaniel.l.desimone@intel.com>
Date: Wednesday, March 31, 2021 at 5:00 PM
To: "devel@edk2.groups.io" <devel@edk2.groups.io>, "benjamin.doron00@gmail.com" <benjamin.doron00@gmail.com>
Subject: Re: [edk2-devel] MinPlatform Board port (GSoC 2021)

Hi Benjamin,

Great to meet you and welcome to the TianoCore project! Glad you hear you are interested! Doing a board port to the Acer Aspire VN7-572G laptop sounds like a great GSoC project! I presume that since you already did a coreboot port that boot guard is disabled on this laptop and you have figured out how to flash images onto it 😊.

The only thing that might be a little challenging is getting a 2nd copy of that laptop for your mentor, so the possibility exists that when it comes to debugging problems you might be a little more on your own than you would be otherwise. I’m not too worried about that looking at your CB:35523, it seems like you know what you are doing.

For sure our conventions and infrastructure are different, but there are more parallels between MinPlatform and coreboot than might initially meet the eye. For example:

BoardInitBeforeMemoryInit() is roughly equivalent to bootblock_mainboard_init().
BoardInitBeforeSiliconInit() is roughly equivalent to mainboard_init().
SiliconPolicyUpdatePreMem() is roughly equivalent to mainboard_memory_init_params().

https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardInitLib/PeiBoardInitPreMemLib.c
https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardInitLib/PeiBoardInitPostMemLib.c
FSP Dispatch Mode Policy Init: https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.c
FSP API Mode Policy Init: https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiFspPolicyUpdateLib.c

I’d recommend only implementing dispatch mode for new boards. We only had the API mode version because we were busy making a version of Kaby Lake FSP that supports dispatch mode (aka AmberLakeFspBinPkg) at the same time we were developing KabyLakeOpenBoardPkg back in 2019.

One difference is we group our board ports based on the SOC they use. So your new board port would go under Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G for example.

I will give you the same caution that I gave Pedro that you will need to be careful about IP cross-contamination. Since coreboot is a GPL project and TianoCore is a BSD+Patent project, we can’t use any of their code. So you need to be careful to NOT read the coreboot Kaby Lake code (with the one exception being your patch to add the VN7-572G, since you are the exclusive author of that work you can choose to re-license it as BSD.) In general, on the days you are doing TianoCore work don’t look at any coreboot code. That way the cycle of sleep and dreams clears your head of influence.

As to your questions:


  1.  I wrote the prompt to be a bit more general. I’d recommend talking about your specific project to get MinPlatform working on the Acer Aspire VN7-572G. What specific additions or changes are you planning to make to KabylakeOpenBoardPkg to get the VN7-572G working for example? Also, talk a bit about timeline. The GSoC program breaks the summer up into two half’s: June 7 – July 16 and July 16 – August 16. What should your mentor expect to be done on July 16th? What should your mentor to expect to be done on August 16th?
  2.  I’m not 100% sure, but my guess is your email address can be whatever you want. But the application form should contain your full legal name for tax purposes. That doesn’t mean we won’t use your preferred nickname when conversing.

Hope this helps and welcome to the project!

With Best Regards,
Nate

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Benjamin Doron
Sent: Tuesday, March 30, 2021 4:28 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] MinPlatform Board port (GSoC 2021)

Hi all,
This may be my first time participating in GSoC and contributing to TianoCore. I'm looking to complete the MinPlatform board port task for an Acer Aspire VN7-572G laptop, which is a Skylake-U platform supported by the Kabylake FSP.

I have previously written a coreboot port for the same board, still pending review. I hope the fact that some of the board-level understanding is complete does not preclude me from participating, but many implementation details don't seem to transfer. Also, I'm looking to learn more about firmware and produce something new. I've made some other contributions to coreboot as well.

I've also previously worked on an EDK2 fork, adding and developing features for UefiPayloadPkg on coreboot (I can link it if anyone wants to see and possibly work on upstreaming my commits a different time).
I have some knowledge of C programming.

Some questions:

  1.  Regarding the project proposal, Google recommends to avoid copying the prompt. I can write briefly about MinPlatform, but the task outline doesn't leave much room for flexibility. How do I outline this properly?
  2.  My legal name does not match my email/preferred name. How do I resolve this (without, for example, the form being rejected because my email and first name don't match)?

I have a technical question or two as well, but they can wait.

Looking forward to working on TianoCore!


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

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

[Benjamin Doron]

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

On Wed, Mar 31, 2021 at 07:58 PM, Nate DeSimone wrote:

> 
> 
> 
> Hi Benjamin,
> 
> 
> 
> 
> 
> 
> 
> Great to meet you and welcome to the TianoCore project! Glad you hear you
> are interested! Doing a board port to the Acer Aspire VN7-572G laptop
> sounds like a great GSoC project! I presume that since you already did a
> coreboot port that boot guard is disabled on this laptop and you have
> figured out how to flash images onto it 😊.
> 
> 

Hi Nate,
Nice to meet you too, and thanks!

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

> 
> 
> 
> The only thing that might be a little challenging is getting a 2 nd copy of
> that laptop for your mentor, so the possibility exists that when it comes
> to debugging problems you might be a little more on your own than you
> would be otherwise. I’m not too worried about that looking at your
> CB:35523, it seems like you know what you are doing.
> 
> 

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

> 
> 
> 
> For sure our conventions and infrastructure are different, but there are
> more parallels between MinPlatform and coreboot than might initially meet
> the eye. For example:
> 
> 
> 
> 
> 
> 
> 
> BoardInitBeforeMemoryInit() is roughly equivalent to
> bootblock_mainboard_init().
> 
> 
> 
> BoardInitBeforeSiliconInit() is roughly equivalent to mainboard_init().
> 
> 
> 
> SiliconPolicyUpdatePreMem() is roughly equivalent to
> mainboard_memory_init_params().
> 
> 
> 
> 
> 
> 
> 
> https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardInitLib/PeiBoardInitPreMemLib.c
> 
> 
> 
> 
> https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardInitLib/PeiBoardInitPostMemLib.c
> 
> 
> 
> 
> FSP Dispatch Mode Policy Init: https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.c
> (
> https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.c
> )
> 
> 
> 
> FSP API Mode Policy Init: https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiFspPolicyUpdateLib.c
> (
> https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiFspPolicyUpdateLib.c
> )
> 
> 
> 
> 
> 
> 
> 
> I’d recommend only implementing dispatch mode for new boards. We only had
> the API mode version because we were busy making a version of Kaby Lake
> FSP that supports dispatch mode (aka AmberLakeFspBinPkg) at the same time
> we were developing KabyLakeOpenBoardPkg back in 2019.
> 
> 
> 
> 
> 
> 
> 
> One difference is we group our board ports based on the SOC they use. So
> your new board port would go under
> Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G for example.
> 
> 

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.

> 
> 
> 
> I will give you the same caution that I gave Pedro that you will need to
> be careful about IP cross-contamination. Since coreboot is a GPL project
> and TianoCore is a BSD+Patent project, we can’t use any of their code. So
> you need to be careful to NOT read the coreboot Kaby Lake code (with the
> one exception being your patch to add the VN7-572G, since you are the
> exclusive author of that work you can choose to re-license it as BSD.) In
> general, on the days you are doing TianoCore work don’t look at any
> coreboot code. That way the cycle of sleep and dreams clears your head of
> influence.
> 
> 

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.

> 
> 
> 
> As to your questions:
> 
> 
> 
> 
> 
> * I wrote the prompt to be a bit more general. I’d recommend talking about
> your specific project to get MinPlatform working on the Acer Aspire
> VN7-572G. What specific additions or changes are you planning to make to
> KabylakeOpenBoardPkg to get the VN7-572G working for example? Also, talk a
> bit about timeline. The GSoC program breaks the summer up into two half’s:
> June 7 – July 16 and July 16 – August 16. What should your mentor expect
> to be done on July 16th? What should your mentor to expect to be done on
> August 16th?
> * I’m not 100% sure, but my guess is your email address can be whatever
> you want. But the application form should contain your full legal name for
> tax purposes. That doesn’t mean we won’t use your preferred nickname when
> conversing.
> 

On timeline, I think I'll have more to do in the first half. Because I can't solder to the UART pins, I'll need it to boot first. (However, I was very wrong about in this when working on my coreboot port. The OS booted as soon as, if I understand correctly, FSP-T wasn't misconfigured and I set the FSP UPD for display correctly. It took a lot more time to improve the port.)

Sorry, I'll just write something up.

> 
> 
> 
> Hope this helps and welcome to the project!
> 
> 

Yes, thanks!

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

Best regards,
Benjamin Doron

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

Re: [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

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

[Benjamin Doron]

[-- 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 --]

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

[Nate DeSimone]

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

On Thu, Apr 8, 2021 at 10:33 PM, Benjamin Doron wrote:

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

Ah I understand now, yes that makes much more sense!

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

Yup, the general idea is to have FSP integrate nicely regardless of the bootloader architecture.

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

I see your application in the system and it looks great, nicely written and formatted! Thank you Benjamin we will be in touch.


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

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

[Benjamin Doron]

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

Hi again,
I forgot to mention previously that I will likely be taking one university course during the summer, likely occupying 3-5 hours per week. I don't imagine this would be an issue, but let me know if I should mention it in my project proposal (or if mentioning it here is sufficient).

> I see your application in the system and it looks great, nicely written and formatted! Thank you Benjamin we will be in touch.

Great to hear, thanks!

Best regards,
Benjamin Doron

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

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

[Nate DeSimone]

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

Hi Benjamin,

Since Google is expecting students to only work 18 hours a week on their GSoC projects this year that should be totally fine. It might not be a bad idea to mention it in your application just so we have a good paper trail.

Best Regards,
Nate

From: Benjamin Doron <benjamin.doron00@gmail.com>
Sent: Monday, April 12, 2021 11:35 AM
To: Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; devel@edk2.groups.io
Subject: Re: [edk2-devel] MinPlatform Board port (GSoC 2021)

Hi again,
I forgot to mention previously that I will likely be taking one university course during the summer, likely occupying 3-5 hours per week. I don't imagine this would be an issue, but let me know if I should mention it in my project proposal (or if mentioning it here is sufficient).

> I see your application in the system and it looks great, nicely written and formatted! Thank you Benjamin we will be in touch.

Great to hear, thanks!

Best regards,
Benjamin Doron

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

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

[Benjamin Doron]

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

Hi all,
My GSoC project proposal to work on a MinPlatform board port has been accepted, mentored by Nate DeSimone and Isaac Oram. Hopefully it will be an educational and enjoyable experience for me and a productive summer overall.

Nate and I have already discussed the project briefly on here, but in general, what would be a good way to communicate with mentors?

I've compiled a Kabylake RVP image, so my development environment is working here. I've also looked at the features directory and the board libraries to get an idea of the integration required. It appears that the libraries supporting FSP API and dispatch modes, respectively, offer different features (for instance, microcode patch in dispatch mode, HDA verb tables in API mode)? I had noted previous observations in the project proposal, but I will continue to familiarise myself with the OpenBoardPkg and MinPlatform control flow, so that I can identify and plan for possible issues in advance.

What else should I do in preparation/during the next 3 weeks?

Best regards,
Benjamin Doron

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

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

[Oram, Isaac W]

[-- Attachment #1.1: Type: text/plain, Size: 3512 bytes --]

Benjamin,

There was some discussion of FSP and MinPlatform resources on the mailing list today.  I would check those out to augment your exploration.  Especially note the MinPlatform porting training links.

I would also make sure that you have the board information you need.  Whatever datasheets and such that are required.
In addition to the Minimum Platform spec, I like to have the UEFI Spec and the UEFI Platform Initialization arch specs handy for reference.  ACPI too.
That gives you the HW and SW documents.  And you have mentors and the mailing list for a network of experts.  Those plus hardware and tools should set you up.  Minimum tools capabilities should be flash programming and serial debug.

Attached is a document I haven’t figured out where to post.  It outlines what should be the basic control flow.  I say should because I don’t think that we have fully implemented or tried to enforce yet.  Thus any given board port may have excursions.

The intention is that you can take this and use the Stage column to sort for what functions you care about for implementing the different stage functionality.
Step one, you would filter on Stage “1” and Use Case “Board Porting” and you would see all the functions you need to implement to get basic debug functionality on your board.  Then progressively work through Stage 2 through 5 respectively in order to increase functionality.  You can also look at functions by UEFI phase (SEC, PEI, DXE, SMM).  This is very Dispatch mode oriented by the way.  The Order and Absolute columns just exist to order the functions in column A in sensible ways.

This can also be useful for identifying “what didn’t happen that was supposed to”.  If you have a debug log from a working system, that often serves the same purpose.  But since the Minimum Platform Arch is intended to make new board porting easier, we don’t want to assume that we have logs of successful boots available.

I will defer to Nate on communication recommendations as all the GSoC projects will be working those out.  And I have to admit I didn’t read the GSoC documentation thoroughly yet.

Regards,
Isaac


From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Benjamin Doron
Sent: Wednesday, May 19, 2021 4:45 PM
To: Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; devel@edk2.groups.io
Subject: Re: [edk2-devel] MinPlatform Board port (GSoC 2021)

Hi all,
My GSoC project proposal to work on a MinPlatform board port has been accepted, mentored by Nate DeSimone and Isaac Oram. Hopefully it will be an educational and enjoyable experience for me and a productive summer overall.

Nate and I have already discussed the project briefly on here, but in general, what would be a good way to communicate with mentors?

I've compiled a Kabylake RVP image, so my development environment is working here. I've also looked at the features directory and the board libraries to get an idea of the integration required. It appears that the libraries supporting FSP API and dispatch modes, respectively, offer different features (for instance, microcode patch in dispatch mode, HDA verb tables in API mode)? I had noted previous observations in the project proposal, but I will continue to familiarise myself with the OpenBoardPkg and MinPlatform control flow, so that I can identify and plan for possible issues in advance.

What else should I do in preparation/during the next 3 weeks?

Best regards,
Benjamin Doron


[-- Attachment #1.2: Type: text/html, Size: 6452 bytes --]

[-- Attachment #2: Required Functions.ods --]
[-- Type: application/oleobject, Size: 22115 bytes --]

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

[Benjamin Doron]

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

Hi Isaac,
Thanks for the document. I've seen the main MinPlatform document before, which also outlines control flow, but this shows a quick overview of it all. I'll look for the MinPlatform porting training links too. Thanks.

> 
> 
> 
> I would also make sure that you have the board information you need. 
> Whatever datasheets and such that are required.
> 
> 
> 
> In addition to the Minimum Platform spec, I like to have the UEFI Spec and
> the UEFI Platform Initialization arch specs handy for reference.  ACPI
> too.
> 
> 
> 
> That gives you the HW and SW documents.  And you have mentors and the
> mailing list for a network of experts.  Those plus hardware and tools
> should set you up.  Minimum tools capabilities should be flash programming
> and serial debug.
> 
> 

I have the schematics, boardview and the datasheets that became relevant to porting (some I was unable to find, mainly regarding PCIe devices). While this board may have a working serial pad, it would be difficult to access and likely requires soldering (which I cannot do).

I planned to skip directly to stage 4 (OS), or at least 3 (shell). I should have the required board knowledge from my coreboot port. For debug logs, I think the serial port library which logs Status Codes (which will be stored in memory) could be a good fit. For early problems in PEI, I see there is a serial port library which logs to SPI flash. If these fail here, I'll have to hope the USB3 debugging feature will work.

> 
> 
> 
> I will defer to Nate on communication recommendations as all the GSoC
> projects will be working those out.  And I have to admit I didn’t read the
> GSoC documentation thoroughly yet.
> 
> 

Okay, not a problem.

Nice to meet you!

Best regards,
Benjamin Doron

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