1. devel@edk2.groups.io
  2. Messages
   Date   
Re: [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

Daniel Schaefer
 

Hi Leif,

you're right. If I revert my commit and include
  NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
without making any changes to it, the build succeeds.

What do others think? (cc Michael, Pete, Andrew, Ard, who have made changes to this module)
Is this a big hack or should we use it in RISC-V, too and move the module to MdeModulePkg?
Why isn't this a problem on x86? Was it fine on Itanium?

- Daniel

From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Leif Lindholm <leif@...>

Sent: Thursday, March 12, 2020 11:55
To: devel@edk2.groups.io <devel@edk2.groups.io>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Chen, Gilbert <gilbert.chen@...>; Dandan Bi <dandan.bi@...>; Eric Dong <eric.dong@...>
Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment
 
Hi Daniel,

There is nothing wrong with this patch that just went in (and I should
have called out sooner if I wanted to stop it), but I think a better
solution is to implement a RISC-V variant of
ArmPkg/Library/CompilerIntrinsicsLib/.

It is perfectly valid for the compiler to generate memcpy calls in
response to struct operations that are perfectly valid C.

In fact, we could consider moving the ArmPkg one over into
MdeModulePkg. I have a feeling that including a
  NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
in your current build would be an alternative solution to your
compilation error.

/
    Leif

On Mon, Mar 02, 2020 at 11:32:38 +0100, Daniel Schaefer wrote:
> GCC translates a simple assignment to memcpy, which EDKII doesn't provide.
> See: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mail-2Darchive.com_edk2-2Ddevel-40lists.01.org_msg11928.html&d=DwIBAg&c=C5b8zRQO1miGmBeVZ2LFWg&r=wVtkBG7Yvxr1ZwGC2X-DFznM8iUD7og3137fRa2yRiU&m=OH3BPEpUySzO08XGI-6pvl4Uo-7mUgOsaf-jKHSCoJM&s=pUtOxfKtpYxlYwtDHP8hhRZ8QJ52whxSqi285877XsM&e=
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2547
>
> Signed-off-by: Daniel Schaefer <daniel.schaefer@...>
> Cc: Abner Chang <abner.chang@...>
> Cc: Gilbert Chen <gilbert.chen@...>
> Cc: Leif Lindholm <leif@...>
> Cc: Dandan Bi <dandan.bi@...>
> Cc: Eric Dong <eric.dong@...>
> ---
>
> Notes:
>     v2:
>       - Use CopyMem instead of CopyGuid [Dandan]
>
>  MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> index 5cc527679a78..0540e6fa8a44 100644
> --- a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> +++ b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> @@ -619,7 +619,7 @@ CreateDeviceManagerForm(
>          TokenHelp = HiiSetString (HiiHandle, 0, String, NULL);
>          FreePool (String);
> 
> -        FormSetGuid = ((EFI_IFR_FORM_SET *)Ptr)->Guid;
> +        CopyMem (&FormSetGuid, &((EFI_IFR_FORM_SET *) Ptr)->Guid, sizeof (EFI_GUID));
> 
>          //
>          // Network device process
> --
> 2.25.0
>
>
>
>



Re: [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

Ni, Ray
 

Leif,
Does CompilerIntrinsicsLib exist because GCC doesn't support to disable intrinsic?
How does the linker find the CompilerInstrinsicsLib in linking phase?

Thanks,
Ray

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Leif
Lindholm
Sent: Thursday, March 12, 2020 6:55 PM
To: devel@edk2.groups.io; daniel.schaefer@...
Cc: Abner Chang <abner.chang@...>; Gilbert Chen
<gilbert.chen@...>; Bi, Dandan <dandan.bi@...>; Dong, Eric
<eric.dong@...>
Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem
instead of GUID assignment

Hi Daniel,

There is nothing wrong with this patch that just went in (and I should
have called out sooner if I wanted to stop it), but I think a better
solution is to implement a RISC-V variant of
ArmPkg/Library/CompilerIntrinsicsLib/.

It is perfectly valid for the compiler to generate memcpy calls in
response to struct operations that are perfectly valid C.

In fact, we could consider moving the ArmPkg one over into
MdeModulePkg. I have a feeling that including a
NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
in your current build would be an alternative solution to your
compilation error.

/
Leif

On Mon, Mar 02, 2020 at 11:32:38 +0100, Daniel Schaefer wrote:
GCC translates a simple assignment to memcpy, which EDKII doesn't
provide.
See: https://www.mail-archive.com/edk2-
devel@.../msg11928.html

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

Signed-off-by: Daniel Schaefer <daniel.schaefer@...>
Cc: Abner Chang <abner.chang@...>
Cc: Gilbert Chen <gilbert.chen@...>
Cc: Leif Lindholm <leif@...>
Cc: Dandan Bi <dandan.bi@...>
Cc: Eric Dong <eric.dong@...>
---

Notes:
v2:
- Use CopyMem instead of CopyGuid [Dandan]

MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
index 5cc527679a78..0540e6fa8a44 100644
--- a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
+++ b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
@@ -619,7 +619,7 @@ CreateDeviceManagerForm(
TokenHelp = HiiSetString (HiiHandle, 0, String, NULL);
FreePool (String);

- FormSetGuid = ((EFI_IFR_FORM_SET *)Ptr)->Guid;
+ CopyMem (&FormSetGuid, &((EFI_IFR_FORM_SET *) Ptr)->Guid,
sizeof (EFI_GUID));

//
// Network device process
--
2.25.0
Re: [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

Leif Lindholm
 

Hi Daniel,

There is nothing wrong with this patch that just went in (and I should
have called out sooner if I wanted to stop it), but I think a better
solution is to implement a RISC-V variant of
ArmPkg/Library/CompilerIntrinsicsLib/.

It is perfectly valid for the compiler to generate memcpy calls in
response to struct operations that are perfectly valid C.

In fact, we could consider moving the ArmPkg one over into
MdeModulePkg. I have a feeling that including a
NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
in your current build would be an alternative solution to your
compilation error.

/
Leif

On Mon, Mar 02, 2020 at 11:32:38 +0100, Daniel Schaefer wrote:
GCC translates a simple assignment to memcpy, which EDKII doesn't provide.
See: https://www.mail-archive.com/edk2-devel@lists.01.org/msg11928.html

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

Signed-off-by: Daniel Schaefer <daniel.schaefer@...>
Cc: Abner Chang <abner.chang@...>
Cc: Gilbert Chen <gilbert.chen@...>
Cc: Leif Lindholm <leif@...>
Cc: Dandan Bi <dandan.bi@...>
Cc: Eric Dong <eric.dong@...>
---

Notes:
v2:
- Use CopyMem instead of CopyGuid [Dandan]

MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
index 5cc527679a78..0540e6fa8a44 100644
--- a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
+++ b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
@@ -619,7 +619,7 @@ CreateDeviceManagerForm(
TokenHelp = HiiSetString (HiiHandle, 0, String, NULL);
FreePool (String);

- FormSetGuid = ((EFI_IFR_FORM_SET *)Ptr)->Guid;
+ CopyMem (&FormSetGuid, &((EFI_IFR_FORM_SET *) Ptr)->Guid, sizeof (EFI_GUID));

//
// Network device process
--
2.25.0
Re: [PATCH 5/5] OvmfPkg: improve SMM comms security with adaptive MemoryTypeInformation

Leif Lindholm
 

On Thu, Mar 12, 2020 at 01:30:10 +0100, Laszlo Ersek wrote:
On 03/11/20 20:36, Leif Lindholm wrote:
On Wed, Mar 11, 2020 at 17:22:47 +0100, Laszlo Ersek wrote:
+STATIC EFI_MEMORY_TYPE_INFORMATION mDefaultMemoryTypeInformation[] = {
+ { EfiACPIMemoryNVS, 0x004 },
+ { EfiACPIReclaimMemory, 0x008 },
+ { EfiReservedMemoryType, 0x004 },
+ { EfiRuntimeServicesData, 0x024 },
+ { EfiRuntimeServicesCode, 0x030 },
+ { EfiBootServicesCode, 0x180 },
+ { EfiBootServicesData, 0xF00 },
+ { EfiMaxMemoryType, 0x000 }
+};
Could you add a comment as to where these page counts come from?
Oh, right, they're just moved across from OvmfPkg/PlatformPei/Platform.c.

It *would* be nice if that could be cleaned up at the same time...
Sorry, I don't understand -- what kind of cleanup do you have in mind
precisely? The table is not copied, but moved from the original place,
so I'm unsure what's left in "Platform.c" to clean up.
Not left to clean up there, but something to consider addressing when
moving it here. Yes, it's just a move, so we could argue it doesn't
need fixing - but it's a struct with a bunch of live-coded numerical
values completely without explanation.

"I'd rather not" is an acceptable answer, but I figured I should point
it out.
Good point!

Yet, I'd rather not :) Long read ahead:

This table is used for priming the memory type BINs in the DXE Core.
After this set, in non-SMM builds, the functionality will remain the
same (the table stays in effect for every boot); in SMM builds, the
table is only a starting point for the feedback loop.

What's important is that the numbers in the table are entirely ad-hoc.
They were last updated in commit 991d95636264, in 2010. They capture a
set of BIN hints that made sense at the time, for *some* (now unknown)
workloads / boot paths. That's the important trait of this table: it
made sense at some point in time, for some use case. That's the property
we should not regress.

So let's consider the possible ways to improve the table.
There is fixing and there is improving.

The preceding paragraph as a comment block would prevent the next
person who comes across it going "Where the $EXPLETIVE did these
numbers come from?".

(Adding the preceding paragraph as well would have saved me another
minute of grepping, but that is more down to the fact that this is a
repeating pattern implemented differently for different platforms -
for most ARM platforms partly hidden away in EmbeddedPkg:
https://github.com/tianocore/edk2/blob/master/EmbeddedPkg/EmbeddedPkg.dec#L104)

(1) Given that in SMM builds, the table will function only as a starting
point for the feedback loop, start using two tables. A new one (for the
SMM build) with nice numbers (everything 0x1, or everyting 0x1000,
whatever), and keep the old one for the non-SMM build.

Unfortunately, this "improvement" is a net negative, because then we'd
have *more* stuff, on top of the *current* dump-of-obscure-numbers.

(2) Keep the one table, but replace the values with nicer looking
numbers (see examples above). Unfortunately, larger numbers could waste
memory (stuck in BINs and hence in the UEFI memmap) for some boots, and
smaller page counts would increase memmap fragmentation.

We might cause some (at best, superficial) regressions. And we'd lose
the property "this table made sense at some point in time" -- because
the new ad-hoc numbers wouldn't even be rooted in measurements.

(3) Actually measure various boots and try to derive new page counts
from those.

This is something I'm not prepared to do. The memory needs (considering
the various memory types too), depend on a bunch of stuff:

- ACPI tables generated by QEMU (influences AcpiNVS, AcpiReclaim, and
even Reserved -- some opcodes in QEMU's ACPI linker/loader script
require the production of S3 boot script opcodes). For example if the
QEMU command line specifies the vmgenid device, then the S3 boot script
stuff applies.

- S3 support enabled/disabled in general on the QEMU cmdline.

- OS bootloader footprint.
- Separately loaded drivers (including Option ROMs?), making these
numers impossible to precisely determine statically.

This approach would uphold the property "has been useful at some point
in time, for some workloads" -- but it's too much time to research, and
it's anyway obviated by the dynamic / adaptive approach that this series
enables for OVMF (in the SMM build).

(4) OK, so let's not touch the numeric values, but move them out of the
table?

(4a) Introduce macros.

Not a good idea, as these numbers are never referenced anywhere else.
The following:

#define MTI_RT_DATA_PAGE_COUNT 0x024
...
{ EfiRuntimeServicesData, MTI_RT_DATA_PAGE_COUNT },

is not one bit more readable or expressive, but is more wasteful, than
the current

{ EfiRuntimeServicesData, 0x024 },

(4b) Introduce PCDs.

Even worse: it elevates these ad-hoc numbers to the OvmfPkg.dec file,
without any plan or intent whatsoever to ever update the constants, or
to reference them in any other modules, or to override them in any of
the locations where PCDs can be overridden (DSC file, FDF file, and for
dynamic access PCDs: C code).
See EmbeddedPkg.

Basically, all of the variants you enumerate exist in the tree(s)
today.

These numbers are basically a state-dump from a time when they had been
found somewhat useful. They still work acceptably, and without an
interest in (3), I wouldn't like to touch them with a ten foot pole. :)
Sure.

So what I'm *actually* after is.

(5) *Somehow* standardise how platforms build up the HOB

I think this means *hiding* BuildGuidDataHob() behind some
higher-level functions, backed by some market-segment (or
market-segment:architecture tuple) specific defaults.


But for this patch, if you could add the archaeology bit in a comment
block, I think that would be useful for whatever next lost soul
stumbles upon it.

With or without that, for the series:
Acked-by: Leif Lindholm <leif@...>
Re: [patch v2] OvmfPkg: Fix build failure with VS2015 tool chain

Laszlo Ersek
 

Hello Liming,

(adding Michael)

On 03/12/20 05:30, Liming Gao wrote:
warning C4244: '=': conversion from 'UINTN' to 'UINT32', possible loss of data
With this fix, OvmfIa32, OvmfX64 and OvmfIa32X64 can pass build.

Cc: Laszlo Ersek <lersek@...>
Cc: Ard Biesheuvel <ard.biesheuvel@...>
Signed-off-by: Liming Gao <liming.gao@...>
---
OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c b/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c
index 1868c9fcaf..1f02da2503 100644
--- a/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c
+++ b/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c
@@ -384,7 +384,7 @@ QemuLoadKernelImage (
//
// Drop the terminating NUL, convert to UTF-16.
//
- KernelLoadedImage->LoadOptionsSize = (CommandLineSize - 1) * 2;
+ KernelLoadedImage->LoadOptionsSize = (UINT32) ((CommandLineSize - 1) * 2);
}

QemuFwCfgSelectItem (QemuFwCfgItemInitrdSize);
This patch seems to be fixing the pre-existent TianoCore ticket

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

Can you please coordinate with Michael?

BTW, I prefer this patch to the one that Michael attached to the ticket
in <https://bugzilla.tianocore.org/show_bug.cgi?id=2582#c3>.

So my suggestion is for Liming to reassign the BZ to himself please,
reference the BZ in the commit message, and then merge this patch.

Reviewed-by: Laszlo Ersek <lersek@...>

Thanks,
Laszlo
Re: [edk2/master PATCH RISC-V CI Code Changes v1 01/11] FatPkg: Add RISC-V architecture for EDK2 CI.

Ni, Ray
 

Reviewed-by: Ray Ni <ray.ni@...>

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Abner Chang
Sent: Friday, March 6, 2020 1:36 PM
To: devel@edk2.groups.io
Cc: abner.chang@...; Ni, Ray <ray.ni@...>; Leif Lindholm <leif@...>; Gilbert Chen
<gilbert.chen@...>; Daniel Schaefer <daniel.schaefer@...>
Subject: [edk2-devel] [edk2/master PATCH RISC-V CI Code Changes v1 01/11] FatPkg: Add RISC-V architecture for EDK2 CI.

BZ:2562:
https://bugzilla.tianocore.org/show_bug.cgi?id=2562

Add RISC-V architecture for EDK2 CI testing.

Signed-off-by: Abner Chang <abner.chang@...>

Cc: Ray Ni <ray.ni@...>
Cc: Leif Lindholm <leif@...>
Cc: Gilbert Chen <gilbert.chen@...>
Cc: Daniel Schaefer <daniel.schaefer@...>
---
FatPkg/FatPkg.dsc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/FatPkg/FatPkg.dsc b/FatPkg/FatPkg.dsc
index 1676c2eb8f..d86256068b 100644
--- a/FatPkg/FatPkg.dsc
+++ b/FatPkg/FatPkg.dsc
@@ -4,6 +4,7 @@
# This Platform file is used to generate the Binary Fat Drivers

# for EDK II Prime release.

# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.<BR>

+# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights reserved.<BR>

#

# SPDX-License-Identifier: BSD-2-Clause-Patent

#

@@ -14,7 +15,7 @@
PLATFORM_GUID = 25b55dbc-9d0b-4a32-80da-46e1273d622c

PLATFORM_VERSION = 0.3

DSC_SPECIFICATION = 0x00010005

- SUPPORTED_ARCHITECTURES = IA32|X64|EBC|ARM|AARCH64

+ SUPPORTED_ARCHITECTURES = IA32|X64|EBC|ARM|AARCH64|RISCV64

OUTPUT_DIRECTORY = Build/Fat

BUILD_TARGETS = DEBUG|RELEASE|NOOPT

SKUID_IDENTIFIER = DEFAULT

--
2.25.0


-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55584): https://edk2.groups.io/g/devel/message/55584
Mute This Topic: https://groups.io/mt/71767323/1712937
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [ray.ni@...]
-=-=-=-=-=-=
Re: [edk2/master PATCH RISC-V CI Code Changes v1 01/11] FatPkg: Add RISC-V architecture for EDK2 CI.

Liming Gao
 

Edk2 spec are listed in https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Specifications

This change requires to update INF/DEC/DSC/FDF/Build spec. You can find their github repo in the above link. Then, create git patch for the change.

Thanks
Liming

-----Original Message-----
From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Sent: 2020年3月12日 14:27
To: devel@edk2.groups.io; Ni, Ray <ray.ni@...>; Gao, Liming <liming.gao@...>; Kinney, Michael D <michael.d.kinney@...>
Cc: Leif Lindholm <leif@...>; Chen, Gilbert <gilbert.chen@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>
Subject: RE: [edk2-devel] [edk2/master PATCH RISC-V CI Code Changes v1 01/11] FatPkg: Add RISC-V architecture for EDK2 CI.



-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
Ni, Ray
Sent: Thursday, March 12, 2020 1:40 PM
To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
<abner.chang@...>; Gao, Liming <liming.gao@...>; Kinney,
Michael D <michael.d.kinney@...>
Cc: Leif Lindholm <leif@...>; Chen, Gilbert
<gilbert.chen@...>; Schaefer, Daniel (DualStudy)
<daniel.schaefer@...>
Subject: Re: [edk2-devel] [edk2/master PATCH RISC-V CI Code Changes v1
01/11] FatPkg: Add RISC-V architecture for EDK2 CI.

Abner,
Has the change to BaseTools supporting new ARCH been merged?
No, not yet. The whole changes to RISCV64 ARCH is in the separate huge set of patches. We have three sets of RISC-V edk2 port.

1. Patches for RISC-V EDK2 CI enablement 2. Patches for edk2 modules other than RISC-V ones, which fix the issues for building packages respectively on RISC-V arch.
3 . RISC-V edk2 port

The patch needs your Reviewed-by is belong to #2. We can have a PR for #3 and trigger CI testing once #1 and #2 are merged to master.


Liming, Mike,
Does INF specification need to be updated for this new ARCH?
Good question, how to submit the changes to these specs?


Thanks,
Ray

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Abner
Chang
Sent: Friday, March 6, 2020 1:36 PM
To: devel@edk2.groups.io
Cc: abner.chang@...; Ni, Ray <ray.ni@...>; Leif Lindholm
<leif@...>; Gilbert Chen <gilbert.chen@...>; Daniel
Schaefer <daniel.schaefer@...>
Subject: [edk2-devel] [edk2/master PATCH RISC-V CI Code Changes v1
01/11] FatPkg: Add RISC-V architecture for EDK2 CI.

BZ:2562:
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.tianoc
or
e.org_show-5Fbug.cgi-3Fid-
3D2562&d=DwIFAg&c=C5b8zRQO1miGmBeVZ2LFWg&r=_
SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E&m=hdx0AmnugjVyUKB
Egf8jkKDBs
rX81gAFwMi_pmEH2-
g&s=7pymX9FxJA5arZHTI9zd_qr3b2Jk2tx3OVff9UkxoW4&e=

Add RISC-V architecture for EDK2 CI testing.

Signed-off-by: Abner Chang <abner.chang@...>

Cc: Ray Ni <ray.ni@...>
Cc: Leif Lindholm <leif@...>
Cc: Gilbert Chen <gilbert.chen@...>
Cc: Daniel Schaefer <daniel.schaefer@...>
---
FatPkg/FatPkg.dsc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/FatPkg/FatPkg.dsc b/FatPkg/FatPkg.dsc index
1676c2eb8f..d86256068b 100644
--- a/FatPkg/FatPkg.dsc
+++ b/FatPkg/FatPkg.dsc
@@ -4,6 +4,7 @@
# This Platform file is used to generate the Binary Fat Drivers

# for EDK II Prime release.

# Copyright (c) 2007 - 2018, Intel Corporation. All rights
reserved.<BR>

+# Copyright (c) 2020, Hewlett Packard Enterprise Development LP.
+All rights reserved.<BR>

#

# SPDX-License-Identifier: BSD-2-Clause-Patent

#

@@ -14,7 +15,7 @@
PLATFORM_GUID = 25b55dbc-9d0b-4a32-80da-46e1273d622c

PLATFORM_VERSION = 0.3

DSC_SPECIFICATION = 0x00010005

- SUPPORTED_ARCHITECTURES = IA32|X64|EBC|ARM|AARCH64

+ SUPPORTED_ARCHITECTURES =
IA32|X64|EBC|ARM|AARCH64|RISCV64

OUTPUT_DIRECTORY = Build/Fat

BUILD_TARGETS = DEBUG|RELEASE|NOOPT

SKUID_IDENTIFIER = DEFAULT

--
2.25.0


-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55584):
https://urldefense.proofpoint.com/v2/url?u=https-
3A__edk2.groups.io_g_
devel_message_55584&d=DwIFAg&c=C5b8zRQO1miGmBeVZ2LFWg&r=_SN
6FZBN4Vgi4U
lkskz6qU3NYRO03nHp9P7Z5q59A3E&m=hdx0AmnugjVyUKBEgf8jkKDBsrX81g
AFwMi_pm
EH2-g&s=WRly7Kh6eK9ppe59UcH-U5xBt7Lsp2K38n1jfPO1mKg&e=
Mute This Topic:
https://urldefense.proofpoint.com/v2/url?u=https-
3A__groups.io_mt_7176
7323_1712937&d=DwIFAg&c=C5b8zRQO1miGmBeVZ2LFWg&r=_SN6FZBN4V
gi4Ulkskz6q
U3NYRO03nHp9P7Z5q59A3E&m=hdx0AmnugjVyUKBEgf8jkKDBsrX81gAFwMi
_pmEH2-g&s
=wuAcZWk-ZDd7lyPIz4_Ph3LwBqgNanz3lag5-evIjns&e=
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-
3A__edk2.groups.io_g_devel_unsub&d=DwIFAg&c=C5b8zRQO1miGmBeVZ2
LFWg&r=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E&m=hdx0Amn
ugjVyUKBEgf8jkKDBsrX81gAFwMi_pmEH2-g&s=dAyFUfd07U1tFQRk-
aK_WytEXVsMhZszgAPW8IoXljA&e= [ray.ni@...]
-=-=-=-=-=-=
Re: [edk2/master PATCH RISC-V CI Code Changes v1 01/11] FatPkg: Add RISC-V architecture for EDK2 CI.

Abner Chang
 

-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Ni,
Ray
Sent: Thursday, March 12, 2020 1:40 PM
To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
<abner.chang@...>; Gao, Liming <liming.gao@...>; Kinney,
Michael D <michael.d.kinney@...>
Cc: Leif Lindholm <leif@...>; Chen, Gilbert
<gilbert.chen@...>; Schaefer, Daniel (DualStudy)
<daniel.schaefer@...>
Subject: Re: [edk2-devel] [edk2/master PATCH RISC-V CI Code Changes v1
01/11] FatPkg: Add RISC-V architecture for EDK2 CI.

Abner,
Has the change to BaseTools supporting new ARCH been merged?
No, not yet. The whole changes to RISCV64 ARCH is in the separate huge set of patches. We have three sets of RISC-V edk2 port.

1. Patches for RISC-V EDK2 CI enablement
2. Patches for edk2 modules other than RISC-V ones, which fix the issues for building packages respectively on RISC-V arch.
3 . RISC-V edk2 port

The patch needs your Reviewed-by is belong to #2. We can have a PR for #3 and trigger CI testing once #1 and #2 are merged to master.


Liming, Mike,
Does INF specification need to be updated for this new ARCH?
Good question, how to submit the changes to these specs?


Thanks,
Ray

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Abner
Chang
Sent: Friday, March 6, 2020 1:36 PM
To: devel@edk2.groups.io
Cc: abner.chang@...; Ni, Ray <ray.ni@...>; Leif Lindholm
<leif@...>; Gilbert Chen <gilbert.chen@...>; Daniel
Schaefer <daniel.schaefer@...>
Subject: [edk2-devel] [edk2/master PATCH RISC-V CI Code Changes v1
01/11] FatPkg: Add RISC-V architecture for EDK2 CI.

BZ:2562:
INVALID URI REMOVED
e.org_show-5Fbug.cgi-3Fid-
3D2562&d=DwIFAg&c=C5b8zRQO1miGmBeVZ2LFWg&r=_
SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E&m=hdx0AmnugjVyUKB
Egf8jkKDBs
rX81gAFwMi_pmEH2-
g&s=7pymX9FxJA5arZHTI9zd_qr3b2Jk2tx3OVff9UkxoW4&e=

Add RISC-V architecture for EDK2 CI testing.

Signed-off-by: Abner Chang <abner.chang@...>

Cc: Ray Ni <ray.ni@...>
Cc: Leif Lindholm <leif@...>
Cc: Gilbert Chen <gilbert.chen@...>
Cc: Daniel Schaefer <daniel.schaefer@...>
---
FatPkg/FatPkg.dsc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/FatPkg/FatPkg.dsc b/FatPkg/FatPkg.dsc index
1676c2eb8f..d86256068b 100644
--- a/FatPkg/FatPkg.dsc
+++ b/FatPkg/FatPkg.dsc
@@ -4,6 +4,7 @@
# This Platform file is used to generate the Binary Fat Drivers

# for EDK II Prime release.

# Copyright (c) 2007 - 2018, Intel Corporation. All rights
reserved.<BR>

+# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All
+rights reserved.<BR>

#

# SPDX-License-Identifier: BSD-2-Clause-Patent

#

@@ -14,7 +15,7 @@
PLATFORM_GUID = 25b55dbc-9d0b-4a32-80da-46e1273d622c

PLATFORM_VERSION = 0.3

DSC_SPECIFICATION = 0x00010005

- SUPPORTED_ARCHITECTURES = IA32|X64|EBC|ARM|AARCH64

+ SUPPORTED_ARCHITECTURES =
IA32|X64|EBC|ARM|AARCH64|RISCV64

OUTPUT_DIRECTORY = Build/Fat

BUILD_TARGETS = DEBUG|RELEASE|NOOPT

SKUID_IDENTIFIER = DEFAULT

--
2.25.0


-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55584):
INVALID URI REMOVED
3A__edk2.groups.io_g_
devel_message_55584&d=DwIFAg&c=C5b8zRQO1miGmBeVZ2LFWg&r=_SN
6FZBN4Vgi4U
lkskz6qU3NYRO03nHp9P7Z5q59A3E&m=hdx0AmnugjVyUKBEgf8jkKDBsrX81g
AFwMi_pm
EH2-g&s=WRly7Kh6eK9ppe59UcH-U5xBt7Lsp2K38n1jfPO1mKg&e=
Mute This Topic:
INVALID URI REMOVED
3A__groups.io_mt_7176
7323_1712937&d=DwIFAg&c=C5b8zRQO1miGmBeVZ2LFWg&r=_SN6FZBN4V
gi4Ulkskz6q
U3NYRO03nHp9P7Z5q59A3E&m=hdx0AmnugjVyUKBEgf8jkKDBsrX81gAFwMi
_pmEH2-g&s
=wuAcZWk-ZDd7lyPIz4_Ph3LwBqgNanz3lag5-evIjns&e=
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: INVALID URI REMOVED
3A__edk2.groups.io_g_devel_unsub&d=DwIFAg&c=C5b8zRQO1miGmBeVZ2
LFWg&r=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E&m=hdx0Amn
ugjVyUKBEgf8jkKDBsrX81gAFwMi_pmEH2-g&s=dAyFUfd07U1tFQRk-
aK_WytEXVsMhZszgAPW8IoXljA&e= [ray.ni@...]
-=-=-=-=-=-=
Re: [PATCH v2] UnitTestFrameworkPkg/UnitTestLib: Check Suite pointer before use.

Zhang, Shenglei
 

Reviewed-by: Shenglei Zhang <shenglei.zhang@...>

-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
GuoMinJ
Sent: Thursday, March 5, 2020 2:18 PM
To: devel@edk2.groups.io
Cc: GuoMinJ <newexplorerj@...>; Kinney, Michael D
<michael.d.kinney@...>; Sean Brogan <sean.brogan@...>;
Bret Barkelew <Bret.Barkelew@...>
Subject: [edk2-devel] [PATCH v2] UnitTestFrameworkPkg/UnitTestLib: Check
Suite pointer before use.

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

The Suite pointer is used before check if it is valid,
correct it to check the validation before use.

Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Sean Brogan <sean.brogan@...>
Cc: Bret Barkelew <Bret.Barkelew@...>
Signed-off-by: GuoMinJ <newexplorerj@...>
---
UnitTestFrameworkPkg/Library/UnitTestLib/RunTests.c | 6 +++---
UnitTestFrameworkPkg/Library/UnitTestLib/UnitTestLib.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/UnitTestFrameworkPkg/Library/UnitTestLib/RunTests.c
b/UnitTestFrameworkPkg/Library/UnitTestLib/RunTests.c
index fb247c59e7..b053e04959 100644
--- a/UnitTestFrameworkPkg/Library/UnitTestLib/RunTests.c
+++ b/UnitTestFrameworkPkg/Library/UnitTestLib/RunTests.c
@@ -33,13 +33,13 @@ RunTestSuite (
UNIT_TEST *Test;
UNIT_TEST_FRAMEWORK *ParentFramework;

- TestEntry = NULL;
- ParentFramework = (UNIT_TEST_FRAMEWORK *)Suite->ParentFramework;
-
if (Suite == NULL) {
return EFI_INVALID_PARAMETER;
}

+ TestEntry = NULL;
+ ParentFramework = (UNIT_TEST_FRAMEWORK *)Suite-
ParentFramework;
+
DEBUG ((DEBUG_VERBOSE, "--------------------------------------------------------
-\n"));
DEBUG ((DEBUG_VERBOSE, "RUNNING TEST SUITE: %a\n", Suite->Title));
DEBUG ((DEBUG_VERBOSE, "--------------------------------------------------------
-\n"));
diff --git a/UnitTestFrameworkPkg/Library/UnitTestLib/UnitTestLib.c
b/UnitTestFrameworkPkg/Library/UnitTestLib/UnitTestLib.c
index fd15991ea4..b136992d99 100644
--- a/UnitTestFrameworkPkg/Library/UnitTestLib/UnitTestLib.c
+++ b/UnitTestFrameworkPkg/Library/UnitTestLib/UnitTestLib.c
@@ -436,7 +436,6 @@ AddTestCase (

Status = EFI_SUCCESS;
Suite = (UNIT_TEST_SUITE *)SuiteHandle;
- ParentFramework = (UNIT_TEST_FRAMEWORK *)Suite->ParentFramework;

//
// First, let's check to make sure that our parameters look good.
@@ -445,6 +444,7 @@ AddTestCase (
return EFI_INVALID_PARAMETER;
}

+ ParentFramework = (UNIT_TEST_FRAMEWORK *)Suite-
ParentFramework;
//
// Create the new entry.
NewTestEntry = AllocateZeroPool (sizeof( UNIT_TEST_LIST_ENTRY ));
--
2.17.1
Re: [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

Abner Chang
 

Appreciated, Jian J.

From: Wang, Jian J <jian.j.wang@...>
Sent: Thursday, March 12, 2020 1:58:05 PM
To: devel@edk2.groups.io <devel@edk2.groups.io>; Bi, Dandan <dandan.bi@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Chen, Gilbert <gilbert.chen@...>; Leif Lindholm <leif@...>; Dong, Eric <eric.dong@...>
Subject: RE: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment
 
Pushed @ 64a228f5f89320fd632bb6c55e154961f2410680

Regards,
Jian

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Dandan Bi
> Sent: Thursday, March 05, 2020 8:40 AM
> To: Daniel Schaefer <daniel.schaefer@...>; devel@edk2.groups.io
> Cc: Abner Chang <abner.chang@...>; Gilbert Chen
> <gilbert.chen@...>; Leif Lindholm <leif@...>; Dong, Eric
> <eric.dong@...>
> Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem
> instead of GUID assignment
>
> Reviewed-by: Dandan Bi <dandan.bi@...>
>
>
> Thanks,
> Dandan
> > -----Original Message-----
> > From: Daniel Schaefer [mailto:daniel.schaefer@...]
> > Sent: Monday, March 2, 2020 6:33 PM
> > To: devel@edk2.groups.io
> > Cc: Abner Chang <abner.chang@...>; Gilbert Chen
> > <gilbert.chen@...>; Leif Lindholm <leif@...>; Bi, Dandan
> > <dandan.bi@...>; Dong, Eric <eric.dong@...>
> > Subject: [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID
> > assignment
> >
> > GCC translates a simple assignment to memcpy, which EDKII doesn't provide.
> > See: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mail-2Darchive.com_edk2-2Ddevel-40lists.01.org_msg11928.html&d=DwIFAg&c=C5b8zRQO1miGmBeVZ2LFWg&r=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E&m=qsK4hsWLOpM-1nZt2HfGb1E4kXmVxp4jkftrFuHTN28&s=ZonntN3tqpPe93R8wS97gWaVOO-PKkJxBK02ksvSU6Y&e=
> >
> > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2547
> >
> > Signed-off-by: Daniel Schaefer <daniel.schaefer@...>
> > Cc: Abner Chang <abner.chang@...>
> > Cc: Gilbert Chen <gilbert.chen@...>
> > Cc: Leif Lindholm <leif@...>
> > Cc: Dandan Bi <dandan.bi@...>
> > Cc: Eric Dong <eric.dong@...>
> > ---
> >
> > Notes:
> >     v2:
> >       - Use CopyMem instead of CopyGuid [Dandan]
> >
> >  MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> > b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> > index 5cc527679a78..0540e6fa8a44 100644
> > --- a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> > +++ b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> > @@ -619,7 +619,7 @@ CreateDeviceManagerForm(
> >          TokenHelp = HiiSetString (HiiHandle, 0, String, NULL);
> >
> >          FreePool (String);
> >
> >
> >
> > -        FormSetGuid = ((EFI_IFR_FORM_SET *)Ptr)->Guid;
> >
> > +        CopyMem (&FormSetGuid, &((EFI_IFR_FORM_SET *) Ptr)->Guid, sizeof
> > (EFI_GUID));
> >
> >
> >
> >          //
> >
> >          // Network device process
> >
> > --
> > 2.25.0
>
>
>

Re: [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

Wang, Jian J
 

Pushed @ 64a228f5f89320fd632bb6c55e154961f2410680

Regards,
Jian

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Dandan Bi
Sent: Thursday, March 05, 2020 8:40 AM
To: Daniel Schaefer <daniel.schaefer@...>; devel@edk2.groups.io
Cc: Abner Chang <abner.chang@...>; Gilbert Chen
<gilbert.chen@...>; Leif Lindholm <leif@...>; Dong, Eric
<eric.dong@...>
Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem
instead of GUID assignment

Reviewed-by: Dandan Bi <dandan.bi@...>


Thanks,
Dandan
-----Original Message-----
From: Daniel Schaefer [mailto:daniel.schaefer@...]
Sent: Monday, March 2, 2020 6:33 PM
To: devel@edk2.groups.io
Cc: Abner Chang <abner.chang@...>; Gilbert Chen
<gilbert.chen@...>; Leif Lindholm <leif@...>; Bi, Dandan
<dandan.bi@...>; Dong, Eric <eric.dong@...>
Subject: [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID
assignment

GCC translates a simple assignment to memcpy, which EDKII doesn't provide.
See: https://www.mail-archive.com/edk2-devel@lists.01.org/msg11928.html

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

Signed-off-by: Daniel Schaefer <daniel.schaefer@...>
Cc: Abner Chang <abner.chang@...>
Cc: Gilbert Chen <gilbert.chen@...>
Cc: Leif Lindholm <leif@...>
Cc: Dandan Bi <dandan.bi@...>
Cc: Eric Dong <eric.dong@...>
---

Notes:
v2:
- Use CopyMem instead of CopyGuid [Dandan]

MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
index 5cc527679a78..0540e6fa8a44 100644
--- a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
+++ b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
@@ -619,7 +619,7 @@ CreateDeviceManagerForm(
TokenHelp = HiiSetString (HiiHandle, 0, String, NULL);

FreePool (String);



- FormSetGuid = ((EFI_IFR_FORM_SET *)Ptr)->Guid;

+ CopyMem (&FormSetGuid, &((EFI_IFR_FORM_SET *) Ptr)->Guid, sizeof
(EFI_GUID));



//

// Network device process

--
2.25.0
Re: [PATCH v2 1/2] CryptoPkg/BaseCryptLibOnProtocolPpi: Add missing comments

Zhang, Shenglei
 

Reviewed-by: Shenglei Zhang <shenglei.zhang@...>

-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
GuoMinJ
Sent: Thursday, March 5, 2020 2:41 PM
To: devel@edk2.groups.io
Cc: GuoMinJ <newexplorerj@...>; Wang, Jian J
<jian.j.wang@...>; Lu, XiaoyuX <xiaoyux.lu@...>
Subject: [edk2-devel] [PATCH v2 1/2] CryptoPkg/BaseCryptLibOnProtocolPpi:
Add missing comments

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

DxeCryptLibConstructor have no comments for it, add comments for it.

Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyux.lu@...>
Signed-off-by: GuoMinJ <newexplorerj@...>
---
.../Library/BaseCryptLibOnProtocolPpi/DxeCryptLib.c | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/CryptoPkg/Library/BaseCryptLibOnProtocolPpi/DxeCryptLib.c
b/CryptoPkg/Library/BaseCryptLibOnProtocolPpi/DxeCryptLib.c
index 34d5f410b0..b503a5708b 100644
--- a/CryptoPkg/Library/BaseCryptLibOnProtocolPpi/DxeCryptLib.c
+++ b/CryptoPkg/Library/BaseCryptLibOnProtocolPpi/DxeCryptLib.c
@@ -32,6 +32,15 @@ GetCryptoServices (
return (VOID *)mCryptoProtocol;
}

+/**
+ Locate the valid Crypto Protocol.
+
+ @param ImageHandle The firmware allocated handle for the EFI image.
+ @param SystemTable A pointer to the EFI System Table.
+
+ @retval EFI_SUCCESS The constructor executed correctly.
+ @retval EFI_NOT_FOUND Found no valid Crypto Protocol.
+**/
EFI_STATUS
EFIAPI
DxeCryptLibConstructor (
--
2.17.1
Re: [PATCH v2 2/2] CryptoPkg/BaseHashApiLib: Rename BaseHashApiLib by HashApiLib

Zhang, Shenglei
 

Reviewed-by: Shenglei Zhang <shenglei.zhang@...>

-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
GuoMinJ
Sent: Thursday, March 5, 2020 2:41 PM
To: devel@edk2.groups.io
Cc: GuoMinJ <newexplorerj@...>; Wang, Jian J
<jian.j.wang@...>; Lu, XiaoyuX <xiaoyux.lu@...>
Subject: [edk2-devel] [PATCH v2 2/2] CryptoPkg/BaseHashApiLib: Rename
BaseHashApiLib by HashApiLib

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

According to CryptoPkg.dsc, the library class only have HashApiLib, so i
think the BaseHashApiLib should be considered as base name rather than
library class.

Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyux.lu@...>
Signed-off-by: GuoMinJ <newexplorerj@...>
---
CryptoPkg/Library/BaseHashApiLib/BaseHashApiLib.inf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CryptoPkg/Library/BaseHashApiLib/BaseHashApiLib.inf
b/CryptoPkg/Library/BaseHashApiLib/BaseHashApiLib.inf
index b4d8675ddd..046320353b 100644
--- a/CryptoPkg/Library/BaseHashApiLib/BaseHashApiLib.inf
+++ b/CryptoPkg/Library/BaseHashApiLib/BaseHashApiLib.inf
@@ -17,7 +17,7 @@
FILE_GUID = B1E566DD-DE7C-4F04-BDA0-B1295D3BE927
MODULE_TYPE = BASE
VERSION_STRING = 1.0
- LIBRARY_CLASS = BaseHashApiLib
+ LIBRARY_CLASS = HashApiLib

#
# The following information is for reference only and not required by the
build tools.
--
2.17.1
[PATCH 3/3] SecurityPkg: add null version of VariableKeyLib

Wang, Jian J
 

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

Add null version of VariableKeyLib instance. The full version should be
provided by platforms which supports key generator.

Cc: Jiewen Yao <jiewen.yao@...>
Cc: Chao Zhang <chao.b.zhang@...>
Cc: Nishant C Mistry <nishant.c.mistry@...>
Signed-off-by: Jian J Wang <jian.j.wang@...>
---
.../VariableKeyLibNull/VariableKeyLibNull.c | 67 +++++++++++++++++++
.../VariableKeyLibNull/VariableKeyLibNull.inf | 33 +++++++++
SecurityPkg/SecurityPkg.dsc | 2 +
3 files changed, 102 insertions(+)
create mode 100644 SecurityPkg/Library/VariableKeyLibNull/VariableKeyLibNu=
ll.c
create mode 100644 SecurityPkg/Library/VariableKeyLibNull/VariableKeyLibNu=
ll.inf

diff --git a/SecurityPkg/Library/VariableKeyLibNull/VariableKeyLibNull.c b/=
SecurityPkg/Library/VariableKeyLibNull/VariableKeyLibNull.c
new file mode 100644
index 0000000000..2ef6a68ea0
--- /dev/null
+++ b/SecurityPkg/Library/VariableKeyLibNull/VariableKeyLibNull.c
@@ -0,0 +1,67 @@
+/** @file=0D
+ Null version of VariableKeyLib for build purpose. Don't use it in real p=
roduct.=0D
+=0D
+Copyright (c) 2020, Intel Corporation. All rights reserved.<BR>=0D
+SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+=0D
+**/=0D
+#include <Library/DebugLib.h>=0D
+#include <Library/VariableKeyLib.h>=0D
+=0D
+/**=0D
+ Retrieves the variable root key.=0D
+=0D
+ @param[out] VariableRootKey A pointer to pointer for the var=
iable root key buffer.=0D
+ @param[in,out] VariableRootKeySize The size in bytes of the variabl=
e root key.=0D
+=0D
+ @retval EFI_SUCCESS The variable root key was returned=
.=0D
+ @retval EFI_DEVICE_ERROR An error occurred while attempting=
to get the variable root key.=0D
+ @retval EFI_ACCESS_DENIED The function was invoked after loc=
king the key interface.=0D
+ @retval EFI_UNSUPPORTED The variable root key is not suppo=
rted in the current boot configuration.=0D
+**/=0D
+EFI_STATUS=0D
+EFIAPI=0D
+GetVariableRootKey (=0D
+ OUT VOID **VariableRootKey,=0D
+ IN OUT UINTN *VariableRootKeySize=0D
+ )=0D
+{=0D
+ ASSERT (FALSE);=0D
+ return EFI_UNSUPPORTED;=0D
+}=0D
+=0D
+/**=0D
+ Regenerates the variable root key.=0D
+=0D
+ @retval EFI_SUCCESS The variable root key was regenera=
ted successfully.=0D
+ @retval EFI_DEVICE_ERROR An error occurred while attempting=
to regenerate the root key.=0D
+ @retval EFI_ACCESS_DENIED The function was invoked after loc=
king the key interface.=0D
+ @retval EFI_UNSUPPORTED Key regeneration is not supported =
in the current boot configuration.=0D
+**/=0D
+EFI_STATUS=0D
+EFIAPI=0D
+RegenerateKey (=0D
+ VOID=0D
+ )=0D
+{=0D
+ ASSERT (FALSE);=0D
+ return EFI_UNSUPPORTED;=0D
+}=0D
+=0D
+/**=0D
+ Locks the regenerate key interface.=0D
+=0D
+ @retval EFI_SUCCESS The key interface was locked succe=
ssfully.=0D
+ @retval EFI_UNSUPPORTED Locking the key interface is not s=
upported in the current boot configuration.=0D
+ @retval Others An error occurred while attempting=
to lock the key interface.=0D
+**/=0D
+EFI_STATUS=0D
+EFIAPI=0D
+LockKeyInterface (=0D
+ VOID=0D
+ )=0D
+{=0D
+ ASSERT (FALSE);=0D
+ return EFI_UNSUPPORTED;=0D
+}=0D
+=0D
diff --git a/SecurityPkg/Library/VariableKeyLibNull/VariableKeyLibNull.inf =
b/SecurityPkg/Library/VariableKeyLibNull/VariableKeyLibNull.inf
new file mode 100644
index 0000000000..ea74e38cf9
--- /dev/null
+++ b/SecurityPkg/Library/VariableKeyLibNull/VariableKeyLibNull.inf
@@ -0,0 +1,33 @@
+## @file=0D
+# Provides Null version of VariableKeyLib for build only.=0D
+#=0D
+# Copyright (c) 2020, Intel Corporation. All rights reserved.<BR>=0D
+# SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+#=0D
+##=0D
+=0D
+[Defines]=0D
+ INF_VERSION =3D 0x00010029=0D
+ BASE_NAME =3D VariableKeyLibNull=0D
+ FILE_GUID =3D 2B640ED8-1E6A-4516-9F1D-25910E59BC4A=
=0D
+ MODULE_TYPE =3D BASE=0D
+ VERSION_STRING =3D 1.0=0D
+ LIBRARY_CLASS =3D VariableKeyLib=0D
+=0D
+#=0D
+# The following information is for reference only and not required by the =
build tools.=0D
+#=0D
+# VALID_ARCHITECTURES =3D IA32 X64 Arm AArch64=0D
+#=0D
+=0D
+[Sources]=0D
+ VariableKeyLibNull.c=0D
+=0D
+[Packages]=0D
+ MdePkg/MdePkg.dec=0D
+ SecurityPkg/SecurityPkg.dec=0D
+=0D
+[LibraryClasses]=0D
+ BaseLib=0D
+ DebugLib=0D
+=0D
diff --git a/SecurityPkg/SecurityPkg.dsc b/SecurityPkg/SecurityPkg.dsc
index 97e0e7ed6e..4b85f77b02 100644
--- a/SecurityPkg/SecurityPkg.dsc
+++ b/SecurityPkg/SecurityPkg.dsc
@@ -64,6 +64,7 @@
TcgStorageCoreLib|SecurityPkg/Library/TcgStorageCoreLib/TcgStorageCoreLi=
b.inf=0D
TcgStorageOpalLib|SecurityPkg/Library/TcgStorageOpalLib/TcgStorageOpalLi=
b.inf=0D
ResetSystemLib|MdeModulePkg/Library/BaseResetSystemLibNull/BaseResetSyst=
emLibNull.inf=0D
+ VariableKeyLib|SecurityPkg/Library/VariableKeyLibNull/VariableKeyLibNull=
.inf=0D
RpmcLib|SecurityPkg/Library/RpmcLibNull/RpmcLibNull.inf=0D
=0D
[LibraryClasses.ARM]=0D
@@ -221,6 +222,7 @@
#=0D
# Variable Confidentiality & Integrity=0D
#=0D
+ SecurityPkg/Library/VariableKeyLibNull/VariableKeyLibNull.inf=0D
SecurityPkg/Library/RpmcLibNull/RpmcLibNull.inf=0D
=0D
#=0D
--=20
2.24.0.windows.2
[PATCH 2/3] SecurityPkg: add null version of RpmcLib

Wang, Jian J
 

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

Add null version of RpmcLib instance. The full version should be provided
by platform which supports RPMC device.

Cc: Jiewen Yao <jiewen.yao@...>
Cc: Chao Zhang <chao.b.zhang@...>
Cc: Nishant C Mistry <nishant.c.mistry@...>
Signed-off-by: Jian J Wang <jian.j.wang@...>
---
SecurityPkg/Library/RpmcLibNull/RpmcLibNull.c | 55 +++++++++++++++++++
.../Library/RpmcLibNull/RpmcLibNull.inf | 33 +++++++++++
SecurityPkg/SecurityPkg.dsc | 6 ++
3 files changed, 94 insertions(+)
create mode 100644 SecurityPkg/Library/RpmcLibNull/RpmcLibNull.c
create mode 100644 SecurityPkg/Library/RpmcLibNull/RpmcLibNull.inf

diff --git a/SecurityPkg/Library/RpmcLibNull/RpmcLibNull.c b/SecurityPkg/Li=
brary/RpmcLibNull/RpmcLibNull.c
new file mode 100644
index 0000000000..586590c65f
--- /dev/null
+++ b/SecurityPkg/Library/RpmcLibNull/RpmcLibNull.c
@@ -0,0 +1,55 @@
+/** @file=0D
+ NULL RpmcLib instance for build purpose.=0D
+=0D
+Copyright (c) 2020, Intel Corporation. All rights reserved.<BR>=0D
+SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+=0D
+**/=0D
+=0D
+#include <Library/DebugLib.h>=0D
+#include <Library/RpmcLib.h>=0D
+=0D
+/**=0D
+ Requests the current monotonic counter from the designated RPMC counter.=
=0D
+=0D
+ @param[in] CounterIndex The RPMC index.=0D
+ @param[out] CounterValue A pointer to a buffer to store the=
RPMC value.=0D
+=0D
+ @retval EFI_SUCCESS The operation completed successful=
ly.=0D
+ @retval EFI_INVALID_PARAMETER The CounterValue pointer is NULL o=
r CounterIndex is invalid.=0D
+ @retval EFI_NOT_READY The given RPMC at CounterIndex is =
not yet initialized.=0D
+ @retval EFI_DEVICE_ERROR A device error occurred while atte=
mpting to update the counter.=0D
+ @retval EFI_UNSUPPORTED Requesting the monotonic counter i=
s not supported in the current boot configuration.=0D
+**/=0D
+EFI_STATUS=0D
+EFIAPI=0D
+RequestMonotonicCounter (=0D
+ IN UINT8 CounterIndex,=0D
+ OUT UINT32 *CounterValue=0D
+ )=0D
+{=0D
+ ASSERT (FALSE);=0D
+ return EFI_UNSUPPORTED;=0D
+}=0D
+=0D
+/**=0D
+ Increments the designated monotonic counter in the SPI flash device by 1=
.=0D
+=0D
+ @param[in] CounterIndex The RPMC index.=0D
+=0D
+ @retval EFI_SUCCESS The operation completed successful=
ly.=0D
+ @retval EFI_INVALID_PARAMETER The given CounterIndex value is in=
valid.=0D
+ @retval EFI_NOT_READY The given RPMC at CounterIndex is =
not yet initialized.=0D
+ @retval EFI_DEVICE_ERROR A device error occurred while atte=
mpting to update the counter.=0D
+ @retval EFI_UNSUPPORTED Incrementing the monotonic counter=
is not supported in the current boot configuration.=0D
+**/=0D
+EFI_STATUS=0D
+EFIAPI=0D
+IncrementMonotonicCounter (=0D
+ IN UINT8 CounterIndex=0D
+ )=0D
+{=0D
+ ASSERT (FALSE);=0D
+ return EFI_UNSUPPORTED;=0D
+}=0D
+=0D
diff --git a/SecurityPkg/Library/RpmcLibNull/RpmcLibNull.inf b/SecurityPkg/=
Library/RpmcLibNull/RpmcLibNull.inf
new file mode 100644
index 0000000000..500edfa87d
--- /dev/null
+++ b/SecurityPkg/Library/RpmcLibNull/RpmcLibNull.inf
@@ -0,0 +1,33 @@
+## @file=0D
+# Provides Null version of RpmcLib for build purpose.=0D
+#=0D
+# Copyright (c) 2020, Intel Corporation. All rights reserved.<BR>=0D
+# SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+#=0D
+##=0D
+=0D
+[Defines]=0D
+ INF_VERSION =3D 0x00010029=0D
+ BASE_NAME =3D RpmcLibNull=0D
+ FILE_GUID =3D FAE0BA22-92E2-4334-8F0F-96AFF9BAE360=
=0D
+ MODULE_TYPE =3D BASE=0D
+ VERSION_STRING =3D 1.0=0D
+ LIBRARY_CLASS =3D RpmcLib=0D
+=0D
+#=0D
+# The following information is for reference only and not required by the =
build tools.=0D
+#=0D
+# VALID_ARCHITECTURES =3D IA32 X64 Arm AArch64=0D
+#=0D
+=0D
+[Sources]=0D
+ RpmcLibNull.c=0D
+=0D
+[Packages]=0D
+ MdePkg/MdePkg.dec=0D
+ SecurityPkg/SecurityPkg.dec=0D
+=0D
+[LibraryClasses]=0D
+ BaseLib=0D
+ DebugLib=0D
+=0D
diff --git a/SecurityPkg/SecurityPkg.dsc b/SecurityPkg/SecurityPkg.dsc
index a2eeadda7a..97e0e7ed6e 100644
--- a/SecurityPkg/SecurityPkg.dsc
+++ b/SecurityPkg/SecurityPkg.dsc
@@ -64,6 +64,7 @@
TcgStorageCoreLib|SecurityPkg/Library/TcgStorageCoreLib/TcgStorageCoreLi=
b.inf=0D
TcgStorageOpalLib|SecurityPkg/Library/TcgStorageOpalLib/TcgStorageOpalLi=
b.inf=0D
ResetSystemLib|MdeModulePkg/Library/BaseResetSystemLibNull/BaseResetSyst=
emLibNull.inf=0D
+ RpmcLib|SecurityPkg/Library/RpmcLibNull/RpmcLibNull.inf=0D
=0D
[LibraryClasses.ARM]=0D
#=0D
@@ -217,6 +218,11 @@
SecurityPkg/Library/TcgStorageCoreLib/TcgStorageCoreLib.inf=0D
SecurityPkg/Library/TcgStorageOpalLib/TcgStorageOpalLib.inf=0D
=0D
+ #=0D
+ # Variable Confidentiality & Integrity=0D
+ #=0D
+ SecurityPkg/Library/RpmcLibNull/RpmcLibNull.inf=0D
+=0D
#=0D
# Other=0D
#=0D
--=20
2.24.0.windows.2
[PATCH 1/3] SecurityPkg: add RpmcLib and VariableKeyLib public headers

Wang, Jian J
 

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

RpmcLib.h and VariableKeyLib.h are header files required to access RPMC
device and Key generator from platform. They will be used to ensure the
integrity and confidentiality of NV variables.

Cc: Jiewen Yao <jiewen.yao@...>
Cc: Chao Zhang <chao.b.zhang@...>
Cc: Nishant C Mistry <nishant.c.mistry@...>
Signed-off-by: Jian J Wang <jian.j.wang@...>
---
SecurityPkg/Include/Library/RpmcLib.h | 50 +++++++++++++++++
SecurityPkg/Include/Library/VariableKeyLib.h | 59 ++++++++++++++++++++
SecurityPkg/SecurityPkg.dec | 8 +++
3 files changed, 117 insertions(+)
create mode 100644 SecurityPkg/Include/Library/RpmcLib.h
create mode 100644 SecurityPkg/Include/Library/VariableKeyLib.h

diff --git a/SecurityPkg/Include/Library/RpmcLib.h b/SecurityPkg/Include/Li=
brary/RpmcLib.h
new file mode 100644
index 0000000000..c2e7d12f43
--- /dev/null
+++ b/SecurityPkg/Include/Library/RpmcLib.h
@@ -0,0 +1,50 @@
+/** @file=0D
+ Public definitions for the Replay Protected Monotonic Counter (RPMC) Lib=
rary.=0D
+=0D
+Copyright (c) 2020, Intel Corporation. All rights reserved.<BR>=0D
+SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+=0D
+**/=0D
+=0D
+#ifndef _RPMC_LIB_H_=0D
+#define _RPMC_LIB_H_=0D
+=0D
+#include <Uefi/UefiBaseType.h>=0D
+=0D
+/**=0D
+ Requests the current monotonic counter from the designated RPMC counter.=
=0D
+=0D
+ @param[in] CounterIndex The RPMC index.=0D
+ @param[out] CounterValue A pointer to a buffer to store the=
RPMC value.=0D
+=0D
+ @retval EFI_SUCCESS The operation completed successful=
ly.=0D
+ @retval EFI_INVALID_PARAMETER The CounterValue pointer is is NUL=
L or CounterIndex is invalid.=0D
+ @retval EFI_NOT_READY The given RPMC at CounterIndex is =
not yet initialized.=0D
+ @retval EFI_DEVICE_ERROR A device error occurred while atte=
mpting to update the counter.=0D
+ @retval EFI_UNSUPPORTED Requesting the monotonic counter i=
s not supported in the current boot configuration.=0D
+**/=0D
+EFI_STATUS=0D
+EFIAPI=0D
+RequestMonotonicCounter (=0D
+ IN UINT8 CounterIndex,=0D
+ OUT UINT32 *CounterValue=0D
+ );=0D
+=0D
+/**=0D
+ Increments the designated monotonic counter in the SPI flash device by 1=
.=0D
+=0D
+ @param[in] CounterIndex The RPMC index.=0D
+=0D
+ @retval EFI_SUCCESS The operation completed successful=
ly.=0D
+ @retval EFI_INVALID_PARAMETER The given CounterIndex value is in=
valid.=0D
+ @retval EFI_NOT_READY The given RPMC at CounterIndex is =
not yet initialized.=0D
+ @retval EFI_DEVICE_ERROR A device error occurred while atte=
mpting to update the counter.=0D
+ @retval EFI_UNSUPPORTED Incrementing the monotonic counter=
is not supported in the current boot configuration.=0D
+**/=0D
+EFI_STATUS=0D
+EFIAPI=0D
+IncrementMonotonicCounter (=0D
+ IN UINT8 CounterIndex=0D
+ );=0D
+=0D
+#endif
\ No newline at end of file
diff --git a/SecurityPkg/Include/Library/VariableKeyLib.h b/SecurityPkg/Inc=
lude/Library/VariableKeyLib.h
new file mode 100644
index 0000000000..fe642b3d66
--- /dev/null
+++ b/SecurityPkg/Include/Library/VariableKeyLib.h
@@ -0,0 +1,59 @@
+/** @file=0D
+ Public definitions for Variable Key Library.=0D
+=0D
+Copyright (c) 2020, Intel Corporation. All rights reserved.<BR>=0D
+SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+=0D
+**/=0D
+=0D
+#ifndef _VARIABLE_KEY_LIB_H_=0D
+#define _VARIABLE_KEY_LIB_H_=0D
+=0D
+#include <Uefi/UefiBaseType.h>=0D
+=0D
+/**=0D
+ Retrieves the variable root key.=0D
+=0D
+ @param[out] VariableRootKey A pointer to pointer for the var=
iable root key buffer.=0D
+ @param[in,out] VariableRootKeySize The size in bytes of the variabl=
e root key.=0D
+=0D
+ @retval EFI_SUCCESS The variable root key was returned=
.=0D
+ @retval EFI_DEVICE_ERROR An error occurred while attempting=
to get the variable root key.=0D
+ @retval EFI_ACCESS_DENIED The function was invoked after loc=
king the key interface.=0D
+ @retval EFI_UNSUPPORTED The variable root key is not suppo=
rted in the current boot configuration.=0D
+**/=0D
+EFI_STATUS=0D
+EFIAPI=0D
+GetVariableRootKey (=0D
+ OUT VOID **VariableRootKey,=0D
+ IN OUT UINTN *VariableRootKeySize=0D
+ );=0D
+=0D
+/**=0D
+ Regenerates the variable root key.=0D
+=0D
+ @retval EFI_SUCCESS The variable root key was regenera=
ted successfully.=0D
+ @retval EFI_DEVICE_ERROR An error occurred while attempting=
to regenerate the root key.=0D
+ @retval EFI_ACCESS_DENIED The function was invoked after loc=
king the key interface.=0D
+ @retval EFI_UNSUPPORTED Key regeneration is not supported =
in the current boot configuration.=0D
+**/=0D
+EFI_STATUS=0D
+EFIAPI=0D
+RegenerateKey (=0D
+ VOID=0D
+ );=0D
+=0D
+/**=0D
+ Locks the regenerate key interface.=0D
+=0D
+ @retval EFI_SUCCESS The key interface was locked succe=
ssfully.=0D
+ @retval EFI_UNSUPPORTED Locking the key interface is not s=
upported in the current boot configuration.=0D
+ @retval Others An error occurred while attempting=
to lock the key interface.=0D
+**/=0D
+EFI_STATUS=0D
+EFIAPI=0D
+LockKeyInterface (=0D
+ VOID=0D
+ );=0D
+=0D
+#endif
\ No newline at end of file
diff --git a/SecurityPkg/SecurityPkg.dec b/SecurityPkg/SecurityPkg.dec
index 5335cc5397..2cdfb02cc5 100644
--- a/SecurityPkg/SecurityPkg.dec
+++ b/SecurityPkg/SecurityPkg.dec
@@ -76,6 +76,14 @@
#=0D
TcgStorageOpalLib|Include/Library/TcgStorageOpalLib.h=0D
=0D
+ ## @libraryclass Provides interfaces to access RPMC device.=0D
+ #=0D
+ RpmcLib|Include/Library/RpmcLib.h=0D
+=0D
+ ## @libraryclass Provides interfaces to access variable root key.=0D
+ #=0D
+ VariableKeyLib|Include/Library/VariableKeyLib.h=0D
+=0D
[Guids]=0D
## Security package token space guid.=0D
# Include/Guid/SecurityPkgTokenSpace.h=0D
--=20
2.24.0.windows.2
[PATCH 0/3] Add RpmcLib and VariableKeyLib

Wang, Jian J
 

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D2594=0D
Patch branch: https://github.com/jwang36/edk2/tree/bz2594-part1-common-inte=
rfaces-between-platform-and-edk2
=0D
Cc: Jiewen Yao <jiewen.yao@...>=0D
Cc: Chao Zhang <chao.b.zhang@...>=0D
Cc: Nishant C Mistry <nishant.c.mistry@...>=0D

Jian J Wang (3):
SecurityPkg: add RpmcLib and VariableKeyLib public headers
SecurityPkg: add null version of RpmcLib
SecurityPkg: add null version of VariableKeyLib

SecurityPkg/Include/Library/RpmcLib.h | 50 ++++++++++++++
SecurityPkg/Include/Library/VariableKeyLib.h | 59 ++++++++++++++++
SecurityPkg/Library/RpmcLibNull/RpmcLibNull.c | 55 +++++++++++++++
.../Library/RpmcLibNull/RpmcLibNull.inf | 33 +++++++++
.../VariableKeyLibNull/VariableKeyLibNull.c | 67 +++++++++++++++++++
.../VariableKeyLibNull/VariableKeyLibNull.inf | 33 +++++++++
SecurityPkg/SecurityPkg.dec | 8 +++
SecurityPkg/SecurityPkg.dsc | 8 +++
8 files changed, 313 insertions(+)
create mode 100644 SecurityPkg/Include/Library/RpmcLib.h
create mode 100644 SecurityPkg/Include/Library/VariableKeyLib.h
create mode 100644 SecurityPkg/Library/RpmcLibNull/RpmcLibNull.c
create mode 100644 SecurityPkg/Library/RpmcLibNull/RpmcLibNull.inf
create mode 100644 SecurityPkg/Library/VariableKeyLibNull/VariableKeyLibNu=
ll.c
create mode 100644 SecurityPkg/Library/VariableKeyLibNull/VariableKeyLibNu=
ll.inf

--=20
2.24.0.windows.2
Re: [edk2/master PATCH RISC-V CI Code Changes v1 01/11] FatPkg: Add RISC-V architecture for EDK2 CI.

Ni, Ray
 

Abner,
Has the change to BaseTools supporting new ARCH been merged?

Liming, Mike,
Does INF specification need to be updated for this new ARCH?

Thanks,
Ray

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Abner Chang
Sent: Friday, March 6, 2020 1:36 PM
To: devel@edk2.groups.io
Cc: abner.chang@...; Ni, Ray <ray.ni@...>; Leif Lindholm <leif@...>; Gilbert Chen
<gilbert.chen@...>; Daniel Schaefer <daniel.schaefer@...>
Subject: [edk2-devel] [edk2/master PATCH RISC-V CI Code Changes v1 01/11] FatPkg: Add RISC-V architecture for EDK2 CI.

BZ:2562:
https://bugzilla.tianocore.org/show_bug.cgi?id=2562

Add RISC-V architecture for EDK2 CI testing.

Signed-off-by: Abner Chang <abner.chang@...>

Cc: Ray Ni <ray.ni@...>
Cc: Leif Lindholm <leif@...>
Cc: Gilbert Chen <gilbert.chen@...>
Cc: Daniel Schaefer <daniel.schaefer@...>
---
FatPkg/FatPkg.dsc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/FatPkg/FatPkg.dsc b/FatPkg/FatPkg.dsc
index 1676c2eb8f..d86256068b 100644
--- a/FatPkg/FatPkg.dsc
+++ b/FatPkg/FatPkg.dsc
@@ -4,6 +4,7 @@
# This Platform file is used to generate the Binary Fat Drivers

# for EDK II Prime release.

# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.<BR>

+# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights reserved.<BR>

#

# SPDX-License-Identifier: BSD-2-Clause-Patent

#

@@ -14,7 +15,7 @@
PLATFORM_GUID = 25b55dbc-9d0b-4a32-80da-46e1273d622c

PLATFORM_VERSION = 0.3

DSC_SPECIFICATION = 0x00010005

- SUPPORTED_ARCHITECTURES = IA32|X64|EBC|ARM|AARCH64

+ SUPPORTED_ARCHITECTURES = IA32|X64|EBC|ARM|AARCH64|RISCV64

OUTPUT_DIRECTORY = Build/Fat

BUILD_TARGETS = DEBUG|RELEASE|NOOPT

SKUID_IDENTIFIER = DEFAULT

--
2.25.0


-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55584): https://edk2.groups.io/g/devel/message/55584
Mute This Topic: https://groups.io/mt/71767323/1712937
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [ray.ni@...]
-=-=-=-=-=-=
[patch v2] OvmfPkg: Fix build failure with VS2015 tool chain

Liming Gao
 

warning C4244: '=': conversion from 'UINTN' to 'UINT32', possible loss of data
With this fix, OvmfIa32, OvmfX64 and OvmfIa32X64 can pass build.

Cc: Laszlo Ersek <lersek@...>
Cc: Ard Biesheuvel <ard.biesheuvel@...>
Signed-off-by: Liming Gao <liming.gao@...>
---
OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c b/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c
index 1868c9fcaf..1f02da2503 100644
--- a/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c
+++ b/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c
@@ -384,7 +384,7 @@ QemuLoadKernelImage (
//
// Drop the terminating NUL, convert to UTF-16.
//
- KernelLoadedImage->LoadOptionsSize = (CommandLineSize - 1) * 2;
+ KernelLoadedImage->LoadOptionsSize = (UINT32) ((CommandLineSize - 1) * 2);
}

QemuFwCfgSelectItem (QemuFwCfgItemInitrdSize);
--
2.13.0.windows.1
Re: [PATCH v2 0/2] Use submodule way to access brotli

Bob Feng
 

Reviewed-by: Bob Feng <bob.c.feng@...>

-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Zhang, Shenglei
Sent: Monday, March 9, 2020 2:32 PM
To: devel@edk2.groups.io
Cc: Gao, Liming <liming.gao@...>; Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>; Feng, Bob C <bob.c.feng@...>
Subject: [edk2-devel] [PATCH v2 0/2] Use submodule way to access brotli

Currently brotli is used and customized by edk2 in BaseTools and MdeModulePkg. These two patches make brotli a submodule in edk2.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2558
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2559

The patches are too big. So I attach the patch link for 1/2 and 2/2.
https://github.com/shenglei10/edk2/commits/brotli

v2: Update INF in 1/2.

Cc: Liming Gao <liming.gao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Hao A Wu <hao.a.wu@...>
Cc: Bob Feng <bob.c.feng@...>

--
2.18.0.windows.1
35161 - 35180 of 90922