Date   

Re: [PATCH 0/5] ArmPkg: OemMiscLib and Universal/Smbios improvements and fixes

Rebecca Cran
 

On 4/13/21 10:25 AM, Leif Lindholm wrote:
On Tue, Mar 30, 2021 at 20:16:14 -0600, Rebecca Cran wrote:
Add the set of improvements requested during the initial series to move
closer to a full/proper implementation, fix the
chassis SKU number string, and fix a typo in a comment.

This is a breaking change wrt SbsaQemu in edk2-platforms.
I can't find a corresponding patch for that.
Are you looking for the APIs in this set to stabilise first?
I haven't sent it out yet. I think having this set reviewed and accepted first would be best, to avoid extra churn.

--
Rebecca Cran

/
Leif

Rebecca Cran (5):
ArmPkg: Allow platforms to override PCI supported state in
SmbiosMiscDxe
ArmPkg: Allow platforms to supply more data for SMBIOS Type3 record
ArmPkg: Allow platforms to report their boot status via OemMiscLib
call
ArmPkg: Fix calculation of offset of chassis SKU Number in
SmbiosMiscDxe
ArmPkg: Fix typo of Manufacturer in comment in SmbiosMiscDxe

ArmPkg/ArmPkg.dec | 1 +
ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf | 1 +
ArmPkg/Include/Library/OemMiscLib.h | 70 ++++++++++++++
ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c | 99 ++++++++++++++++++++
ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c | 4 +
ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type03/MiscChassisManufacturerData.c | 2 +-
ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type03/MiscChassisManufacturerFunction.c | 20 +++-
ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type32/MiscBootInformationFunction.c | 3 +
8 files changed, 194 insertions(+), 6 deletions(-)

--
2.26.2


Re: [PATCH 1/5] ArmPkg: Allow platforms to override PCI supported state in SmbiosMiscDxe

Rebecca Cran
 

On 4/13/21 10:51 AM, Leif Lindholm wrote:
On Tue, Mar 30, 2021 at 20:16:15 -0600, Rebecca Cran wrote:
Not all platforms support PCI, so introduce a PCD to allow platforms to
specify whether they support it.
Are we planning to add one?
Not that I know of.

If not, I'd rather skip this until we do.
These days, I would expect any platform providing SMBIOS tables to
have PCI.
I added it based on feedback on the original review (I think Samer requested it), but it sounds like dropping it would be fine.

--
Rebecca Cran

No further comments on this set.
/
Leif

Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
---
ArmPkg/ArmPkg.dec | 1 +
ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf | 1 +
ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c | 4 ++++
3 files changed, 6 insertions(+)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index a8a22c649ff8..51ac2191c85a 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -125,6 +125,7 @@ [PcdsFixedAtBuild.common]
#
# SMBIOS PCDs
#
+ gArmTokenSpaceGuid.PcdPlatformSupportsPCI|TRUE|BOOLEAN|0x30000052
gArmTokenSpaceGuid.PcdSystemProductName|L""|VOID*|0x30000053
gArmTokenSpaceGuid.PcdSystemVersion|L""|VOID*|0x30000054
gArmTokenSpaceGuid.PcdBaseBoardManufacturer|L""|VOID*|0x30000055
diff --git a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
index 60d8fe31c219..ebc4c99ac436 100644
--- a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
+++ b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
@@ -71,6 +71,7 @@ [Pcd]
gArmTokenSpaceGuid.PcdFdSize
gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVendor
gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString
+ gArmTokenSpaceGuid.PcdPlatformSupportsPCI
gArmTokenSpaceGuid.PcdSystemBiosRelease
gArmTokenSpaceGuid.PcdEmbeddedControllerFirmwareRelease
gArmTokenSpaceGuid.PcdSystemProductName
diff --git a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c
index 5aea32521bd3..a06f814aeb7c 100644
--- a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c
+++ b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c
@@ -13,6 +13,7 @@
#include <Library/DebugLib.h>
#include <Library/HiiLib.h>
#include <Library/MemoryAllocationLib.h>
+#include <Library/PcdLib.h>
#include <Library/PrintLib.h>
#include <Library/UefiBootServicesTableLib.h>
@@ -264,6 +265,9 @@ SMBIOS_MISC_TABLE_FUNCTION (MiscBiosVendor)
UnicodeStrToAsciiStrS (Version, StrStart, VerStrLen + 1);
StrStart += VerStrLen + 1;
UnicodeStrToAsciiStrS (ReleaseDate, StrStart, DateStrLen + 1);
+
+ SmbiosRecord->BiosCharacteristics.PciIsSupported = FixedPcdGetBool (PcdPlatformSupportsPCI);
+
//
// Now we have got the full smbios record, call smbios protocol to add this record.
//
--
2.26.2


回复: [edk2-devel] [PATCH v1 1/1] Fix AsmReadMsr64() and AsmWriteMsr64() with GCC toolchain

gaoliming
 

Create PR https://github.com/tianocore/edk2/pull/1562 for it.

Thanks
Liming

-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 gaoliming
发送时间: 2021年4月13日 9:16
收件人: devel@edk2.groups.io; naitaku@gmail.com
抄送: 'Michael D Kinney' <michael.d.kinney@intel.com>; 'Zhiguang Liu'
<zhiguang.liu@intel.com>
主题: 回复: [edk2-devel] [PATCH v1 1/1] Fix AsmReadMsr64() and
AsmWriteMsr64() with GCC toolchain

Naito:
The fix is correct. Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Takuto
Naito
发送时间: 2021年4月12日 23:07
收件人: devel@edk2.groups.io
抄送: Takuto Naito <naitaku@gmail.com>; Michael D Kinney
<michael.d.kinney@intel.com>; Liming Gao <gaoliming@byosoft.com.cn>;
Zhiguang Liu <zhiguang.liu@intel.com>
主题: [edk2-devel] [PATCH v1 1/1] Fix AsmReadMsr64() and
AsmWriteMsr64()
with GCC toolchain

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3325

1. AsmReadMsr64() in X64/GccInlinePriv.c
AsmReadMsr64 can return uninitialized value if FilterBeforeMsrRead
returns False. This causes build error with the CLANG toolchain.

2. AsmWriteMsr64() in X64/GccInlinePriv.c
In the case that FilterBeforeMsrWrite changes Value and returns True,
The original Value, not the changed Value, is written to the MSR.
This behavior is different from the one of AsmWriteMsr64() in
X64/WriteMsr64.c for the MSFT toolchain.

Signed-off-by: Takuto Naito <naitaku@gmail.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
---
MdePkg/Library/BaseLib/X64/GccInlinePriv.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Library/BaseLib/X64/GccInlinePriv.c
b/MdePkg/Library/BaseLib/X64/GccInlinePriv.c
index e4920f2116..244bd62ee6 100644
--- a/MdePkg/Library/BaseLib/X64/GccInlinePriv.c
+++ b/MdePkg/Library/BaseLib/X64/GccInlinePriv.c
@@ -80,7 +80,7 @@ AsmReadMsr64 (
}
FilterAfterMsrRead (Index, &Value);

- return (((UINT64)HighData) << 32) | LowData;
+ return Value;
}

