MinPlatformPkg question

MinPlatformPkg question

[Kirkendall, Garrett]

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

[Public]

+ MinPlatformPkg Maintainers

Start the conversation:
Some time back there were posts about promoting MinPlatformPkg up to a more generic level.  Is there still a desire to implement this and possibly even to promote this more generic MinPlatformPkg to the edk2 repository.  Would it be expanded to encompass different architectures other than x86, and maybe how?


GARRETT KIRKENDALL
----------------------------------------------------------------------------------------------------------------------------------
Facebook<https://www.facebook.com/AMD> |  Twitter<https://twitter.com/AMD> |  amd.com<http://www.amd.com/>
[cid:image001.png@01D92658.1A4E0AC0]

Words to live by: "Slow is Smooth.  Smooth is Fast."


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

[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 2614 bytes --]

Re: MinPlatformPkg question

[Isaac Oram]

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

Garrett,

Preface:  I don't have a strong objection to moving MinPlatformPkg.  I would generally prefer to move silicon/platform/board specific content out of edk2 and into edk2-platforms or elsewhere.
I am concerned that moving content could negatively impact current users in a way that would increase fragmentation though.  I that eventually someone will make a package manager and then it will all be localized and won't matter where packages come from.


I am very interested in expanding use.  We have purposefully avoided "finishing" to a 1.0 version of spec until more adoption has occurred.

I have not seen any feedback on what would be needed to expand to different architectures.  I personally have some open questions for discussion, like the approach for standardized FV layout and the use of PCD to describe them.  And refactoring the DSC/FDF include content.  QemuOpenBoardPkg work generated a better option there.

I would propose that we modify and extend the current content in a mostly backwards compatible way.  Then, once we have the changes clear, we make an incompatible MinPlatformV1Pkg or something like that in conjunction with 1.0 spec.  The benefit I would like is not punishing existing adopters and ending up with a simple/minimal package for longer term use.

Regards,
Isaac

From: Kirkendall, Garrett <Garrett.Kirkendall@amd.com>
Sent: Thursday, January 12, 2023 5:33 AM
To: devel@edk2.groups.io; Chiu, Chasel <chasel.chiu@intel.com>; Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; Oram, Isaac W <isaac.w.oram@intel.com>; Gao, Liming <gaoliming@byosoft.com.cn>; Dong, Eric <eric.dong@intel.com>
Subject: MinPlatformPkg question


[Public]

+ MinPlatformPkg Maintainers

Start the conversation:
Some time back there were posts about promoting MinPlatformPkg up to a more generic level.  Is there still a desire to implement this and possibly even to promote this more generic MinPlatformPkg to the edk2 repository.  Would it be expanded to encompass different architectures other than x86, and maybe how?


GARRETT KIRKENDALL
----------------------------------------------------------------------------------------------------------------------------------
Facebook<https://www.facebook.com/AMD> |  Twitter<https://twitter.com/AMD> |  amd.com<http://www.amd.com/>
[cid:image001.png@01D92675.025F4F10]

Words to live by: "Slow is Smooth.  Smooth is Fast."


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

[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 2614 bytes --]

Re: MinPlatformPkg question

[Kirkendall, Garrett]

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

[Public]

Isaac,

One of the obvious hindrances to acceptance is the Firmware Volumes with Fsp in the name.  They would be obvious to an Intel FSP solution, but they are not obvious to any other solution.  Would it be possible to give them a more generic descriptive name that would apply to any type of solution?

GARRETT KIRKENDALL
----------------------------------------------------------------------------------------------------------------------------------
Facebook<https://www.facebook.com/AMD> |  Twitter<https://twitter.com/AMD> |  amd.com<http://www.amd.com/>
[cid:image001.png@01D93562.64340C20]

Words to live by: "Slow is Smooth.  Smooth is Fast."

From: Oram, Isaac W <isaac.w.oram@intel.com>
Sent: Thursday, January 12, 2023 3:44 PM
To: Kirkendall, Garrett <Garrett.Kirkendall@amd.com>; devel@edk2.groups.io; Chiu, Chasel <chasel.chiu@intel.com>; Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; Gao, Liming <gaoliming@byosoft.com.cn>; Dong, Eric <eric.dong@intel.com>; Bobroff, Zachary <zacharyb@ami.com>; Zimmer, Vincent <vincent.zimmer@intel.com>
Subject: RE: MinPlatformPkg question

Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.

