1. rfc@edk2.groups.io
  2. Messages
   Date   
Re: [edk2-devel] [RFC] Support Both MM Traditional and Standalone Drivers with One MM Core

Siyuan, Fu <siyuan.fu@...>
 

Hi, Jiewen/Laszlo

Thanks for your comments on this.

Hi, Ard/Sami/Supreeth

Since ARM based platforms are currently the major user of the MM Core in StandaloneMmPkg, I would like to hear you idea about this change. Do you have any concern about adding MM Traditional driver support to the Standalone MM Core?

Best Regards
Siyuan

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek
Sent: 2020年10月9日 21:08
To: Yao, Jiewen <jiewen.yao@intel.com>; rfc@edk2.groups.io;
devel@edk2.groups.io; Fu, Siyuan <siyuan.fu@intel.com>
Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>;
ard.biesheuvel@arm.com; sami.mujawar@arm.com;
supreeth.venkatesh@arm.com
Subject: Re: [edk2-rfc] [edk2-devel] [RFC] Support Both MM Traditional and
Standalone Drivers with One MM Core

On 10/09/20 14:23, Yao, Jiewen wrote:
IMHO, StandaloneMm (in StandaloneMmPkg) should be the long term
direction to replace the traditional MM (in MdeModulePkg).

If we want to do some enhancement, I prefer #2 to update the one in
StandaloneMmPkg.
Once we retire transitional MM, we can delete the PiSmmCore in
MdeModulePkg.

This is a good idea -- when we think we are ready to retire PiSmmCore in
MdeModulePkg, because we think that StandaloneMmPkg can fully replace
it, platforms can evaluate the latter (hopefully with some simple DSC /
FDF modifications), and report back whether they see regressions or
whether StandaloneMmPkg behaves as a drop-in replacement indeed, for
PiSmmCore in MdeModulePkg.

Thanks
Laszlo


If we choose #1, the EDKII will have two standaloneMm Cores (the one in
StandaloneMmPkg and the one in MdeModulePkg), which may bring lots of
confusing and we may need merge them later.

Thank you
Yao Jiewen

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Laszlo Ersek
Sent: Friday, October 9, 2020 7:56 PM
To: devel@edk2.groups.io; Fu, Siyuan <siyuan.fu@intel.com>;
rfc@edk2.groups.io
Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>;
ard.biesheuvel@arm.com; sami.mujawar@arm.com; Yao, Jiewen
<jiewen.yao@intel.com>; supreeth.venkatesh@arm.com
Subject: Re: [edk2-rfc] [edk2-devel] [RFC] Support Both MM Traditional and
Standalone Drivers with One MM Core

On 10/09/20 07:22, Siyuan, Fu wrote:
Hi, All

This email is to collect feedback about making one common EDK2 MM Core
driver to support both MM Traditional drivers and MM Standalone drivers.

We know that PI Spec defines two types of MM-related drivers: MM
Traditional Drivers and MM Standalone Drivers. There are two MM Core
modules exist in EDK2 but each of them can only support one single type of
MM
drivers:
- PiSmmCore in MdeModulePkg supports MM Traditional driver dispatch.
It
doesn't have FV parsing logic and relies on EFI Firmware Volume2 Protocol
for
driver discovery. It doesn't support MM Standalone driver.
- StandaloneMmCore in StandaloneMmPkg supports MM Standalone
driver
dispatch. It has FV parsing and decompress logic but only limited to one single
firmware volume (called standalone BFV in code). It doesn't support MM
Traditional driver.

However, a platform may want to have both of the two types of MM drivers
coexist in its firmware, for example, when it tries to transfer from Traditional
MM mode to Standalone MM mode, in a stage by stage manner. However,
it's
not possible with current EDK2 MM Core because of above limitations. Thus,
here we propose to have a common MM Core module in EDK2, which could:
- Support both MM Traditional drivers and MM Standalone drivers.
- Use shared Depex evaluation when dispatching all the MM drivers.
- Use a shared MM System Table when invoking all the MM drivers' entry
point, which mean handle/protocol database is shared.
- Have self-contained FV parsing and driver discovery capability.

We realized there could be 2 possible options to make this happen:
- Option 1: Update the MdeModulePkg Core. In this approach, we will
need
to add the FV decompress, driver discovery and MM Standalone driver
dispatcher to the PiSmmCore module in MdeModulePkg.
- Option 2: Update the StandaloneMmPkg Core. Which means adding MM
Traditional dispatcher and multiple FV support to existing standalone Core in
StandaloneMmPkg. Will also need to add PEI/DXE IPL module to invoke the
Standalone MM Core and pass UEFI System Table to it.

The option 1 will have less impact to those platforms which only use MM
Standalone drivers currently, because those platforms can stay with the
unchanged Standalone MM Core. While option 2 looks more like a clean
solution because it could support all the cases (Traditional MM only,
Standalone
MM only, and mix-used platform). So I'd like to hear the community's
feedback
about which option is preferred, and let me know if you have any concerns
with
this change. Thanks!

Which method is the least risky with regard to regressions, in your opinion?

I tend to prefer #2. Either option is neutral for ArmVirtPkg at the
moment, and option#2 is safer for OvmfPkg (no risk of regression). Thus
far, there has not been any need (that I know of) for OVMF to support
standalone MM drivers.

Furthermore, if we wanted to add Management Mode support to ArmVirtPkg
at some (later) point, I believe (?) we'd just use StandaloneMmPkg right
from the start.

I.e., from my perspective, mixing MM module types, for some kind of
transition for a platform from one MM mode to another, is not
immediately useful; so my goal is to minimize the risk of regressions.