/**
@@ -111,11 +111,10 @@ AsmWriteMsr64 (
UINT32 HighData;
BOOLEAN Flag;

- LowData = (UINT32)(Value);
- HighData = (UINT32)(Value >> 32);
-
Flag = FilterBeforeMsrWrite (Index, &Value);
if (Flag) {
+ LowData = (UINT32)(Value);
+ HighData = (UINT32)(Value >> 32);
__asm__ __volatile__ (
"wrmsr"
:
--
2.31.1










Re: VirtIO Sound Driver (GSoC 2021)

Ethin Probst
 

Okay, so looking at the EDK2 driver developers guide, here are my thoughts:

- Each audio driver will be a bus driver, even if it doesn't control
buses in the traditional sense.
- I think the initialization sequence should be different: there
should be an AudioDxe, but it should contain three separate bus
drivers for each kind of audio device supported.
- For the VirtIO audio device driver, it'll most likely consume the
PCI I/O protocol and produce the EFI_VIRTIO_AUDIO_OUTPUT_PROTOCOL and
EFI_VIRTIO_AUDIO_INPUT_PROTOCOL protocols. This will just be an
ordinary UEFI device driver.
- The HDA audio device driver will consume the PCI I/O protocol and
will produce different device handles per HDA controller found. I'd
produce a handle per codec, but that seems overkill. Each handle will
be attached to both an audio stream protocol and a controller
management protocol. The audio stream protocol will manage the
creation, control, and deletion of audio streams as well as the
processing of audio data. The controller management protocol is
responsible for allowing applications or other drivers to manage the
HDA controller itself.

I haven't planned for the USB audio device driver yet, but these are
my thoughts so far. What do you guys think? Am I over-complicating
this setup? How can it be improved upon?

On 4/13/21, Ethin Probst via groups.io
<harlydavidsen=gmail.com@groups.io> wrote:
Hi Andrew,

The developer guide for EDK2 drivers is a godsend. Thank you very
much, and thank you, Mike, for your excellent work on the guide! I may
just ahve to do my building on Linux and not Windows -- unless the Bug
-- bug 3302 -- has been fixed. I'll have to do testing on Linux, at
any rate, since Windows hosts do not support VirtIO emulation and I
can't seem to find any way of emulating them in a guest machine with
Windows as a host.

On 4/13/21, Andrew Fish <afish@apple.com> wrote:


On Apr 13, 2021, at 9:53 AM, Ethin Probst <harlydavidsen@gmail.com>
wrote:

Would it be possible for us to conduct discussion on the UEFI talkbox?
I don't mind using email, but things could definitely get moving
quicker over there (though its not a requirement obviously).
Sure, don’t think I’ve really used that but as long as I get pointed int
he
right direction I can make it work.

For a device driver the general UEFI model is for the Entry point of the
driver to publish a EFI_DRIVER_BINDING_PROTOCOL[1]. The Supported()
function
matches on the PCI devices. The Start() function installs the Protocols
to
do work, and the Stop() undoes the Start().

Mike Kinney started this back in the day and it describes how to write
UEFI
drivers:
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer%27s-Guide

[1]https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DriverBinding.h#L157

Thanks,

Andrew Fish

Here's how I generally envision the driver functioning:

1. Firmware/platform code calls InitaudioOutput() or something like
it. This function scans the PCIe bus and scans for one of the
following:
- Vendor ID 0x1AF4, device ID 0x1059: VirtIO sound device
- PCI class 0x0C, subclass 0x03, program interface 0x30 or 0x40: for
USB audio interface (I'm only thinking of targeting XHCI and USB 4,
and not UHCI, OHCI or EHCI). But maybe EDK2 will take that out of my
hands. If so, it will make things easier.
- For USB audio devices I'm not quite sure what to look for; I'm
definitely unused to USB.
2. If any of the above cases are found, appropriate driver
initialization occurs. Since for the time being I am solely focusing
on VirtIO sound devices, the VirtIO general initialization sequence
will occur as outlined in sec. 3 of the VirtIO specification available
at https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html
<https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html>.
As for actual protocol exposure that would be spec-worthy, for
EFI_AUDIO_OUTPUT_PROTOCOL, I'm not quite sure what to expose. VirtIO
is rather simple: there's a buffer for sending and receiving audio
data in PCM streams. So for that we could expose a Reset(),
RemapJack(), GetJackConfig(), GetPcmConfig(), SetPcmParams(),
Prepare(), Release(), Start(), and Stop() function for the
corresponding request types VIRTIO_SND_R_JACK_GET_CONFIG,
VIRTIO_SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG,
VIRTIO_SND_R_PCM_SET_PARAMS, VIRTIO_SND_R_PCM_PREPARE,
VIRTIO_SND_R_PCM_RELEASE, VIRTIO_SND_R_PCM_START, and
VIRTIO_SND_R_PCM_STOP control requests. However, for HDA things are a
lot more complex, so I'm not sure how that should work.
For VirtIO -- which is what I'll focus on for now -- everything is
described, in excellent detail, in sec. 5.14 of the above-linked
document. What are your guys's thoughts thus far and how should
everything be mapped to UEFI interfaces?

On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>>
wrote:
Leif,

Since I have put some brain cells around this area in the past I can be
the
backup and help out too.

I’d also point out if you are having issues building or have general
questions on how things work it is fine to use the mailing list. I’ve
got
a
lot of feedback that folks read or search the mailing list looking for
answer to their questions so one person asking can help out a lot of
other
people.

Thanks,

Andrew Fish

On Apr 13, 2021, at 5:28 AM, Leif Lindholm <leif@nuviainc.com> wrote:

Hi all, especially Ethin.

Apologies for radio silence - last week I was off on holiday, and
before
that ... let's just say corporate acquisitions generate some
distractions.
Anyway, I'm back, and since I'm down as the mentor for this task, feel
free to spam me with any remaining/new questions.

/
Leif

On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst <harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
wrote:
I'll attach the bug for the build tools to the BZ shortly.
Laszlo, thanks for that. I don't know their email addresses though.
And yes, I was going to make it device independent, as the majority
(if not all) of UEFI protocols are.

On 4/6/21, Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>
<mailto:lersek@redhat.com <mailto:lersek@redhat.com>>>
wrote:
On 03/31/21 08:41, Nate DeSimone wrote:
Another option is to put the protocol definition in MdeModulePkg and
mark it with the EDKII_ prefix. For my last “code first” UEFI spec
contribution I did this with the PPI that added up getting added.
The new audio protocol should be generic, only its implementation in
question should be virtio specific.

Please include Gerd Hoffmann (CC'd) in the protocol design, as well
as
the developers of the virtio-sound device model in QEMU.

Thanks
Laszlo





Thanks,

Nate



*From: *<devel@edk2.groups.io <mailto:devel@edk2.groups.io>
<mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>> on
behalf
of "Andrew Fish via groups.io <http://groups.io/> <http://groups.io/
<http://groups.io/>>"
<afish=apple.com@groups.io <mailto:afish=apple.com@groups.io>
<mailto:apple.com@groups.io <mailto:apple.com@groups.io>>>
*Reply-To: *"devel@edk2.groups.io <mailto:devel@edk2.groups.io>
<mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>"
<devel@edk2.groups.io <mailto:devel@edk2.groups.io>
<mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>,
"afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com
<mailto:afish@apple.com>>" <afish@apple.com <mailto:afish@apple.com>
<mailto:afish@apple.com <mailto:afish@apple.com>>>
*Date: *Tuesday, March 30, 2021 at 10:54 PM
*To: *edk2-devel-groups-io <devel@edk2.groups.io
<mailto:devel@edk2.groups.io>
<mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>,
"harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>"
<harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
*Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>
<mailto:rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>>>
*Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)





On Mar 30, 2021, at 5:01 PM, Ethin Probst
<harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>>
wrote:



I'm wondering where exactly I should add the VirtIO sound
protocol.
I
just familiarized myself with the build system and am about to
test
it
by building OVMF if possible, but I'm wondering where I should
actually put the protocol and all that stuff. Maybe there's
documentation I've missed as well.



Ethin,



For the driver I’d match the patter of OVMF [1] and use
OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers as
a
template.



The protocol is more of a public thing. I think eventually we would
like
to publish the protocol in the UEFI Spec (I can help with that part)
and
that would mean we put the Protocol definition in
MdePkg/Include/Protocol, but we don’t want to do that before it is
standardized as that causes compatibility issues. So this is a “code
first project” (code prototype and then contribute to the UEFI Forum
for
inclusion in the specification) so we need to follow some code first
rules that I don’t remember of the top of my head? So why not start
out
the protocol definition OvmfPkg/Include/Protocol. You can also add a
test application looks like you can just use the root [2] of OVMF
for
that. That way the project is not blocked.



We can have a conversation on the mailing list about better places
to
put stuff, and it should be easy enough to move stuff around if
everything else is working.



[1] find OvmfPkg -iname '*Virtio*.inf'

OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf

OvmfPkg/VirtioScsiDxe/VirtioScsi.inf

OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf

OvmfPkg/Library/VirtioLib/VirtioLib.inf

OvmfPkg/VirtioGpuDxe/VirtioGpu.inf

OvmfPkg/VirtioBlkDxe/VirtioBlk.inf

OvmfPkg/Virtio10Dxe/Virtio10.inf

OvmfPkg/VirtioNetDxe/VirtioNet.inf

OvmfPkg/VirtioRngDxe/VirtioRng.inf



[2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf
|
grep MODULE_TYPE

EnrollDefaultKeys/EnrollDefaultKeys.inf:13: MODULE_TYPE
= UEFI_APPLICATION



Thanks,



Andrew Fish






On 3/30/21, Ethin Probst via groups.io <http://groups.io/>
<http://groups.io/ <http://groups.io/>>
<http://groups.io/ <http://groups.io/> <http://groups.io/
<http://groups.io/>>>
<harlydavidsen=gmail.com@groups.io
<mailto:harlydavidsen=gmail.com@groups.io>
<mailto:gmail.com@groups.io
<mailto:gmail.com@groups.io>>
<mailto:harlydavidsen <mailto:harlydavidsen>=gmail.com@groups.io
<mailto:gmail.com@groups.io>
<mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>> wrote:

I agree. Plus, it gives me a chance to finally learn the EDK2
build
system and how it works! I've been working on a hobby OS as a
side
project and, though learning from other code examples from
OSes
is
fun, I have to say that learning from the firmware code like
from
SeaBIOS has been some of the most enlightening and
interesting
times
thus far.
Thanks for the link to your code, Rafael; once I get virtIO
support
in, I can work on HDA support, though I might tackle USB
support
second and HDA third. We'll see, but VirtIO definitely is
coming
first.

As I said before, I look forward to working with all of you
wonderful
people!

On 3/30/21, Rafael Rodrigues Machado
<rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>
<mailto:rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>>
<mailto:rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>
<mailto:rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>>>>
wrote:

This would be amazing so people can continue my work
related
to
accessibility at BIOS. Something desired by the blind
people
since the
90's
Just for reference, this is what I have done:


https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
<https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
<https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
<https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>

Thanks
Rafael

Em seg, 29 de mar de 2021 20:24, Ethin Probst
<harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
escreveu:


Hello everyone,

This is the first time I've ever contributed to EDK2.
As
part of GSoC
2021, I have submitted a proposal to implement a UEFI
audio output
protocol that will utilize the VirtIO sound driver.
I've
already
submitted a draft proposal, and apologize if I've
done
things out of
order. This is my first time doing GSoC 2021, and
contributing to EDK2
felt like a really fun thing to do!

I look forward to working with you guys on this and
any
future projects!
:-)

--
Signed,
Ethin D. Probst









--
Signed,
Ethin D. Probst







--
Signed,
Ethin D. Probst






--
Signed,
Ethin D. Probst






--
Signed,
Ethin D. Probst



--
Signed,
Ethin D. Probst






--
Signed,
Ethin D. Probst


TianoCore Bug Triage - APAC / NAMO - Tue, 04/13/2021 6:30pm-7:30pm #cal-reminder

devel@edk2.groups.io Calendar <devel@...>
 

Reminder: TianoCore Bug Triage - APAC / NAMO

When: Tuesday, 13 April 2021, 6:30pm to 7:30pm, (GMT-07:00) America/Los Angeles

Where:https://teams.microsoft.com/l/meetup-join/19%3ameeting_MzA2YzBiM2MtZDM5OS00MjQyLWIyZGUtZDRmNTlkZTg5YmYy%40thread.v2/0?context=%7b%22Tid%22%3a%223f29ed5e-8d29-429d-a771-6b1ae4150dd7%22%2c%22Oid%22%3a%22634e9251-1a6d-4e35-8269-856651a5178f%22%7d

View Event

Organizer: Liming Gao gaoliming@...

Description:

You're invited to join a Microsoft Teams meeting

Title: TianoCore Bug Triage - APAC / NAMO
Time: Apr 14, 2021 9:30:00 AM

Join on your computer or mobile app
Click here to join the meeting


回复: [edk2-devel] GCC49 DEBUG AARCH64 and ARM builds use -O0

gaoliming
 

Ard:

-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Ard
Biesheuvel
发送时间: 2021年4月14日 0:37
收件人: Rebecca Cran <rebecca@nuviainc.com>
抄送: Laszlo Ersek <lersek@redhat.com>; edk2-devel-groups-io
<devel@edk2.groups.io>; Leif Lindholm <leif@nuviainc.com>; Liming Gao
(Byosoft address) <gaoliming@byosoft.com.cn>; Ard Biesheuvel
<ardb+tianocore@kernel.org>
主题: Re: [edk2-devel] GCC49 DEBUG AARCH64 and ARM builds use -O0

On Tue, 13 Apr 2021 at 14:12, Rebecca Cran <rebecca@nuviainc.com> wrote:

+Ard (with the correct email address)

On 4/13/21 4:32 AM, Laszlo Ersek wrote:
+Liming

On 04/12/21 17:10, Rebecca Cran wrote:
I noticed the GCC49 (and GCC48) AARCH64 and ARM DEBUG builds use
-O0,
unlike IA32 and X64 platforms which build with -Os.

e.g. from
https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/tools_def.te
mplate
:

DEBUG_GCC49_AARCH64_CC_FLAGS =
DEF(GCC49_AARCH64_CC_FLAGS) -O0

Is that deliberate, or should it be like X64 where DEBUG builds are
optimized and NOOPT is used when unoptimized binaries are needed?
Seems to go back to commit dafe0fedc508 ("BaseTools: Add GCC49
toolchain; align data sections to 0x40", 2014-07-28). My guess is that
in 2014, gcc (4.9) may have had issues with arm64 code generation with
-Os.

You hint at DEBUG_GCC48_AARCH64_CC_FLAGS too, which seems like a
promising clue at first -- because, perhaps the GCC49 flags in the
above-mentioned commit had simply been modeled on the then-existent
GCC48 ones.

Unfortunately however, the GCC48 entry appeared in the
less-than-helpfully-explained commit 2bc3256ca6d4 ("Sync BaseTool trunk
(version r2640) into EDKII BaseTools.", 2014-01-10).

Thanks
Laszlo
IIRC we only added NOOPT for ARM much later, and at that time, we
decided to leave GCC49 alone.
If no special reason, DEBUG_GCC49_AARCH64 can be updated from -O0 to -Os like GCC49_IA32 and GCC49_X64.

Thanks
Liming



Re: VirtIO Sound Driver (GSoC 2021)

Ethin Probst
 

Hi Andrew,

The developer guide for EDK2 drivers is a godsend. Thank you very
much, and thank you, Mike, for your excellent work on the guide! I may
just ahve to do my building on Linux and not Windows -- unless the Bug
-- bug 3302 -- has been fixed. I'll have to do testing on Linux, at
any rate, since Windows hosts do not support VirtIO emulation and I
can't seem to find any way of emulating them in a guest machine with
Windows as a host.

On 4/13/21, Andrew Fish <afish@apple.com> wrote:


On Apr 13, 2021, at 9:53 AM, Ethin Probst <harlydavidsen@gmail.com>
wrote:

Would it be possible for us to conduct discussion on the UEFI talkbox?
I don't mind using email, but things could definitely get moving
quicker over there (though its not a requirement obviously).
Sure, don’t think I’ve really used that but as long as I get pointed int he
right direction I can make it work.

For a device driver the general UEFI model is for the Entry point of the
driver to publish a EFI_DRIVER_BINDING_PROTOCOL[1]. The Supported() function
matches on the PCI devices. The Start() function installs the Protocols to
do work, and the Stop() undoes the Start().

Mike Kinney started this back in the day and it describes how to write UEFI
drivers:
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer%27s-Guide

[1]https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DriverBinding.h#L157

Thanks,

Andrew Fish

Here's how I generally envision the driver functioning:

1. Firmware/platform code calls InitaudioOutput() or something like
it. This function scans the PCIe bus and scans for one of the
following:
- Vendor ID 0x1AF4, device ID 0x1059: VirtIO sound device
- PCI class 0x0C, subclass 0x03, program interface 0x30 or 0x40: for
USB audio interface (I'm only thinking of targeting XHCI and USB 4,
and not UHCI, OHCI or EHCI). But maybe EDK2 will take that out of my
hands. If so, it will make things easier.
- For USB audio devices I'm not quite sure what to look for; I'm
definitely unused to USB.
2. If any of the above cases are found, appropriate driver
initialization occurs. Since for the time being I am solely focusing
on VirtIO sound devices, the VirtIO general initialization sequence
will occur as outlined in sec. 3 of the VirtIO specification available
at https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html
<https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html>.
As for actual protocol exposure that would be spec-worthy, for
EFI_AUDIO_OUTPUT_PROTOCOL, I'm not quite sure what to expose. VirtIO
is rather simple: there's a buffer for sending and receiving audio
data in PCM streams. So for that we could expose a Reset(),
RemapJack(), GetJackConfig(), GetPcmConfig(), SetPcmParams(),
Prepare(), Release(), Start(), and Stop() function for the
corresponding request types VIRTIO_SND_R_JACK_GET_CONFIG,
VIRTIO_SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG,
VIRTIO_SND_R_PCM_SET_PARAMS, VIRTIO_SND_R_PCM_PREPARE,
VIRTIO_SND_R_PCM_RELEASE, VIRTIO_SND_R_PCM_START, and
VIRTIO_SND_R_PCM_STOP control requests. However, for HDA things are a
lot more complex, so I'm not sure how that should work.
For VirtIO -- which is what I'll focus on for now -- everything is
described, in excellent detail, in sec. 5.14 of the above-linked
document. What are your guys's thoughts thus far and how should
everything be mapped to UEFI interfaces?

On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>> wrote:
Leif,

Since I have put some brain cells around this area in the past I can be
the
backup and help out too.

I’d also point out if you are having issues building or have general
questions on how things work it is fine to use the mailing list. I’ve got
a
lot of feedback that folks read or search the mailing list looking for
answer to their questions so one person asking can help out a lot of
other
people.

Thanks,

Andrew Fish

On Apr 13, 2021, at 5:28 AM, Leif Lindholm <leif@nuviainc.com> wrote:

Hi all, especially Ethin.

Apologies for radio silence - last week I was off on holiday, and
before
that ... let's just say corporate acquisitions generate some
distractions.
Anyway, I'm back, and since I'm down as the mentor for this task, feel
free to spam me with any remaining/new questions.

/
Leif

On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst <harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
wrote:
I'll attach the bug for the build tools to the BZ shortly.
Laszlo, thanks for that. I don't know their email addresses though.
And yes, I was going to make it device independent, as the majority
(if not all) of UEFI protocols are.

On 4/6/21, Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>
<mailto:lersek@redhat.com <mailto:lersek@redhat.com>>>
wrote:
On 03/31/21 08:41, Nate DeSimone wrote:
Another option is to put the protocol definition in MdeModulePkg and
mark it with the EDKII_ prefix. For my last “code first” UEFI spec
contribution I did this with the PPI that added up getting added.
The new audio protocol should be generic, only its implementation in
question should be virtio specific.

Please include Gerd Hoffmann (CC'd) in the protocol design, as well as
the developers of the virtio-sound device model in QEMU.

Thanks
Laszlo





Thanks,

Nate



*From: *<devel@edk2.groups.io <mailto:devel@edk2.groups.io>
<mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>> on
behalf
of "Andrew Fish via groups.io <http://groups.io/> <http://groups.io/
<http://groups.io/>>"
<afish=apple.com@groups.io <mailto:afish=apple.com@groups.io>
<mailto:apple.com@groups.io <mailto:apple.com@groups.io>>>
*Reply-To: *"devel@edk2.groups.io <mailto:devel@edk2.groups.io>
<mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>"
<devel@edk2.groups.io <mailto:devel@edk2.groups.io>
<mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>,
"afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com
<mailto:afish@apple.com>>" <afish@apple.com <mailto:afish@apple.com>
<mailto:afish@apple.com <mailto:afish@apple.com>>>
*Date: *Tuesday, March 30, 2021 at 10:54 PM
*To: *edk2-devel-groups-io <devel@edk2.groups.io
<mailto:devel@edk2.groups.io>
<mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>,
"harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>"
<harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
*Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>
<mailto:rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>>>
*Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)





On Mar 30, 2021, at 5:01 PM, Ethin Probst <harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>>
wrote:



I'm wondering where exactly I should add the VirtIO sound
protocol.
I
just familiarized myself with the build system and am about to
test
it
by building OVMF if possible, but I'm wondering where I should
actually put the protocol and all that stuff. Maybe there's
documentation I've missed as well.



Ethin,



For the driver I’d match the patter of OVMF [1] and use
OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers as a
template.



The protocol is more of a public thing. I think eventually we would
like
to publish the protocol in the UEFI Spec (I can help with that part)
and
that would mean we put the Protocol definition in
MdePkg/Include/Protocol, but we don’t want to do that before it is
standardized as that causes compatibility issues. So this is a “code
first project” (code prototype and then contribute to the UEFI Forum
for
inclusion in the specification) so we need to follow some code first
rules that I don’t remember of the top of my head? So why not start
out
the protocol definition OvmfPkg/Include/Protocol. You can also add a
test application looks like you can just use the root [2] of OVMF for
that. That way the project is not blocked.



We can have a conversation on the mailing list about better places to
put stuff, and it should be easy enough to move stuff around if
everything else is working.



[1] find OvmfPkg -iname '*Virtio*.inf'

OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf

OvmfPkg/VirtioScsiDxe/VirtioScsi.inf

OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf

OvmfPkg/Library/VirtioLib/VirtioLib.inf

OvmfPkg/VirtioGpuDxe/VirtioGpu.inf

OvmfPkg/VirtioBlkDxe/VirtioBlk.inf

OvmfPkg/Virtio10Dxe/Virtio10.inf

OvmfPkg/VirtioNetDxe/VirtioNet.inf

OvmfPkg/VirtioRngDxe/VirtioRng.inf



[2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf |
grep MODULE_TYPE

EnrollDefaultKeys/EnrollDefaultKeys.inf:13: MODULE_TYPE
= UEFI_APPLICATION



Thanks,



Andrew Fish






On 3/30/21, Ethin Probst via groups.io <http://groups.io/>
<http://groups.io/ <http://groups.io/>>
<http://groups.io/ <http://groups.io/> <http://groups.io/
<http://groups.io/>>>
<harlydavidsen=gmail.com@groups.io
<mailto:harlydavidsen=gmail.com@groups.io> <mailto:gmail.com@groups.io
<mailto:gmail.com@groups.io>>
<mailto:harlydavidsen <mailto:harlydavidsen>=gmail.com@groups.io
<mailto:gmail.com@groups.io>
<mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>> wrote:

I agree. Plus, it gives me a chance to finally learn the EDK2
build
system and how it works! I've been working on a hobby OS as a
side
project and, though learning from other code examples from
OSes
is
fun, I have to say that learning from the firmware code like
from
SeaBIOS has been some of the most enlightening and interesting
times
thus far.
Thanks for the link to your code, Rafael; once I get virtIO
support
in, I can work on HDA support, though I might tackle USB
support
second and HDA third. We'll see, but VirtIO definitely is
coming
first.

As I said before, I look forward to working with all of you
wonderful
people!

On 3/30/21, Rafael Rodrigues Machado
<rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>
<mailto:rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>>
<mailto:rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>
<mailto:rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>>>>
wrote:

This would be amazing so people can continue my work
related
to
accessibility at BIOS. Something desired by the blind
people
since the
90's
Just for reference, this is what I have done:


https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
<https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
<https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
<https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>

Thanks
Rafael

Em seg, 29 de mar de 2021 20:24, Ethin Probst
<harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
escreveu:


Hello everyone,

This is the first time I've ever contributed to EDK2.
As
part of GSoC
2021, I have submitted a proposal to implement a UEFI
audio output
protocol that will utilize the VirtIO sound driver.
I've
already
submitted a draft proposal, and apologize if I've done
things out of
order. This is my first time doing GSoC 2021, and
contributing to EDK2
felt like a really fun thing to do!

I look forward to working with you guys on this and
any
future projects!
:-)

--
Signed,
Ethin D. Probst









--
Signed,
Ethin D. Probst







--
Signed,
Ethin D. Probst






--
Signed,
Ethin D. Probst






--
Signed,
Ethin D. Probst


--
Signed,
Ethin D. Probst


Re: VirtIO Sound Driver (GSoC 2021)

Andrew Fish
 



On Apr 13, 2021, at 9:53 AM, Ethin Probst <harlydavidsen@...> wrote:

Would it be possible for us to conduct discussion on the UEFI talkbox?
I don't mind using email, but things could definitely get moving
quicker over there (though its not a requirement obviously).


Sure, don’t think I’ve really used that but as long as I get pointed int he right direction I can make it work.

For a device driver the general UEFI model is for the Entry point of the driver to publish a EFI_DRIVER_BINDING_PROTOCOL[1]. The Supported() function matches on the PCI devices. The Start() function installs the Protocols to do work, and the Stop() undoes the Start().

Mike Kinney started this back in the day and it describes how to write UEFI drivers: https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer%27s-Guide


Thanks,

Andrew Fish

Here's how I generally envision the driver functioning:

1. Firmware/platform code calls InitaudioOutput() or something like
it. This function scans the PCIe bus and scans for one of the
following:
- Vendor ID 0x1AF4, device ID 0x1059: VirtIO sound device
- PCI class 0x0C, subclass 0x03, program interface 0x30 or 0x40: for
USB audio interface (I'm only thinking of targeting XHCI and USB 4,
and not UHCI, OHCI or EHCI). But maybe EDK2 will take that out of my
hands. If so, it will make things easier.
- For USB audio devices I'm not quite sure what to look for; I'm
definitely unused to USB.
2. If any of the above cases are found, appropriate driver
initialization occurs. Since for the time being I am solely focusing
on VirtIO sound devices, the VirtIO general initialization sequence
will occur as outlined in sec. 3 of the VirtIO specification available
at https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html.
As for actual protocol exposure that would be spec-worthy, for
EFI_AUDIO_OUTPUT_PROTOCOL, I'm not quite sure what to expose. VirtIO
is rather simple: there's a buffer for sending and receiving audio
data in PCM streams. So for that we could expose a Reset(),
RemapJack(), GetJackConfig(), GetPcmConfig(), SetPcmParams(),
Prepare(), Release(), Start(), and Stop() function for the
corresponding request types VIRTIO_SND_R_JACK_GET_CONFIG,
VIRTIO_SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG,
VIRTIO_SND_R_PCM_SET_PARAMS, VIRTIO_SND_R_PCM_PREPARE,
VIRTIO_SND_R_PCM_RELEASE, VIRTIO_SND_R_PCM_START, and
VIRTIO_SND_R_PCM_STOP control requests. However, for HDA things are a
lot more complex, so I'm not sure how that should work.
For VirtIO -- which is what I'll focus on for now -- everything is
described, in excellent detail, in sec. 5.14 of the above-linked
document. What are your guys's thoughts thus far and how should
everything be mapped to UEFI interfaces?

On 4/13/21, Andrew Fish <afish@...> wrote:
Leif,

Since I have put some brain cells around this area in the past I can be the
backup and help out too.

I’d also point out if you are having issues building or have general
questions on how things work it is fine to use the mailing list. I’ve got a
lot of feedback that folks read or search the mailing list looking for
answer to their questions so one person asking can help out a lot of other
people.

Thanks,

Andrew Fish

On Apr 13, 2021, at 5:28 AM, Leif Lindholm <leif@...> wrote:

Hi all, especially Ethin.

Apologies for radio silence - last week I was off on holiday, and before
that ... let's just say corporate acquisitions generate some
distractions.
Anyway, I'm back, and since I'm down as the mentor for this task, feel
free to spam me with any remaining/new questions.

/
   Leif

On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst <harlydavidsen@...
<mailto:harlydavidsen@...>> wrote:
I'll attach the bug for the build tools to the BZ shortly.
Laszlo, thanks for that. I don't know their email addresses though.
And yes, I was going to make it device independent, as the majority
(if not all) of UEFI protocols are.

On 4/6/21, Laszlo Ersek <lersek@... <mailto:lersek@...>>
wrote:
On 03/31/21 08:41, Nate DeSimone wrote:
Another option is to put the protocol definition in MdeModulePkg and
mark it with the EDKII_ prefix. For my last “code first” UEFI spec
contribution I did this with the PPI that added up getting added.

The new audio protocol should be generic, only its implementation in
question should be virtio specific.

Please include Gerd Hoffmann (CC'd) in the protocol design, as well as
the developers of the virtio-sound device model in QEMU.

Thanks
Laszlo





Thanks,

Nate



*From: *<devel@edk2.groups.io <mailto:devel@edk2.groups.io>> on behalf
of "Andrew Fish via groups.io <http://groups.io/>"
<afish@... <mailto:apple.com@groups.io>>
*Reply-To: *"devel@edk2.groups.io <mailto:devel@edk2.groups.io>"
<devel@edk2.groups.io <mailto:devel@edk2.groups.io>>,
"afish@... <mailto:afish@...>" <afish@...
<mailto:afish@...>>
*Date: *Tuesday, March 30, 2021 at 10:54 PM
*To: *edk2-devel-groups-io <devel@edk2.groups.io
<mailto:devel@edk2.groups.io>>,
"harlydavidsen@... <mailto:harlydavidsen@...>"
<harlydavidsen@... <mailto:harlydavidsen@...>>
*Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado@...
<mailto:rafaelrodrigues.machado@...>>
*Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)





   On Mar 30, 2021, at 5:01 PM, Ethin Probst <harlydavidsen@...
<mailto:harlydavidsen@...>
   <mailto:harlydavidsen@... <mailto:harlydavidsen@...>>>
wrote:



   I'm wondering where exactly I should add the VirtIO sound protocol.
I
   just familiarized myself with the build system and am about to
test
it
   by building OVMF if possible, but I'm wondering where I should
   actually put the protocol and all that stuff. Maybe there's
   documentation I've missed as well.



Ethin,



For the driver I’d match the patter of OVMF [1] and use
OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers as a
template.



The protocol is more of a public thing. I think eventually we would
like
to publish the protocol in the UEFI Spec (I can help with that part)
and
that would mean we put the Protocol definition in
MdePkg/Include/Protocol, but we don’t want to do that before it is
standardized as that causes compatibility issues. So this is a “code
first project” (code prototype and then contribute to the UEFI Forum
for
inclusion in the specification) so we need to follow some code first
rules that I don’t remember of the top of my head? So why not start
out
the protocol definition OvmfPkg/Include/Protocol. You can also add a
test application looks like you can just use the root [2] of OVMF for
that. That way the project is not blocked.



We can have a conversation on the mailing list about better places to
put stuff, and it should be easy enough to move stuff around if
everything else is working.



[1] find OvmfPkg  -iname '*Virtio*.inf'

OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf

OvmfPkg/VirtioScsiDxe/VirtioScsi.inf

OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf

OvmfPkg/Library/VirtioLib/VirtioLib.inf

OvmfPkg/VirtioGpuDxe/VirtioGpu.inf

OvmfPkg/VirtioBlkDxe/VirtioBlk.inf

OvmfPkg/Virtio10Dxe/Virtio10.inf

OvmfPkg/VirtioNetDxe/VirtioNet.inf

OvmfPkg/VirtioRngDxe/VirtioRng.inf



[2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf |
grep MODULE_TYPE

EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
   = UEFI_APPLICATION



Thanks,



Andrew Fish






   On 3/30/21, Ethin Probst via groups.io <http://groups.io/>
<http://groups.io/ <http://groups.io/>>
   <harlydavidsen@... <mailto:gmail.com@groups.io>
   <mailto:harlydavidsen <mailto:harlydavidsen>=gmail.com@groups.io
<mailto:gmail.com@groups.io>>> wrote:

       I agree. Plus, it gives me a chance to finally learn the EDK2
build
       system and how it works! I've been working on a hobby OS as a
side
       project and, though learning from other code examples from
OSes
is
       fun, I have to say that learning from the firmware code like
from
       SeaBIOS has been some of the most enlightening and interesting
times
       thus far.
       Thanks for the link to your code, Rafael; once I get virtIO
support
       in, I can work on HDA support, though I might tackle USB
support
       second and HDA third. We'll see, but VirtIO definitely is
coming
       first.

       As I said before, I look forward to working with all of you
       wonderful
       people!

       On 3/30/21, Rafael Rodrigues Machado
       <rafaelrodrigues.machado@...
<mailto:rafaelrodrigues.machado@...>
       <mailto:rafaelrodrigues.machado@...
<mailto:rafaelrodrigues.machado@...>>>
       wrote:

           This would be amazing so people can continue my work
related
to
           accessibility at BIOS. Something desired by the blind
people
           since the
           90's
           Just for reference, this is what I have done:


https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
<https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>

           Thanks
           Rafael

           Em seg, 29 de mar de 2021 20:24, Ethin Probst
           <harlydavidsen@... <mailto:harlydavidsen@...>>
           escreveu:


               Hello everyone,

               This is the first time I've ever contributed to EDK2.
As
               part of GSoC
               2021, I have submitted a proposal to implement a UEFI
               audio output
               protocol that will utilize the VirtIO sound driver.
I've
               already
               submitted a draft proposal, and apologize if I've done
               things out of
               order. This is my first time doing GSoC 2021, and
               contributing to EDK2
               felt like a really fun thing to do!

               I look forward to working with you guys on this and
any
               future projects!
               :-)

               --
               Signed,
               Ethin D. Probst









       --
       Signed,
       Ethin D. Probst







   --
   Signed,
   Ethin D. Probst










--
Signed,
Ethin D. Probst










-- 
Signed,
Ethin D. Probst




Re: [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

Samer El-Haj-Mahmoud
 

In order to make progress on this, I opened a code-first ECR against the UEFI spec to clarify the language around the Boot#### options processing.

Code First ECR: https://bugzilla.tianocore.org/show_bug.cgi?id=3336

Feedback on the proposed language is appreciated. Please provide the feedback directly in the BZ above.

I will update the thread/BZ with results from USWG.

Thanks,
--Samer

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Pete
Batard via groups.io
Sent: Thursday, February 25, 2021 5:55 AM
To: Wang, Sunny (HPS SW) <sunnywang@hpe.com>; Laszlo Ersek
<lersek@redhat.com>; Leif Lindholm <leif@nuviainc.com>;
devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>; zhichao.gao@intel.com
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Andrei
Warkentin (awarkentin@vmware.com) <awarkentin@vmware.com>; Ard
Biesheuvel <ardb+tianocore@kernel.org>; Andrew Fish <afish@apple.com>;
Michael D Kinney <michael.d.kinney@intel.com>; Jian J Wang
<jian.j.wang@intel.com>; Hao A Wu <hao.a.wu@intel.com>;
Sunny.Hsuanwen.Wang@gmail.com
Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
recovery

Hi Sunny,

I appreciate the input, but seeing that it is clear that no consensus has been
reached with regards to how the specs should be interpreted, and that at
least 4 separate people have now indicated that their interpretation is
different from the one you are putting forward (i.e.
you assert that the current code implementation is specs compliant whereas
we assert that the current code implementation is not specs compliant), I
believe that any further work on this will have to be conditioned, first, by a
specs update, that removes any ambiguity as to the scope in which
ReadyToBoot should apply.

Until that has happened, it seems very pointless to me to start talking
possible code workarounds, because we still can't appear to be in agreement
as to whether the current code implementation of ReadyToBoot is specs
compliant or not.

Now, even as I am the one proposing it, I'm afraid that I am not planning to
be the one opening a formal specs update request, since there really is only
so much more time I am willing to devote to this matter. But I am hoping
somebody else will.

Regards,

/Pete

On 2021.02.22 09:28, Wang, Sunny (HPS SW) wrote:
Hi all,

How about we signal ReadyToBoot ONLY for the default platform recovery
option? The default platform recovery option here means the one created
by the code below in BdsEntry().
Status = EfiBootManagerInitializeLoadOption (
&PlatformDefaultBootOption,
LoadOptionNumberUnassigned,
LoadOptionTypePlatformRecovery,
LOAD_OPTION_ACTIVE,
L"Default PlatformRecovery",
FilePath,
NULL,
0
);

In other words, we just need to slightly update Pete's patch as the
following (adding the code below to EfiBootManagerProcessLoadOption()):

+ if ((LoadOption->OptionType == LoadOptionTypePlatformRecovery) &&
StrCmp (LoadOption ->Description, L"Default
PlatformRecovery")) {
+ //
+ // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about
to load and execute the boot option.
+ //
+ EfiSignalEventReadyToBoot ();

+ //
+ // Report Status Code to indicate ReadyToBoot was signalled
+ //
+ REPORT_STATUS_CODE (EFI_PROGRESS_CODE,
+ (EFI_SOFTWARE_DXE_BS_DRIVER |
+ EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
+ }

I think the existing platforms that have their platform-specific
PlatformRecovery option may also do either of the following things to make
the system have no chance to load the default platform recovery option
because they do have a better way to recover the boot options:
1. Make their PlatformRecovery option have higher priority than the
default platform recovery option (has a lower number (####) than the
default platform recovery option)
2. Remove the default platform recovery option.
Therefore, if we only signal ReadyToBoot for the default platform recovery
option, this may not affect the existing platforms because the code may
never be run on these platforms.





If the solution above doesn't work, I think the suggestion (Solution 2:
adding a new application as a PlatformRecovery####) I mentioned, in the
beginning, can be re-considered. The suggestion (solution 2) is based on the
thoughts below:
1. I think that processing/evaluating the Boot#### can be interpreted as
the code after the comment " 6. Load EFI boot option to ImageHandle" in
EfiBootManagerBoot() because these code are similar to the code in
EfiBootManagerProcessLoadOption(). Based on this, I think our current
implementation is compliant with the description below in the UEFI spec. Of
course, we can improve our implementation by moving the code for
processing/evaluating the Boot#### from EfiBootManagerBoot() to
EfiBootManagerProcessLoadOption() and make EfiBootManagerBoot() call
EfiBootManagerProcessLoadOption().
“After all SysPrep#### variables have been launched and exited,
the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group
and begin to evaluate Boot#### variables with Attributes set to
LOAD_OPTION_CATEGORY_BOOT according to the order defined by
BootOrder. The FilePathList of variables marked
LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the
completion of EFI_EVENT_GROUP_READY_TO_BOOT event group
processing."
2. Moreover, it looks like we want to process PlatformRecovery####
option in the same way as Boot#### (do more things like setting BootCurrent
for PlatformRecovery####). If so, I would still prefer to do what I suggest in
the beginning to create a new application as a new PlatformRecovery####
option for generating and launching a boot option for the bootable image
that is found by using a short-form File Path Media Device Path so that we
won't run into other difficulties. At least, I already saw the difficulty of no
connection between BootCurrent variable and PlatformRecovery####
variable. Of course, this application can be implemented without platform
specific stuff, so it can be commonly used by all platforms that need to load a
boot image discovered by using short-form File Path Media Device Path.




Regards,
Sunny Wang

-----Original Message-----
From: Laszlo Ersek <lersek@redhat.com>
Sent: Wednesday, February 17, 2021 10:26 PM
To: Pete Batard <pete@akeo.ie>; Leif Lindholm <leif@nuviainc.com>;
devel@edk2.groups.io
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Andrei
Warkentin (awarkentin@vmware.com) <awarkentin@vmware.com>;
Wang, Sunny
(HPS SW) <sunnywang@hpe.com>; zhichao.gao@intel.com;
ray.ni@intel.com;
Ard Biesheuvel <ardb+tianocore@kernel.org>; Andrew Fish
<afish@apple.com>; Michael D Kinney <michael.d.kinney@intel.com>; Jian
J Wang <jian.j.wang@intel.com>; Hao A Wu <hao.a.wu@intel.com>
Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2][PATCH 1/1]
MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
recovery

On 02/17/21 13:18, Pete Batard wrote:
Hi Leif,

Thanks for trying to resurrect this issue.

At this stage, and despite some initial pushback in the bugzilla
ticket, I believe we can all agree with the consensus that
UefiBootManagerLib is not in fact specs-compliant and therefore needs
to be fixed, one way or another, to make it specs-compliant.

My take on this is that, rather than propose a new patch, I'd much
rather have the current maintainers agree on the course of action to
fix the library (which, as Leif suggests, might very well be to split
the library into a specs-compliant and non-specs-compliant version),
as it would of course be better if the fix came from people who have
better understanding of the ramifications we might face with trying
to correct the current behaviour, and especially, who have knowledge
of the platforms that might be impacted from making the lib specs-
compliant.

Especially, I don't think that the patch that I originally submitted
for this, or the additional proposals we made, are still receivable,
as they seem to fall short of fixing the issue in a manner that all
platforms can be happy with. And that is why I'd like to hear from
the maintainers on what their preferred approach would be.
A new Feature PCD could satisfy both sets of platforms, could it not?

(Sorry if the original patch already had such a PCD; I don't
remember.)

Of course then we'd have a debate around the DEC default for the new
PCD
-- I'd say the default value of the PCD should match the spec-mandated
behavior.

I don't recall any specifics, but a bug-compat pattern that's sometimes used
is this:

if (BugCompatEnabled) {
//
// do the right thing in the wrong place, for legacy platforms' sake
//
Foo ();
}

//
// Do some stuff.
//
Bar ();

if (!BugCompatEnabled) {
//
// do the right thing in the right place, for conformant platforms
//
Foo ();
}

Not sure if it applies here.

Thanks
Laszlo


On 2021.02.17 11:42, Leif Lindholm wrote:
Hi Pete, +various

Resurrecting this old thread since Ard pointed out an issue I ran
into myself had already been encountered by Pete.
And the bugzilla ticket (directly below this reply) has had no
relevant progress since August.

Executive summary:
The current UefiBootManagerLib implementation of the
PlatformRecovery path does not notify the
EFI_EVENT_GROUP_READY_TO_BOOT event.

The argument has been made that since changing this would affect an
unnamed number of non-public platforms, the behaviour cannot be
changed even though it violates the UEFI specification.

I disagree with that statement. If we want to fork
UefiBootManagerLib into a BrokenLegacyUefiBootManagerLib and an
actually correct one, and have those platforms move to the
BrokenLegacy variant, I'm OK with that.

But using the default version should give specification-compliant
behaviour.

/
Leif

On Tue, Jun 30, 2020 at 18:17:10 +0100, Pete Batard wrote:
Please note that I have created a bug report
(https://bugzilla.tianocore.org/show_bug.cgi?id=2831) to address
the non-compliance issue was raised during the course of the
discussion below.

Regards,

/Pete


On 2020.06.17 18:06, Samer El-Haj-Mahmoud wrote:
I worked with Pete offline on this..

This code seems to be violating the UEFI Spec:

https://github.com/tianocore/edk2/blob/a56af23f066e2816c67b7c6e64d
e
7ddefcd70780/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c#L176
3


//
// 3. Signal the EVT_SIGNAL_READY_TO_BOOT event when we are
about to load and execute
// the boot option.
//
if (BmIsBootManagerMenuFilePath (BootOption->FilePath)) {
DEBUG ((EFI_D_INFO, "[Bds] Booting Boot Manager Menu.\n"));
BmStopHotkeyService (NULL, NULL);
} else {
EfiSignalEventReadyToBoot();
//
// Report Status Code to indicate ReadyToBoot was signalled
//
REPORT_STATUS_CODE (EFI_PROGRESS_CODE,
(EFI_SOFTWARE_DXE_BS_DRIVER |
EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
//
// 4. Repair system through DriverHealth protocol
//
BmRepairAllControllers (0);
}

The UEFI Spec section 3.1.7 clearly states that Boot Options (and
their FilePathList) *shall not* be evaluated prior to the
completion of EFI_EVENT_GROUP_READY_TO_BOOT event group
processing:

"After all SysPrep#### variables have been launched and exited,
the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event
group and begin to evaluate Boot#### variables with Attributes set
to LOAD_OPTION_CATEGORY_BOOT according to the order defined
by
BootOrder. The FilePathList of variables marked
LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the
completion of EFI_EVENT_GROUP_READY_TO_BOOT event group
processing."

This is a prescriptive language that is stronger than the language
in section 7.1 which defines the ReadyToBoot event group in a
general way:

"EFI_EVENT_GROUP_RESET_SYSTEM
This event group is notified by the system when ResetSystem() is
invoked and the system is about to be reset. The event group is
only notified prior to ExitBootServices() invocation."

The EDK2 code in the else block above (to call
EfiSignalEventReadyToBoot() ) need to move before the code that is
processing BootOption->FilePath. In fact, why is this signaling
even a BootManager task? It should be a higher level BDS task
(after processing SysPrp and before processing Boot options, per the
spec).
This would be somewhere around
https://github.com/tianocore/edk2/blob/b15646484eaffcf7cc464fdea02
1
4498f26addc2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c#L1007
where SysPrep is processed.

This should also take care of the issue Pete reported in this
thread, without the need for explicitly signaling ReadyToBoot from
PlatformRecovery (or changing the UEFI spec).

Thanks,
--Samer



From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
Samer El-Haj-Mahmoud via groups.io
Sent: Wednesday, June 17, 2020 12:42 PM
To: devel@edk2.groups.io; Andrei Warkentin
(awarkentin@vmware.com)
<awarkentin@vmware.com>; Wang, Sunny (HPS SW)
<sunnywang@hpe.com>;
pete@akeo.ie
Cc: zhichao.gao@intel.com; ray.ni@intel.com; Ard Biesheuvel
<Ard.Biesheuvel@arm.com>; leif@nuviainc.com; Samer El-Haj-
Mahmoud
<Samer.El-Haj-Mahmoud@arm.com>
Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on
platform
recovery

The UEFI spec (3.1.7) says:

"After all SysPrep#### variables have been launched and exited,
the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event
group and begin to evaluate Boot#### variables with Attributes set
to LOAD_OPTION_CATEGORY_BOOT according to the order defined
by
BootOrder. The FilePathList of variables marked
LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the
completion of EFI_EVENT_GROUP_READY_TO_BOOT event group
processing."

The way I read this, I expect ReadyToBoot to be signaled after
SysPrep#### (if any) are processed, but before Boot#### are
processed. Is my understanding correct that this language implies
ReadyToBoot need to be signaled even if BootOrder does not contain
any Boot#### options marked as LOAD_OPTION_CATEGORY_BOOT?
And if
so, is EDK2 not doing this, which leads us to this patch
(signaling it in PlatformRecovery?)



From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
On
Behalf Of Andrei Warkentin via groups.io
Sent: Wednesday, June 17, 2020 12:37 PM
To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>;
mailto:devel@edk2.groups.io; mailto:pete@akeo.ie
Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; Ard
Biesheuvel <mailto:Ard.Biesheuvel@arm.com>;
mailto:leif@nuviainc.com
Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on
platform
recovery

Thanks Pete.

I think the question I have, that I hope Tiano veterans can chime
in, is whether we are doing the right thing, or if we should be
overriding the boot mode? I.e. is it normal that we boot up in
recovery until options are saved?


A


________________________________________
From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
on
behalf of Pete Batard via groups.io
<mailto:pete=akeo.ie@groups.io>
Sent: Wednesday, June 17, 2020 11:34 AM
To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>;
mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
Cc: mailto:zhichao.gao@intel.com <mailto:zhichao.gao@intel.com>;
mailto:ray.ni@intel.com <mailto:ray.ni@intel.com>;
mailto:ard.biesheuvel@arm.com <mailto:ard.biesheuvel@arm.com>;
mailto:leif@nuviainc.com <mailto:leif@nuviainc.com>
Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on
platform
recovery

On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:
Thanks for checking my comments, Pete.

Or is the "one more" the issue, meaning that it would get
signaled more than once?
[Sunny] Yeah, it would get signaled more than once if the
PlatformRecovery option (a UEFI application) calls
EfiBootManagerBoot() to launch the recovered boot option inside
of the application.
Okay.

One element that I'm going to point out is that, with the current
EDK2 code (i.e. without this proposal applied), and after a user
goes into the setup to save their boot options in order for
regular boot options to get executed instead of PlaformRecovery,
the OnReadyToBoot event is actually called twice.

So my understanding is that, while we of course want to avoid this
and any patch proposal should actively try to prevent it, it seems
we already have behaviour in EDK2 that can lead to OnReadyToBoot
being signalled more than once.

At least the current Pi 4 platform does demonstrate this behaviour.
For instance, if you run DEBUG, you will see two instances of:

RemoveDtStdoutPath: could not retrieve DT blob - Not Found

which is a one-instance message generated from the
ConsolePrefDxe's
OnReadyToBoot() call. I've also confirmed more specifically that
OnReadyToBoot() is indeed called twice.

I don't recall us doing much of any special with regards to boot
options for the Pi platform, so my guess is that it's probably not
the only platform where OnReadyToBoot might be signalled more
than
once, and that this might be tied to a default EDK2 behaviour.
Therefore I don't see having a repeated event as a major deal
breaker (though, again, if we can avoid that, we of course will
want to).

I don't mind trying an alternative approach, but I don't
understand how what you describe would help. Can you please be
more specific about what you have in mind?
[Sunny] Sure. I added more information below. If it is still not
clear enough, feel free to let me know.
1. Create a UEFI application with the code to signal
ReadyToBoot and pick /efi/boot/bootaa64.efi from either SD or USB
and run it.
So that would basically be adding code that duplicates, in part,
what Platform Recovery already does.

I have to be honest: Even outside of the extra work this would
require, I don't really like the idea of having to write our own
application, as it will introduce new possible points of failures
and require extra maintenance (especially as we will want to be
able to handle network boot and other options, and before long, I
fear that we're going to have to write our own Pi specific boot
manager). Doing so simply because the current Platform Recovery,
which does suit our needs otherwise, is not designed to call
ReadyToBoot does not seem like the best course of action in my
book.

Instead, I still logically believe that any option that calls a
boot loader should signal ReadyToBoot, regardless of whether it
was launched from Boot Manager or Platform Recovery, and that it
shouldn't be left to each platform to work around that.

Of course, I understand that this would require a specs change,
and that it also may have ramifications for existing platforms
that interpret the current specs pedantically. But to me,
regardless of what the specs appear to be limiting it to right
now, the logic of a "ReadyToBoot"
event is that it should be signalled whenever a bootloader is
about to be executed, rather than only when a bootloader happened
to be launched through a formal Boot Manager option.

I would therefore appreciate if other people could weigh in on
this matter, to see if I'm the only one who believes that we could
ultimately have more to gain from signalling ReadyToBoot with
PlatformRecovery options than leaving things as they stand right
now...

2. Then, call EfiBootManagerInitializeLoadOption like
the following in a DXE driver or other places before "Default
PlatformRecovery" registration:
Status = EfiBootManagerInitializeLoadOption (
&LoadOption,

0,
-> 0 is the OptionNumber to let application be load before "
Default PlatformRecovery" option
LoadOptionTypePlatformRecovery,
LOAD_OPTION_ACTIVE,
L"Application for recovering boot options",

FilePath,
-> FilePath is the Application's device path,
NULL,
0
);


My reasoning is that, if PlatformRecovery#### can execute a
regular bootloader like /efi/boot/boot####.efi from installation
media, then it should go through the same kind of initialization
that happens for a regular boot option, and that should include
signaling the ReadyToBoot event.
[Sunny] Thanks for clarifying this, and Sorry about that I missed
your cover letter for this patch. I was just thinking that we
may not really need to make this behavior change in both EDK II
code and UEFI specification for solving the problem specific to
the case that OS is loaded by "Default PlatformRecovery" option,
The way I see it is that the Pi platform is unlikely to be the
only one where PlatformRecovery is seen as a means to install an OS.
Granted, this may seem like abusing the option, but since UEFI
doesn't provide an "Initial OS Install" mode, I would assert that
it as good a use of this option as any.

In other words, I don't think this improvement would only benefit
the Pi platform.

and I'm also not sure if it is worth making this change to affect
some of the system or BIOS vendors who have implemented their
PlatformRecovery option.
That's a legitimate concern, and I would agree the one major
potential pitfall of this proposal, if there happens to exist a
system where an OnReadyToBoot even before running the recovery
option can have adverse effects.

I don't really believe that such a system exists, because I expect
most recovery boot loaders to also work (or at least have been
designed to
work) as regular boot options. But I don't have enough experience
with platform recovery to know if that's a correct assertion to make...

If the alternative approach I mentioned works for you, I think
that would be an easier solution.
Right now, even as the patch proposal has multiple issues that
require it to be amended (Don't signal ReadyToBoot except for
PlatformRecovery
+ Prevent situations where ReadyToBoot could be signalled multiple
times) I still see it as both an easier solution than the
alternative, as well as one that *should* benefit people who
design Platform Recovery UEFI applications in the long run. So
that is why I am still trying to advocate for it.

But I very much hear your concerns, and I agree that specs changes
are better avoided when possible.

Thus, at this stage, even as I don't want to drag this discussion
much further, I don't feel like I want to commit to one solution
or the other before we have had a chance to hear other people, who
may have their own opinion on the matter, express their views.

Regards,

/Pete



Regards,
Sunny Wang

-----Original Message-----
From: Pete Batard [mailto:pete@akeo.ie]
Sent: Wednesday, June 17, 2020 6:59 PM
To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>;
mailto:devel@edk2.groups.io
Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com;
mailto:ard.biesheuvel@arm.com; mailto:leif@nuviainc.com
Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on
platform
recovery

Hi Sunny, thanks for looking into this.

On 2020.06.17 09:16, Wang, Sunny (HPS SW) wrote:
Hi Pete.

Since the EfiBootManagerProcessLoadOption is called by
ProcessLoadOptions as well, your change would also cause some
unexpected behavior like:
1. Signal one more ReadyToBoot for the PlatformRecovery option
which is an application that calls EfiBootManagerBoot() to
launch its recovered boot option.
I'm not sure I understand how this part is unwanted.

The point of this patch is to ensure that ReadyToBoot is
signalled for the PlatformRecovery option, so isn't what you
describe above exactly what we want?

Or is the "one more" the issue, meaning that it would get
signalled more than once?


2. Signal ReadyToBoot for SysPrep#### or Driver#### that is not
really a "boot" option.
Yes, I've been wondering about that, because BdsEntry.c's
ProcessLoadOptions(), which calls
EfiBootManagerProcessLoadOption(),
mentions that it will load will load and start every Driver####,
SysPrep#### or PlatformRecovery####. But the comment about the
while() loop in EfiBootManagerProcessLoadOption() only mentions
PlatformRecovery####.

If needed, I guess we could amend the patch to detect the type of
option and only signal ReadyToBoot for PlatformRecovery####.

To solve your problem, creating a PlatformRecovery option with
the smallest option number and using it instead of default one
(with short-form File Path Media Device Path) looks like a
simpler solution.
I don't mind trying an alternative approach, but I don't
understand how what you describe would help. Can you please be
more specific about what you have in mind?

Our main issue here is that we must have ReadyToBoot signalled so
that the ReadyToBoot() function callback from
EmbeddedPkg/Drivers/ConsolePrefDxe gets executed in order for
the
boot loader invoked from PlatformRecovery#### to use a properly
initialized graphical console. So I'm not sure I quite get how
switching from one PlatformRecovery#### option to another would
improve things.

If it helps, here is what we currently default to, in terms of
boot options, on a Raspberry Pi 4 platform with a newly build
firmware:

[Bds]=============Begin Load Options Dumping
...=============
Driver Options:
SysPrep Options:
Boot Options:
Boot0000: UiApp 0x0109
Boot0001: UEFI Shell 0x0000
PlatformRecovery Options:
PlatformRecovery0000: Default PlatformRecovery
0x0001 [Bds]=============End Load Options
Dumping=============

With this, PlatformRecovery0000 gets executed by default, which
is what we want, since it will pick /efi/boot/bootaa64.efi from
either SD or USB and run it, the only issue being that, because
ReadyToBoot has not been executed, the graphical console is not
operative so users can't interact with the OS installer.

So I'm really not sure how adding an extra PlatformRecovery####
would help. And I'm also not too familiar with how one would go
around to add such an entry...

By the way, I also checked the UEFI specification. It looks
making sense to only signal ReadyToBoot for boot option
(Boot####).

That's something I considered too, but I disagree with this
conclusion.

My reasoning is that, if PlatformRecovery#### can execute a
regular bootloader like /efi/boot/boot####.efi from installation
media, then it should go through the same kind of initialization
that happens for a regular boot option, and that should include
signalling the ReadyToBoot event.

If there was a special bootloader for PlatformRecovery#### (e.g.
/efi/boot/recovery####.efi) then I would agree with only
signalling ReadyToBoot for a formal Boot#### option. But that
isn't the case, so I think it is reasonable to want to have
ReadyToBoot also occur when a /efi/boot/boot####.efi bootloader
is executed from PlatformRecovery####., especially when we know
it can be crucial to ensuring that the end user can actually use the
graphical console.

Therefore, your change may also require specification change.
Yes, I mentioned that in the cover letter for this patch
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%
2
Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F61327&amp;data=02%7C01%
7C
a
warkentin%40vmware.com%7C5f90d077bc7949c1122f08d812dc48d3%7Cb391
3
8
ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280084611749324&amp;sdat
a
=
2%2B%2FcvMkrmZGTRRLDGSuMsKbiyDOGtwYwZ7qSqMyMicc%3D&amp;res
erved=0
), which also describes the issue we are trying to solve in
greater details. This is what I wrote:

-----------------------------------------------------------------
-
------

Note however that this may require a specs update, as the current
UEFI specs for EFI_BOOT_SERVICES.CreateEventEx() have:

> EFI_EVENT_GROUP_READY_TO_BOOT
> This event group is notified by the system when the
Boot Manager
> is about to load and execute a boot option.

and, once this patch has been applied, we may want to update this
section to mention that it applies to both Boot Manager and
Platform Recovery.
-----------------------------------------------------------------
-
------



Again, I don't have an issue with trying to use an alternate
approach to solve our problem (though I ultimately believe that,
if PlatformRecovery#### can launch a /efi/boot/boot####.efi
bootloader then we must update the specs and the code to have
ReadyToBoot also signalled then, because that's the logical thing
to do). But right now, I'm not seeing how to achieve that when
PlatformRecovery#### is the option that is used to launch the OS
installation the bootloader. So if you can provide mode details
on how exactly you think creating an alternate PlatformRecovery
option would help, I would appreciate it.

Regards,

/Pete


Regards,
Sunny Wang

-----Original Message-----
From: mailto:devel@edk2.groups.io
[mailto:devel@edk2.groups.io]
On Behalf Of Pete Batard
Sent: Tuesday, June 16, 2020 5:56 PM
To: mailto:devel@edk2.groups.io
Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com;
mailto:ard.biesheuvel@arm.com; mailto:leif@nuviainc.com
Subject: [edk2-devel] [edk2][PATCH 1/1]
MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on
platform
recovery

Currently, the ReadyToBoot event is only signaled when a formal
Boot Manager option is executed (in BmBoot.c ->
EfiBootManagerBoot ()).

However, with the introduction of Platform Recovery in UEFI 2.5,
which may lead to the execution of a boot loader that has
similar requirements to a regular one, yet is not launched as a
Boot Manager option, it also becomes necessary to signal
ReadyToBoot when a Platform Recovery boot loader runs.

Especially, this can be critical to ensuring that the graphical
console is actually usable during platform recovery, as some
platforms do rely on the ConsolePrefDxe driver, which only
performs console initialization after ReadyToBoot is triggered.

This patch fixes that behaviour by calling
EfiSignalEventReadyToBoot () in
EfiBootManagerProcessLoadOption
(), which is the function that sets up the platform recovery
boot process.

Signed-off-by: Pete Batard <mailto:pete@akeo.ie>
---
MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
| 9
+++++++++
1 file changed, 9 insertions(+)

diff --git
a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
index 89372b3b97b8..117f1f5b124c 100644
---
a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
+++
b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
@@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
return EFI_SUCCESS;
}

+ //
+ // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are
+about
to load and execute the boot option.
+ //
+ EfiSignalEventReadyToBoot ();
+ //
+ // Report Status Code to indicate ReadyToBoot was signalled
+// REPORT_STATUS_CODE (EFI_PROGRESS_CODE,
(EFI_SOFTWARE_DXE_BS_DRIVER |
+ EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
+
//
// Load and start the load option.
//
--
2.21.0.windows.1




IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the
intended recipient, please notify the sender immediately and do
not disclose the contents to any other person, use it for any
purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the
intended recipient, please notify the sender immediately and do
not disclose the contents to any other person, use it for any
purpose, or store or copy the information in any medium. Thank you.





IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: [GSoC proposal] Secure Image Loader

Andrew Fish
 

On Apr 13, 2021, at 11:04 AM, Desimone, Nathaniel L <nathaniel.l.desimone@intel.com> wrote:

Hi Marvin,

What Mike and I were thinking is having a FixedAtBuildPcd which chooses whether to use the new loader or the old loader at compile time. We were also thinking the same thing of shimming the old loader into the new interface. I completely agree with you that it is unlikely the new loader is "broken"... it is more likely that broken images exist out in the world somewhere and that we won't know that they are broken until someone tries to build their system's firmware with the new loader included. Once the broken images are found, it can take some time to get them fixed. A lot of times they come from outside vendors and the source code for those binaries is not readily available. Because of that, there may be a need to fallback to the old loader in the interim period while a fixed binary is being acquired.

This could become very difficult for OpROMs on PCIe add-in cards since they are stored on a separate device rom and most of the time are completely non-upgradable. We should think about how we can handle the case where we find an old graphics or network card built in 2014 that has a UEFI OpROM that contains a broken PE/COFF header which cannot be fixed.
Don’t forget Thunderbolt dongles, docks, and devices.

Thanks,

Andrew Fish

Thanks,
Nate

-----Original Message-----
From: Marvin Häuser <mhaeuser@posteo.de>
Sent: Tuesday, April 13, 2021 12:32 AM
To: Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io; Laszlo Ersek <lersek@redhat.com>; Andrew Fish <afish@apple.com>
Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader

Hey Mike,
Hey Nate,

I'm not 100 % sure I get what you mean. The interfaces of the two solutions are not compatible (however I could write wrapper code to shim the old into the new I suppose?), so on-the-fly switching between the two would be inconvenient. I do plan to keep the old library around and guard it with the deprecated interfaces macro, for out-of-tree code, however. The new library interfaces will probably be something like PeCoffLib2, PeCoffDebugLib2, maybe more.

I'm also not sure what on-the-fly switching would accomplish, as testing with the old loader allows broken images to be loaded, i.e. just because something "works" with the old code but not the new, it doesn't mean that the new code is broken.

Instead of debugging with two libraries, I rather want to make sure this thing is rock-solid before even sending out the patches. For this I would like to build a small EFI file database to parse and load from userland, checking for image acceptance and memory safety. This would include several versions of Windows and macOS bootloaders, Option ROMs (NVIDIA and AMD GOP, iPXE), tools (memtest), and so on. If you have anything you want to have especially tested, please let me know.

Best regards,
Marvin

13.04.2021 02:56:22 Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>:

Hi Marvin,

I agree with Mike K that having both the new strict loader and the old loader co-exist for some time may be the best option. That will give the ecosystem time to test the new loader and correct any issues that arise from its introduction.

Best Regards,
Nate

-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: Monday, April 12, 2021 5:20 PM
To: Marvin Häuser <mhaeuser@posteo.de>; devel@edk2.groups.io;
Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; Laszlo Ersek
<lersek@redhat.com>; Andrew Fish <afish@apple.com>; Kinney, Michael D
<michael.d.kinney@intel.com>
Subject: RE: [edk2-devel] [GSoC proposal] Secure Image Loader

Hi Marvin,

If it has not already been considered, one option is to submit a new instance of the PE/COFF Library, so both the existing one and the new one are available to the ecosystem.

This allows you to be successful in submitting code outlined in your proposal and gives the ecosystem time to evaluate and decide when/if to switch from the old to the new.

Mike

-----Original Message-----
From: Marvin Häuser <mhaeuser@posteo.de>
Sent: Monday, April 12, 2021 10:22 AM
To: devel@edk2.groups.io; Desimone, Nathaniel L
<nathaniel.l.desimone@intel.com>; Laszlo Ersek <lersek@redhat.com>;
Andrew Fish <afish@apple.com>; Kinney, Michael D
<michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader

Good day Nate,

As you seem to be mostly in charge of the GSoC side of things, I
direct this at you, but of course everyone is welcome to comment.

I think I finished my first round of investigations just in time for
the deadline. You can find a list of BZs attached[1]. Please note
that
1) some are declared security issues and may not be publicly
accessible, and 2) that this list is far from complete. I only added
items that are
a) not implicitly fixed by "simply" deploying the new Image Loader
(*some* important prerequisites are listed), and b) I am confident
are actual issues (or things to consider) I believe to know how to approach.

I have taken notes about more things, e.g. the existence of the
security architectural protocols, which I could not find a rationale
for. I can prepare something for this matter, but it really needs an
active discussion with some of the core people. I'm not sure delayed
e-mail discussion is going to be enough, but there is an official IRC
I suppose. :) I hope we can work something out for this.

I also hope this makes it clearer why I don't believe that we need to
"fill" 10 weeks, but rather the opposite. This is not a matter of
replacing a library instance, but the whole surrounding ecosystem
needs to follow for the changes to make sense. And as I tried to make
clear in my discussion with Michael Brown, I am not keen on
preserving backwards-compatibility with platform code (i.e. PEI, DXE,
things we consider "internal"), as most of it should be controlled by
EDK II already. This of course does *not* include user code (OROMs,
bootloaders, ...), for which I want to provide the *option* to lock
some of them out for security, but with sane defaults that will
ensure good compatibility.

I'd like to thank Michael Brown for his cooperation and support,
because we recently landed changes in iPXE to allow for the strictest
image format and permission constraints currently possible[2].

I will have to rework the submitted proposal to reflect the new
knowledge. To be honest, seeing how the BZs kept rolling in, I am not
convinced an amazing amount of mainlining can be accomplished during
the
10 weeks. It may have to suffice to have a publicly accessible
prototype (e.g. OVMF) and a subset of the planned patches on the list.
I hope you can manage to provide some feedback before the deadline passes tomorrow.

Thank you in advance!

Best regards,
Marvin

[1]
https://bugzilla.tianocore.org/show_bug.cgi?id=3315
https://bugzilla.tianocore.org/show_bug.cgi?id=3316
https://bugzilla.tianocore.org/show_bug.cgi?id=3317
https://bugzilla.tianocore.org/show_bug.cgi?id=3318
https://bugzilla.tianocore.org/show_bug.cgi?id=3319
https://bugzilla.tianocore.org/show_bug.cgi?id=3320
https://bugzilla.tianocore.org/show_bug.cgi?id=3321
https://bugzilla.tianocore.org/show_bug.cgi?id=3322
https://bugzilla.tianocore.org/show_bug.cgi?id=3323
https://bugzilla.tianocore.org/show_bug.cgi?id=3324
https://bugzilla.tianocore.org/show_bug.cgi?id=3326
https://bugzilla.tianocore.org/show_bug.cgi?id=3327
https://bugzilla.tianocore.org/show_bug.cgi?id=3328
https://bugzilla.tianocore.org/show_bug.cgi?id=3329
https://bugzilla.tianocore.org/show_bug.cgi?id=3330
https://bugzilla.tianocore.org/show_bug.cgi?id=3331

[2] https://github.com/ipxe/ipxe/pull/313

On 06.04.21 11:41, Nate DeSimone wrote:
Hi Marvin,

Great to meet you and welcome back! Glad you hear you are
interested! Completing a formal verification of a PE/COFF
loader is certainly impressive. Was this done with some sort of
automated theorem proving? It would seem a rather arduous task doing
an inductive proof for an algorithm like that by hand! I completely agree with you that getting a formally verified PE/COFF loader into mainline is undoubtably valuable and would pay security dividends for years to come.

Admittedly, this is an area of computer science that I don't have a
great deal of experience with. The furthest I have
gone on this topic is writing out proofs for simple algorithms on
exams in my Algorithms class in college. Regardless you have a much
better idea of what the current status is of the work that you and
Vitaly have done. I guess my only question is do you think there is
sufficient work remaining to fill the 10 week GSoC development window? Certainly we can use some of that time to perform the code reviews you mention and write up formal ECRs for the UEFI spec changes that you believe are needed.

Thank you for sending the application and alerting us to the great
work you and Vitaly have done! I'll read your paper
more closely and come back with any questions I still have.

With Best Regards,
Nate

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
Marvin Häuser
Sent: Sunday, April 4, 2021 4:02 PM
To: devel@edk2.groups.io; Laszlo Ersek <lersek@redhat.com>; Andrew
Fish <afish@apple.com>; Kinney, Michael D
<michael.d.kinney@intel.com>
Subject: [edk2-devel] [GSoC proposal] Secure Image Loader

Good day everyone,

I'll keep the introduction brief because I've been around for a
while now. :) I'm Marvin Häuser, a third-year Computer Science
student from TU Kaiserslautern, Germany. Late last year, my
colleague Vitaly from ISP RAS and me introduced a formally verified
Image Loader for UEFI usage at ISP RAS Open[1] due to various
defects we outlined in the corresponding paper. Thank you once again Laszlo for your *incredible* review work on the publication part.

I now want to make an effort to mainline it, preferably as part of
the current Google Summer of Code event. To be clear, my internship
at ISP RAS has concluded, and while Vitaly will be available for
design discussion, he has other priorities at the moment and the
practical part will be on me. I have previously submitted a proposal via the GSoC website for your review.

There are many things to consider:
1. The Image Loader is a core component, and there needs to be a
significant level of quality and security assurance.
2. Being consumed by many packages, the proposed patch set will
take a lot of time to review and integrate.
3. During my initial exploration, I discovered defective PPIs and protocols (e.g.
returning data with no corresponding size) originating from the
UEFI PI and UEFI specifications. Changes need to be discussed,
settled on, and submitted to the UEFI Forum.
4. Some UEFI APIs like the Security Architecture protocols are
inconveniently abstract, see 5.
5. Some of the current code does not use the existing context, or
accesses it outside of the exposed APIs. The control flow of the
dispatchers may need to be adapted to make the context available to appropriate APIs.

But obviously there are not only unpleasant considerations:
A. The Image Loader is mostly formally verified, and only very few
changes will be required from the last proven state. This gives a
lot of trust in its correctness and safety.
B. All outlined defects that are of critical nature have been fixed successfully.
C. The Image Loader has been tested with real-world code loading
real-world OSes on thousands of machines in the past few months,
including rejecting malformed images (configurable by PCD).
D. The new APIs will centralise everything PE, reducing code
duplication and potentially unsafe operations.
E. Centralising and reduced parse duplication may improve overall
boot performance.
F. The code has been coverage-tested to not contain dead code.
G. The code has been fuzz-tested including sanitizers to not invoke
undefined behaviour.
H. I already managed to identify a malformed image in OVMF with its
help (incorrectly reported section alignment of an Intel IPXE
driver). A fix will be submitted shortly.
I. I plan to support PE section permissions, allowing for read-only
data segments when enabled.

There are likely more points for both lists, but I hope this gives
a decent starting point for discussion. What are your thoughts on
the matter? I strongly encourage everyone to read the section
regarding defects of our publication[2] to better understand the
motivation. The vague points above can of course be elaborated in due time, as you see fit.

Thank you for your time!

Best regards,
Marvin


[1] https://github.com/mhaeuser/ISPRASOpen-SecurePE
[2] https://arxiv.org/pdf/2012.05471.pdf







Re: [GSoC proposal] Secure Image Loader

Michael D Kinney
 

Hi Nate,

Yes. A FixedAtBuild PCD or a FeatureFlag PCD is one way. However, that approach does add some risk to the existing PE/COFF loader functionality.

My suggestion was to add a new library instance as a peer to the existing library instance.

I believe Marvin is also suggesting some changes to the PE/COFF Library Class APIs, which would be more challenging to support old and news.

I agree with Andrew that the proposed changes to the PE/COFF Library Class need to be reviewed to see if there is a path to support old and new.

Mike

-----Original Message-----
From: Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>
Sent: Tuesday, April 13, 2021 11:05 AM
To: Marvin Häuser <mhaeuser@posteo.de>
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io; Laszlo Ersek <lersek@redhat.com>; Andrew Fish
<afish@apple.com>
Subject: RE: [edk2-devel] [GSoC proposal] Secure Image Loader

Hi Marvin,

What Mike and I were thinking is having a FixedAtBuildPcd which chooses whether to use the new loader or the old loader at
compile time. We were also thinking the same thing of shimming the old loader into the new interface. I completely agree
with you that it is unlikely the new loader is "broken"... it is more likely that broken images exist out in the world
somewhere and that we won't know that they are broken until someone tries to build their system's firmware with the new
loader included. Once the broken images are found, it can take some time to get them fixed. A lot of times they come from
outside vendors and the source code for those binaries is not readily available. Because of that, there may be a need to
fallback to the old loader in the interim period while a fixed binary is being acquired.

This could become very difficult for OpROMs on PCIe add-in cards since they are stored on a separate device rom and most
of the time are completely non-upgradable. We should think about how we can handle the case where we find an old graphics
or network card built in 2014 that has a UEFI OpROM that contains a broken PE/COFF header which cannot be fixed.

Thanks,
Nate

-----Original Message-----
From: Marvin Häuser <mhaeuser@posteo.de>
Sent: Tuesday, April 13, 2021 12:32 AM
To: Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io; Laszlo Ersek <lersek@redhat.com>; Andrew Fish
<afish@apple.com>
Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader

Hey Mike,
Hey Nate,

I'm not 100 % sure I get what you mean. The interfaces of the two solutions are not compatible (however I could write
wrapper code to shim the old into the new I suppose?), so on-the-fly switching between the two would be inconvenient. I do
plan to keep the old library around and guard it with the deprecated interfaces macro, for out-of-tree code, however. The
new library interfaces will probably be something like PeCoffLib2, PeCoffDebugLib2, maybe more.

I'm also not sure what on-the-fly switching would accomplish, as testing with the old loader allows broken images to be
loaded, i.e. just because something "works" with the old code but not the new, it doesn't mean that the new code is
broken.

Instead of debugging with two libraries, I rather want to make sure this thing is rock-solid before even sending out the
patches. For this I would like to build a small EFI file database to parse and load from userland, checking for image
acceptance and memory safety. This would include several versions of Windows and macOS bootloaders, Option ROMs (NVIDIA
and AMD GOP, iPXE), tools (memtest), and so on. If you have anything you want to have especially tested, please let me
know.

Best regards,
Marvin

13.04.2021 02:56:22 Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>:

Hi Marvin,

I agree with Mike K that having both the new strict loader and the old loader co-exist for some time may be the best
option. That will give the ecosystem time to test the new loader and correct any issues that arise from its introduction.

Best Regards,
Nate

-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: Monday, April 12, 2021 5:20 PM
To: Marvin Häuser <mhaeuser@posteo.de>; devel@edk2.groups.io;
Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; Laszlo Ersek
<lersek@redhat.com>; Andrew Fish <afish@apple.com>; Kinney, Michael D
<michael.d.kinney@intel.com>
Subject: RE: [edk2-devel] [GSoC proposal] Secure Image Loader

Hi Marvin,

If it has not already been considered, one option is to submit a new instance of the PE/COFF Library, so both the
existing one and the new one are available to the ecosystem.

This allows you to be successful in submitting code outlined in your proposal and gives the ecosystem time to evaluate
and decide when/if to switch from the old to the new.

Mike

-----Original Message-----
From: Marvin Häuser <mhaeuser@posteo.de>
Sent: Monday, April 12, 2021 10:22 AM
To: devel@edk2.groups.io; Desimone, Nathaniel L
<nathaniel.l.desimone@intel.com>; Laszlo Ersek <lersek@redhat.com>;
Andrew Fish <afish@apple.com>; Kinney, Michael D
<michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader

Good day Nate,

As you seem to be mostly in charge of the GSoC side of things, I
direct this at you, but of course everyone is welcome to comment.

I think I finished my first round of investigations just in time for
the deadline. You can find a list of BZs attached[1]. Please note
that
1) some are declared security issues and may not be publicly
accessible, and 2) that this list is far from complete. I only added
items that are
a) not implicitly fixed by "simply" deploying the new Image Loader
(*some* important prerequisites are listed), and b) I am confident
are actual issues (or things to consider) I believe to know how to approach.

I have taken notes about more things, e.g. the existence of the
security architectural protocols, which I could not find a rationale
for. I can prepare something for this matter, but it really needs an
active discussion with some of the core people. I'm not sure delayed
e-mail discussion is going to be enough, but there is an official IRC
I suppose. :) I hope we can work something out for this.

I also hope this makes it clearer why I don't believe that we need to
"fill" 10 weeks, but rather the opposite. This is not a matter of
replacing a library instance, but the whole surrounding ecosystem
needs to follow for the changes to make sense. And as I tried to make
clear in my discussion with Michael Brown, I am not keen on
preserving backwards-compatibility with platform code (i.e. PEI, DXE,
things we consider "internal"), as most of it should be controlled by
EDK II already. This of course does *not* include user code (OROMs,
bootloaders, ...), for which I want to provide the *option* to lock
some of them out for security, but with sane defaults that will
ensure good compatibility.

I'd like to thank Michael Brown for his cooperation and support,
because we recently landed changes in iPXE to allow for the strictest
image format and permission constraints currently possible[2].

I will have to rework the submitted proposal to reflect the new
knowledge. To be honest, seeing how the BZs kept rolling in, I am not
convinced an amazing amount of mainlining can be accomplished during
the
10 weeks. It may have to suffice to have a publicly accessible
prototype (e.g. OVMF) and a subset of the planned patches on the list.
I hope you can manage to provide some feedback before the deadline passes tomorrow.

Thank you in advance!

Best regards,
Marvin

[1]
https://bugzilla.tianocore.org/show_bug.cgi?id=3315
https://bugzilla.tianocore.org/show_bug.cgi?id=3316
https://bugzilla.tianocore.org/show_bug.cgi?id=3317
https://bugzilla.tianocore.org/show_bug.cgi?id=3318
https://bugzilla.tianocore.org/show_bug.cgi?id=3319
https://bugzilla.tianocore.org/show_bug.cgi?id=3320
https://bugzilla.tianocore.org/show_bug.cgi?id=3321
https://bugzilla.tianocore.org/show_bug.cgi?id=3322
https://bugzilla.tianocore.org/show_bug.cgi?id=3323
https://bugzilla.tianocore.org/show_bug.cgi?id=3324
https://bugzilla.tianocore.org/show_bug.cgi?id=3326
https://bugzilla.tianocore.org/show_bug.cgi?id=3327
https://bugzilla.tianocore.org/show_bug.cgi?id=3328
https://bugzilla.tianocore.org/show_bug.cgi?id=3329
https://bugzilla.tianocore.org/show_bug.cgi?id=3330
https://bugzilla.tianocore.org/show_bug.cgi?id=3331

[2] https://github.com/ipxe/ipxe/pull/313

On 06.04.21 11:41, Nate DeSimone wrote:
Hi Marvin,

Great to meet you and welcome back! Glad you hear you are
interested! Completing a formal verification of a PE/COFF
loader is certainly impressive. Was this done with some sort of
automated theorem proving? It would seem a rather arduous task doing
an inductive proof for an algorithm like that by hand! I completely agree with you that getting a formally verified
PE/COFF loader into mainline is undoubtably valuable and would pay security dividends for years to come.

Admittedly, this is an area of computer science that I don't have a
great deal of experience with. The furthest I have
gone on this topic is writing out proofs for simple algorithms on
exams in my Algorithms class in college. Regardless you have a much
better idea of what the current status is of the work that you and
Vitaly have done. I guess my only question is do you think there is
sufficient work remaining to fill the 10 week GSoC development window? Certainly we can use some of that time to
perform the code reviews you mention and write up formal ECRs for the UEFI spec changes that you believe are needed.

Thank you for sending the application and alerting us to the great
work you and Vitaly have done! I'll read your paper
more closely and come back with any questions I still have.

With Best Regards,
Nate

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
Marvin Häuser
Sent: Sunday, April 4, 2021 4:02 PM
To: devel@edk2.groups.io; Laszlo Ersek <lersek@redhat.com>; Andrew
Fish <afish@apple.com>; Kinney, Michael D
<michael.d.kinney@intel.com>
Subject: [edk2-devel] [GSoC proposal] Secure Image Loader

Good day everyone,

I'll keep the introduction brief because I've been around for a
while now. :) I'm Marvin Häuser, a third-year Computer Science
student from TU Kaiserslautern, Germany. Late last year, my
colleague Vitaly from ISP RAS and me introduced a formally verified
Image Loader for UEFI usage at ISP RAS Open[1] due to various
defects we outlined in the corresponding paper. Thank you once again Laszlo for your *incredible* review work on the
publication part.

I now want to make an effort to mainline it, preferably as part of
the current Google Summer of Code event. To be clear, my internship
at ISP RAS has concluded, and while Vitaly will be available for
design discussion, he has other priorities at the moment and the
practical part will be on me. I have previously submitted a proposal via the GSoC website for your review.

There are many things to consider:
1. The Image Loader is a core component, and there needs to be a
significant level of quality and security assurance.
2. Being consumed by many packages, the proposed patch set will
take a lot of time to review and integrate.
3. During my initial exploration, I discovered defective PPIs and protocols (e.g.
returning data with no corresponding size) originating from the
UEFI PI and UEFI specifications. Changes need to be discussed,
settled on, and submitted to the UEFI Forum.
4. Some UEFI APIs like the Security Architecture protocols are
inconveniently abstract, see 5.
5. Some of the current code does not use the existing context, or
accesses it outside of the exposed APIs. The control flow of the
dispatchers may need to be adapted to make the context available to appropriate APIs.

But obviously there are not only unpleasant considerations:
A. The Image Loader is mostly formally verified, and only very few
changes will be required from the last proven state. This gives a
lot of trust in its correctness and safety.
B. All outlined defects that are of critical nature have been fixed successfully.
C. The Image Loader has been tested with real-world code loading
real-world OSes on thousands of machines in the past few months,
including rejecting malformed images (configurable by PCD).
D. The new APIs will centralise everything PE, reducing code
duplication and potentially unsafe operations.
E. Centralising and reduced parse duplication may improve overall
boot performance.
F. The code has been coverage-tested to not contain dead code.
G. The code has been fuzz-tested including sanitizers to not invoke
undefined behaviour.
H. I already managed to identify a malformed image in OVMF with its
help (incorrectly reported section alignment of an Intel IPXE
driver). A fix will be submitted shortly.
I. I plan to support PE section permissions, allowing for read-only
data segments when enabled.

There are likely more points for both lists, but I hope this gives
a decent starting point for discussion. What are your thoughts on
the matter? I strongly encourage everyone to read the section
regarding defects of our publication[2] to better understand the
motivation. The vague points above can of course be elaborated in due time, as you see fit.

Thank you for your time!

Best regards,
Marvin


[1] https://github.com/mhaeuser/ISPRASOpen-SecurePE
[2] https://arxiv.org/pdf/2012.05471.pdf







Re: [GSoC proposal] Secure Image Loader

Nate DeSimone
 

Hi Marvin,

What Mike and I were thinking is having a FixedAtBuildPcd which chooses whether to use the new loader or the old loader at compile time. We were also thinking the same thing of shimming the old loader into the new interface. I completely agree with you that it is unlikely the new loader is "broken"... it is more likely that broken images exist out in the world somewhere and that we won't know that they are broken until someone tries to build their system's firmware with the new loader included. Once the broken images are found, it can take some time to get them fixed. A lot of times they come from outside vendors and the source code for those binaries is not readily available. Because of that, there may be a need to fallback to the old loader in the interim period while a fixed binary is being acquired.

This could become very difficult for OpROMs on PCIe add-in cards since they are stored on a separate device rom and most of the time are completely non-upgradable. We should think about how we can handle the case where we find an old graphics or network card built in 2014 that has a UEFI OpROM that contains a broken PE/COFF header which cannot be fixed.

Thanks,
Nate

-----Original Message-----
From: Marvin Häuser <mhaeuser@posteo.de>
Sent: Tuesday, April 13, 2021 12:32 AM
To: Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io; Laszlo Ersek <lersek@redhat.com>; Andrew Fish <afish@apple.com>
Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader

Hey Mike,
Hey Nate,

I'm not 100 % sure I get what you mean. The interfaces of the two solutions are not compatible (however I could write wrapper code to shim the old into the new I suppose?), so on-the-fly switching between the two would be inconvenient. I do plan to keep the old library around and guard it with the deprecated interfaces macro, for out-of-tree code, however. The new library interfaces will probably be something like PeCoffLib2, PeCoffDebugLib2, maybe more.

I'm also not sure what on-the-fly switching would accomplish, as testing with the old loader allows broken images to be loaded, i.e. just because something "works" with the old code but not the new, it doesn't mean that the new code is broken.

Instead of debugging with two libraries, I rather want to make sure this thing is rock-solid before even sending out the patches. For this I would like to build a small EFI file database to parse and load from userland, checking for image acceptance and memory safety. This would include several versions of Windows and macOS bootloaders, Option ROMs (NVIDIA and AMD GOP, iPXE), tools (memtest), and so on. If you have anything you want to have especially tested, please let me know.

Best regards,
Marvin

13.04.2021 02:56:22 Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>:

Hi Marvin,

I agree with Mike K that having both the new strict loader and the old loader co-exist for some time may be the best option. That will give the ecosystem time to test the new loader and correct any issues that arise from its introduction.

Best Regards,
Nate

-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: Monday, April 12, 2021 5:20 PM
To: Marvin Häuser <mhaeuser@posteo.de>; devel@edk2.groups.io;
Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; Laszlo Ersek
<lersek@redhat.com>; Andrew Fish <afish@apple.com>; Kinney, Michael D
<michael.d.kinney@intel.com>
Subject: RE: [edk2-devel] [GSoC proposal] Secure Image Loader

Hi Marvin,

If it has not already been considered, one option is to submit a new instance of the PE/COFF Library, so both the existing one and the new one are available to the ecosystem.

This allows you to be successful in submitting code outlined in your proposal and gives the ecosystem time to evaluate and decide when/if to switch from the old to the new.

Mike

-----Original Message-----
From: Marvin Häuser <mhaeuser@posteo.de>
Sent: Monday, April 12, 2021 10:22 AM
To: devel@edk2.groups.io; Desimone, Nathaniel L
<nathaniel.l.desimone@intel.com>; Laszlo Ersek <lersek@redhat.com>;
Andrew Fish <afish@apple.com>; Kinney, Michael D
<michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader

Good day Nate,

As you seem to be mostly in charge of the GSoC side of things, I
direct this at you, but of course everyone is welcome to comment.

I think I finished my first round of investigations just in time for
the deadline. You can find a list of BZs attached[1]. Please note
that
1) some are declared security issues and may not be publicly
accessible, and 2) that this list is far from complete. I only added
items that are
a) not implicitly fixed by "simply" deploying the new Image Loader
(*some* important prerequisites are listed), and b) I am confident
are actual issues (or things to consider) I believe to know how to approach.

I have taken notes about more things, e.g. the existence of the
security architectural protocols, which I could not find a rationale
for. I can prepare something for this matter, but it really needs an
active discussion with some of the core people. I'm not sure delayed
e-mail discussion is going to be enough, but there is an official IRC
I suppose. :) I hope we can work something out for this.

I also hope this makes it clearer why I don't believe that we need to
"fill" 10 weeks, but rather the opposite. This is not a matter of
replacing a library instance, but the whole surrounding ecosystem
needs to follow for the changes to make sense. And as I tried to make
clear in my discussion with Michael Brown, I am not keen on
preserving backwards-compatibility with platform code (i.e. PEI, DXE,
things we consider "internal"), as most of it should be controlled by
EDK II already. This of course does *not* include user code (OROMs,
bootloaders, ...), for which I want to provide the *option* to lock
some of them out for security, but with sane defaults that will
ensure good compatibility.

I'd like to thank Michael Brown for his cooperation and support,
because we recently landed changes in iPXE to allow for the strictest
image format and permission constraints currently possible[2].

I will have to rework the submitted proposal to reflect the new
knowledge. To be honest, seeing how the BZs kept rolling in, I am not
convinced an amazing amount of mainlining can be accomplished during
the
10 weeks. It may have to suffice to have a publicly accessible
prototype (e.g. OVMF) and a subset of the planned patches on the list.
I hope you can manage to provide some feedback before the deadline passes tomorrow.

Thank you in advance!

Best regards,
Marvin

[1]
https://bugzilla.tianocore.org/show_bug.cgi?id=3315
https://bugzilla.tianocore.org/show_bug.cgi?id=3316
https://bugzilla.tianocore.org/show_bug.cgi?id=3317
https://bugzilla.tianocore.org/show_bug.cgi?id=3318
https://bugzilla.tianocore.org/show_bug.cgi?id=3319
https://bugzilla.tianocore.org/show_bug.cgi?id=3320
https://bugzilla.tianocore.org/show_bug.cgi?id=3321
https://bugzilla.tianocore.org/show_bug.cgi?id=3322
https://bugzilla.tianocore.org/show_bug.cgi?id=3323
https://bugzilla.tianocore.org/show_bug.cgi?id=3324
https://bugzilla.tianocore.org/show_bug.cgi?id=3326
https://bugzilla.tianocore.org/show_bug.cgi?id=3327
https://bugzilla.tianocore.org/show_bug.cgi?id=3328
https://bugzilla.tianocore.org/show_bug.cgi?id=3329
https://bugzilla.tianocore.org/show_bug.cgi?id=3330
https://bugzilla.tianocore.org/show_bug.cgi?id=3331

[2] https://github.com/ipxe/ipxe/pull/313

On 06.04.21 11:41, Nate DeSimone wrote:
Hi Marvin,

Great to meet you and welcome back! Glad you hear you are
interested! Completing a formal verification of a PE/COFF
loader is certainly impressive. Was this done with some sort of
automated theorem proving? It would seem a rather arduous task doing
an inductive proof for an algorithm like that by hand! I completely agree with you that getting a formally verified PE/COFF loader into mainline is undoubtably valuable and would pay security dividends for years to come.

Admittedly, this is an area of computer science that I don't have a
great deal of experience with. The furthest I have
gone on this topic is writing out proofs for simple algorithms on
exams in my Algorithms class in college. Regardless you have a much
better idea of what the current status is of the work that you and
Vitaly have done. I guess my only question is do you think there is
sufficient work remaining to fill the 10 week GSoC development window? Certainly we can use some of that time to perform the code reviews you mention and write up formal ECRs for the UEFI spec changes that you believe are needed.

Thank you for sending the application and alerting us to the great
work you and Vitaly have done! I'll read your paper
more closely and come back with any questions I still have.

With Best Regards,
Nate

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
Marvin Häuser
Sent: Sunday, April 4, 2021 4:02 PM
To: devel@edk2.groups.io; Laszlo Ersek <lersek@redhat.com>; Andrew
Fish <afish@apple.com>; Kinney, Michael D
<michael.d.kinney@intel.com>
Subject: [edk2-devel] [GSoC proposal] Secure Image Loader

Good day everyone,

I'll keep the introduction brief because I've been around for a
while now. :) I'm Marvin Häuser, a third-year Computer Science
student from TU Kaiserslautern, Germany. Late last year, my
colleague Vitaly from ISP RAS and me introduced a formally verified
Image Loader for UEFI usage at ISP RAS Open[1] due to various
defects we outlined in the corresponding paper. Thank you once again Laszlo for your *incredible* review work on the publication part.

I now want to make an effort to mainline it, preferably as part of
the current Google Summer of Code event. To be clear, my internship
at ISP RAS has concluded, and while Vitaly will be available for
design discussion, he has other priorities at the moment and the
practical part will be on me. I have previously submitted a proposal via the GSoC website for your review.

There are many things to consider:
1. The Image Loader is a core component, and there needs to be a
significant level of quality and security assurance.
2. Being consumed by many packages, the proposed patch set will
take a lot of time to review and integrate.
3. During my initial exploration, I discovered defective PPIs and protocols (e.g.
returning data with no corresponding size) originating from the
UEFI PI and UEFI specifications. Changes need to be discussed,
settled on, and submitted to the UEFI Forum.
4. Some UEFI APIs like the Security Architecture protocols are
inconveniently abstract, see 5.
5. Some of the current code does not use the existing context, or
accesses it outside of the exposed APIs. The control flow of the
dispatchers may need to be adapted to make the context available to appropriate APIs.

But obviously there are not only unpleasant considerations:
A. The Image Loader is mostly formally verified, and only very few
changes will be required from the last proven state. This gives a
lot of trust in its correctness and safety.
B. All outlined defects that are of critical nature have been fixed successfully.
C. The Image Loader has been tested with real-world code loading
real-world OSes on thousands of machines in the past few months,
including rejecting malformed images (configurable by PCD).
D. The new APIs will centralise everything PE, reducing code
duplication and potentially unsafe operations.
E. Centralising and reduced parse duplication may improve overall
boot performance.
F. The code has been coverage-tested to not contain dead code.
G. The code has been fuzz-tested including sanitizers to not invoke
undefined behaviour.
H. I already managed to identify a malformed image in OVMF with its
help (incorrectly reported section alignment of an Intel IPXE
driver). A fix will be submitted shortly.
I. I plan to support PE section permissions, allowing for read-only
data segments when enabled.

There are likely more points for both lists, but I hope this gives
a decent starting point for discussion. What are your thoughts on
the matter? I strongly encourage everyone to read the section
regarding defects of our publication[2] to better understand the
motivation. The vague points above can of course be elaborated in due time, as you see fit.

Thank you for your time!

Best regards,
Marvin


[1] https://github.com/mhaeuser/ISPRASOpen-SecurePE
[2] https://arxiv.org/pdf/2012.05471.pdf







Re: [PATCH v3 01/10] Silicon/Phytium: Added PlatformLib to FT2000/4

Leif Lindholm
 

On Wed, Mar 17, 2021 at 15:26:38 +0800, Ling Jia wrote:
The PlatformLib supported the system library for FT2000/4 chip.
Platform/Phytium: Added the dsc and fdf files of DurianPkg.

v3:
DurianPkg.dsc:Added OrderedCollectionLib to upstream changes in
edk2, and some parameters omitted in V2 version.
Please summarise all changes between revisions in the cover letter
(0/5). The commit message should not include this information.

Signed-off-by: Ling Jia <jialing@phytium.com.cn>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
---
If there is anything you want to specifically highlight for an
individual patch, but does not belong in the commit message, you can
say it here - after the "---" line.

Typo comment below.

Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dec | 41 +++
Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dsc.inc | 345 ++++++++++++++++++++
Platform/Phytium/DurianPkg/DurianPkg.dsc | 298 +++++++++++++++++
Platform/Phytium/DurianPkg/DurianPkg.fdf | 210 ++++++++++++
Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.inf | 55 ++++
Silicon/Phytium/PhytiumCommonPkg/Include/SystemServiceInterface.h | 112 +++++++
Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.c | 137 ++++++++
Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLibMem.c | 156 +++++++++
Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/AArch64/PhytiumPlatformHelper.S | 76 +++++
Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.fdf.inc | 119 +++++++
10 files changed, 1549 insertions(+)

diff --git a/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dec b/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dec
new file mode 100644
index 0000000000..48f430c88d
--- /dev/null
+++ b/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dec
@@ -0,0 +1,41 @@
+## @file
+# This package provides common Phytium silicon modules.
+#
+# Copyright (C) 2020, Phytium Technology Co,Ltd. All rights reserved.
+#
+# SPDX-License-Identifier:BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+ DEC_SPECIFICATION = 0x0001001b
+ PACKAGE_NAME = PhytiumCommnonPkg
+ PACKAGE_GUID = b34af0b4-3e7c-11eb-a9d0-0738806d2dec
+ PACKAGE_VERSION = 0.1
+
+################################################################################
+#
+# Include Section - list of Include Paths that are provided by this package.
+# Comments are used for Keywords and Module Types.
+#
+# Supported Module Types:
+# BASE SEC PEI_CORE PEIM DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SMM_DRIVER DXE_SAL_DRIVER UEFI_DRIVER UEFI_APPLICATION
+#
+################################################################################
+[Includes]
+ Include # Root include for the package
+
+[Guids.common]
+ gPhytiumPlatformTokenSpaceGuid = { 0x8c3abed4, 0x1fc8, 0x46d3, { 0xb4, 0x17, 0xa3, 0x22, 0x38, 0x14, 0xde, 0x76 } }
+
+[PcdsFixedAtBuild.common]
+ gPhytiumPlatformTokenSpaceGuid.PcdSystemIoBase|0x0|UINT64|0x00000000
+ gPhytiumPlatformTokenSpaceGuid.PcdSystemIoSize|0x0|UINT64|0x00000001
+
+ #
+ # PCI configuration address space
+ #
+ gPhytiumPlatformTokenSpaceGuid.PcdPciConfigBase|0x0|UINT64|0x00000002
+ gPhytiumPlatformTokenSpaceGuid.PcdPciConfigSize|0x0|UINT64|0x00000003
+
+[Protocols]
diff --git a/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dsc.inc b/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dsc.inc
new file mode 100644
index 0000000000..121fe0e7c5
--- /dev/null
+++ b/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dsc.inc
@@ -0,0 +1,345 @@
+## @file
+# This package provides common open source Phytium silicon modules.
+#
+# Copyright (C) 2020, Phytium Technology Co, Ltd. All rights reserved.
+#
+# SPDX-License-Identifier:BSD-2-Clause-Patent
+#
+##
+
+
+[LibraryClasses.common]
+ #
+ # ARM Architectural Libraries
+ #
+ ArmDisassemblerLib|ArmPkg/Library/ArmDisassemblerLib/ArmDisassemblerLib.inf
+ ArmGicLib|ArmPkg/Drivers/ArmGic/ArmGicLib.inf
+ ArmGicArchLib|ArmPkg/Library/ArmGicArchLib/ArmGicArchLib.inf
+ ArmPlatformStackLib|ArmPlatformPkg/Library/ArmPlatformStackLib/ArmPlatformStackLib.inf
+ ArmSmcLib|ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
+ ArmGenericTimerCounterLib|ArmPkg/Library/ArmGenericTimerPhyCounterLib/ArmGenericTimerPhyCounterLib.inf
+ ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
+ ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
+
+ AcpiLib|EmbeddedPkg/Library/AcpiLib/AcpiLib.inf
+ AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
+
+ BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
+ BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
+ BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
+ BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
+ BmpSupportLib|MdeModulePkg/Library/BaseBmpSupportLib/BaseBmpSupportLib.inf
+
+ CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
+ CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
+ CpuExceptionHandlerLib|ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.inf
+ CacheMaintenanceLib|ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.inf
+ CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
+ !if $(TARGET) == RELEASE
+ DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
+ !else
+ DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+ !endif
+
+ DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
+ DxeServicesTableLib|MdePkg/Library/DxeServicesTableLib/DxeServicesTableLib.inf
+ DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
+ DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf
+ DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
+ DebugAgentTimerLib|EmbeddedPkg/Library/DebugAgentTimerLibNull/DebugAgentTimerLibNull.inf
+ DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
+
+ FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf
+ FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
+ FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
+
+ HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
+ HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
+ HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
+
+ IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
+ IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
+
+ OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
+
+ PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
+ PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+ PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
+ PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
+ PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull.inf
+ PlatformPeiLib|ArmPlatformPkg/PlatformPei/PlatformPeiLib.inf
+ PlatformSecureLib|SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf
+ PlatformBootManagerLib|ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+ PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLibNull.inf
+
+ RngLib|MdePkg/Library/BaseRngLibTimerLib/BaseRngLibTimerLib.inf
+ ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseReportStatusCodeLibNull.inf
+
+ SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
+ ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
+ SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
+ ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
+ SafeIntLib|MdePkg/Library/BaseSafeIntLib/BaseSafeIntLib.inf
+
+ TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
+ TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
+
+ UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
+ UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
+ UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.inf
+ UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf
+ UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf
+ UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
+ UefiApplicationEntryPoint|MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf
+ UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf
+ UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
+
+ VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
+ VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
+
+ #
+ # Scsi Requirements
+ #
+ UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
+
+ #
+ # USB Requirements
+ #
+ UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
+
+ #
+ # Networking Requirements
+ #
+ DpcLib|NetworkPkg/Library/DxeDpcLib/DxeDpcLib.inf
+ IpIoLib|NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib.inf
+ NetLib|NetworkPkg/Library/DxeNetLib/DxeNetLib.inf
+ UdpIoLib|NetworkPkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf
+ HttpLib|NetworkPkg/Library/DxeHttpLib/DxeHttpLib.inf
+
+[LibraryClasses.common.SEC]
+ ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf
+ DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
+ ExtractGuidedSectionLib|EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.inf
+ LzmaDecompressLib|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
+ MemoryAllocationLib|EmbeddedPkg/Library/PrePiMemoryAllocationLib/PrePiMemoryAllocationLib.inf
+ HobLib|EmbeddedPkg/Library/PrePiHobLib/PrePiHobLib.inf
+ PrePiLib|EmbeddedPkg/Library/PrePiLib/PrePiLib.inf
+ PrePiHobListPointerLib|ArmPlatformPkg/Library/PrePiHobListPointerLib/PrePiHobListPointerLib.inf
+ PerformanceLib|MdeModulePkg/Library/PeiPerformanceLib/PeiPerformanceLib.inf
+
+[LibraryClasses.common.SEC, LibraryClasses.common.PEIM]
+ MemoryInitPeiLib|ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.inf
+
+[LibraryClasses.common.DXE_CORE]
+ DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
+ DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
+ ExtractGuidedSectionLib|MdePkg/Library/DxeExtractGuidedSectionLib/DxeExtractGuidedSectionLib.inf
+ HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
+ MemoryAllocationLib|MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationLib.inf
+ PerformanceLib|MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.inf
+
+[LibraryClasses.common.DXE_DRIVER]
+ DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
+ MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
+ SecurityManagementLib|MdeModulePkg/Library/DxeSecurityManagementLib/DxeSecurityManagementLib.inf
+ PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
+ VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.inf
+
+[LibraryClasses.common.UEFI_APPLICATION]
+ DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
+ HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
+ MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
+
+ #
+ # UiApp dependencies
+ #
+ FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
+ PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
+
+[LibraryClasses.common.UEFI_DRIVER]
+ ExtractGuidedSectionLib|MdePkg/Library/DxeExtractGuidedSectionLib/DxeExtractGuidedSectionLib.inf
+ PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
+ DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
+ MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
+
+[LibraryClasses.common.DXE_RUNTIME_DRIVER]
+ !if $(SECURE_BOOT_ENABLE) == TRUE
+ BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
+ !endif
+
+ CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
+
+ !if $(TARGET) != RELEASE
+ DebugLib|MdePkg/Library/DxeRuntimeDebugLibSerialPort/DxeRuntimeDebugLibSerialPort.inf
+ !endif
+
+ HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
+ MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
+ ReportStatusCodeLib|MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/RuntimeDxeReportStatusCodeLib.inf
+ VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLibRuntimeDxe.inf
+
+[LibraryClasses.AARCH64.DXE_RUNTIME_DRIVER]
+ EfiResetSystemLib|ArmPkg/Library/ArmPsciResetSystemLib/ArmPsciResetSystemLib.inf
+
+[LibraryClasses.ARM, LibraryClasses.AARCH64]
+ NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
+
+ #
+ # Add support for GCC stack protector
+ #
+ NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
+
+[LibraryClasses.common.UEFI_DRIVER, LibraryClasses.common.UEFI_APPLICATION, LibraryClasses.common.DXE_RUNTIME_DRIVER, LibraryClasses.common.DXE_DRIVER]
+ PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
+
+[BuildOptions]
+ RVCT:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
+ GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
+
+[BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER]
+ GCC:*_*_AARCH64_DLINK_FLAGS = -z common-page-size=0x10000
+
+################################################################################
+#
+# Pcd Section - list of all EDK II PCD Entries defined by this Platform
+#
+################################################################################
+
+[PcdsFeatureFlag.common]
+ gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
+ gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy|FALSE
+ gEfiMdePkgTokenSpaceGuid.PcdComponentNameDisable|FALSE
+ gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnosticsDisable|TRUE
+ gEfiMdePkgTokenSpaceGuid.PcdComponentName2Disable|TRUE
+ gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnostics2Disable|TRUE
+
+ gEmbeddedTokenSpaceGuid.PcdPrePiProduceMemoryTypeInformationHob|TRUE
+
+ gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE
+
+ # Use the Vector Table location in CpuDxe. We will not copy the Vector Table at PcdCpuVectorBaseAddress
+ gArmTokenSpaceGuid.PcdRelocateVectorTable|FALSE
+
+ gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultLangDeprecate|TRUE
+ gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
+ gEfiMdeModulePkgTokenSpaceGuid.PcdPciBusHotplugDeviceSupport|FALSE
+
+[PcdsFixedAtBuild.common]
+ gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength|1000000
+ gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength|1000000
+ gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength|1000000
+ gEfiMdePkgTokenSpaceGuid.PcdSpinLockTimeout|10000000
+ gEfiMdePkgTokenSpaceGuid.PcdDebugClearMemoryValue|0xAF
+ gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask|0
+ gEfiMdePkgTokenSpaceGuid.PcdPostCodePropertyMask|0
+ gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|320
+ gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections|TRUE
+
+!if $(TARGET) == RELEASE
+ gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x21
+!else
+ gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2f
+!endif
+
+ # DEBUG_INIT 0x00000001 // Initialization
+ # DEBUG_WARN 0x00000002 // Warnings
+ # DEBUG_LOAD 0x00000004 // Load events
+ # DEBUG_FS 0x00000008 // EFI File system
+ # DEBUG_POOL 0x00000010 // Alloc & Free's
+ # DEBUG_PAGE 0x00000020 // Alloc & Free's
+ # DEBUG_INFO 0x00000040 // Verbose
+ # DEBUG_DISPATCH 0x00000080 // PEI/DXE Dispatchers
+ # DEBUG_VARIABLE 0x00000100 // Variable
+ # DEBUG_BM 0x00000400 // Boot Manager
+ # DEBUG_BLKIO 0x00001000 // BlkIo Driver
+ # DEBUG_NET 0x00004000 // SNI Driver
+ # DEBUG_UNDI 0x00010000 // UNDI Driver
+ # DEBUG_LOADFILE 0x00020000 // UNDI Driver
+ # DEBUG_EVENT 0x00080000 // Event messages
+ # DEBUG_GCD 0x00100000 // Global Coherency Database changes
+ # DEBUG_CACHE 0x00200000 // Memory range cachability changes
+ # DEBUG_ERROR 0x80000000 // Error
+ gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80000046
+
+ gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07
+
+ gEmbeddedTokenSpaceGuid.PcdTimerPeriod|200000
+
+ gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0
+ gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0
+ gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0
+ gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|80
+ gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|65
+ gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesCode|400
+ gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesData|20000
+ gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderCode|20
+ gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderData|0
+
+ gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
+
+ gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
+
+!if $(SECURE_BOOT_ENABLE) == TRUE
+ gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04
+ gEfiSecurityPkgTokenSpaceGuid.PcdFixedMediaImageVerificationPolicy|0x04
+ gEfiSecurityPkgTokenSpaceGuid.PcdRemovableMediaImageVerificationPolicy|0x04
+!endif
+
+!if $(SECURE_BOOT_ENABLE) == TRUE
+ gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x10000
+!else
+ gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x4000
+!endif
+
+ # Default platform supported RFC 4646 languages: English & French & Chinese Simplified.
+ # Default Value of PlatformLangCodes Variable.
+ gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultPlatformLangCodes|"en-US;zh-Hans"
+
+ # Default current RFC 4646 language: Chinese Simplified.
+ # Default Value of PlatformLang Variable.
+ gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultPlatformLang|"en-US"
+ gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|4
+
+ #
+ # ACPI Table Version
+ #
+ gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x20
+
+ gArmPlatformTokenSpaceGuid.PL011UartInterrupt|67
+ gEfiMdeModulePkgTokenSpaceGuid.PcdSrIovSupport|FALSE
+
+[PcdsDynamicDefault.common.DEFAULT]
+ ## This PCD defines the video horizontal resolution.
+ # This PCD could be set to 0 then video resolution could be at highest resolution.
+ gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|640
+ ## This PCD defines the video vertical resolution.
+ # This PCD could be set to 0 then video resolution could be at highest resolution.
+ gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|480
+
+ ## This PCD defines the Console output row and the default value is 80 according to UEFI spec.
+ # This PCD could be set to 0 then console output could be at max column and max row.
+ gEfiMdeModulePkgTokenSpaceGuid.PcdConOutColumn|128
+ ## This PCD defines the Console output column and the default value is 25 according to UEFI spec.
+ # This PCD could be set to 0 then console output could be at max column and max row.
+ gEfiMdeModulePkgTokenSpaceGuid.PcdConOutRow|40
+
+ ## Specify the video horizontal resolution of text setup.
+ # @Prompt Video Horizontal Resolution of Text Setup
+ gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoHorizontalResolution|640
+
+ ## Specify the video vertical resolution of text setup.
+ # @Prompt Video Vertical Resolution of Text Setup
+ gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoVerticalResolution|480
+
+ ## Specify the console output column of text setup.
+ # @Prompt Console Output Column of Text Setup
+ gEfiMdeModulePkgTokenSpaceGuid.PcdSetupConOutColumn|128
+ ## Specify the console output row of text setup.
+ # @Prompt Console Output Row of Text Setup
+ gEfiMdeModulePkgTokenSpaceGuid.PcdSetupConOutRow|40
+
+ ## The number of seconds that the firmware will wait before initiating the original default boot selection.
+ # A value of 0 indicates that the default boot selection is to be initiated immediately on boot.
+ # The value of 0xFFFF then firmware will wait for user input before booting.
+ # @Prompt Boot Timeout (s)
+ gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|5
diff --git a/Platform/Phytium/DurianPkg/DurianPkg.dsc b/Platform/Phytium/DurianPkg/DurianPkg.dsc
new file mode 100644
index 0000000000..b523ecd658
--- /dev/null
+++ b/Platform/Phytium/DurianPkg/DurianPkg.dsc
@@ -0,0 +1,298 @@
+## @file
+# This package provides common open source Phytium Platform modules.
+#
+# Copyright (C) 2020, Phytium Technology Co, Ltd. All rights reserved.
+#
+# SPDX-License-Identifier:BSD-2-Clause-Patent
+#
+##
+
+################################################################################
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+################################################################################
+[Defines]
+ PLATFORM_NAME = DurianPkg
+ PLATFORM_GUID = 8f7ac876-3e7c-11eb-86cb-33f68535d613
+ PLATFORM_VERSION = 0.1
+ DSC_SPECIFICATION = 0x0001001c
+ OUTPUT_DIRECTORY = Build/$(PLATFORM_NAME)
+ SUPPORTED_ARCHITECTURES = AARCH64
+ BUILD_TARGETS = DEBUG|RELEASE|NOOPT
+ SKUID_IDENTIFIER = DEFAULT
+ FLASH_DEFINITION = Platform/Phytium/DurianPkg/DurianPkg.fdf
+
+!include Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dsc.inc
+
+[LibraryClasses.common]
+ # Phytium Platform library
+ ArmPlatformLib|Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.inf
+
+ # PL011 UART Driver and Dependency Libraries
+ SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
+ PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
+ PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
+
+[LibraryClasses.common.DXE_DRIVER]
+
+
+################################################################################
+#
+# Pcd Section - list of all EDK II PCD Entries defined by this Platform
+#
+################################################################################
+[PcdsFixedAtBuild.common]
+ gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVendor|L"Durian Platform"
+ gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"V1.0"
+
+ gArmTokenSpaceGuid.PcdVFPEnabled|1
+ gArmTokenSpaceGuid.PcdArmPrimaryCoreMask|0x101
+ gArmTokenSpaceGuid.PcdArmPrimaryCore|0x0
+ gArmPlatformTokenSpaceGuid.PcdCoreCount|4
+
+ #
+ # NV Storage PCDs.
+ #
+ gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0xe00000
+ gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x00010000
+ gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64|0xe10000
+ gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x00010000
+ gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64|0xe20000
+ gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x00010000
+
+ # Size of the region used by UEFI in permanent memory (Reserved 64MB)
+ gArmPlatformTokenSpaceGuid.PcdSystemMemoryUefiRegionSize|0x04000000
+
+ #
+ # PL011 - Serial Terminal
+ #
+ gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x28001000
+ gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth|0
+ gArmPlatformTokenSpaceGuid.PL011UartClkInHz|48000000
+ gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200
+
+ #
+ # ARM General Interrupt Controller
+ #
+ gArmTokenSpaceGuid.PcdGicDistributorBase|0x29900000
+ gArmTokenSpaceGuid.PcdGicRedistributorsBase|0x29980000
+ gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0x29c00000
+
+ # System IO space
+ gPhytiumPlatformTokenSpaceGuid.PcdSystemIoBase|0x0
+ gPhytiumPlatformTokenSpaceGuid.PcdSystemIoSize|0x40000000
+
+ #
+ # System Memory (2GB ~ 4GB - 64MB), the top 64MB is reserved for
+ # PBF(the processor basic firmware, Mainly deals the initialization
+ # of the chip).
+ #
+ gArmTokenSpaceGuid.PcdSystemMemoryBase|0x80000000
+ gArmTokenSpaceGuid.PcdSystemMemorySize|0x7B000000
+
+ # Stack Size
+ gArmPlatformTokenSpaceGuid.PcdCPUCorePrimaryStackSize|0x4000
+
+ #
+ # Designware PCI Root Complex
+ #
+ gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0x40000000
+ gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|28
+ gPhytiumPlatformTokenSpaceGuid.PcdPciConfigBase|0x40000000
+ gPhytiumPlatformTokenSpaceGuid.PcdPciConfigSize|0x10000000
+ gArmTokenSpaceGuid.PcdPciBusMin|0
+ gArmTokenSpaceGuid.PcdPciBusMax|255
+ gArmTokenSpaceGuid.PcdPciIoBase|0x00000
+ gArmTokenSpaceGuid.PcdPciIoSize|0xf00000
+ gArmTokenSpaceGuid.PcdPciIoTranslation|0x50000000
+ gArmTokenSpaceGuid.PcdPciMmio32Base|0x58000000
+ gArmTokenSpaceGuid.PcdPciMmio32Size|0x28000000
+ gArmTokenSpaceGuid.PcdPciMmio32Translation|0x0
+ gArmTokenSpaceGuid.PcdPciMmio64Base|0x1000000000
+ gArmTokenSpaceGuid.PcdPciMmio64Size|0x1000000000
+ gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|FALSE
+
+################################################################################
+#
+# Components Section - list of all EDK II Modules needed by this Platform
+#
+################################################################################
+[Components.common]
+ #
+ # PCD database
+ #
+ MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
+
+ ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
+ ShellPkg/Application/Shell/Shell.inf {
+ <LibraryClasses>
+ ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
+ NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
+ NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
+ NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
+ NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
+ NULL|ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.inf
+ NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
+ NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
+ NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
+ HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
+ PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
+ BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
+ OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
+ }
+
+ ArmPlatformPkg/PrePi/PeiMPCore.inf {
+ <LibraryClasses>
+ ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
+ }
+
+ #
+ # Dxe core entry
+ #
+ MdeModulePkg/Core/Dxe/DxeMain.inf {
+ <LibraryClasses>
+ PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+ NULL|MdeModulePkg/Library/DxeCrc32GuidedSectionExtractLib/DxeCrc32GuidedSectionExtractLib.inf
+ }
+
+ #
+ # DXE driver
+ #
+ MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
+ MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
+ MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+ <LibraryClasses>
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+ }
+ MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
+
+ #
+ # Common Arm Timer and Gic Components
+ #
+ ArmPkg/Drivers/CpuDxe/CpuDxe.inf
+ ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
+ EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
+ ArmPkg/Drivers/TimerDxe/TimerDxe.inf
+
+ #
+ # security system
+ #
+ MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
+ <LibraryClasses>
+ NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
+ }
+
+ #
+ # network, mod for https boot.
+ #
+ NetworkPkg/SnpDxe/SnpDxe.inf
+ NetworkPkg/DpcDxe/DpcDxe.inf
+ NetworkPkg/MnpDxe/MnpDxe.inf
+ NetworkPkg/ArpDxe/ArpDxe.inf
+ NetworkPkg/Dhcp4Dxe/Dhcp4Dxe.inf
+ NetworkPkg/Ip4Dxe/Ip4Dxe.inf
+ NetworkPkg/Mtftp4Dxe/Mtftp4Dxe.inf
+ NetworkPkg/Udp4Dxe/Udp4Dxe.inf
+ NetworkPkg/VlanConfigDxe/VlanConfigDxe.inf
+
+ NetworkPkg/Ip6Dxe/Ip6Dxe.inf
+ NetworkPkg/Udp6Dxe/Udp6Dxe.inf
+ NetworkPkg/Dhcp6Dxe/Dhcp6Dxe.inf
+ NetworkPkg/Mtftp6Dxe/Mtftp6Dxe.inf
+ NetworkPkg/TcpDxe/TcpDxe.inf
+
+ NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
+
+ NetworkPkg/DnsDxe/DnsDxe.inf
+ NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.inf
+ NetworkPkg/HttpDxe/HttpDxe.inf
+
+ #
+ # FV Filesystem
+ #
+ MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
+
+ #
+ # Common Console Components
+ # ConIn,ConOut,StdErr
+ MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
+ MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
+ MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
+ MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
+ MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
+
+ SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
+
+ #
+ # Hii database init
+ #
+ MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
+
+ #
+ # FAT filesystem + GPT/MBR partitioning
+ #
+ MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
+ MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
+ MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
+ FatPkg/EnhancedFatDxe/Fat.inf
+
+ #
+ # Generic Watchdog Timer
+ #
+ ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
+
+ #
+ # Usb Support
+ #
+ MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf
+ MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe.inf
+ MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
+ MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
+ MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
+ MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouseDxe.inf
+ MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
+
+ #
+ # IDE/AHCI Support
+ #
+ MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
+ MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
+ MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
+ MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
+ MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
+
+ #
+ # PCI Support
+ #
+ ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf
+ MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
+
+ #
+ # The following 2 module perform the same work except one operate variable.
+ # Only one of both should be put into fdf.
+ #
+ MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
+
+ #
+ # NVME Support
+ #
+ MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
+
+
+ #
+ # Bds
+ #
+ MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
+ MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
+ MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+ MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
+ MdeModulePkg/Universal/DriverSampleDxe/DriverSampleDxe.inf
+ MdeModulePkg/Application/UiApp/UiApp.inf {
+ <LibraryClasses>
+ NULL|MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerUiLib.inf
+ NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
+ NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
+ }
+ MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenuApp.inf
+
diff --git a/Platform/Phytium/DurianPkg/DurianPkg.fdf b/Platform/Phytium/DurianPkg/DurianPkg.fdf
new file mode 100644
index 0000000000..9d75b072c6
--- /dev/null
+++ b/Platform/Phytium/DurianPkg/DurianPkg.fdf
@@ -0,0 +1,210 @@
+## @file
+# This package provides common open source Phytium Platform modules.
+#
+# Copyright (C) 2020, Phytium Technology Co, Ltd. All rights reserved.
+#
+# SPDX-License-Identifier:BSD-2-Clause-Patent
+#
+##
+
+################################################################################
+#
+# FD Section
+# The [FD] Section is made up of the definition statements and a
+# description of what goes into the Flash Device Image. Each FD section
+# defines one flash "device" image. A flash device image may be one of
+# the following: Removable media bootable image (like a boot floppy
+# image,) an Option ROM image (that would be "flashed" into an add-in
+# card,) a System "Flash" image (that would be burned into a system's
+# flash) or an Update ("Capsule") image that will be used to update and
+# existing system flash.
+#
+################################################################################
+
+[FD.PHYTIUM]
+BaseAddress = 0x88000000|gArmTokenSpaceGuid.PcdFdBaseAddress
+Size = 0x01000000|gArmTokenSpaceGuid.PcdFdSize
+ErasePolarity = 1
+
+# This one is tricky, it must be: BlockSize * NumBlocks = Size
+BlockSize = 0x10000
+NumBlocks = 0x100
+
+################################################################################
+#
+# Following are lists of FD Region layout which correspond to the locations of different
+# images within the flash device.
+#
+# Regions must be defined in ascending order and may not overlap.
+#
+# A Layout Region start with a eight digit hex offset (leading "0x" required) followed by
+# the pipe "|" character, followed by the size of the region, also in hex with the leading
+# "0x" characters. Like:
+# Offset|Size
+# PcdOffsetCName|PcdSizeCName
+# RegionType <FV, DATA, or FILE>
+#
+################################################################################
+
+0x00000000|0x200000
+gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
+FV = FVMAIN_COMPACT
+
+################################################################################
+#
+# FV Section
+#
+# [FV] section is used to define what components or modules are placed within a flash
+# device file. This section also defines order the components and modules are positioned
+# within the image. The [FV] section consists of define statements, set statements and
+# module statements.
+#
+################################################################################
+
+[FV.FvMain]
+BlockSize = 0x40
+NumBlocks = 0 # This FV gets compressed so make it just big enough
+FvAlignment = 16 # FV alignment and FV attributes setting.
+ERASE_POLARITY = 1
+MEMORY_MAPPED = TRUE
+STICKY_WRITE = TRUE
+LOCK_CAP = TRUE
+LOCK_STATUS = TRUE
+WRITE_DISABLED_CAP = TRUE
+WRITE_ENABLED_CAP = TRUE
+WRITE_STATUS = TRUE
+WRITE_LOCK_CAP = TRUE
+WRITE_LOCK_STATUS = TRUE
+READ_DISABLED_CAP = TRUE
+READ_ENABLED_CAP = TRUE
+READ_STATUS = TRUE
+READ_LOCK_CAP = TRUE
+READ_LOCK_STATUS = TRUE
+
+ APRIORI DXE {
+ INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
+ }
+
+ INF MdeModulePkg/Core/Dxe/DxeMain.inf
+ INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
+
+ #
+ # PI DXE Drivers producing Architectural Protocols (EFI Services)
+ #
+ INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
+ INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
+ INF EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
+
+ INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
+ INF MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
+
+ INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
+ INF ArmPkg/Drivers/CpuDxe/CpuDxe.inf
+ INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
+ INF ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
+
+ #
+ # Variable services
+ #
+ INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+ INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
+
+ INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
+
+ #
+ # Multiple Console IO support
+ #
+ INF MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
+ INF MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
+ INF MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
+ INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
+ INF MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
+
+ #
+ # FAT filesystem + GPT/MBR partitioning
+ #
+ INF MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
+ INF MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
+ INF FatPkg/EnhancedFatDxe/Fat.inf
+ INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
+
+ #
+ # SATA Controller
+ #
+ INF MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
+ INF MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
+ INF MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
+ INF MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
+ INF MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
+
+ #
+ # NVMe boot devices
+ #
+ INF MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
+
+ #
+ # Usb Support
+ #
+ INF MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf
+ INF MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe.inf
+ INF MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
+ INF MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
+ INF MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
+ INF MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouseDxe.inf
+ INF MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
+
+ #
+ # NetWork
+ #
+ INF NetworkPkg/SnpDxe/SnpDxe.inf
+ INF NetworkPkg/DpcDxe/DpcDxe.inf
+ INF NetworkPkg/MnpDxe/MnpDxe.inf
+ INF NetworkPkg/ArpDxe/ArpDxe.inf
+ INF NetworkPkg/Dhcp4Dxe/Dhcp4Dxe.inf
+ INF NetworkPkg/Ip4Dxe/Ip4Dxe.inf
+ INF NetworkPkg/Mtftp4Dxe/Mtftp4Dxe.inf
+ INF NetworkPkg/Udp4Dxe/Udp4Dxe.inf
+ INF NetworkPkg/VlanConfigDxe/VlanConfigDxe.inf
+
+ #
+ # UEFI applications
+ #
+ INF ShellPkg/Application/Shell/Shell.inf
+
+ #
+ # Bds
+ #
+ INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
+ INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
+ INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+ INF MdeModulePkg/Universal/DriverSampleDxe/DriverSampleDxe.inf
+ INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
+ INF MdeModulePkg/Application/UiApp/UiApp.inf
+
+[FV.FVMAIN_COMPACT]
+FvAlignment = 16
+ERASE_POLARITY = 1
+MEMORY_MAPPED = TRUE
+STICKY_WRITE = TRUE
+LOCK_CAP = TRUE
+LOCK_STATUS = TRUE
+WRITE_DISABLED_CAP = TRUE
+WRITE_ENABLED_CAP = TRUE
+WRITE_STATUS = TRUE
+WRITE_LOCK_CAP = TRUE
+WRITE_LOCK_STATUS = TRUE
+READ_DISABLED_CAP = TRUE
+READ_ENABLED_CAP = TRUE
+READ_STATUS = TRUE
+READ_LOCK_CAP = TRUE
+READ_LOCK_STATUS = TRUE
+
+ INF ArmPlatformPkg/PrePi/PeiMPCore.inf
+
+ FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
+ SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF PROCESSING_REQUIRED = TRUE {
+ SECTION FV_IMAGE = FVMAIN
+ }
+ }
+
+!include Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.fdf.inc
diff --git a/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.inf b/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.inf
new file mode 100644
index 0000000000..40c070767a
--- /dev/null
+++ b/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.inf
@@ -0,0 +1,55 @@
+#/** @file
+# Library for Phytium Platform.
+#
+# Copyright (C) 2020, Phytium Technology Co, Ltd. All rights reserved.<BR>
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+#**/
+
+[Defines]
+ INF_VERSION = 0x0001001b
+ BASE_NAME = PlatformLib
+ FILE_GUID = fac08f56-40fe-11eb-a2a3-27b46864b1f3
+ MODULE_TYPE = BASE
+ VERSION_STRING = 1.0
+ LIBRARY_CLASS = ArmPlatformLib
+
+[Packages]
+ ArmPkg/ArmPkg.dec
+ ArmPlatformPkg/ArmPlatformPkg.dec
+ MdePkg/MdePkg.dec
+ MdeModulePkg/MdeModulePkg.dec
+ Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dec
+
+[LibraryClasses]
+ ArmSmcLib
+ HobLib
+
+[Sources.common]
+ PlatformLib.c
+ PlatformLibMem.c
+
+[Sources.AARCH64]
+ AArch64/PhytiumPlatformHelper.S
+
+[Guids]
+
+[FixedPcd]
+ gPhytiumPlatformTokenSpaceGuid.PcdSystemIoBase
+ gPhytiumPlatformTokenSpaceGuid.PcdSystemIoSize
+ gPhytiumPlatformTokenSpaceGuid.PcdPciConfigBase
+ gPhytiumPlatformTokenSpaceGuid.PcdPciConfigSize
+ gArmTokenSpaceGuid.PcdPciBusMin
+ gArmTokenSpaceGuid.PcdPciBusMax
+ gArmTokenSpaceGuid.PcdPciIoBase
+ gArmTokenSpaceGuid.PcdPciIoSize
+ gArmTokenSpaceGuid.PcdPciIoTranslation
+ gArmTokenSpaceGuid.PcdPciMmio32Base
+ gArmTokenSpaceGuid.PcdPciMmio32Size
+ gArmTokenSpaceGuid.PcdPciMmio32Translation
+ gArmTokenSpaceGuid.PcdPciMmio64Base
+ gArmTokenSpaceGuid.PcdPciMmio64Size
+
+[Pcd]
+ gArmPlatformTokenSpaceGuid.PcdCoreCount
diff --git a/Silicon/Phytium/PhytiumCommonPkg/Include/SystemServiceInterface.h b/Silicon/Phytium/PhytiumCommonPkg/Include/SystemServiceInterface.h
new file mode 100644
index 0000000000..c4395153a3
--- /dev/null
+++ b/Silicon/Phytium/PhytiumCommonPkg/Include/SystemServiceInterface.h
@@ -0,0 +1,112 @@
+/** @file
+
+ Copyright (C) 2020, Phytium Technology Co Ltd. All rights reserved.<BR>
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef SYSTEM_SERVICE_INTERFACE_H_
+#define SYSTEM_SERVICE_INTERFACE_H_
+
+/* SMC function IDs for OEM Service queries */
+#define PHYTIUM_OEM_SVC_PSSI_VERSION 0x8200ff03
+#define PHYTIUM_OEM_SVC_PBF_VERSION 0x82000001
+#define PHYTIUM_OEM_SVC_CPU_VERSION 0xc2000002
+#define PHYTIUM_OEM_SVC_CPU_MAPS 0xc2000003
+#define PHYTIUM_OEM_SVC_CPU_CONF 0xc2000004
+#define PHYTIUM_OEM_SVC_MEM_REGIONS 0xc2000005
+#define PHYTIUM_OEM_SVC_MCU_DIMMS 0xc2000006
+#define PHYTIUM_OEM_SVC_PCI_CONTROLLER 0xc2000007
+#define PHYTIUM_OEM_SVC_HOST_BRIDGE 0xc2000008
+#define PHYTIUM_OEM_SVC_GET_FLASH_CMD 0xC200000C
+
+#define PHYTIUM_IOBASE_MASK 0xfffffff
+#define PHYTIUM_MEMIO32_MASK 0xffffffff
+#define PHYTIUM_MEMIO64_MASK 0xffffffffff
+
+#pragma pack(1)
+
+typedef struct {
+ UINT64 CpuMapCount;
+ UINT64 CpuMap[1];
+} PHYTIUM_CPU_MAP_INFO;
+
+
+typedef struct {
+ UINT64 CpuFreq; // Hz
+ UINT64 CpuL3CacheSize; // Byte
+ UINT64 CpuL3CacheLineSize; // Byte
+} PHYTIUM_CPU_COURE_INFO;
I believe this should be
CORE, not
COURE
?