Garrett,

Preface:  I don't have a strong objection to moving MinPlatformPkg.  I would generally prefer to move silicon/platform/board specific content out of edk2 and into edk2-platforms or elsewhere.
I am concerned that moving content could negatively impact current users in a way that would increase fragmentation though.  I that eventually someone will make a package manager and then it will all be localized and won't matter where packages come from.


I am very interested in expanding use.  We have purposefully avoided "finishing" to a 1.0 version of spec until more adoption has occurred.

I have not seen any feedback on what would be needed to expand to different architectures.  I personally have some open questions for discussion, like the approach for standardized FV layout and the use of PCD to describe them.  And refactoring the DSC/FDF include content.  QemuOpenBoardPkg work generated a better option there.

I would propose that we modify and extend the current content in a mostly backwards compatible way.  Then, once we have the changes clear, we make an incompatible MinPlatformV1Pkg or something like that in conjunction with 1.0 spec.  The benefit I would like is not punishing existing adopters and ending up with a simple/minimal package for longer term use.

Regards,
Isaac

From: Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>
Sent: Thursday, January 12, 2023 5:33 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Chiu, Chasel <chasel.chiu@intel.com<mailto:chasel.chiu@intel.com>>; Desimone, Nathaniel L <nathaniel.l.desimone@intel.com<mailto:nathaniel.l.desimone@intel.com>>; Oram, Isaac W <isaac.w.oram@intel.com<mailto:isaac.w.oram@intel.com>>; Gao, Liming <gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>>; Dong, Eric <eric.dong@intel.com<mailto:eric.dong@intel.com>>
Subject: MinPlatformPkg question


[Public]

+ MinPlatformPkg Maintainers

Start the conversation:
Some time back there were posts about promoting MinPlatformPkg up to a more generic level.  Is there still a desire to implement this and possibly even to promote this more generic MinPlatformPkg to the edk2 repository.  Would it be expanded to encompass different architectures other than x86, and maybe how?


GARRETT KIRKENDALL
----------------------------------------------------------------------------------------------------------------------------------
Facebook<https://www.facebook.com/AMD> |  Twitter<https://twitter.com/AMD> |  amd.com<http://www.amd.com/>
[cid:image001.png@01D93562.64340C20]

Words to live by: "Slow is Smooth.  Smooth is Fast."


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

[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 2614 bytes --]

Re: [edk2-devel] MinPlatformPkg question

[Pedro Falcato]

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

On Tue, Jan 31, 2023 at 4:54 PM Kirkendall, Garrett via groups.io
<garrett.kirkendall=amd.com@groups.io> wrote:

> [Public]
>
>
>
> Isaac,
>
>
>
> One of the obvious hindrances to acceptance is the Firmware Volumes with
> Fsp in the name.  They would be obvious to an Intel FSP solution, but they
> are not obvious to any other solution.  Would it be possible to give them a
> more generic descriptive name that would apply to any type of solution?
>
>
>
> *GARRETT KIRKENDALL*
>
>
> *----------------------------------------------------------------------------------------------------------------------------------*
>
> Facebook <https://www.facebook.com/AMD> |  Twitter
> <https://twitter.com/AMD> |  amd.com <http://www.amd.com/>
>
>
>
>
>
> Words to live by: "Slow is Smooth.  Smooth is Fast."
>
>
>

Garrett,

Surely you've got bigger issues with the MinPlatform than naming right? I
don't see how this can ever be a hindrance, particularly considering all
you've got in the final firmware images are GUIDs.

https://github.com/tianocore/edk2-platforms/blob/master/Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.fdf
is an example of a virtual platform for QEMU in MinPlatform fashion.
Combine that and
some other Intel platform and you probably have a decent idea of how an AMD
platform would look like (mentioned QOBP because of the lack of FSP and
pre-mem CAR, although AIUI AGESA does expose an FSP interface).

There are no problems by leaving firmware volumes you don't need/don't make
sense (like e.g Fsp-T) empty.

