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