+
+typedef struct {
+ UINT64 CupVersion; //cpu version
+ PHYTIUM_CPU_COURE_INFO CpuCoreInfo; //cpu core info
+ PHYTIUM_CPU_MAP_INFO CpuMapInfo; //cpu map info
+}PHYTIUM_CPU_INFO;
+
+typedef struct {
+ UINT64 MemSize; // MB
+ UINT64 MemDramId;
+ UINT64 MemModuleId;
+ UINT64 MemSerial;
+ UINT64 MemSlotNumber;
+ UINT64 MemFeatures;
+} MCU_DIMM;
Could you add PHYTIUM_ prefixes for all of the remaining structures as
well please?

+
+#define MCU_DIMM_MAXCOUNT 2
+
+typedef struct {
+ UINT64 MemFreq; // MHz
+ UINT64 MemDimmCount;
+ MCU_DIMM McuDimm[1];
+} MCU_DIMMS;
+
+typedef struct {
+ UINT64 MemStart;
+ UINT64 MemSize;
+ UINT64 MemNodeId;
+} MEMORY_BLOCK;
+
+typedef struct {
+ UINT64 MemBlockCount;
+ MEMORY_BLOCK MemBlock[1];
+} MEMORY_INFO;
+
+typedef struct {
+ UINT8 PciLane;
+ UINT8 PciSpeed;
+ UINT8 Reserved[6];
+} PCI_BLOCK;
+
+typedef struct {
+ UINT64 PciCount;
+ PCI_BLOCK PciBlock[1];
+} PHYTIUM_PCI_CONTROLLER;
+
+typedef struct {
+ UINT8 BusStart;
+ UINT8 BusEnd;
+ UINT8 Reserved[6];
+ UINT64 PciConfigBase;
+ UINT64 IoBase;
+ UINT64 IoSize;
+ UINT64 Mem32Base;
+ UINT64 Mem32Size;
+ UINT64 Mem64Base;
+ UINT64 Mem64Size;
+ UINT16 IntA;
+ UINT16 IntB;
+ UINT16 IntC;
+ UINT16 IntD;
+} PCI_HOST_BLOCK;
Including this one.