-- 
Pedro

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

[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 2614 bytes --]

Re: [edk2-devel] MinPlatformPkg question

[Kirkendall, Garrett]

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

[AMD Official Use Only - General]

While I can work with Fsp named items in the MinPlatformPkg specification, I assumed the UEFI/edk2 team and maintainers might be amenable to making the specification more generic.  One of my concerns with Fsp named FVs is that critical core edk2 components are specified in them like PeiCore is specified in FvFspM.fv, etc.  There is only one guaranteed vendor implementing FSP and therefore it might be better to have more generic names which could attract more adopters more easily and reduce confusion.  Maybe there could be specified alternate names for non-FSP implementations?

Having FSP in the name would imply that the product supports FSP when it does not.

I'm looking forward in time as much as possible where this specification could encompass ARM, RISCV, etc. and provide similar useful items MinPlatformPkg can provide to x86 platforms.

I look forward to the next level of unified flow/structure that Minimum Platform can provide to the industry.

GARRETT KIRKENDALL
----------------------------------------------------------------------------------------------------------------------------------
Facebook<https://www.facebook.com/AMD> |  Twitter<https://twitter.com/AMD> |  amd.com<http://www.amd.com/>
[cid:image001.png@01D93576.B3AD9190]

Words to live by: "Slow is Smooth.  Smooth is Fast."

From: Pedro Falcato <pedro.falcato@gmail.com>
Sent: Tuesday, January 31, 2023 12:58 PM
To: devel@edk2.groups.io; Kirkendall, Garrett <Garrett.Kirkendall@amd.com>
Cc: Oram, Isaac W <isaac.w.oram@intel.com>; Chiu, Chasel <chasel.chiu@intel.com>; Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; Gao, Liming <gaoliming@byosoft.com.cn>; Dong, Eric <eric.dong@intel.com>; Bobroff, Zachary <zacharyb@ami.com>; Zimmer, Vincent <vincent.zimmer@intel.com>
Subject: Re: [edk2-devel] MinPlatformPkg question

Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.

On Tue, Jan 31, 2023 at 4:54 PM Kirkendall, Garrett via groups.io<http://groups.io> <garrett.kirkendall=amd.com@groups.io<mailto:amd.com@groups.io>> wrote:

[Public]

Isaac,

One of the obvious hindrances to acceptance is the Firmware Volumes with Fsp in the name.  They would be obvious to an Intel FSP solution, but they are not obvious to any other solution.  Would it be possible to give them a more generic descriptive name that would apply to any type of solution?

GARRETT KIRKENDALL
----------------------------------------------------------------------------------------------------------------------------------
Facebook<https://www.facebook.com/AMD> |  Twitter<https://twitter.com/AMD> |  amd.com<http://www.amd.com/>
[cid:image001.png@01D93576.B3AD9190]

Words to live by: "Slow is Smooth.  Smooth is Fast."


Garrett,

Surely you've got bigger issues with the MinPlatform than naming right? I don't see how this can ever be a hindrance, particularly considering all you've got in the final firmware images are GUIDs.

https://github.com/tianocore/edk2-platforms/blob/master/Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.fdf is an example of a virtual platform for QEMU in MinPlatform fashion. Combine that and
some other Intel platform and you probably have a decent idea of how an AMD platform would look like (mentioned QOBP because of the lack of FSP and pre-mem CAR, although AIUI AGESA does expose an FSP interface).

There are no problems by leaving firmware volumes you don't need/don't make sense (like e.g Fsp-T) empty.

--
Pedro

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

[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 2614 bytes --]

Re: [edk2-devel] MinPlatformPkg question

[Isaac Oram]

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

Garrett,

Yeah, that was what I was trying to get at with "let's use what we have now and then make an incompatible V1.0".  I like the idea of alternates too.  I dislike punishing early adopters and I don't think alternatives hurt most of the envisioned use cases.
Maybe we should start a branch for proposing and staging concrete changes.

It isn't well polished, but if I summarize what we were going for, it looks something like this:

The key objectives for specifying FV are to:

  *   Enable developers to rapidly understand what is same and different between boards and platforms
  *   Enable binary reuse use cases (integration, test, security, update) at a larger scope than individual drivers.
  *   Leverage validation of binaries across targets

The potential key use cases for specified Firmware Volumes include:

  *   Auditing:  Develop tools that can decompose the defined portion of a UEFI firmware solution.
  *   Integration:  Binary FV containing common core elements (Stage III) can be well defined, with clear interfaces, dependencies, and functionality.
  *   Integration:  Binary FV containing silicon support can be well defined and more readily managed, integrated, and audited.
  *   Auditing:  Build tool extensions can produce cryptographic strength hashes of defined FV that should not be customized.
  *   Optimization:  Support tools that can intelligently optimize out unneeded components.
  *   Simplification:  By separating into a set of known FV, we can define and mature them such that ownership can be maintained by one entity.

Is there anything you would add or change for why the spec should specify FV?  What are interesting use cases you would like to see or prioritize?

Regards,
Isaac


From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Kirkendall, Garrett via groups.io
Sent: Tuesday, January 31, 2023 11:28 AM
To: Pedro Falcato <pedro.falcato@gmail.com>; devel@edk2.groups.io
Cc: Oram, Isaac W <isaac.w.oram@intel.com>; Chiu, Chasel <chasel.chiu@intel.com>; Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; Gao, Liming <gaoliming@byosoft.com.cn>; Dong, Eric <eric.dong@intel.com>; Bobroff, Zachary <zacharyb@ami.com>; Zimmer, Vincent <vincent.zimmer@intel.com>
Subject: Re: [edk2-devel] MinPlatformPkg question


[AMD Official Use Only - General]

While I can work with Fsp named items in the MinPlatformPkg specification, I assumed the UEFI/edk2 team and maintainers might be amenable to making the specification more generic.  One of my concerns with Fsp named FVs is that critical core edk2 components are specified in them like PeiCore is specified in FvFspM.fv, etc.  There is only one guaranteed vendor implementing FSP and therefore it might be better to have more generic names which could attract more adopters more easily and reduce confusion.  Maybe there could be specified alternate names for non-FSP implementations?

Having FSP in the name would imply that the product supports FSP when it does not.

I'm looking forward in time as much as possible where this specification could encompass ARM, RISCV, etc. and provide similar useful items MinPlatformPkg can provide to x86 platforms.

I look forward to the next level of unified flow/structure that Minimum Platform can provide to the industry.

GARRETT KIRKENDALL
----------------------------------------------------------------------------------------------------------------------------------
Facebook<https://www.facebook.com/AMD> |  Twitter<https://twitter.com/AMD> |  amd.com<http://www.amd.com/>
[cid:image001.png@01D93569.E8855270]

Words to live by: "Slow is Smooth.  Smooth is Fast."

From: Pedro Falcato <pedro.falcato@gmail.com<mailto:pedro.falcato@gmail.com>>
Sent: Tuesday, January 31, 2023 12:58 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Kirkendall, Garrett <Garrett.Kirkendall@amd.com<mailto:Garrett.Kirkendall@amd.com>>
Cc: Oram, Isaac W <isaac.w.oram@intel.com<mailto:isaac.w.oram@intel.com>>; Chiu, Chasel <chasel.chiu@intel.com<mailto:chasel.chiu@intel.com>>; Desimone, Nathaniel L <nathaniel.l.desimone@intel.com<mailto:nathaniel.l.desimone@intel.com>>; Gao, Liming <gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>>; Dong, Eric <eric.dong@intel.com<mailto:eric.dong@intel.com>>; Bobroff, Zachary <zacharyb@ami.com<mailto:zacharyb@ami.com>>; Zimmer, Vincent <vincent.zimmer@intel.com<mailto:vincent.zimmer@intel.com>>
Subject: Re: [edk2-devel] MinPlatformPkg question

Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.

On Tue, Jan 31, 2023 at 4:54 PM Kirkendall, Garrett via groups.io<http://groups.io> <garrett.kirkendall=amd.com@groups.io<mailto:amd.com@groups.io>> wrote:

[Public]

Isaac,