Thanks
Laszlo
Re: [edk2-devel] [RFC] Support Both MM Traditional and Standalone Drivers with One MM Core

Yao, Jiewen
 

IMHO, StandaloneMm (in StandaloneMmPkg) should be the long term direction to replace the traditional MM (in MdeModulePkg).

If we want to do some enhancement, I prefer #2 to update the one in StandaloneMmPkg.
Once we retire transitional MM, we can delete the PiSmmCore in MdeModulePkg.

If we choose #1, the EDKII will have two standaloneMm Cores (the one in StandaloneMmPkg and the one in MdeModulePkg), which may bring lots of confusing and we may need merge them later.

Thank you
Yao Jiewen

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Laszlo Ersek
Sent: Friday, October 9, 2020 7:56 PM
To: devel@edk2.groups.io; Fu, Siyuan <siyuan.fu@intel.com>;
rfc@edk2.groups.io
Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>;
ard.biesheuvel@arm.com; sami.mujawar@arm.com; Yao, Jiewen
<jiewen.yao@intel.com>; supreeth.venkatesh@arm.com
Subject: Re: [edk2-rfc] [edk2-devel] [RFC] Support Both MM Traditional and
Standalone Drivers with One MM Core

On 10/09/20 07:22, Siyuan, Fu wrote:
Hi, All

This email is to collect feedback about making one common EDK2 MM Core
driver to support both MM Traditional drivers and MM Standalone drivers.

We know that PI Spec defines two types of MM-related drivers: MM
Traditional Drivers and MM Standalone Drivers. There are two MM Core
modules exist in EDK2 but each of them can only support one single type of MM
drivers:
- PiSmmCore in MdeModulePkg supports MM Traditional driver dispatch. It
doesn't have FV parsing logic and relies on EFI Firmware Volume2 Protocol for
driver discovery. It doesn't support MM Standalone driver.
- StandaloneMmCore in StandaloneMmPkg supports MM Standalone driver
dispatch. It has FV parsing and decompress logic but only limited to one single
firmware volume (called standalone BFV in code). It doesn't support MM
Traditional driver.

However, a platform may want to have both of the two types of MM drivers
coexist in its firmware, for example, when it tries to transfer from Traditional
MM mode to Standalone MM mode, in a stage by stage manner. However, it's
not possible with current EDK2 MM Core because of above limitations. Thus,
here we propose to have a common MM Core module in EDK2, which could:
- Support both MM Traditional drivers and MM Standalone drivers.
- Use shared Depex evaluation when dispatching all the MM drivers.
- Use a shared MM System Table when invoking all the MM drivers' entry
point, which mean handle/protocol database is shared.
- Have self-contained FV parsing and driver discovery capability.

We realized there could be 2 possible options to make this happen:
- Option 1: Update the MdeModulePkg Core. In this approach, we will need
to add the FV decompress, driver discovery and MM Standalone driver
dispatcher to the PiSmmCore module in MdeModulePkg.
- Option 2: Update the StandaloneMmPkg Core. Which means adding MM
Traditional dispatcher and multiple FV support to existing standalone Core in
StandaloneMmPkg. Will also need to add PEI/DXE IPL module to invoke the
Standalone MM Core and pass UEFI System Table to it.

The option 1 will have less impact to those platforms which only use MM
Standalone drivers currently, because those platforms can stay with the
unchanged Standalone MM Core. While option 2 looks more like a clean
solution because it could support all the cases (Traditional MM only, Standalone
MM only, and mix-used platform). So I'd like to hear the community's feedback
about which option is preferred, and let me know if you have any concerns with
this change. Thanks!

Which method is the least risky with regard to regressions, in your opinion?

I tend to prefer #2. Either option is neutral for ArmVirtPkg at the
moment, and option#2 is safer for OvmfPkg (no risk of regression). Thus
far, there has not been any need (that I know of) for OVMF to support
standalone MM drivers.

Furthermore, if we wanted to add Management Mode support to ArmVirtPkg
at some (later) point, I believe (?) we'd just use StandaloneMmPkg right
from the start.

I.e., from my perspective, mixing MM module types, for some kind of
transition for a platform from one MM mode to another, is not
immediately useful; so my goal is to minimize the risk of regressions.

Thanks
Laszlo
Re: [edk2-devel] [RFC] Support Both MM Traditional and Standalone Drivers with One MM Core

Laszlo Ersek
 

On 10/09/20 14:23, Yao, Jiewen wrote:
IMHO, StandaloneMm (in StandaloneMmPkg) should be the long term direction to replace the traditional MM (in MdeModulePkg).

If we want to do some enhancement, I prefer #2 to update the one in StandaloneMmPkg.
Once we retire transitional MM, we can delete the PiSmmCore in MdeModulePkg.
This is a good idea -- when we think we are ready to retire PiSmmCore in
MdeModulePkg, because we think that StandaloneMmPkg can fully replace
it, platforms can evaluate the latter (hopefully with some simple DSC /
FDF modifications), and report back whether they see regressions or
whether StandaloneMmPkg behaves as a drop-in replacement indeed, for
PiSmmCore in MdeModulePkg.

Thanks
Laszlo


If we choose #1, the EDKII will have two standaloneMm Cores (the one in StandaloneMmPkg and the one in MdeModulePkg), which may bring lots of confusing and we may need merge them later.