If you address all these comments, you can add
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
to the commit message for this patch for v4.

/
Leif

+
+typedef struct {
+ UINT64 PciHostCount;
+ PCI_HOST_BLOCK PciHostBlock[1];
+} PHYTIUM_PCI_HOST_BRIDGE;
+
+#pragma pack ()
+
+
+#endif // SYSTEM_SERVICE_INTERFACE_H_
diff --git a/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.c b/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.c
new file mode 100644
index 0000000000..6a8d226574
--- /dev/null
+++ b/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.c
@@ -0,0 +1,137 @@
+/** @file
+ Library for Phytium platform.
+
+ Copyright (C) 2020, Phytium Technology Co Ltd. All rights reserved.<BR>
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include <Library/ArmPlatformLib.h>
+#include <Library/DebugLib.h>
+#include <Library/IoLib.h>
+#include <Library/PcdLib.h>
+#include <Ppi/ArmMpCoreInfo.h>
+
+ARM_CORE_INFO mPhytiumMpCoreInfoTable[] = {
+ {
+ 0x0, 0x0, // Cluster 0, Core 0
+
+ // MP Core MailBox Set/Get/Clear Addresses and Clear Value
+ (EFI_PHYSICAL_ADDRESS)0,
+ (EFI_PHYSICAL_ADDRESS)0,
+ (EFI_PHYSICAL_ADDRESS)0,
+ (UINT64)0xFFFFFFFF
+ }
+};
+
+/*
+ This function geted the current Boot Mode.
+
+ This function returns the boot reason on the platform.
+
+ @return Return the current Boot Mode of the platform.
+
+*/
+EFI_BOOT_MODE
+ArmPlatformGetBootMode (
+ VOID
+ )
+{
+ return BOOT_WITH_FULL_CONFIGURATION;
+}
+
+
+/**
+ Initialize controllers that must setup in the normal world.
+
+ This function is called by the ArmPlatformPkg/Pei or ArmPlatformPkg/Pei/PlatformPeim
+ in the PEI phase.
+
+ @retval EFI_SUCCESS ArmPlatformInitialize() is executed successfully.
+
+**/
+RETURN_STATUS
+ArmPlatformInitialize (
+ IN UINTN MpId
+ )
+{
+ return RETURN_SUCCESS;
+}
+
+
+/**
+ This function Inited the system (or sometimes called permanent) memory.
+
+ This memory is generally represented by the DRAM.
+
+ @param[in] None.
+
+ @retval None.
+
+**/
+VOID
+ArmPlatformInitializeSystemMemory (
+ VOID
+ )
+{
+ // Nothing to do here
+}
+
+
+/**
+ This function geted the information of core.
+
+ @param[out] CoreCount The count of CoreInfoTable.
+ @param[out] ArmCoreTable The pointer of CoreInfoTable.
+
+ @retval EFI_SUCCESS PrePeiCoreGetMpCoreInfo() is executed successfully.
+
+**/
+EFI_STATUS
+PrePeiCoreGetMpCoreInfo (
+ OUT UINTN *CoreCount,
+ OUT ARM_CORE_INFO **ArmCoreTable
+ )
+{
+ *CoreCount = PcdGet32 (PcdCoreCount);
+ *ArmCoreTable = mPhytiumMpCoreInfoTable;
+
+ return EFI_SUCCESS;
+}
+
+//
+// Needs to be declared in the file. Otherwise gArmMpCoreInfoPpiGuid is
+// undefined in the contect of PrePeiCore
+//
+EFI_GUID mArmMpCoreInfoPpiGuid = ARM_MP_CORE_INFO_PPI_GUID;
+ARM_MP_CORE_INFO_PPI mMpCoreInfoPpi = { PrePeiCoreGetMpCoreInfo };
+
+EFI_PEI_PPI_DESCRIPTOR gPlatformPpiTable[] =
+{
+ {
+ EFI_PEI_PPI_DESCRIPTOR_PPI,
+ &mArmMpCoreInfoPpiGuid,
+ &mMpCoreInfoPpi
+ }
+};
+
+
+/**
+ This function geted the information of Ppitable.
+
+ @param[out] PpiListSize The size of Ppitable.
+ @param[out] PpiList The pointer of Ppitable.
+
+ @retval None.
+
+**/
+VOID
+ArmPlatformGetPlatformPpiList (
+ OUT UINTN *PpiListSize,
+ OUT EFI_PEI_PPI_DESCRIPTOR **PpiList
+ )
+{
+ *PpiListSize = sizeof (gPlatformPpiTable);
+ *PpiList = gPlatformPpiTable;
+}
diff --git a/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLibMem.c b/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLibMem.c
new file mode 100644
index 0000000000..7e54cb6e74
--- /dev/null
+++ b/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLibMem.c
@@ -0,0 +1,156 @@
+/** @file
+ Library of memory map for Phytium platform.
+
+ Copyright (C) 2020, Phytium Technology Co Ltd. All rights reserved.<BR>
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include <Library/ArmPlatformLib.h>
+#include <Library/DebugLib.h>
+#include <Library/HobLib.h>
+#include <Library/PcdLib.h>
+#include <Library/MemoryAllocationLib.h>
+#include <Library/ArmSmcLib.h>
+#include <SystemServiceInterface.h>
+
+// Number of Virtual Memory Map Descriptors
+#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS 32
+
+// DDR attributes
+#define DDR_ATTRIBUTES_CACHED ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK
+#define DDR_ATTRIBUTES_UNCACHED ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED
+
+/**
+ Return the Virtual Memory Map of your platform
+
+ This Virtual Memory Map is used by MemoryInitPei Module to initialize the MMU on your platform.
+
+ @param[out] VirtualMemoryMap Array of ARM_MEMORY_REGION_DESCRIPTOR describing a Physical-to-
+ Virtual Memory mapping. This array must be ended by a zero-filled
+ entry
+**/
+VOID
+ArmPlatformGetVirtualMemoryMap (
+ IN ARM_MEMORY_REGION_DESCRIPTOR** VirtualMemoryMap
+ )
+{
+ ARM_MEMORY_REGION_ATTRIBUTES CacheAttributes;
+ ARM_MEMORY_REGION_DESCRIPTOR *VirtualMemoryTable;
+ EFI_RESOURCE_ATTRIBUTE_TYPE ResourceAttributes;
+ MEMORY_BLOCK *MemBlock;
+ MEMORY_INFO *MemInfo;
+ ARM_SMC_ARGS ArmSmcArgs;
+ UINT32 MemBlockCnt;
+ UINT32 Index1;
+ UINT32 Index2;
+
+ MemBlock = NULL;
+ MemInfo = NULL;
+ MemBlockCnt = 0;
+ Index1 = 0;
+ Index2 = 0;
+ CacheAttributes = ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
+
+ ASSERT (VirtualMemoryMap != NULL);
+ VirtualMemoryTable = (ARM_MEMORY_REGION_DESCRIPTOR*)AllocatePages \
+ (EFI_SIZE_TO_PAGES (sizeof (ARM_MEMORY_REGION_DESCRIPTOR) * \
+ MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS));
+ if (VirtualMemoryTable == NULL) {
+ return;
+ }
+
+ ResourceAttributes =
+ EFI_RESOURCE_ATTRIBUTE_PRESENT |
+ EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
+ EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
+ EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
+ EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
+ EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE |
+ EFI_RESOURCE_ATTRIBUTE_TESTED;
+
+ MemInfo = AllocatePages (1);
+ ASSERT (MemInfo != NULL);
+
+ ArmSmcArgs.Arg0 = PHYTIUM_OEM_SVC_MEM_REGIONS;
+ ArmSmcArgs.Arg1 = (UINTN) MemInfo;
+ ArmSmcArgs.Arg2 = EFI_PAGE_SIZE;
+ ArmCallSmc (&ArmSmcArgs);
+ if (ArmSmcArgs.Arg0 == 0) {
+ MemBlockCnt = MemInfo->MemBlockCount;
+ MemBlock = MemInfo->MemBlock;
+ } else {
+ ASSERT (FALSE);
+ }
+
+ //Soc Io Space
+ VirtualMemoryTable[Index1].PhysicalBase = PcdGet64 (PcdSystemIoBase);
+ VirtualMemoryTable[Index1].VirtualBase = PcdGet64 (PcdSystemIoBase);
+ VirtualMemoryTable[Index1].Length = PcdGet64 (PcdSystemIoSize);
+ VirtualMemoryTable[Index1].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
+
+ //
+ // PCI Configuration Space
+ //
+ VirtualMemoryTable[++Index1].PhysicalBase = PcdGet64 (PcdPciConfigBase);
+ VirtualMemoryTable[Index1].VirtualBase = PcdGet64 (PcdPciConfigBase);
+ VirtualMemoryTable[Index1].Length = PcdGet64 (PcdPciConfigSize);
+ VirtualMemoryTable[Index1].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
+
+ //
+ // PCI Memory Space
+ //
+ VirtualMemoryTable[++Index1].PhysicalBase = PcdGet64 (PcdPciIoBase) + PcdGet64 (PcdPciIoTranslation);
+ VirtualMemoryTable[Index1].VirtualBase = PcdGet64 (PcdPciIoBase) + PcdGet64 (PcdPciIoTranslation);
+ VirtualMemoryTable[Index1].Length = PcdGet64 (PcdPciIoSize);
+ VirtualMemoryTable[Index1].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
+
+ //
+ // PCI Memory Space
+ //
+ VirtualMemoryTable[++Index1].PhysicalBase = PcdGet32 (PcdPciMmio32Base);
+ VirtualMemoryTable[Index1].VirtualBase = PcdGet32 (PcdPciMmio32Base);
+ VirtualMemoryTable[Index1].Length = PcdGet32 (PcdPciMmio32Size);
+ VirtualMemoryTable[Index1].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
+
+ //
+ // 64-bit PCI Memory Space
+ //
+ VirtualMemoryTable[++Index1].PhysicalBase = PcdGet64 (PcdPciMmio64Base);
+ VirtualMemoryTable[Index1].VirtualBase = PcdGet64 (PcdPciMmio64Base);
+ VirtualMemoryTable[Index1].Length = PcdGet64 (PcdPciMmio64Size);
+ VirtualMemoryTable[Index1].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
+
+ //DDR
+ for (Index2 = 0; Index2 < MemBlockCnt; Index2++) {
+ VirtualMemoryTable[++Index1].PhysicalBase = MemBlock->MemStart;
+ VirtualMemoryTable[Index1].VirtualBase = MemBlock->MemStart;
+ VirtualMemoryTable[Index1].Length = MemBlock->MemSize;
+ VirtualMemoryTable[Index1].Attributes = CacheAttributes;
+
+ BuildResourceDescriptorHob (
+ EFI_RESOURCE_SYSTEM_MEMORY,
+ ResourceAttributes,
+ MemBlock->MemStart,
+ MemBlock->MemSize
+ );
+
+ MemBlock++;
+ }
+
+ // End of Table
+ VirtualMemoryTable[++Index1].PhysicalBase = 0;
+ VirtualMemoryTable[Index1].VirtualBase = 0;
+ VirtualMemoryTable[Index1].Length = 0;
+ VirtualMemoryTable[Index1].Attributes = (ARM_MEMORY_REGION_ATTRIBUTES)0;
+
+
+ for (Index2 = 0; Index2 < Index1; Index2++) {
+ DEBUG ((DEBUG_ERROR, "PhysicalBase %12lx VirtualBase %12lx Length %12lx Attributes %12lx\n",\
+ VirtualMemoryTable[Index2].PhysicalBase, VirtualMemoryTable[Index2].VirtualBase, \
+ VirtualMemoryTable[Index2].Length, VirtualMemoryTable[Index2].Attributes));
+ }
+
+ *VirtualMemoryMap = VirtualMemoryTable;
+}
diff --git a/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/AArch64/PhytiumPlatformHelper.S b/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/AArch64/PhytiumPlatformHelper.S
new file mode 100644
index 0000000000..cce23b7861
--- /dev/null
+++ b/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/AArch64/PhytiumPlatformHelper.S
@@ -0,0 +1,76 @@
+#
+# Copyright (c) 2011-2013, ARM Limited. All rights reserved.
+#
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD License
+# which accompanies this distribution. The full text of the license may be found at
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+#
+#
+
+#include <AsmMacroIoLibV8.h>
+#include <Base.h>
+#include <Library/ArmLib.h>
+#include <Library/PcdLib.h>
+#include <AutoGen.h>
+
+.text
+.align 2
+
+GCC_ASM_EXPORT(ArmPlatformPeiBootAction)
+GCC_ASM_EXPORT(ArmPlatformIsPrimaryCore)
+GCC_ASM_EXPORT(ArmPlatformGetPrimaryCoreMpId)
+GCC_ASM_EXPORT(ArmPlatformGetCorePosition)
+
+PrimaryCoreMpid: .word 0x0
+
+
+ASM_PFX(ArmPlatformPeiBootAction):
+ // Save MPIDR_EL1[23:0] in a variable.
+ mov x20, x30
+ bl ASM_PFX(ArmReadMpidr)
+ lsl w0, w0, #8
+ lsr w0, w0, #8
+ ldr x1, =PrimaryCoreMpid
+ str w0, [x1]
+ ret x20
+
+//UINTN
+//ArmPlatformGetPrimaryCoreMpId (
+// VOID
+// );
+ASM_PFX(ArmPlatformGetPrimaryCoreMpId):
+ ldr x0, =PrimaryCoreMpid
+ ldr w0, [x0]
+ ret
+
+//UINTN
+//ArmPlatformIsPrimaryCore (
+// IN UINTN MpId
+// );
+ASM_PFX(ArmPlatformIsPrimaryCore):
+ mov x20, x30
+ bl ASM_PFX(ArmReadMpidr)
+ lsl w0, w0, #8
+ lsr w0, w0, #8
+ ldr x1, =PrimaryCoreMpid
+ ldr w1, [x1]
+ cmp w0, w1
+ cset x0, eq
+ ret x20
+
+//UINTN
+//ArmPlatformGetCorePosition (
+// IN UINTN MpId
+// );
+// With this function: CorePos = (ClusterId * 4) + CoreId
+ASM_PFX(ArmPlatformGetCorePosition):
+ and x1, x0, #ARM_CORE_MASK
+ and x0, x0, #ARM_CLUSTER_MASK
+ add x0, x1, x0, LSR #6
+ ret
+
+ASM_FUNCTION_REMOVE_IF_UNREFERENCED
diff --git a/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.fdf.inc b/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.fdf.inc
new file mode 100644
index 0000000000..641266c601
--- /dev/null
+++ b/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.fdf.inc
@@ -0,0 +1,119 @@
+## @file
+# This package provides common open source Phytium silicon modules.
+#
+# Copyright (C) 2020, Phytium Technology Co, Ltd. All rights reserved.
+#
+# SPDX-License-Identifier:BSD-2-Clause-Patent
+#
+##
+
+############################################################################
+# Example of a DXE_DRIVER FFS file with a Checksum encapsulation section #
+############################################################################
+#
+#[Rule.Common.DXE_DRIVER]
+# FILE DRIVER = $(NAMED_GUID) {
+# DXE_DEPEX DXE_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
+# COMPRESS PI_STD {
+# GUIDED {
+# PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
+# UI STRING="$(MODULE_NAME)" Optional
+# VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
+# }
+# }
+# }
+#
+############################################################################
+
+[Rule.Common.SEC]
+ FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED FIXED {
+ TE TE Align = Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
+ }
+
+[Rule.Common.PEI_CORE]
+ FILE PEI_CORE = $(NAMED_GUID) FIXED {
+ TE TE Align = Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
+ UI STRING ="$(MODULE_NAME)" Optional
+ }
+
+[Rule.Common.PEIM]
+ FILE PEIM = $(NAMED_GUID) FIXED {
+ PEI_DEPEX PEI_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
+ TE TE Align = Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
+ UI STRING="$(MODULE_NAME)" Optional
+ }
+
+[Rule.Common.PEIM.TIANOCOMPRESSED]
+ FILE PEIM = $(NAMED_GUID) DEBUG_MYTOOLS_IA32 {
+ PEI_DEPEX PEI_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
+ GUIDED A31280AD-481E-41B6-95E8-127F4C984779 PROCESSING_REQUIRED = TRUE {
+ PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
+ UI STRING="$(MODULE_NAME)" Optional
+ }
+ }
+
+[Rule.Common.DXE_CORE]
+ FILE DXE_CORE = $(NAMED_GUID) {
+ PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
+ UI STRING="$(MODULE_NAME)" Optional
+ }
+
+[Rule.Common.UEFI_DRIVER]
+ FILE DRIVER = $(NAMED_GUID) {
+ DXE_DEPEX DXE_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
+ PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
+ UI STRING="$(MODULE_NAME)" Optional
+ }
+
+[Rule.Common.DXE_DRIVER]
+ FILE DRIVER = $(NAMED_GUID) {
+ DXE_DEPEX DXE_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
+ PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
+ UI STRING="$(MODULE_NAME)" Optional
+ }
+
+[Rule.Common.DXE_RUNTIME_DRIVER]
+ FILE DRIVER = $(NAMED_GUID) {
+ DXE_DEPEX DXE_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
+ PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
+ UI STRING="$(MODULE_NAME)" Optional
+ }
+
+[Rule.Common.UEFI_APPLICATION]
+ FILE APPLICATION = $(NAMED_GUID) {
+ UI STRING ="$(MODULE_NAME)" Optional
+ PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
+ }
+
+[Rule.Common.UEFI_DRIVER.BINARY]
+ FILE DRIVER = $(NAMED_GUID) {
+ DXE_DEPEX DXE_DEPEX Optional |.depex
+ PE32 PE32 |.efi
+ UI STRING="$(MODULE_NAME)" Optional
+ VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
+ }
+
+[Rule.Common.UEFI_APPLICATION.BINARY]
+ FILE APPLICATION = $(NAMED_GUID) {
+ PE32 PE32 |.efi
+ UI STRING="$(MODULE_NAME)" Optional
+ VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
+ }
+
+[Rule.Common.USER_DEFINED.BIOSINFO]
+ FILE FREEFORM = $(NAMED_GUID) {
+ RAW BIN Align = 16 $(INF_OUTPUT)/$(MODULE_NAME).acpi
+ }
+
+[Rule.Common.UEFI_APPLICATION.UI]
+ FILE APPLICATION = $(NAMED_GUID) {
+ PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
+ UI STRING="Enter Setup"
+ VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
+ }
+
+[Rule.Common.USER_DEFINED.ACPITABLE]
+ FILE FREEFORM = $(NAMED_GUID) {
+ RAW ACPI |.acpi
+ RAW ASL |.aml
+ }
--
2.25.1


