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

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

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

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

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

Hey Leif, 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

Hey Bret, 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

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

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

Hey Sean, 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

Hey Hot, Edk2 would be a good place as well. Thanks, Nate

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

Why not move to edk2 repo? Thanks, Hot

Hey Laszlo, 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:

Sounds good. 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/.

Hey Leif, Happy to hear! 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

Hi Nate, totally agree with you. Best, Chris -- *Christian Walter* *Head of Firmware Development / Cyber Security * 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: 

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

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

Hi Nate, 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