Thank you
Yao Jiewen

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Laszlo Ersek
Sent: Friday, October 9, 2020 7:56 PM
To: devel@edk2.groups.io; Fu, Siyuan <siyuan.fu@intel.com>;
rfc@edk2.groups.io
Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>;
ard.biesheuvel@arm.com; sami.mujawar@arm.com; Yao, Jiewen
<jiewen.yao@intel.com>; supreeth.venkatesh@arm.com
Subject: Re: [edk2-rfc] [edk2-devel] [RFC] Support Both MM Traditional and
Standalone Drivers with One MM Core

On 10/09/20 07:22, Siyuan, Fu wrote:
Hi, All

This email is to collect feedback about making one common EDK2 MM Core
driver to support both MM Traditional drivers and MM Standalone drivers.

We know that PI Spec defines two types of MM-related drivers: MM
Traditional Drivers and MM Standalone Drivers. There are two MM Core
modules exist in EDK2 but each of them can only support one single type of MM
drivers:
- PiSmmCore in MdeModulePkg supports MM Traditional driver dispatch. It
doesn't have FV parsing logic and relies on EFI Firmware Volume2 Protocol for
driver discovery. It doesn't support MM Standalone driver.
- StandaloneMmCore in StandaloneMmPkg supports MM Standalone driver
dispatch. It has FV parsing and decompress logic but only limited to one single
firmware volume (called standalone BFV in code). It doesn't support MM
Traditional driver.

However, a platform may want to have both of the two types of MM drivers
coexist in its firmware, for example, when it tries to transfer from Traditional
MM mode to Standalone MM mode, in a stage by stage manner. However, it's
not possible with current EDK2 MM Core because of above limitations. Thus,
here we propose to have a common MM Core module in EDK2, which could:
- Support both MM Traditional drivers and MM Standalone drivers.
- Use shared Depex evaluation when dispatching all the MM drivers.
- Use a shared MM System Table when invoking all the MM drivers' entry
point, which mean handle/protocol database is shared.
- Have self-contained FV parsing and driver discovery capability.

We realized there could be 2 possible options to make this happen:
- Option 1: Update the MdeModulePkg Core. In this approach, we will need
to add the FV decompress, driver discovery and MM Standalone driver
dispatcher to the PiSmmCore module in MdeModulePkg.
- Option 2: Update the StandaloneMmPkg Core. Which means adding MM
Traditional dispatcher and multiple FV support to existing standalone Core in
StandaloneMmPkg. Will also need to add PEI/DXE IPL module to invoke the
Standalone MM Core and pass UEFI System Table to it.

The option 1 will have less impact to those platforms which only use MM
Standalone drivers currently, because those platforms can stay with the
unchanged Standalone MM Core. While option 2 looks more like a clean
solution because it could support all the cases (Traditional MM only, Standalone
MM only, and mix-used platform). So I'd like to hear the community's feedback
about which option is preferred, and let me know if you have any concerns with
this change. Thanks!

Which method is the least risky with regard to regressions, in your opinion?

I tend to prefer #2. Either option is neutral for ArmVirtPkg at the
moment, and option#2 is safer for OvmfPkg (no risk of regression). Thus
far, there has not been any need (that I know of) for OVMF to support
standalone MM drivers.

Furthermore, if we wanted to add Management Mode support to ArmVirtPkg
at some (later) point, I believe (?) we'd just use StandaloneMmPkg right
from the start.

I.e., from my perspective, mixing MM module types, for some kind of
transition for a platform from one MM mode to another, is not
immediately useful; so my goal is to minimize the risk of regressions.

Thanks
Laszlo
Re: [edk2-devel] [RFC] Support Both MM Traditional and Standalone Drivers with One MM Core

Laszlo Ersek
 

On 10/09/20 07:22, Siyuan, Fu wrote:
Hi, All

This email is to collect feedback about making one common EDK2 MM Core driver to support both MM Traditional drivers and MM Standalone drivers.

We know that PI Spec defines two types of MM-related drivers: MM Traditional Drivers and MM Standalone Drivers. There are two MM Core modules exist in EDK2 but each of them can only support one single type of MM drivers:
- PiSmmCore in MdeModulePkg supports MM Traditional driver dispatch. It doesn't have FV parsing logic and relies on EFI Firmware Volume2 Protocol for driver discovery. It doesn't support MM Standalone driver.
- StandaloneMmCore in StandaloneMmPkg supports MM Standalone driver dispatch. It has FV parsing and decompress logic but only limited to one single firmware volume (called standalone BFV in code). It doesn't support MM Traditional driver.

However, a platform may want to have both of the two types of MM drivers coexist in its firmware, for example, when it tries to transfer from Traditional MM mode to Standalone MM mode, in a stage by stage manner. However, it's not possible with current EDK2 MM Core because of above limitations. Thus, here we propose to have a common MM Core module in EDK2, which could:
- Support both MM Traditional drivers and MM Standalone drivers.
- Use shared Depex evaluation when dispatching all the MM drivers.
- Use a shared MM System Table when invoking all the MM drivers' entry point, which mean handle/protocol database is shared.
- Have self-contained FV parsing and driver discovery capability.

We realized there could be 2 possible options to make this happen:
- Option 1: Update the MdeModulePkg Core. In this approach, we will need to add the FV decompress, driver discovery and MM Standalone driver dispatcher to the PiSmmCore module in MdeModulePkg.
- Option 2: Update the StandaloneMmPkg Core. Which means adding MM Traditional dispatcher and multiple FV support to existing standalone Core in StandaloneMmPkg. Will also need to add PEI/DXE IPL module to invoke the Standalone MM Core and pass UEFI System Table to it.