Re: [PATCH 1/5] ArmPkg: Allow platforms to override PCI supported state in SmbiosMiscDxe

Ard Biesheuvel
 

On Tue, 13 Apr 2021 at 18:51, Leif Lindholm <leif@nuviainc.com> wrote:

On Tue, Mar 30, 2021 at 20:16:15 -0600, Rebecca Cran wrote:
Not all platforms support PCI, so introduce a PCD to allow platforms to
specify whether they support it.
Are we planning to add one?
If not, I'd rather skip this until we do.
These days, I would expect any platform providing SMBIOS tables to
have PCI.
Also, does it matter? SMBIOS is mostly informational, and whether a
platform 'supports' PCI does not imply that it 'implements' it. And
even if it implements PCI, it may not have any slots.

IOW, this is PC legacy that we care little about one way or the other, I think..


No further comments on this set.

/
Leif

Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
---
ArmPkg/ArmPkg.dec | 1 +
ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf | 1 +
ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c | 4 ++++
3 files changed, 6 insertions(+)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index a8a22c649ff8..51ac2191c85a 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -125,6 +125,7 @@ [PcdsFixedAtBuild.common]
#
# SMBIOS PCDs
#
+ gArmTokenSpaceGuid.PcdPlatformSupportsPCI|TRUE|BOOLEAN|0x30000052
gArmTokenSpaceGuid.PcdSystemProductName|L""|VOID*|0x30000053
gArmTokenSpaceGuid.PcdSystemVersion|L""|VOID*|0x30000054
gArmTokenSpaceGuid.PcdBaseBoardManufacturer|L""|VOID*|0x30000055
diff --git a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
index 60d8fe31c219..ebc4c99ac436 100644
--- a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
+++ b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
@@ -71,6 +71,7 @@ [Pcd]
gArmTokenSpaceGuid.PcdFdSize
gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVendor
gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString
+ gArmTokenSpaceGuid.PcdPlatformSupportsPCI
gArmTokenSpaceGuid.PcdSystemBiosRelease
gArmTokenSpaceGuid.PcdEmbeddedControllerFirmwareRelease
gArmTokenSpaceGuid.PcdSystemProductName
diff --git a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c
index 5aea32521bd3..a06f814aeb7c 100644
--- a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c
+++ b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c
@@ -13,6 +13,7 @@
#include <Library/DebugLib.h>
#include <Library/HiiLib.h>
#include <Library/MemoryAllocationLib.h>
+#include <Library/PcdLib.h>
#include <Library/PrintLib.h>
#include <Library/UefiBootServicesTableLib.h>

