[edk2-devel] MinPlatformPkg question

Tue Jan 31 20:43:22 UTC 2023

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

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

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

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99367): https://edk2.groups.io/g/devel/message/99367
Mute This Topic: https://groups.io/mt/96222267/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20230131/9ff2d138/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2614 bytes
Desc: image001.png
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20230131/9ff2d138/attachment-0001.png>