The option 1 will have less impact to those platforms which only use MM Standalone drivers currently, because those platforms can stay with the unchanged Standalone MM Core. While option 2 looks more like a clean solution because it could support all the cases (Traditional MM only, Standalone MM only, and mix-used platform). So I'd like to hear the community's feedback about which option is preferred, and let me know if you have any concerns with this change. Thanks!
Which method is the least risky with regard to regressions, in your opinion?

I tend to prefer #2. Either option is neutral for ArmVirtPkg at the
moment, and option#2 is safer for OvmfPkg (no risk of regression). Thus
far, there has not been any need (that I know of) for OVMF to support
standalone MM drivers.

Furthermore, if we wanted to add Management Mode support to ArmVirtPkg
at some (later) point, I believe (?) we'd just use StandaloneMmPkg right
from the start.

I.e., from my perspective, mixing MM module types, for some kind of
transition for a platform from one MM mode to another, is not
immediately useful; so my goal is to minimize the risk of regressions.

Thanks
Laszlo
[RFC] Support Both MM Traditional and Standalone Drivers with One MM Core

Siyuan, Fu <siyuan.fu@...>
 

Hi, All

This email is to collect feedback about making one common EDK2 MM Core driver to support both MM Traditional drivers and MM Standalone drivers.

We know that PI Spec defines two types of MM-related drivers: MM Traditional Drivers and MM Standalone Drivers. There are two MM Core modules exist in EDK2 but each of them can only support one single type of MM drivers:
- PiSmmCore in MdeModulePkg supports MM Traditional driver dispatch. It doesn't have FV parsing logic and relies on EFI Firmware Volume2 Protocol for driver discovery. It doesn't support MM Standalone driver.
- StandaloneMmCore in StandaloneMmPkg supports MM Standalone driver dispatch. It has FV parsing and decompress logic but only limited to one single firmware volume (called standalone BFV in code). It doesn't support MM Traditional driver.

However, a platform may want to have both of the two types of MM drivers coexist in its firmware, for example, when it tries to transfer from Traditional MM mode to Standalone MM mode, in a stage by stage manner. However, it's not possible with current EDK2 MM Core because of above limitations. Thus, here we propose to have a common MM Core module in EDK2, which could:
- Support both MM Traditional drivers and MM Standalone drivers.
- Use shared Depex evaluation when dispatching all the MM drivers.
- Use a shared MM System Table when invoking all the MM drivers' entry point, which mean handle/protocol database is shared.
- Have self-contained FV parsing and driver discovery capability.

We realized there could be 2 possible options to make this happen:
- Option 1: Update the MdeModulePkg Core. In this approach, we will need to add the FV decompress, driver discovery and MM Standalone driver dispatcher to the PiSmmCore module in MdeModulePkg.
- Option 2: Update the StandaloneMmPkg Core. Which means adding MM Traditional dispatcher and multiple FV support to existing standalone Core in StandaloneMmPkg. Will also need to add PEI/DXE IPL module to invoke the Standalone MM Core and pass UEFI System Table to it.

The option 1 will have less impact to those platforms which only use MM Standalone drivers currently, because those platforms can stay with the unchanged Standalone MM Core. While option 2 looks more like a clean solution because it could support all the cases (Traditional MM only, Standalone MM only, and mix-used platform). So I'd like to hear the community's feedback about which option is preferred, and let me know if you have any concerns with this change. Thanks!

Best Regards
Siyuan
Re: [edk2-devel] [edk2-rfc] [RFC] Request to move MinPlatformPkg out of the Intel folder

Nate DeSimone
 

Hey Leif,

On 10/4/20, 3:00 PM, Leif Lindholm <leif@nuviainc.com> wrote:

On Sun, Oct 04, 2020 at 20:46:50 +0000, Desimone, Nathaniel L wrote:
Hey Hot,

On 10/1/20, 9:20 PM, Tian, Hot <hot.tian@intel.com> wrote:

Why not move to edk2 repo?
Edk2 would be a good place as well.
If it is being used by any external consumers, then yes edk2 makes perfect
sense.

It might still make sense to start prototyping that usage in a vendor-neutral
section of edk2-platforms.
It is actually seeing a pretty large amount of external consumption right now. To my knowledge, every IBV and most OEMs depend on MinPlatformPkg for Tiger Lake UEFI firmware implementations. Given the interest we have seen here for non-Intel MinPlatform firmware, I believe that edk2 is likely the best place for it.

Thanks,
Nate
Re: [edk2-devel] [RFC] Request to move MinPlatformPkg out of the Intel folder

Nate DeSimone
 

Hey Bret,

On 10/5/20, 12:35 PM, Bret Barkelew <bret.barkelew@microsoft.com> wrote:

Perhaps this is the time we get EdkRepo and Stuart to join forces and
become the one-true-repo-management solution for EDK.
I'm not opposed to that idea, but it sounds like a totally different RFC 😊. We also need to be cognizant that there are many people downstream from TianoCore that don't use any repo management tooling.

Thanks,
Nate
Re: [edk2-devel] [RFC] Request to move MinPlatformPkg out of the Intel folder

Bret Barkelew <bret.barkelew@...>
 

I think that to support anything larger that proofs of concept – in other words, to support the actual platforms that we WANT to consume this trusted, common code – we already have to support recursive submodules.

Our team HIGHLY recommends that platforms submodule edk2 rather than forking it, which means (for most) that they are already invested in repo management tooling of one form or another.

Perhaps this is the time we get EdkRepo and Stuart to join forces and become the one-true-repo-management solution for EDK.