@@ -264,6 +265,9 @@ SMBIOS_MISC_TABLE_FUNCTION (MiscBiosVendor)
UnicodeStrToAsciiStrS (Version, StrStart, VerStrLen + 1);
StrStart += VerStrLen + 1;
UnicodeStrToAsciiStrS (ReleaseDate, StrStart, DateStrLen + 1);
+
+ SmbiosRecord->BiosCharacteristics.PciIsSupported = FixedPcdGetBool (PcdPlatformSupportsPCI);
+
//
// Now we have got the full smbios record, call smbios protocol to add this record.
//
--
2.26.2


Re: VirtIO Sound Driver (GSoC 2021)

Ethin Probst
 

Would it be possible for us to conduct discussion on the UEFI talkbox?
I don't mind using email, but things could definitely get moving
quicker over there (though its not a requirement obviously).

Here's how I generally envision the driver functioning:

1. Firmware/platform code calls InitaudioOutput() or something like
it. This function scans the PCIe bus and scans for one of the
following:
- Vendor ID 0x1AF4, device ID 0x1059: VirtIO sound device
- PCI class 0x0C, subclass 0x03, program interface 0x30 or 0x40: for
USB audio interface (I'm only thinking of targeting XHCI and USB 4,
and not UHCI, OHCI or EHCI). But maybe EDK2 will take that out of my
hands. If so, it will make things easier.
- For USB audio devices I'm not quite sure what to look for; I'm
definitely unused to USB.
2. If any of the above cases are found, appropriate driver
initialization occurs. Since for the time being I am solely focusing
on VirtIO sound devices, the VirtIO general initialization sequence
will occur as outlined in sec. 3 of the VirtIO specification available
at https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html.
As for actual protocol exposure that would be spec-worthy, for
EFI_AUDIO_OUTPUT_PROTOCOL, I'm not quite sure what to expose. VirtIO
is rather simple: there's a buffer for sending and receiving audio
data in PCM streams. So for that we could expose a Reset(),
RemapJack(), GetJackConfig(), GetPcmConfig(), SetPcmParams(),
Prepare(), Release(), Start(), and Stop() function for the
corresponding request types VIRTIO_SND_R_JACK_GET_CONFIG,
VIRTIO_SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG,
VIRTIO_SND_R_PCM_SET_PARAMS, VIRTIO_SND_R_PCM_PREPARE,
VIRTIO_SND_R_PCM_RELEASE, VIRTIO_SND_R_PCM_START, and
VIRTIO_SND_R_PCM_STOP control requests. However, for HDA things are a
lot more complex, so I'm not sure how that should work.
For VirtIO -- which is what I'll focus on for now -- everything is
described, in excellent detail, in sec. 5.14 of the above-linked
document. What are your guys's thoughts thus far and how should
everything be mapped to UEFI interfaces?

