[edk2] [PATCH v2] MdeModulePkg/CapsuleApp: Fix memory leak issue.
This issue is caused by FileInfoBuffer variable. This is a pointer array
and each elements also pointer to a memory buffer that is allocated and
returned by AllocateCopyPool function.
Cc: Jian J Wang
Cc: Hao Wu
Cc: Zhang Chao B
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chen A Chen
---
MdeModulePkg/Application/CapsuleApp/CapsuleDump.c | 83 ---
1 file changed, 58 insertions(+), 25 deletions(-)
diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
index ba2583accb..732472bb9c 100644
--- a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
+++ b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
@@ -806,48 +806,69 @@ DumpCapsuleFromDisk (
Status = Fs->OpenVolume (Fs, );
if (EFI_ERROR (Status)) {
Print (L"Cannot open volume. Status = %r\n", Status);
-return EFI_NOT_FOUND;
+goto Done;
}
Status = Root->Open (Root, , EFI_CAPSULE_FILE_DIRECTORY,
EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE , 0);
if (EFI_ERROR (Status)) {
Print (L"Cannot open %s. Status = %r\n", EFI_CAPSULE_FILE_DIRECTORY,
Status);
-return EFI_NOT_FOUND;
+goto Done;
}
//
// Get file count first
//
- for ( Status = FileHandleFindFirstFile (DirHandle, )
- ; !EFI_ERROR(Status) && !NoFile
- ; Status = FileHandleFindNextFile (DirHandle, FileInfo, )
- ){
-if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
- continue;
+ do {
+Status = FileHandleFindFirstFile (DirHandle, );
+if (EFI_ERROR (Status) || FileInfo == NULL) {
+ Print (L"Get File Info Fail. Status = %r\n", Status);
+ goto Done;
}
-FileCount++;
- }
+
+if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
+ FileCount++;
+}
+
+Status = FileHandleFindNextFile (DirHandle, FileInfo, );
+if (EFI_ERROR (Status)) {
+ Print (L"Get Next File Fail. Status = %r\n", Status);
+ goto Done;
+}
+ } while (!NoFile);
if (FileCount == 0) {
Print (L"Error: No capsule file found!\n");
-return EFI_NOT_FOUND;
+Status = EFI_NOT_FOUND;
+goto Done;
}
FileInfoBuffer = AllocatePool (sizeof(FileInfo) * FileCount);
+ if (FileInfoBuffer == NULL) {
+Status = EFI_OUT_OF_RESOURCES;
+goto Done;
+ }
NoFile = FALSE;
//
// Get all file info
//
- for ( Status = FileHandleFindFirstFile (DirHandle, )
- ; !EFI_ERROR (Status) && !NoFile
- ; Status = FileHandleFindNextFile (DirHandle, FileInfo, )
- ){
-if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
- continue;
+ do {
+Status = FileHandleFindFirstFile (DirHandle, );
+if (EFI_ERROR (Status) || FileInfo == NULL) {
+ Print (L"Get File Info Fail. Status = %r\n", Status);
+ goto Done;
+}
+
+if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
+ FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size,
FileInfo);
}
-FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size,
FileInfo);
- }
+
+Status = FileHandleFindNextFile (DirHandle, FileInfo, );
+if (EFI_ERROR (Status)) {
+ Print (L"Get Next File Fail. Status = %r\n", Status);
+ goto Done;
+}
+ } while (!NoFile);
//
// Sort FileInfoBuffer by alphabet order
@@ -866,7 +887,8 @@ DumpCapsuleFromDisk (
}
if (!DumpCapsuleInfo) {
-return EFI_SUCCESS;
+Status = EFI_SUCCESS;
+goto Done;
}
Print(L"The infomation of the capsules:\n");
@@ -875,19 +897,20 @@ DumpCapsuleFromDisk (
FileHandle = NULL;
Status = DirHandle->Open (DirHandle, ,
FileInfoBuffer[Index]->FileName, EFI_FILE_MODE_READ, 0);
if (EFI_ERROR (Status)) {
- break;
+ goto Done;
}
Status = FileHandleGetSize (FileHandle, (UINT64 *) );
if (EFI_ERROR (Status)) {
Print (L"Cannot read file %s. Status = %r\n",
FileInfoBuffer[Index]->FileName, Status);
FileHandleClose (FileHandle);
- return Status;
+ goto Done;
}
FileBuffer = AllocatePool (FileSize);
if (FileBuffer == NULL) {
- return RETURN_OUT_OF_RESOURCES;
+ Status = EFI_OUT_OF_RESOURCES;
+ goto Done;
}
Status = FileHandleRead (FileHandle, , FileBuffer);
@@ -895,7 +918,7 @@ DumpCapsuleFromDisk (
Print (L"Cannot read file %s. Status = %r\n",
FileInfoBuffer[Index]->FileName, Status);
FreePool (FileBuffer);
FileHandleClose (FileHandle);
- return Status;
+ goto Done;
}
Print (L"**\n");
@@ -906,7 +929,17 @@ DumpCapsuleFromDisk (
FreePool (FileBuffer);
}
- return EFI_SUCCESS;
+Done:
+ if (FileInfoBuffer != NULL) {
+for (Index = 0; Index < FileCount; Index++) {
+ if (FileInfoBuffer[Index] != NULL) {
+FreePool (FileInfoBuffer[Index]);
+ }
+}
+FreePool (FileInfoBuffer);
+ }
+
+ return
Re: [edk2] [MdePkg/BaseLib v1 1/1] MdePkg BaseLib: Add new API CalculateCrc16()
Liming,
Agree with you. There are no other usages now.
Thanks
On 2/11/2019 10:15 PM, Gao, Liming wrote:
> Ming:
> So, there is no common CRC16 algorithm in edk2. I suggest to collect all
> CRC16 request in the firmware code, then discussion how to add
> CalculateCrc16() API in BaseLib. There may be more than one CalculateCrc16()
> API with the different postfix for the different algorithm. Besides eeprom
> and DebugAgent, are there other usages?
>
> Thanks
> Liming
>> -Original Message-
>> From: Ming Huang [mailto:ming.hu...@linaro.org]
>> Sent: Saturday, February 2, 2019 7:12 PM
>> To: Gao, Liming ; Ni, Ray ;
>> linaro-u...@lists.linaro.org; edk2-devel@lists.01.org; Kinney,
>> Michael D
>> Cc: huangmin...@huawei.com; Dong, Eric ;
>> zhangjinso...@huawei.com; wanghuiqi...@huawei.com;
>> wai...@126.com; Zeng, Star ; huangda...@hisilicon.com
>> Subject: Re: [edk2] [MdePkg/BaseLib v1 1/1] MdePkg BaseLib: Add new API
>> CalculateCrc16()
>>
>>
>>
>> On 2/1/2019 8:25 PM, Gao, Liming wrote:
>>> Ming:
>>> What's usage model of new Crc16()? Can they use the same algorithm in
>>> DebugAgent?
>>
>> It is used in check MAC read from eeprom. I think they cann't use the
>> algorithm in
>> DebugAgent.
>>
>> Thanks.
>>
>>>
>>> Thanks
>>> Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Ming Huang
Sent: Friday, February 1, 2019 3:12 PM
To: Ni, Ray ; linaro-u...@lists.linaro.org;
edk2-devel@lists.01.org; Kinney, Michael D ;
Gao, Liming
Cc: huangmin...@huawei.com; Dong, Eric ;
zhangjinso...@huawei.com; wanghuiqi...@huawei.com;
wai...@126.com; Zeng, Star ; huangda...@hisilicon.com
Subject: Re: [edk2] [MdePkg/BaseLib v1 1/1] MdePkg BaseLib: Add new API
CalculateCrc16()
On 2/1/2019 2:37 PM, Ni, Ray wrote:
> There is an CRC16 calculation implementation in
> SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugAgent.c
>
> Does your implementation generate the same CRC16 as above one?
It is not the same with above one.
>
>> -Original Message-
>> From: edk2-devel On Behalf Of Ming
>> Huang
>> Sent: Friday, February 1, 2019 2:02 PM
>> To: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org; Kinney,
>> Michael D
>> ; Gao, Liming
>> Cc: huangmin...@huawei.com; Dong, Eric ;
>> zhangjinso...@huawei.com; Zeng, Star ;
>> wai...@126.com; wanghuiqi...@huawei.com; huangda...@hisilicon.com
>> Subject: [edk2] [MdePkg/BaseLib v1 1/1] MdePkg BaseLib: Add new API
>> CalculateCrc16()
>>
>> CalculateCrc16() bases on the initialized mCrcTable. When
>> CalculateCrc16() is
>> used, mCrcTable16 will take 512Bytes size in the image. When
>> CalculateCrc16() is not used, mCrcTable16 will not be built in the
>> image, and
>> no size impact.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang
>> ---
>> MdePkg/Include/Library/BaseLib.h | 20 ++
>> MdePkg/Library/BaseLib/CheckSum.c | 73
>> 2 files changed, 93 insertions(+)
>>
>> diff --git a/MdePkg/Include/Library/BaseLib.h
>> b/MdePkg/Include/Library/BaseLib.h
>> index 1eb842384ee2..956b971e5c69 100644
>> --- a/MdePkg/Include/Library/BaseLib.h
>> +++ b/MdePkg/Include/Library/BaseLib.h
>> @@ -4855,6 +4855,26 @@ CalculateCrc32(
>>IN UINTNLength
>>);
>>
>> +/**
>> + Computes and returns a 16-bit CRC for a data buffer.
>> + CRC16 value bases on CCITT.
>> +
>> + If Buffer is NULL, then ASSERT().
>> + If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
>> +
>> + @param[in] Buffer A pointer to the buffer on which the 16-bit
>> CRC is to
>> be computed.
>> + @param[in] Length The number of bytes in the buffer Data.
>> +
>> + @retval Crc16The 16-bit CRC was computed for the data
>> buffer.
>> +
>> +**/
>> +UINT16
>> +EFIAPI
>> +CalculateCrc16(
>> + IN VOID *Buffer,
>> + IN UINTNLength
>> + );
>> +
>> //
>> // Base Library CPU Functions
>> //
>> diff --git a/MdePkg/Library/BaseLib/CheckSum.c
>> b/MdePkg/Library/BaseLib/CheckSum.c
>> index 03d49afc5e6c..4e27aebe44bc 100644
>> --- a/MdePkg/Library/BaseLib/CheckSum.c
>> +++ b/MdePkg/Library/BaseLib/CheckSum.c
>> @@ -630,3 +630,76 @@ CalculateCrc32(
>>
>>return Crc ^ 0x;
>> }
>> +
>> +GLOBAL_REMOVE_IF_UNREFERENCED CONST UINT16 mCrcTable16[256] =
>> {
>> + 0x, 0x1021, 0x2042, 0x3063, 0x4084, 0x50A5, 0x60C6, 0x70E7,
>> + 0x8108, 0x9129, 0xA14A, 0xB16B, 0xC18C, 0xD1AD, 0xE1CE, 0xF1EF,
>> + 0x1231, 0x0210, 0x3273, 0x2252,
Re: [edk2] [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6 configuration during driver start.
I agree to use debug message. No need to interrupt boot process.
Thanks,
Ting
-Original Message-
From: Wu, Jiaxin
Sent: Tuesday, February 12, 2019 8:48 AM
To: Fu, Siyuan
Cc: edk2-devel@lists.01.org; Mike Turner ; Ye,
Ting
Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6 configuration
during driver start.
Looks it's enough to add the warning debug message. I have sent the version 2
patch to do that.
Thanks,
Jiaxin
> -Original Message-
> From: Fu, Siyuan
> Sent: Tuesday, February 12, 2019 8:28 AM
> To: Wu, Jiaxin
> Cc: edk2-devel@lists.01.org; Mike Turner
> ; Ye, Ting
> Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> configuration during driver start.
>
> Yes, Jiaxin. You should not use popup messages unless you 100 percent
> sure the code is running in setup browser.
>
> BestRegards
> Fu Siyuan
>
>
> > -Original Message-
> > From: Mike Turner [mailto:michael.tur...@microsoft.com]
> > Sent: Monday, February 11, 2019 11:10 PM
> > To: Wu, Jiaxin ; Ye, Ting ;
> > edk2- de...@lists.01.org
> > Cc: Fu, Siyuan
> > Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> > configuration during driver start.
> >
> > I haven't seen any patch for a popup, but message popups during
> > driver
> binding
> > start are not a good thing.
> >
> > Michael R Turner
> > Surface UEFI Development
> > Microsoft Corporation
> > One Redmond Way
> > Redmond WA 98052
> >
> > 425-705-0928
> >
> > This email message may contain confidential and privileged
> information. Any
> > unauthorized use is prohibited. If you are not the intended
> > recipient,
> please
> > contact the sender by reply email and destroy all copies of the
> > original message.
> >
> >
> > -Original Message-
> > From: Wu, Jiaxin
> > Sent: Sunday, February 10, 2019 7:10 PM
> > To: Ye, Ting ; edk2-devel@lists.01.org
> > Cc: Mike Turner ; Fu, Siyuan
> >
> > Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> > configuration during driver start.
> >
> > Agree, thanks the comment. I will update the patch.
> >
> >
> >
> > > -Original Message-
> > > From: Ye, Ting
> > > Sent: Monday, February 11, 2019 11:09 AM
> > > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > > Cc: Michael Turner ; Fu, Siyuan
> > >
> > > Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> > > configuration during driver start.
> > >
> > > Hi Jiaxin,
> > >
> > > I agree we need start IPv6 stack no matter the configuration is valid or
> > > not.
> > > However I would suggest to add more comments and pop up warning
> > > messages to let user know we continue to start IPv6 stack without
> > > using previously saved configuration.
> > >
> > > Thanks,
> > > Ting
> > >
> > > -Original Message-
> > > From: Wu, Jiaxin
> > > Sent: Sunday, February 3, 2019 2:24 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Michael Turner ; Ye, Ting
> > > ; Fu, Siyuan ; Wu, Jiaxin
> > >
> > > Subject: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> > > configuration during driver start.
> > >
> > > REF:
> > >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugz
> > >
> illa.tianocore.org%2Fshow_bug.cgi%3Fid%3D1448data=02%7C01%7C
> Micha
> > >
> el.Turner%40microsoft.com%7C93fb5d7f003b48c6561d08d68fce66f4%7C72f9
> 88b
> > >
> f86f141af91ab2d7cd011db47%7C1%7C0%7C636854514000398927sdata
> =bCAbT
> > > njjX9bmuRiASoCkPiZtdqUY14BDMgyLd%2BYNNx4%3Dreserved=0
> > >
> > > This patch is to clean the invalid data and continue to start IP6 driver.
> > >
> > > Cc: Michael Turner
> > > Cc: Ye Ting
> > > Cc: Fu Siyuan
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Wu Jiaxin
> > > Signed-off-by: Michael Turner
> > > ---
> > > NetworkPkg/Ip6Dxe/Ip6Driver.c | 20 ++--
> > > 1 file changed, 18 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > > b/NetworkPkg/Ip6Dxe/Ip6Driver.c index 4c607125a6..1bd1c61da8
> > > 100644
> > > --- a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > > +++ b/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > > @@ -586,11 +586,19 @@ Ip6DriverBindingStart (
> > > Ip6ConfigDataTypeManualAddress,
> > > DataItem->DataSize,
> > > DataItem->Data.Ptr
> > > );
> > > if (EFI_ERROR(Status) && Status != EFI_NOT_READY) {
> > > - goto UNINSTALL_PROTOCOL;
> > > + //
> > > + // Clean the invalid ManualAddress configuration.
> > > + //
> > > + Status = Ip6Cfg->SetData (
> > > + Ip6Cfg,
> > > + Ip6ConfigDataTypeManualAddress,
> > > + 0,
> > > + NULL
> > > + );
> > > }
> > >}
> > >
> > >//
> > >// If there is any default gateway address, set it.
> > > @@ -602,11 +610,19 @@ Ip6DriverBindingStart (
> > >
Re: [edk2] [edk2-platforms/devel-MinPlatform][PATCH v3 1/1] ReadMe.md: Update Minimum Platform details
Reviewed-by: Chasel Chiu > -Original Message- > From: Desimone, Nathaniel L > Sent: Wednesday, February 6, 2019 1:34 AM > To: Kubacki, Michael A ; > edk2-devel@lists.01.org > Cc: Kinney, Michael D ; Sinha, Ankit > ; Chiu, Chasel ; Oram, Isaac W > ; Gao, Liming > Subject: Re: [edk2-platforms/devel-MinPlatform][PATCH v3 1/1] ReadMe.md: > Update Minimum Platform details > > Reviewed-by: Nate DeSimone > > On 2/4/19, 5:57 PM, "Kubacki, Michael A" > wrote: > > Adds details on the EDK II Minimum Platform design for Intel > platforms. > > * Overview of Minimum Platform > * Board package purpose and conventions > * Stage boot concept and control > * Minimum Platform firmware solution stack overview > * Updates build instructions for all OpenBoardPkgs > * Adds information for the ClevoOpenBoardPkg > * Adds planned activities and ideas for the future > > Cc: Michael D Kinney > Cc: Nate DeSimone > Cc: Ankit Sinha > Cc: Chasel Chiu > Cc: Isaac W Oram > Cc: Liming Gao > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Michael Kubacki > --- > ReadMe.md | 164 > ++ > 1 file changed, 132 insertions(+), 32 deletions(-) > > diff --git a/ReadMe.md b/ReadMe.md > index 9b873da2e3..72e332a476 100644 > --- a/ReadMe.md > +++ b/ReadMe.md > @@ -1,8 +1,73 @@ > -# **EDK II Minimized firmware for Intel(R) platforms** > +# **EDK II Minimum Platform Firmware for Intel(R) Platforms** > > -## Features > -* The Minimized Kabylake provides the minimal feature of the Kabylake > BIOS. > -* The Minimized Purley provides the minimal feature of the Purley BIOS. > +The Minimum Platform is a software architecture that guides uniform > delivery of Intel platforms enabling firmware > +solutions for basic boot functionality with extensibility built-in. > + > +Package maintainers for the Minimum Platform projects are listed in > Maintainers.txt. > + > +## Overview > +The key elements of the architecture are organized into a staged boot > approach where each stage has requirements and > +functionality for specific use cases. The generic control flow through > the > boot process is implemented in the > > +[`MinPlatformPkg`](https://github.com/tianocore/edk2-platforms/tree/devel > -MinPlatform/Platform/Intel/MinPlatformPkg). > +The generic nature of the tasks performed in MinPlatformPkg lends to > reuse > across all Intel platforms with no > +source modification. Details for any particular board are made > accessible to > the MinPlatformPkg through a well-defined > +statically linked board API. A complete platform solution then consists > of the > MinPlatformPkg and a compatible board > +package. > + > +## Board Naming Convention > +The board packages supported by Intel follow the naming convention > \OpenBoardPkg where xxx refers to the > +encompassing platform name for a particular platform generation. For > example, the > [`KabylakeOpenBoardPkg`](https://github.com/tianocore/edk2-platforms/tree > /devel-MinPlatform/Platform/Intel/KabylakeOpenBoardPkg) contains the > +board code for Intel Kaby Lake reference systems. Intel uses the moniker > "OpenBoardPkg" to indicate that this package > +is the open source board code. A closed source counterpart may exist > which > simply uses "BoardPkg". Both directly use > +the MinPlatformPkg from edk2-platforms. > + > +## Stage Selection > +Stage selection is controlled via the PCD > `gMinPlatformPkgTokenSpaceGuid.PcdBootStage` in > [`MinPlatformPkg.dec`](https://github.com/tianocore/edk2-platforms/blob/d > evel-MinPlatform/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dec). > +The stage should be configured in the board package DSC file to the > appropriate value. For example, a board may disable > +all advanced features by setting this value to 4 instead of 6. This may > be used > to improve boot time for a particular > +use case. Decrementing the stage can also be used for debug since only > the > actions required for that stage objective > +should be executed. As an example, ACPI initialization is not required > for a > Stage 3 boot. > + > +The stages are defined as follows: > + > +| Stage | Functional Objective | Example Capabilities > | > +| > ---|--|--- > -| > +| I | Minimal Debug| Serial port output, source > debug > enabled, hardware debugger enabled| > +| II | Memory Functional| Basic hardware initialization > necessary to reach memory initialization, permanent memory available | > +| III| Boot to UI |
Re: [edk2] [PATCH v2] NetworkPkg/Ip6Dxe: Clean the invalid IPv6 configuration during driver start.
Hi, Jiaxin
I think the Ip6Cfg->SetData() may return other error, which not only because
invalid config data is used. Why not just check the config data in
Ip6ConfigReadConfigData()?
BestRegards
Fu Siyuan
> -Original Message-
> From: Wu, Jiaxin
> Sent: Tuesday, February 12, 2019 8:47 AM
> To: edk2-devel@lists.01.org
> Cc: Michael Turner ; Ye, Ting
> ; Fu, Siyuan ; Wu, Jiaxin
>
> Subject: [PATCH v2] NetworkPkg/Ip6Dxe: Clean the invalid IPv6 configuration
> during driver start.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1448
>
> *v2: Add the warning debug message.
>
> This patch is to clean the invalid data and continue to start IP6 driver.
>
> Cc: Michael Turner
> Cc: Ye Ting
> Cc: Fu Siyuan
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wu Jiaxin
> ---
> NetworkPkg/Ip6Dxe/Ip6Driver.c | 22 --
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/NetworkPkg/Ip6Dxe/Ip6Driver.c b/NetworkPkg/Ip6Dxe/Ip6Driver.c
> index 4c607125a6..7ec74f6ebc 100644
> --- a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> +++ b/NetworkPkg/Ip6Dxe/Ip6Driver.c
> @@ -586,11 +586,20 @@ Ip6DriverBindingStart (
> Ip6ConfigDataTypeManualAddress,
> DataItem->DataSize,
> DataItem->Data.Ptr
> );
> if (EFI_ERROR(Status) && Status != EFI_NOT_READY) {
> - goto UNINSTALL_PROTOCOL;
> + //
> + // Clean the invalid ManualAddress configuration.
> + //
> + Status = Ip6Cfg->SetData (
> + Ip6Cfg,
> + Ip6ConfigDataTypeManualAddress,
> + 0,
> + NULL
> + );
> + DEBUG ((EFI_D_WARN, "Ip6DriverBindingStart: Clean the invalid
> ManualAddress configuration.\n"));
> }
>}
>
>//
>// If there is any default gateway address, set it.
> @@ -602,11 +611,20 @@ Ip6DriverBindingStart (
> Ip6ConfigDataTypeGateway,
> DataItem->DataSize,
> DataItem->Data.Ptr
> );
> if (EFI_ERROR(Status)) {
> - goto UNINSTALL_PROTOCOL;
> + //
> + // Clean the invalid Gateway configuration.
> + //
> + Status = Ip6Cfg->SetData (
> + Ip6Cfg,
> + Ip6ConfigDataTypeGateway,
> + 0,
> + NULL
> + );
> + DEBUG ((EFI_D_WARN, "Ip6DriverBindingStart: Clean the invalid Gateway
> configuration.\n"));
> }
>}
>
>//
>// ready to go: start the receiving and timer
> --
> 2.17.1.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6 configuration during driver start.
Looks it's enough to add the warning debug message. I have sent the version 2
patch to do that.
Thanks,
Jiaxin
> -Original Message-
> From: Fu, Siyuan
> Sent: Tuesday, February 12, 2019 8:28 AM
> To: Wu, Jiaxin
> Cc: edk2-devel@lists.01.org; Mike Turner ;
> Ye, Ting
> Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> configuration during driver start.
>
> Yes, Jiaxin. You should not use popup messages unless you 100 percent sure
> the code is running in setup browser.
>
> BestRegards
> Fu Siyuan
>
>
> > -Original Message-
> > From: Mike Turner [mailto:michael.tur...@microsoft.com]
> > Sent: Monday, February 11, 2019 11:10 PM
> > To: Wu, Jiaxin ; Ye, Ting ; edk2-
> > de...@lists.01.org
> > Cc: Fu, Siyuan
> > Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> > configuration during driver start.
> >
> > I haven't seen any patch for a popup, but message popups during driver
> binding
> > start are not a good thing.
> >
> > Michael R Turner
> > Surface UEFI Development
> > Microsoft Corporation
> > One Redmond Way
> > Redmond WA 98052
> >
> > 425-705-0928
> >
> > This email message may contain confidential and privileged
> information. Any
> > unauthorized use is prohibited. If you are not the intended recipient,
> please
> > contact the sender by reply email and destroy all copies of the original
> > message.
> >
> >
> > -Original Message-
> > From: Wu, Jiaxin
> > Sent: Sunday, February 10, 2019 7:10 PM
> > To: Ye, Ting ; edk2-devel@lists.01.org
> > Cc: Mike Turner ; Fu, Siyuan
> >
> > Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> > configuration during driver start.
> >
> > Agree, thanks the comment. I will update the patch.
> >
> >
> >
> > > -Original Message-
> > > From: Ye, Ting
> > > Sent: Monday, February 11, 2019 11:09 AM
> > > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > > Cc: Michael Turner ; Fu, Siyuan
> > >
> > > Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> > > configuration during driver start.
> > >
> > > Hi Jiaxin,
> > >
> > > I agree we need start IPv6 stack no matter the configuration is valid or
> > > not.
> > > However I would suggest to add more comments and pop up warning
> > > messages to let user know we continue to start IPv6 stack without
> > > using previously saved configuration.
> > >
> > > Thanks,
> > > Ting
> > >
> > > -Original Message-
> > > From: Wu, Jiaxin
> > > Sent: Sunday, February 3, 2019 2:24 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Michael Turner ; Ye, Ting
> > > ; Fu, Siyuan ; Wu, Jiaxin
> > >
> > > Subject: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> > > configuration during driver start.
> > >
> > > REF:
> > >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugz
> > >
> illa.tianocore.org%2Fshow_bug.cgi%3Fid%3D1448data=02%7C01%7C
> Micha
> > >
> el.Turner%40microsoft.com%7C93fb5d7f003b48c6561d08d68fce66f4%7C72f9
> 88b
> > >
> f86f141af91ab2d7cd011db47%7C1%7C0%7C636854514000398927sdata
> =bCAbT
> > > njjX9bmuRiASoCkPiZtdqUY14BDMgyLd%2BYNNx4%3Dreserved=0
> > >
> > > This patch is to clean the invalid data and continue to start IP6 driver.
> > >
> > > Cc: Michael Turner
> > > Cc: Ye Ting
> > > Cc: Fu Siyuan
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Wu Jiaxin
> > > Signed-off-by: Michael Turner
> > > ---
> > > NetworkPkg/Ip6Dxe/Ip6Driver.c | 20 ++--
> > > 1 file changed, 18 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > > b/NetworkPkg/Ip6Dxe/Ip6Driver.c index 4c607125a6..1bd1c61da8 100644
> > > --- a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > > +++ b/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > > @@ -586,11 +586,19 @@ Ip6DriverBindingStart (
> > > Ip6ConfigDataTypeManualAddress,
> > > DataItem->DataSize,
> > > DataItem->Data.Ptr
> > > );
> > > if (EFI_ERROR(Status) && Status != EFI_NOT_READY) {
> > > - goto UNINSTALL_PROTOCOL;
> > > + //
> > > + // Clean the invalid ManualAddress configuration.
> > > + //
> > > + Status = Ip6Cfg->SetData (
> > > + Ip6Cfg,
> > > + Ip6ConfigDataTypeManualAddress,
> > > + 0,
> > > + NULL
> > > + );
> > > }
> > >}
> > >
> > >//
> > >// If there is any default gateway address, set it.
> > > @@ -602,11 +610,19 @@ Ip6DriverBindingStart (
> > > Ip6ConfigDataTypeGateway,
> > > DataItem->DataSize,
> > > DataItem->Data.Ptr
> > > );
> > > if (EFI_ERROR(Status)) {
> > > - goto UNINSTALL_PROTOCOL;
> > > + //
> > > + // Clean the invalid Gateway configuration.
> > > + //
> > > + Status = Ip6Cfg->SetData (
> > > +
[edk2] [PATCH v2] NetworkPkg/Ip6Dxe: Clean the invalid IPv6 configuration during driver start.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1448
*v2: Add the warning debug message.
This patch is to clean the invalid data and continue to start IP6 driver.
Cc: Michael Turner
Cc: Ye Ting
Cc: Fu Siyuan
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wu Jiaxin
---
NetworkPkg/Ip6Dxe/Ip6Driver.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/NetworkPkg/Ip6Dxe/Ip6Driver.c b/NetworkPkg/Ip6Dxe/Ip6Driver.c
index 4c607125a6..7ec74f6ebc 100644
--- a/NetworkPkg/Ip6Dxe/Ip6Driver.c
+++ b/NetworkPkg/Ip6Dxe/Ip6Driver.c
@@ -586,11 +586,20 @@ Ip6DriverBindingStart (
Ip6ConfigDataTypeManualAddress,
DataItem->DataSize,
DataItem->Data.Ptr
);
if (EFI_ERROR(Status) && Status != EFI_NOT_READY) {
- goto UNINSTALL_PROTOCOL;
+ //
+ // Clean the invalid ManualAddress configuration.
+ //
+ Status = Ip6Cfg->SetData (
+ Ip6Cfg,
+ Ip6ConfigDataTypeManualAddress,
+ 0,
+ NULL
+ );
+ DEBUG ((EFI_D_WARN, "Ip6DriverBindingStart: Clean the invalid
ManualAddress configuration.\n"));
}
}
//
// If there is any default gateway address, set it.
@@ -602,11 +611,20 @@ Ip6DriverBindingStart (
Ip6ConfigDataTypeGateway,
DataItem->DataSize,
DataItem->Data.Ptr
);
if (EFI_ERROR(Status)) {
- goto UNINSTALL_PROTOCOL;
+ //
+ // Clean the invalid Gateway configuration.
+ //
+ Status = Ip6Cfg->SetData (
+ Ip6Cfg,
+ Ip6ConfigDataTypeGateway,
+ 0,
+ NULL
+ );
+ DEBUG ((EFI_D_WARN, "Ip6DriverBindingStart: Clean the invalid Gateway
configuration.\n"));
}
}
//
// ready to go: start the receiving and timer
--
2.17.1.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6 configuration during driver start.
Yes, Jiaxin. You should not use popup messages unless you 100 percent sure the
code is running in setup browser.
BestRegards
Fu Siyuan
> -Original Message-
> From: Mike Turner [mailto:michael.tur...@microsoft.com]
> Sent: Monday, February 11, 2019 11:10 PM
> To: Wu, Jiaxin ; Ye, Ting ; edk2-
> de...@lists.01.org
> Cc: Fu, Siyuan
> Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> configuration during driver start.
>
> I haven't seen any patch for a popup, but message popups during driver binding
> start are not a good thing.
>
> Michael R Turner
> Surface UEFI Development
> Microsoft Corporation
> One Redmond Way
> Redmond WA 98052
>
> 425-705-0928
>
> This email message may contain confidential and privileged information. Any
> unauthorized use is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message.
>
>
> -Original Message-
> From: Wu, Jiaxin
> Sent: Sunday, February 10, 2019 7:10 PM
> To: Ye, Ting ; edk2-devel@lists.01.org
> Cc: Mike Turner ; Fu, Siyuan
>
> Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> configuration during driver start.
>
> Agree, thanks the comment. I will update the patch.
>
>
>
> > -Original Message-
> > From: Ye, Ting
> > Sent: Monday, February 11, 2019 11:09 AM
> > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > Cc: Michael Turner ; Fu, Siyuan
> >
> > Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> > configuration during driver start.
> >
> > Hi Jiaxin,
> >
> > I agree we need start IPv6 stack no matter the configuration is valid or
> > not.
> > However I would suggest to add more comments and pop up warning
> > messages to let user know we continue to start IPv6 stack without
> > using previously saved configuration.
> >
> > Thanks,
> > Ting
> >
> > -Original Message-
> > From: Wu, Jiaxin
> > Sent: Sunday, February 3, 2019 2:24 PM
> > To: edk2-devel@lists.01.org
> > Cc: Michael Turner ; Ye, Ting
> > ; Fu, Siyuan ; Wu, Jiaxin
> >
> > Subject: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> > configuration during driver start.
> >
> > REF:
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugz
> > illa.tianocore.org%2Fshow_bug.cgi%3Fid%3D1448data=02%7C01%7CMicha
> > el.Turner%40microsoft.com%7C93fb5d7f003b48c6561d08d68fce66f4%7C72f988b
> > f86f141af91ab2d7cd011db47%7C1%7C0%7C636854514000398927sdata=bCAbT
> > njjX9bmuRiASoCkPiZtdqUY14BDMgyLd%2BYNNx4%3Dreserved=0
> >
> > This patch is to clean the invalid data and continue to start IP6 driver.
> >
> > Cc: Michael Turner
> > Cc: Ye Ting
> > Cc: Fu Siyuan
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Wu Jiaxin
> > Signed-off-by: Michael Turner
> > ---
> > NetworkPkg/Ip6Dxe/Ip6Driver.c | 20 ++--
> > 1 file changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > b/NetworkPkg/Ip6Dxe/Ip6Driver.c index 4c607125a6..1bd1c61da8 100644
> > --- a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > +++ b/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > @@ -586,11 +586,19 @@ Ip6DriverBindingStart (
> > Ip6ConfigDataTypeManualAddress,
> > DataItem->DataSize,
> > DataItem->Data.Ptr
> > );
> > if (EFI_ERROR(Status) && Status != EFI_NOT_READY) {
> > - goto UNINSTALL_PROTOCOL;
> > + //
> > + // Clean the invalid ManualAddress configuration.
> > + //
> > + Status = Ip6Cfg->SetData (
> > + Ip6Cfg,
> > + Ip6ConfigDataTypeManualAddress,
> > + 0,
> > + NULL
> > + );
> > }
> >}
> >
> >//
> >// If there is any default gateway address, set it.
> > @@ -602,11 +610,19 @@ Ip6DriverBindingStart (
> > Ip6ConfigDataTypeGateway,
> > DataItem->DataSize,
> > DataItem->Data.Ptr
> > );
> > if (EFI_ERROR(Status)) {
> > - goto UNINSTALL_PROTOCOL;
> > + //
> > + // Clean the invalid Gateway configuration.
> > + //
> > + Status = Ip6Cfg->SetData (
> > + Ip6Cfg,
> > + Ip6ConfigDataTypeGateway,
> > + 0,
> > + NULL
> > + );
> > }
> >}
> >
> >//
> >// ready to go: start the receiving and timer
> > --
> > 2.17.1.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdePkg/BaseLib: implement SpeculationBarrier() for ARM and AArch64
Ard: I agree your comments not to add PCD until there is the real problem. Thanks Liming >-Original Message- >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard >Biesheuvel >Sent: Tuesday, February 12, 2019 1:32 AM >To: Leif Lindholm >Cc: Kinney, Michael D ; edk2- >de...@lists.01.org; Gao, Liming >Subject: Re: [edk2] [PATCH] MdePkg/BaseLib: implement SpeculationBarrier() >for ARM and AArch64 > >On Mon, 11 Feb 2019 at 15:41, Leif Lindholm wrote: >> >> On Wed, Feb 06, 2019 at 12:08:22AM +, Ard Biesheuvel wrote: >> > Replace the dummy C implementation of SpeculationBarrier() with >> > implementations consisting of the recommended DSB SY + ISB sequence, >> > as recommended by ARM in the whitepaper "Cache Speculation Side- >channels" >> > version 2.4, dated October 2018. >> > >> > Contributed-under: TianoCore Contribution Agreement 1.1 >> > Signed-off-by: Ard Biesheuvel >> >> Patch looks fine. >> Reviewed-by: Leif Lindholm >> >> Question: do we expect performance impact to be sufficient to >> motivate a Pcd to be able to disable the barrier on unaffected >> processors? >> > >Currently, these are only used on some codepaths in the MM component >of the variable store, which do not look like hot paths to me. > >In general, I think it should be fine to defer doing something like >this until someone highlights it as an actual problem (and has the >numbers to prove it) > > >> > --- >> > MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S | 39 > >> > MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm | 38 >+++ >> > MdePkg/Library/BaseLib/Arm/SpeculationBarrier.S | 39 > >> > MdePkg/Library/BaseLib/Arm/SpeculationBarrier.asm | 39 > >> > MdePkg/Library/BaseLib/Arm/SpeculationBarrier.c | 30 --- >> > MdePkg/Library/BaseLib/BaseLib.inf| 7 +++- >> > 6 files changed, 160 insertions(+), 32 deletions(-) >> > >> > diff --git a/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S >b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S >> > new file mode 100644 >> > index ..500bdadca5d2 >> > --- /dev/null >> > +++ b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S >> > @@ -0,0 +1,39 @@ >> > +##-- >> > +# >> > +# SpeculationBarrier() for AArch64 >> > +# >> > +# Copyright (c) 2019, Linaro Ltd. 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. >> > +# >> > +##-- >> > + >> > +.text >> > +.p2align 2 >> > + >> > +GCC_ASM_EXPORT(SpeculationBarrier) >> > + >> > + >> > +#/** >> > +# Uses as a barrier to stop speculative execution. >> > +# >> > +# Ensures that no later instruction will execute speculatively, until all >prior >> > +# instructions have completed. >> > +# >> > +#**/ >> > +#VOID >> > +#EFIAPI >> > +#SpeculationBarrier ( >> > +# VOID >> > +# ); >> > +# >> > +ASM_PFX(SpeculationBarrier): >> > +dsb sy >> > +isb >> > +ret >> > diff --git a/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm >b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm >> > new file mode 100644 >> > index ..0c4b915b7798 >> > --- /dev/null >> > +++ b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm >> > @@ -0,0 +1,38 @@ >> > +;-- >> > +; >> > +; SpeculationBarrier() for AArch64 >> > +; >> > +; Copyright (c) 2019, Linaro Ltd. 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. >> > +; >> > +;-- >> > + >> > + EXPORT SpeculationBarrier >> > + AREA BaseLib_LowLevel, CODE, READONLY >> > + >> > +;/** >> > +; Uses as a barrier to stop speculative execution. >> > +; >> > +; Ensures that no later instruction will execute speculatively, until >> > all prior >> > +; instructions have completed. >> > +; >> > +;**/ >> > +;VOID >> > +;EFIAPI >> >
Re: [edk2] [PATCH edk2-non-osi v1 3/7] Hisilicon/D06: Update Mbigen and gic RAS register
On Fri, Feb 01, 2019 at 10:25:03PM +0800, Ming Huang wrote: > As chip group suggestions, update Mbigen and gic RAS configuration > flow. Update how? / Leif > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang > --- > Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi | Bin 17984 -> > 18720 bytes > 1 file changed, 0 insertions(+), 0 deletions(-) > > diff --git a/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi > b/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi > index 19adbc9..9ea21e9 100644 > Binary files a/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi and > b/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi differ > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-non-osi v1 2/7] Hisilicon/D0x: Rename StartupAp() function
On Fri, Feb 01, 2019 at 10:25:02PM +0800, Ming Huang wrote: > As suggestion of community, 'AP' is a bit unfortunate to use in EDK2 > context. PI specifies 'BSP' for Boot-strap Processor, as the one > executing all of the EDK2 code. It then uses 'AP' to refer to > Additional Processors, which can be assigned tasks using the > EFI_MP_SERVICES_PROTOCOL. In a TianoCore context, this should be > 'BSP'. So, Rename StartupAp() to StartUpBSP. Please add a comment somewhere that this applies to D0x PlatformSysCtrlLib. > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang > --- > > Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib > | Bin 297590 -> 229128 bytes > > Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib > | Bin 344310 -> 275312 bytes > > Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib > | Bin 356032 -> 375916 bytes > 3 files changed, 0 insertions(+), 0 deletions(-) These are substantial changes in image size from only changing the name of a function. So I'll have a little look around. 1610 version appears to have switched from building with GCC49_RELEASE to GCC48_RELEASE. 1616 and 1620 versions seem to have used GCC48_RELEASE all along. I definitely see additional renamed functions in these libraries too. Please have an inventory and determine what may be affecting image sizes. Also, I *beg* you - please upgrade from "GNU C 4.8.3 20131202 (prerelease)". / Leif > > diff --git > a/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib > > b/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib > index 68be770..4c63a26 100644 > Binary files > a/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib > and > b/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib > differ > diff --git > a/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib > > b/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib > index b3cc88e..cb2c652 100644 > Binary files > a/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib > and > b/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib > differ > diff --git > a/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib > > b/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib > index 50d453a..d643f7b 100644 > Binary files > a/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib > and > b/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib > differ > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 16/16] Hisilicon/D0x: Modify version to 19.02
On Fri, Feb 01, 2019 at 10:29:07PM +0800, Ming Huang wrote: > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang Reviewed-by: Leif Lindholm > --- > Platform/Hisilicon/D03/D03.dsc | 4 ++-- > Platform/Hisilicon/D05/D05.dsc | 4 ++-- > Platform/Hisilicon/D06/D06.dsc | 4 ++-- > 3 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/Platform/Hisilicon/D03/D03.dsc b/Platform/Hisilicon/D03/D03.dsc > index 35b54f8c83be..07ff461277df 100644 > --- a/Platform/Hisilicon/D03/D03.dsc > +++ b/Platform/Hisilicon/D03/D03.dsc > @@ -171,12 +171,12 @@ [PcdsFixedAtBuild.common] >!ifdef $(FIRMWARE_VER) > > gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"$(FIRMWARE_VER)" >!else > -gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"Development > build 18.08 for Hisilicon D03" > +gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"Development > build 19.02 for Hisilicon D03" >!endif > >gHisiTokenSpaceGuid.PcdBiosVersionString|L"10.01.01T18" > > - gHisiTokenSpaceGuid.PcdBiosVersionForBmc|L"1.12" > + gHisiTokenSpaceGuid.PcdBiosVersionForBmc|L"19.02" > >gHisiTokenSpaceGuid.PcdSystemProductName|L"D03" >gHisiTokenSpaceGuid.PcdSystemVersion|L"Estuary" > diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc > index 49bd5b37ea34..70b044c7e33a 100644 > --- a/Platform/Hisilicon/D05/D05.dsc > +++ b/Platform/Hisilicon/D05/D05.dsc > @@ -187,12 +187,12 @@ [PcdsFixedAtBuild.common] >!ifdef $(FIRMWARE_VER) > > gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"$(FIRMWARE_VER)" >!else > -gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"Development > build 18.08 for Hisilicon D05" > +gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"Development > build 19.02 for Hisilicon D05" >!endif > >gHisiTokenSpaceGuid.PcdBiosVersionString|L"10.01.01T18" > > - gHisiTokenSpaceGuid.PcdBiosVersionForBmc|L"1.12" > + gHisiTokenSpaceGuid.PcdBiosVersionForBmc|L"19.02" > >gHisiTokenSpaceGuid.PcdSystemProductName|L"D05" >gHisiTokenSpaceGuid.PcdSystemVersion|L"Estuary" > diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc > index a3a01bfb1e23..73bea728b0f6 100644 > --- a/Platform/Hisilicon/D06/D06.dsc > +++ b/Platform/Hisilicon/D06/D06.dsc > @@ -156,12 +156,12 @@ [PcdsFixedAtBuild.common] >!ifdef $(FIRMWARE_VER) > > gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"$(FIRMWARE_VER)" >!else > -gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"Development > build 18.08 for Hisilicon D06" > +gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"Development > build 19.02 for Hisilicon D06" >!endif > >gHisiTokenSpaceGuid.PcdBiosVersionString|L"10.01.01T18" > > - gHisiTokenSpaceGuid.PcdBiosVersionForBmc|L"0.42" > + gHisiTokenSpaceGuid.PcdBiosVersionForBmc|L"19.02" > >gHisiTokenSpaceGuid.PcdSystemProductName|L"D06" >gHisiTokenSpaceGuid.PcdSystemVersion|L"VER.A" > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 15/16] Hisilicon/D06: Use CalculateCrc16 in BaseLib
On Fri, Feb 01, 2019 at 10:29:06PM +0800, Ming Huang wrote:
> This patch is relative with "Add new API CalculateCrc16()" in edk2.
The commit message should describe what the patch does.
I don't mind keeping the above line in, but we also need the
description.
Obviously, this patch depends on the corresponding one going into
edk2, which is has not yet.
/
Leif
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c | 69
> ++--
> 1 file changed, 5 insertions(+), 64 deletions(-)
>
> diff --git a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> index 9bf274e1b991..3ba4f305fb8e 100644
> --- a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> +++ b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> @@ -14,6 +14,7 @@
> **/
>
> #include
> +#include
> #include
> #include
> #include
> @@ -56,66 +57,6 @@ ETH_PRODUCT_DESC gEthPdtDesc[ETH_MAX_PORT] =
> {FALSE, ETH_INVALID, ETH_INVALID, ETH_INVALID, ETH_INVALID}
> };
>
> -UINT16 CrcTable16[256] = {
> - 0x, 0x1021, 0x2042, 0x3063, 0x4084, 0x50A5, 0x60C6, 0x70E7,
> - 0x8108, 0x9129, 0xA14A, 0xB16B, 0xC18C, 0xD1AD, 0xE1CE, 0xF1EF,
> - 0x1231, 0x0210, 0x3273, 0x2252, 0x52B5, 0x4294, 0x72F7, 0x62D6,
> - 0x9339, 0x8318, 0xB37B, 0xA35A, 0xD3BD, 0xC39C, 0xF3FF, 0xE3DE,
> - 0x2462, 0x3443, 0x0420, 0x1401, 0x64E6, 0x74C7, 0x44A4, 0x5485,
> - 0xA56A, 0xB54B, 0x8528, 0x9509, 0xE5EE, 0xF5CF, 0xC5AC, 0xD58D,
> - 0x3653, 0x2672, 0x1611, 0x0630, 0x76D7, 0x66F6, 0x5695, 0x46B4,
> - 0xB75B, 0xA77A, 0x9719, 0x8738, 0xF7DF, 0xE7FE, 0xD79D, 0xC7BC,
> - 0x48C4, 0x58E5, 0x6886, 0x78A7, 0x0840, 0x1861, 0x2802, 0x3823,
> - 0xC9CC, 0xD9ED, 0xE98E, 0xF9AF, 0x8948, 0x9969, 0xA90A, 0xB92B,
> - 0x5AF5, 0x4AD4, 0x7AB7, 0x6A96, 0x1A71, 0x0A50, 0x3A33, 0x2A12,
> - 0xDBFD, 0xCBDC, 0xFBBF, 0xEB9E, 0x9B79, 0x8B58, 0xBB3B, 0xAB1A,
> - 0x6CA6, 0x7C87, 0x4CE4, 0x5CC5, 0x2C22, 0x3C03, 0x0C60, 0x1C41,
> - 0xEDAE, 0xFD8F, 0xCDEC, 0xDDCD, 0xAD2A, 0xBD0B, 0x8D68, 0x9D49,
> - 0x7E97, 0x6EB6, 0x5ED5, 0x4EF4, 0x3E13, 0x2E32, 0x1E51, 0x0E70,
> - 0xFF9F, 0xEFBE, 0xDFDD, 0xCFFC, 0xBF1B, 0xAF3A, 0x9F59, 0x8F78,
> - 0x9188, 0x81A9, 0xB1CA, 0xA1EB, 0xD10C, 0xC12D, 0xF14E, 0xE16F,
> - 0x1080, 0x00A1, 0x30C2, 0x20E3, 0x5004, 0x4025, 0x7046, 0x6067,
> - 0x83B9, 0x9398, 0xA3FB, 0xB3DA, 0xC33D, 0xD31C, 0xE37F, 0xF35E,
> - 0x02B1, 0x1290, 0x22F3, 0x32D2, 0x4235, 0x5214, 0x6277, 0x7256,
> - 0xB5EA, 0xA5CB, 0x95A8, 0x8589, 0xF56E, 0xE54F, 0xD52C, 0xC50D,
> - 0x34E2, 0x24C3, 0x14A0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,
> - 0xA7DB, 0xB7FA, 0x8799, 0x97B8, 0xE75F, 0xF77E, 0xC71D, 0xD73C,
> - 0x26D3, 0x36F2, 0x0691, 0x16B0, 0x6657, 0x7676, 0x4615, 0x5634,
> - 0xD94C, 0xC96D, 0xF90E, 0xE92F, 0x99C8, 0x89E9, 0xB98A, 0xA9AB,
> - 0x5844, 0x4865, 0x7806, 0x6827, 0x18C0, 0x08E1, 0x3882, 0x28A3,
> - 0xCB7D, 0xDB5C, 0xEB3F, 0xFB1E, 0x8BF9, 0x9BD8, 0xABBB, 0xBB9A,
> - 0x4A75, 0x5A54, 0x6A37, 0x7A16, 0x0AF1, 0x1AD0, 0x2AB3, 0x3A92,
> - 0xFD2E, 0xED0F, 0xDD6C, 0xCD4D, 0xBDAA, 0xAD8B, 0x9DE8, 0x8DC9,
> - 0x7C26, 0x6C07, 0x5C64, 0x4C45, 0x3CA2, 0x2C83, 0x1CE0, 0x0CC1,
> - 0xEF1F, 0xFF3E, 0xCF5D, 0xDF7C, 0xAF9B, 0xBFBA, 0x8FD9, 0x9FF8,
> - 0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0,
> -};
> -
> -UINT16 MakeCrcCheckSum (
> - UINT8 *Buffer,
> - UINT32 Length
> - )
> -{
> - UINT16 StartCRC = 0;
> -
> - if (Length > SIZE_512KB) {
> -return 0;
> - }
> -
> - if (Buffer == NULL) {
> -return 0;
> - }
> -
> - while (Length) {
> -StartCRC = CrcTable16 [((UINT8) ((StartCRC >> 8) & 0xff)) ^ *(Buffer++)]
> ^
> - ((UINT16) (StartCRC << 8));
> -Length--;
> - }
> -
> - return StartCRC;
> -}
> -
> -
> EFI_STATUS
> OemGetMacE2prom(
>IN UINT32 Port,
> @@ -170,8 +111,8 @@ OemGetMacE2prom(
> return Status;
>}
>
> - Crc16 = MakeCrcCheckSum (
> -(UINT8 *)&(MacDesc.MacLen),
> + Crc16 = CalculateCrc16 (
> +&(MacDesc.MacLen),
> sizeof (MacDesc.MacLen) + sizeof (MacDesc.Mac)
> );
>if ((Crc16 != MacDesc.Crc16) || (Crc16 == 0)) {
> @@ -207,8 +148,8 @@ OemSetMacE2prom (
> MacDesc.Mac[I] = Addr[I];
>}
>
> - MacDesc.Crc16 = MakeCrcCheckSum (
> -(UINT8 *)&(MacDesc.MacLen),
> + MacDesc.Crc16 = CalculateCrc16 (
> +&(MacDesc.MacLen),
> sizeof (MacDesc.MacLen) + MAC_ADDR_LEN
> );
>
> --
> 2.9.5
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 14/16] Hisilicon/D0x: Remove SP805 watchdog pcd
On Fri, Feb 01, 2019 at 09:34:34PM +0800, Ming Huang wrote: > SP805 watchdog is no used for D0x, so remove it. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang Reviewed-by: Leif Lindholm > --- > Platform/Hisilicon/D03/D03.dsc | 3 --- > Platform/Hisilicon/D05/D05.dsc | 3 --- > Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf | 1 - > 3 files changed, 7 deletions(-) > > diff --git a/Platform/Hisilicon/D03/D03.dsc b/Platform/Hisilicon/D03/D03.dsc > index fe443dd929ad..35b54f8c83be 100644 > --- a/Platform/Hisilicon/D03/D03.dsc > +++ b/Platform/Hisilicon/D03/D03.dsc > @@ -149,9 +149,6 @@ [PcdsFixedAtBuild.common] > >gHisiTokenSpaceGuid.PcdPcieRootBridgeMask|0x7 # > bit0:HB0RB0,bit1:HB0RB1,bit2:HB0RB2,bit3:HB0RB3,bit4:HB1RB0,bit5:HB1RB1,bit6:HB1RB2,bit7:HB1RB3 > > - ## SP805 Watchdog - Motherboard Watchdog > - gArmPlatformTokenSpaceGuid.PcdSP805WatchdogBase|0x601e > - >## Serial Terminal >gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x2F8 >gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200 > diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc > index 0c4f21fbe056..49bd5b37ea34 100644 > --- a/Platform/Hisilicon/D05/D05.dsc > +++ b/Platform/Hisilicon/D05/D05.dsc > @@ -163,9 +163,6 @@ [PcdsFixedAtBuild.common] >gHisiTokenSpaceGuid.PcdPcieRootBridgeMask2P|0x34F4 # > bit0:HB0RB0,bit1:HB0RB1,bit2:HB0RB2,bit3:HB0RB3,bit4:HB0RB4,bit5:HB0RB5,bit6:HB0RB6,bit7:HB0RB7 > # > bit8:HB1RB0,bit9:HB1RB1,bit10:HB1RB2,bit11:HB1RB3,bit12:HB1RB4,bit13:HB1RB5,bit14:HB1RB6,bit14:HB1RB15 > > - ## SP805 Watchdog - Motherboard Watchdog > - gArmPlatformTokenSpaceGuid.PcdSP805WatchdogBase|0x601e > - >## Serial Terminal >gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x602B >gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200 > diff --git > a/Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf > b/Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf > index 3563df6e10d1..4ce5f5fea1f3 100644 > --- a/Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf > +++ b/Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf > @@ -61,5 +61,4 @@ [FixedPcd] >gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase >gHisiTokenSpaceGuid.PcdSysControlBaseAddress >gHisiTokenSpaceGuid.PcdPeriSubctrlAddress > - gArmPlatformTokenSpaceGuid.PcdSP805WatchdogBase > > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 13/16] Hisilicon/D06: Remove SECURE_BOOT_ENABLE definition
On Fri, Feb 01, 2019 at 09:34:33PM +0800, Ming Huang wrote:
> As secure boot is not ready, remove SECURE_BOOT_ENABLE and
> relative code.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
Reviewed-by: Leif Lindholm
> ---
> Platform/Hisilicon/D06/D06.dsc | 12
> Platform/Hisilicon/D06/D06.fdf | 11 ---
> 2 files changed, 23 deletions(-)
>
> diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc
> index 6d581337f199..a3a01bfb1e23 100644
> --- a/Platform/Hisilicon/D06/D06.dsc
> +++ b/Platform/Hisilicon/D06/D06.dsc
> @@ -30,7 +30,6 @@ [Defines]
>FLASH_DEFINITION =
> Platform/Hisilicon/$(PLATFORM_NAME)/$(PLATFORM_NAME).fdf
>DEFINE NETWORK_IP6_ENABLE = FALSE
>DEFINE HTTP_BOOT_ENABLE= FALSE
> - DEFINE SECURE_BOOT_ENABLE = FALSE
>
> !include Silicon/Hisilicon/Hisilicon.dsc.inc
>
> @@ -87,9 +86,6 @@ [LibraryClasses.common]
>LpcLib|Silicon/Hisilicon/Hi1620/Library/LpcLibHi1620/LpcLib.inf
>
> SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
>OemNicLib|Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.inf
> -!if $(SECURE_BOOT_ENABLE) == TRUE
> - FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
> -!endif
>PciExpressLib|MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf
>
> PciPlatformLib|Silicon/Hisilicon/Hi1620/Library/Hi1620PciPlatformLib/Hi1620PciPlatformLib.inf
>
> @@ -290,15 +286,7 @@ [Components.common]
>MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
>Platform/Hisilicon/D06/Drivers/OemNicConfig2PHi1620/OemNicConfig2P.inf
>
> -!if $(SECURE_BOOT_ENABLE) == TRUE
> - MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
> -
> -
> NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
> - }
> -
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
> -!else
>MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
> -!endif
>Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf
>MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
>
> diff --git a/Platform/Hisilicon/D06/D06.fdf b/Platform/Hisilicon/D06/D06.fdf
> index f72b513352fb..e402628a1b35 100644
> --- a/Platform/Hisilicon/D06/D06.fdf
> +++ b/Platform/Hisilicon/D06/D06.fdf
> @@ -88,17 +88,10 @@ [FD.D06]
>#Blockmap[1]: End
>0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>## This is the VARIABLE_STORE_HEADER
> -!if $(SECURE_BOOT_ENABLE) == TRUE
> - #Signature: gEfiAuthenticatedVariableGuid =
> - # { 0xaaf32c78, 0x947b, 0x439a, { 0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3,
> 0x77, 0x92 }}
> - 0x78, 0x2c, 0xf3, 0xaa, 0x7b, 0x94, 0x9a, 0x43,
> - 0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3, 0x77, 0x92,
> -!else
>#Signature: gEfiVariableGuid =
># { 0xddcf3616, 0x3275, 0x4164, { 0x98, 0xb6, 0xfe, 0x85, 0x70, 0x7f,
> 0xfe, 0x7d }}
>0x16, 0x36, 0xcf, 0xdd, 0x75, 0x32, 0x64, 0x41,
>0x98, 0xb6, 0xfe, 0x85, 0x70, 0x7f, 0xfe, 0x7d,
> -!endif
>#Size: 0xe000
> (gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize) - 0x48 (size
> of EFI_FIRMWARE_VOLUME_HEADER) = 0xdFB8
>0xB8, 0xdF, 0x00, 0x00,
>#FORMATTED: 0x5A #HEALTHY: 0xFE #Reserved: UINT16 #Reserved1: UINT32
> @@ -183,10 +176,6 @@ [FV.FvMain]
>INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
>INF
> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
>
> -!if $(SECURE_BOOT_ENABLE) == TRUE
> - INF
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
> -!endif
> -
>INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
>INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
>INF EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
> --
> 2.9.5
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 11/16] Hisilicon/D06: Add Setup Item "Support DPC"
On Fri, Feb 01, 2019 at 09:34:31PM +0800, Ming Huang wrote:
> Add setup item "Support DPC" to enable or disable PCIe DPC
> (Downstream Port Containment).
This patch also seems to disable the SRIOV configuration and delete a
lot of ports. Can you explain how this is related?
/
Leif
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Silicon/Hisilicon/Include/Library/OemConfigData.h | 1 +
> Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr | 2 -
> Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c | 4 +
> Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr| 197
> +---
> Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfigStrings.uni | 3 +-
> 5 files changed, 10 insertions(+), 197 deletions(-)
>
> diff --git a/Silicon/Hisilicon/Include/Library/OemConfigData.h
> b/Silicon/Hisilicon/Include/Library/OemConfigData.h
> index f120e3123c83..c0097d0829f0 100644
> --- a/Silicon/Hisilicon/Include/Library/OemConfigData.h
> +++ b/Silicon/Hisilicon/Include/Library/OemConfigData.h
> @@ -49,6 +49,7 @@ typedef struct {
>UINT8 OSWdtAction;
>/*PCIe Config*/
>UINT8 PcieSRIOVSupport;
> + UINT8 PcieDPCSupport;
>UINT8 PciePort[PCIE_MAX_TOTAL_PORTS];
>UINT8 PcieLinkSpeedPort[PCIE_MAX_TOTAL_PORTS];
>UINT8 PcieLinkDeEmphasisPort[PCIE_MAX_TOTAL_PORTS];
> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
> b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
> index 08236704fbfe..93ccb99bdc67 100644
> --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
> +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
> @@ -62,11 +62,9 @@ formset
>prompt = STRING_TOKEN(STR_IBMC_CONFIG_FORM_TITLE),
>help = STRING_TOKEN(STR_IBMC_CONFIG_FORM_HELP);
>
> -suppressif TRUE;
> goto PCIE_CONFIG_FORM_ID,
>prompt = STRING_TOKEN(STR_PCIE_CONFIG_FORM_TITLE),
>help= STRING_TOKEN(STR_PCIE_CONFIG_FORM_HELP);
> -endif;
>
> goto MISC_CONFIG_FORM_ID,
>prompt = STRING_TOKEN(STR_MISC_CONFIG_FORM_TITLE),
> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
> b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
> index 6668103af027..be4ce8820f73 100644
> --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
> +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
> @@ -290,6 +290,10 @@ OemConfigUiLibConstructor (
>Configuration.OSWdtTimeout = 5;
>Configuration.OSWdtAction = 1;
>//
> + //Set the default value of the PCIe option
> + //
> + Configuration.PcieDPCSupport = 0;
> + //
>//Set the default value of the Misc option
>//
>Configuration.EnableSmmu = 1;
> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr
> b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr
> index 7cf7cdd29ba2..c65907fe846e 100644
> --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr
> +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr
> @@ -17,203 +17,12 @@
> form formid = PCIE_CONFIG_FORM_ID,
>title = STRING_TOKEN (STR_PCIE_CONFIG_FORM_TITLE);
>
> - goto VFR_FORMID_PCIE_SOCKET0,
> -prompt = STRING_TOKEN (STR_PCIE_CPU_0_PROMPT),
> -help= STRING_TOKEN (STR_PCIE_CPU_PROMPT_HELP);
> -
> - goto VFR_FORMID_PCIE_SOCKET1,
> -prompt = STRING_TOKEN (STR_PCIE_CPU_1_PROMPT),
> -help= STRING_TOKEN (STR_PCIE_CPU_PROMPT_HELP);
> -
> - oneof varid = OEM_CONFIG_DATA.PcieSRIOVSupport,
> -prompt = STRING_TOKEN (STR_SRIOV_SUPPORT_PROMPT),
> -help = STRING_TOKEN (STR_SRIOV_SUPPORT_HELP),
> + oneof varid = OEM_CONFIG_DATA.PcieDPCSupport,
> +prompt = STRING_TOKEN (STR_DPC_SUPPORT_PROMPT),
> +help = STRING_TOKEN (STR_DPC_SUPPORT_HELP),
> option text = STRING_TOKEN (STR_DISABLE), value = 0, flags =
> MANUFACTURING | DEFAULT | RESET_REQUIRED;
> option text = STRING_TOKEN (STR_ENABLE), value = 1, flags =
> RESET_REQUIRED;
>endoneof;
>
> endform;
>
> -form formid = VFR_FORMID_PCIE_SOCKET0,
> - title = STRING_TOKEN(STR_PCIE_CPU_0_PROMPT);
> -
> - goto VFR_FORMID_PCIE_PORT2,
> -prompt = STRING_TOKEN(STR_PCIE_PORT_2_PROMPT),
> -help= STRING_TOKEN(STR_PCIE_PORT_PROMPT_HELP);
> -
> - goto VFR_FORMID_PCIE_PORT4,
> -prompt = STRING_TOKEN(STR_PCIE_PORT_4_PROMPT),
> -help= STRING_TOKEN(STR_PCIE_PORT_PROMPT_HELP);
> -
> - goto VFR_FORMID_PCIE_PORT5,
> -prompt = STRING_TOKEN(STR_PCIE_PORT_5_PROMPT),
> -help= STRING_TOKEN(STR_PCIE_PORT_PROMPT_HELP);
> -
> - goto VFR_FORMID_PCIE_PORT6,
> -prompt = STRING_TOKEN(STR_PCIE_PORT_6_PROMPT),
> -help= STRING_TOKEN(STR_PCIE_PORT_PROMPT_HELP);
> -
> - goto VFR_FORMID_PCIE_PORT7,
> -
Re: [edk2] [PATCH edk2-platforms v1 10/16] Hisilicon/D06: Modify for M7 self-Adapte support
On Fri, Feb 01, 2019 at 09:34:30PM +0800, Ming Huang wrote:
> As new M7(Cortex-M7) firmware support self-adapte, so do not
> need BIOS to implement some function, remove useless funtions
> and report CPU0/CPU1 Nic NCL offset to M7.
I don't really care that some other device in the system is a
Cortex-A7. What is its function? Is it an SCP, an MCP, ?
Please describe its function rather than its implementation.
What are the external dependencies?
Is this addressed by one of the patches for edk2-non-osi?
More style issues below.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c | 272
>
> 1 file changed, 45 insertions(+), 227 deletions(-)
>
> diff --git a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> index aaf990216982..9bf274e1b991 100644
> --- a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> +++ b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> @@ -21,44 +21,21 @@
> #include
>
> #define CPU2_SFP2_100G_CARD_OFFSET 0x25
> -#define CPU1_SFP1_LOCATE_OFFSET 0x16
> -#define CPU1_SFP0_LOCATE_OFFSET 0x12
> -#define CPU2_SFP1_LOCATE_OFFSET 0x21
> -#define CPU2_SFP0_LOCATE_OFFSET 0x19
> -#define CPU2_SFP2_10G_GE_CARD_OFFSET 0x25
>
> -#define SFP_10G_SPEED 10
> -#define SFP_25G_SPEED 25
> -#define SFP_100G_SPEED 100
> -#define SFP_GE_SPEED1
> -
> -#define SFP_GE_SPEED_VAL_VENDOR_FINISAR 0x0C
> -#define SFP_GE_SPEED_VAL0x0D
> -#define SFP_10G_SPEED_VAL 0x67
> -#define SFP_25G_SPEED_VAL 0xFF
> +#define SOCKET1_NET_PORT_100G 1
> +#define SOCKET0_NET_PORT_NUM 4
> +#define SOCKET1_NET_PORT_NUM 2
>
> #define CARD_PRESENT_100G (BIT7)
> -#define CARD_PRESENT_10G(BIT0)
> -#define SELECT_SFP_BY_INDEX(index) (1 << (index - 1))
> -#define SPF_SPEED_OFFSET12
> -
> -#define SFP_DEVICE_ADDRESS 0x50
> -#define CPU1_9545_I2C_ADDR 0x70
> -#define CPU2_9545_I2C_ADDR 0x71
> -
> -#define FIBER_PRESENT 0
> -#define CARD_PRESENT 1
> -#define I2C_PORT_SFP 4
> -#define CPU2_I2C_PORT_SFP 5
> -
> -#define SOCKET_0 0
> -#define SOCKET_1 1
> #define EEPROM_I2C_PORT 4
> #define EEPROM_PAGE_SIZE 0x40
> #define MAC_ADDR_LEN 6
> #define I2C_OFFSET_EEPROM_ETH0 (0xc00)
> #define I2C_SLAVEADDR_EEPROM (0x52)
>
> +#define SRAM_NIC_NCL1_OFFSET_FLAG 0xA0E87FE0
> +#define SRAM_NIC_NCL2_OFFSET_FLAG 0xA0E87FE4
Is this just a hard-coded address in SRAM? Where is it specified?
I don't think "_FLAG" is the correct name for this #define - this is
the actual offset value. So _OFFSET_ADDRESS would be more descriptive.
> +
> #pragma pack(1)
> typedef struct {
>UINT16 Crc16;
> @@ -114,204 +91,6 @@ UINT16 CrcTable16[256] = {
>0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0,
> };
>
> -EFI_STATUS
> -GetSfpSpeed (
> - UINT16 Socket,
> - UINT16 SfpNum,
> - UINT8* FiberSpeed
> - )
> -{
> - EFI_STATUS Status;
> - I2C_DEVICE SpdDev;
> - UINT8 SfpSelect;
> - UINT8 SfpSpeed;
> - UINT32 RegAddr;
> - UINT16 I2cAddr;
> - UINT32 SfpPort;
> -
> - SfpSpeed = 0x0;
> - if (Socket == SOCKET_1) {
> -I2cAddr = CPU2_9545_I2C_ADDR;
> -SfpPort = CPU2_I2C_PORT_SFP;
> - } else {
> -I2cAddr = CPU1_9545_I2C_ADDR;
> -SfpPort = I2C_PORT_SFP;
> - }
> -
> - Status = I2CInit (Socket, SfpPort, Normal);
> - if (EFI_ERROR (Status)) {
> -DEBUG ((DEBUG_ERROR, "[%a]:[%dL] Socket%d Call I2CInit failed!
> p1=0x%x.\n",
> -__FUNCTION__, __LINE__, Socket, Status));
> -return Status;
> - }
> -
> - SpdDev.Socket = Socket;
> - SpdDev.DeviceType = DEVICE_TYPE_SPD;
> - SpdDev.Port = SfpPort;
> - SpdDev.SlaveDeviceAddress = I2cAddr;
> - RegAddr = 0x0;
> - SfpSelect = SELECT_SFP_BY_INDEX (SfpNum);
> -
> - Status = I2CWrite (, RegAddr, 1, );
> - if (EFI_ERROR (Status)) {
> -DEBUG ((DEBUG_ERROR, "I2CWrite Error =%r.\n", Status));
> -return Status;
> - }
> -
> - SpdDev.Socket = Socket;
> - SpdDev.DeviceType = DEVICE_TYPE_SPD;
> - SpdDev.Port = SfpPort;
> - SpdDev.SlaveDeviceAddress = SFP_DEVICE_ADDRESS;
> -
> - RegAddr = SPF_SPEED_OFFSET;
> - Status = I2CRead (, RegAddr, 1, );
> - if (EFI_ERROR (Status)) {
> -DEBUG ((DEBUG_ERROR, "I2CRead Error =%r.\n", Status));
> -return Status;
> - }
> -
> - DEBUG ((DEBUG_INFO, "BR, Nominal, Nominal signalling rate, SfpSpeed:
> 0x%x\n",
> - SfpSpeed));
> -
> - if (SfpSpeed == SFP_10G_SPEED_VAL) {
> -*FiberSpeed = SFP_10G_SPEED;
> - } else if (SfpSpeed == SFP_25G_SPEED_VAL) {
> -*FiberSpeed = SFP_25G_SPEED;
> - } else if ((SfpSpeed == SFP_GE_SPEED_VAL) ||
> - (SfpSpeed == SFP_GE_SPEED_VAL_VENDOR_FINISAR)) {
> -*FiberSpeed = SFP_GE_SPEED;
> - }
>
Re: [edk2] [PATCH edk2-platforms] Silicon/SynQuacer/Stage2Tables: fix build for cross compile from x86
On Mon, Feb 11, 2019 at 07:33:22PM +0100, Ard Biesheuvel wrote: > AArch64 binutils support AArch32 seamlessly when running natively, > which allowed us to drop the -I objcopy argument specifying that > the input format is elf64-little, which is no longer accurate now > that the module can be built in 32-bit mode as well (which makes no > difference whatsoever given that the resulting binary image is only > a set of stage2 page tables) > > The same does not apply to binutils hosted on x86, so add back the > appropriate input format depending on the target type. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Acked-by: Leif Lindholm Tested-by: Leif Lindholm > --- > Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.inf | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.inf > b/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.inf > index f845015b9002..3e7039d586e1 100644 > --- a/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.inf > +++ b/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.inf > @@ -26,6 +26,8 @@ [Sources] > [BuildOptions] >*_*_*_OBJCOPY_PATH == objcopy >*_*_*_OBJCOPY_FLAGS == -O binary -j .rodata > + *_*_AARCH64_OBJCOPY_FLAGS = -I elf64-little > + *_*_ARM_OBJCOPY_FLAGS = -I elf32-little >*_*_*_ASM_FLAGS == -nostdlib > -Wl,-e,0x81f8000,--section-start=.rodata=0x81f8000 >*_CLANG35_*_ASM_FLAGS = -no-integrated-as >*_CLANG38_*_ASM_FLAGS = -no-integrated-as > -- > 2.20.1 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms] Silicon/Socionext: use variable attributes from Uefi/UefiMultiPhase.h
On Mon, Feb 11, 2019 at 07:03:09PM +0100, Ard Biesheuvel wrote: > On Mon, 11 Feb 2019 at 19:02, Leif Lindholm wrote: > > > > Use EFI variable attributes from Uefi/UefiMultiPhase.h in PlatformDxe > > .vfr rather than local definitions. > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Leif Lindholm > > Reviewed-by: Ard Biesheuvel Thanks, pushed as d7b29975f8. > > --- > > .../Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr | 9 > > + > > 1 file changed, 1 insertion(+), 8 deletions(-) > > > > diff --git > > a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr > > b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr > > index 8a395eac68..25b7b49a3d 100644 > > --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr > > +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr > > @@ -15,14 +15,7 @@ > > #include > > #include > > #include > > - > > -// > > -// EFI Variable attributes > > -// > > -#define EFI_VARIABLE_NON_VOLATILE 0x0001 > > -#define EFI_VARIABLE_BOOTSERVICE_ACCESS 0x0002 > > -#define EFI_VARIABLE_RUNTIME_ACCESS 0x0004 > > -#define EFI_VARIABLE_READ_ONLY 0x0008 > > +#include > > > > formset > >guid = SYNQUACER_PLATFORM_FORMSET_GUID, > > -- > > 2.11.0 > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 09/16] Hisilicon/D06: Add PCI_OSC_SUPPORT
On Fri, Feb 01, 2019 at 09:34:29PM +0800, Ming Huang wrote:
> Add PCI_OSC_SUPPORT for remaining host bridges to remove fail
> output in kernel:
> [ 103.478893] acpi PNP0A08:01: _OSC failed (AE_NOT_FOUND);
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl | 64
>
> 1 file changed, 64 insertions(+)
>
> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> index 4d9d9d95be68..86d8728b82f2 100644
> --- a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> +++ b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> @@ -17,6 +17,50 @@
> **/
>
> //#include "ArmPlatform.h"
> +
> +/*
> + See ACPI 6.1 Spec, 6.2.11, PCI Firmware Spec 3.0, 4.5
> +*/
> +#define PCI_OSC_SUPPORT() \
PCI0 and PCI6 already have _OSC entries.
This macro ends up being used for 1-5 and 7-B.
So calling it PCI_OSC_SUPPORT seems somewhat misleading.
Then again, there is a lot of similarities between this macro and the
existing entries. Could the same macro be used for 0 and 6? Or could
the macro be split up into multiple parts and reused?
/
Leif
> + Name(SUPP, Zero) /* PCI _OSC Support Field value */ \
> + Name(CTRL, Zero) /* PCI _OSC Control Field value */ \
> + Method(_OSC,4) { \
> +If(LEqual(Arg0,ToUUID("33DB4D5B-1FF7-401C-9657-7441C03DD766"))) { \
> + /* Create DWord-adressable fields from the Capabilities Buffer */ \
> + CreateDWordField(Arg3,0,CDW1) \
> + CreateDWordField(Arg3,4,CDW2) \
> + CreateDWordField(Arg3,8,CDW3) \
> + /* Save Capabilities DWord2 & 3 */ \
> + Store(CDW2,SUPP) \
> + Store(CDW3,CTRL) \
> + /* Only allow native hot plug control if OS supports: */ \
> + /* ASPM */ \
> + /* Clock PM */ \
> + /* MSI/MSI-X */ \
> + If(LNotEqual(And(SUPP, 0x16), 0x16)) { \
> +And(CTRL,0x1E,CTRL) \
> + }\
> + \
> + /* Do not allow native PME, AER */ \
> + /* Never allow SHPC (no SHPC controller in this system)*/ \
> + And(CTRL,0x10,CTRL) \
> + If(LNotEqual(Arg1,One)) { /* Unknown revision */ \
> +Or(CDW1,0x08,CDW1) \
> + } \
> + \
> + If(LNotEqual(CDW3,CTRL)) { /* Capabilities bits were masked */ \
> +Or(CDW1,0x10,CDW1) \
> + } \
> + \
> + /* Update DWORD3 in the buffer */ \
> + Store(CTRL,CDW3) \
> + Return(Arg3) \
> +} Else { \
> + Or(CDW1,4,CDW1) /* Unrecognized UUID */ \
> + Return(Arg3) \
> +} \
> + } // End _OSC
> +
> Scope(_SB)
> {
>Device (PCI0)
> @@ -270,6 +314,8 @@ Device (PCI1)
> Return (RBUF)
>} // Method(_CRS), this method
> return RBUF!
>
> + PCI_OSC_SUPPORT ()
> +
>Method (_STA, 0x0, NotSerialized)
>{
> Return (0xf)
> @@ -333,6 +379,8 @@ Device (PCI2)
> Return (RBUF)
>} // Method(_CRS), this method
> return RBUF!
>
> + PCI_OSC_SUPPORT ()
> +
>Method (_STA, 0x0, NotSerialized)
>{
> Return (0xf)
> @@ -382,6 +430,8 @@ Device (PCI3)
> Return (RBUF)
>} // Method(_CRS), this method
> return RBUF!
>
> + PCI_OSC_SUPPORT ()
> +
>Method (_STA, 0x0, NotSerialized)
>{
> Return (0xf)
> @@ -431,6 +481,8 @@ Device (PCI4)
> Return (RBUF)
>} // Method(_CRS), this method
> return RBUF!
>
> + PCI_OSC_SUPPORT ()
> +
>Method (_STA, 0x0, NotSerialized)
>{
> Return (0x0F)
> @@ -505,6 +557,8 @@ Device (PCI5)
> Return (RBUF)
>}// Method(_CRS), this method return
> RBUF!
>
> + PCI_OSC_SUPPORT ()
> +
>Method (_STA, 0x0, NotSerialized)
>{
> Return (0xf)
> @@ -1002,6 +1056,8 @@ Device (PCI7)
> Return (RBUF)
>} // Method(_CRS), this method
> return RBUF!
>
> + PCI_OSC_SUPPORT ()
> +
>Method (_STA, 0x0, NotSerialized)
>{
> Return (0xf)
> @@ -1066,6 +1122,8 @@ Device (PCI8)
> Return (RBUF)
>} // Method(_CRS), this method
> return RBUF!
>
> + PCI_OSC_SUPPORT ()
> +
>Method (_STA, 0x0, NotSerialized)
>{
> Return (0xf)
> @@ -1115,6 +1173,8 @@ Device (PCI9)
> Return (RBUF)
>} // Method(_CRS), this method
> return RBUF!
>
> + PCI_OSC_SUPPORT ()
> +
>Method (_STA, 0x0, NotSerialized)
>{
> Return (0xf)
> @@ -1164,6 +1224,8 @@ Device (PCIA)
> Return (RBUF)
>} // Method(_CRS), this method
> return RBUF!
>
> + PCI_OSC_SUPPORT ()
> +
>Method (_STA, 0x0, NotSerialized)
>{
> Return (0x0F)
> @@ -1238,6 +1300,8 @@ Device (PCIB)
> Return (RBUF)
>}
Re: [edk2] [PATCH edk2-platforms v1 08/16] Hisilicon/D06: Change HCCS speed from 30G to 26G
On Fri, Feb 01, 2019 at 09:34:28PM +0800, Ming Huang wrote:
> Follow chip team suggestion to change HCCS(Huawei Cache-Coherent
> System) speed from 30G to 26G, this modification can avoid some
> unstable stress issue.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Silicon/Hisilicon/Include/Library/OemMiscLib.h | 10 ++
> Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c | 8
> 2 files changed, 18 insertions(+)
>
> diff --git a/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> b/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> index dfac87d635d9..3c0cd0319122 100644
> --- a/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> +++ b/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> @@ -22,6 +22,11 @@
> #include
> #include
>
> +#define HCCS_PLL_VALUE_3000 0x52240781
> +#define HCCS_PLL_VALUE_2600 0x52240681
> +#define HCCS_PLL_VALUE_2800 0x52240701
Could these be described by a proper macro instead of just values?
A cursory glance suggests that an increase of 0x80 in the lower half
means 200MHz.
If not, please sort them by frequency, ascending.
> +
> +
> #define PCIEDEVICE_REPORT_MAX 8
> #define MAX_PROCESSOR_SOCKETS MAX_SOCKET
> #define MAX_MEMORY_CHANNELSMAX_CHANNEL
> @@ -55,4 +60,9 @@ extern EFI_STRING_ID
> gDimmToDevLocator[MAX_SOCKET][MAX_CHANNEL][MAX_DIMM];
> EFI_HII_HANDLE EFIAPI OemGetPackages ();
> UINTN OemGetCpuFreq (UINT8 Socket);
>
> +UINTN
> +OemGetHccsFreq (
> + VOID
> + );
> +
> #endif
> diff --git a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> index 8f2ac308c7b9..83e53cfeb5dd 100644
> --- a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> +++ b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> @@ -223,3 +223,11 @@ UINTN OemGetCpuFreq (UINT8 Socket)
>}
> }
>
> +UINTN
> +OemGetHccsFreq (
The commit message describes this patch as changing the frequency.
The actual code simply returns a value.
The name of the function returning this value suggests the value is a
frequency.
> + VOID
> + )
> +{
> + return HCCS_PLL_VALUE_2600;
But the constant returned is named suggesting a PLL configuration
value. And the frequency suggested by the name is many orders of
magnitude below that described by the commit message.
/
Leif
> +}
> +
> --
> 2.9.5
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms] Silicon/SynQuacer/Stage2Tables: fix build for cross compile from x86
AArch64 binutils support AArch32 seamlessly when running natively, which allowed us to drop the -I objcopy argument specifying that the input format is elf64-little, which is no longer accurate now that the module can be built in 32-bit mode as well (which makes no difference whatsoever given that the resulting binary image is only a set of stage2 page tables) The same does not apply to binutils hosted on x86, so add back the appropriate input format depending on the target type. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.inf | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.inf b/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.inf index f845015b9002..3e7039d586e1 100644 --- a/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.inf +++ b/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.inf @@ -26,6 +26,8 @@ [Sources] [BuildOptions] *_*_*_OBJCOPY_PATH == objcopy *_*_*_OBJCOPY_FLAGS == -O binary -j .rodata + *_*_AARCH64_OBJCOPY_FLAGS = -I elf64-little + *_*_ARM_OBJCOPY_FLAGS = -I elf32-little *_*_*_ASM_FLAGS == -nostdlib -Wl,-e,0x81f8000,--section-start=.rodata=0x81f8000 *_CLANG35_*_ASM_FLAGS = -no-integrated-as *_CLANG38_*_ASM_FLAGS = -no-integrated-as -- 2.20.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 07/16] Hisilicon/D0x: Rename StartupAp() function
On Fri, Feb 01, 2019 at 09:34:27PM +0800, Ming Huang wrote:
> As suggestion of community, 'AP' is a bit unfortunate to use in EDK2
> context. PI specifies 'BSP' for Boot-strap Processor, as the one
> executing all of the EDK2 code. It then uses 'AP' to refer to
> Additional Processors, which can be assigned tasks using the
> EFI_MP_SERVICES_PROTOCOL. In a TianoCore context, this should be 'BSP'.
> So, Rename StartupAp() to StartUpBSP.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
Reviewed-by: Leif Lindholm
Thanks!
> ---
> Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h | 2 +-
> Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.c | 2 +-
> Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.c | 2 +-
> Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.c | 2 +-
> Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.c | 3 ++-
> Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.c | 2 +-
> 6 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h
> b/Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h
> index a232e52ed719..712b77c44fc8 100644
> --- a/Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h
> +++ b/Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h
> @@ -76,7 +76,7 @@ VOID MN_CONFIG (VOID);
> VOID SmmuConfigForOS (VOID);
> VOID SmmuConfigForBios (VOID);
>
> -VOID StartupAp (VOID);
> +VOID StartUpBSP (VOID);
>
> VOID LlcCleanInvalidate (VOID);
>
> diff --git a/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.c
> b/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.c
> index 97cf6b8d8757..dacd9e871faf 100644
> --- a/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.c
> +++ b/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.c
> @@ -83,7 +83,7 @@ void QResetAp(VOID)
> //SCCL A
> if (!PcdGet64 (PcdTrustedFirmwareEnable))
> {
> -StartupAp();
> +StartUpBSP ();
> }
> }
>
> diff --git a/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.c
> b/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.c
> index b57fdfa68e45..c8a9da73bbca 100644
> --- a/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.c
> +++ b/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.c
> @@ -133,7 +133,7 @@ VOID CoreSelectBoot(VOID)
> {
> if (!PcdGet64 (PcdTrustedFirmwareEnable))
> {
> -StartupAp ();
> +StartUpBSP ();
> }
>
> return;
> diff --git a/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.c
> b/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.c
> index 76a055cbe980..b374347e5c4d 100644
> --- a/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.c
> +++ b/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.c
> @@ -35,7 +35,7 @@ QResetAp (
>(VOID)WriteBackInvalidateDataCacheRange((VOID *)
> FixedPcdGet64(PcdMailBoxAddress), 8);
>
>if (!PcdGet64 (PcdTrustedFirmwareEnable)) {
> -StartupAp();
> +StartUpBSP ();
>}
> }
>
> diff --git a/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.c
> b/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.c
> index 4c4c944dbead..a1458da7f0a3 100644
> --- a/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.c
> +++ b/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.c
> @@ -96,7 +96,7 @@ UINTN OemGetDimmSlot(UINTN Socket, UINTN Channel)
> VOID CoreSelectBoot(VOID)
> {
>if (!PcdGet64 (PcdTrustedFirmwareEnable)) {
> - StartupAp ();
> + StartUpBSP ();
>}
>
>return;
> @@ -128,3 +128,4 @@ BOOLEAN OemIsNeedDisableExpanderBuffer(VOID)
> {
>return TRUE;
> }
> +
> diff --git a/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.c
> b/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.c
> index 0790f7941ae7..a8261d370626 100644
> --- a/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.c
> +++ b/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.c
> @@ -78,7 +78,7 @@ QResetAp (
>
>//SCCL A
>if (!PcdGet64 (PcdTrustedFirmwareEnable)) {
> -StartupAp ();
> +StartUpBSP ();
>}
> }
>
> --
> 2.9.5
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms] Silicon/Socionext: use variable attributes from Uefi/UefiMultiPhase.h
On Mon, 11 Feb 2019 at 19:02, Leif Lindholm wrote: > > Use EFI variable attributes from Uefi/UefiMultiPhase.h in PlatformDxe > .vfr rather than local definitions. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Leif Lindholm Reviewed-by: Ard Biesheuvel > --- > .../Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr | 9 > + > 1 file changed, 1 insertion(+), 8 deletions(-) > > diff --git > a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr > b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr > index 8a395eac68..25b7b49a3d 100644 > --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr > +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr > @@ -15,14 +15,7 @@ > #include > #include > #include > - > -// > -// EFI Variable attributes > -// > -#define EFI_VARIABLE_NON_VOLATILE 0x0001 > -#define EFI_VARIABLE_BOOTSERVICE_ACCESS 0x0002 > -#define EFI_VARIABLE_RUNTIME_ACCESS 0x0004 > -#define EFI_VARIABLE_READ_ONLY 0x0008 > +#include > > formset >guid = SYNQUACER_PLATFORM_FORMSET_GUID, > -- > 2.11.0 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms] Silicon/Socionext: use variable attributes from Uefi/UefiMultiPhase.h
Use EFI variable attributes from Uefi/UefiMultiPhase.h in PlatformDxe .vfr rather than local definitions. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Leif Lindholm --- .../Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr | 9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr index 8a395eac68..25b7b49a3d 100644 --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr @@ -15,14 +15,7 @@ #include #include #include - -// -// EFI Variable attributes -// -#define EFI_VARIABLE_NON_VOLATILE 0x0001 -#define EFI_VARIABLE_BOOTSERVICE_ACCESS 0x0002 -#define EFI_VARIABLE_RUNTIME_ACCESS 0x0004 -#define EFI_VARIABLE_READ_ONLY 0x0008 +#include formset guid = SYNQUACER_PLATFORM_FORMSET_GUID, -- 2.11.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdePkg/BaseLib: implement SpeculationBarrier() for ARM and AArch64
On Mon, 11 Feb 2019 at 15:41, Leif Lindholm wrote: > > On Wed, Feb 06, 2019 at 12:08:22AM +, Ard Biesheuvel wrote: > > Replace the dummy C implementation of SpeculationBarrier() with > > implementations consisting of the recommended DSB SY + ISB sequence, > > as recommended by ARM in the whitepaper "Cache Speculation Side-channels" > > version 2.4, dated October 2018. > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Ard Biesheuvel > > Patch looks fine. > Reviewed-by: Leif Lindholm > > Question: do we expect performance impact to be sufficient to > motivate a Pcd to be able to disable the barrier on unaffected > processors? > Currently, these are only used on some codepaths in the MM component of the variable store, which do not look like hot paths to me. In general, I think it should be fine to defer doing something like this until someone highlights it as an actual problem (and has the numbers to prove it) > > --- > > MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S | 39 > > > > MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm | 38 > > +++ > > MdePkg/Library/BaseLib/Arm/SpeculationBarrier.S | 39 > > > > MdePkg/Library/BaseLib/Arm/SpeculationBarrier.asm | 39 > > > > MdePkg/Library/BaseLib/Arm/SpeculationBarrier.c | 30 --- > > MdePkg/Library/BaseLib/BaseLib.inf| 7 +++- > > 6 files changed, 160 insertions(+), 32 deletions(-) > > > > diff --git a/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S > > b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S > > new file mode 100644 > > index ..500bdadca5d2 > > --- /dev/null > > +++ b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S > > @@ -0,0 +1,39 @@ > > +##-- > > +# > > +# SpeculationBarrier() for AArch64 > > +# > > +# Copyright (c) 2019, Linaro Ltd. 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. > > +# > > +##-- > > + > > +.text > > +.p2align 2 > > + > > +GCC_ASM_EXPORT(SpeculationBarrier) > > + > > + > > +#/** > > +# Uses as a barrier to stop speculative execution. > > +# > > +# Ensures that no later instruction will execute speculatively, until all > > prior > > +# instructions have completed. > > +# > > +#**/ > > +#VOID > > +#EFIAPI > > +#SpeculationBarrier ( > > +# VOID > > +# ); > > +# > > +ASM_PFX(SpeculationBarrier): > > +dsb sy > > +isb > > +ret > > diff --git a/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm > > b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm > > new file mode 100644 > > index ..0c4b915b7798 > > --- /dev/null > > +++ b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm > > @@ -0,0 +1,38 @@ > > +;-- > > +; > > +; SpeculationBarrier() for AArch64 > > +; > > +; Copyright (c) 2019, Linaro Ltd. 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. > > +; > > +;-- > > + > > + EXPORT SpeculationBarrier > > + AREA BaseLib_LowLevel, CODE, READONLY > > + > > +;/** > > +; Uses as a barrier to stop speculative execution. > > +; > > +; Ensures that no later instruction will execute speculatively, until all > > prior > > +; instructions have completed. > > +; > > +;**/ > > +;VOID > > +;EFIAPI > > +;SpeculationBarrier ( > > +; VOID > > +; ); > > +; > > +SpeculationBarrier > > +dsb sy > > +isb > > +ret > > + > > + END > > diff --git a/MdePkg/Library/BaseLib/Arm/SpeculationBarrier.S > > b/MdePkg/Library/BaseLib/Arm/SpeculationBarrier.S > > new file mode 100644 > > index ..7857558aba17 > > --- /dev/null > > +++ b/MdePkg/Library/BaseLib/Arm/SpeculationBarrier.S > > @@ -0,0 +1,39 @@ > > +##-- > > +# > > +#
Re: [edk2] [PATCH] Maintainers: add TPM2 reviewers for OvmfPkg
On Mon, 11 Feb 2019 at 13:53, Laszlo Ersek wrote: > > OVMF can be built with a significant amount of TPM2 code now; add > Marc-André and Stefan as Reviewers for TPM2-related patches. > > Keep the list of "R" entries alphabetically sorted. > > Cc: Andrew Fish > Cc: Ard Biesheuvel > Cc: Jordan Justen > Cc: Leif Lindholm > Cc: Marc-André Lureau > Cc: Michael D Kinney > Cc: Stefan Berger > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Laszlo Ersek Acked-by: Ard Biesheuvel > --- > Maintainers.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Maintainers.txt b/Maintainers.txt > index 3b2676bc32ea..92f683827923 100644 > --- a/Maintainers.txt > +++ b/Maintainers.txt > @@ -214,14 +214,16 @@ M: Ray Ni > OvmfPkg > W: http://www.tianocore.org/ovmf/ > M: Jordan Justen > M: Laszlo Ersek > M: Ard Biesheuvel > R: Anthony Perard > R: Julien Grall > +R: Marc-André Lureau > +R: Stefan Berger > S: Maintained > > PcAtChipsetPkg > W: https://github.com/tianocore/tianocore.github.io/wiki/PcAtChipsetPkg > M: Ray Ni > > QuarkPlatformPkg, QuarkSocPkg > -- > 2.19.1.3.g30247aa5d201 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 06/16] Hisilicon/D06: Add OemGetCpuFreq to encapsulate difference
On Fri, Feb 01, 2019 at 09:34:26PM +0800, Ming Huang wrote:
> From: xingjiang tang
>
> Implementation OemGetCpuFreq() to get cpu frequency from cpld to
> encapsulate project difference, for some projects don't support
> get cpu frequency by this way.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Platform/Hisilicon/D06/Include/Library/CpldD06.h | 4
> Silicon/Hisilicon/Include/Library/OemMiscLib.h | 2 ++
> Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c | 16
>
> 3 files changed, 22 insertions(+)
>
> diff --git a/Platform/Hisilicon/D06/Include/Library/CpldD06.h
> b/Platform/Hisilicon/D06/Include/Library/CpldD06.h
> index ec9b49f4e70d..4d07a8ab3741 100644
> --- a/Platform/Hisilicon/D06/Include/Library/CpldD06.h
> +++ b/Platform/Hisilicon/D06/Include/Library/CpldD06.h
> @@ -36,4 +36,8 @@
> #define CPLD_X8_X8_X8_BOARD_ID0x92
> #define CPLD_X16_X8_BOARD_ID 0x93
>
> +#define CPLD_CLOCK_FLAG 0xFD
> +#define CPLD_BOM_VER_FLAG0x0B
> +#define BRD_VER_4TH 0x4
What is BRD_VER_4TH? Please write out full words.
Also, this macro needs a CPLD_ prefix.
> +
> #endif /* __CPLDD06_H__ */
> diff --git a/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> b/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> index 86ea6a1b3deb..dfac87d635d9 100644
> --- a/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> +++ b/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> @@ -53,4 +53,6 @@ BOOLEAN OemIsNeedDisableExpanderBuffer(VOID);
>
> extern EFI_STRING_ID gDimmToDevLocator[MAX_SOCKET][MAX_CHANNEL][MAX_DIMM];
> EFI_HII_HANDLE EFIAPI OemGetPackages ();
> +UINTN OemGetCpuFreq (UINT8 Socket);
> +
> #endif
> diff --git a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> index 2a9db46d1ff9..8f2ac308c7b9 100644
> --- a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> +++ b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> @@ -207,3 +207,19 @@ OemIsNeedDisableExpanderBuffer (
> {
>return TRUE;
> }
> +
> +UINTN OemGetCpuFreq (UINT8 Socket)
> +{
> + UINT8 BrdVerData;
Write out full words.
> +
> + BrdVerData = MmioRead8(CPLD_BASE_ADDRESS + CPLD_BOM_VER_FLAG);
Space before (.
> +
> + if (BrdVerData >= BRD_VER_4TH){ //2.5G
What is the comment saying? The number below?
The number below is also saying the number below.
A useful comment would be
"// Board revision 4 and higher run at 2.5GHz
// Earlier revisions run at 2GHz"
At that point you don't even need the #define.
And not really the temporary variable either.
> +return 25;
> + }
> + else
> + {
} else {
/
Leif
> + return 20;
> + }
> +}
> +
> --
> 2.9.5
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 05/16] Hisilicon/D06: Add more PCIe port INT-x support
On Fri, Feb 01, 2019 at 09:34:25PM +0800, Ming Huang wrote:
> From: Jason Zhang
>
> Since NVMe riser width is 6*X4, need add the related
> port's INT-x support to match OS driver.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl | 65
> +++-
> 1 file changed, 50 insertions(+), 15 deletions(-)
>
> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> index 27fde2e09bfe..4d9d9d95be68 100644
> --- a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> +++ b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> @@ -41,11 +41,21 @@ Scope(_SB)
>// adding RPx INTx configure deponds on hardware board topology,
>// if UEFI enables RPx, RPy, RPz... related INTx configure
>// should be added
> + Package () {0x2,0,0,640}, // INT_A
> + Package () {0x2,1,0,641}, // INT_B
> + Package () {0x2,2,0,642}, // INT_C
> + Package () {0x2,3,0,643}, // INT_D
> +
>Package () {0x4,0,0,640}, // INT_A
>Package () {0x4,1,0,641}, // INT_B
>Package () {0x4,2,0,642}, // INT_C
>Package () {0x4,3,0,643}, // INT_D
>
> + Package () {0x6,0,0,640}, // INT_A
> + Package () {0x6,1,0,641}, // INT_B
> + Package () {0x6,2,0,642}, // INT_C
> + Package () {0x6,3,0,643}, // INT_D
> +
>Package () {0x8,0,0,640}, // INT_A
>Package () {0x8,1,0,641}, // INT_B
>Package () {0x8,2,0,642}, // INT_C
> @@ -56,6 +66,11 @@ Scope(_SB)
>Package () {0xC,2,0,642}, // INT_C
>Package () {0xC,3,0,643}, // INT_D
>
> + Package () {0xE,0,0,640}, // INT_A
> + Package () {0xE,1,0,641}, // INT_B
> + Package () {0xE,2,0,642}, // INT_C
> + Package () {0xE,3,0,643}, // INT_D
> +
>Package () {0x10,0,0,640}, // INT_A
>Package () {0x10,1,0,641}, // INT_B
>Package () {0x10,2,0,642}, // INT_C
> @@ -759,26 +774,46 @@ Device (PCI6)
> // adding RPx INTx configure deponds on hardware board topology,
> // if UEFI enables RPx, RPy, RPz... related INTx configure
> // should be added
> -Package () {0x04,0,0,640}, // INT_A
> -Package () {0x04,1,0,641}, // INT_B
> -Package () {0x04,2,0,642}, // INT_C
> -Package () {0x04,3,0,643}, // INT_D
> -
> -Package () {0x08,0,0,640}, // INT_A
> -Package () {0x08,1,0,641}, // INT_B
> -Package () {0x08,2,0,642}, // INT_C
> -Package () {0x08,3,0,643}, // INT_D
> -
> -Package () {0x0C,0,0,640}, // INT_A
> -Package () {0x0C,1,0,641}, // INT_B
> -Package () {0x0C,2,0,642}, // INT_C
> -Package () {0x0C,3,0,643}, // INT_D
Please don't include the non-functional change of dropping the leading
0 (0x0 -> 0x) here together with the functional change of adding new
entries. Please submit as a separate patch.
/
Leif
> +Package () {0x2,0,0,640}, // INT_A
> +Package () {0x2,1,0,641}, // INT_B
> +Package () {0x2,2,0,642}, // INT_C
> +Package () {0x2,3,0,643}, // INT_D
> +
> +Package () {0x4,0,0,640}, // INT_A
> +Package () {0x4,1,0,641}, // INT_B
> +Package () {0x4,2,0,642}, // INT_C
> +Package () {0x4,3,0,643}, // INT_D
> +
> +Package () {0x6,0,0,640}, // INT_A
> +Package () {0x6,1,0,641}, // INT_B
> +Package () {0x6,2,0,642}, // INT_C
> +Package () {0x6,3,0,643}, // INT_D
> +
> +Package () {0x8,0,0,640}, // INT_A
> +Package () {0x8,1,0,641}, // INT_B
> +Package () {0x8,2,0,642}, // INT_C
> +Package () {0x8,3,0,643}, // INT_D
> +
> +Package () {0xC,0,0,640}, // INT_A
> +Package () {0xC,1,0,641}, // INT_B
> +Package () {0xC,2,0,642}, // INT_C
> +Package () {0xC,3,0,643}, // INT_D
> +
> +Package () {0xE,0,0,640}, // INT_A
> +Package () {0xE,1,0,641}, // INT_B
> +Package () {0xE,2,0,642}, // INT_C
> +Package () {0xE,3,0,643}, // INT_D
>
> Package () {0x10,0,0,640}, // INT_A
> Package () {0x10,1,0,641}, // INT_B
> Package () {0x10,2,0,642}, // INT_C
> Package () {0x10,3,0,643}, // INT_D
> - })
> +
> +Package ()
Re: [edk2] [PATCH edk2-platforms 6/8] Silicon/SynQuacer/Stage2Tables: fix 32-bit build
On Mon, Jan 14, 2019 at 06:52:07PM +0100, Ard Biesheuvel wrote: > On Mon, 14 Jan 2019 at 18:02, Ard Biesheuvel > wrote: > > > > The static stage2 page tables don't contain any code, but we are > > relying on the linker to resolve the references to the next level > > tables, so we can only use native word size quantities. So add a > > CPP macro to emit the same quantity in different ways. > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Ard Biesheuvel > > --- > > Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.S | 12 +--- > > The 'elf64-little' in the .inf is now wrong as well, but it seems I > can just remove that and objcopy will detect the input format. Hmm. Actually, no. When cross-compiling: $ objcopy -O binary -j .rodata /work/git/tianocore/Build/DeveloperBox/DEBUG_GCC5/AARCH64/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables/OUTPUT/Stage2Tables.elf /work/git/tianocore/Build/DeveloperBox/DEBUG_GCC5/AARCH64/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables/OUTPUT/Stage2Tables.bin objcopy: Unable to recognise the format of the input file `/work/git/tianocore/Build/DeveloperBox/DEBUG_GCC5/AARCH64/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables/OUTPUT/Stage2Tables.elf' If I put -I elf64-little back, the command succeeds. If I explicitly call the cross-toolchain objcopy, the command succeeds without that addition. When building natively, this works fine without the flag. Why do we even end up running the build machine native objcopy here? / Leif > > 1 file changed, 9 insertions(+), 3 deletions(-) > > > > diff --git a/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.S > > b/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.S > > index af55f27bca47..28c7a6ac970f 100644 > > --- a/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.S > > +++ b/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.S > > @@ -32,6 +32,12 @@ > > #define TT_S2_L3_PAGE (0x1 << 1) > > #define TT_S2_VALID (0x1 << 0) > > > > +#ifdef __aarch64__ > > +#define QWORD(x).quad (x) > > +#else > > +#define QWORD(x).long (x), 0 > > +#endif > > + > >.altmacro > >.macrofor, start, count, do, arg2, arg3, arg4 > >.if \count == 1 > > @@ -69,7 +75,7 @@ > >.section ".rodata", "a", %progbits > >/* level 1 */ > >s2_mem_entry 0 /* 0x_ - 0x3fff_ */ > > - .quad 1f + TT_S2_TABLE /* 0x4000_ - 0x7fff_ */ > > + QWORD (1f + TT_S2_TABLE) /* 0x4000_ - 0x7fff_ */ > >for 2, 246, s2_mem_entry /* 0x8000_ - 0x3d__ */ > >for 248, 8, s2_dev_entry /* PCIe MMIO64 */ > >for 256, 768, s2_mem_entry /* 0x40__ - 0xff__ */ > > @@ -77,12 +83,12 @@ > >/* level 2 */ > > 1:for 0, 256, s2_mem_entry, 21, 0x4000, 1 > > > > - .quad 2f + TT_S2_TABLE /* 0x6000_ -> RC #0 bus 0 */ > > + QWORD (2f + TT_S2_TABLE) /* 0x6000_ -> RC #0 bus 0 */ > >for 1, 15, s2_mem_entry, 21, 0x6000 > >for 0, 48, s2_mem_entry, 21, 0x6200, 1 > >for 0, 64, s2_dev_entry, 21, 0x6800, 1 /* PCIe MMIO32 */ > > > > - .quad 3f + TT_S2_TABLE /* 0x7000_ -> RC #1 bus 0 */ > > + QWORD (3f + TT_S2_TABLE) /* 0x7000_ -> RC #1 bus 0 */ > >for 1, 15, s2_mem_entry, 21, 0x7000 > >for 0, 48, s2_mem_entry, 21, 0x7200, 1 > >for 0, 64, s2_dev_entry, 21, 0x7800, 1 /* PCIe MMIO32 */ > > -- > > 2.17.1 > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] Maintainers: add TPM2 reviewers for OvmfPkg
On 02/11/19 14:06, Leif Lindholm wrote: > On Mon, Feb 11, 2019 at 01:53:43PM +0100, Laszlo Ersek wrote: >> OVMF can be built with a significant amount of TPM2 code now; add >> Marc-André and Stefan as Reviewers for TPM2-related patches. >> >> Keep the list of "R" entries alphabetically sorted. > > For this patch: > Reviewed-by: Leif Lindholm > > However - unrelated sidenote: Julien, is that address still valid for > you? FWIW, I haven't received "recipient invalid" or similar errors from the Linaro mail system. Thanks, Laszlo > > / > Leif > >> Cc: Andrew Fish >> Cc: Ard Biesheuvel >> Cc: Jordan Justen >> Cc: Leif Lindholm >> Cc: Marc-André Lureau >> Cc: Michael D Kinney >> Cc: Stefan Berger >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Laszlo Ersek >> --- >> Maintainers.txt | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/Maintainers.txt b/Maintainers.txt >> index 3b2676bc32ea..92f683827923 100644 >> --- a/Maintainers.txt >> +++ b/Maintainers.txt >> @@ -214,14 +214,16 @@ M: Ray Ni >> OvmfPkg >> W: http://www.tianocore.org/ovmf/ >> M: Jordan Justen >> M: Laszlo Ersek >> M: Ard Biesheuvel >> R: Anthony Perard >> R: Julien Grall >> +R: Marc-André Lureau >> +R: Stefan Berger >> S: Maintained >> >> PcAtChipsetPkg >> W: https://github.com/tianocore/tianocore.github.io/wiki/PcAtChipsetPkg >> M: Ray Ni >> >> QuarkPlatformPkg, QuarkSocPkg >> -- >> 2.19.1.3.g30247aa5d201 >> > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] BaseTools: handling of $(ARCH) in .dsc/.fdf when multiple -a specified
Leif: I will check BaseTools implementation and share more information on how to handle ARCH when multiple ARCH are specified. Thanks Liming > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo > Ersek > Sent: Tuesday, February 5, 2019 7:36 PM > To: Leif Lindholm > Cc: edk2-devel@lists.01.org; Gao, Liming > Subject: Re: [edk2] BaseTools: handling of $(ARCH) in .dsc/.fdf when multiple > -a specified > > On 02/05/19 12:08, Leif Lindholm wrote: > > On Mon, Feb 04, 2019 at 08:02:55PM +0100, Laszlo Ersek wrote: > > >> AIUI, "-a IA32 -a X64" it means "build the Components.* sections > >> (plural) as dictated by the '-a' flags, and then organize the full > >> (multi-arch) set of modules into the flash device(s), described by > >> FLASH_DEFINITION". > > > > Nope, I did spot that actually :) > > Although I was certainly confused the first 10 times I looked at those > > .dscs. > > > > And it could still be squashed into a common .dsc/.fdf if there was a > > useful way of handling $(ARCH) when multiple -a have been specified to > > the build command. > > I agree. > > Thanks > Laszlo > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 02/16] Hisilicon/D0x: Add DriverHealthManagerDxe
On Fri, Feb 01, 2019 at 09:34:22PM +0800, Ming Huang wrote:
> DriverHealthManagerDxe Collect driver health form of third party
> drivers to repair no healthy card.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
Reviewed-by: Leif Lindholm
> ---
> Platform/Hisilicon/D03/D03.dsc | 1 +
> Platform/Hisilicon/D05/D05.dsc | 1 +
> Platform/Hisilicon/D06/D06.dsc | 1 +
> Platform/Hisilicon/D03/D03.fdf | 1 +
> Platform/Hisilicon/D05/D05.fdf | 1 +
> Platform/Hisilicon/D06/D06.fdf | 1 +
> 6 files changed, 6 insertions(+)
>
> diff --git a/Platform/Hisilicon/D03/D03.dsc b/Platform/Hisilicon/D03/D03.dsc
> index 3f59be22ec8e..fe443dd929ad 100644
> --- a/Platform/Hisilicon/D03/D03.dsc
> +++ b/Platform/Hisilicon/D03/D03.dsc
> @@ -492,6 +492,7 @@ [Components.common]
>
>MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> + MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
>
> SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.inf {
>
> diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc
> index 25db1c38d287..0c4f21fbe056 100644
> --- a/Platform/Hisilicon/D05/D05.dsc
> +++ b/Platform/Hisilicon/D05/D05.dsc
> @@ -638,6 +638,7 @@ [Components.common]
>MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
>MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> + MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
>
>
> SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.inf {
> diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc
> index cbbd99e4a659..6d581337f199 100644
> --- a/Platform/Hisilicon/D06/D06.dsc
> +++ b/Platform/Hisilicon/D06/D06.dsc
> @@ -435,6 +435,7 @@ [Components.common]
>
> Silicon/Hisilicon/Hi1620/Drivers/Pl011DebugSerialPortInitDxe/Pl011DebugSerialPortInitDxe.inf
>MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> + MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
>
> SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.inf {
>
> diff --git a/Platform/Hisilicon/D03/D03.fdf b/Platform/Hisilicon/D03/D03.fdf
> index f453f9e46321..3f07b2e57778 100644
> --- a/Platform/Hisilicon/D03/D03.fdf
> +++ b/Platform/Hisilicon/D03/D03.fdf
> @@ -295,6 +295,7 @@ [FV.FvMain]
>INF
> MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
>INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> + INF
> MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
>
> [FV.FVMAIN_COMPACT]
> diff --git a/Platform/Hisilicon/D05/D05.fdf b/Platform/Hisilicon/D05/D05.fdf
> index 85dd791564a4..9632aea4b00e 100644
> --- a/Platform/Hisilicon/D05/D05.fdf
> +++ b/Platform/Hisilicon/D05/D05.fdf
> @@ -314,6 +314,7 @@ [FV.FvMain]
>INF
> MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
>INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> + INF
> MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
>
> [FV.FVMAIN_COMPACT]
> diff --git a/Platform/Hisilicon/D06/D06.fdf b/Platform/Hisilicon/D06/D06.fdf
> index fda29ab322e9..a937660a09e2 100644
> --- a/Platform/Hisilicon/D06/D06.fdf
> +++ b/Platform/Hisilicon/D06/D06.fdf
> @@ -319,6 +319,7 @@ [FV.FvMain]
>INF
> MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
>INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> + INF
> MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
>
> [FV.FVMAIN_COMPACT]
> --
> 2.9.5
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 01/16] Hisilicon/D0x: Remove SerdesLib
On Fri, Feb 01, 2019 at 09:34:21PM +0800, Ming Huang wrote: > SerdesLib is useless for SmbiosMiscDxe and D06, so remove it. Should it not then also delete #include from Platform/Hisilicon/D06/Library/OemMiscLibD06/BoardFeatureD06.c, Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c and Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/Type09/MiscSystemSlotDesignationFunction.c ? Meanwhile, Platform/Hisilicon/D03/Library/OemMiscLib2P/BoardFeature2PHi1610.c and Platform/Hisilicon/D05/Library/OemMiscLibD05/BoardFeatureD05.c both include this header, but Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf and Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf do not declare the dependency. Can you investigate and submit an updated patch addressing all of the unnecessary references? Best Regards, Leif > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang > --- > Platform/Hisilicon/D06/D06.dsc | 2 -- > Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf | 1 - > 2 files changed, 3 deletions(-) > > diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc > index 396bd03c9d24..cbbd99e4a659 100644 > --- a/Platform/Hisilicon/D06/D06.dsc > +++ b/Platform/Hisilicon/D06/D06.dsc > @@ -64,8 +64,6 @@ [LibraryClasses.common] > >CpldIoLib|Silicon/Hisilicon/Library/CpldIoLib/CpldIoLib.inf > > - SerdesLib|Silicon/Hisilicon/Hi1620/Library/Hi1620Serdes/Hi1620SerdesLib.inf > - >TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf > > RealTimeClockLib|Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.inf >OemMiscLib|Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.inf > diff --git a/Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf > b/Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf > index 61cead7779b9..8e5c56fa41fd 100644 > --- a/Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf > +++ b/Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf > @@ -77,7 +77,6 @@ [LibraryClasses] > >IpmiCmdLib > > - SerdesLib > > [Protocols] >gEfiSmbiosProtocolGuid # PROTOCOL ALWAYS_CONSUMED > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 12/16] Hisilicon/D06: Use new flash layout
On Fri, Feb 01, 2019 at 09:34:32PM +0800, Ming Huang wrote: > In new flash layout, BIOS fd change from offset 1M to 8M in 16M > spi flash. This bit > Use the new CustomData.Fv which indicate the offset > of fd and which flash area can be updated for BMC. is of critical importance. Should be its own paragraph. How does this change affect variable storage? Will the server maintain state after a firmware upgrade, or will the operator need to rescue it manually via the BMC? / Leif > > This patch is relative with patch "Use new flash layout" in > edk2-non-osi. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang > --- > Platform/Hisilicon/D06/D06.fdf | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Platform/Hisilicon/D06/D06.fdf b/Platform/Hisilicon/D06/D06.fdf > index d495ad7f264c..f72b513352fb 100644 > --- a/Platform/Hisilicon/D06/D06.fdf > +++ b/Platform/Hisilicon/D06/D06.fdf > @@ -29,7 +29,7 @@ [DEFINES] > > > [FD.D06] > > -BaseAddress = 0x20410|gArmTokenSpaceGuid.PcdFdBaseAddress # The base > address of the Firmware in NOR Flash. > +BaseAddress = 0x20480|gArmTokenSpaceGuid.PcdFdBaseAddress # The base > address of the Firmware in NOR Flash. > > Size = 0x0040|gArmTokenSpaceGuid.PcdFdSize # The size > in bytes of the FLASH Device > ErasePolarity = 1 > @@ -124,7 +124,7 @@ [FD.D06] > 0x003E|0x0001 > > 0x003F|0x0001 > -FILE = Platform/Hisilicon/D0x-CustomData.Fv > +FILE = Platform/Hisilicon/D06/CustomData.Fv > > > > # > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-non-osi v1 6/7] Hisilicon/D06: Fix numa node wrong issue
*bangs head on desk*
That question I just asked as a reply to
("Silicon/Hisilicon/D06: Set TA as Node 0 for TA boot")
was meant to be a comment on this patch.
So - was this change one that was meant to happen together with
edk2-platforms "Silicon/Hisilicon/D06: Set TA as Node 0 for TA boot"?
What is the user visible behaviour that this change addresses?
/
Leif
On Fri, Feb 01, 2019 at 10:25:06PM +0800, Ming Huang wrote:
> Numa informations are acquired from HOB that build from memory
> initialization module. Correct numa informations to match booting
> from TA(Totem A or super cpu cluster A).
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi | Bin 297696 -> 358656
> bytes
> 1 file changed, 0 insertions(+), 0 deletions(-)
>
> diff --git a/Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi
> b/Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi
> index 5fba353..fea1475 100644
> Binary files a/Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi and
> b/Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi differ
> --
> 2.9.5
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v3 4/5] Silicon/Hisilicon/D06: Set TA as Node 0 for TA boot
On Tue, Nov 20, 2018 at 05:01:49PM +0800, Ming Huang wrote:
> Linux kernel will recognize NUMA node by processor order,
> and the Node and proximity domain (PXM) will be not identical
> between BIOS and OS kernel after changing to TA(Totem A) boot,
> so adjust the NUMA node number and proximity domain (PXM) to
> match.
Is this a change that should have gone in together with edk2-platforms
cc2b26de91e09be9f9789d553e7b3e079c822efb?
("Silicon/Hisilicon/D06: Set TA as Node 0 for TA boot")
What is the visible effect to a user of the partial change?
Failure to boot? Poor performance?
/
Leif
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl | 28 +--
> Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Hi1620Iort.asl | 18 +-
> Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Hi1620Srat.aslc| 194
> ++--
> 3 files changed, 120 insertions(+), 120 deletions(-)
>
> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> index 87a2da8843e4..27fde2e09bfe 100644
> --- a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> +++ b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> @@ -212,7 +212,7 @@ Scope(_SB)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x01)
> +Return(0x00)
>}
> } // Device(PCI0)
>
> @@ -262,7 +262,7 @@ Device (PCI1)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x01)
> +Return(0x00)
>}
> } // Device(PCI1)
>
> @@ -325,7 +325,7 @@ Device (PCI2)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x01)
> +Return(0x00)
>}
> }
>
> @@ -374,7 +374,7 @@ Device (PCI3)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x01)
> +Return(0x00)
>}
> }
>
> @@ -423,7 +423,7 @@ Device (PCI4)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x01)
> +Return(0x00)
>}
> }
>
> @@ -733,7 +733,7 @@ Device (PCI5)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x01)
> +Return(0x00)
>}
> }
>
> @@ -866,11 +866,11 @@ Device (PCI6)
> // Never allow SHPC (no SHPC controller in this system)
> And(CTRL,0x1D,CTRL)
>
> -If(LNotEqual(Arg1,One)) { // Unknown revision
> +If(LNotEqual(Arg1,One)) { // Unknown revision
>Or(CDW1,0x08,CDW1)
> }
>
> -If(LNotEqual(CDW3,CTRL)) { // Capabilities bits were masked
> +If(LNotEqual(CDW3,CTRL)) { // Capabilities bits were masked
>Or(CDW1,0x10,CDW1)
> }
>
> @@ -924,7 +924,7 @@ Device (PCI6)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x03)
> +Return(0x02)
>}
> } // Device(PCI6)
>
> @@ -974,7 +974,7 @@ Device (PCI7)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x03)
> +Return(0x02)
>}
> } // Device(PCI7)
>
> @@ -1038,7 +1038,7 @@ Device (PCI8)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x03)
> +Return(0x02)
>}
> }// Device(PCI8)
>
> @@ -1087,7 +1087,7 @@ Device (PCI9)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x03)
> +Return(0x02)
>}
> }// Device(PCI9)
>
> @@ -1136,7 +1136,7 @@ Device (PCIA)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x03)
> +Return(0x02)
>}
> }// Device(PCIA)
>
> @@ -1210,7 +1210,7 @@ Device (PCIB)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x03)
> +Return(0x02)
>}
> }
>
> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Hi1620Iort.asl
> b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Hi1620Iort.asl
> index 08e15c17bf40..994018db96b5 100644
> --- a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Hi1620Iort.asl
> +++ b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Hi1620Iort.asl
> @@ -53,7 +53,7 @@
> [0004] PRI Interrupt :
> [0004] GERR Interrupt :
> [0004] Sync Interrupt :
> -[0004] Proximity Domain : 0001
> +[0004] Proximity Domain :
> [0004] DeviceID mapping index : 0002
>
> [0004] Input base :
> @@ -97,7 +97,7 @@
> [0004] PRI Interrupt :
> [0004] GERR Interrupt :
> [0004] Sync Interrupt :
> -[0004] Proximity Domain : 0001
> +[0004] Proximity Domain :
> [0004] DeviceID mapping index : 0001
>
> [0004] Input base : 7c00
> @@ -135,7 +135,7 @@
> [0004] PRI Interrupt :
> [0004] GERR Interrupt :
> [0004] Sync Interrupt :
> -[0004] Proximity Domain : 0001
> +[0004] Proximity Domain :
Re: [edk2] [PATCH] MdePkg/BaseLib: implement SpeculationBarrier() for ARM and AArch64
On Wed, Feb 06, 2019 at 12:08:22AM +, Ard Biesheuvel wrote: > Replace the dummy C implementation of SpeculationBarrier() with > implementations consisting of the recommended DSB SY + ISB sequence, > as recommended by ARM in the whitepaper "Cache Speculation Side-channels" > version 2.4, dated October 2018. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Patch looks fine. Reviewed-by: Leif Lindholm Question: do we expect performance impact to be sufficient to motivate a Pcd to be able to disable the barrier on unaffected processors? Regards, Leif > --- > MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S | 39 > > MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm | 38 > +++ > MdePkg/Library/BaseLib/Arm/SpeculationBarrier.S | 39 > > MdePkg/Library/BaseLib/Arm/SpeculationBarrier.asm | 39 > > MdePkg/Library/BaseLib/Arm/SpeculationBarrier.c | 30 --- > MdePkg/Library/BaseLib/BaseLib.inf| 7 +++- > 6 files changed, 160 insertions(+), 32 deletions(-) > > diff --git a/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S > b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S > new file mode 100644 > index ..500bdadca5d2 > --- /dev/null > +++ b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S > @@ -0,0 +1,39 @@ > +##-- > +# > +# SpeculationBarrier() for AArch64 > +# > +# Copyright (c) 2019, Linaro Ltd. 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. > +# > +##-- > + > +.text > +.p2align 2 > + > +GCC_ASM_EXPORT(SpeculationBarrier) > + > + > +#/** > +# Uses as a barrier to stop speculative execution. > +# > +# Ensures that no later instruction will execute speculatively, until all > prior > +# instructions have completed. > +# > +#**/ > +#VOID > +#EFIAPI > +#SpeculationBarrier ( > +# VOID > +# ); > +# > +ASM_PFX(SpeculationBarrier): > +dsb sy > +isb > +ret > diff --git a/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm > b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm > new file mode 100644 > index ..0c4b915b7798 > --- /dev/null > +++ b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm > @@ -0,0 +1,38 @@ > +;-- > +; > +; SpeculationBarrier() for AArch64 > +; > +; Copyright (c) 2019, Linaro Ltd. 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. > +; > +;-- > + > + EXPORT SpeculationBarrier > + AREA BaseLib_LowLevel, CODE, READONLY > + > +;/** > +; Uses as a barrier to stop speculative execution. > +; > +; Ensures that no later instruction will execute speculatively, until all > prior > +; instructions have completed. > +; > +;**/ > +;VOID > +;EFIAPI > +;SpeculationBarrier ( > +; VOID > +; ); > +; > +SpeculationBarrier > +dsb sy > +isb > +ret > + > + END > diff --git a/MdePkg/Library/BaseLib/Arm/SpeculationBarrier.S > b/MdePkg/Library/BaseLib/Arm/SpeculationBarrier.S > new file mode 100644 > index ..7857558aba17 > --- /dev/null > +++ b/MdePkg/Library/BaseLib/Arm/SpeculationBarrier.S > @@ -0,0 +1,39 @@ > +##-- > +# > +# SpeculationBarrier() for AArch64 > +# > +# Copyright (c) 2019, Linaro Ltd. 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. > +# >
Re: [edk2] [PATCH] MdePkg/BaseLib: implement SpeculationBarrier() for ARM and AArch64
Ard: I have no comments on this patch. Reviewed-by: Liming Gao > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Wednesday, February 6, 2019 8:08 AM > To: edk2-devel@lists.01.org > Cc: leif.lindh...@linaro.org; Gao, Liming ; Kinney, > Michael D ; Ard Biesheuvel > > Subject: [PATCH] MdePkg/BaseLib: implement SpeculationBarrier() for ARM and > AArch64 > > Replace the dummy C implementation of SpeculationBarrier() with > implementations consisting of the recommended DSB SY + ISB sequence, > as recommended by ARM in the whitepaper "Cache Speculation Side-channels" > version 2.4, dated October 2018. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S | 39 > > MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm | 38 > +++ > MdePkg/Library/BaseLib/Arm/SpeculationBarrier.S | 39 > > MdePkg/Library/BaseLib/Arm/SpeculationBarrier.asm | 39 > > MdePkg/Library/BaseLib/Arm/SpeculationBarrier.c | 30 --- > MdePkg/Library/BaseLib/BaseLib.inf| 7 +++- > 6 files changed, 160 insertions(+), 32 deletions(-) > > diff --git a/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S > b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S > new file mode 100644 > index ..500bdadca5d2 > --- /dev/null > +++ b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S > @@ -0,0 +1,39 @@ > +##-- > +# > +# SpeculationBarrier() for AArch64 > +# > +# Copyright (c) 2019, Linaro Ltd. 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. > +# > +##-- > + > +.text > +.p2align 2 > + > +GCC_ASM_EXPORT(SpeculationBarrier) > + > + > +#/** > +# Uses as a barrier to stop speculative execution. > +# > +# Ensures that no later instruction will execute speculatively, until all > prior > +# instructions have completed. > +# > +#**/ > +#VOID > +#EFIAPI > +#SpeculationBarrier ( > +# VOID > +# ); > +# > +ASM_PFX(SpeculationBarrier): > +dsb sy > +isb > +ret > diff --git a/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm > b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm > new file mode 100644 > index ..0c4b915b7798 > --- /dev/null > +++ b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm > @@ -0,0 +1,38 @@ > +;-- > +; > +; SpeculationBarrier() for AArch64 > +; > +; Copyright (c) 2019, Linaro Ltd. 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. > +; > +;-- > + > + EXPORT SpeculationBarrier > + AREA BaseLib_LowLevel, CODE, READONLY > + > +;/** > +; Uses as a barrier to stop speculative execution. > +; > +; Ensures that no later instruction will execute speculatively, until all > prior > +; instructions have completed. > +; > +;**/ > +;VOID > +;EFIAPI > +;SpeculationBarrier ( > +; VOID > +; ); > +; > +SpeculationBarrier > +dsb sy > +isb > +ret > + > + END > diff --git a/MdePkg/Library/BaseLib/Arm/SpeculationBarrier.S > b/MdePkg/Library/BaseLib/Arm/SpeculationBarrier.S > new file mode 100644 > index ..7857558aba17 > --- /dev/null > +++ b/MdePkg/Library/BaseLib/Arm/SpeculationBarrier.S > @@ -0,0 +1,39 @@ > +##-- > +# > +# SpeculationBarrier() for AArch64 > +# > +# Copyright (c) 2019, Linaro Ltd. 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, >
Re: [edk2] [MdePkg/BaseLib v1 1/1] MdePkg BaseLib: Add new API CalculateCrc16()
Ming:
So, there is no common CRC16 algorithm in edk2. I suggest to collect all
CRC16 request in the firmware code, then discussion how to add CalculateCrc16()
API in BaseLib. There may be more than one CalculateCrc16() API with the
different postfix for the different algorithm. Besides eeprom and DebugAgent,
are there other usages?
Thanks
Liming
> -Original Message-
> From: Ming Huang [mailto:ming.hu...@linaro.org]
> Sent: Saturday, February 2, 2019 7:12 PM
> To: Gao, Liming ; Ni, Ray ;
> linaro-u...@lists.linaro.org; edk2-devel@lists.01.org; Kinney,
> Michael D
> Cc: huangmin...@huawei.com; Dong, Eric ;
> zhangjinso...@huawei.com; wanghuiqi...@huawei.com;
> wai...@126.com; Zeng, Star ; huangda...@hisilicon.com
> Subject: Re: [edk2] [MdePkg/BaseLib v1 1/1] MdePkg BaseLib: Add new API
> CalculateCrc16()
>
>
>
> On 2/1/2019 8:25 PM, Gao, Liming wrote:
> > Ming:
> > What's usage model of new Crc16()? Can they use the same algorithm in
> > DebugAgent?
>
> It is used in check MAC read from eeprom. I think they cann't use the
> algorithm in
> DebugAgent.
>
> Thanks.
>
> >
> > Thanks
> > Liming
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >> Ming Huang
> >> Sent: Friday, February 1, 2019 3:12 PM
> >> To: Ni, Ray ; linaro-u...@lists.linaro.org;
> >> edk2-devel@lists.01.org; Kinney, Michael D ;
> >> Gao, Liming
> >> Cc: huangmin...@huawei.com; Dong, Eric ;
> >> zhangjinso...@huawei.com; wanghuiqi...@huawei.com;
> >> wai...@126.com; Zeng, Star ; huangda...@hisilicon.com
> >> Subject: Re: [edk2] [MdePkg/BaseLib v1 1/1] MdePkg BaseLib: Add new API
> >> CalculateCrc16()
> >>
> >>
> >>
> >> On 2/1/2019 2:37 PM, Ni, Ray wrote:
> >>> There is an CRC16 calculation implementation in
> >>> SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugAgent.c
> >>>
> >>> Does your implementation generate the same CRC16 as above one?
> >>
> >> It is not the same with above one.
> >>
> >>>
> -Original Message-
> From: edk2-devel On Behalf Of Ming
> Huang
> Sent: Friday, February 1, 2019 2:02 PM
> To: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org; Kinney,
> Michael D
> ; Gao, Liming
> Cc: huangmin...@huawei.com; Dong, Eric ;
> zhangjinso...@huawei.com; Zeng, Star ;
> wai...@126.com; wanghuiqi...@huawei.com; huangda...@hisilicon.com
> Subject: [edk2] [MdePkg/BaseLib v1 1/1] MdePkg BaseLib: Add new API
> CalculateCrc16()
>
> CalculateCrc16() bases on the initialized mCrcTable. When
> CalculateCrc16() is
> used, mCrcTable16 will take 512Bytes size in the image. When
> CalculateCrc16() is not used, mCrcTable16 will not be built in the
> image, and
> no size impact.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> MdePkg/Include/Library/BaseLib.h | 20 ++
> MdePkg/Library/BaseLib/CheckSum.c | 73
> 2 files changed, 93 insertions(+)
>
> diff --git a/MdePkg/Include/Library/BaseLib.h
> b/MdePkg/Include/Library/BaseLib.h
> index 1eb842384ee2..956b971e5c69 100644
> --- a/MdePkg/Include/Library/BaseLib.h
> +++ b/MdePkg/Include/Library/BaseLib.h
> @@ -4855,6 +4855,26 @@ CalculateCrc32(
> IN UINTNLength
> );
>
> +/**
> + Computes and returns a 16-bit CRC for a data buffer.
> + CRC16 value bases on CCITT.
> +
> + If Buffer is NULL, then ASSERT().
> + If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
> +
> + @param[in] Buffer A pointer to the buffer on which the 16-bit
> CRC is to
> be computed.
> + @param[in] Length The number of bytes in the buffer Data.
> +
> + @retval Crc16The 16-bit CRC was computed for the data
> buffer.
> +
> +**/
> +UINT16
> +EFIAPI
> +CalculateCrc16(
> + IN VOID *Buffer,
> + IN UINTNLength
> + );
> +
> //
> // Base Library CPU Functions
> //
> diff --git a/MdePkg/Library/BaseLib/CheckSum.c
> b/MdePkg/Library/BaseLib/CheckSum.c
> index 03d49afc5e6c..4e27aebe44bc 100644
> --- a/MdePkg/Library/BaseLib/CheckSum.c
> +++ b/MdePkg/Library/BaseLib/CheckSum.c
> @@ -630,3 +630,76 @@ CalculateCrc32(
>
> return Crc ^ 0x;
> }
> +
> +GLOBAL_REMOVE_IF_UNREFERENCED CONST UINT16 mCrcTable16[256] =
> {
> + 0x, 0x1021, 0x2042, 0x3063, 0x4084, 0x50A5, 0x60C6, 0x70E7,
> + 0x8108, 0x9129, 0xA14A, 0xB16B, 0xC18C, 0xD1AD, 0xE1CE, 0xF1EF,
> + 0x1231, 0x0210, 0x3273, 0x2252, 0x52B5, 0x4294, 0x72F7, 0x62D6,
> + 0x9339, 0x8318, 0xB37B, 0xA35A, 0xD3BD, 0xC39C, 0xF3FF, 0xE3DE,
> + 0x2462, 0x3443, 0x0420,
Re: [edk2] [PATCH] MdeModulePkg/CapsuleApp: Fix memory leak issue.
ChenChen:
Please add FileInfoBuffer[Index] NULL check before free
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Chen A
Chen
Sent: Monday, February 11, 2019 2:17 PM
To: edk2-devel@lists.01.org
Cc: Wu, Hao A ; Gao, Liming ; Zhang,
Chao B
Subject: [edk2] [PATCH] MdeModulePkg/CapsuleApp: Fix memory leak issue.
This issue is caused by FileInfoBuffer variable. This is a pointer array and
each elements also pointer to a memory buffer that is allocated and returned by
AllocateCopyPool function.
Cc: Jian J Wang
Cc: Hao Wu
Cc: Zhang Chao B
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chen A Chen
---
MdeModulePkg/Application/CapsuleApp/CapsuleDump.c | 81 ---
1 file changed, 56 insertions(+), 25 deletions(-)
diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
index 7bef5a1378..00cf45d66a 100644
--- a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
+++ b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
@@ -806,48 +806,69 @@ DumpCapsuleFromDisk (
Status = Fs->OpenVolume (Fs, );
if (EFI_ERROR (Status)) {
Print (L"Cannot open volume. Status = %r\n", Status);
-return EFI_NOT_FOUND;
+goto Done;
}
Status = Root->Open (Root, , EFI_CAPSULE_FILE_DIRECTORY,
EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE , 0);
if (EFI_ERROR (Status)) {
Print (L"Cannot open %s. Status = %r\n", EFI_CAPSULE_FILE_DIRECTORY,
Status);
-return EFI_NOT_FOUND;
+goto Done;
}
//
// Get file count first
//
- for ( Status = FileHandleFindFirstFile (DirHandle, )
- ; !EFI_ERROR(Status) && !NoFile
- ; Status = FileHandleFindNextFile (DirHandle, FileInfo, )
- ){
-if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
- continue;
+ do {
+Status = FileHandleFindFirstFile (DirHandle, );
+if (EFI_ERROR (Status) || FileInfo == NULL) {
+ Print (L"Get File Info Fail. Status = %r\n", Status);
+ goto Done;
}
-FileCount++;
- }
+
+if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
+ FileCount++;
+}
+
+Status = FileHandleFindNextFile (DirHandle, FileInfo, );
+if (EFI_ERROR (Status)) {
+ Print (L"Get Next File Fail. Status = %r\n", Status);
+ goto Done;
+}
+ } while (!NoFile);
if (FileCount == 0) {
Print (L"Error: No capsule file found!\n");
-return EFI_NOT_FOUND;
+Status = EFI_NOT_FOUND;
+goto Done;
}
FileInfoBuffer = AllocatePool (sizeof(FileInfo) * FileCount);
+ if (FileInfoBuffer == NULL) {
+Status = EFI_OUT_OF_RESOURCES;
+goto Done;
+ }
NoFile = FALSE;
//
// Get all file info
//
- for ( Status = FileHandleFindFirstFile (DirHandle, )
- ; !EFI_ERROR (Status) && !NoFile
- ; Status = FileHandleFindNextFile (DirHandle, FileInfo, )
- ){
-if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
- continue;
+ do {
+Status = FileHandleFindFirstFile (DirHandle, );
+if (EFI_ERROR (Status) || FileInfo == NULL) {
+ Print (L"Get File Info Fail. Status = %r\n", Status);
+ goto Done;
}
-FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size,
FileInfo);
- }
+
+if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
+ FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size,
FileInfo);
+}
+
+Status = FileHandleFindNextFile (DirHandle, FileInfo, );
+if (EFI_ERROR (Status)) {
+ Print (L"Get Next File Fail. Status = %r\n", Status);
+ goto Done;
+}
+ } while (!NoFile);
//
// Sort FileInfoBuffer by alphabet order @@ -866,7 +887,8 @@
DumpCapsuleFromDisk (
}
if (!DumpCapsuleInfo) {
-return EFI_SUCCESS;
+Status = EFI_SUCCESS;
+goto Done;
}
Print(L"The infomation of the capsules:\n"); @@ -875,19 +897,20 @@
DumpCapsuleFromDisk (
FileHandle = NULL;
Status = DirHandle->Open (DirHandle, ,
FileInfoBuffer[Index]->FileName, EFI_FILE_MODE_READ, 0);
if (EFI_ERROR (Status)) {
- break;
+ goto Done;
}
Status = FileHandleGetSize (FileHandle, (UINT64 *) );
if (EFI_ERROR (Status)) {
Print (L"Cannot read file %s. Status = %r\n",
FileInfoBuffer[Index]->FileName, Status);
FileHandleClose (FileHandle);
- return Status;
+ goto Done;
}
FileBuffer = AllocatePool (FileSize);
if (FileBuffer == NULL) {
- return RETURN_OUT_OF_RESOURCES;
+ Status = EFI_OUT_OF_RESOURCES;
+ goto Done;
}
Status = FileHandleRead (FileHandle, , FileBuffer); @@ -895,7
+918,7 @@ DumpCapsuleFromDisk (
Print (L"Cannot read file %s. Status = %r\n",
FileInfoBuffer[Index]->FileName, Status);
FreePool (FileBuffer);
FileHandleClose (FileHandle);
- return Status;
+ goto Done;
}
Print
Re: [edk2] [PATCH] Maintainers: add TPM2 reviewers for OvmfPkg
On 2/11/19 7:53 AM, Laszlo Ersek wrote: OVMF can be built with a significant amount of TPM2 code now; add Marc-André and Stefan as Reviewers for TPM2-related patches. Keep the list of "R" entries alphabetically sorted. Cc: Andrew Fish Cc: Ard Biesheuvel Cc: Jordan Justen Cc: Leif Lindholm Cc: Marc-André Lureau Cc: Michael D Kinney Cc: Stefan Berger Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek Reviewed-by: Stefan Berger --- Maintainers.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Maintainers.txt b/Maintainers.txt index 3b2676bc32ea..92f683827923 100644 --- a/Maintainers.txt +++ b/Maintainers.txt @@ -214,14 +214,16 @@ M: Ray Ni OvmfPkg W: http://www.tianocore.org/ovmf/ M: Jordan Justen M: Laszlo Ersek M: Ard Biesheuvel R: Anthony Perard R: Julien Grall +R: Marc-André Lureau +R: Stefan Berger S: Maintained PcAtChipsetPkg W: https://github.com/tianocore/tianocore.github.io/wiki/PcAtChipsetPkg M: Ray Ni QuarkPlatformPkg, QuarkSocPkg ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] Maintainers: add TPM2 reviewers for OvmfPkg
On Mon, Feb 11, 2019 at 01:53:43PM +0100, Laszlo Ersek wrote: > OVMF can be built with a significant amount of TPM2 code now; add > Marc-André and Stefan as Reviewers for TPM2-related patches. > > Keep the list of "R" entries alphabetically sorted. For this patch: Reviewed-by: Leif Lindholm However - unrelated sidenote: Julien, is that address still valid for you? / Leif > Cc: Andrew Fish > Cc: Ard Biesheuvel > Cc: Jordan Justen > Cc: Leif Lindholm > Cc: Marc-André Lureau > Cc: Michael D Kinney > Cc: Stefan Berger > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Laszlo Ersek > --- > Maintainers.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Maintainers.txt b/Maintainers.txt > index 3b2676bc32ea..92f683827923 100644 > --- a/Maintainers.txt > +++ b/Maintainers.txt > @@ -214,14 +214,16 @@ M: Ray Ni > OvmfPkg > W: http://www.tianocore.org/ovmf/ > M: Jordan Justen > M: Laszlo Ersek > M: Ard Biesheuvel > R: Anthony Perard > R: Julien Grall > +R: Marc-André Lureau > +R: Stefan Berger > S: Maintained > > PcAtChipsetPkg > W: https://github.com/tianocore/tianocore.github.io/wiki/PcAtChipsetPkg > M: Ray Ni > > QuarkPlatformPkg, QuarkSocPkg > -- > 2.19.1.3.g30247aa5d201 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/CapsuleApp: Fix potential NULL pointer dereference issue
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Chen
> A Chen
> Sent: Monday, February 11, 2019 2:11 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A; Gao, Liming
> Subject: [edk2] [PATCH] MdeModulePkg/CapsuleApp: Fix potential NULL pointer
> dereference issue
>
> To avoid potential NULL pointer dereference issue. Initialize them at
> the beginning of the function. This patch is a supplement which was missed
> at e98212cb5d59fff8f385d9179ad7f1a3ce9cf215 commit.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> ---
> MdeModulePkg/Application/CapsuleApp/CapsuleDump.c | 23
> +-
> .../Application/CapsuleApp/CapsuleOnDisk.c | 5 -
> 2 files changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> index 33d2ecc582..cbbfda1424 100644
> --- a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> @@ -1001,12 +1001,15 @@ DumpProvisionedCapsule (
>EFI_SIMPLE_FILE_SYSTEM_PROTOCOL *Fs;
>EFI_SHELL_PROTOCOL *ShellProtocol;
>
> - ShellProtocol = GetShellProtocol ();
> -
>Index = 0;
>CapsuleDataPtr64 = NULL;
>BootNext = NULL;
> - ShellProtocol = NULL;
> +
> + ShellProtocol = GetShellProtocol ();
> + if (ShellProtocol == NULL) {
> +Print (L"Get Shell Protocol Fail\n");
> +return ;
> + }
>
>//
>// Dump capsule provisioned on Memory
> @@ -1033,16 +1036,16 @@ DumpProvisionedCapsule (
>(VOID **) ,
>NULL
>);
> -if (EFI_ERROR (Status)) {
> +if (EFI_ERROR (Status) || CapsuleDataPtr64 == NULL) {
>if (Index == 0) {
> Print (L"No data.\n");
>}
>break;
> -} else {
> - Index++;
> - Print (L"Capsule Description at 0x%08x\n", *CapsuleDataPtr64);
> - DumpBlockDescriptors ((EFI_CAPSULE_BLOCK_DESCRIPTOR*) (UINTN)
> *CapsuleDataPtr64, DumpCapsuleInfo);
> }
> +
> +Index++;
> +Print (L"Capsule Description at 0x%08x\n", *CapsuleDataPtr64);
> +DumpBlockDescriptors ((EFI_CAPSULE_BLOCK_DESCRIPTOR*) (UINTN)
> *CapsuleDataPtr64, DumpCapsuleInfo);
>}
>
>//
> @@ -1057,7 +1060,9 @@ DumpProvisionedCapsule (
> (VOID **) ,
> NULL
> );
> - if (!EFI_ERROR (Status)) {
> + if (EFI_ERROR (Status) || BootNext == NULL) {
> +Print (L"Get BootNext Variable Fail. Status = %r\n", Status);
> + } else {
> UnicodeSPrint (BootOptionName, sizeof (BootOptionName), L"Boot%04x",
> *BootNext);
> Status = EfiBootManagerVariableToLoadOption (BootOptionName,
> );
> if (!EFI_ERROR (Status)) {
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> b/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> index 4faa863bca..f6e46cbdb1 100644
> --- a/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> @@ -445,7 +445,10 @@ GetUpdateFileSystem (
> (VOID **),
> NULL
> );
> -if (!EFI_ERROR (Status)) {
> +if (EFI_ERROR (Status) || BootNextData == NULL) {
> + Print (L"Get Boot Next Data Fail. Status = %r\n", Status);
> + return EFI_NOT_FOUND;
> +} else {
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
>UnicodeSPrint (BootOptionName, sizeof (BootOptionName), L"Boot%04x",
> *BootNextData);
>Status = EfiBootManagerVariableToLoadOption (BootOptionName,
> );
>if (!EFI_ERROR (Status)) {
> --
> 2.16.2.windows.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/CapsuleApp: Fix memory leak issue.
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Chen
> A Chen
> Sent: Monday, February 11, 2019 2:17 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A; Gao, Liming; Zhang, Chao B
> Subject: [edk2] [PATCH] MdeModulePkg/CapsuleApp: Fix memory leak issue.
>
> This issue is caused by FileInfoBuffer variable. This is a pointer array
> and each elements also pointer to a memory buffer that is allocated and
> returned by AllocateCopyPool function.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Zhang Chao B
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> ---
> MdeModulePkg/Application/CapsuleApp/CapsuleDump.c | 81
> ---
> 1 file changed, 56 insertions(+), 25 deletions(-)
>
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> index 7bef5a1378..00cf45d66a 100644
> --- a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> @@ -806,48 +806,69 @@ DumpCapsuleFromDisk (
>Status = Fs->OpenVolume (Fs, );
>if (EFI_ERROR (Status)) {
> Print (L"Cannot open volume. Status = %r\n", Status);
> -return EFI_NOT_FOUND;
> +goto Done;
>}
>
>Status = Root->Open (Root, , EFI_CAPSULE_FILE_DIRECTORY,
> EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE , 0);
>if (EFI_ERROR (Status)) {
> Print (L"Cannot open %s. Status = %r\n", EFI_CAPSULE_FILE_DIRECTORY,
> Status);
> -return EFI_NOT_FOUND;
> +goto Done;
>}
>
>//
>// Get file count first
>//
> - for ( Status = FileHandleFindFirstFile (DirHandle, )
> - ; !EFI_ERROR(Status) && !NoFile
> - ; Status = FileHandleFindNextFile (DirHandle, FileInfo, )
> - ){
> -if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
> - continue;
> + do {
> +Status = FileHandleFindFirstFile (DirHandle, );
> +if (EFI_ERROR (Status) || FileInfo == NULL) {
> + Print (L"Get File Info Fail. Status = %r\n", Status);
> + goto Done;
> }
> -FileCount++;
> - }
> +
> +if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
> + FileCount++;
> +}
> +
> +Status = FileHandleFindNextFile (DirHandle, FileInfo, );
> +if (EFI_ERROR (Status)) {
> + Print (L"Get Next File Fail. Status = %r\n", Status);
> + goto Done;
> +}
> + } while (!NoFile);
>
>if (FileCount == 0) {
> Print (L"Error: No capsule file found!\n");
> -return EFI_NOT_FOUND;
> +Status = EFI_NOT_FOUND;
> +goto Done;
>}
>
>FileInfoBuffer = AllocatePool (sizeof(FileInfo) * FileCount);
> + if (FileInfoBuffer == NULL) {
> +Status = EFI_OUT_OF_RESOURCES;
> +goto Done;
> + }
>NoFile = FALSE;
>
>//
>// Get all file info
>//
> - for ( Status = FileHandleFindFirstFile (DirHandle, )
> - ; !EFI_ERROR (Status) && !NoFile
> - ; Status = FileHandleFindNextFile (DirHandle, FileInfo, )
> - ){
> -if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
> - continue;
> + do {
> +Status = FileHandleFindFirstFile (DirHandle, );
> +if (EFI_ERROR (Status) || FileInfo == NULL) {
> + Print (L"Get File Info Fail. Status = %r\n", Status);
> + goto Done;
> }
> -FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size,
> FileInfo);
> - }
> +
> +if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
> + FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size,
> FileInfo);
An error handling may be needed here as well.
Also, if memory allocation does fail here during the 'do-while' loop,
elements in array 'FileInfoBuffer' may not all have valid values.
For this case, the cleanup under tag 'Done' may not be proper.
Best Regards,
Hao Wu
> +}
> +
> +Status = FileHandleFindNextFile (DirHandle, FileInfo, );
> +if (EFI_ERROR (Status)) {
> + Print (L"Get Next File Fail. Status = %r\n", Status);
> + goto Done;
> +}
> + } while (!NoFile);
>
>//
>// Sort FileInfoBuffer by alphabet order
> @@ -866,7 +887,8 @@ DumpCapsuleFromDisk (
>}
>
>if (!DumpCapsuleInfo) {
> -return EFI_SUCCESS;
> +Status = EFI_SUCCESS;
> +goto Done;
>}
>
>Print(L"The infomation of the capsules:\n");
> @@ -875,19 +897,20 @@ DumpCapsuleFromDisk (
> FileHandle = NULL;
> Status = DirHandle->Open (DirHandle, , FileInfoBuffer[Index]-
> >FileName, EFI_FILE_MODE_READ, 0);
> if (EFI_ERROR (Status)) {
> - break;
> + goto Done;
> }
>
> Status = FileHandleGetSize (FileHandle, (UINT64 *) );
> if (EFI_ERROR (Status)) {
>Print (L"Cannot read file %s. Status = %r\n", FileInfoBuffer[Index]-
> >FileName, Status);
>FileHandleClose (FileHandle);
> - return Status;
> + goto Done;
> }
>
> FileBuffer = AllocatePool
[edk2] [PATCH] Maintainers: add TPM2 reviewers for OvmfPkg
OVMF can be built with a significant amount of TPM2 code now; add Marc-André and Stefan as Reviewers for TPM2-related patches. Keep the list of "R" entries alphabetically sorted. Cc: Andrew Fish Cc: Ard Biesheuvel Cc: Jordan Justen Cc: Leif Lindholm Cc: Marc-André Lureau Cc: Michael D Kinney Cc: Stefan Berger Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek --- Maintainers.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Maintainers.txt b/Maintainers.txt index 3b2676bc32ea..92f683827923 100644 --- a/Maintainers.txt +++ b/Maintainers.txt @@ -214,14 +214,16 @@ M: Ray Ni OvmfPkg W: http://www.tianocore.org/ovmf/ M: Jordan Justen M: Laszlo Ersek M: Ard Biesheuvel R: Anthony Perard R: Julien Grall +R: Marc-André Lureau +R: Stefan Berger S: Maintained PcAtChipsetPkg W: https://github.com/tianocore/tianocore.github.io/wiki/PcAtChipsetPkg M: Ray Ni QuarkPlatformPkg, QuarkSocPkg -- 2.19.1.3.g30247aa5d201 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch v2] OvmfPkg: Add TCG2 Configuration menu to the Device Manager menu
On 01/25/19 22:30, Stefan Berger wrote: > This patch adds the TCG2 Configuration menu to the Device Manager > menu. We can apparently reuse the sample Tcg2ConfigDxe from > SecurityPkg/Tcg/Tcg2Config without obvious adverse effects. The > added TCG2 Configuration menu now shows details about the attached > TPM 2.0 and lets one for example configure the active PCR banks > or issue commands, among other things. > > The code is added to Ovmf by building with -DTPM2_ENABLE and > -DTPM2_CONFIG_ENABLE. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Stefan Berger > --- > OvmfPkg/OvmfPkgIa32.dsc| 4 > OvmfPkg/OvmfPkgIa32.fdf| 3 +++ > OvmfPkg/OvmfPkgIa32X64.dsc | 4 > OvmfPkg/OvmfPkgIa32X64.fdf | 3 +++ > OvmfPkg/OvmfPkgX64.dsc | 4 > OvmfPkg/OvmfPkgX64.fdf | 3 +++ > 6 files changed, 21 insertions(+) > > diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc > index aee19b75d7..2b642ab5dc 100644 > --- a/OvmfPkg/OvmfPkgIa32.dsc > +++ b/OvmfPkg/OvmfPkgIa32.dsc > @@ -40,6 +40,7 @@ >DEFINE SMM_REQUIRE = FALSE >DEFINE TLS_ENABLE = FALSE >DEFINE TPM2_ENABLE = FALSE > + DEFINE TPM2_CONFIG_ENABLE = FALSE > ># ># Flash size selection. Setting FD_SIZE_IN_KB on the command line directly > to > @@ -632,6 +633,9 @@ > > NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf > > NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf >} > +!if $(TPM2_CONFIG_ENABLE) == TRUE > + SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf > +!endif > !endif > ># > diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf > index e013099136..4999403ad7 100644 > --- a/OvmfPkg/OvmfPkgIa32.fdf > +++ b/OvmfPkg/OvmfPkgIa32.fdf > @@ -381,6 +381,9 @@ INF > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf > > !if $(TPM2_ENABLE) == TRUE > INF SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf > +!if $(TPM2_CONFIG_ENABLE) == TRUE > +INF SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf > +!endif > !endif > > > > diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc > index 90cbd8e341..14a5c1bb29 100644 > --- a/OvmfPkg/OvmfPkgIa32X64.dsc > +++ b/OvmfPkg/OvmfPkgIa32X64.dsc > @@ -40,6 +40,7 @@ >DEFINE SMM_REQUIRE = FALSE >DEFINE TLS_ENABLE = FALSE >DEFINE TPM2_ENABLE = FALSE > + DEFINE TPM2_CONFIG_ENABLE = FALSE > ># ># Flash size selection. Setting FD_SIZE_IN_KB on the command line directly > to > @@ -640,6 +641,9 @@ > > NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf > > NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf >} > +!if $(TPM2_CONFIG_ENABLE) == TRUE > + SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf > +!endif > !endif > > [Components.X64] > diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf > index afaa334384..d0cc107928 100644 > --- a/OvmfPkg/OvmfPkgIa32X64.fdf > +++ b/OvmfPkg/OvmfPkgIa32X64.fdf > @@ -388,6 +388,9 @@ INF > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf > > !if $(TPM2_ENABLE) == TRUE > INF SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf > +!if $(TPM2_CONFIG_ENABLE) == TRUE > +INF SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf > +!endif > !endif > > > > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc > index 83d16eb00b..aa7197f533 100644 > --- a/OvmfPkg/OvmfPkgX64.dsc > +++ b/OvmfPkg/OvmfPkgX64.dsc > @@ -40,6 +40,7 @@ >DEFINE SMM_REQUIRE = FALSE >DEFINE TLS_ENABLE = FALSE >DEFINE TPM2_ENABLE = FALSE > + DEFINE TPM2_CONFIG_ENABLE = FALSE > ># ># Flash size selection. Setting FD_SIZE_IN_KB on the command line directly > to > @@ -639,6 +640,9 @@ > > NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf > > NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf >} > +!if $(TPM2_CONFIG_ENABLE) == TRUE > + SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf > +!endif > !endif > ># > diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf > index afaa334384..d0cc107928 100644 > --- a/OvmfPkg/OvmfPkgX64.fdf > +++ b/OvmfPkg/OvmfPkgX64.fdf > @@ -388,6 +388,9 @@ INF > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf > > !if $(TPM2_ENABLE) == TRUE > INF SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf > +!if $(TPM2_CONFIG_ENABLE) == TRUE > +INF SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf > +!endif > !endif > > > > Pushed as commit 3103389043bd. Thanks Laszlo ___ edk2-devel mailing list
Re: [edk2] [Patch v2] OvmfPkg: Add TCG2 Configuration menu to the Device Manager menu
Hi On Fri, Jan 25, 2019 at 10:30 PM Stefan Berger wrote: > > This patch adds the TCG2 Configuration menu to the Device Manager > menu. We can apparently reuse the sample Tcg2ConfigDxe from > SecurityPkg/Tcg/Tcg2Config without obvious adverse effects. The > added TCG2 Configuration menu now shows details about the attached > TPM 2.0 and lets one for example configure the active PCR banks > or issue commands, among other things. > > The code is added to Ovmf by building with -DTPM2_ENABLE and > -DTPM2_CONFIG_ENABLE. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Stefan Berger patch looks good (I have done minimal testing, though). Reviewed-by: Marc-André Lureau > --- > OvmfPkg/OvmfPkgIa32.dsc| 4 > OvmfPkg/OvmfPkgIa32.fdf| 3 +++ > OvmfPkg/OvmfPkgIa32X64.dsc | 4 > OvmfPkg/OvmfPkgIa32X64.fdf | 3 +++ > OvmfPkg/OvmfPkgX64.dsc | 4 > OvmfPkg/OvmfPkgX64.fdf | 3 +++ > 6 files changed, 21 insertions(+) > > diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc > index aee19b75d7..2b642ab5dc 100644 > --- a/OvmfPkg/OvmfPkgIa32.dsc > +++ b/OvmfPkg/OvmfPkgIa32.dsc > @@ -40,6 +40,7 @@ >DEFINE SMM_REQUIRE = FALSE >DEFINE TLS_ENABLE = FALSE >DEFINE TPM2_ENABLE = FALSE > + DEFINE TPM2_CONFIG_ENABLE = FALSE > ># ># Flash size selection. Setting FD_SIZE_IN_KB on the command line directly > to > @@ -632,6 +633,9 @@ > > NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf > > NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf >} > +!if $(TPM2_CONFIG_ENABLE) == TRUE > + SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf > +!endif > !endif > ># > diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf > index e013099136..4999403ad7 100644 > --- a/OvmfPkg/OvmfPkgIa32.fdf > +++ b/OvmfPkg/OvmfPkgIa32.fdf > @@ -381,6 +381,9 @@ INF > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf > > !if $(TPM2_ENABLE) == TRUE > INF SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf > +!if $(TPM2_CONFIG_ENABLE) == TRUE > +INF SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf > +!endif > !endif > > > > diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc > index 90cbd8e341..14a5c1bb29 100644 > --- a/OvmfPkg/OvmfPkgIa32X64.dsc > +++ b/OvmfPkg/OvmfPkgIa32X64.dsc > @@ -40,6 +40,7 @@ >DEFINE SMM_REQUIRE = FALSE >DEFINE TLS_ENABLE = FALSE >DEFINE TPM2_ENABLE = FALSE > + DEFINE TPM2_CONFIG_ENABLE = FALSE > ># ># Flash size selection. Setting FD_SIZE_IN_KB on the command line directly > to > @@ -640,6 +641,9 @@ > > NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf > > NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf >} > +!if $(TPM2_CONFIG_ENABLE) == TRUE > + SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf > +!endif > !endif > > [Components.X64] > diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf > index afaa334384..d0cc107928 100644 > --- a/OvmfPkg/OvmfPkgIa32X64.fdf > +++ b/OvmfPkg/OvmfPkgIa32X64.fdf > @@ -388,6 +388,9 @@ INF > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf > > !if $(TPM2_ENABLE) == TRUE > INF SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf > +!if $(TPM2_CONFIG_ENABLE) == TRUE > +INF SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf > +!endif > !endif > > > > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc > index 83d16eb00b..aa7197f533 100644 > --- a/OvmfPkg/OvmfPkgX64.dsc > +++ b/OvmfPkg/OvmfPkgX64.dsc > @@ -40,6 +40,7 @@ >DEFINE SMM_REQUIRE = FALSE >DEFINE TLS_ENABLE = FALSE >DEFINE TPM2_ENABLE = FALSE > + DEFINE TPM2_CONFIG_ENABLE = FALSE > ># ># Flash size selection. Setting FD_SIZE_IN_KB on the command line directly > to > @@ -639,6 +640,9 @@ > > NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf > > NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf >} > +!if $(TPM2_CONFIG_ENABLE) == TRUE > + SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf > +!endif > !endif > ># > diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf > index afaa334384..d0cc107928 100644 > --- a/OvmfPkg/OvmfPkgX64.fdf > +++ b/OvmfPkg/OvmfPkgX64.fdf > @@ -388,6 +388,9 @@ INF > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf > > !if $(TPM2_ENABLE) == TRUE > INF SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf > +!if $(TPM2_CONFIG_ENABLE) == TRUE > +INF SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf > +!endif > !endif > > > > -- > 2.20.1 >
Re: [edk2] [PATCH v2 05/10] OvmfPkg/README: Remove UNIXGCC
On 02/11/19 03:48, Shenglei Zhang wrote:
> Remove UNIXGCC in OvmfPkgIa32.dsc, OvmfPkgIa32X64.dsc
> and OvmfPkgX64.dsc.
> Remove content related to UNIXGCC in README.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1377
>
> Cc: Jordan Justen
> Cc: Laszlo Ersek
> Cc: Ard Biesheuvel
> Cc: Anthony Perard
> Cc: Julien Grall
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang
> Reviewed-by: Laszlo Ersek
> ---
> OvmfPkg/OvmfPkgIa32.dsc| 1 -
> OvmfPkg/OvmfPkgIa32X64.dsc | 1 -
> OvmfPkg/OvmfPkgX64.dsc | 1 -
> OvmfPkg/README | 19 ---
> 4 files changed, 22 deletions(-)
>
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index aee19b75d7..7872ead8de 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -61,7 +61,6 @@
> !endif
>
> [BuildOptions]
> - GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
>GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
>INTEL:RELEASE_*_*_CC_FLAGS = /D MDEPKG_NDEBUG
>MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 90cbd8e341..eef8ae25f3 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -61,7 +61,6 @@
> !endif
>
> [BuildOptions]
> - GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
>GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
>INTEL:RELEASE_*_*_CC_FLAGS = /D MDEPKG_NDEBUG
>MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 83d16eb00b..6d5623857c 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -61,7 +61,6 @@
> !endif
>
> [BuildOptions]
> - GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
>GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
>INTEL:RELEASE_*_*_CC_FLAGS = /D MDEPKG_NDEBUG
>MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG
> diff --git a/OvmfPkg/README b/OvmfPkg/README
> index 68ce0750af..c014d07bfb 100644
> --- a/OvmfPkg/README
> +++ b/OvmfPkg/README
> @@ -402,25 +402,6 @@ main firmware (MAINFV) into RAM memory at address
> 0x80. The
> remaining OVMF firmware then uses this decompressed firmware
> volume image.
>
> -=== UNIXGCC Debug ===
> -
> -If you build with the UNIXGCC toolchain, then debugging will be disabled
> -due to larger image sizes being produced by the UNIXGCC toolchain. The
> -first choice recommendation is to use GCC48 or newer instead.
> -
> -If you must use UNIXGCC, then you can override the build options for
> -particular libraries and modules in the .dsc to re-enable debugging
> -selectively. For example:
> - [Components]
> - OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf {
> -
> - GCC:*_*_*_CC_FLAGS = -UMDEPKG_NDEBUG
> - }
> - MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
> -
> - GCC:*_*_*_CC_FLAGS = -UMDEPKG_NDEBUG
> - }
> -
> === UEFI Windows 7 & Windows 2008 Server ===
>
> * One of the '-vga std' and '-vga qxl' QEMU options should be used.
>
Looks good, thanks! (+Phil)
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4 12/13] OvmfPkg/LockBoxLib: Update the comments for API UpdateLockBox()
On 02/11/19 08:57, Hao Wu wrote: > The previous commit: > MdeModulePkg/SmmLockBoxLib: Support LockBox enlarge in UpdateLockBox() > > adds the support to enlarge a LockBox when using the LockBoxLib API > UpdateLockBox(). > > This commit is to sync the API description comment of UpdateLockBox() with > its counterparts in MdeModulePkg. > > Cc: Laszlo Ersek > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Hao Wu > --- > OvmfPkg/Library/LockBoxLib/LockBoxLib.c | 11 --- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/OvmfPkg/Library/LockBoxLib/LockBoxLib.c > b/OvmfPkg/Library/LockBoxLib/LockBoxLib.c > index 45481b9230..fe9ea1b0d5 100644 > --- a/OvmfPkg/Library/LockBoxLib/LockBoxLib.c > +++ b/OvmfPkg/Library/LockBoxLib/LockBoxLib.c > @@ -3,7 +3,7 @@ >Library implementing the LockBox interface for OVMF > >Copyright (C) 2013, Red Hat, Inc. > - Copyright (c) 2010 - 2014, Intel Corporation. All rights reserved. > + Copyright (c) 2010 - 2019, Intel Corporation. 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 > @@ -224,8 +224,13 @@ SetLockBoxAttributes ( >@retval RETURN_INVALID_PARAMETER the Guid is NULL, or Buffer is NULL, or > Length is 0. >@retval RETURN_NOT_FOUND the requested GUID not found. > - @retval RETURN_BUFFER_TOO_SMALL the original buffer to too small to hold > -new information. > + @retval RETURN_BUFFER_TOO_SMALL for lockbox with attribute > +LOCK_BOX_ATTRIBUTE_RESTORE_IN_PLACE, the > +original buffer to too small to hold new > +information. > + @retval RETURN_OUT_OF_RESOURCES for lockbox with attribute > +LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY, no > +enough resource to save the information. >@retval RETURN_ACCESS_DENIED it is too late to invoke this interface >@retval RETURN_NOT_STARTEDit is too early to invoke this interface >@retval RETURN_UNSUPPORTEDthe service is not supported by > Reviewed-by: Laszlo Ersek Thanks! Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Self-replicating image
Hi Mike, Sorry to say I have not yet filed a BZ. Would you like me to, or are you happy doing it? Cheers, Tom On 08/02/2019 17:59, Kinney, Michael D wrote: > Hi Thomas, > > I have been looking into this topic of multiple controllers this > week. I have some prototype code that I think resolves the issues > but needs a bit more work on some corner cases. > > I am using the PCI Option ROM use case to evaluate the changes. > PCI Option ROM can use Bus Specific Driver Override Protocol so > the driver from the option ROM manages the PCI controller the option > ROM is attached. PCI Option ROMs can also use the Driver Family > Override Protocol so one of the PCI Option ROMs can manage a group > of PCI controllers. > > It is also possible for an FMP driver for integrated devices to > manage multiple integrated devices if there is more than one of > the same device with FW storage. The multiple controller use case > is not limited to busses like PCI. > > The current version of the FmpDeviceLib is optimized for an FMP > instance that manages a single FW storage device. If an FmpDeviceLib > is intended to manage multiple FW storage devices, then a few > extra services in the FmpDeviceLib are required. > > The concept is to extend the FmpDeviceLib with a couple extra > APIs that add support for Stop()/Unload() operations and to > to set the context for the current FmpDeviceLib actions. > > Have you entered a BZ for this issue yet? I can start adding > details in the BZ and post some proposed changes soon. > > Best regards, > > Mike > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel- >> boun...@lists.01.org] On Behalf Of Andrew Fish via >> edk2-devel >> Sent: Friday, February 8, 2019 9:16 AM >> To: Tomas Pilar (tpilar) >> Cc: edk2-devel@lists.01.org >> Subject: Re: [edk2] Self-replicating image >> >> >> >>> On Feb 8, 2019, at 6:42 AM, Tomas Pilar (tpilar) >> wrote: >>> Hi, >>> >>> I am currently pondering the most elegant way to >> implement capsule update for our devices that would >> work in the presence of multiple devices in the host. >>> Capsule allows embedding a driver that is executed >> prior to the update, which is very handy. Crypto >> library is quite large and would not fit into an >> OptionROM, so being able to supply FMP driver in the >> capsule is great. >>> However, if only one instance of the driver loads, >> the FMP upstream is currently written to support only >> one device per instance. So I wonder if there is a >> easy, neat way for my image to replicate on >> DriverBinding so that I end up with one instance per >> device. >> >> Tom, >> >> The usually model in EFI is to have one driver handle >> multiple things. >> >>> It looks like I should be able to do it with gBS- >>> LoadImage() and passing information about currently >> loaded image though I might have to CopyMem() the image >> itself to new location. >> gBS->LoadImage() will load and relocate the image to a >> malloced address of the correct memory type for the >> image. The inputs are just the source of the image, so >> no need to CopyMem() anything. gBS->StartImage() calls >> the entry point. >> >> Thanks, >> >> Andrew Fish >> >>> Thoughts? >>> >>> Cheers, >>> Tom >>> ___ >>> edk2-devel mailing list >>> edk2-devel@lists.01.org >>> https://lists.01.org/mailman/listinfo/edk2-devel >> ___ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-non-osi 1/1] Platform/Socionext: update TF-A binary to upstream release
(+ Ilias) On Mon, 11 Feb 2019 at 10:19, Sumit Garg wrote: > > On Mon, 11 Feb 2019 at 14:30, Ard Biesheuvel > wrote: > > > > On Mon, 11 Feb 2019 at 05:55, Sumit Garg wrote: > > > > > > On Sat, 9 Feb 2019 at 17:18, Ard Biesheuvel > > > wrote: > > > > > > > > On Tue, 5 Feb 2019 at 09:01, Sumit Garg wrote: > > > > > > > > > > Update TF-A to upstream v2.0 release (Commit: dbc8d9496ead). Also > > > > > update > > > > > OP-TEE to upstream v3.4.0 release (Commit: 406c609bbf08). > > > > > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > > > Signed-off-by: Sumit Garg > > > > > --- > > > > > > > > > > Following is reference repo to pull this patch: > > > > > ssh://g...@git.linaro.org/people/sumit.garg/edk2-non-osi.git > > > > > > > > > > Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin | Bin 415251 -> > > > > > 402963 bytes > > > > > 1 file changed, 0 insertions(+), 0 deletions(-) > > > > > > > > > > diff --git a/Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin > > > > > b/Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin > > > > > index bc6f4563a5d6..e6ce62a2a20b 100644 > > > > > Binary files a/Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin and > > > > > b/Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin differ > > > > > -- > > > > > 2.7.4 > > > > > > > > > > > > > Thanks Sumit > > > > > > > > I created a firmware build with this change, could you please double > > > > check it? > > > > > > > > > > Thanks Ard for incorporating this updated TF-A image. And yes this > > > updated firmware capsule could work pretty well for me. > > > > > > > Thanks Sumit. > > > > I take it you used fwupdate to install it? Which version did you use? > > Yes I used fwupdate to install DeveloperBox.Cap. Following is version info: > > Distro version: > Distributor ID: Debian > Description: Debian GNU/Linux 9.5 (stretch) > Release: 9.5 > Codename: stretch > > fwupdate version: > fwupdate/stretch-backports,now 10-3~bpo9+1 arm64 [installed] > > > (We are seeing segfaults with fwupdate 12 on debian unstable) > > Is it specific to any particular capsule update (like this one) or in > general when trying to run fwupdate? > We are trying to figure that out, but the machine in question has a one-off firmware build installed at the moment. We can reproduce this with fwupdate 10 as well. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-non-osi 1/1] Platform/Socionext: update TF-A binary to upstream release
On Mon, 11 Feb 2019 at 14:30, Ard Biesheuvel wrote: > > On Mon, 11 Feb 2019 at 05:55, Sumit Garg wrote: > > > > On Sat, 9 Feb 2019 at 17:18, Ard Biesheuvel > > wrote: > > > > > > On Tue, 5 Feb 2019 at 09:01, Sumit Garg wrote: > > > > > > > > Update TF-A to upstream v2.0 release (Commit: dbc8d9496ead). Also update > > > > OP-TEE to upstream v3.4.0 release (Commit: 406c609bbf08). > > > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > > Signed-off-by: Sumit Garg > > > > --- > > > > > > > > Following is reference repo to pull this patch: > > > > ssh://g...@git.linaro.org/people/sumit.garg/edk2-non-osi.git > > > > > > > > Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin | Bin 415251 -> > > > > 402963 bytes > > > > 1 file changed, 0 insertions(+), 0 deletions(-) > > > > > > > > diff --git a/Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin > > > > b/Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin > > > > index bc6f4563a5d6..e6ce62a2a20b 100644 > > > > Binary files a/Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin and > > > > b/Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin differ > > > > -- > > > > 2.7.4 > > > > > > > > > > Thanks Sumit > > > > > > I created a firmware build with this change, could you please double > > > check it? > > > > > > > Thanks Ard for incorporating this updated TF-A image. And yes this > > updated firmware capsule could work pretty well for me. > > > > Thanks Sumit. > > I take it you used fwupdate to install it? Which version did you use? Yes I used fwupdate to install DeveloperBox.Cap. Following is version info: Distro version: Distributor ID: Debian Description: Debian GNU/Linux 9.5 (stretch) Release: 9.5 Codename: stretch fwupdate version: fwupdate/stretch-backports,now 10-3~bpo9+1 arm64 [installed] > (We are seeing segfaults with fwupdate 12 on debian unstable) Is it specific to any particular capsule update (like this one) or in general when trying to run fwupdate? -Sumit ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2] CryptoPkg: Fix various typos
Pushed@2a784a2cc356df5a8958afe88bc7e844dc0fb7cc Regards, Jian > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ye, > Ting > Sent: Monday, February 11, 2019 9:52 AM > To: Antoine Coeur ; edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH v2] CryptoPkg: Fix various typos > > Reviewed-by: Ye Ting > > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Antoine Coeur > Sent: Friday, February 8, 2019 12:12 AM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH v2] CryptoPkg: Fix various typos > > Fix various typos in CryptoPkg. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Coeur > --- > CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c | 2 +- > CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c > b/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c > index d63c23df09..540c5715cb 100644 > --- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c > +++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c > @@ -142,7 +142,7 @@ IMPLEMENT_ASN1_FUNCTIONS (TS_TST_INFO) >@param[in] Asn1Time Pointer to the ASN.1 GeneralizedTime to be > converted. >@param[out] SigningTime Return the corresponding EFI Time. > > - @retval TRUE The time convertion succeeds. > + @retval TRUE The time conversion succeeds. >@retval FALSE Invalid parameters. > > **/ > diff --git a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c > b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c > index 9510a4a383..80f5c2578e 100644 > --- a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c > +++ b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c > @@ -84,14 +84,14 @@ QuickSortWorker ( > } >} >// > - // Swap pivot to it's final position (NextSwapLocaiton) > + // Swap pivot to its final position (NextSwapLocation) >// >CopyMem (Buffer, Pivot, ElementSize); >CopyMem (Pivot, (UINT8 *)BufferToSort + (NextSwapLocation * ElementSize), > ElementSize); >CopyMem ((UINT8 *)BufferToSort + (NextSwapLocation * ElementSize), Buffer, > ElementSize); > >// > - // Now recurse on 2 paritial lists. Neither of these will have the 'pivot' > element. > + // Now recurse on 2 partial lists. Neither of these will have the 'pivot' > element. >// IE list is sorted left half, pivot element, sorted right half... >// >QuickSortWorker ( > -- > 2.17.2 (Apple Git-113) > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 05/10] OvmfPkg/README: Remove UNIXGCC
On Mon, 11 Feb 2019 at 02:48, Shenglei Zhang wrote:
>
> Remove UNIXGCC in OvmfPkgIa32.dsc, OvmfPkgIa32X64.dsc
> and OvmfPkgX64.dsc.
> Remove content related to UNIXGCC in README.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1377
>
> Cc: Jordan Justen
> Cc: Laszlo Ersek
> Cc: Ard Biesheuvel
> Cc: Anthony Perard
> Cc: Julien Grall
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang
> Reviewed-by: Laszlo Ersek
Acked-by: Ard Biesheuvel
> ---
> OvmfPkg/OvmfPkgIa32.dsc| 1 -
> OvmfPkg/OvmfPkgIa32X64.dsc | 1 -
> OvmfPkg/OvmfPkgX64.dsc | 1 -
> OvmfPkg/README | 19 ---
> 4 files changed, 22 deletions(-)
>
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index aee19b75d7..7872ead8de 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -61,7 +61,6 @@
> !endif
>
> [BuildOptions]
> - GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
>GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
>INTEL:RELEASE_*_*_CC_FLAGS = /D MDEPKG_NDEBUG
>MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 90cbd8e341..eef8ae25f3 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -61,7 +61,6 @@
> !endif
>
> [BuildOptions]
> - GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
>GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
>INTEL:RELEASE_*_*_CC_FLAGS = /D MDEPKG_NDEBUG
>MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 83d16eb00b..6d5623857c 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -61,7 +61,6 @@
> !endif
>
> [BuildOptions]
> - GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
>GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
>INTEL:RELEASE_*_*_CC_FLAGS = /D MDEPKG_NDEBUG
>MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG
> diff --git a/OvmfPkg/README b/OvmfPkg/README
> index 68ce0750af..c014d07bfb 100644
> --- a/OvmfPkg/README
> +++ b/OvmfPkg/README
> @@ -402,25 +402,6 @@ main firmware (MAINFV) into RAM memory at address
> 0x80. The
> remaining OVMF firmware then uses this decompressed firmware
> volume image.
>
> -=== UNIXGCC Debug ===
> -
> -If you build with the UNIXGCC toolchain, then debugging will be disabled
> -due to larger image sizes being produced by the UNIXGCC toolchain. The
> -first choice recommendation is to use GCC48 or newer instead.
> -
> -If you must use UNIXGCC, then you can override the build options for
> -particular libraries and modules in the .dsc to re-enable debugging
> -selectively. For example:
> - [Components]
> - OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf {
> -
> - GCC:*_*_*_CC_FLAGS = -UMDEPKG_NDEBUG
> - }
> - MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
> -
> - GCC:*_*_*_CC_FLAGS = -UMDEPKG_NDEBUG
> - }
> -
> === UEFI Windows 7 & Windows 2008 Server ===
>
> * One of the '-vga std' and '-vga qxl' QEMU options should be used.
> --
> 2.18.0.windows.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-non-osi 1/1] Platform/Socionext: update TF-A binary to upstream release
On Mon, 11 Feb 2019 at 05:55, Sumit Garg wrote: > > On Sat, 9 Feb 2019 at 17:18, Ard Biesheuvel wrote: > > > > On Tue, 5 Feb 2019 at 09:01, Sumit Garg wrote: > > > > > > Update TF-A to upstream v2.0 release (Commit: dbc8d9496ead). Also update > > > OP-TEE to upstream v3.4.0 release (Commit: 406c609bbf08). > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > Signed-off-by: Sumit Garg > > > --- > > > > > > Following is reference repo to pull this patch: > > > ssh://g...@git.linaro.org/people/sumit.garg/edk2-non-osi.git > > > > > > Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin | Bin 415251 -> > > > 402963 bytes > > > 1 file changed, 0 insertions(+), 0 deletions(-) > > > > > > diff --git a/Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin > > > b/Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin > > > index bc6f4563a5d6..e6ce62a2a20b 100644 > > > Binary files a/Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin and > > > b/Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin differ > > > -- > > > 2.7.4 > > > > > > > Thanks Sumit > > > > I created a firmware build with this change, could you please double check > > it? > > > > Thanks Ard for incorporating this updated TF-A image. And yes this > updated firmware capsule could work pretty well for me. > Thanks Sumit. I take it you used fwupdate to install it? Which version did you use? (We are seeing segfaults with fwupdate 12 on debian unstable) ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