Or we could all move to Rust and start complaining about Cargo immediately. 😉

- Bret

From: Nate DeSimone via groups.io<mailto:nathaniel.l.desimone=intel.com@groups.io>
Sent: Sunday, October 4, 2020 2:02 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; spbrogan@outlook.com<mailto:spbrogan@outlook.com>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>
Cc: Leif Lindholm<mailto:leif@nuviainc.com>; Laszlo Ersek<mailto:lersek@redhat.com>; Ard Biesheuvel<mailto:ard.biesheuvel@arm.com>; Kirkendall, Garrett<mailto:garrett.kirkendall@amd.com>; Lendacky, Thomas<mailto:thomas.lendacky@amd.com>; thomas.abraham@arm.com<mailto:thomas.abraham@arm.com>; Frank.Orr@dell.com<mailto:Frank.Orr@dell.com>; Jim Dailey<mailto:jim.dailey@dell.com>; Abner Chang<mailto:abner.chang@hpe.com>; Wang, Sunny (HPS SW)<mailto:sunnywang@hpe.com>; Daniel Schaefer<mailto:daniel.schaefer@hpe.com>; Liming Gao<mailto:gaoliming@byosoft.com.cn>; Tim Lewis<mailto:tim.lewis@insyde.com>; Kevin D Davis<mailto:kevin.davis@insyde.com>; Felix Polyudov<mailto:felixp@ami.com>; Kinney, Michael D<mailto:michael.d.kinney@intel.com>; Oram, Isaac W<mailto:isaac.w.oram@intel.com>; Ni, Ray<mailto:ray.ni@intel.com>
Subject: [EXTERNAL] Re: [edk2-devel] [RFC] Request to move MinPlatformPkg out of the Intel folder

Hey Sean,

On 10/2/20, 8:37 PM, Sean <spbrogan@outlook.com> wrote:
I could imagine a path where edk2-platforms starts using submodules (or
something with similar properties) and then pulls in the "new"
MinPlatform repo.
IMHO I'm starting to get annoyed at the number of submodules in edk2 at this point. It's getting to the point that we are in danger of needing recursive submodule clones, which are a huge PITA for anyone not using either stuart or EdkRepo. I'd rather not get to that point.

Thanks,
Nate
Re: [edk2-devel] [edk2-rfc] [RFC] Request to move MinPlatformPkg out of the Intel folder

Leif Lindholm
 

On Sun, Oct 04, 2020 at 20:46:50 +0000, Desimone, Nathaniel L wrote:
Hey Hot,

On 10/1/20, 9:20 PM, Tian, Hot <hot.tian@intel.com> wrote:

Why not move to edk2 repo?
Edk2 would be a good place as well.
If it is being used by any external consumers, then yes edk2 makes
perfect sense.

It might still make sense to start prototyping that usage in a
vendor-neutral section of edk2-platforms.

/
Leif
Re: [edk2-devel] [RFC] Request to move MinPlatformPkg out of the Intel folder

Nate DeSimone
 

Hey Sean,

On 10/2/20, 8:37 PM, Sean <spbrogan@outlook.com> wrote:
I could imagine a path where edk2-platforms starts using submodules (or
something with similar properties) and then pulls in the "new"
MinPlatform repo.
IMHO I'm starting to get annoyed at the number of submodules in edk2 at this point. It's getting to the point that we are in danger of needing recursive submodule clones, which are a huge PITA for anyone not using either stuart or EdkRepo. I'd rather not get to that point.

Thanks,
Nate
Re: [edk2-devel] [edk2-rfc] [RFC] Request to move MinPlatformPkg out of the Intel folder

Nate DeSimone
 

Hey Hot,

On 10/1/20, 9:20 PM, Tian, Hot <hot.tian@intel.com> wrote:

Why not move to edk2 repo?
Edk2 would be a good place as well.

Thanks,
Nate
Re: [edk2-devel] [RFC] Request to move MinPlatformPkg out of the Intel folder

Sean
 

Nate,

I would actually propose you go further. In Project Mu we consume MinPlatform as its own repo. This is because it has its own lifetime and spans multiple product generations and hopefully someday multiple architectures/silicon providers. By mixing it in with all the platform code of edk2-platforms it is harder to leverage in other projects.

https://github.com/microsoft/mu_common_intel_min_platform

I could imagine a path where edk2-platforms starts using submodules (or something with similar properties) and then pulls in the "new" MinPlatform repo. Then as code in the current package gets cleaned up and generalized for the firmware ecosystem it could be moved to the new MinPlatform repo.

Another thread with open edk2-platform questions: https://edk2.groups.io/g/devel/message/65544


Thanks
Sean

On 9/30/2020 4:17 PM, Nate DeSimone wrote:
Hi Everyone,
This has come up informally a couple of times already, but I do think that it would be beneficial to move MinPlatformPkg out of the Platform/Intel folder and into a vendor neutral folder. MinPlatform really isn't Intel specific, it's just "middleware" that is intended to make it easier and faster to build EDK II based firmware. We have always intended MinPlatform to be vendor neutral, and it would be great to see MinPlatform based implementations for non-Intel silicon. Anyone working with EDK II should feel welcome to work with us on MinPlatform, regardless of the SoC in use.
To that end, I propose that we move MinPlatformPkg out of edk2-platforms/Platform/Intel to edk2-platforms/Platform/MinPlatformPkg. It might also make sense to move edk2-platforms/Platform/Intel/Tools and edk2-platforms/Platform/Intel/build_bios.py to edk2-platforms/Platform as well since those are all useful for building MinPlatform based firmware, but I could also see that being something for another time. Let me know what you think!
Thanks,
Nate
Re: [edk2-devel] [edk2-rfc] [RFC] Request to move MinPlatformPkg out of the Intel folder