On 4/13/21, Andrew Fish <afish@apple.com> wrote:
Leif,

Since I have put some brain cells around this area in the past I can be the
backup and help out too.

I’d also point out if you are having issues building or have general
questions on how things work it is fine to use the mailing list. I’ve got a
lot of feedback that folks read or search the mailing list looking for
answer to their questions so one person asking can help out a lot of other
people.

Thanks,

Andrew Fish

On Apr 13, 2021, at 5:28 AM, Leif Lindholm <leif@nuviainc.com> wrote:

Hi all, especially Ethin.

Apologies for radio silence - last week I was off on holiday, and before
that ... let's just say corporate acquisitions generate some
distractions.
Anyway, I'm back, and since I'm down as the mentor for this task, feel
free to spam me with any remaining/new questions.

/
Leif

On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst <harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com>> wrote:
I'll attach the bug for the build tools to the BZ shortly.
Laszlo, thanks for that. I don't know their email addresses though.
And yes, I was going to make it device independent, as the majority
(if not all) of UEFI protocols are.

On 4/6/21, Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>>
wrote:
On 03/31/21 08:41, Nate DeSimone wrote:
Another option is to put the protocol definition in MdeModulePkg and
mark it with the EDKII_ prefix. For my last “code first” UEFI spec
contribution I did this with the PPI that added up getting added.
The new audio protocol should be generic, only its implementation in
question should be virtio specific.