One of the obvious hindrances to acceptance is the Firmware Volumes with Fsp in the name.  They would be obvious to an Intel FSP solution, but they are not obvious to any other solution.  Would it be possible to give them a more generic descriptive name that would apply to any type of solution?

GARRETT KIRKENDALL
----------------------------------------------------------------------------------------------------------------------------------
Facebook<https://www.facebook.com/AMD> |  Twitter<https://twitter.com/AMD> |  amd.com<http://www.amd.com/>
[cid:image001.png@01D93569.E8855270]

Words to live by: "Slow is Smooth.  Smooth is Fast."


Garrett,

Surely you've got bigger issues with the MinPlatform than naming right? I don't see how this can ever be a hindrance, particularly considering all you've got in the final firmware images are GUIDs.

https://github.com/tianocore/edk2-platforms/blob/master/Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.fdf is an example of a virtual platform for QEMU in MinPlatform fashion. Combine that and
some other Intel platform and you probably have a decent idea of how an AMD platform would look like (mentioned QOBP because of the lack of FSP and pre-mem CAR, although AIUI AGESA does expose an FSP interface).

There are no problems by leaving firmware volumes you don't need/don't make sense (like e.g Fsp-T) empty.

--
Pedro


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

[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 2614 bytes --]

Re: [edk2-devel] MinPlatformPkg question

[Pedro Falcato]

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

On Tue, Jan 31, 2023 at 7:28 PM Kirkendall, Garrett <
Garrett.Kirkendall@amd.com> wrote:

> [AMD Official Use Only - General]
>
>
>
> While I can work with Fsp named items in the MinPlatformPkg specification,
> I assumed the UEFI/edk2 team and maintainers might be amenable to making
> the specification more generic.  One of my concerns with Fsp named FVs is
> that critical core edk2 components are specified in them like PeiCore is
> specified in FvFspM.fv, etc.  There is only one guaranteed vendor
> implementing FSP and therefore it might be better to have more generic
> names which could attract more adopters more easily and reduce confusion.
> Maybe there could be specified alternate names for non-FSP implementations?
>

Hi,

To be clear, you are right that renaming things from FspX (and other
possible examples) is a good idea. It's just not really a hindrance
(despite silly politics), the docs are. You do not need the FSP to use
MinPlatform.

If you want to talk about real problems, we can start by mentioning that
MinPlatform docs are not really all that great. They:
 1) Mention Intel and Intel platforms all that time (why? this is supposed
to be vendor agnostic) as well, almost assuming you're an Intel platform at
points
 2) Do not go in much depth about creating your own MinPlatform (and
subsequently OpenBoardPkg) from scratch, and assume you already have an
OpenBoardPkg to simply copy from
 3) Lack simplicity and conciseness in many points

All of this may very well slow adoption. As far as I know, on the
QemuOpenBoard GSoC project the spec was mostly very underutilized except
some bits like the list of required modules.


> Having FSP in the name would imply that the product supports FSP when it
> does not.
>
>
>
> I'm looking forward in time as much as possible where this specification
> could encompass ARM, RISCV, etc. and provide similar useful items
> MinPlatformPkg can provide to x86 platforms.
>

MinPlatform is AIUI at the moment pretty x86 PC centric. It requires
components from PcAtChipsetPkg, UefiCpuPkg (which as you may know, is
x86-only/mostly despite the name). Also requires a bunch of components like
SATA and USB support which may not be wanted or needed in e.g a smaller
riscv64 platform. It assumes a bog-standard PC environment where you need
all sorts of features and components and drivers.

Something I would personally love would be all sorts of reduced booting in
MinPlatform (as in boot-to-OS-but-load-it-from-flash, etc. Many options),
but it's probably far away still.

I look forward to the next level of unified flow/structure that Minimum
> Platform can provide to the industry.
>
>
>
> *GARRETT KIRKENDALL*
>
>
> *----------------------------------------------------------------------------------------------------------------------------------*
>
> Facebook <https://www.facebook.com/AMD> |  Twitter
> <https://twitter.com/AMD> |  amd.com <http://www.amd.com/>
>
>
>
>
>
> Words to live by: "Slow is Smooth.  Smooth is Fast."
>
>
>


-- 
Pedro

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

[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 2614 bytes --]