Re: [edk2-devel] MinPlatformPkg question

["Isaac Oram" <isaac.w.oram@intel.com>]

[-- 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 --]