Please include Gerd Hoffmann (CC'd) in the protocol design, as well as
the developers of the virtio-sound device model in QEMU.

Thanks
Laszlo





Thanks,

Nate



*From: *<devel@edk2.groups.io <mailto:devel@edk2.groups.io>> on behalf
of "Andrew Fish via groups.io <http://groups.io/>"
<afish=apple.com@groups.io <mailto:apple.com@groups.io>>
*Reply-To: *"devel@edk2.groups.io <mailto:devel@edk2.groups.io>"
<devel@edk2.groups.io <mailto:devel@edk2.groups.io>>,
"afish@apple.com <mailto:afish@apple.com>" <afish@apple.com
<mailto:afish@apple.com>>
*Date: *Tuesday, March 30, 2021 at 10:54 PM
*To: *edk2-devel-groups-io <devel@edk2.groups.io
<mailto:devel@edk2.groups.io>>,
"harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>"
<harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
*Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>>
*Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)





On Mar 30, 2021, at 5:01 PM, Ethin Probst <harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
wrote:



I'm wondering where exactly I should add the VirtIO sound protocol.
I
just familiarized myself with the build system and am about to
test
it
by building OVMF if possible, but I'm wondering where I should
actually put the protocol and all that stuff. Maybe there's
documentation I've missed as well.



Ethin,



For the driver I’d match the patter of OVMF [1] and use
OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers as a
template.



The protocol is more of a public thing. I think eventually we would
like
to publish the protocol in the UEFI Spec (I can help with that part)
and
that would mean we put the Protocol definition in
MdePkg/Include/Protocol, but we don’t want to do that before it is
standardized as that causes compatibility issues. So this is a “code
first project” (code prototype and then contribute to the UEFI Forum
for
inclusion in the specification) so we need to follow some code first
rules that I don’t remember of the top of my head? So why not start
out
the protocol definition OvmfPkg/Include/Protocol. You can also add a
test application looks like you can just use the root [2] of OVMF for
that. That way the project is not blocked.



We can have a conversation on the mailing list about better places to
put stuff, and it should be easy enough to move stuff around if
everything else is working.



[1] find OvmfPkg -iname '*Virtio*.inf'

OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf

OvmfPkg/VirtioScsiDxe/VirtioScsi.inf

OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf

OvmfPkg/Library/VirtioLib/VirtioLib.inf

OvmfPkg/VirtioGpuDxe/VirtioGpu.inf

OvmfPkg/VirtioBlkDxe/VirtioBlk.inf

OvmfPkg/Virtio10Dxe/Virtio10.inf

OvmfPkg/VirtioNetDxe/VirtioNet.inf

OvmfPkg/VirtioRngDxe/VirtioRng.inf



[2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf |
grep MODULE_TYPE

EnrollDefaultKeys/EnrollDefaultKeys.inf:13: MODULE_TYPE
= UEFI_APPLICATION



Thanks,



Andrew Fish






On 3/30/21, Ethin Probst via groups.io <http://groups.io/>
<http://groups.io/ <http://groups.io/>>
<harlydavidsen=gmail.com@groups.io <mailto:gmail.com@groups.io>
<mailto:harlydavidsen <mailto:harlydavidsen>=gmail.com@groups.io
<mailto:gmail.com@groups.io>>> wrote:

I agree. Plus, it gives me a chance to finally learn the EDK2
build
system and how it works! I've been working on a hobby OS as a
side
project and, though learning from other code examples from
OSes
is
fun, I have to say that learning from the firmware code like
from
SeaBIOS has been some of the most enlightening and interesting
times
thus far.
Thanks for the link to your code, Rafael; once I get virtIO
support
in, I can work on HDA support, though I might tackle USB
support
second and HDA third. We'll see, but VirtIO definitely is
coming
first.

As I said before, I look forward to working with all of you
wonderful
people!

On 3/30/21, Rafael Rodrigues Machado
<rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>
<mailto:rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>>>
wrote:

This would be amazing so people can continue my work
related
to
accessibility at BIOS. Something desired by the blind
people
since the
90's
Just for reference, this is what I have done:


https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
<https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>

Thanks
Rafael

Em seg, 29 de mar de 2021 20:24, Ethin Probst
<harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
escreveu:


Hello everyone,

This is the first time I've ever contributed to EDK2.
As
part of GSoC
2021, I have submitted a proposal to implement a UEFI
audio output
protocol that will utilize the VirtIO sound driver.
I've
already
submitted a draft proposal, and apologize if I've done
things out of
order. This is my first time doing GSoC 2021, and
contributing to EDK2
felt like a really fun thing to do!

I look forward to working with you guys on this and
any
future projects!
:-)

--
Signed,
Ethin D. Probst









--
Signed,
Ethin D. Probst







--
Signed,
Ethin D. Probst






--
Signed,
Ethin D. Probst





--
Signed,
Ethin D. Probst


Re: [PATCH 1/5] ArmPkg: Allow platforms to override PCI supported state in SmbiosMiscDxe

Leif Lindholm
 

On Tue, Mar 30, 2021 at 20:16:15 -0600, Rebecca Cran wrote:
Not all platforms support PCI, so introduce a PCD to allow platforms to
specify whether they support it.
Are we planning to add one?
If not, I'd rather skip this until we do.
These days, I would expect any platform providing SMBIOS tables to
have PCI.

No further comments on this set.

/
Leif

Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
---
ArmPkg/ArmPkg.dec | 1 +
ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf | 1 +
ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c | 4 ++++
3 files changed, 6 insertions(+)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index a8a22c649ff8..51ac2191c85a 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -125,6 +125,7 @@ [PcdsFixedAtBuild.common]
#
# SMBIOS PCDs
#
+ gArmTokenSpaceGuid.PcdPlatformSupportsPCI|TRUE|BOOLEAN|0x30000052
gArmTokenSpaceGuid.PcdSystemProductName|L""|VOID*|0x30000053
gArmTokenSpaceGuid.PcdSystemVersion|L""|VOID*|0x30000054
gArmTokenSpaceGuid.PcdBaseBoardManufacturer|L""|VOID*|0x30000055
diff --git a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
index 60d8fe31c219..ebc4c99ac436 100644
--- a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
+++ b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
@@ -71,6 +71,7 @@ [Pcd]
gArmTokenSpaceGuid.PcdFdSize
gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVendor
gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString
+ gArmTokenSpaceGuid.PcdPlatformSupportsPCI
gArmTokenSpaceGuid.PcdSystemBiosRelease
gArmTokenSpaceGuid.PcdEmbeddedControllerFirmwareRelease
gArmTokenSpaceGuid.PcdSystemProductName
diff --git a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c
index 5aea32521bd3..a06f814aeb7c 100644
--- a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c
+++ b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c
@@ -13,6 +13,7 @@
#include <Library/DebugLib.h>
#include <Library/HiiLib.h>
#include <Library/MemoryAllocationLib.h>
+#include <Library/PcdLib.h>
#include <Library/PrintLib.h>
#include <Library/UefiBootServicesTableLib.h>

@@ -264,6 +265,9 @@ SMBIOS_MISC_TABLE_FUNCTION (MiscBiosVendor)
UnicodeStrToAsciiStrS (Version, StrStart, VerStrLen + 1);
StrStart += VerStrLen + 1;
UnicodeStrToAsciiStrS (ReleaseDate, StrStart, DateStrLen + 1);
+
+ SmbiosRecord->BiosCharacteristics.PciIsSupported = FixedPcdGetBool (PcdPlatformSupportsPCI);
+
//
// Now we have got the full smbios record, call smbios protocol to add this record.
//
--
2.26.2


Re: [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

Samer El-Haj-Mahmoud
 

I just got to this thread. Apologies for the delay.

 

I went through the ACPI spec. Here is what I see:

 

https://uefi.org/specs/ACPI/6.4/19_ASL_Reference/ACPI_Source_Language_Reference.html#qwordmemory-qword-memory-resource-descriptor-macro

 

ResourceUsage specifies whether the Memory range is consumed by this device (ResourceConsumer) or passed on to child devices (ResourceProducer). If nothing is specified, then ResourceConsumer is assumed.”
 
https://uefi.org/specs/ACPI/6.4/06_Device_Configuration/Device_Configuration.html#dma-direct-memory-access
 
“ It specifies the ranges the bus controller (bridge) decodes on the child-side of its interface. (This is analogous to the _CRS object, which describes the resources that the bus controller decodes on the parent-side of its interface.) Any ranges described in the resources of a _DMA object can be used by child devices for DMA or bus master transactions..”
 
The way I read the spec, this wording in the _DMA definition “Any ranges described in the resources of a _DMA object can be used by child devices..” suggests that this should be a ResourceProducer, per the QWordMemory resource descriptor definition above
 

The _DMA example in section 6.2.4 uses a “ResourceConsumer”, when it should really be “ResourceProducer” according to these definitions: It describes , the child devices view of the address range, so the "translation" added is the CPU's view of the same range.

 
I submitted a “code first” ECR to correct the ACPI spec example (here : https://bugzilla.tianocore.org/show_bug.cgi?id=3335). Please provide feedback on the BZ (or this thread) whether you agree or not, so we can take this to ASWG/UEFI Forum for discussion and approval
 
Thanks,
--Samer
 
 

 

From: Andrei Warkentin <awarkentin@...>
Sent: Thursday, April 8, 2021 10:24 AM
To: Jeremy Linton <Jeremy.Linton@...>; devel@edk2.groups.io
Cc: Ard Biesheuvel <Ard.Biesheuvel@...>; leif@...; pete@...; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
Subject: Re: [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

 

I don't know... the ACPI spec is weird.

 

 

...lists ResourceConsumer for _DMA.

 

A

 


From: Jeremy Linton <jeremy.linton@...>
Sent: Thursday, April 8, 2021 12:58 AM
To: devel@edk2.groups.io <devel@edk2.groups.io>
Cc: ard.biesheuvel@... <ard.biesheuvel@...>; leif@... <leif@...>; pete@... <pete@...>; samer.el-haj-mahmoud@... <samer.el-haj-mahmoud@...>; Andrei Warkentin <awarkentin@...>; Jeremy Linton <jeremy.linton@...>
Subject: [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

 

Bridge devices should be marked as producers so that their
children can consume the resources. In linux if this isn't
true then the translation gets ignored and the DMA values
are incorrect. This fixes DMA on all the devices that
need a translation.

Signed-off-by: Jeremy Linton <jeremy.linton@...>
---
 Platform/RaspberryPi/AcpiTables/Dsdt.asl | 2 +-
 Platform/RaspberryPi/AcpiTables/Emmc.asl | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
index d116f965e1..32cd5fc9f9 100644
--- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
+++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
@@ -205,7 +205,7 @@ DefinitionBlock ("Dsdt.aml", "DSDT", 5, "RPIFDN", "RPI", 2)
         // Only the first GB is available.

         // Bus 0xC0000000 -> CPU 0x00000000.

         //

-        QWordMemory (ResourceConsumer,

+        QWordMemory (ResourceProducer,

           ,

           MinFixed,

           MaxFixed,

diff --git a/Platform/RaspberryPi/AcpiTables/Emmc.asl b/Platform/RaspberryPi/AcpiTables/Emmc.asl
index 179dd3ecdb..0fbc2a79ea 100644
--- a/Platform/RaspberryPi/AcpiTables/Emmc.asl
+++ b/Platform/RaspberryPi/AcpiTables/Emmc.asl
@@ -32,7 +32,7 @@ DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN", "RPI4EMMC", 2)
       }

 

       Name (_DMA, ResourceTemplate() {

-        QWordMemory (ResourceConsumer,

+        QWordMemory (ResourceProducer,

           ,

           MinFixed,

           MaxFixed,

--
2.13.7

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: GCC49 DEBUG AARCH64 and ARM builds use -O0

Ard Biesheuvel
 

On Tue, 13 Apr 2021 at 14:12, Rebecca Cran <rebecca@nuviainc.com> wrote:

+Ard (with the correct email address)

On 4/13/21 4:32 AM, Laszlo Ersek wrote:
+Liming

On 04/12/21 17:10, Rebecca Cran wrote:
I noticed the GCC49 (and GCC48) AARCH64 and ARM DEBUG builds use -O0,
unlike IA32 and X64 platforms which build with -Os.

e.g. from
https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/tools_def.template
:

DEBUG_GCC49_AARCH64_CC_FLAGS = DEF(GCC49_AARCH64_CC_FLAGS) -O0

Is that deliberate, or should it be like X64 where DEBUG builds are
optimized and NOOPT is used when unoptimized binaries are needed?
Seems to go back to commit dafe0fedc508 ("BaseTools: Add GCC49
toolchain; align data sections to 0x40", 2014-07-28). My guess is that
in 2014, gcc (4.9) may have had issues with arm64 code generation with -Os.

You hint at DEBUG_GCC48_AARCH64_CC_FLAGS too, which seems like a
promising clue at first -- because, perhaps the GCC49 flags in the
above-mentioned commit had simply been modeled on the then-existent
GCC48 ones.

Unfortunately however, the GCC48 entry appeared in the
less-than-helpfully-explained commit 2bc3256ca6d4 ("Sync BaseTool trunk
(version r2640) into EDKII BaseTools.", 2014-01-10).

Thanks
Laszlo
IIRC we only added NOOPT for ARM much later, and at that time, we
decided to leave GCC49 alone.


Re: [PATCH 0/5] ArmPkg: OemMiscLib and Universal/Smbios improvements and fixes

Leif Lindholm
 

On Tue, Mar 30, 2021 at 20:16:14 -0600, Rebecca Cran wrote:
Add the set of improvements requested during the initial series to move
closer to a full/proper implementation, fix the
chassis SKU number string, and fix a typo in a comment.

This is a breaking change wrt SbsaQemu in edk2-platforms.
I can't find a corresponding patch for that.
Are you looking for the APIs in this set to stabilise first?

/
Leif

Rebecca Cran (5):
ArmPkg: Allow platforms to override PCI supported state in
SmbiosMiscDxe
ArmPkg: Allow platforms to supply more data for SMBIOS Type3 record
ArmPkg: Allow platforms to report their boot status via OemMiscLib
call
ArmPkg: Fix calculation of offset of chassis SKU Number in
SmbiosMiscDxe
ArmPkg: Fix typo of Manufacturer in comment in SmbiosMiscDxe

ArmPkg/ArmPkg.dec | 1 +
ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf | 1 +
ArmPkg/Include/Library/OemMiscLib.h | 70 ++++++++++++++
ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c | 99 ++++++++++++++++++++
ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c | 4 +
ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type03/MiscChassisManufacturerData.c | 2 +-
ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type03/MiscChassisManufacturerFunction.c | 20 +++-
ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type32/MiscBootInformationFunction.c | 3 +
8 files changed, 194 insertions(+), 6 deletions(-)

--
2.26.2


Re: [PATCH v3 00/10] Added support for FT2000/4 chip

Leif Lindholm
 

Hi Ling,

Many apologies.

Qualcomm's acquisition of NUVIA closed on 16 March, which caused a lot
of initial disruption. Then I took last week as holiday. I am back
now, and will start going through my review backlog.

Best Regards,

Leif

On Tue, Apr 13, 2021 at 10:35:09 +0800, 贾玲 wrote:
Hi Leif,

It's been a few days since I sent V3 patches. Do you have any suggestions for this patches? Looking forward to your reply!

Best Regards,

Ling
-----原始邮件-----
发件人: "Ling Jia" <jialing@phytium.com.cn>
发送时间: 2021-03-17 15:26:37 (星期三)
收件人: devel@edk2.groups.io
抄送: "Leif Lindholm" <leif@nuviainc.com>, "Ling Jia" <jialing@phytium.com.cn>
主题: [PATCH v3 00/10] Added support for FT2000/4 chip

This series added packages to support FT2000/4 chip.
Platform/Phytium: Added DurianPkg, include DurianPkg.dsc and DurianPkg.fdf.
Silicon/Phytium: Added FT2000-4Pkg and PhytiumCommonPkg.

The modules could be runed at the silicon of FT2000/4.
They supported Acpi parameter configuration, Pci bus scaning,
flash read-write and erase abd operating system boot function.
Maintainers.txt: Added maintainers and reviewers for the DurianPkg.

The public git repository is :
https://github.com/jialing2020/edk2-platforms/tree/Phytium_Opensource_For_FT2000-4_v3

v3:
Optimized the codes to meet the edk2 coding specification.

Ling Jia (10):
Silicon/Phytium: Added PlatformLib to FT2000/4
Silicon/Phytium: Added Acpi support to FT2000/4
Silicon/Phytium: Added SMBIOS support to FT2000/4
Silicon/Phytium: Added PciSegmentLib to FT2000/4
Silicon/Phytium: Added PciHostBridgeLib to FT2000/4
Silicon/Phytium: Added Spi driver support to FT2000/4
Silicon/Phytium: Added flash driver support to Phytium Silicon
Silicon/Phytium: Added fvb driver for norflash
Silicon/Phytium: Added Rtc driver to FT2000/4
Maintainers.txt: Added maintainers and reviewers for the DurianPkg

Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dec | 52 +
Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dsc.inc | 345 +++++
Platform/Phytium/DurianPkg/DurianPkg.dsc | 331 +++++
Platform/Phytium/DurianPkg/DurianPkg.fdf | 235 ++++
Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/AcpiTables.inf | 56 +
Silicon/Phytium/FT2000-4Pkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf | 47 +
Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.inf | 44 +
Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.inf | 48 +
Silicon/Phytium/FT2000-4Pkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf | 47 +
Silicon/Phytium/FT2000-4Pkg/Library/PciSegmentLib/PciSegmentLib.inf | 28 +
Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.inf | 55 +
Silicon/Phytium/FT2000-4Pkg/Library/RealTimeClockLib/RealTimeClockLib.inf | 39 +
Silicon/Phytium/PhytiumCommonPkg/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf | 53 +
Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.inf | 61 +
Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.h | 64 +
Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.h | 99 ++
Silicon/Phytium/FT2000-4Pkg/Library/RealTimeClockLib/RealTimeClockLib.h | 24 +
Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.h | 104 ++
Silicon/Phytium/PhytiumCommonPkg/Include/Platform.h | 80 ++
Silicon/Phytium/PhytiumCommonPkg/Include/Protocol/SpiNorFlashProtocol.h | 74 +
Silicon/Phytium/PhytiumCommonPkg/Include/Protocol/SpiProtocol.h | 51 +
Silicon/Phytium/PhytiumCommonPkg/Include/SystemServiceInterface.h | 112 ++
Silicon/Phytium/FT2000-4Pkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c | 943 +++++++++++++
Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.c | 198 +++
Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.c | 424 ++++++
Silicon/Phytium/FT2000-4Pkg/Library/PciHostBridgeLib/PciHostBridgeLib.c | 181 +++
Silicon/Phytium/FT2000-4Pkg/Library/PciSegmentLib/PciSegmentLib.c | 1434 ++++++++++++++++++++
Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.c | 137 ++
Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLibMem.c | 156 +++
Silicon/Phytium/FT2000-4Pkg/Library/RealTimeClockLib/RealTimeClockLib.c | 462 +++++++
Silicon/Phytium/PhytiumCommonPkg/Drivers/AcpiPlatformDxe/AcpiPlatform.c | 250 ++++
Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.c | 1304 ++++++++++++++++++
Maintainers.txt | 8 +
Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/AcpiSsdtRootPci.asl | 209 +++
Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Dbg2.aslc | 80 ++
Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Dsdt/Cpu.asl | 85 ++
Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Dsdt/Dsdt.asl | 15 +
Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Dsdt/Uart.asl | 65 +
Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Fadt.aslc | 77 ++
Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Gtdt.aslc | 83 ++
Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Iort.aslc | 89 ++
Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Madt.aslc | 67 +
Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Mcfg.aslc | 65 +
Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Pptt.aslc | 219 +++
Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Spcr.aslc | 73 +
Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/AArch64/PhytiumPlatformHelper.S | 76 ++
Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.fdf.inc | 119 ++
47 files changed, 8868 insertions(+)
create mode 100644 Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dec
create mode 100644 Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dsc.inc
create mode 100644 Platform/Phytium/DurianPkg/DurianPkg.dsc
create mode 100644 Platform/Phytium/DurianPkg/DurianPkg.fdf
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/AcpiTables.inf
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.inf
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.inf
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Library/PciSegmentLib/PciSegmentLib.inf
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.inf
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Library/RealTimeClockLib/RealTimeClockLib.inf
create mode 100644 Silicon/Phytium/PhytiumCommonPkg/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf
create mode 100644 Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.inf
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.h
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.h
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Library/RealTimeClockLib/RealTimeClockLib.h
create mode 100644 Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.h
create mode 100644 Silicon/Phytium/PhytiumCommonPkg/Include/Platform.h
create mode 100644 Silicon/Phytium/PhytiumCommonPkg/Include/Protocol/SpiNorFlashProtocol.h
create mode 100644 Silicon/Phytium/PhytiumCommonPkg/Include/Protocol/SpiProtocol.h
create mode 100644 Silicon/Phytium/PhytiumCommonPkg/Include/SystemServiceInterface.h
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.c
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.c
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Library/PciHostBridgeLib/PciHostBridgeLib.c
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Library/PciSegmentLib/PciSegmentLib.c
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.c
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLibMem.c
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Library/RealTimeClockLib/RealTimeClockLib.c
create mode 100644 Silicon/Phytium/PhytiumCommonPkg/Drivers/AcpiPlatformDxe/AcpiPlatform.c
create mode 100644 Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.c
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/AcpiSsdtRootPci.asl
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Dbg2.aslc
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Dsdt/Cpu.asl
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Dsdt/Dsdt.asl
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Dsdt/Uart.asl
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Fadt.aslc
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Gtdt.aslc
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Iort.aslc
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Madt.aslc
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Mcfg.aslc
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Pptt.aslc
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Spcr.aslc
create mode 100644 Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/AArch64/PhytiumPlatformHelper.S
create mode 100644 Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.fdf.inc

--
2.25.1



10041 - 10060 of 84037