Hot Tian
 

Why not move to edk2 repo?

Thanks,
Hot

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Leif Lindholm
Sent: Friday, October 02, 2020 7:26
To: Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>
Cc: rfc@edk2.groups.io; devel@edk2.groups.io; Laszlo Ersek <lersek@redhat.com>; Ard Biesheuvel <ard.biesheuvel@arm.com>; Kirkendall, Garrett <garrett.kirkendall@amd.com>; Lendacky, Thomas <thomas.lendacky@amd.com>; thomas.abraham@arm.com; Frank.Orr@dell.com; Jim Dailey <jim.dailey@dell.com>; Abner Chang <abner.chang@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; Daniel Schaefer <daniel.schaefer@hpe.com>; Liming Gao <gaoliming@byosoft.com.cn>; Tim Lewis <tim.lewis@insyde.com>; Kevin@Insyde <kevin.davis@insyde.com>; Felix Polyudov <felixp@ami.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Oram, Isaac W <isaac.w.oram@intel.com>; Ni, Ray <ray.ni@intel.com>
Subject: Re: [edk2-devel] [edk2-rfc] [RFC] Request to move MinPlatformPkg out of the Intel folder

On Thu, Oct 01, 2020 at 23:20:01 +0000, Desimone, Nathaniel L wrote:
One thing I think is needed for this to move out of Platform/Intel
would be a ReadMe.rst describing the intended real-world use.
Some of this lives in Platform/Intel/Readme.md today.
Could we start with a set moving this text into a separate file
under MinPlatformPkg and rework that into something that stands on its own?
Yeah agreed, given that the feedback on this RFC has been pretty
positive thus far, I'm planning on making a patch series for this.
I'll make these changes part of said patch series.
Sounds good.

If I was to bikeshed, I'd probably suggest
Platform/TianoCore/MinPlatformPkg. Oops, guess I did.
Seems a little superfluous to me... isn't edk2-platforms part of
TianoCore by definition? 😊
It is. It's just the pattern for everything else in edk2-platforms (apart from OptionRomPkg, which was just transplanted from edk2) exists in the form of <section>/$VENDOR/. Platform/MinPlatformPkg would be the only bare package in Platform/.

I think we should see this as a separate step, regardless.

I do think we should be able to do better on sharing some of this
platform image tooling cross-architecture (even moreso now Risc-V is
involved), but I would prefer for us to spend the effort of
identifying the intersections upfront before we start uploading
tools to places where they look generic and may confuse people.

Maybe we should raise this part as a BZ?
Yup, sounds like good next steps to me. I've filed the BZ:
https://bugzilla.tianocore.org/show_bug.cgi?id=2992
Top man.

Best Regards,

Leif
Re: [edk2-devel] [RFC] Request to move MinPlatformPkg out of the Intel folder

Nate DeSimone
 

Hey Laszlo,

On 9/30/20, 11:54 PM, Laszlo Ersek <lersek@redhat.com> wrote:

Since I've been CC'd -- the MinPlatformPkg move seems logical to me.
Regarding the tools, I guess it depends on how many Intel-specific quirks
they contain. I guess they could be moved too after a potential refactoring /
splitting.
With regard to the tool refactoring, Leif had the same feedback and I completely agree with both of you. I have filed a BZ to track the tool refactoring as a separate item: https://bugzilla.tianocore.org/show_bug.cgi?id=2992

Thanks,
Nate
Re: [RFC] Request to move MinPlatformPkg out of the Intel folder

Leif Lindholm
 

On Thu, Oct 01, 2020 at 23:20:01 +0000, Desimone, Nathaniel L wrote:
One thing I think is needed for this to move out of Platform/Intel would be a
ReadMe.rst describing the intended real-world use.
Some of this lives in Platform/Intel/Readme.md today.
Could we start with a set moving this text into a separate file under
MinPlatformPkg and rework that into something that stands on its own?
Yeah agreed, given that the feedback on this RFC has been pretty
positive thus far, I'm planning on making a patch series for
this. I'll make these changes part of said patch series.
Sounds good.

If I was to bikeshed, I'd probably suggest
Platform/TianoCore/MinPlatformPkg. Oops, guess I did.
Seems a little superfluous to me... isn't edk2-platforms part of TianoCore by definition? 😊
It is. It's just the pattern for everything else in edk2-platforms
(apart from OptionRomPkg, which was just transplanted from edk2)
exists in the form of <section>/$VENDOR/. Platform/MinPlatformPkg
would be the only bare package in Platform/.

I think we should see this as a separate step, regardless.

I do think we should be able to do better on sharing some of this platform
image tooling cross-architecture (even moreso now Risc-V is involved), but I
would prefer for us to spend the effort of identifying the intersections
upfront before we start uploading tools to places where they look generic
and may confuse people.

Maybe we should raise this part as a BZ?
Yup, sounds like good next steps to me. I've filed the BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2992
Top man.

Best Regards,

Leif
Re: [RFC] Request to move MinPlatformPkg out of the Intel folder

Nate DeSimone
 

Hey Leif,

On 10/1/20, 4:52 AM, " Leif Lindholm" <leif@nuviainc.com> wrote:

Very positive to this on the whole.
Happy to hear!

I have only been following MinPlatformPkg peripherally - at the time it was
merged, I did not have the bandwidth to look into it and help make it cross-
architecture from the start, so I mostly refrained from comment.

One thing I think is needed for this to move out of Platform/Intel would be a
ReadMe.rst describing the intended real-world use.
Some of this lives in Platform/Intel/Readme.md today.
Could we start with a set moving this text into a separate file under
MinPlatformPkg and rework that into something that stands on its own?
Yeah agreed, given that the feedback on this RFC has been pretty positive thus far, I'm planning on making a patch series for this. I'll make these changes part of said patch series.

If I was to bikeshed, I'd probably suggest
Platform/TianoCore/MinPlatformPkg. Oops, guess I did.
Seems a little superfluous to me... isn't edk2-platforms part of TianoCore by definition? 😊

I think we should see this as a separate step, regardless.

I do think we should be able to do better on sharing some of this platform
image tooling cross-architecture (even moreso now Risc-V is involved), but I
would prefer for us to spend the effort of identifying the intersections
upfront before we start uploading tools to places where they look generic
and may confuse people.

Maybe we should raise this part as a BZ?
Yup, sounds like good next steps to me. I've filed the BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2992

Thanks,
Nate
Re: [edk2-devel] [RFC] Request to move MinPlatformPkg out of the Intel folder

christian.walter@...
 

Hi Nate,

totally agree with you.

Best,

Chris

On 10/1/20 9:43 AM, Wim Vervoorn wrote:
Hi Nate,

I agree this sounds like a good plan. The MinPlatform should be as generic as possible and suitable for all architectures.

In fact it is similar to the UEFIPayload package wich is also standalone.

Best Regards,
Wim Vervoorn

Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands

T : +31-(0)73-594 46 64
E : wvervoorn@eltan.com
W : http://www.eltan.com


"This message contains confidential information. Unless you are the intended recipient of this message, any use of this message is strictly prohibited. If you have received this message in error, please immediately notify the sender by telephone +31-(0)73-5944664 or reply email, and immediately delete this message and all copies."


-----Original Message-----
From: rfc@edk2.groups.io [mailto:rfc@edk2.groups.io] On Behalf Of Nate DeSimone
Sent: Thursday, October 1, 2020 1:17 AM
To: devel@edk2.groups.io; rfc@edk2.groups.io
Cc: Leif Lindholm <leif@nuviainc.com>; Laszlo Ersek <lersek@redhat.com>; Ard Biesheuvel <ard.biesheuvel@arm.com>; Kirkendall, Garrett <garrett.kirkendall@amd.com>; Lendacky, Thomas <thomas.lendacky@amd.com>; thomas.abraham@arm.com; Frank.Orr@dell.com; Jim Dailey <jim.dailey@dell.com>; Abner Chang <abner.chang@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; Daniel Schaefer <daniel.schaefer@hpe.com>; Liming Gao <gaoliming@byosoft.com.cn>; Tim Lewis <tim.lewis@insyde.com>; Kevin@Insyde <kevin.davis@insyde.com>; Felix Polyudov <felixp@ami.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Oram, Isaac W <isaac.w.oram@intel.com>; Ni, Ray <ray.ni@intel.com>
Subject: [edk2-rfc] [RFC] Request to move MinPlatformPkg out of the Intel folder

Hi Everyone,

This has come up informally a couple of times already, but I do think that it would be beneficial to move MinPlatformPkg out of the Platform/Intel folder and into a vendor neutral folder. MinPlatform really isn't Intel specific, it's just "middleware" that is intended to make it easier and faster to build EDK II based firmware. We have always intended MinPlatform to be vendor neutral, and it would be great to see MinPlatform based implementations for non-Intel silicon. Anyone working with EDK II should feel welcome to work with us on MinPlatform, regardless of the SoC in use.

To that end, I propose that we move MinPlatformPkg out of edk2-platforms/Platform/Intel to edk2-platforms/Platform/MinPlatformPkg. It might also make sense to move edk2-platforms/Platform/Intel/Tools and edk2-platforms/Platform/Intel/build_bios.py to edk2-platforms/Platform as well since those are all useful for building MinPlatform based firmware, but I could also see that being something for another time. Let me know what you think!

Thanks,
Nate













--
*Christian Walter*
*Head of Firmware Development / Cyber Security *



9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Email:  christian.walter@9elements.com
Phone:  _+49 234 68 94 188 <tel:+492346894188>_
Mobile:  _+49 176 70845047 <tel:+4917670845047>_

Sitz der Gesellschaft: Bochum
Handelsregister: Amtsgericht Bochum, HRB 17519
Geschäftsführung: Sebastian Deutsch, Eray Basar

Datenschutzhinweise nach Art. 13 DSGVO <https://9elements.com/privacy>
Re: [RFC] Request to move MinPlatformPkg out of the Intel folder

Wim Vervoorn <wvervoorn@...>
 

Hi Nate,

I agree this sounds like a good plan. The MinPlatform should be as generic as possible and suitable for all architectures.

In fact it is similar to the UEFIPayload package wich is also standalone.

Best Regards,
Wim Vervoorn

Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands

T : +31-(0)73-594 46 64
E : wvervoorn@eltan.com
W : http://www.eltan.com


"This message contains confidential information. Unless you are the intended recipient of this message, any use of this message is strictly prohibited. If you have received this message in error, please immediately notify the sender by telephone +31-(0)73-5944664 or reply email, and immediately delete this message and all copies."

-----Original Message-----
From: rfc@edk2.groups.io [mailto:rfc@edk2.groups.io] On Behalf Of Nate DeSimone
Sent: Thursday, October 1, 2020 1:17 AM
To: devel@edk2.groups.io; rfc@edk2.groups.io
Cc: Leif Lindholm <leif@nuviainc.com>; Laszlo Ersek <lersek@redhat.com>; Ard Biesheuvel <ard.biesheuvel@arm.com>; Kirkendall, Garrett <garrett.kirkendall@amd.com>; Lendacky, Thomas <thomas.lendacky@amd.com>; thomas.abraham@arm.com; Frank.Orr@dell.com; Jim Dailey <jim.dailey@dell.com>; Abner Chang <abner.chang@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; Daniel Schaefer <daniel.schaefer@hpe.com>; Liming Gao <gaoliming@byosoft.com.cn>; Tim Lewis <tim.lewis@insyde.com>; Kevin@Insyde <kevin.davis@insyde.com>; Felix Polyudov <felixp@ami.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Oram, Isaac W <isaac.w.oram@intel.com>; Ni, Ray <ray.ni@intel.com>
Subject: [edk2-rfc] [RFC] Request to move MinPlatformPkg out of the Intel folder

Hi Everyone,

This has come up informally a couple of times already, but I do think that it would be beneficial to move MinPlatformPkg out of the Platform/Intel folder and into a vendor neutral folder. MinPlatform really isn't Intel specific, it's just "middleware" that is intended to make it easier and faster to build EDK II based firmware. We have always intended MinPlatform to be vendor neutral, and it would be great to see MinPlatform based implementations for non-Intel silicon. Anyone working with EDK II should feel welcome to work with us on MinPlatform, regardless of the SoC in use.

To that end, I propose that we move MinPlatformPkg out of edk2-platforms/Platform/Intel to edk2-platforms/Platform/MinPlatformPkg. It might also make sense to move edk2-platforms/Platform/Intel/Tools and edk2-platforms/Platform/Intel/build_bios.py to edk2-platforms/Platform as well since those are all useful for building MinPlatform based firmware, but I could also see that being something for another time. Let me know what you think!

Thanks,
Nate
Re: [RFC] Request for new git repository for EdkRepo

Bjorge, Erik C
 

I am fine with a new repo. This also supports a good workflow to get a tool that then lets you pull full platforms. In theory you would only ever really need to clone a single repo manually (assuming reasonable manifest support).

Are you also looking at creating a separate manifest repo as well or just creating a manifest branch in the new EdkRepo repository?

Thanks,
-Erik

-----Original Message-----
From: Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>
Sent: Wednesday, September 30, 2020 2:56 PM
To: devel@edk2.groups.io; rfc@edk2.groups.io
Cc: Desimone, Ashley E <ashley.e.desimone@intel.com>; Bjorge, Erik C <erik.c.bjorge@intel.com>
Subject: [RFC] Request for new git repository for EdkRepo

Hi Everyone,

Given that EdkRepo has existed in the project for over a year now (in edk2-staging) I think it is time to get out of staging. I have considered multiple possible landing zones:

1. edk2
2. edk2-pytool-library
3. A new repository

Edk2 does not seem like a good location as EdkRepo isn't strictly necessary to build EDK II, and I think all of us would prefer that edk2 not become a dumping ground. I have talked with the other maintainers of edk2-pytool-library and they would prefer that EdkRepo not enter that repository because EdkRepo does not have a robust set of unit tests yet and they don't want their test coverage metrics to decline. Therefore, the best choice seems to be a new repository. As always if anyone has comments they are welcome!

Thanks,
Nate
Re: [RFC] Request to move MinPlatformPkg out of the Intel folder

Leif Lindholm
 

Hi Nate,

On Wed, Sep 30, 2020 at 23:17:15 +0000, Desimone, Nathaniel L wrote:
This has come up informally a couple of times already, but I do
think that it would be beneficial to move MinPlatformPkg out of the
Platform/Intel folder and into a vendor neutral folder. MinPlatform
really isn't Intel specific, it's just "middleware" that is intended
to make it easier and faster to build EDK II based firmware. We have
always intended MinPlatform to be vendor neutral, and it would be
great to see MinPlatform based implementations for non-Intel
silicon. Anyone working with EDK II should feel welcome to work with
us on MinPlatform, regardless of the SoC in use.
Very positive to this on the whole.

I have only been following MinPlatformPkg peripherally - at the time
it was merged, I did not have the bandwidth to look into it and help
make it cross-architecture from the start, so I mostly refrained from
comment.

One thing I think is needed for this to move out of Platform/Intel
would be a ReadMe.rst describing the intended real-world use.
Some of this lives in Platform/Intel/Readme.md today.
Could we start with a set moving this text into a separate file under
MinPlatformPkg and rework that into something that stands on its own?

To that end, I propose that we move MinPlatformPkg out of
edk2-platforms/Platform/Intel to
edk2-platforms/Platform/MinPlatformPkg.
If I was to bikeshed, I'd probably suggest
Platform/TianoCore/MinPlatformPkg. Oops, guess I did.

It might also make sense to
move edk2-platforms/Platform/Intel/Tools and
edk2-platforms/Platform/Intel/build_bios.py to
edk2-platforms/Platform as well since those are all useful for
building MinPlatform based firmware, but I could also see that being
something for another time. Let me know what you think!
I think we should see this as a separate step, regardless.

I do think we should be able to do better on sharing some of this
platform image tooling cross-architecture (even moreso now Risc-V is
involved), but I would prefer for us to spend the effort of
identifying the intersections upfront before we start uploading tools
to places where they look generic and may confuse people.

Maybe we should raise this part as a BZ?

Best Regards,

Leif
321 - 340 of 753