[edk2] [edk2-test][Patch 0/3] Add VerifySignature() Test
This is the cover letter. The series of patches are listed below. uefi-sct/SctPkg:Convert EOL to Windows(CRLF) in PKCS7Verify uefi-sct/SctPkg:Add VerifySignature() Func Test uefi-sct/SctPkg:Add VerifySignature() Conf Test .../EFI/Protocol/PKCS7Verify/BlackBoxTest/Guid.c | 93 +- .../EFI/Protocol/PKCS7Verify/BlackBoxTest/Guid.h | 193 +-- .../PKCS7Verify/BlackBoxTest/Pkcs7BBTest.inf | 126 +- .../BlackBoxTest/Pkcs7BBTestConformance.c | 1305 +--- .../PKCS7Verify/BlackBoxTest/Pkcs7BBTestData.c | 1568 +--- .../PKCS7Verify/BlackBoxTest/Pkcs7BBTestFunction.c | 553 --- .../PKCS7Verify/BlackBoxTest/Pkcs7BBTestMain.c | 458 +++--- .../PKCS7Verify/BlackBoxTest/Pkcs7BBTestMain.h | 248 ++-- 8 files changed, 2690 insertions(+), 1854 deletions(-) -- 2.9.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot
Thanks for pointers Andrew But if I use emulated runtime variables or say efi=noruntime, I am getting same behavior. On device tree, I see device tree same in both cases. In case of direct boot, only user space console is corrupted whereas kernel space console already prints good characters. FYI, Both user space and kernel space are on same kermit session Regards Udit > -Original Message- > From: af...@apple.com > Sent: Thursday, November 29, 2018 7:22 AM > To: Udit Kumar > Cc: edk2-devel@lists.01.org; Ni, Ruiyu ; Zeng, Star > > Subject: Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot > > Udit, > > Memory map differences would be expected as UiApp.efi is going to allocate > memory too. The OS Loader starts off as an EFI Application so it needs to know > EFI time allocations in addition to what allocations are legal for the OS to > use. > > In general how EFI communicates with the OS is via EFI NVRAM Variables. You > can look at the Table in section "3.3 Globally Defined Variables" of the UEFI > Spec. The OSprot will also figure out information about the platform from ACPI > tables published by the EFI firmware. Also the OS Loader is an EFI App so it > can > access any protocol mentioned in the UEFI Spec. So form example on a Unix like > OS the OS Loader may construct a Device Tree and pass it up to the kernel. It > is > going to be the code in the OS loader that does all this magic. If your > working > with a FOSS OS you may want to try and dump that device tree, and see if > something is different. Then you could try to figure out the code in the OS > Loader that produces that part of the device tree. > > Thanks, > > Andrew Fish > > > On Nov 28, 2018, at 5:42 PM, Udit Kumar wrote: > > > > Hi , > > I am looking for information/Help. If UEFI passed different > > information to OS, in below boot path > > > > 1. Enter into Setup menu (By pressing Esc key), On display of > > UiApp.efi on console, select device to boot OS 2. Let the boot OS > > without user intervention from same device as of 1 > > > > I could see, UEFI pass different memory map in case of 1 and 2. > > Is there some other/extra information is being shared with OS/OS Loader. > > > > For me, if I use 1) for booting then OS boots okay, If I use option > > 2) for booting then when user-space prints are printed as garbage. > > Whereas kernel space prints are good on serial console > > > > Thanks > > Udit > > ___ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis > > ts.01.org%2Fmailman%2Flistinfo%2Fedk2- > develdata=02%7C01%7Cudit.ku > > > mar%40nxp.com%7C2188b5d2f4cb4c3fafbf08d6559d53d7%7C686ea1d3bc2b4c > 6fa92 > > > cd99c5c301635%7C0%7C0%7C636790531534117827sdata=lD8yDYmuqO > hf5co6y > > gkjTV9HTi1Kft8y4xJFOgU6TJE%3Dreserved=0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot
Udit, Memory map differences would be expected as UiApp.efi is going to allocate memory too. The OS Loader starts off as an EFI Application so it needs to know EFI time allocations in addition to what allocations are legal for the OS to use. In general how EFI communicates with the OS is via EFI NVRAM Variables. You can look at the Table in section "3.3 Globally Defined Variables" of the UEFI Spec. The OSprot will also figure out information about the platform from ACPI tables published by the EFI firmware. Also the OS Loader is an EFI App so it can access any protocol mentioned in the UEFI Spec. So form example on a Unix like OS the OS Loader may construct a Device Tree and pass it up to the kernel. It is going to be the code in the OS loader that does all this magic. If your working with a FOSS OS you may want to try and dump that device tree, and see if something is different. Then you could try to figure out the code in the OS Loader that produces that part of the device tree. Thanks, Andrew Fish > On Nov 28, 2018, at 5:42 PM, Udit Kumar wrote: > > Hi , > I am looking for information/Help. If UEFI passed different information to > OS, in below boot path > > 1. Enter into Setup menu (By pressing Esc key), On display of UiApp.efi on > console, select device to boot OS > 2. Let the boot OS without user intervention from same device as of 1 > > I could see, UEFI pass different memory map in case of 1 and 2. > Is there some other/extra information is being shared with OS/OS Loader. > > For me, if I use 1) for booting then OS boots okay, > If I use option 2) for booting then when user-space prints are printed as > garbage. Whereas kernel space prints are good on serial console > > Thanks > Udit > ___ > 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] Help on boot manager 'Boot Manager Menu' and direct boot
Hi , I am looking for information/Help. If UEFI passed different information to OS, in below boot path 1. Enter into Setup menu (By pressing Esc key), On display of UiApp.efi on console, select device to boot OS 2. Let the boot OS without user intervention from same device as of 1 I could see, UEFI pass different memory map in case of 1 and 2. Is there some other/extra information is being shared with OS/OS Loader. For me, if I use 1) for booting then OS boots okay, If I use option 2) for booting then when user-space prints are printed as garbage. Whereas kernel space prints are good on serial console Thanks Udit ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] MdeModulePkg: Correct PCD name in MdeModulePkg.uni
Reviewed-by: Bi Dandan Thanks, Dandan > -Original Message- > From: Gao, Liming > Sent: Thursday, November 29, 2018 9:18 AM > To: edk2-devel@lists.01.org > Cc: Bi, Dandan ; Zeng, Star > Subject: [Patch] MdeModulePkg: Correct PCD name in MdeModulePkg.uni > > https://bugzilla.tianocore.org/show_bug.cgi?id=1363 > New PCD PcdVpdBaseAddress64 is added in MdeModulePkg.dec. > Its string token in MdeModulePkg.uni should match to its name. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Liming Gao > Cc: Bi Dandan > Cc: Star Zeng > --- > MdeModulePkg/MdeModulePkg.uni | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/MdeModulePkg/MdeModulePkg.uni > b/MdeModulePkg/MdeModulePkg.uni index 9b1766b36a..c754d7bb15 > 100644 > --- a/MdeModulePkg/MdeModulePkg.uni > +++ b/MdeModulePkg/MdeModulePkg.uni > @@ -1261,9 +1261,9 @@ > > "On TRUE, the string FPDT > record will be used to store every performance entry.\n" > > "On FALSE, the different > FPDT record will be used to store the different performance entries." > > -#string > STR_gEfiMdeModulePkgTokenSpaceGuid_PcdVpdBaseAddress_PROMPT > #language en-US "64bit VPD base address" > +#string > STR_gEfiMdeModulePkgTokenSpaceGuid_PcdVpdBaseAddress64_PROMPT > #language en-US "64bit VPD base address" > > -#string > STR_gEfiMdeModulePkgTokenSpaceGuid_PcdVpdBaseAddress_HELP > #language en-US "VPD type PCD allows a developer to point to an absolute > physical address PcdVpdBaseAddress64" > +#string > STR_gEfiMdeModulePkgTokenSpaceGuid_PcdVpdBaseAddress64_HELP > #language en-US "VPD type PCD allows a developer to point to an absolute > physical address PcdVpdBaseAddress64" > > "to store PCD value. It will be > DynamicExDefault only." > > "It is used to set VPD region base > address. So, it can't be DynamicExVpd PCD. Its value is" > > "required to be accessed in PcdDxe > driver entry point. So, its value must be set in PEI phase." > -- > 2.13.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] MdeModulePkg: Correct PCD name in MdeModulePkg.uni
Reviewed-by: Star Zeng -Original Message- From: Gao, Liming Sent: Thursday, November 29, 2018 9:18 AM To: edk2-devel@lists.01.org Cc: Bi, Dandan ; Zeng, Star Subject: [Patch] MdeModulePkg: Correct PCD name in MdeModulePkg.uni https://bugzilla.tianocore.org/show_bug.cgi?id=1363 New PCD PcdVpdBaseAddress64 is added in MdeModulePkg.dec. Its string token in MdeModulePkg.uni should match to its name. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao Cc: Bi Dandan Cc: Star Zeng --- MdeModulePkg/MdeModulePkg.uni | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MdeModulePkg/MdeModulePkg.uni b/MdeModulePkg/MdeModulePkg.uni index 9b1766b36a..c754d7bb15 100644 --- a/MdeModulePkg/MdeModulePkg.uni +++ b/MdeModulePkg/MdeModulePkg.uni @@ -1261,9 +1261,9 @@ "On TRUE, the string FPDT record will be used to store every performance entry.\n" "On FALSE, the different FPDT record will be used to store the different performance entries." -#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdVpdBaseAddress_PROMPT #language en-US "64bit VPD base address" +#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdVpdBaseAddress64_PROMPT #language en-US "64bit VPD base address" -#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdVpdBaseAddress_HELP #language en-US "VPD type PCD allows a developer to point to an absolute physical address PcdVpdBaseAddress64" +#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdVpdBaseAddress64_HELP #language en-US "VPD type PCD allows a developer to point to an absolute physical address PcdVpdBaseAddress64" "to store PCD value. It will be DynamicExDefault only." "It is used to set VPD region base address. So, it can't be DynamicExVpd PCD. Its value is" "required to be accessed in PcdDxe driver entry point. So, its value must be set in PEI phase." -- 2.13.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] SecurityPkg: Remove dead code and inf redundant definitions.
Reviewed-by: Eric Dong for Opal part.
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Chen A Chen
> Sent: Wednesday, November 28, 2018 2:27 PM
> To: edk2-devel@lists.01.org
> Cc: Zhang, Chao B
> Subject: [edk2] [PATCH] SecurityPkg: Remove dead code and inf redundant
> definitions.
>
> Fix BZ1065, https://bugzilla.tianocore.org/show_bug.cgi?id=1065
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> Cc: Zhang Chao B
> ---
> SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf | 1 -
> SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.c | 52
> SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.h | 23 --
> SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.h| 11 -
> .../Tcg/Opal/OpalPassword/OpalHiiCallbacks.c | 87 --
> SecurityPkg/Tcg/Opal/OpalPassword/OpalNvmeMode.c | 321
> -
> SecurityPkg/Tcg/Opal/OpalPassword/OpalNvmeMode.h | 128
> .../Tcg/Opal/OpalPassword/OpalPasswordDxe.inf | 2 -
> .../Tcg/Opal/OpalPassword/OpalPasswordPei.inf | 1 -
> SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf | 1 -
> SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf| 1 -
> SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf| 1 -
> SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDxe.inf | 1 -
> .../SecureBootConfigDxe/SecureBootConfigDxe.inf| 2 -
> 14 files changed, 632 deletions(-)
>
> diff --git a/SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf
> b/SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf
> index 6f9a77b868..a17fa4046d 100644
> --- a/SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf
> +++ b/SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf
> @@ -43,7 +43,6 @@
>UefiDriverEntryPoint
>UefiBootServicesTableLib
>UefiRuntimeServicesTableLib
> - ReportStatusCodeLib
>DebugLib
>UefiLib
>MemoryAllocationLib
> diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.c
> b/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.c
> index d51865380f..0c4edd5346 100644
> --- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.c
> +++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.c
> @@ -969,58 +969,6 @@ AhciReset (
>
> }
>
> -/**
> - Send Buffer cmd to specific device.
> -
> - @param[in] AhciContext The pointer to the AHCI_CONTEXT.
> - @param[in] PortThe port number of attached ATA device.
> - @param[in] PortMultiplier The port number of port multiplier of
> attached ATA device.
> - @param[in, out] Buffer The Data Buffer to store IDENTIFY PACKET
> Data.
> -
> - @retval EFI_DEVICE_ERRORThe cmd abort with error occurs.
> - @retval EFI_TIMEOUT The operation is time out.
> - @retval EFI_UNSUPPORTED The device is not ready for executing.
> - @retval EFI_SUCCESS The cmd executes successfully.
> -
> -**/
> -EFI_STATUS
> -EFIAPI
> -AhciIdentify (
> - IN AHCI_CONTEXT *AhciContext,
> - IN UINT8Port,
> - IN UINT8PortMultiplier,
> - IN OUT ATA_IDENTIFY_DATA*Buffer
> - )
> -{
> - EFI_STATUS Status;
> - EFI_ATA_COMMAND_BLOCKAtaCommandBlock;
> -
> - if (AhciContext == NULL || Buffer == NULL) {
> -return EFI_INVALID_PARAMETER;
> - }
> -
> - ZeroMem (, sizeof (EFI_ATA_COMMAND_BLOCK));
> -
> - AtaCommandBlock.AtaCommand = ATA_CMD_IDENTIFY_DRIVE;
> - AtaCommandBlock.AtaSectorCount = 1;
> -
> - Status = AhciPioTransfer (
> - AhciContext,
> - Port,
> - PortMultiplier,
> - NULL,
> - 0,
> - TRUE,
> - ,
> - NULL,
> - Buffer,
> - sizeof (ATA_IDENTIFY_DATA),
> - ATA_TIMEOUT
> - );
> -
> - return Status;
> -}
> -
> /**
>Allocate transfer-related data struct which is used at AHCI mode.
>
> diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.h
> b/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.h
> index 037f81ac24..2076b0411b 100644
> --- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.h
> +++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.h
> @@ -293,29 +293,6 @@ typedef struct {
>UINT32AhciBar;
> } AHCI_CONTEXT;
>
> -/**
> - Send Buffer cmd to specific device.
> -
> - @param AhciContext The pointer to the AHCI_CONTEXT.
> - @param PortThe number of port.
> - @param PortMultiplier The timeout Value of stop.
> - @param Buffer The Data Buffer to store IDENTIFY PACKET Data.
> -
> - @retval EFI_DEVICE_ERRORThe cmd abort with error occurs.
> - @retval EFI_TIMEOUT The operation is time out.
> - @retval EFI_UNSUPPORTED The device is not ready for executing.
> - @retval EFI_SUCCESS The cmd executes successfully.
> -
> -**/
> -EFI_STATUS
> -EFIAPI
> -AhciIdentify (
> - IN AHCI_CONTEXT *AhciContext,
> - IN
[edk2] [Patch] MdeModulePkg: Correct PCD name in MdeModulePkg.uni
https://bugzilla.tianocore.org/show_bug.cgi?id=1363 New PCD PcdVpdBaseAddress64 is added in MdeModulePkg.dec. Its string token in MdeModulePkg.uni should match to its name. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao Cc: Bi Dandan Cc: Star Zeng --- MdeModulePkg/MdeModulePkg.uni | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MdeModulePkg/MdeModulePkg.uni b/MdeModulePkg/MdeModulePkg.uni index 9b1766b36a..c754d7bb15 100644 --- a/MdeModulePkg/MdeModulePkg.uni +++ b/MdeModulePkg/MdeModulePkg.uni @@ -1261,9 +1261,9 @@ "On TRUE, the string FPDT record will be used to store every performance entry.\n" "On FALSE, the different FPDT record will be used to store the different performance entries." -#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdVpdBaseAddress_PROMPT #language en-US "64bit VPD base address" +#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdVpdBaseAddress64_PROMPT #language en-US "64bit VPD base address" -#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdVpdBaseAddress_HELP #language en-US "VPD type PCD allows a developer to point to an absolute physical address PcdVpdBaseAddress64" +#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdVpdBaseAddress64_HELP #language en-US "VPD type PCD allows a developer to point to an absolute physical address PcdVpdBaseAddress64" "to store PCD value. It will be DynamicExDefault only." "It is used to set VPD region base address. So, it can't be DynamicExVpd PCD. Its value is" "required to be accessed in PcdDxe driver entry point. So, its value must be set in PEI phase." -- 2.13.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-announce] Research Request
I did a further experiment for you: https://github.com/lersek/edk2/pull/2 I cannot rebase away my history from PRs... Hopefully you have a nice email trail too. -Original Message- From: Laszlo Ersek Sent: Wednesday, November 28, 2018 2:02 PM To: Jeremiah Cox ; Brian J. Johnson ; stephano Cc: edk2-devel@lists.01.org Subject: Re: [edk2] [edk2-announce] Research Request On 11/28/18 19:31, Jeremiah Cox wrote: > Test PR submitted Thanks! Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms 07/27] Silicon/NXP: Add i.MX display library support
Hi Leif,
> -Original Message-
> From: Leif Lindholm
> Sent: Thursday, November 1, 2018 11:05 AM
> To: Chris Co
> Cc: edk2-devel@lists.01.org; Ard Biesheuvel ;
> Michael D Kinney
> Subject: Re: [PATCH edk2-platforms 07/27] Silicon/NXP: Add i.MX display
> library support
>
> On Fri, Sep 21, 2018 at 08:25:58AM +, Chris Co wrote:
> > This adds support for processing EDID data on NXP i.MX platforms.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Christopher Co
> > Cc: Ard Biesheuvel
> > Cc: Leif Lindholm
> > Cc: Michael D Kinney
> > ---
> > Silicon/NXP/iMXPlatformPkg/Include/iMXDisplay.h| 114
> +++
> > Silicon/NXP/iMXPlatformPkg/Library/iMXDisplayLib/iMXDisplayLib.c | 152
>
> > Silicon/NXP/iMXPlatformPkg/Library/iMXDisplayLib/iMXDisplayLib.inf |
> > 31
> > 3 files changed, 297 insertions(+)
> >
> > diff --git a/Silicon/NXP/iMXPlatformPkg/Include/iMXDisplay.h
> > b/Silicon/NXP/iMXPlatformPkg/Include/iMXDisplay.h
> > new file mode 100644
> > index ..70ef8d0af97f
> > --- /dev/null
> > +++ b/Silicon/NXP/iMXPlatformPkg/Include/iMXDisplay.h
> > @@ -0,0 +1,114 @@
> > +/** @file
> > +*
> > +* Copyright (c) 2018 Microsoft 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 distribution. The full text of the license
> > +may be found at
> > +*
> > +https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopens
> > +ource.org%2Flicenses%2Fbsd-
> license.phpdata=02%7C01%7CChristopher
> >
> +.Co%40microsoft.com%7C06e5c1f1adef43f79f9008d6402494f7%7C72f988bf86
> f1
> >
> +41af91ab2d7cd011db47%7C1%7C0%7C636766923203571004sdata=6GJ
> qphnDZ
> > +gT%2FGOiEeSSnPeTRGiRn%2B9CB%2Fi4A0ilq3MA%3Dreserved=0
> > +*
> > +* THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> > +BASIS,
> > +* WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> > +*
> > +**/
> > +
> > +#ifndef __IMX_DISPLAY_H__
> > +#define __IMX_DISPLAY_H__
> > +
> > +#define EDID_MIN_SIZE 128
> > +#define EDID_I2C_ADDRESS0x50
>
> Are all of these #defines and functions called only from within iMX platform
> code?
>
These defines and functions are called by iMX platform and silicon (iMX6Pkg)
code. Should I prefix these defines with "IMX_" and function names with "Imx"?
I made changes to address the rest of the feedback.
Chris
> > +
> > +// The first DTD is the preferred timing, refer to 3.1 VESA EDID spec.
> > +#define EDID_DTD_1_OFFSET 0x36
> > +#define EDID_DTD_2_OFFSET 0x48
> > +#define EDID_DTD_3_OFFSET 0x5A
> > +#define EDID_DTD_4_OFFSET 0x6C
> > +
> > +typedef enum {
> > + PIXEL_FORMAT_ARGB32,
> > + PIXEL_FORMAT_BGRA32,
> > +} PIXEL_FORMAT;
> > +
> > +typedef struct _DISPLAY_TIMING {
> > + UINT32 PixelClock;
> > + UINT32 HActive;
> > + UINT32 HBlank;
> > + UINT32 VActive;
> > + UINT32 VBlank;
> > + UINT32 HSync;
> > + UINT32 VSync;
> > + UINT32 HSyncOffset;
> > + UINT32 VSyncOffset;
> > + UINT32 HImageSize;
> > + UINT32 VImageSize;
> > + UINT32 HBorder;
> > + UINT32 VBorder;
> > + UINT32 EdidFlags;
> > + UINT32 Flags;
> > + UINT32 PixelRepetition;
> > + UINT32 Bpp;
> > + PIXEL_FORMAT PixelFormat;
> > +} DISPLAY_TIMING, *PDISPLAY_TIMING, DTD;
> > +
> > +typedef struct _DETAILED_TIMING_DESCRIPTOR {
> > + UINT8 PixelClock[2];
> > + UINT8 HActive;
> > + UINT8 HBlank;
> > + UINT8 HActiveBlank;
> > + UINT8 VActive;
> > + UINT8 VBlank;
> > + UINT8 VActiveBlank;
> > + UINT8 HSyncOffset;
> > + UINT8 HSyncWidth;
> > + UINT8 VSyncOffsetWidth;
> > + UINT8 HVOffsetWidth;
> > + UINT8 HImageSize;
> > + UINT8 VImageSize;
> > + UINT8 HVImageSize;
> > + UINT8 HBorder;
> > + UINT8 VBorder;
> > + UINT8 EdidFlags;
> > +} DETAILED_TIMING_DESCRIPTOR, *PDETAILED_TIMING_DESCRIPTOR;
> > +
> > +/**
> > + Convert detailed timing descriptor to display timing format
> > +
> > + @param[in]DTDPtrPointer to detailed timing descriptor.
> > + @param[out] DisplayTimingPtr Pointer to display timing structure.
> > +
> > + @retval EFI_SUCCESS Detailed timing descriptor data was converted.
> > +
> > +**/
> > +EFI_STATUS
> > +ConvertDTDToDisplayTiming (
> > + IN DETAILED_TIMING_DESCRIPTOR *DTDPtr,
> > + OUT DISPLAY_TIMING *DisplayTimingPtr
> > + );
> > +
> > +/**
> > + Debug dump of Display Timing structure
> > +
> > + @param[in]DisplayTimingNamePtr Name of display timing structure.
> > + @param[in]DisplayTimingPtr Pointer to display timing structure.
> > +**/
> > +VOID
> > +PrintDisplayTiming (
> > + IN CHAR8*DisplayTimingNamePtr,
> > + IN DISPLAY_TIMING *DisplayTimingPtr
> > + );
> > +
> > +/**
> > + Check if EDID is valid
> > +
> > + @param[in]EdidDataPtr Pointer to EDID data.
> > +
> > + @retval EFI_SUCCESS
Re: [edk2] [PATCH v3 0/2] SortLib for UEFI SEC
Push them at 864cba9598a934ae3f7ae744b75d60e07dbd9fe9.. ae960002fe7cb50bf5bd9741abc5a1aa92718fe6 >-Original Message- >From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >Sent: Thursday, November 29, 2018 8:28 AM >To: Gao, Liming >Cc: Jeff Brasen ; Carsey, Jaben >; edk2-devel@lists.01.org; Dong, Eric >; Zeng, Star ; Leif Lindholm > >Subject: Re: [edk2] [PATCH v3 0/2] SortLib for UEFI SEC > >On Thu, 29 Nov 2018 at 01:26, Gao, Liming wrote: >> >> Jeff: >> I have given R-B on MdeModulePkg change. If EmbeddedPkg maintainer >has no comments on the change in EmbeddedPkg, I will help push your >patches. >> > >Looks fine to me > >Reviewed-by: Ard Biesheuvel > >> >-Original Message- >> >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >Jeff >> >Brasen >> >Sent: Thursday, November 29, 2018 1:56 AM >> >To: Carsey, Jaben ; edk2-devel@lists.01.org >> >Cc: Dong, Eric ; Zeng, Star >> >Subject: Re: [edk2] [PATCH v3 0/2] SortLib for UEFI SEC >> > >> >+cc package maintainers >> > >> > >> > >> > >> >From: Jeff Brasen >> >Sent: Wednesday, November 28, 2018 10:17 AM >> >To: Carsey, Jaben; edk2-devel@lists.01.org >> >Subject: Re: [edk2] [PATCH v3 0/2] SortLib for UEFI SEC >> > >> > >> >Any additional updates on this patch series? >> > >> > >> >Thanks, >> > >> >Jeff >> > >> > >> >From: Carsey, Jaben >> >Sent: Thursday, November 8, 2018 4:46:15 PM >> >To: Jeff Brasen; edk2-devel@lists.01.org >> >Subject: RE: [edk2] [PATCH v3 0/2] SortLib for UEFI SEC >> > >> >For the series. >> >Reviewed-by: Jaben Carsey >> > >> >> -Original Message- >> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf >Of >> >> Jeff Brasen >> >> Sent: Thursday, November 08, 2018 11:04 AM >> >> To: edk2-devel@lists.01.org >> >> Cc: Jeff Brasen >> >> Subject: [edk2] [PATCH v3 0/2] SortLib for UEFI SEC >> >> >> >> This patch series enables support for BaseSortLib in UEFI SEC Phase. >> >> This requires the addition of the AllocateZeroPool which is implemented >> >> in the PrePiMemoryAllocationLib. >> >> >> >> Changelog: >> >> v1 - Initial version >> >> v2 - Update order of NULL check in MemoryAllocationLib >> >> v3 - Switch to ZeroMem from SetMem >> >> >> >> Jeff Brasen (2): >> >> EmbeddedPkg/PrePiMemoryAllocationLib: Added AllocateZeroPool() >> >> MdeModulePkg/BaseSortLib: Enable for all module types >> >> >> >> .../PrePiMemoryAllocationLib/MemoryAllocationLib.c | 32 >> >> ++ >> >> MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf | 4 +-- >> >> 2 files changed, 34 insertions(+), 2 deletions(-) >> >> >> >> -- >> >> 2.7.4 >> >> >> >> ___ >> >> edk2-devel mailing list >> >> edk2-devel@lists.01.org >> >> https://lists.01.org/mailman/listinfo/edk2-devel >> > >> >--- >> >This email message is for the sole use of the intended recipient(s) and may >> >contain >> >confidential information. Any unauthorized review, use, disclosure or >> >distribution >> >is prohibited. If you are not the intended recipient, please contact the >sender >> >by >> >reply email and destroy all copies of the original message. >> >--- >> >___ >> >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 v3 0/2] SortLib for UEFI SEC
On Thu, 29 Nov 2018 at 01:26, Gao, Liming wrote: > > Jeff: > I have given R-B on MdeModulePkg change. If EmbeddedPkg maintainer has no > comments on the change in EmbeddedPkg, I will help push your patches. > Looks fine to me Reviewed-by: Ard Biesheuvel > >-Original Message- > >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jeff > >Brasen > >Sent: Thursday, November 29, 2018 1:56 AM > >To: Carsey, Jaben ; edk2-devel@lists.01.org > >Cc: Dong, Eric ; Zeng, Star > >Subject: Re: [edk2] [PATCH v3 0/2] SortLib for UEFI SEC > > > >+cc package maintainers > > > > > > > > > >From: Jeff Brasen > >Sent: Wednesday, November 28, 2018 10:17 AM > >To: Carsey, Jaben; edk2-devel@lists.01.org > >Subject: Re: [edk2] [PATCH v3 0/2] SortLib for UEFI SEC > > > > > >Any additional updates on this patch series? > > > > > >Thanks, > > > >Jeff > > > > > >From: Carsey, Jaben > >Sent: Thursday, November 8, 2018 4:46:15 PM > >To: Jeff Brasen; edk2-devel@lists.01.org > >Subject: RE: [edk2] [PATCH v3 0/2] SortLib for UEFI SEC > > > >For the series. > >Reviewed-by: Jaben Carsey > > > >> -Original Message- > >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > >> Jeff Brasen > >> Sent: Thursday, November 08, 2018 11:04 AM > >> To: edk2-devel@lists.01.org > >> Cc: Jeff Brasen > >> Subject: [edk2] [PATCH v3 0/2] SortLib for UEFI SEC > >> > >> This patch series enables support for BaseSortLib in UEFI SEC Phase. > >> This requires the addition of the AllocateZeroPool which is implemented > >> in the PrePiMemoryAllocationLib. > >> > >> Changelog: > >> v1 - Initial version > >> v2 - Update order of NULL check in MemoryAllocationLib > >> v3 - Switch to ZeroMem from SetMem > >> > >> Jeff Brasen (2): > >> EmbeddedPkg/PrePiMemoryAllocationLib: Added AllocateZeroPool() > >> MdeModulePkg/BaseSortLib: Enable for all module types > >> > >> .../PrePiMemoryAllocationLib/MemoryAllocationLib.c | 32 > >> ++ > >> MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf | 4 +-- > >> 2 files changed, 34 insertions(+), 2 deletions(-) > >> > >> -- > >> 2.7.4 > >> > >> ___ > >> edk2-devel mailing list > >> edk2-devel@lists.01.org > >> https://lists.01.org/mailman/listinfo/edk2-devel > > > >--- > >This email message is for the sole use of the intended recipient(s) and may > >contain > >confidential information. Any unauthorized review, use, disclosure or > >distribution > >is prohibited. If you are not the intended recipient, please contact the > >sender > >by > >reply email and destroy all copies of the original message. > >--- > >___ > >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 v3 0/2] SortLib for UEFI SEC
Jeff: I have given R-B on MdeModulePkg change. If EmbeddedPkg maintainer has no comments on the change in EmbeddedPkg, I will help push your patches. Thanks Liming >-Original Message- >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jeff >Brasen >Sent: Thursday, November 29, 2018 1:56 AM >To: Carsey, Jaben ; edk2-devel@lists.01.org >Cc: Dong, Eric ; Zeng, Star >Subject: Re: [edk2] [PATCH v3 0/2] SortLib for UEFI SEC > >+cc package maintainers > > > > >From: Jeff Brasen >Sent: Wednesday, November 28, 2018 10:17 AM >To: Carsey, Jaben; edk2-devel@lists.01.org >Subject: Re: [edk2] [PATCH v3 0/2] SortLib for UEFI SEC > > >Any additional updates on this patch series? > > >Thanks, > >Jeff > > >From: Carsey, Jaben >Sent: Thursday, November 8, 2018 4:46:15 PM >To: Jeff Brasen; edk2-devel@lists.01.org >Subject: RE: [edk2] [PATCH v3 0/2] SortLib for UEFI SEC > >For the series. >Reviewed-by: Jaben Carsey > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> Jeff Brasen >> Sent: Thursday, November 08, 2018 11:04 AM >> To: edk2-devel@lists.01.org >> Cc: Jeff Brasen >> Subject: [edk2] [PATCH v3 0/2] SortLib for UEFI SEC >> >> This patch series enables support for BaseSortLib in UEFI SEC Phase. >> This requires the addition of the AllocateZeroPool which is implemented >> in the PrePiMemoryAllocationLib. >> >> Changelog: >> v1 - Initial version >> v2 - Update order of NULL check in MemoryAllocationLib >> v3 - Switch to ZeroMem from SetMem >> >> Jeff Brasen (2): >> EmbeddedPkg/PrePiMemoryAllocationLib: Added AllocateZeroPool() >> MdeModulePkg/BaseSortLib: Enable for all module types >> >> .../PrePiMemoryAllocationLib/MemoryAllocationLib.c | 32 >> ++ >> MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf | 4 +-- >> 2 files changed, 34 insertions(+), 2 deletions(-) >> >> -- >> 2.7.4 >> >> ___ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel > >--- >This email message is for the sole use of the intended recipient(s) and may >contain >confidential information. Any unauthorized review, use, disclosure or >distribution >is prohibited. If you are not the intended recipient, please contact the >sender >by >reply email and destroy all copies of the original message. >--- >___ >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] BaseTool: Filter out unused structure pcds
Reviewed-by: Liming Gao
>-Original Message-
>From: Feng, Bob C
>Sent: Thursday, November 01, 2018 10:57 PM
>To: edk2-devel@lists.01.org
>Cc: Feng, Bob C ; Gao, Liming
>Subject: [Patch] BaseTool: Filter out unused structure pcds
>
>V2:
>Fixed the issue that V1 adds new check
>to the Pcds in the platform unused library INF files.
>It breaks the existing platform.
>
>V1：
>The current code handle all the structure pcds
>even if there is no module or library use them.
>This patch is going to filter out the unused structure pcds.
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Bob Feng
>Cc: Liming Gao
>---
> .../Source/Python/Workspace/DscBuildData.py | 22
>+++
> .../Source/Python/Workspace/InfBuildData.py | 9
> .../Python/Workspace/WorkspaceDatabase.py | 5 -
> 3 files changed, 35 insertions(+), 1 deletion(-)
>
>diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py
>b/BaseTools/Source/Python/Workspace/DscBuildData.py
>index 6d596b2b54..5d25d20639 100644
>--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
>+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
>@@ -1467,10 +1467,11 @@ class DscBuildData(PlatformBuildClassObject):
> if str_pcd_obj.Type in
>[self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_HII],
>self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_EX_HII]]:
> str_pcd_obj_str.DefaultFromDSC =
> {skuname:{defaultstore:
>str_pcd_obj.SkuInfoList[skuname].DefaultStoreDict.get(defaultstore,
>str_pcd_obj.SkuInfoList[skuname].HiiDefaultValue) for defaultstore in
>DefaultStores} for skuname in str_pcd_obj.SkuInfoList}
> else:
> str_pcd_obj_str.DefaultFromDSC =
> {skuname:{defaultstore:
>str_pcd_obj.SkuInfoList[skuname].DefaultStoreDict.get(defaultstore,
>str_pcd_obj.SkuInfoList[skuname].DefaultValue) for defaultstore in
>DefaultStores} for skuname in str_pcd_obj.SkuInfoList}
> S_pcd_set[Pcd] = str_pcd_obj_str
>+self.FilterStrcturePcd(S_pcd_set)
> if S_pcd_set:
> GlobalData.gStructurePcd[self.Arch] = S_pcd_set
> for stru_pcd in S_pcd_set.values():
> for skuid in SkuIds:
> if skuid in stru_pcd.SkuOverrideValues:
>@@ -1562,10 +1563,31 @@ class DscBuildData(PlatformBuildClassObject):
> elif TAB_DEFAULT in pcd.SkuInfoList and TAB_COMMON in
>pcd.SkuInfoList:
> del pcd.SkuInfoList[TAB_COMMON]
>
> map(self.FilterSkuSettings, [Pcds[pcdkey] for pcdkey in Pcds if
>Pcds[pcdkey].Type in DynamicPcdType])
> return Pcds
>+@cached_property
>+def PlatformUsedPcds(self):
>+FdfInfList = []
>+if GlobalData.gFdfParser:
>+FdfInfList = GlobalData.gFdfParser.Profile.InfList
>+FdfModuleList = [PathClass(NormPath(Inf), GlobalData.gWorkspace,
>Arch=self._Arch) for Inf in FdfInfList]
>+AllModulePcds = set()
>+ModuleSet = set(self._Modules.keys() + FdfModuleList)
>+for ModuleFile in ModuleSet:
>+ModuleData = self._Bdb[ModuleFile, self._Arch, self._Target,
>self._Toolchain]
>+AllModulePcds = AllModulePcds | ModuleData.PcdsName
>+for ModuleFile in self.LibraryInstances:
>+ModuleData = self._Bdb.CreateBuildObject(ModuleFile, self._Arch,
>self._Target, self._Toolchain)
>+AllModulePcds = AllModulePcds | ModuleData.PcdsName
>+return AllModulePcds
>+
>+#Filter the StrucutrePcd that is not used by any module in dsc file and
>fdf
>file.
>+def FilterStrcturePcd(self, S_pcd_set):
>+UnusedStruPcds = set(S_pcd_set.keys()) - self.PlatformUsedPcds
>+for (Token, TokenSpaceGuid) in UnusedStruPcds:
>+del S_pcd_set[(Token, TokenSpaceGuid)]
>
> ## Retrieve non-dynamic PCD settings
> #
> # @param TypePCD type
> #
>diff --git a/BaseTools/Source/Python/Workspace/InfBuildData.py
>b/BaseTools/Source/Python/Workspace/InfBuildData.py
>index d615cccdf7..99bbecfd1f 100644
>--- a/BaseTools/Source/Python/Workspace/InfBuildData.py
>+++ b/BaseTools/Source/Python/Workspace/InfBuildData.py
>@@ -792,10 +792,19 @@ class InfBuildData(ModuleBuildClassObject):
> RetVal.update(self._GetPcd(MODEL_PCD_FEATURE_FLAG))
> RetVal.update(self._GetPcd(MODEL_PCD_DYNAMIC))
> RetVal.update(self._GetPcd(MODEL_PCD_DYNAMIC_EX))
> return RetVal
>
>+@cached_property
>+def PcdsName(self):
>+PcdsName = set()
>+for Type in
>(MODEL_PCD_FIXED_AT_BUILD,MODEL_PCD_PATCHABLE_IN_MODULE,MO
>DEL_PCD_FEATURE_FLAG,MODEL_PCD_DYNAMIC,MODEL_PCD_DYNAMIC_E
>X):
>+RecordList = self._RawData[Type, self._Arch, self._Platform]
>+for TokenSpaceGuid, PcdCName, _, _, _, _, _ in RecordList:
>+PcdsName.add((PcdCName, TokenSpaceGuid))
>+return PcdsName
>+
> ## Retrieve build options specific to this module
>
Re: [edk2] [Patch v2] Maintainers.txt: Add the rule to hand over the package maintain role
Yes. I will update it based on your comments, then push the change. >-Original Message- >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >Laszlo Ersek >Sent: Thursday, November 29, 2018 4:03 AM >To: Philippe Mathieu-Daudé ; Gao, Liming >; edk2-devel@lists.01.org >Subject: Re: [edk2] [Patch v2] Maintainers.txt: Add the rule to hand over the >package maintain role > >On 11/28/18 16:13, Philippe Mathieu-Daudé wrote: >> Hi, >> >> On 28/11/18 15:03, Liming Gao wrote: >>> In V2, change his to the, and add new maintainers follow up. >>> >>> Contributed-under: TianoCore Contribution Agreement 1.1 >>> Signed-off-by: Liming Gao >>> --- >>> Maintainers.txt | 5 - >>> 1 file changed, 4 insertions(+), 1 deletion(-) >>> >>> diff --git a/Maintainers.txt b/Maintainers.txt >>> index 91a4657adc..e102114c34 100644 >>> --- a/Maintainers.txt >>> +++ b/Maintainers.txt >>> @@ -6,7 +6,10 @@ EDK II. >>> >>> In general, you should not privately email the maintainer. You should >>> email the edk2-devel list, and Cc the package maintainers and >>> -reviewers. >>> +reviewers. If the package maintainer wants to hand over the role to >> >> I'd move this to another paragraph, the first one is directed to >> contributors, the second one would be to maintainers. >> >>> +other people, the package maintainer should send the patch to update >>> +Maintainers.txt with new maintainer, and the new maintainer should >>> +follow up with an Acked-by or a Reviewed-by. >> >> I noticed an extra space at the end of the lines you added, which >> resulted in the following errors when applying: >> >> Applying: Maintainers.txt: Add the rule to hand over the package >> maintain role >> .git/rebase-apply/patch:14: trailing whitespace. >> reviewers. If the package maintainer wants to hand over the role to >> .git/rebase-apply/patch:15: trailing whitespace. >> other people, the package maintainer should send the patch to update >> .git/rebase-apply/patch:16: trailing whitespace. >> Maintainers.txt with new maintainer, and the new maintainer should >> error: patch failed: Maintainers.txt:6 >> error: Maintainers.txt: patch does not apply >> >> >> Thanks for adding the maintainership handover clarification, I appreciate :) >> >> With space fixed (same or another paragraphs): >> Reviewed-by: Philippe Mathieu-Daudé > >Good observations! > >My R-b stands, but if Liming decides to fix up the two warts that you >point out (just before pushing), that is, breaking the new sentence to a >new paragraph, and removing trailing whitespace, my R-b stands in that >case too. > >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] [RFC PATCH 2/2] ArmVirtPkg/QemuVirtMemInfoLib: trim the MMIO region mapping
On 11/28/18 20:16, Ard Biesheuvel wrote: > QEMU/mach-virt is rather unhelpful when it comes to tracking down > NULL pointer dereferences that occur while running in UEFI: since > we have NOR flash mapped at address 0x0, inadvertent reads go > unnoticed, and even most writes are silently dropped, unless you're > unlucky and the instruction in question is one that KVM cannot > emulate, in which case you end up with a QEMU crash like this: > > error: kvm run failed Function not implemented >PC=00013f7ff804 X00=00013f7ab108 X01=0064 > X02=00013f801988 X03=83c4 X04= > X05=9644 X06=fffd8270 X07=00013f7ab4a0 > X08=0001 X09=00013f803b88 X10=00013f7e88d0 > X11=0009 X12=00013f7ab554 X13=0008 > X14=0002 X15= X16= > X17= X18= X19= > X20=00013f81c000 X21=00013f7ab170 X22=00013f81c000 > X23=0918 X24=00013f407020 X25=00013f81c000 > X26=00013f803530 X27=00013f802000 X28=00013f7ab270 > X29=00013f7ab0d0 X30=00013f7fee10 SP=00013f7a6f30 > PSTATE=83c5 N--- EL1h > > and a warning in the host kernel log that load/store instruction > decoding is not supported by KVM. > > Given that the first page of the flash device is not actually > used anyway, let's reduce the mappings of the peripheral space > and the flash device (both of which cover page #0) to only cover > what is actually required. Please insert a pointer here, to the PcdFvBaseAddress / PcdFvSize settings in the "ArmVirtQemu.fdf" and "ArmVirtQemuKernel.fdf" files. You could even quote them verbatim (from both FDF files): ArmVirtQemu.fdf: > 0x1000|0x001ff000 > gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize ArmVirtQemuKernel.fdf: > 0x8000|0x001f8000 > gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize > After this change, any inadvertent read or write from/to the first > physical page will trigger a translation fault inside the guest, > regardless of the nature of the instruction, without crashing QEMU. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf| 4 ++-- > ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf | 2 ++ > ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c | 18 > +++--- > 3 files changed, 15 insertions(+), 9 deletions(-) > > diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf > b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf > index 5c5b841051ad..b6abc52531a8 100644 > --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf > +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf > @@ -39,9 +39,9 @@ [LibraryClasses] >PcdLib > > [Pcd] > - gArmTokenSpaceGuid.PcdFdBaseAddress > + gArmTokenSpaceGuid.PcdFvBaseAddress >gArmTokenSpaceGuid.PcdSystemMemoryBase >gArmTokenSpaceGuid.PcdSystemMemorySize > > [FixedPcd] > - gArmTokenSpaceGuid.PcdFdSize > + gArmTokenSpaceGuid.PcdFvSize > diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf > b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf > index d12089760b22..16802c5c414b 100644 > --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf > +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf > @@ -43,9 +43,11 @@ [LibraryClasses] > > [Pcd] >gArmTokenSpaceGuid.PcdFdBaseAddress > + gArmTokenSpaceGuid.PcdFvBaseAddress >gArmTokenSpaceGuid.PcdSystemMemoryBase >gArmTokenSpaceGuid.PcdSystemMemorySize > > [FixedPcd] >gArmTokenSpaceGuid.PcdFdSize > + gArmTokenSpaceGuid.PcdFvSize >gArmVirtTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress > diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c > b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c > index 0285a11b1d77..0818d0b42d6c 100644 > --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c > +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c > @@ -21,6 +21,10 @@ > // Number of Virtual Memory Map Descriptors > #define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS 5 > > +// mach-virt's 'miscellaneous device I/O' region > +#define MACH_VIRT_PERIPH_BASE 0x0800 > +#define MACH_VIRT_PERIPH_SIZE SIZE_128MB > + So this extends from the end of VIRT_FLASH (that is, one past it) to just before VIRT_PCIE_MMIO. Correct? If so, can you work that into the comment? (Not necessarily with the QEMU enum constants.) > /** >Return the Virtual Memory Map of your platform > > @@ -66,16 +70,16 @@ ArmVirtGetMemoryMap ( >VirtualMemoryTable[0].VirtualBase, >VirtualMemoryTable[0].Length)); > > - // Peripheral space before DRAM > -
Re: [edk2] [RFC PATCH 1/2] ArmVirtPkg/NorFlashQemuLib: disregard our primary FV
On 11/29/18 00:06, Ard Biesheuvel wrote:
> On Wed, 28 Nov 2018 at 23:54, Laszlo Ersek wrote:
>>
>> On 11/28/18 20:16, Ard Biesheuvel wrote:
>>> The primary FV contains the firmware boot image, which is not
>>> runtime updatable in our case. So exposing it to the NOR flash
>>> driver is undesirable, since it may attempt to modify the NOR
>>> flash contents.
>>
>> With you so far.
>>
>>> It is also rather pointless, since we don't
>>> keep anything there that we don't already expose via the FVB
>>> protocol instances that DXE core creates for us based on the
>>> FV HOBs
>>
>> I don't follow -- the DXE core does rely on the FV HOBs that we create for
>> it, but I don't remember the DXE core creating FVB protocol instances. An
>> FVB ("firmware volume block") protocol instance is usually created by a
>> flash driver. What am I missing?
>>
>> Do you mean handles with MemoryMapped(...)/FvFile(...) and
>> Fv(...)/FvFile(...) device paths on them? That point into firmware volumes
>> (that have been supposedly decompressed from flash to RAM)?
>>
>
> The DXE core dispatcher calls CoreProcessFvImageFile() for all FV
> images it encounters, but looking closer, that only happens for
> embedded FV images, not the primary one.
>
> But that still means the primary FV contains nothing we actually need.
OK; I missed CoreProcessFvImageFile(). Even though it's specified in
Vol2, "10.4 Firmware Volume Image Files", of the PI-1.6 spec.
Thanks
Laszlo
>
>>> (and so there is nothing the partition or file system
>>> drivers could potentially attach to via the block I/O and disk
>>> I/O protocol instances that the NOR flash driver creates)
>>
>> Ugh, NorFlashDxe creates BlockIo and DiskIo interfaces itself???
>>
>> Let's see...
>>
>> /*
>> Although DiskIoDxe will automatically install the DiskIO protocol whenever
>> we install the BlockIO protocol, its implementation is sub-optimal as it
>> reads
>> and writes entire blocks using the BlockIO protocol. In fact we can access
>> NOR flash with a finer granularity than that, so we can improve performance
>> by directly producing the DiskIO protocol.
>> */
>>
>> Umm... this flash driver does a lot more than I thought it did... or should.
>> :)
>>
>>
>> Anyway I think it should suffice to say in the commit message that we don't
>> want to expose the first flash device as an FVB protocol instance, because
>> (a) it's read-only, and (b) in the DXE phase, we don't use anything from
>> that flash device. It contains:
>> - the reset vector,
>> - the SEC module,
>> - (for ArmVirtQemu) the non-compressed PEI core, and PEIMs,
>> - and a compressed bunch of DXE modules (incl. the DXE core) which are
>> decompressed to RAM anyway.
>>
>>> So let's disregard the NOR flash block that covers the primary
>>> FV.
>>
>> OK.
>>
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Ard Biesheuvel
>>> ---
>>> ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf | 5 +
>>> ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c | 13 +++--
>>> 2 files changed, 16 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
>>> b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
>>> index d86ff36dbd58..c5752a243e6b 100644
>>> --- a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
>>> +++ b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
>>> @@ -28,6 +28,7 @@ [Sources.common]
>>> [Packages]
>>>MdePkg/MdePkg.dec
>>>ArmPlatformPkg/ArmPlatformPkg.dec
>>> + ArmPkg/ArmPkg.dec
>>>ArmVirtPkg/ArmVirtPkg.dec
>>>
>>> [LibraryClasses]
>>> @@ -40,3 +41,7 @@ [Protocols]
>>>
>>> [Depex]
>>>gFdtClientProtocolGuid
>>> +
>>> +[Pcd]
>>> + gArmTokenSpaceGuid.PcdFvBaseAddress
>>> + gArmTokenSpaceGuid.PcdFvSize
>>> diff --git a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
>>> b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
>>> index 2678f57eaaad..72b47bdb5a78 100644
>>> --- a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
>>> +++ b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
>>> @@ -75,13 +75,22 @@ NorFlashPlatformGetDevices (
>>>Size = SwapBytes64 (ReadUnaligned64 ((VOID *)[2]));
>>>Reg += 4;
>>>
>>> + PropSize -= 4 * sizeof (UINT32);
>>> +
>>> + //
>>> + // Disregard any flash devices that overlap with the primary FV.
>>> + // The firmware is not updatable from inside the guest anyway.
>>> + //
>>> + if ((PcdGet64 (PcdFvBaseAddress) + PcdGet32 (PcdFvSize) >= Base) &&
>>> + (Base + Size) >= PcdGet64 (PcdFvBaseAddress)) {
>>> +continue;
>>> + }
>>> +
>>
>> The overlap condition is expressed correctly, in general, I think; however,
>> both subconditions are off-by-one each. In each, we compare an exclusive
>> limit (one's end) with an inclusive limit (the other's base). And, when
>> exclusive equals inclusive, there is no overlap; they are directly adjacent
>> only. I'd
Re: [edk2] [RFC PATCH 1/2] ArmVirtPkg/NorFlashQemuLib: disregard our primary FV
On Wed, 28 Nov 2018 at 23:54, Laszlo Ersek wrote:
>
> On 11/28/18 20:16, Ard Biesheuvel wrote:
> > The primary FV contains the firmware boot image, which is not
> > runtime updatable in our case. So exposing it to the NOR flash
> > driver is undesirable, since it may attempt to modify the NOR
> > flash contents.
>
> With you so far.
>
> > It is also rather pointless, since we don't
> > keep anything there that we don't already expose via the FVB
> > protocol instances that DXE core creates for us based on the
> > FV HOBs
>
> I don't follow -- the DXE core does rely on the FV HOBs that we create for
> it, but I don't remember the DXE core creating FVB protocol instances. An FVB
> ("firmware volume block") protocol instance is usually created by a flash
> driver. What am I missing?
>
> Do you mean handles with MemoryMapped(...)/FvFile(...) and
> Fv(...)/FvFile(...) device paths on them? That point into firmware volumes
> (that have been supposedly decompressed from flash to RAM)?
>
The DXE core dispatcher calls CoreProcessFvImageFile() for all FV
images it encounters, but looking closer, that only happens for
embedded FV images, not the primary one.
But that still means the primary FV contains nothing we actually need.
> > (and so there is nothing the partition or file system
> > drivers could potentially attach to via the block I/O and disk
> > I/O protocol instances that the NOR flash driver creates)
>
> Ugh, NorFlashDxe creates BlockIo and DiskIo interfaces itself???
>
> Let's see...
>
> /*
> Although DiskIoDxe will automatically install the DiskIO protocol whenever
> we install the BlockIO protocol, its implementation is sub-optimal as it
> reads
> and writes entire blocks using the BlockIO protocol. In fact we can access
> NOR flash with a finer granularity than that, so we can improve performance
> by directly producing the DiskIO protocol.
> */
>
> Umm... this flash driver does a lot more than I thought it did... or should.
> :)
>
>
> Anyway I think it should suffice to say in the commit message that we don't
> want to expose the first flash device as an FVB protocol instance, because
> (a) it's read-only, and (b) in the DXE phase, we don't use anything from that
> flash device. It contains:
> - the reset vector,
> - the SEC module,
> - (for ArmVirtQemu) the non-compressed PEI core, and PEIMs,
> - and a compressed bunch of DXE modules (incl. the DXE core) which are
> decompressed to RAM anyway.
>
> > So let's disregard the NOR flash block that covers the primary
> > FV.
>
> OK.
>
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel
> > ---
> > ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf | 5 +
> > ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c | 13 +++--
> > 2 files changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
> > b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
> > index d86ff36dbd58..c5752a243e6b 100644
> > --- a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
> > +++ b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
> > @@ -28,6 +28,7 @@ [Sources.common]
> > [Packages]
> >MdePkg/MdePkg.dec
> >ArmPlatformPkg/ArmPlatformPkg.dec
> > + ArmPkg/ArmPkg.dec
> >ArmVirtPkg/ArmVirtPkg.dec
> >
> > [LibraryClasses]
> > @@ -40,3 +41,7 @@ [Protocols]
> >
> > [Depex]
> >gFdtClientProtocolGuid
> > +
> > +[Pcd]
> > + gArmTokenSpaceGuid.PcdFvBaseAddress
> > + gArmTokenSpaceGuid.PcdFvSize
> > diff --git a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > index 2678f57eaaad..72b47bdb5a78 100644
> > --- a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > +++ b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> > @@ -75,13 +75,22 @@ NorFlashPlatformGetDevices (
> >Size = SwapBytes64 (ReadUnaligned64 ((VOID *)[2]));
> >Reg += 4;
> >
> > + PropSize -= 4 * sizeof (UINT32);
> > +
> > + //
> > + // Disregard any flash devices that overlap with the primary FV.
> > + // The firmware is not updatable from inside the guest anyway.
> > + //
> > + if ((PcdGet64 (PcdFvBaseAddress) + PcdGet32 (PcdFvSize) >= Base) &&
> > + (Base + Size) >= PcdGet64 (PcdFvBaseAddress)) {
> > +continue;
> > + }
> > +
>
> The overlap condition is expressed correctly, in general, I think; however,
> both subconditions are off-by-one each. In each, we compare an exclusive
> limit (one's end) with an inclusive limit (the other's base). And, when
> exclusive equals inclusive, there is no overlap; they are directly adjacent
> only. I'd drop the equal signs.
>
>
> >mNorFlashDevices[Num].DeviceBaseAddress = (UINTN)Base;
> >mNorFlashDevices[Num].RegionBaseAddress = (UINTN)Base;
> >mNorFlashDevices[Num].Size = (UINTN)Size;
> >
Re: [edk2] [RFC PATCH 1/2] ArmVirtPkg/NorFlashQemuLib: disregard our primary FV
On 11/28/18 20:16, Ard Biesheuvel wrote:
> The primary FV contains the firmware boot image, which is not
> runtime updatable in our case. So exposing it to the NOR flash
> driver is undesirable, since it may attempt to modify the NOR
> flash contents.
With you so far.
> It is also rather pointless, since we don't
> keep anything there that we don't already expose via the FVB
> protocol instances that DXE core creates for us based on the
> FV HOBs
I don't follow -- the DXE core does rely on the FV HOBs that we create for it,
but I don't remember the DXE core creating FVB protocol instances. An FVB
("firmware volume block") protocol instance is usually created by a flash
driver. What am I missing?
Do you mean handles with MemoryMapped(...)/FvFile(...) and Fv(...)/FvFile(...)
device paths on them? That point into firmware volumes (that have been
supposedly decompressed from flash to RAM)?
> (and so there is nothing the partition or file system
> drivers could potentially attach to via the block I/O and disk
> I/O protocol instances that the NOR flash driver creates)
Ugh, NorFlashDxe creates BlockIo and DiskIo interfaces itself???
Let's see...
/*
Although DiskIoDxe will automatically install the DiskIO protocol whenever
we install the BlockIO protocol, its implementation is sub-optimal as it reads
and writes entire blocks using the BlockIO protocol. In fact we can access
NOR flash with a finer granularity than that, so we can improve performance
by directly producing the DiskIO protocol.
*/
Umm... this flash driver does a lot more than I thought it did... or should. :)
Anyway I think it should suffice to say in the commit message that we don't
want to expose the first flash device as an FVB protocol instance, because (a)
it's read-only, and (b) in the DXE phase, we don't use anything from that flash
device. It contains:
- the reset vector,
- the SEC module,
- (for ArmVirtQemu) the non-compressed PEI core, and PEIMs,
- and a compressed bunch of DXE modules (incl. the DXE core) which are
decompressed to RAM anyway.
> So let's disregard the NOR flash block that covers the primary
> FV.
OK.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf | 5 +
> ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c | 13 +++--
> 2 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
> b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
> index d86ff36dbd58..c5752a243e6b 100644
> --- a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
> +++ b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
> @@ -28,6 +28,7 @@ [Sources.common]
> [Packages]
>MdePkg/MdePkg.dec
>ArmPlatformPkg/ArmPlatformPkg.dec
> + ArmPkg/ArmPkg.dec
>ArmVirtPkg/ArmVirtPkg.dec
>
> [LibraryClasses]
> @@ -40,3 +41,7 @@ [Protocols]
>
> [Depex]
>gFdtClientProtocolGuid
> +
> +[Pcd]
> + gArmTokenSpaceGuid.PcdFvBaseAddress
> + gArmTokenSpaceGuid.PcdFvSize
> diff --git a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> index 2678f57eaaad..72b47bdb5a78 100644
> --- a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> +++ b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> @@ -75,13 +75,22 @@ NorFlashPlatformGetDevices (
>Size = SwapBytes64 (ReadUnaligned64 ((VOID *)[2]));
>Reg += 4;
>
> + PropSize -= 4 * sizeof (UINT32);
> +
> + //
> + // Disregard any flash devices that overlap with the primary FV.
> + // The firmware is not updatable from inside the guest anyway.
> + //
> + if ((PcdGet64 (PcdFvBaseAddress) + PcdGet32 (PcdFvSize) >= Base) &&
> + (Base + Size) >= PcdGet64 (PcdFvBaseAddress)) {
> +continue;
> + }
> +
The overlap condition is expressed correctly, in general, I think; however,
both subconditions are off-by-one each. In each, we compare an exclusive limit
(one's end) with an inclusive limit (the other's base). And, when exclusive
equals inclusive, there is no overlap; they are directly adjacent only. I'd
drop the equal signs.
>mNorFlashDevices[Num].DeviceBaseAddress = (UINTN)Base;
>mNorFlashDevices[Num].RegionBaseAddress = (UINTN)Base;
>mNorFlashDevices[Num].Size = (UINTN)Size;
>mNorFlashDevices[Num].BlockSize = QEMU_NOR_BLOCK_SIZE;
>Num++;
> -
> - PropSize -= 4 * sizeof (UINT32);
> }
>}
>
>
Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-test][PATCH] Framework/Include: allow usage with EFI version 2.7
Thanks for the patch. Pushed with the following changes copyright text by adding a comma as below: Copyright (c) 2018, ARM Ltd. All rights reserved. On Wed, 2018-11-28 at 14:59 +0530, Lokesh B V wrote: Thanks, Supreeth > EDK2 supports EFI version 2.7 and so allow UEFI-SCT to be > usable with this version of EFI. > > Cc: Supreeth Venkatesh > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Lokesh B V > --- > uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/Include/SctDef.h | > 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/uefi- > sct/SctPkg/TestInfrastructure/SCT/Framework/Include/SctDef.h b/uefi- > sct/SctPkg/TestInfrastructure/SCT/Framework/Include/SctDef.h > index d24c201..8fda374 100644 > --- a/uefi- > sct/SctPkg/TestInfrastructure/SCT/Framework/Include/SctDef.h > +++ b/uefi- > sct/SctPkg/TestInfrastructure/SCT/Framework/Include/SctDef.h > @@ -2,6 +2,7 @@ > >Copyright 2006 - 2017 Unified EFI, Inc. >Copyright (c) 2010 - 2017, Intel Corporation. All rights > reserved. > + Copyright (c) 2018 ARM Ltd. All rights reserved. > >This program and the accompanying materials >are licensed and made available under the terms and conditions of > the BSD License > @@ -46,6 +47,8 @@ Abstract: > #define EFI_SCT_NAMEL"UEFI2.5 Self > Certification Test(SCT2)" > #elif (EFI_SPECIFICATION_VERSION == EFI_2_60_SYSTEM_TABLE_REVISION) > #define EFI_SCT_NAMEL"UEFI2.6 Self > Certification Test(SCT2)" > +#elif (EFI_SPECIFICATION_VERSION == EFI_2_70_SYSTEM_TABLE_REVISION) > +#define EFI_SCT_NAMEL"UEFI2.7 Self > Certification Test(SCT2)" > #else > #error Unknown EFI_SPECIFICATION_VERSION > #endif ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-test][PATCH v2] SctPkg/build: Add support for GenBin tool build
On Wed, 2018-11-28 at 15:00 +0530, Lokesh B V wrote: > As the GenBin tool is necessary for SCT build, it is appropriate to > support it's build in the SCT build procedure. > > Cc: Supreeth Venkatesh > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Lokesh B V Reviewed-by: Supreeth Venkatesh Pushed with additional changes specified below (inline). > --- > Changes since v1: > * Addressed review comments from the mailing list > * modified Copyright content > > uefi-sct/SctPkg/build.sh | 28 +++- > 1 file changed, 15 insertions(+), 13 deletions(-) > > diff --git a/uefi-sct/SctPkg/build.sh b/uefi-sct/SctPkg/build.sh > index 73581c9..a469362 100755 > --- a/uefi-sct/SctPkg/build.sh > +++ b/uefi-sct/SctPkg/build.sh > @@ -1,7 +1,7 @@ > #!/bin/bash > # > # Copyright 2006 - 2015 Unified EFI, Inc. > -# Copyright (c) 2011 - 2015, ARM Ltd. All rights reserved. > +# Copyright (c) 2011 - 2018, ARM Ltd. All rights reserved. > # > # This program and the accompanying materials > # are licensed and made available under the terms and conditions of > the BSD License > @@ -228,21 +228,23 @@ else >echo using prebuilt tools > fi > > -# Copy GenBin file to Base tools directory > +rm -f $EDK_TOOLS_PATH/Source/C/bin/GenBin > + > +# build the GenBin if it doesn't yet exist > +echo Building GenBin > +make -C $EDK_TOOLS_PATH/../SctPkg/Tools/Source/GenBin make -C SctPkg/Tools/Source/GenBin is enough here. > +status=$? > +if test $status -ne 0 > +then > +echo Error while building GenBin > + exit -1 > +fi > + > +# Copy GenBin file to Base tools bin directory > DEST_DIR=`GetEdkToolsPathBinDirectory` > # Ensure the directory exist > mkdir -p $DEST_DIR > -case `uname -m` in > - x86_64) > - cp SctPkg/Tools/Bin/GenBin_lin_64 $DEST_DIR/GenBin > - ;; > - x86_32) > - cp SctPkg/Tools/Bin/GenBin_lin_32 $DEST_DIR/GenBin > - ;; > - *) > - cp SctPkg/Tools/Bin/GenBin_lin_32 $DEST_DIR/GenBin > - ;; > -esac > +cp $EDK_TOOLS_PATH/Source/C/bin/GenBin $DEST_DIR/GenBin > > # > # Build the SCT package ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-test][PATCH v2] SctPkg/Tools: Fix incorrect line ending detection by GenBin tool
On Wed, 2018-11-28 at 15:00 +0530, Lokesh B V wrote:
> Some windows editors uses "\r\n" for line feed. While processing uefi
> sct testcase info file, the GenBin tool logic to skip line feed
> doesn't
> consider the presence of carraige return(\r) in line feed. So this
Changed to "consider the presence of carriage return(\r)"
> results
> in incorrect format error.
>
> Fixed this issue by changing logic of Trim and Getline functions used
> in GenBin source code.
>
> Cc: Supreeth Venkatesh
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Lokesh B V
Reviewed-by: Supreeth Venkatesh
Pushed with additional changes inline below.
> ---
> Changes since v1:
> * Adopted changes suggested by Supreeth.
> * modified Copyright content
>
> uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c | 58 +-
> --
> 1 file changed, 26 insertions(+), 32 deletions(-)
>
> diff --git a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c b/uefi-
> sct/SctPkg/Tools/Source/GenBin/GenBin.c
> index 61bb35b..6d8e844 100644
> --- a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
> +++ b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
> @@ -2,6 +2,7 @@
>
>Copyright 2006 - 2010 Unified EFI, Inc.
>Copyright (c) 2010 Intel Corporation. All rights reserved.
> + Copyright (c) 2018 ARM Ltd. All rights reserved.
>
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of
> the BSD License
> @@ -32,6 +33,7 @@ Abstract:
> #include
> #include
> #include
> +#include
>
> //
> // Definitions
> @@ -49,7 +51,7 @@ PrintUsage (
>void
>);
>
> -void
> +char *
> Trim (
>char*String
>);
> @@ -159,50 +161,42 @@ PrintUsage (
> }
>
>
> -void
> +char *
> Trim (
>char*String
>)
> {
> - int Index1;
> - int Index2;
>int Length;
> + char *end;
>
>Length = strlen (String);
>
> - //
> - // Remove the space characters from the beginning of this string
> - //
> - for (Index1 = 0; Index1 < Length; Index1++) {
> -if ((String[Index1] != ' ' ) &&
> -(String[Index1] != '\t') &&
> -(String[Index1] != '\n')) {
> - break;
> -}
> - }
> -
> - for (Index2 = Index1; Index2 < Length; Index2++) {
> -String[Index2 - Index1] = String[Index2];
> + if (!Length) {
> +return String;
>}
>
> - Length = Length - Index1;
> + end = String + Length - 1;
>
>//
>// Remove the space characters from the end of this string
>//
> - for (Index1 = 0; Index1 < Length; Index1++) {
> -if ((String[Length - 1 - Index1] != ' ' ) &&
> -(String[Length - 1 - Index1] != '\t') &&
> -(String[Length - 1 - Index1] != '\n')) {
> - break;
> -}
> + while (end >= String && isspace (*end)) {
> +end--;
>}
>
> - String[Length - Index1] = '\0';
> + *(end + 1) = '\0';
> +
> + //
> + // Remove the space characters from the beginning of this string
> + //
> + while (*String && isspace (*String)) {
> +String++;
> + }
>
>//
>// Done
>//
> + return String;
> }
>
>
> @@ -227,20 +221,20 @@ GetLine (
>return -1;
> }
>
> -(*LineNo)++;
> -
> //
> // Remove the beginning and ending space characters
> //
> -Trim (String);
> +String = Trim (Result);
>
> //
> -// Ignore the empty line and comment line
> +// Skip the empty line and comment line
> //
> -if ((String[0] != '\0') &&
> -(String[0] != '#' )) {
> - break;
> +if ((String[0] == '\0') ||
> +(String[0] == '#' )) {
> + continue;
> }
> +
> +(*LineNo)++;
As LineNo is being used only for printing where the issue is, we should
increment line number as soon as fgets yields successful output.
Changed this and committed.
>}
>
>//
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-test][PATCH] SctPkg/UEFI: Fix invalid GUID value format error
On Wed, 2018-11-28 at 14:59 +0530, Lokesh B V wrote:
> Fix all GUID values that are defined with a invalid GUID
> value format.
>
> Cc: Supreeth Venkatesh
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Lokesh B V
Reviewed-by: Supreeth Venkatesh
Pushed.
> ---
> uefi-sct/SctPkg/UEFI/UEFI.dec | 204 +---
> --
> 1 file changed, 102 insertions(+), 102 deletions(-)
>
> diff --git a/uefi-sct/SctPkg/UEFI/UEFI.dec b/uefi-
> sct/SctPkg/UEFI/UEFI.dec
> index 14cc5b0..e3a6148 100644
> --- a/uefi-sct/SctPkg/UEFI/UEFI.dec
> +++ b/uefi-sct/SctPkg/UEFI/UEFI.dec
> @@ -1,7 +1,7 @@
> ## @file
> #
> # Copyright 2004 - 2017 Unified EFI, Inc.
> -# Copyright (c) 2014, ARM Limited. All rights reserved.
> +# Copyright (c) 2014 - 2018, ARM Limited. All rights reserved.
> # Copyright (c) 2016 - 2018, Intel Corporation. All rights
> reserved.
> # (C) Copyright 2017 Hewlett Packard Enterprise Development LP
> #
> @@ -44,25 +44,25 @@
>
>
> [Guids.common]
> - gBlackBoxEfiFileInfoGuid = { 0x9576e92, 0x6d3f, 0x11d2, 0x8e,
> 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b }
> - gBlackBoxEfiFileInfoIdGuid = { 0x9576e93, 0x6d3f, 0x11d2, 0x8e,
> 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b }
> + gBlackBoxEfiFileInfoGuid = { 0x9576e92, 0x6d3f, 0x11d2, { 0x8e,
> 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b }}
> + gBlackBoxEfiFileInfoIdGuid = { 0x9576e93, 0x6d3f, 0x11d2, { 0x8e,
> 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b }}
>gBlackBoxEfiFileSystemInfoGuid = { 0x09576E93, 0x6D3F, 0x11D2, {
> 0x8E, 0x39, 0x00, 0xA0, 0xC9, 0x69, 0x72, 0x3B }}
> - gBlackBoxEfiFileSystemVolumeLabelInfoIdGuid = { 0xDB47D7D3,0xFE81,
> 0x11d3, 0x9A, 0x35, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }
> - gBlackBoxEfiTcp4RegistryDataGuid = { 0x755B4303, 0xCAA5, 0x4481,
> 0xB1, 0x3D, 0x07, 0xBE, 0x14, 0xD5, 0x4D, 0x3F}
> - gBlackBoxEfiTcp6RegistryDataGuid = { 0x80623540, 0x7B41, 0x4306,
> 0x99, 0x87, 0x1B, 0xF6, 0xE5, 0xAD, 0x15, 0x3E }
> + gBlackBoxEfiFileSystemVolumeLabelInfoIdGuid = { 0xDB47D7D3,
> 0xFE81, 0x11d3, { 0x9A, 0x35, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }}
> + gBlackBoxEfiTcp4RegistryDataGuid = { 0x755B4303, 0xCAA5, 0x4481, {
> 0xB1, 0x3D, 0x07, 0xBE, 0x14, 0xD5, 0x4D, 0x3F }}
> + gBlackBoxEfiTcp6RegistryDataGuid = { 0x80623540, 0x7B41, 0x4306, {
> 0x99, 0x87, 0x1B, 0xF6, 0xE5, 0xAD, 0x15, 0x3E }}
>gBlackBoxEfiPcAnsiGuid = { 0xE0C14753, 0xF9BE, 0x11D2, { 0x9A,
> 0x0C, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }}
>gBlackBoxEfiVT100Guid = { 0xDFA66065, 0xB419, 0x11D3, { 0x9A,
> 0x2D, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }}
>gBlackBoxEfiVT100PlusGuid = { 0x7BAEC70B, 0x57E0, 0x4C76, { 0x8E,
> 0x87, 0x2F, 0x9E, 0x28, 0x08, 0x83, 0x43 }}
>gBlackBoxEfiVTUTF8Guid = { 0xAD15A0D6, 0x8BEC, 0x4ACF, { 0xA0,
> 0x73, 0xD0, 0x1D, 0xE7, 0x7E, 0x2D, 0x88 }}
>
> - gBlackBoxEfiHash2AlgorithmSha1Guid = { 0x2ae9d80f, 0x3fb2, 0x4095,
> 0xb7, 0xb1, 0xe9, 0x31, 0x57, 0xb9, 0x46, 0xb6 }
> - gBlackBoxEfiHash2AlgorithmSha224Guid = { 0x8df01a06, 0x9bd5,
> 0x4bf7, 0xb0, 0x21, 0xdb, 0x4f, 0xd9, 0xcc, 0xf4, 0x5b }
> - gBlackBoxEfiHash2AlgorithmSha256Guid = { 0x51aa59de, 0xfdf2,
> 0x4ea3, 0xbc, 0x63, 0x87, 0x5f, 0xb7, 0x84, 0x2e, 0xe9 }
> - gBlackBoxEfiHash2AlgorithmSha384Guid = { 0xefa96432, 0xde33,
> 0x4dd2, 0xae, 0xe6, 0x32, 0x8c, 0x33, 0xdf, 0x77, 0x7a }
> - gBlackBoxEfiHash2AlgorithmSha512Guid = { 0xcaa4381e, 0x750c,
> 0x4770, 0xb8, 0x70, 0x7a, 0x23, 0xb4, 0xe4, 0x21, 0x30 }
> - gBlackBoxEfiHash2AlgorithmMD5Guid = { 0xaf7c79c, 0x65b5, 0x4319,
> 0xb0, 0xae, 0x44, 0xec, 0x48, 0x4e, 0x4a, 0xd7 }
> - gBlackBoxEfiHash2AlgorithmSha1NoPadGuid = { 0x24c5dc2f, 0x53e2,
> 0x40ca, 0x9e, 0xd6, 0xa5, 0xd9, 0xa4, 0x9f, 0x46, 0x3b }
> - gBlackBoxEfiHash2AlgorithmSha256NoPadGuid = { 0x8628752a, 0x6cb7,
> 0x4814, 0x96, 0xfc, 0x24, 0xa8, 0x15, 0xac, 0x22, 0x26 }
> + gBlackBoxEfiHash2AlgorithmSha1Guid = { 0x2ae9d80f, 0x3fb2, 0x4095,
> { 0xb7, 0xb1, 0xe9, 0x31, 0x57, 0xb9, 0x46, 0xb6 }}
> + gBlackBoxEfiHash2AlgorithmSha224Guid = { 0x8df01a06, 0x9bd5,
> 0x4bf7, { 0xb0, 0x21, 0xdb, 0x4f, 0xd9, 0xcc, 0xf4, 0x5b }}
> + gBlackBoxEfiHash2AlgorithmSha256Guid = { 0x51aa59de, 0xfdf2,
> 0x4ea3, { 0xbc, 0x63, 0x87, 0x5f, 0xb7, 0x84, 0x2e, 0xe9 }}
> + gBlackBoxEfiHash2AlgorithmSha384Guid = { 0xefa96432, 0xde33,
> 0x4dd2, { 0xae, 0xe6, 0x32, 0x8c, 0x33, 0xdf, 0x77, 0x7a }}
> + gBlackBoxEfiHash2AlgorithmSha512Guid = { 0xcaa4381e, 0x750c,
> 0x4770, { 0xb8, 0x70, 0x7a, 0x23, 0xb4, 0xe4, 0x21, 0x30 }}
> + gBlackBoxEfiHash2AlgorithmMD5Guid = { 0xaf7c79c, 0x65b5, 0x4319, {
> 0xb0, 0xae, 0x44, 0xec, 0x48, 0x4e, 0x4a, 0xd7 }}
> + gBlackBoxEfiHash2AlgorithmSha1NoPadGuid = { 0x24c5dc2f, 0x53e2,
> 0x40ca, { 0x9e, 0xd6, 0xa5, 0xd9, 0xa4, 0x9f, 0x46, 0x3b }}
> + gBlackBoxEfiHash2AlgorithmSha256NoPadGuid = { 0x8628752a, 0x6cb7,
> 0x4814, { 0x96, 0xfc, 0x24, 0xa8, 0x15, 0xac, 0x22, 0x26 }}
>
>
>gBlackBoxEfiCertSha256Guid = { 0xc1c41626, 0x504c,
> 0x4092, {0xac, 0xa9, 0x41, 0xf9, 0x36, 0x93, 0x43, 0x28 }}
> @@
Re: [edk2] [edk2-test][PATCH] Add *.o and *.d pattern to .gitignore
On Wed, 2018-11-28 at 15:00 +0530, Lokesh B V wrote: > Ignore *.o and *.d untracked files. > > Cc: Supreeth Venkatesh > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Lokesh B V Reviewed-by: Supreeth Venkatesh Pushed. > --- > .gitignore | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/.gitignore b/.gitignore > index 821ed66..3b8d818 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -1,2 +1,3 @@ > Build/ > tags/ > +*.[od] ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-test][PATCH] SctPkg/UEFI: Fix invalid GUID value format error
On Wed, 2018-11-28 at 20:35 +, Supreeth Venkatesh wrote:
On Wed, 2018-11-28 at 14:59 +0530, Lokesh B V wrote:
> Fix all GUID values that are defined with a invalid GUID
> value format.
>
> Cc: Supreeth Venkatesh
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Lokesh B V
Reviewed-by: Supreeth Venkatesh
Pushed.
> ---
> uefi-sct/SctPkg/UEFI/UEFI.dec | 204 +---
> --
> 1 file changed, 102 insertions(+), 102 deletions(-)
>
> diff --git a/uefi-sct/SctPkg/UEFI/UEFI.dec b/uefi-
> sct/SctPkg/UEFI/UEFI.dec
> index 14cc5b0..e3a6148 100644
> --- a/uefi-sct/SctPkg/UEFI/UEFI.dec
> +++ b/uefi-sct/SctPkg/UEFI/UEFI.dec
> @@ -1,7 +1,7 @@
> ## @file
> #
> # Copyright 2004 - 2017 Unified EFI, Inc.
> -# Copyright (c) 2014, ARM Limited. All rights reserved.
> +# Copyright (c) 2014 - 2018, ARM Limited. All rights reserved.
> # Copyright (c) 2016 - 2018, Intel Corporation. All rights
> reserved.
> # (C) Copyright 2017 Hewlett Packard Enterprise Development LP
> #
> @@ -44,25 +44,25 @@
>
>
> [Guids.common]
> - gBlackBoxEfiFileInfoGuid = { 0x9576e92, 0x6d3f, 0x11d2, 0x8e,
> 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b }
> - gBlackBoxEfiFileInfoIdGuid = { 0x9576e93, 0x6d3f, 0x11d2, 0x8e,
> 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b }
> + gBlackBoxEfiFileInfoGuid = { 0x9576e92, 0x6d3f, 0x11d2, { 0x8e,
> 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b }}
> + gBlackBoxEfiFileInfoIdGuid = { 0x9576e93, 0x6d3f, 0x11d2, { 0x8e,
> 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b }}
>gBlackBoxEfiFileSystemInfoGuid = { 0x09576E93, 0x6D3F, 0x11D2, {
> 0x8E, 0x39, 0x00, 0xA0, 0xC9, 0x69, 0x72, 0x3B }}
> - gBlackBoxEfiFileSystemVolumeLabelInfoIdGuid = { 0xDB47D7D3,0xFE81,
> 0x11d3, 0x9A, 0x35, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }
> - gBlackBoxEfiTcp4RegistryDataGuid = { 0x755B4303, 0xCAA5, 0x4481,
> 0xB1, 0x3D, 0x07, 0xBE, 0x14, 0xD5, 0x4D, 0x3F}
> - gBlackBoxEfiTcp6RegistryDataGuid = { 0x80623540, 0x7B41, 0x4306,
> 0x99, 0x87, 0x1B, 0xF6, 0xE5, 0xAD, 0x15, 0x3E }
> + gBlackBoxEfiFileSystemVolumeLabelInfoIdGuid = { 0xDB47D7D3,
> 0xFE81, 0x11d3, { 0x9A, 0x35, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }}
> + gBlackBoxEfiTcp4RegistryDataGuid = { 0x755B4303, 0xCAA5, 0x4481, {
> 0xB1, 0x3D, 0x07, 0xBE, 0x14, 0xD5, 0x4D, 0x3F }}
> + gBlackBoxEfiTcp6RegistryDataGuid = { 0x80623540, 0x7B41, 0x4306, {
> 0x99, 0x87, 0x1B, 0xF6, 0xE5, 0xAD, 0x15, 0x3E }}
>gBlackBoxEfiPcAnsiGuid = { 0xE0C14753, 0xF9BE, 0x11D2, { 0x9A,
> 0x0C, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }}
>gBlackBoxEfiVT100Guid = { 0xDFA66065, 0xB419, 0x11D3, { 0x9A,
> 0x2D, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }}
>gBlackBoxEfiVT100PlusGuid = { 0x7BAEC70B, 0x57E0, 0x4C76, { 0x8E,
> 0x87, 0x2F, 0x9E, 0x28, 0x08, 0x83, 0x43 }}
>gBlackBoxEfiVTUTF8Guid = { 0xAD15A0D6, 0x8BEC, 0x4ACF, { 0xA0,
> 0x73, 0xD0, 0x1D, 0xE7, 0x7E, 0x2D, 0x88 }}
>
> - gBlackBoxEfiHash2AlgorithmSha1Guid = { 0x2ae9d80f, 0x3fb2, 0x4095,
> 0xb7, 0xb1, 0xe9, 0x31, 0x57, 0xb9, 0x46, 0xb6 }
> - gBlackBoxEfiHash2AlgorithmSha224Guid = { 0x8df01a06, 0x9bd5,
> 0x4bf7, 0xb0, 0x21, 0xdb, 0x4f, 0xd9, 0xcc, 0xf4, 0x5b }
> - gBlackBoxEfiHash2AlgorithmSha256Guid = { 0x51aa59de, 0xfdf2,
> 0x4ea3, 0xbc, 0x63, 0x87, 0x5f, 0xb7, 0x84, 0x2e, 0xe9 }
> - gBlackBoxEfiHash2AlgorithmSha384Guid = { 0xefa96432, 0xde33,
> 0x4dd2, 0xae, 0xe6, 0x32, 0x8c, 0x33, 0xdf, 0x77, 0x7a }
> - gBlackBoxEfiHash2AlgorithmSha512Guid = { 0xcaa4381e, 0x750c,
> 0x4770, 0xb8, 0x70, 0x7a, 0x23, 0xb4, 0xe4, 0x21, 0x30 }
> - gBlackBoxEfiHash2AlgorithmMD5Guid = { 0xaf7c79c, 0x65b5, 0x4319,
> 0xb0, 0xae, 0x44, 0xec, 0x48, 0x4e, 0x4a, 0xd7 }
> - gBlackBoxEfiHash2AlgorithmSha1NoPadGuid = { 0x24c5dc2f, 0x53e2,
> 0x40ca, 0x9e, 0xd6, 0xa5, 0xd9, 0xa4, 0x9f, 0x46, 0x3b }
> - gBlackBoxEfiHash2AlgorithmSha256NoPadGuid = { 0x8628752a, 0x6cb7,
> 0x4814, 0x96, 0xfc, 0x24, 0xa8, 0x15, 0xac, 0x22, 0x26 }
> + gBlackBoxEfiHash2AlgorithmSha1Guid = { 0x2ae9d80f, 0x3fb2, 0x4095,
> { 0xb7, 0xb1, 0xe9, 0x31, 0x57, 0xb9, 0x46, 0xb6 }}
> + gBlackBoxEfiHash2AlgorithmSha224Guid = { 0x8df01a06, 0x9bd5,
> 0x4bf7, { 0xb0, 0x21, 0xdb, 0x4f, 0xd9, 0xcc, 0xf4, 0x5b }}
> + gBlackBoxEfiHash2AlgorithmSha256Guid = { 0x51aa59de, 0xfdf2,
> 0x4ea3, { 0xbc, 0x63, 0x87, 0x5f, 0xb7, 0x84, 0x2e, 0xe9 }}
> + gBlackBoxEfiHash2AlgorithmSha384Guid = { 0xefa96432, 0xde33,
> 0x4dd2, { 0xae, 0xe6, 0x32, 0x8c, 0x33, 0xdf, 0x77, 0x7a }}
> + gBlackBoxEfiHash2AlgorithmSha512Guid = { 0xcaa4381e, 0x750c,
> 0x4770, { 0xb8, 0x70, 0x7a, 0x23, 0xb4, 0xe4, 0x21, 0x30 }}
> + gBlackBoxEfiHash2AlgorithmMD5Guid = { 0xaf7c79c, 0x65b5, 0x4319, {
> 0xb0, 0xae, 0x44, 0xec, 0x48, 0x4e, 0x4a, 0xd7 }}
> + gBlackBoxEfiHash2AlgorithmSha1NoPadGuid = { 0x24c5dc2f, 0x53e2,
> 0x40ca, { 0x9e, 0xd6, 0xa5, 0xd9, 0xa4, 0x9f, 0x46, 0x3b }}
> + gBlackBoxEfiHash2AlgorithmSha256NoPadGuid = { 0x8628752a, 0x6cb7,
> 0x4814, { 0x96, 0xfc, 0x24, 0xa8, 0x15, 0xac, 0x22, 0x26 }}
>
>
>gBlackBoxEfiCertSha256Guid = { 0xc1c41626, 0x504c,
>
Re: [edk2] [edk2-announce] Research Request
On 11/28/18 19:31, Jeremiah Cox wrote: > Test PR submitted Thanks! Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2] ArmPkg/ArmScmiDxe: Add clock enable function
Add function to allow enabling and disabling of the clock using the SCMI
interface. Add gArmScmiClock2ProtocolGuid to distinguish platforms that
support new API from those that just have the older protocol.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jeff Brasen
Cc: Ard Biesheuvel
Cc: Leif Lindholm
Cc: Grish Pathak
---
ArmPkg/ArmPkg.dec | 1 +
.../ArmScmiDxe/ArmScmiClockProtocolPrivate.h | 7 +++
ArmPkg/Drivers/ArmScmiDxe/ArmScmiDxe.inf | 1 +
ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c | 52 +-
ArmPkg/Include/Protocol/ArmScmiClockProtocol.h | 27 +++
5 files changed, 87 insertions(+), 1 deletion(-)
diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index d99eb67..2f5e5b3 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -59,6 +59,7 @@
## Arm System Control and Management Interface(SCMI) Clock management
protocol
## ArmPkg/Include/Protocol/ArmScmiClockProtocol.h
gArmScmiClockProtocolGuid = { 0x91ce67a8, 0xe0aa, 0x4012, { 0xb9, 0x9f,
0xb6, 0xfc, 0xf3, 0x4, 0x8e, 0xaa } }
+ gArmScmiClock2ProtocolGuid = { 0xb8d8caf2, 0x9e94, 0x462c, { 0xa8, 0x34,
0x6c, 0x99, 0xfc, 0x05, 0xef, 0xcf } }
## Arm System Control and Management Interface(SCMI) Clock management
protocol
## ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h
diff --git a/ArmPkg/Drivers/ArmScmiDxe/ArmScmiClockProtocolPrivate.h
b/ArmPkg/Drivers/ArmScmiDxe/ArmScmiClockProtocolPrivate.h
index 0d1ec6f..c135bac 100644
--- a/ArmPkg/Drivers/ArmScmiDxe/ArmScmiClockProtocolPrivate.h
+++ b/ArmPkg/Drivers/ArmScmiDxe/ArmScmiClockProtocolPrivate.h
@@ -59,6 +59,13 @@ typedef struct {
CLOCK_RATE_DWORD Rate;
} CLOCK_RATE_SET_ATTRIBUTES;
+
+// Message parameters for CLOCK_CONFIG_SET command.
+typedef struct {
+ UINT32 ClockId;
+ UINT32 Attributes;
+} CLOCK_CONFIG_SET_ATTRIBUTES;
+
// if ClockAttr Bit[0] is set then clock device is enabled.
#define CLOCK_ENABLE_MASK 0x1
#define CLOCK_ENABLED(ClockAttr) ((ClockAttr & CLOCK_ENABLE_MASK) == 1)
diff --git a/ArmPkg/Drivers/ArmScmiDxe/ArmScmiDxe.inf
b/ArmPkg/Drivers/ArmScmiDxe/ArmScmiDxe.inf
index 05ce9c0..9b29b9f 100644
--- a/ArmPkg/Drivers/ArmScmiDxe/ArmScmiDxe.inf
+++ b/ArmPkg/Drivers/ArmScmiDxe/ArmScmiDxe.inf
@@ -46,6 +46,7 @@
[Protocols]
gArmScmiBaseProtocolGuid
gArmScmiClockProtocolGuid
+ gArmScmiClock2ProtocolGuid
gArmScmiPerformanceProtocolGuid
[Depex]
diff --git a/ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c
b/ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c
index 64d2afa..27b53d3 100644
--- a/ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c
+++ b/ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c
@@ -388,6 +388,53 @@ ClockRateSet (
return Status;
}
+/** Enable/Disable specified clock.
+
+ @param[in] ThisA Pointer to SCMI_CLOCK_PROTOCOL Instance.
+ @param[in] ClockId Identifier for the clock device.
+ @param[in] Enable TRUE to enable, FALSE to disable.
+
+ @retval EFI_SUCCESS Clock enable/disable successful.
+ @retval EFI_DEVICE_ERROR SCP returns an SCMI error.
+ @retval !(EFI_SUCCESS) Other errors.
+**/
+STATIC
+EFI_STATUS
+ClockEnable (
+ IN SCMI_CLOCK2_PROTOCOL *This,
+ IN UINT32 ClockId,
+ IN BOOLEAN Enable
+ )
+{
+ EFI_STATUS Status;
+ CLOCK_CONFIG_SET_ATTRIBUTES *ClockConfigSetAttributes;
+ SCMI_COMMANDCmd;
+ UINT32 PayloadLength;
+
+ Status = ScmiCommandGetPayload ((UINT32**));
+ if (EFI_ERROR (Status)) {
+return Status;
+ }
+
+ // Fill arguments for clock protocol command.
+ ClockConfigSetAttributes->ClockId= ClockId;
+ ClockConfigSetAttributes->Attributes = Enable ? BIT0 : 0;
+
+ Cmd.ProtocolId = SCMI_PROTOCOL_ID_CLOCK;
+ Cmd.MessageId = SCMI_MESSAGE_ID_CLOCK_CONFIG_SET;
+
+ PayloadLength = sizeof (CLOCK_CONFIG_SET_ATTRIBUTES);
+
+ // Execute and wait for response on a SCMI channel.
+ Status = ScmiCommandExecute (
+ ,
+ ,
+ NULL
+ );
+
+ return Status;
+}
+
// Instance of the SCMI clock management protocol.
STATIC CONST SCMI_CLOCK_PROTOCOL ScmiClockProtocol = {
ClockGetVersion,
@@ -395,7 +442,8 @@ STATIC CONST SCMI_CLOCK_PROTOCOL ScmiClockProtocol = {
ClockGetClockAttributes,
ClockDescribeRates,
ClockRateGet,
- ClockRateSet
+ ClockRateSet,
+ ClockEnable
};
/** Initialize clock management protocol and install protocol on a given
handle.
@@ -413,6 +461,8 @@ ScmiClockProtocolInit (
Handle,
,
,
+,
+,
NULL
);
}
diff --git a/ArmPkg/Include/Protocol/ArmScmiClockProtocol.h
b/ArmPkg/Include/Protocol/ArmScmiClockProtocol.h
index 3db26cb..28d3d59 100644
--- a/ArmPkg/Include/Protocol/ArmScmiClockProtocol.h
+++ b/ArmPkg/Include/Protocol/ArmScmiClockProtocol.h
@@ -24,7 +24,12 @@
0x91ce67a8,
Re: [edk2] [Patch v2] Maintainers.txt: Add the rule to hand over the package maintain role
On 11/28/18 16:13, Philippe Mathieu-Daudé wrote: > Hi, > > On 28/11/18 15:03, Liming Gao wrote: >> In V2, change his to the, and add new maintainers follow up. >> >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Liming Gao >> --- >> Maintainers.txt | 5 - >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/Maintainers.txt b/Maintainers.txt >> index 91a4657adc..e102114c34 100644 >> --- a/Maintainers.txt >> +++ b/Maintainers.txt >> @@ -6,7 +6,10 @@ EDK II. >> >> In general, you should not privately email the maintainer. You should >> email the edk2-devel list, and Cc the package maintainers and >> -reviewers. >> +reviewers. If the package maintainer wants to hand over the role to > > I'd move this to another paragraph, the first one is directed to > contributors, the second one would be to maintainers. > >> +other people, the package maintainer should send the patch to update >> +Maintainers.txt with new maintainer, and the new maintainer should >> +follow up with an Acked-by or a Reviewed-by. > > I noticed an extra space at the end of the lines you added, which > resulted in the following errors when applying: > > Applying: Maintainers.txt: Add the rule to hand over the package > maintain role > .git/rebase-apply/patch:14: trailing whitespace. > reviewers. If the package maintainer wants to hand over the role to > .git/rebase-apply/patch:15: trailing whitespace. > other people, the package maintainer should send the patch to update > .git/rebase-apply/patch:16: trailing whitespace. > Maintainers.txt with new maintainer, and the new maintainer should > error: patch failed: Maintainers.txt:6 > error: Maintainers.txt: patch does not apply > > > Thanks for adding the maintainership handover clarification, I appreciate :) > > With space fixed (same or another paragraphs): > Reviewed-by: Philippe Mathieu-Daudé Good observations! My R-b stands, but if Liming decides to fix up the two warts that you point out (just before pushing), that is, breaking the new sentence to a new paragraph, and removing trailing whitespace, my R-b stands in that case too. Thanks! Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch v2] Maintainers.txt: Add the rule to hand over the package maintain role
On 11/28/18 15:03, Liming Gao wrote: > In V2, change his to the, and add new maintainers follow up. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Liming Gao > --- > Maintainers.txt | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/Maintainers.txt b/Maintainers.txt > index 91a4657adc..e102114c34 100644 > --- a/Maintainers.txt > +++ b/Maintainers.txt > @@ -6,7 +6,10 @@ EDK II. > > In general, you should not privately email the maintainer. You should > email the edk2-devel list, and Cc the package maintainers and > -reviewers. > +reviewers. If the package maintainer wants to hand over the role to > +other people, the package maintainer should send the patch to update > +Maintainers.txt with new maintainer, and the new maintainer should > +follow up with an Acked-by or a Reviewed-by. > > Descriptions of section entries: > > Reviewed-by: Laszlo Ersek ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 16/16] EmbeddedPkg/EmbeddedPkg.dec: drop PcdPrePiCpuMemorySize declarations
On 11/28/18 15:33, Ard Biesheuvel wrote: > PcdPrePiCpuMemorySize is no longer used so drop the declarations from > the package DEC file. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > EmbeddedPkg/EmbeddedPkg.dec | 4 > 1 file changed, 4 deletions(-) > > diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec > index 28a143865d0e..ff5aab07d745 100644 > --- a/EmbeddedPkg/EmbeddedPkg.dec > +++ b/EmbeddedPkg/EmbeddedPkg.dec > @@ -170,22 +170,18 @@ [PcdsFixedAtBuild.common] >gEmbeddedTokenSpaceGuid.PcdAndroidBootDevicePath|L""|VOID*|0x0057 > > [PcdsFixedAtBuild.ARM] > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize|32|UINT8|0x0010 >gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|0|UINT8|0x0011 > ># ISP1761 USB OTG Controller >gEmbeddedTokenSpaceGuid.PcdIsp1761BaseAddress|0|UINT32|0x0021 > > [PcdsFixedAtBuild.AARCH64] > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize|48|UINT8|0x0010 >gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|0|UINT8|0x0011 > > [PcdsFixedAtBuild.IA32] > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize|36|UINT8|0x0010 >gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|16|UINT8|0x0011 > > [PcdsFixedAtBuild.X64] > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize|52|UINT8|0x0010 >gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|16|UINT8|0x0011 > > [PcdsFixedAtBuild.common, PcdsDynamic.common] > Reviewed-by: Laszlo Ersek ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 15/16] ArmVirtPkg: drop PcdPrePiCpuMemorySize assignments from all platforms
On 11/28/18 15:33, Ard Biesheuvel wrote: > PcdPrePiCpuMemorySize is no longer used so drop the PCD overrides > from all platform descriptions in ArmVirtPkg. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > ArmVirtPkg/ArmVirt.dsc.inc | 3 --- > ArmVirtPkg/ArmVirtQemu.dsc | 4 > ArmVirtPkg/ArmVirtQemuKernel.dsc | 4 > 3 files changed, 11 deletions(-) > > diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc > index 70a0ac4d786c..fbdb5c982604 100644 > --- a/ArmVirtPkg/ArmVirt.dsc.inc > +++ b/ArmVirtPkg/ArmVirt.dsc.inc > @@ -388,9 +388,6 @@ [PcdsFixedAtBuild.common] ># >gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE > > -[PcdsFixedAtBuild.ARM] > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize|40 > - > [Components.common] ># ># Ramdisk support > diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc > index 885c6b14b844..a107b6bb5104 100644 > --- a/ArmVirtPkg/ArmVirtQemu.dsc > +++ b/ArmVirtPkg/ArmVirtQemu.dsc > @@ -143,10 +143,6 @@ [PcdsFixedAtBuild.common] >gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|16 > > [PcdsFixedAtBuild.AARCH64] > - # KVM limits it IPA space to 40 bits (1 TB), so there is no need to > - # support anything bigger, even if the host hardware does > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize|40 > - ># Clearing BIT0 in this PCD prevents installing a 32-bit SMBIOS entry > point, ># if the entry point version is >= 3.0. AARCH64 OSes cannot assume the ># presence of the 32-bit entry point anyway (because many AARCH64 systems > diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc > b/ArmVirtPkg/ArmVirtQemuKernel.dsc > index 434d6861a56f..d8fbf14e8f4e 100644 > --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc > +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc > @@ -157,10 +157,6 @@ [PcdsFixedAtBuild.AARCH64] ># >gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|16 > > - # KVM limits it IPA space to 40 bits (1 TB), so there is no need to > - # support anything bigger, even if the host hardware does > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize|40 > - > [PcdsDynamicDefault.common] >gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3 > > Reviewed-by: Laszlo Ersek ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 14/16] EmbeddedPkg/PrePiLib: drop unused PCD reference
On 11/28/18 15:33, Ard Biesheuvel wrote: > Drop the reference to gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize > which is never used. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > EmbeddedPkg/Library/PrePiLib/PrePiLib.inf | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/EmbeddedPkg/Library/PrePiLib/PrePiLib.inf > b/EmbeddedPkg/Library/PrePiLib/PrePiLib.inf > index de68405098c0..3dba884b1f31 100644 > --- a/EmbeddedPkg/Library/PrePiLib/PrePiLib.inf > +++ b/EmbeddedPkg/Library/PrePiLib/PrePiLib.inf > @@ -69,7 +69,6 @@ [Protocols] > > > [FixedPcd.common] > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize >gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize > >gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory > Reviewed-by: Laszlo Ersek ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 13/16] ArmPlatformPkg/PlatformPei: drop unused PCD references
On 11/28/18 15:33, Ard Biesheuvel wrote: > Drop some PCD references that are not actually referenced from the > PlatformPei code. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > ArmPlatformPkg/PlatformPei/PlatformPeiLib.inf | 3 --- > ArmPlatformPkg/PlatformPei/PlatformPeim.inf | 3 --- > 2 files changed, 6 deletions(-) > > diff --git a/ArmPlatformPkg/PlatformPei/PlatformPeiLib.inf > b/ArmPlatformPkg/PlatformPei/PlatformPeiLib.inf > index 314789d0a990..23bb3f37e766 100644 > --- a/ArmPlatformPkg/PlatformPei/PlatformPeiLib.inf > +++ b/ArmPlatformPkg/PlatformPei/PlatformPeiLib.inf > @@ -46,8 +46,5 @@ [FixedPcd] >gArmTokenSpaceGuid.PcdFvBaseAddress >gArmTokenSpaceGuid.PcdFvSize > > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize > - > [depex] >TRUE > diff --git a/ArmPlatformPkg/PlatformPei/PlatformPeim.inf > b/ArmPlatformPkg/PlatformPei/PlatformPeim.inf > index 423b9ab858d1..4934baa838e1 100644 > --- a/ArmPlatformPkg/PlatformPei/PlatformPeim.inf > +++ b/ArmPlatformPkg/PlatformPei/PlatformPeim.inf > @@ -57,9 +57,6 @@ [FixedPcd] >gArmTokenSpaceGuid.PcdFvBaseAddress >gArmTokenSpaceGuid.PcdFvSize > > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize > - > [Depex] >TRUE > > Reviewed-by: Laszlo Ersek ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 10/16] ArmPlatformPkg/PrePi: base GCD memory space size on CPU's PA range
On 11/28/18 15:33, Ard Biesheuvel wrote:
> Derive the size of the GCD memory space map directly from the CPU's
> information registers rather than from the PcdPrePiCpuMemorySize PCD,
> which will be removed.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> ArmPlatformPkg/PrePi/PeiMPCore.inf | 1 -
> ArmPlatformPkg/PrePi/PeiUniCore.inf | 1 -
> ArmPlatformPkg/PrePi/PrePi.c| 2 +-
> 3 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/ArmPlatformPkg/PrePi/PeiMPCore.inf
> b/ArmPlatformPkg/PrePi/PeiMPCore.inf
> index 242b03175536..7e2ad6fc483d 100644
> --- a/ArmPlatformPkg/PrePi/PeiMPCore.inf
> +++ b/ArmPlatformPkg/PrePi/PeiMPCore.inf
> @@ -97,7 +97,6 @@ [FixedPcd]
>
>gArmPlatformTokenSpaceGuid.PcdCoreCount
>
> - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize
>gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize
>
>gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory
> diff --git a/ArmPlatformPkg/PrePi/PeiUniCore.inf
> b/ArmPlatformPkg/PrePi/PeiUniCore.inf
> index a45cdef4ed91..26328b7e8f67 100644
> --- a/ArmPlatformPkg/PrePi/PeiUniCore.inf
> +++ b/ArmPlatformPkg/PrePi/PeiUniCore.inf
> @@ -90,7 +90,6 @@ [FixedPcd]
>
>gArmPlatformTokenSpaceGuid.PcdCoreCount
>
> - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize
>gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize
>
>gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory
> diff --git a/ArmPlatformPkg/PrePi/PrePi.c b/ArmPlatformPkg/PrePi/PrePi.c
> index 02cff7ddc204..245bdded1eb3 100644
> --- a/ArmPlatformPkg/PrePi/PrePi.c
> +++ b/ArmPlatformPkg/PrePi/PrePi.c
> @@ -115,7 +115,7 @@ PrePiMain (
>BuildStackHob (StacksBase, StacksSize);
>
>//TODO: Call CpuPei as a library
> - BuildCpuHob (PcdGet8 (PcdPrePiCpuMemorySize), PcdGet8 (PcdPrePiCpuIoSize));
> + BuildCpuHob (ArmGetPhysicalAddressBits (), PcdGet8 (PcdPrePiCpuIoSize));
>
>if (ArmIsMpCore ()) {
> // Only MP Core platform need to produce gArmMpCoreInfoPpiGuid
>
Acked-by: Laszlo Ersek
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 12/16] BeagleBoardPkg/PrePi: base GCD memory space size on CPU's PA range
On 11/28/18 15:33, Ard Biesheuvel wrote: > Derive the size of the GCD memory space map directly from the CPU's > information registers rather than from the PcdPrePiCpuMemorySize PCD, > which will be removed. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > BeagleBoardPkg/PrePi/PeiUniCore.inf | 1 - > BeagleBoardPkg/PrePi/PrePi.c| 2 +- > 2 files changed, 1 insertion(+), 2 deletions(-) > > diff --git a/BeagleBoardPkg/PrePi/PeiUniCore.inf > b/BeagleBoardPkg/PrePi/PeiUniCore.inf > index 3d72bc5b46e1..53c71d8eafc2 100644 > --- a/BeagleBoardPkg/PrePi/PeiUniCore.inf > +++ b/BeagleBoardPkg/PrePi/PeiUniCore.inf > @@ -86,7 +86,6 @@ [FixedPcd] > >gArmPlatformTokenSpaceGuid.PcdCoreCount > > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize >gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize > >gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory > diff --git a/BeagleBoardPkg/PrePi/PrePi.c b/BeagleBoardPkg/PrePi/PrePi.c > index 46f63f40c46e..bc9b0c80b84c 100644 > --- a/BeagleBoardPkg/PrePi/PrePi.c > +++ b/BeagleBoardPkg/PrePi/PrePi.c > @@ -110,7 +110,7 @@ PrePiMain ( >BuildStackHob (StacksBase, StacksSize); > >//TODO: Call CpuPei as a library > - BuildCpuHob (PcdGet8 (PcdPrePiCpuMemorySize), PcdGet8 (PcdPrePiCpuIoSize)); > + BuildCpuHob (ArmGetPhysicalAddressBits (), PcdGet8 (PcdPrePiCpuIoSize)); > >// Store timer value logged at the beginning of firmware image execution >Performance.ResetEnd = GetTimeInNanoSecond (StartTimeStamp); > Acked-by: Laszlo Ersek ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 11/16] ArmVirtPkg/PrePi: base GCD memory space size on CPU's PA range
On 11/28/18 15:33, Ard Biesheuvel wrote: > Derive the size of the GCD memory space map directly from the CPU's > information registers rather than from the PcdPrePiCpuMemorySize PCD, > which will be removed. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf | 1 - > ArmVirtPkg/PrePi/PrePi.c| 2 +- > 2 files changed, 1 insertion(+), 2 deletions(-) > > diff --git a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf > b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf > index 1587bd92f206..034ddb41cb48 100755 > --- a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf > +++ b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf > @@ -85,7 +85,6 @@ [FixedPcd] > >gArmPlatformTokenSpaceGuid.PcdCoreCount > > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize >gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize > >gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory > diff --git a/ArmVirtPkg/PrePi/PrePi.c b/ArmVirtPkg/PrePi/PrePi.c > index f6abe2f2016b..61de6cfd4ae6 100755 > --- a/ArmVirtPkg/PrePi/PrePi.c > +++ b/ArmVirtPkg/PrePi/PrePi.c > @@ -80,7 +80,7 @@ PrePiMain ( >BuildStackHob (StacksBase, StacksSize); > >//TODO: Call CpuPei as a library > - BuildCpuHob (PcdGet8 (PcdPrePiCpuMemorySize), PcdGet8 (PcdPrePiCpuIoSize)); > + BuildCpuHob (ArmGetPhysicalAddressBits (), PcdGet8 (PcdPrePiCpuIoSize)); > >// Set the Boot Mode >SetBootMode (BOOT_WITH_FULL_CONFIGURATION); > Acked-by: Laszlo Ersek ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [edk2-platforms] [PATCH v5 2/2] Platform/ARM: Add Readme.md
This Readme.md file covers building an aarch64 edk2 image and the instructions on how to obtain and run the ARM Base FVP software model in order to get an aarch64 build/debug environment. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Nariman Poushin --- Changes v1->v2 - Added Contributed-under tag Changes v2->v3 (subject line omitted in previous mail): - Updated the "Download the Sources" section to have the correct path Changes v3->v4 - Removed references to fetching source - Updated location of FVP - Removed instructions on configuring and building Linux - Entirely re-wrote section on running on the (now) Base FVP Changes v4->v5 - Fixed up link to Linaro ARM Landing Team prebuilt tools repo - Fixed up subject line Basically, it's a (much needed) re-write, to reflect Leif's comments, which were very sensible. I have not included running Linux at all, as I figure we can add that later (if needed). For now, there instructions should yield a working development environment for aarch64 running edk2 tianocore (edk2/edk2-platforms? not sure which one is correct ... or if both are). Thanks Nariman ps. Apologies for the slew of patch sets, will have more coffee next time Platform/ARM/Readme.md | 62 ++ Readme.md | 4 +--- 2 files changed, 63 insertions(+), 3 deletions(-) create mode 100644 Platform/ARM/Readme.md diff --git a/Platform/ARM/Readme.md b/Platform/ARM/Readme.md new file mode 100644 index 000..a4c840f --- /dev/null +++ b/Platform/ARM/Readme.md @@ -0,0 +1,62 @@ +== Introduction == + +These instructions explain how to get an edk2/edk2-platforms build running +on the ARM Base FVP, which is a software model provided by ARM (for free) +, which models a Cortex A core with various peripherals. More information +can be found here: +https://developer.arm.com/products/system-design/fixed-virtual-platforms + +Requirement: +* A 32-bit or 64-bit Linux host machine. +* Visual Studio is not officially supported, experimental support can be found here: +[https://git.linaro.org/people/leif.lindholm/edk2.git/log/?h=aarch64-vs] + +== Build EDK2 Tianocore == + +cd $(WORKSPACE)/edk2For the Foundation and Base FVPs (defined by the DSC file Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc): +build -a AARCH64 -p Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc -t GCC5 + +Once built, the edk2 image is the following file Build/ArmVExpress-FVP-AArch64/DEBUG_GCC5/FV/FVP_AARCH64_EFI.fd + +=== Run edk2/edk2-platforms on the ARM Base Platform FVP === + +In order to run the binary we have just built there are a few steps we need to +go through, we need to get a model, a set of prebuilts (where we will swap out +the edk2 image with our own) and the tool with which we will swap out the +prebuilt edk2 image. + +We will also rely on the "run_model" script that comes with the prebuilts, it +is entirely possible to run the model without this but would require quite a bit +of knowledge regarding the areguments ARM fastmodel (documentation can be found here: +https://developer.arm.com/docs/100966/1101/programming-reference-for-base-fvps/base-platform-revc-features) +however the manual set of the FVP is outside the scope of this document. If you are interested +please consult the documentation. + +It's recommended you create a folder where you download the prebuilts and +required tool and copy your edk2 image in to it, as the run script expects +the binaries in the same directory. + +1) Download the Base FVP from here https://developer.arm.com/products/system-design/fixed-virtual-platforms + + - Select Armv8-A Base Platform FVP based on Fast Models 11.4 + - It has a click through license but is free. + +2) Download the 18.10 Linaro ARM Landing Team release for FVP booting UEFI +https://releases.linaro.org/members/arm/platforms/18.10/fvp-uefi.zip + +3) Download the prebuilt fiptool from https://git.linaro.org/landing-teams/working/arm/prebuilt/tools + +4) Update the fip.bin image from fvp-uefi.zip by running the following command: + + fiptool update --nt-fw=[path to binary built above] fip.bin + +5) Execute the FVP run_model.sh script from fvp-uefi.zip and provide a path to the FVP binaries +downloaded in step 1): + + MODEL=[path to FVP binary] ./run_model.sh + +This expects the contents of fvp-uefi.zip, the bl1.bin and fip.bin (which is +the file we modify), to be in the same directory as the run_model.sh script. + +This should be sufficient to provide a build/run/debug environment for aarch64. + diff --git a/Readme.md b/Readme.md index 6ad5953..6748826 100644 --- a/Readme.md +++ b/Readme.md @@ -206,9 +206,7 @@ they will be documented with the platform. * [Overdrive](Platform/AMD/OverdriveBoard) * [Overdrive 1000](Platform/SoftIron/Overdrive1000Board) -## ARM -* [Juno](Platform/ARM/JunoPkg) -* [Versatile
Re: [edk2] [PATCH v3 09/16] ArmPkg/CpuPei: base GCD memory space size on CPU's PA range
On 11/28/18 15:33, Ard Biesheuvel wrote: > Derive the size of the GCD memory space map directly from the CPU's > information registers rather than from the PcdPrePiCpuMemorySize PCD, > which will be removed. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > ArmPkg/Drivers/CpuPei/CpuPei.inf | 1 - > ArmPkg/Drivers/CpuPei/CpuPei.c | 2 +- > 2 files changed, 1 insertion(+), 2 deletions(-) > > diff --git a/ArmPkg/Drivers/CpuPei/CpuPei.inf > b/ArmPkg/Drivers/CpuPei/CpuPei.inf > index eafccd600983..dcea012fd8f9 100644 > --- a/ArmPkg/Drivers/CpuPei/CpuPei.inf > +++ b/ArmPkg/Drivers/CpuPei/CpuPei.inf > @@ -50,7 +50,6 @@ [Guids] >gArmMpCoreInfoGuid > > [FixedPcd] > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize >gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize > > [Depex] > diff --git a/ArmPkg/Drivers/CpuPei/CpuPei.c b/ArmPkg/Drivers/CpuPei/CpuPei.c > index d54f42acfcc8..e63519ff6481 100644 > --- a/ArmPkg/Drivers/CpuPei/CpuPei.c > +++ b/ArmPkg/Drivers/CpuPei/CpuPei.c > @@ -73,7 +73,7 @@ InitializeCpuPeim ( >ArmEnableBranchPrediction (); > >// Publish the CPU memory and io spaces sizes > - BuildCpuHob (PcdGet8 (PcdPrePiCpuMemorySize), PcdGet8 (PcdPrePiCpuIoSize)); > + BuildCpuHob (ArmGetPhysicalAddressBits (), PcdGet8 (PcdPrePiCpuIoSize)); > >// Only MP Core platform need to produce gArmMpCoreInfoPpiGuid >Status = PeiServicesLocatePpi (, 0, NULL, > (VOID**)); > Reviewed-by: Laszlo Ersek ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [edk2-platforms] [PATCH v4 2/2] Platform/ARM: Add Readme.md
This covers the bulk of the information originally present in https://github.com/tianocore/tianocore.github.io/wiki/ArmPlatformPkg-AArch64 regarding building and running the Foundation/Base FVP Platforms. The sections on fetching source have been delegated to the root Readme.md Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Nariman Poushin --- Changes since v3 (subject line omitted in previous mail): - Fixed up link to Linaro ARM Landing Team prebuilt tools repo - Fixed up subject line Platform/ARM/Readme.md | 62 ++ Readme.md | 4 +--- 2 files changed, 63 insertions(+), 3 deletions(-) create mode 100644 Platform/ARM/Readme.md diff --git a/Platform/ARM/Readme.md b/Platform/ARM/Readme.md new file mode 100644 index 000..a4c840f --- /dev/null +++ b/Platform/ARM/Readme.md @@ -0,0 +1,62 @@ +== Introduction == + +These instructions explain how to get an edk2/edk2-platforms build running +on the ARM Base FVP, which is a software model provided by ARM (for free) +, which models a Cortex A core with various peripherals. More information +can be found here: +https://developer.arm.com/products/system-design/fixed-virtual-platforms + +Requirement: +* A 32-bit or 64-bit Linux host machine. +* Visual Studio is not officially supported, experimental support can be found here: +[https://git.linaro.org/people/leif.lindholm/edk2.git/log/?h=aarch64-vs] + +== Build EDK2 Tianocore == + +cd $(WORKSPACE)/edk2For the Foundation and Base FVPs (defined by the DSC file Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc): +build -a AARCH64 -p Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc -t GCC5 + +Once built, the edk2 image is the following file Build/ArmVExpress-FVP-AArch64/DEBUG_GCC5/FV/FVP_AARCH64_EFI.fd + +=== Run edk2/edk2-platforms on the ARM Base Platform FVP === + +In order to run the binary we have just built there are a few steps we need to +go through, we need to get a model, a set of prebuilts (where we will swap out +the edk2 image with our own) and the tool with which we will swap out the +prebuilt edk2 image. + +We will also rely on the "run_model" script that comes with the prebuilts, it +is entirely possible to run the model without this but would require quite a bit +of knowledge regarding the areguments ARM fastmodel (documentation can be found here: +https://developer.arm.com/docs/100966/1101/programming-reference-for-base-fvps/base-platform-revc-features) +however the manual set of the FVP is outside the scope of this document. If you are interested +please consult the documentation. + +It's recommended you create a folder where you download the prebuilts and +required tool and copy your edk2 image in to it, as the run script expects +the binaries in the same directory. + +1) Download the Base FVP from here https://developer.arm.com/products/system-design/fixed-virtual-platforms + + - Select Armv8-A Base Platform FVP based on Fast Models 11.4 + - It has a click through license but is free. + +2) Download the 18.10 Linaro ARM Landing Team release for FVP booting UEFI +https://releases.linaro.org/members/arm/platforms/18.10/fvp-uefi.zip + +3) Download the prebuilt fiptool from https://git.linaro.org/landing-teams/working/arm/prebuilt/tools + +4) Update the fip.bin image from fvp-uefi.zip by running the following command: + + fiptool update --nt-fw=[path to binary built above] fip.bin + +5) Execute the FVP run_model.sh script from fvp-uefi.zip and provide a path to the FVP binaries +downloaded in step 1): + + MODEL=[path to FVP binary] ./run_model.sh + +This expects the contents of fvp-uefi.zip, the bl1.bin and fip.bin (which is +the file we modify), to be in the same directory as the run_model.sh script. + +This should be sufficient to provide a build/run/debug environment for aarch64. + diff --git a/Readme.md b/Readme.md index 6ad5953..6748826 100644 --- a/Readme.md +++ b/Readme.md @@ -206,9 +206,7 @@ they will be documented with the platform. * [Overdrive](Platform/AMD/OverdriveBoard) * [Overdrive 1000](Platform/SoftIron/Overdrive1000Board) -## ARM -* [Juno](Platform/ARM/JunoPkg) -* [Versatile Express](Platform/ARM/VExpressPkg) +## [ARM](Platform/ARM/Readme.md) ## Hisilicon * [D02](Platform/Hisilicon/D02) -- 2.7.4 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Pkcs7 crypto verification without openSSL
Tom, Let me know if you get any useful offline answers. From our experience, there are some licensed 3rd party solutions that are tiny but aren’t cheap. The problem is parts of any encryption runs the risk of triggering government laws about encryption. So the owners of Tianocore made the decision to pull in OpenSSL as a whole to put the problem onto the user of TC. Making smaller versions of OpenSSL means you have a lot of work to incorporate newer versions. Kevin From: edk2-devel on behalf of Tomas Pilar (tpilar) Sent: Wednesday, November 28, 2018 11:40 AM To: edk2-devel@lists.01.org Subject: [edk2] Pkcs7 crypto verification without openSSL Hi, Are there any plans for a crypto library that does not pull in openSSL? When I try to add BaseCryptLib to be able to use FmpAuthenticationLib, my driver size baloons significantly (increase of ~0x3) and it seems like a basic public SHA256 crypto check library should not be _that_ large? 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] [PATCH] Platform/ARM: Add Readme.md
This covers the bulk of the information originally present in https://github.com/tianocore/tianocore.github.io/wiki/ArmPlatformPkg-AArch64 regarding building and running the Foundation/Base FVP Platforms. The sections on fetching source have been delegated to the root Readme.md Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Nariman Poushin --- Changes from v2: - Removed references to fetching source - Updated location of FVP - Removed instructions on configuring and building Linux - Entirely re-wrote section on running on the (now) Base FVP Basically, it's a (much needed) re-write, to reflect Leif's comments, which were very sensible. I have not included running Linux at all, as I figure we can add that later (if needed). For now, there instructions should yield a working development environment for aarch64 running edk2 tianocore (edk2/edk2-platforms? not sure which one is correct ... or if they both are). Thanks Nariman Platform/ARM/Readme.md | 62 ++ Readme.md | 4 +--- 2 files changed, 63 insertions(+), 3 deletions(-) create mode 100644 Platform/ARM/Readme.md diff --git a/Platform/ARM/Readme.md b/Platform/ARM/Readme.md new file mode 100644 index 000..a4c840f --- /dev/null +++ b/Platform/ARM/Readme.md @@ -0,0 +1,62 @@ +== Introduction == + +These instructions explain how to get an edk2/edk2-platforms build running +on the ARM Base FVP, which is a software model provided by ARM (for free) +, which models a Cortex A core with various peripherals. More information +can be found here: +https://developer.arm.com/products/system-design/fixed-virtual-platforms + +Requirement: +* A 32-bit or 64-bit Linux host machine. +* Visual Studio is not officially supported, experimental support can be found here: +[https://git.linaro.org/people/leif.lindholm/edk2.git/log/?h=aarch64-vs] + +== Build EDK2 Tianocore == + +cd $(WORKSPACE)/edk2For the Foundation and Base FVPs (defined by the DSC file Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc): +build -a AARCH64 -p Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc -t GCC5 + +Once built, the edk2 image is the following file Build/ArmVExpress-FVP-AArch64/DEBUG_GCC5/FV/FVP_AARCH64_EFI.fd + +=== Run edk2/edk2-platforms on the ARM Base Platform FVP === + +In order to run the binary we have just built there are a few steps we need to +go through, we need to get a model, a set of prebuilts (where we will swap out +the edk2 image with our own) and the tool with which we will swap out the +prebuilt edk2 image. + +We will also rely on the "run_model" script that comes with the prebuilts, it +is entirely possible to run the model without this but would require quite a bit +of knowledge regarding the areguments ARM fastmodel (documentation can be found here: +https://developer.arm.com/docs/100966/1101/programming-reference-for-base-fvps/base-platform-revc-features) +however the manual set of the FVP is outside the scope of this document. If you are interested +please consult the documentation. + +It's recommended you create a folder where you download the prebuilts and +required tool and copy your edk2 image in to it, as the run script expects +the binaries in the same directory. + +1) Download the Base FVP from here https://developer.arm.com/products/system-design/fixed-virtual-platforms + + - Select Armv8-A Base Platform FVP based on Fast Models 11.4 + - It has a click through license but is free. + +2) Download the 18.10 Linaro ARM Landing Team release for FVP booting UEFI +https://releases.linaro.org/members/arm/platforms/18.10/fvp-uefi.zip + +3) Download the prebuilt fiptool from https://git.linaro.org/landing-teams/working/arm/prebuilt/tools + +4) Update the fip.bin image from fvp-uefi.zip by running the following command: + + fiptool update --nt-fw=[path to binary built above] fip.bin + +5) Execute the FVP run_model.sh script from fvp-uefi.zip and provide a path to the FVP binaries +downloaded in step 1): + + MODEL=[path to FVP binary] ./run_model.sh + +This expects the contents of fvp-uefi.zip, the bl1.bin and fip.bin (which is +the file we modify), to be in the same directory as the run_model.sh script. + +This should be sufficient to provide a build/run/debug environment for aarch64. + diff --git a/Readme.md b/Readme.md index 6ad5953..6748826 100644 --- a/Readme.md +++ b/Readme.md @@ -206,9 +206,7 @@ they will be documented with the platform. * [Overdrive](Platform/AMD/OverdriveBoard) * [Overdrive 1000](Platform/SoftIron/Overdrive1000Board) -## ARM -* [Juno](Platform/ARM/JunoPkg) -* [Versatile Express](Platform/ARM/VExpressPkg) +## [ARM](Platform/ARM/Readme.md) ## Hisilicon * [D02](Platform/Hisilicon/D02) -- 2.7.4 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] Platform/ARM: Add Readme.md
This covers the bulk of the information originally present in https://github.com/tianocore/tianocore.github.io/wiki/ArmPlatformPkg-AArch64 regarding building and running the Foundation/Base FVP Platforms. The sections on fetching source have been delegated to the root Readme.md Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Nariman Poushin --- Changes from v2: - Removed references to fetching source - Updated location of FVP - Removed instructions on configuring and building Linux - Entirely re-wrote section on running on the (now) Base FVP Basically, it's a (much needed) re-write, to reflect Leif's comments, which were very sensible. I have not included running Linux at all, as I figure we can add that later (if needed). For now, there instructions should yield a working development environment for aarch64 running edk2 tianocore (edk2/edk2-platforms? not sure which one is correct ... or if they both are). Thanks Nariman Platform/ARM/Readme.md | 62 ++ Readme.md | 4 +--- 2 files changed, 63 insertions(+), 3 deletions(-) create mode 100644 Platform/ARM/Readme.md diff --git a/Platform/ARM/Readme.md b/Platform/ARM/Readme.md new file mode 100644 index 000..a4c840f --- /dev/null +++ b/Platform/ARM/Readme.md @@ -0,0 +1,62 @@ +== Introduction == + +These instructions explain how to get an edk2/edk2-platforms build running +on the ARM Base FVP, which is a software model provided by ARM (for free) +, which models a Cortex A core with various peripherals. More information +can be found here: +https://developer.arm.com/products/system-design/fixed-virtual-platforms + +Requirement: +* A 32-bit or 64-bit Linux host machine. +* Visual Studio is not officially supported, experimental support can be found here: +[https://git.linaro.org/people/leif.lindholm/edk2.git/log/?h=aarch64-vs] + +== Build EDK2 Tianocore == + +cd $(WORKSPACE)/edk2For the Foundation and Base FVPs (defined by the DSC file Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc): +build -a AARCH64 -p Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc -t GCC5 + +Once built, the edk2 image is the following file Build/ArmVExpress-FVP-AArch64/DEBUG_GCC5/FV/FVP_AARCH64_EFI.fd + +=== Run edk2/edk2-platforms on the ARM Base Platform FVP === + +In order to run the binary we have just built there are a few steps we need to +go through, we need to get a model, a set of prebuilts (where we will swap out +the edk2 image with our own) and the tool with which we will swap out the +prebuilt edk2 image. + +We will also rely on the "run_model" script that comes with the prebuilts, it +is entirely possible to run the model without this but would require quite a bit +of knowledge regarding the areguments ARM fastmodel (documentation can be found here: +https://developer.arm.com/docs/100966/1101/programming-reference-for-base-fvps/base-platform-revc-features) +however the manual set of the FVP is outside the scope of this document. If you are interested +please consult the documentation. + +It's recommended you create a folder where you download the prebuilts and +required tool and copy your edk2 image in to it, as the run script expects +the binaries in the same directory. + +1) Download the Base FVP from here https://developer.arm.com/products/system-design/fixed-virtual-platforms + + - Select Armv8-A Base Platform FVP based on Fast Models 11.4 + - It has a click through license but is free. + +2) Download the 18.10 Linaro ARM Landing Team release for FVP booting UEFI +https://releases.linaro.org/members/arm/platforms/18.10/fvp-uefi.zip + +3) Download the prebuilt fiptool from https://git.linaro.org/landing-teams/working/arm/prebuilt/tools + +4) Update the fip.bin image from fvp-uefi.zip by running the following command: + + fiptool update --nt-fw=[path to binary built above] fip.bin + +5) Execute the FVP run_model.sh script from fvp-uefi.zip and provide a path to the FVP binaries +downloaded in step 1): + + MODEL=[path to FVP binary] ./run_model.sh + +This expects the contents of fvp-uefi.zip, the bl1.bin and fip.bin (which is +the file we modify), to be in the same directory as the run_model.sh script. + +This should be sufficient to provide a build/run/debug environment for aarch64. + diff --git a/Readme.md b/Readme.md index 6ad5953..6748826 100644 --- a/Readme.md +++ b/Readme.md @@ -206,9 +206,7 @@ they will be documented with the platform. * [Overdrive](Platform/AMD/OverdriveBoard) * [Overdrive 1000](Platform/SoftIron/Overdrive1000Board) -## ARM -* [Juno](Platform/ARM/JunoPkg) -* [Versatile Express](Platform/ARM/VExpressPkg) +## [ARM](Platform/ARM/Readme.md) ## Hisilicon * [D02](Platform/Hisilicon/D02) -- 2.7.4 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 08/16] ArmPkg/ArmMmuLib: take the CPU supported maximum PA space into account
On 11/28/18 15:33, Ard Biesheuvel wrote: > In preparation of dropping PcdPrePiCpuMemorySize entirely, base the > maximum size of the identity map on the capabilities of the CPU. > Since that may exceed what is architecturally permitted when using > 4 KB pages, take MAX_ADDRESS into account as well. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf | 3 --- > ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf| 3 --- > ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c | 11 +-- > 3 files changed, 9 insertions(+), 8 deletions(-) > > diff --git a/ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf > b/ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf > index b9f264de8d26..246963361e45 100644 > --- a/ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf > +++ b/ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf > @@ -40,8 +40,5 @@ [LibraryClasses] >CacheMaintenanceLib >MemoryAllocationLib > > -[Pcd.AARCH64] > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize > - > [Pcd.ARM] >gArmTokenSpaceGuid.PcdNormalMemoryNonshareableOverride > diff --git a/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf > b/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf > index ecf13f790734..f689c193b862 100644 > --- a/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf > +++ b/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf > @@ -35,6 +35,3 @@ [LibraryClasses] >ArmLib >CacheMaintenanceLib >MemoryAllocationLib > - > -[Pcd.AARCH64] > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize OK > diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c > b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c > index 4b62ecb6a476..5403b8d4070e 100644 > --- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c > +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c > @@ -604,8 +604,15 @@ ArmConfigureMmu ( > return EFI_INVALID_PARAMETER; >} > > - // Cover the entire GCD memory space > - MaxAddress = (1UL << PcdGet8 (PcdPrePiCpuMemorySize)) - 1; > + // > + // Limit the virtual address space to what we can actually use: UEFI > + // mandates a 1:1 mapping, so no point in making the virtual address > + // space larger than the physical address space. We also have to take > + // into account the architectural limitations that result from UEFI's > + // use of 4 KB pages. > + // > + MaxAddress = MIN (LShiftU64 (1ULL, ArmGetPhysicalAddressBits ()) - 1, > +MAX_ADDRESS); > >// Lookup the Table Level to get the information >LookupAddresstoRootTable (MaxAddress, , ); > This part of edk2 (or ArmVirtQemu) is where I *always* get lost. So let me check the call tree. ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.inf [ArmVirtPkg/ArmVirtQemu.dsc] InitializeMemory() [ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c] PeiServicesInstallPeiMemory() [...] // now we've got permanent PEI RAM MemoryPeim() [ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c] InitMmu() [ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c] ArmVirtGetMemoryMap() [ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c] ArmConfigureMmu() [ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c] In patch v3 04/16, we modify ArmVirtGetMemoryMap() so that the mapping not cover the "Peripheral space after DRAM" (which is practically "limitless"). Good. In this patch, we have to modify ArmConfigureMmu() as well, because the descriptor array that we pass it from ArmVirtGetMemoryMap() does not contain all the information that is necessary for setting up "paging" in general. Also considering mappings that could be added later during DXE, such as MMIO ranges of platform drivers / devices, discontiguous RAM ranges, and so on. So we need a "maximum" here. The maximum that we choose doesn't "seriously" translate to an increased memory footprint of paging artifacts, *unlike* the size of the address space that we actually map for access. Hence in patch v3 04/16, we are conservative, but in this patch, when selecting the maximum, we go as high as we can -- either the architecturally permitted limit (with 4KB page size), or, if the latter is lower, the limit supported by the current CPU. The GCD *could* go higher (even though we'd never attempt to map that in UEFI), assuming the CPU is capable enough (using 64KB pages at OS runtime). This bends my brain. :) I'm now slowly comprehending your blurb. Indeed, the rest of the series pertains to the GCD memory space map. Nit: the second argument of the MIN() macro is not indented idiomatically. With that fixed (no need to repost the series just because of it): Reviewed-by: Laszlo Ersek Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org
Re: [edk2] [edk2-announce] Research Request
On Wednesday, 28 November 2018 11:19:33 MST Jeremiah Cox wrote: > There is a question of how the below is automated such that when there is a > security advisory, a Phabricator instance is patched in a timely fashion. > Perhaps there is a mailing list that would announce these and that could > trigger an auto-update script. I'm not sure most people would like installations to be automatically updated without at least reviewing what such a script was going to do. I agree someone would need to monitor for security advisories though, and schedule maintenance windows to update it. -- Rebecca ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [RFC PATCH 0/2] ArmVirtQemu: unmap page #0 to catch NULL pointer dereferences
Rationale in patch #2. Patch #1 is a prerequisite patch that ensures that we no longer need page #0 to be mapped for the NOR flash driver to be able to expose it as a read/write block device. Cc: Laszlo Ersek Cc: Eric Auger Cc: Andrew Jones Cc: Philippe Mathieu-Daude Ard Biesheuvel (2): ArmVirtPkg/NorFlashQemuLib: disregard our primary FV ArmVirtPkg/QemuVirtMemInfoLib: trim the MMIO region mapping .../NorFlashQemuLib/NorFlashQemuLib.inf| 5 + .../QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf | 4 ++-- .../QemuVirtMemInfoPeiLib.inf | 2 ++ .../Library/NorFlashQemuLib/NorFlashQemuLib.c | 13 +++-- .../QemuVirtMemInfoLib/QemuVirtMemInfoLib.c| 18 +++--- 5 files changed, 31 insertions(+), 11 deletions(-) -- 2.19.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [RFC PATCH 1/2] ArmVirtPkg/NorFlashQemuLib: disregard our primary FV
The primary FV contains the firmware boot image, which is not
runtime updatable in our case. So exposing it to the NOR flash
driver is undesirable, since it may attempt to modify the NOR
flash contents. It is also rather pointless, since we don't
keep anything there that we don't already expose via the FVB
protocol instances that DXE core creates for us based on the
FV HOBs (and so there is nothing the partition or file system
drivers could potentially attach to via the block I/O and disk
I/O protocol instances that the NOR flash driver creates)
So let's disregard the NOR flash block that covers the primary
FV.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf | 5 +
ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c | 13 +++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
index d86ff36dbd58..c5752a243e6b 100644
--- a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
+++ b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
@@ -28,6 +28,7 @@ [Sources.common]
[Packages]
MdePkg/MdePkg.dec
ArmPlatformPkg/ArmPlatformPkg.dec
+ ArmPkg/ArmPkg.dec
ArmVirtPkg/ArmVirtPkg.dec
[LibraryClasses]
@@ -40,3 +41,7 @@ [Protocols]
[Depex]
gFdtClientProtocolGuid
+
+[Pcd]
+ gArmTokenSpaceGuid.PcdFvBaseAddress
+ gArmTokenSpaceGuid.PcdFvSize
diff --git a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
index 2678f57eaaad..72b47bdb5a78 100644
--- a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
+++ b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
@@ -75,13 +75,22 @@ NorFlashPlatformGetDevices (
Size = SwapBytes64 (ReadUnaligned64 ((VOID *)[2]));
Reg += 4;
+ PropSize -= 4 * sizeof (UINT32);
+
+ //
+ // Disregard any flash devices that overlap with the primary FV.
+ // The firmware is not updatable from inside the guest anyway.
+ //
+ if ((PcdGet64 (PcdFvBaseAddress) + PcdGet32 (PcdFvSize) >= Base) &&
+ (Base + Size) >= PcdGet64 (PcdFvBaseAddress)) {
+continue;
+ }
+
mNorFlashDevices[Num].DeviceBaseAddress = (UINTN)Base;
mNorFlashDevices[Num].RegionBaseAddress = (UINTN)Base;
mNorFlashDevices[Num].Size = (UINTN)Size;
mNorFlashDevices[Num].BlockSize = QEMU_NOR_BLOCK_SIZE;
Num++;
-
- PropSize -= 4 * sizeof (UINT32);
}
}
--
2.19.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [RFC PATCH 2/2] ArmVirtPkg/QemuVirtMemInfoLib: trim the MMIO region mapping
QEMU/mach-virt is rather unhelpful when it comes to tracking down NULL pointer dereferences that occur while running in UEFI: since we have NOR flash mapped at address 0x0, inadvertent reads go unnoticed, and even most writes are silently dropped, unless you're unlucky and the instruction in question is one that KVM cannot emulate, in which case you end up with a QEMU crash like this: error: kvm run failed Function not implemented PC=00013f7ff804 X00=00013f7ab108 X01=0064 X02=00013f801988 X03=83c4 X04= X05=9644 X06=fffd8270 X07=00013f7ab4a0 X08=0001 X09=00013f803b88 X10=00013f7e88d0 X11=0009 X12=00013f7ab554 X13=0008 X14=0002 X15= X16= X17= X18= X19= X20=00013f81c000 X21=00013f7ab170 X22=00013f81c000 X23=0918 X24=00013f407020 X25=00013f81c000 X26=00013f803530 X27=00013f802000 X28=00013f7ab270 X29=00013f7ab0d0 X30=00013f7fee10 SP=00013f7a6f30 PSTATE=83c5 N--- EL1h and a warning in the host kernel log that load/store instruction decoding is not supported by KVM. Given that the first page of the flash device is not actually used anyway, let's reduce the mappings of the peripheral space and the flash device (both of which cover page #0) to only cover what is actually required. After this change, any inadvertent read or write from/to the first physical page will trigger a translation fault inside the guest, regardless of the nature of the instruction, without crashing QEMU. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf| 4 ++-- ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf | 2 ++ ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c | 18 +++--- 3 files changed, 15 insertions(+), 9 deletions(-) diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf index 5c5b841051ad..b6abc52531a8 100644 --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf @@ -39,9 +39,9 @@ [LibraryClasses] PcdLib [Pcd] - gArmTokenSpaceGuid.PcdFdBaseAddress + gArmTokenSpaceGuid.PcdFvBaseAddress gArmTokenSpaceGuid.PcdSystemMemoryBase gArmTokenSpaceGuid.PcdSystemMemorySize [FixedPcd] - gArmTokenSpaceGuid.PcdFdSize + gArmTokenSpaceGuid.PcdFvSize diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf index d12089760b22..16802c5c414b 100644 --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf @@ -43,9 +43,11 @@ [LibraryClasses] [Pcd] gArmTokenSpaceGuid.PcdFdBaseAddress + gArmTokenSpaceGuid.PcdFvBaseAddress gArmTokenSpaceGuid.PcdSystemMemoryBase gArmTokenSpaceGuid.PcdSystemMemorySize [FixedPcd] gArmTokenSpaceGuid.PcdFdSize + gArmTokenSpaceGuid.PcdFvSize gArmVirtTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c index 0285a11b1d77..0818d0b42d6c 100644 --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c @@ -21,6 +21,10 @@ // Number of Virtual Memory Map Descriptors #define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS 5 +// mach-virt's 'miscellaneous device I/O' region +#define MACH_VIRT_PERIPH_BASE 0x0800 +#define MACH_VIRT_PERIPH_SIZE SIZE_128MB + /** Return the Virtual Memory Map of your platform @@ -66,16 +70,16 @@ ArmVirtGetMemoryMap ( VirtualMemoryTable[0].VirtualBase, VirtualMemoryTable[0].Length)); - // Peripheral space before DRAM - VirtualMemoryTable[1].PhysicalBase = 0x0; - VirtualMemoryTable[1].VirtualBase = 0x0; - VirtualMemoryTable[1].Length = VirtualMemoryTable[0].PhysicalBase; + // Memory mapped peripherals (UART, RTC, GIC, virtio-mmio, etc) + VirtualMemoryTable[1].PhysicalBase = MACH_VIRT_PERIPH_BASE; + VirtualMemoryTable[1].VirtualBase = MACH_VIRT_PERIPH_BASE; + VirtualMemoryTable[1].Length = MACH_VIRT_PERIPH_SIZE; VirtualMemoryTable[1].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE; - // Remap the FD region as normal executable memory - VirtualMemoryTable[2].PhysicalBase = PcdGet64 (PcdFdBaseAddress); + // Map the FV region as normal executable memory + VirtualMemoryTable[2].PhysicalBase = PcdGet64 (PcdFvBaseAddress); VirtualMemoryTable[2].VirtualBase = VirtualMemoryTable[2].PhysicalBase; - VirtualMemoryTable[2].Length
Re: [edk2] [PATCH v3 07/16] ArmVirtPkg/XenVirtMemInfoLib: refactor reading of the PA space size
On 11/28/18 15:33, Ard Biesheuvel wrote:
> Use the new ArmLib helper to read the CPU's physical address limit
> so we can drop our own homecooked one.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf | 6 ---
> ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c | 11 +++---
> ArmVirtPkg/Library/XenVirtMemInfoLib/AArch64/PhysAddrTop.S | 39
>
> ArmVirtPkg/Library/XenVirtMemInfoLib/Arm/PhysAddrTop.S | 24
> 4 files changed, 5 insertions(+), 75 deletions(-)
Reviewed-by: Laszlo Ersek
Thanks
Laszlo
>
> diff --git a/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf
> b/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf
> index cd4c805a4db9..ae107810e927 100644
> --- a/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf
> +++ b/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf
> @@ -24,12 +24,6 @@ [Defines]
> [Sources]
>XenVirtMemInfoLib.c
>
> -[Sources.ARM]
> - Arm/PhysAddrTop.S
> -
> -[Sources.AARCH64]
> - AArch64/PhysAddrTop.S
> -
> [Packages]
>ArmPkg/ArmPkg.dec
>ArmVirtPkg/ArmVirtPkg.dec
> diff --git a/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c
> b/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c
> index 88ff3167cbfd..6701dec50ea8 100644
> --- a/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c
> +++ b/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c
> @@ -18,11 +18,6 @@
>
> STATIC ARM_MEMORY_REGION_DESCRIPTOR mVirtualMemoryTable[2];
>
> -EFI_PHYSICAL_ADDRESS
> -ArmGetPhysAddrTop (
> - VOID
> - );
> -
> /**
>Return the Virtual Memory Map of your platform
>
> @@ -42,8 +37,12 @@ ArmVirtGetMemoryMap (
>OUT ARM_MEMORY_REGION_DESCRIPTOR **VirtualMemoryMap
>)
> {
> + EFI_PHYSICAL_ADDRESS TopOfAddressSpace;
> +
>ASSERT (VirtualMemoryMap != NULL);
>
> + TopOfAddressSpace = LShiftU64 (1ULL, ArmGetPhysicalAddressBits ());
> +
>//
>// Map the entire physical memory space as cached. The only device
>// we care about is the GIC, which will be stage 2 mapped as a device
> @@ -51,7 +50,7 @@ ArmVirtGetMemoryMap (
>//
>mVirtualMemoryTable[0].PhysicalBase = 0x0;
>mVirtualMemoryTable[0].VirtualBase = 0x0;
> - mVirtualMemoryTable[0].Length = ArmGetPhysAddrTop ();
> + mVirtualMemoryTable[0].Length = TopOfAddressSpace;
>mVirtualMemoryTable[0].Attributes =
> ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
>
>mVirtualMemoryTable[1].PhysicalBase = 0x0;
> diff --git a/ArmVirtPkg/Library/XenVirtMemInfoLib/AArch64/PhysAddrTop.S
> b/ArmVirtPkg/Library/XenVirtMemInfoLib/AArch64/PhysAddrTop.S
> deleted file mode 100644
> index a1f6a194d59b..
> --- a/ArmVirtPkg/Library/XenVirtMemInfoLib/AArch64/PhysAddrTop.S
> +++ /dev/null
> @@ -1,39 +0,0 @@
> -#
> -# Copyright (c) 2011-2013, ARM Limited. All rights reserved.
> -# Copyright (c) 2016-2017, Linaro Limited. All rights reserved.
> -#
> -# This program and the accompanying materials
> -# are licensed and made available under the terms and conditions of the BSD
> License
> -# which accompanies this distribution. The full text of the license may be
> found at
> -# http://opensource.org/licenses/bsd-license.php
> -#
> -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> IMPLIED.
> -#
> -#
> -
> -#include
> -
> -//EFI_PHYSICAL_ADDRESS
> -//GetPhysAddrTop (
> -// VOID
> -// );
> -ASM_FUNC(ArmGetPhysAddrTop)
> - mrs x0, id_aa64mmfr0_el1
> - adr x1, .LPARanges
> - and x0, x0, #7
> - ldrb w1, [x1, x0]
> - mov x0, #1
> - lsl x0, x0, x1
> - ret
> -
> -//
> -// Bits 0..2 of the AA64MFR0_EL1 system register encode the size of the
> -// physical address space support on this CPU:
> -// 0 == 32 bits, 1 == 36 bits, etc etc
> -// 6 and 7 are reserved
> -//
> -.LPARanges:
> - .byte 32, 36, 40, 42, 44, 48, -1, -1
> -
> -ASM_FUNCTION_REMOVE_IF_UNREFERENCED
> diff --git a/ArmVirtPkg/Library/XenVirtMemInfoLib/Arm/PhysAddrTop.S
> b/ArmVirtPkg/Library/XenVirtMemInfoLib/Arm/PhysAddrTop.S
> deleted file mode 100644
> index 9cd81529fb3d..
> --- a/ArmVirtPkg/Library/XenVirtMemInfoLib/Arm/PhysAddrTop.S
> +++ /dev/null
> @@ -1,24 +0,0 @@
> -#
> -# Copyright (c) 2011-2013, ARM Limited. All rights reserved.
> -# Copyright (c) 2014-2017, Linaro Limited. All rights reserved.
> -#
> -# This program and the accompanying materials
> -# are licensed and made available under the terms and conditions of the BSD
> License
> -# which accompanies this distribution. The full text of the license may be
> found at
> -# http://opensource.org/licenses/bsd-license.php
> -#
> -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> IMPLIED.
> -#
> -#
> -
>
Re: [edk2] [PATCH v3 06/16] ArmPkg/ArmLib: add support for reading the max physical address space size
On 11/28/18 15:33, Ard Biesheuvel wrote: > Add a helper function that returns the maximum physical address space > size as supported by the current CPU. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > ArmPkg/Include/Library/ArmLib.h | 6 ++ > ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S | 17 + > ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S | 8 > ArmPkg/Library/ArmLib/Arm/ArmLibSupport.asm | 8 > 4 files changed, 39 insertions(+) > > diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h > index ffda50e9d767..9a804c15fdb6 100644 > --- a/ArmPkg/Include/Library/ArmLib.h > +++ b/ArmPkg/Include/Library/ArmLib.h > @@ -733,4 +733,10 @@ ArmWriteCntvOff ( >UINT64 Val >); > > +UINTN > +EFIAPI > +ArmGetPhysicalAddressBits ( > + VOID > + ); > + > #endif // __ARM_LIB__ > diff --git a/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > b/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > index 1ef2f61f5979..b7173e00b039 100644 > --- a/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > +++ b/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > @@ -196,4 +196,21 @@ ASM_FUNC(ArmWriteSctlr) > 3:msr sctlr_el3, x0 > 4:ret > > +ASM_FUNC(ArmGetPhysicalAddressBits) > + mrs x0, id_aa64mmfr0_el1 > + adr x1, .LPARanges > + and x0, x0, #0xf > + ldrb w0, [x1, x0] > + ret > + > +// > +// Bits 0..3 of the AA64MFR0_EL1 system register encode the size of the > +// physical address space support on this CPU: > +// 0 == 32 bits, 1 == 36 bits, etc etc > +// 7 and up are reserved > +// > +.LPARanges: > + .byte 32, 36, 40, 42, 44, 48, 52, 0 > + .byte 0, 0, 0, 0, 0, 0, 0, 0 > + > ASM_FUNCTION_REMOVE_IF_UNREFERENCED > diff --git a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > index f2a517671f0a..0e9f9d0453e4 100644 > --- a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > +++ b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > @@ -165,4 +165,12 @@ ASM_FUNC(ArmWriteCpuActlr) >isb >bx lr > > +ASM_FUNC (ArmGetPhysicalAddressBits) > + mrc p15, 0, r0, c0, c1, 4 // MMFR0 > + and r0, r0, #0xf// VMSA [3:0] > + cmp r0, #5 // >= 5 implies LPAE support > + movlt r0, #32 // 32 bits if no LPAE > + movge r0, #40 // 40 bits if LPAE > + bx lr > + > ASM_FUNCTION_REMOVE_IF_UNREFERENCED > diff --git a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.asm > b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.asm > index 219140c22b13..3eb52875971d 100644 > --- a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.asm > +++ b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.asm > @@ -169,4 +169,12 @@ >isb >bx lr > > + RVCT_ASM_EXPORT ArmGetPhysicalAddressBits > + mrc p15, 0, r0, c0, c1, 4 ; MMFR0 > + and r0, r0, #0xf; VMSA [3:0] > + cmp r0, #5 ; >= 5 implies LPAE support > + movlt r0, #32 ; 32 bits if no LPAE > + movge r0, #40 ; 40 bits if LPAE > + bx lr > + >END > I didn't review the assembly code, but formally, the patch looks OK to me. Acked-by: Laszlo Ersek ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 05/16] MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits
On 11/28/18 15:33, Ard Biesheuvel wrote: > AArch64 supports the use of more than 48 bits for physical and/or > virtual addressing, but only if the page size is set to 64 KB, > which is not supported by UEFI. So redefine MAX_ADDRESS to cover > only 48 address bits. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > Reviewed-by: Leif Lindholm > --- > MdePkg/Include/AArch64/ProcessorBind.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/MdePkg/Include/AArch64/ProcessorBind.h > b/MdePkg/Include/AArch64/ProcessorBind.h > index 968c18f915ae..dad75df1c579 100644 > --- a/MdePkg/Include/AArch64/ProcessorBind.h > +++ b/MdePkg/Include/AArch64/ProcessorBind.h > @@ -138,9 +138,9 @@ typedef INT64 INTN; > #define MAX_2_BITS 0xC000ULL > > /// > -/// Maximum legal AARCH64 address > +/// Maximum legal AARCH64 address (48 bits for 4 KB page size) > /// > -#define MAX_ADDRESS 0xULL > +#define MAX_ADDRESS 0xULL > > /// > /// Maximum legal AArch64 INTN and UINTN values. > Hmmm. I bit the bullet and grepped the tree for MAX_ADDRESS. The amount of hits is staggering. I can't audit all of them. Generally, MAX_ADDRESS seems to be used in checks that prevent address wrap-around. In that regard, this change looks valid. I can't guarantee this change won't regress anything though. In the previous posting of this patch, I asked Liming some questions (IIRC): 6f1209fb-bb89-a70f-ba0e-3ebf2e12e459@redhat.com">http://mid.mail-archive.com/6f1209fb-bb89-a70f-ba0e-3ebf2e12e459@redhat.com It would be nice to see answers. :) In addition: (a) in "BaseTools/Source/C/Include/AArch64/ProcessorBind.h", we have another instance of the macro definition. I suspect it should be kept in sync. (b) in "BaseTools/Source/C/Common/CommonLib.h", we have: #define MAX_UINTN MAX_ADDRESS which I think relies on (a), and hence it will be amusingly wrong after we synchronize (a) with MdePkg. (BTW, (b) is exactly the kind of assumption that scares me about this patch.) We're not much past the last stable tag (edk2-stable201811), so let's hope there's going to be enough time to catch any regressions. With (a) and (b) investigated / fixed up, I'd be willing to A-b this. Cautiously :) Anyway, this is for MdePkg, so my review is not required. (I certainly do not intend to *oppose* this patch.) Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-announce] Research Request
Test PR submitted
-Original Message-
From: Laszlo Ersek
Sent: Wednesday, November 28, 2018 3:07 AM
To: Brian J. Johnson ; Jeremiah Cox
; stephano
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] [edk2-announce] Research Request
On 11/27/18 22:55, Brian J. Johnson wrote:
> On 11/27/18 6:53 AM, Laszlo Ersek wrote:
>> On 11/26/18 22:43, Jeremiah Cox via edk2-devel wrote:
>>> Feedback on GitHub as follows…
>>>
>>>
1. No Lock-In - What automated data export is available?
We want to be able to leave and take all our data with us. "Data"
here
includes: review comments, pull requests / patches (including
metadata), old (rejected) pull requests and metadata, issue tracker
entries and comments (if issue tracker included). This archiving
should be automated, not something we do by hand.
>>> Untested, but might these all be easily satisfied by subscribing a
>>> mailing list to GitHub notifications?
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhel
>>> p.github.com%2Farticles%2Fabout-notifications%2F%23watching-notifica
>>> tionsdata=02%7C01%7Cjerecox%40microsoft.com%7C86474d2516054fd63
>>> 42708d65521acec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6367900
>>> 00471363695sdata=19UcXzXaxWSI9Dwvj7Nb2p1TRa78H8nxgFznkLKYeOg%3D
>>> reserved=0
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhel
>>> p.github.com%2Farticles%2Fabout-email-notifications%2Fdata=02%7
>>> C01%7Cjerecox%40microsoft.com%7C86474d2516054fd6342708d65521acec%7C7
>>> 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63679471363695sda
>>> ta=ICXNdWhlzBzVfjKk5t5aBsMC6hY8onKZS1T3WqobERk%3Dreserved=0
>> No, they are insufficient.
>>
>> Following the last link above ("about-email-notifications"), one
>> finds several other links; and one of those is:
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp
>> .github.com%2Farticles%2Fabout-notifications%2Fdata=02%7C01%7Cje
>> recox%40microsoft.com%7C86474d2516054fd6342708d65521acec%7C72f988bf86
>> f141af91ab2d7cd011db47%7C1%7C0%7C63679471363695sdata=C%2Fy1v
>> gLJC5cpL9fNQOqw1V28Omzazbu%2BeZC2m13wRLs%3Dreserved=0
>>
>> This article says,
>>
>> GitHub sends participating notifications when you're directly
>> involved in activities or conversations within a repository or a
>> team you're a member of. You'll receive a notification when:
>>
>> [...]
>>
>> - You open, comment on, or close an issue or pull request.
>>
>> [...]
>>
>> This is demonstrably false. I'm a member of the TianoCore
>> organization, I have commented on, and closed (rejected):
>>
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>> ub.com%2Ftianocore%2Fedk2%2Fpull%2F133data=02%7C01%7Cjerecox%40m
>> icrosoft.com%7C86474d2516054fd6342708d65521acec%7C72f988bf86f141af91a
>> b2d7cd011db47%7C1%7C0%7C63679471363695sdata=BT0dw8IxXGiopl3%
>> 2FHfJl7w%2BGG8VSlEb2rvIetin5T2o%3Dreserved=0
>>
>> and I *never* received an email notification about my *own* comment
>> / action. I only received the initial email, about the pull request
>> being opened (attached for reference).
>
> Try going to the "Settings" item under the menu in the top-right
> corner, and clicking on the "Notifications" tab on the left. Under
> "Email notification preferences" there should be a checkbox for
> "Include your own updates". That may do what you need.
That did the trick. I checked the box and then went on to close PR#134.
I got two separate emails shortly after (attached), one about the closure and
another about the comment.
In my opinion, the default value for the setting in question is broken (it
should be "on" by default). However, to me anyway, it's a big plus for GitHub
that it actually supports this feature. If we are going to adopt GitHub, then
we can highlight the knob in our docs.
Regarding GitHub, what remains to be seen (for me) is if & how it preserves old
(unmerged) topic branches, and review comments made for them, after the pull
requestor rebases or deletes those branches in his/her repo.
Can someone please send an artificial/test PR against my personal repo, at
?
Just change some lines in OvmfPkg/README or something like that.
Thank you!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-announce] Research Request
There is a question of how the below is automated such that when there is a security advisory, a Phabricator instance is patched in a timely fashion. Perhaps there is a mailing list that would announce these and that could trigger an auto-update script. It looks like Phabricator has publicly paid out 36 security bug bounties: https://hackerone.com/phabricator/hacktivity?sort_type=latest_disclosable_activity_at=type%3Abounty-awarded%20to%3Aphabricator_query==1 -Original Message- From: Rebecca Cran Sent: Tuesday, November 27, 2018 2:24 PM To: edk2-devel@lists.01.org; Jeremiah Cox Cc: Knop, Ryszard ; stephano Subject: Re: [edk2] [edk2-announce] Research Request On Tuesday, 27 November 2018 14:16:18 MST Jeremiah Cox via edk2-devel wrote: > Do we have data on what it takes to deploy and operate Phabricator > with Harbormaster or Jenkins? The up front development/deployment > activity/costs and then also the ongoing > patching/servicing/maintenance costs? Is Intel planning to provide this? I haven't integrated Harbormaster or Jenkins, but for just Phabricator the patching/servicing has ben really simple for the year+ I've been running it. I'd not consider it 'production' since I'm the only person using it and I'm running from Git master, not a stable branch - but maintenance has been as simple as the following (which could of course be put in a script to reduce the number of steps!): # Stop the Phabricator daemon ./bin/phd stop # Update Phabricator git pull # Update libphputil cd ../libphputil && git pull # Upgrade arcanist (commandline interface) cd ../arcanist && git pull # Upgrade database schema ./bin/storage upgrade # Start Phabricator daemon ./bin/phd start # Reload web server service nginx restart service php-fpm restart The "storage upgrade" command goes through the database looking for any inconsistencies - missing keys, wrong data types etc., and offers to fix them. -- Rebecca ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 04/16] ArmVirtPkg/QemuVirtMemInfoLib: remove 1:1 mapping of top of PA range
On 11/28/18 15:33, Ard Biesheuvel wrote:
> Currently, we map DRAM as EFI_MEMORY_WB, and the remainder of the
> entire virtual address space is mapped with EFI_MEMORY_UC attributes,
> regardless of whether any devices actually reside there.
>
> Now that we are relaxing the address space limit to more than 40 bits,
> mapping all that address space actually takes up more space in page
> tables than we have so far made available as temporary RAM. So let's
> get rid of the mapping rather than increasing the available RAM, given
> that the mapping is not particularly useful anyway.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf| 7
> ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf | 7
> ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c | 25
> +++--
> ArmVirtPkg/Library/QemuVirtMemInfoLib/AArch64/PhysAddrTop.S | 39
>
> ArmVirtPkg/Library/QemuVirtMemInfoLib/Arm/PhysAddrTop.S | 24
>
> 5 files changed, 5 insertions(+), 97 deletions(-)
Reviewed-by: Laszlo Ersek
Thanks!
Laszlo
>
> diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf
> b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf
> index c72a97f9e78a..5c5b841051ad 100644
> --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf
> +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf
> @@ -24,12 +24,6 @@ [Defines]
> [Sources]
>QemuVirtMemInfoLib.c
>
> -[Sources.ARM]
> - Arm/PhysAddrTop.S
> -
> -[Sources.AARCH64]
> - AArch64/PhysAddrTop.S
> -
> [Packages]
>ArmPkg/ArmPkg.dec
>ArmVirtPkg/ArmVirtPkg.dec
> @@ -51,4 +45,3 @@ [Pcd]
>
> [FixedPcd]
>gArmTokenSpaceGuid.PcdFdSize
> - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize
> diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
> b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
> index e4032d3efb53..d12089760b22 100644
> --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
> +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
> @@ -26,12 +26,6 @@ [Sources]
>QemuVirtMemInfoLib.c
>QemuVirtMemInfoPeiLibConstructor.c
>
> -[Sources.ARM]
> - Arm/PhysAddrTop.S
> -
> -[Sources.AARCH64]
> - AArch64/PhysAddrTop.S
> -
> [Packages]
>ArmPkg/ArmPkg.dec
>ArmVirtPkg/ArmVirtPkg.dec
> @@ -55,4 +49,3 @@ [Pcd]
> [FixedPcd]
>gArmTokenSpaceGuid.PcdFdSize
>gArmVirtTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress
> - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize
> diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> index 760bcc169cf4..0285a11b1d77 100644
> --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> @@ -21,11 +21,6 @@
> // Number of Virtual Memory Map Descriptors
> #define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS 5
>
> -EFI_PHYSICAL_ADDRESS
> -ArmGetPhysAddrTop (
> - VOID
> - );
> -
> /**
>Return the Virtual Memory Map of your platform
>
> @@ -45,7 +40,6 @@ ArmVirtGetMemoryMap (
>)
> {
>ARM_MEMORY_REGION_DESCRIPTOR *VirtualMemoryTable;
> - UINT64TopOfMemory;
>
>ASSERT (VirtualMemoryMap != NULL);
>
> @@ -78,23 +72,14 @@ ArmVirtGetMemoryMap (
>VirtualMemoryTable[1].Length = VirtualMemoryTable[0].PhysicalBase;
>VirtualMemoryTable[1].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
>
> - // Peripheral space after DRAM
> - TopOfMemory = MIN (1ULL << FixedPcdGet8 (PcdPrePiCpuMemorySize),
> - ArmGetPhysAddrTop ());
> - VirtualMemoryTable[2].PhysicalBase = VirtualMemoryTable[0].Length +
> VirtualMemoryTable[1].Length;
> - VirtualMemoryTable[2].VirtualBase = VirtualMemoryTable[2].PhysicalBase;
> - VirtualMemoryTable[2].Length = TopOfMemory -
> - VirtualMemoryTable[2].PhysicalBase;
> - VirtualMemoryTable[2].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> -
>// Remap the FD region as normal executable memory
> - VirtualMemoryTable[3].PhysicalBase = PcdGet64 (PcdFdBaseAddress);
> - VirtualMemoryTable[3].VirtualBase = VirtualMemoryTable[3].PhysicalBase;
> - VirtualMemoryTable[3].Length = FixedPcdGet32 (PcdFdSize);
> - VirtualMemoryTable[3].Attributes =
> ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
> + VirtualMemoryTable[2].PhysicalBase = PcdGet64 (PcdFdBaseAddress);
> + VirtualMemoryTable[2].VirtualBase = VirtualMemoryTable[2].PhysicalBase;
> + VirtualMemoryTable[2].Length = FixedPcdGet32 (PcdFdSize);
> + VirtualMemoryTable[2].Attributes =
> ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
>
>// End of Table
> - ZeroMem ([4], sizeof (ARM_MEMORY_REGION_DESCRIPTOR));
> + ZeroMem ([3], sizeof
Re: [edk2] [PATCH v3 03/16] ArmVirtPkg/FdtPciHostBridgeLib: map ECAM and I/O spaces in GCD memory map
On 11/28/18 15:33, Ard Biesheuvel wrote:
> Up until now, we have been getting away with not declaring the ECAM
> and translated I/O spaces at all in the GCD memory map, simply because
> we map the entire address space with device attributes in the early PEI
> code, and so the ECAM space will be mapped wherever it ends up.
>
> Now that we are about to make changes to how ArmVirtQemu reasons
> about the size of the address space, it would be better to get rid
> of this mapping of the entire address space, since it can get
> arbitrarily large without real benefit.
>
> So start by mapping the ECAM and translated I/O spaces explicitly,
> instead of relying on the early PEI mapping.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> Reviewed-by: Philippe Mathieu-Daudé
> Reviewed-by: Laszlo Ersek
> ---
> ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf | 1 +
> ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c | 46
> +++-
> 2 files changed, 46 insertions(+), 1 deletion(-)
>
> diff --git a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
> b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
> index 0995f4b7a156..4011336a353b 100644
> --- a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
> +++ b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
> @@ -42,6 +42,7 @@ [Packages]
> [LibraryClasses]
>DebugLib
>DevicePathLib
> + DxeServicesTableLib
>MemoryAllocationLib
>PciPcdProducerLib
>
> diff --git a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
> b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
> index 5b9c887db35d..ebfa14a349f4 100644
> --- a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
> +++ b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -82,6 +83,33 @@ typedef struct {
> #define DTB_PCI_HOST_RANGE_IO BIT24
> #define DTB_PCI_HOST_RANGE_TYPEMASK (BIT31 | BIT30 | BIT29 | BIT25 |
> BIT24)
>
> +STATIC
> +EFI_STATUS
> +MapGcdMmioSpace (
> + INUINT64Base,
> + INUINT64Size
> + )
> +{
> + EFI_STATUSStatus;
> +
> + Status = gDS->AddMemorySpace (EfiGcdMemoryTypeMemoryMappedIo, Base, Size,
> + EFI_MEMORY_UC);
> + if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR,
> + "%a: failed to add GCD memory space for region [0x%Lx+0x%Lx)\n",
> + __FUNCTION__, Base, Size));
> +return Status;
> + }
> +
> + Status = gDS->SetMemorySpaceAttributes (Base, Size, EFI_MEMORY_UC);
> + if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR,
> + "%a: failed to set memory space attributes for region [0x%Lx+0x%Lx)\n",
> + __FUNCTION__, Base, Size));
> + }
> + return Status;
> +}
> +
> STATIC
> EFI_STATUS
> ProcessPciHost (
> @@ -266,7 +294,23 @@ ProcessPciHost (
> "Io[0x%Lx+0x%Lx)@0x%Lx Mem32[0x%Lx+0x%Lx)@0x0 Mem64[0x%Lx+0x%Lx)@0x0\n",
> __FUNCTION__, ConfigBase, ConfigSize, *BusMin, *BusMax, *IoBase, *IoSize,
> IoTranslation, *Mmio32Base, *Mmio32Size, *Mmio64Base, *Mmio64Size));
> - return EFI_SUCCESS;
> +
> + // Map the ECAM space in the GCD memory map
> + Status = MapGcdMmioSpace (ConfigBase, ConfigSize);
> + ASSERT_EFI_ERROR (Status);
> + if (EFI_ERROR (Status)) {
> +return Status;
> + }
> +
> + //
> + // Map the MMIO window that provides I/O access - the PCI host bridge code
> + // is not aware of this translation and so it will only map the I/O view
> + // in the GCD I/O map.
> + //
> + Status = MapGcdMmioSpace (*IoBase + IoTranslation, *IoSize);
> + ASSERT_EFI_ERROR (Status);
> +
> + return Status;
> }
>
> STATIC PCI_ROOT_BRIDGE mRootBridge;
>
looks good, thanks!
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 02/16] EmbeddedPkg/PrePiHobLib: drop CreateHobList() from library
On 11/28/18 15:33, Ard Biesheuvel wrote:
> Drop the declaration and the implementation of CreateHoblist(),
> which is not used anywhere.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> EmbeddedPkg/Include/Library/PrePiLib.h | 18 -
> EmbeddedPkg/Library/PrePiHobLib/Hob.c | 41
> 2 files changed, 59 deletions(-)
>
> diff --git a/EmbeddedPkg/Include/Library/PrePiLib.h
> b/EmbeddedPkg/Include/Library/PrePiLib.h
> index cf70fca3b619..a857308ecec2 100644
> --- a/EmbeddedPkg/Include/Library/PrePiLib.h
> +++ b/EmbeddedPkg/Include/Library/PrePiLib.h
> @@ -274,24 +274,6 @@ HobConstructor (
>IN VOID *EfiFreeMemoryTop
>);
>
> -/**
> - Retrieves the magic value from the PE/COFF header.
> -
> - @param Hdr The buffer in which to return the PE32, PE32+, or
> TE header.
> -
> - @return EFI_IMAGE_NT_OPTIONAL_HDR32_MAGIC - Image is PE32
> - @return EFI_IMAGE_NT_OPTIONAL_HDR64_MAGIC - Image is PE32+
> -
> -**/
> -VOID
> -CreateHobList (
> - IN VOID *MemoryBegin,
> - IN UINTN MemoryLength,
> - IN VOID *HobBase,
> - IN VOID *StackBase
> - );
> -
> -
> /**
>This service enables PEIMs to create various types of HOBs.
>
> diff --git a/EmbeddedPkg/Library/PrePiHobLib/Hob.c
> b/EmbeddedPkg/Library/PrePiHobLib/Hob.c
> index aff8ea05797b..ba16899a9184 100644
> --- a/EmbeddedPkg/Library/PrePiHobLib/Hob.c
> +++ b/EmbeddedPkg/Library/PrePiHobLib/Hob.c
> @@ -175,47 +175,6 @@ BuildResourceDescriptorHob (
>Hob->ResourceLength= NumberOfBytes;
> }
>
> -/**
> -
> -
> -**/
> -VOID
> -CreateHobList (
> - IN VOID *MemoryBegin,
> - IN UINTN MemoryLength,
> - IN VOID *HobBase,
> - IN VOID *StackBase
> - )
> -{
> - EFI_HOB_HANDOFF_INFO_TABLE *Hob;
> - EFI_RESOURCE_ATTRIBUTE_TYPE Attributes;
> -
> - Hob = HobConstructor (MemoryBegin,MemoryLength,HobBase,StackBase);
> - SetHobList (Hob);
> -
> - BuildCpuHob (PcdGet8 (PcdPrePiCpuMemorySize), PcdGet8 (PcdPrePiCpuIoSize));
> -
> - Attributes =(
> -EFI_RESOURCE_ATTRIBUTE_PRESENT |
> -EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
> -EFI_RESOURCE_ATTRIBUTE_TESTED |
> -EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
> -EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
> -EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
> -EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE
> - );
> -
> - BuildResourceDescriptorHob (EFI_RESOURCE_SYSTEM_MEMORY, Attributes,
> (UINTN)MemoryBegin, MemoryLength);
> -
> - BuildStackHob ((EFI_PHYSICAL_ADDRESS)(UINTN)StackBase, ((UINTN)MemoryBegin
> + MemoryLength) - (UINTN)StackBase);
> -
> - if (FeaturePcdGet (PcdPrePiProduceMemoryTypeInformationHob)) {
> -// Optional feature that helps prevent EFI memory map fragmentation.
> -BuildMemoryTypeInformationHob ();
> - }
> -}
> -
> -
> VOID
> EFIAPI
> BuildFvHobs (
>
Reviewed-by: Laszlo Ersek
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 0/2] SortLib for UEFI SEC
+cc package maintainers From: Jeff Brasen Sent: Wednesday, November 28, 2018 10:17 AM To: Carsey, Jaben; edk2-devel@lists.01.org Subject: Re: [edk2] [PATCH v3 0/2] SortLib for UEFI SEC Any additional updates on this patch series? Thanks, Jeff From: Carsey, Jaben Sent: Thursday, November 8, 2018 4:46:15 PM To: Jeff Brasen; edk2-devel@lists.01.org Subject: RE: [edk2] [PATCH v3 0/2] SortLib for UEFI SEC For the series. Reviewed-by: Jaben Carsey > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Jeff Brasen > Sent: Thursday, November 08, 2018 11:04 AM > To: edk2-devel@lists.01.org > Cc: Jeff Brasen > Subject: [edk2] [PATCH v3 0/2] SortLib for UEFI SEC > > This patch series enables support for BaseSortLib in UEFI SEC Phase. > This requires the addition of the AllocateZeroPool which is implemented > in the PrePiMemoryAllocationLib. > > Changelog: > v1 - Initial version > v2 - Update order of NULL check in MemoryAllocationLib > v3 - Switch to ZeroMem from SetMem > > Jeff Brasen (2): > EmbeddedPkg/PrePiMemoryAllocationLib: Added AllocateZeroPool() > MdeModulePkg/BaseSortLib: Enable for all module types > > .../PrePiMemoryAllocationLib/MemoryAllocationLib.c | 32 > ++ > MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf | 4 +-- > 2 files changed, 34 insertions(+), 2 deletions(-) > > -- > 2.7.4 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 1/2] MdeModulePkg/SdMmcPciHcDxe: Declare V4 64 bit address capability
Separate V4 1/2 patch has been submitted with changes made as per feedback.
Thanks
Ashish
-Original Message-
From: Wu, Hao A
Sent: Wednesday, November 28, 2018 12:25 AM
To: Ashish Singhal ; edk2-devel@lists.01.org
Subject: RE: [edk2] [PATCH v3 1/2] MdeModulePkg/SdMmcPciHcDxe: Declare V4 64
bit address capability
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ashish Singhal
> Sent: Tuesday, November 20, 2018 4:59 AM
> To: edk2-devel@lists.01.org
> Cc: Ashish Singhal
> Subject: [edk2] [PATCH v3 1/2] MdeModulePkg/SdMmcPciHcDxe: Declare V4
> 64 bit address capability
>
> Add capability declaration for V4.x 64 bit system address support.
> This would be used for host controllers working in version 4. Enable
> 64 bit DMA support in PCI layer if V3 or V4 64 bit support is enabled
> in host capability register.
>
> The usage of this new field does not need a guard for version check as
> spec for previous SDMMC versions defines this field as reserved with
> default value of 0.
Hello,
Sorry for the delayed response.
I have filed a Tianocore Feature Requests Bugzilla tracker for the 64-bit
SDMA/ADMA support for Sd/MMC host controller driver:
https://bugzilla.tianocore.org/show_bug.cgi?id=1359
Could you help to include this Bugzilla tracker message in your 2 proposed
patches?
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ashish Singhal
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 4 ++--
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 3 ++-
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 10 +-
> 3 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> index bf9869d..1c18ea4 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> @@ -617,7 +617,6 @@ SdMmcPciHcDriverBindingStart (
> }
>}
>
> - Support64BitDma = TRUE;
Please keep the above line, otherwise GCC compiler (I am testing with GCC4.9)
seems not happy with it.
>for (Slot = FirstBar; Slot < (FirstBar + SlotNum); Slot++) {
> Private->Slot[Slot].Enable = TRUE;
>
> @@ -638,7 +637,8 @@ SdMmcPciHcDriverBindingStart (
> }
> DumpCapabilityReg (Slot, >Capability[Slot]);
>
> -Support64BitDma &= Private->Capability[Slot].SysBus64;
> +Support64BitDma = (Private->Capability[Slot].SysBus64V3 |
> + Private->Capability[Slot].SysBus64V4);
For the above statement, how about:
Support64BitDma &= (Private->Capability[Slot].SysBus64V3 |
Private->Capability[Slot].SysBus64V4);
The Visual Studio 2015 complier build fails for your current proposed change.
Best Regards,
Hao Wu
>
> Status = SdMmcHcGetMaxCurrent (PciIo, Slot,
> >MaxCurrent[Slot]);
> if (EFI_ERROR (Status)) {
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index bedc968..e506875 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -45,7 +45,8 @@ DumpCapabilityReg (
>DEBUG ((DEBUG_INFO, " Voltage 3.3 %a\n", Capability->Voltage33 ?
> "TRUE" : "FALSE"));
>DEBUG ((DEBUG_INFO, " Voltage 3.0 %a\n", Capability->Voltage30 ?
> "TRUE" : "FALSE"));
>DEBUG ((DEBUG_INFO, " Voltage 1.8 %a\n", Capability->Voltage18 ?
> "TRUE" : "FALSE"));
> - DEBUG ((DEBUG_INFO, " 64-bit Sys Bus%a\n", Capability->SysBus64 ?
> "TRUE" : "FALSE"));
> + DEBUG ((DEBUG_INFO, " V4 64-bit Sys Bus %a\n", Capability-
> >SysBus64V4 ? "TRUE" : "FALSE"));
> + DEBUG ((DEBUG_INFO, " V3 64-bit Sys Bus %a\n", Capability-
> >SysBus64V3 ? "TRUE" : "FALSE"));
>DEBUG ((DEBUG_INFO, " Async Interrupt %a\n", Capability->AsyncInt ?
> "TRUE" : "FALSE"));
>DEBUG ((DEBUG_INFO, " SlotType "));
>if (Capability->SlotType == 0x00) { diff --git
> a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h
> index 7e3f588..cc138fc 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h
> @@ -114,24 +114,24 @@ typedef struct {
>UINT32 Voltage33:1; // bit 24
>UINT32 Voltage30:1; // bit 25
>UINT32 Voltage18:1; // bit 26
> - UINT32 Reserved3:1; // bit 27
> - UINT32 SysBus64:1;// bit 28
> + UINT32 SysBus64V4:1; // bit 27
> + UINT32 SysBus64V3:1; // bit 28
>UINT32 AsyncInt:1;// bit 29
>UINT32 SlotType:2;// bit 30:31
>UINT32 Sdr50:1; // bit 32
>UINT32 Sdr104:1; // bit 33
>UINT32 Ddr50:1; // bit 34
> - UINT32 Reserved4:1; // bit 35
> + UINT32 Reserved3:1; //
[edk2] Pkcs7 crypto verification without openSSL
Hi, Are there any plans for a crypto library that does not pull in openSSL? When I try to add BaseCryptLib to be able to use FmpAuthenticationLib, my driver size baloons significantly (increase of ~0x3) and it seems like a basic public SHA256 crypto check library should not be _that_ large? Cheers, Tom ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch v2] Maintainers.txt: Add the rule to hand over the package maintain role
Hi, On 28/11/18 15:03, Liming Gao wrote: > In V2, change his to the, and add new maintainers follow up. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Liming Gao > --- > Maintainers.txt | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/Maintainers.txt b/Maintainers.txt > index 91a4657adc..e102114c34 100644 > --- a/Maintainers.txt > +++ b/Maintainers.txt > @@ -6,7 +6,10 @@ EDK II. > > In general, you should not privately email the maintainer. You should > email the edk2-devel list, and Cc the package maintainers and > -reviewers. > +reviewers. If the package maintainer wants to hand over the role to I'd move this to another paragraph, the first one is directed to contributors, the second one would be to maintainers. > +other people, the package maintainer should send the patch to update > +Maintainers.txt with new maintainer, and the new maintainer should > +follow up with an Acked-by or a Reviewed-by. I noticed an extra space at the end of the lines you added, which resulted in the following errors when applying: Applying: Maintainers.txt: Add the rule to hand over the package maintain role .git/rebase-apply/patch:14: trailing whitespace. reviewers. If the package maintainer wants to hand over the role to .git/rebase-apply/patch:15: trailing whitespace. other people, the package maintainer should send the patch to update .git/rebase-apply/patch:16: trailing whitespace. Maintainers.txt with new maintainer, and the new maintainer should error: patch failed: Maintainers.txt:6 error: Maintainers.txt: patch does not apply Thanks for adding the maintainership handover clarification, I appreciate :) With space fixed (same or another paragraphs): Reviewed-by: Philippe Mathieu-Daudé > > Descriptions of section entries: > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 04/16] ArmVirtPkg/QemuVirtMemInfoLib: remove 1:1 mapping of top of PA range
On 28/11/18 15:33, Ard Biesheuvel wrote:
> Currently, we map DRAM as EFI_MEMORY_WB, and the remainder of the
> entire virtual address space is mapped with EFI_MEMORY_UC attributes,
> regardless of whether any devices actually reside there.
>
> Now that we are relaxing the address space limit to more than 40 bits,
> mapping all that address space actually takes up more space in page
> tables than we have so far made available as temporary RAM. So let's
> get rid of the mapping rather than increasing the available RAM, given
> that the mapping is not particularly useful anyway.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Philippe Mathieu-Daudé
> ---
> ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf| 7
> ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf | 7
> ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c | 25
> +++--
> ArmVirtPkg/Library/QemuVirtMemInfoLib/AArch64/PhysAddrTop.S | 39
>
> ArmVirtPkg/Library/QemuVirtMemInfoLib/Arm/PhysAddrTop.S | 24
>
> 5 files changed, 5 insertions(+), 97 deletions(-)
>
> diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf
> b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf
> index c72a97f9e78a..5c5b841051ad 100644
> --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf
> +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf
> @@ -24,12 +24,6 @@ [Defines]
> [Sources]
>QemuVirtMemInfoLib.c
>
> -[Sources.ARM]
> - Arm/PhysAddrTop.S
> -
> -[Sources.AARCH64]
> - AArch64/PhysAddrTop.S
> -
> [Packages]
>ArmPkg/ArmPkg.dec
>ArmVirtPkg/ArmVirtPkg.dec
> @@ -51,4 +45,3 @@ [Pcd]
>
> [FixedPcd]
>gArmTokenSpaceGuid.PcdFdSize
> - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize
> diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
> b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
> index e4032d3efb53..d12089760b22 100644
> --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
> +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
> @@ -26,12 +26,6 @@ [Sources]
>QemuVirtMemInfoLib.c
>QemuVirtMemInfoPeiLibConstructor.c
>
> -[Sources.ARM]
> - Arm/PhysAddrTop.S
> -
> -[Sources.AARCH64]
> - AArch64/PhysAddrTop.S
> -
> [Packages]
>ArmPkg/ArmPkg.dec
>ArmVirtPkg/ArmVirtPkg.dec
> @@ -55,4 +49,3 @@ [Pcd]
> [FixedPcd]
>gArmTokenSpaceGuid.PcdFdSize
>gArmVirtTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress
> - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize
> diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> index 760bcc169cf4..0285a11b1d77 100644
> --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> @@ -21,11 +21,6 @@
> // Number of Virtual Memory Map Descriptors
> #define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS 5
>
> -EFI_PHYSICAL_ADDRESS
> -ArmGetPhysAddrTop (
> - VOID
> - );
> -
> /**
>Return the Virtual Memory Map of your platform
>
> @@ -45,7 +40,6 @@ ArmVirtGetMemoryMap (
>)
> {
>ARM_MEMORY_REGION_DESCRIPTOR *VirtualMemoryTable;
> - UINT64TopOfMemory;
>
>ASSERT (VirtualMemoryMap != NULL);
>
> @@ -78,23 +72,14 @@ ArmVirtGetMemoryMap (
>VirtualMemoryTable[1].Length = VirtualMemoryTable[0].PhysicalBase;
>VirtualMemoryTable[1].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
>
> - // Peripheral space after DRAM
> - TopOfMemory = MIN (1ULL << FixedPcdGet8 (PcdPrePiCpuMemorySize),
> - ArmGetPhysAddrTop ());
> - VirtualMemoryTable[2].PhysicalBase = VirtualMemoryTable[0].Length +
> VirtualMemoryTable[1].Length;
> - VirtualMemoryTable[2].VirtualBase = VirtualMemoryTable[2].PhysicalBase;
> - VirtualMemoryTable[2].Length = TopOfMemory -
> - VirtualMemoryTable[2].PhysicalBase;
> - VirtualMemoryTable[2].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> -
>// Remap the FD region as normal executable memory
> - VirtualMemoryTable[3].PhysicalBase = PcdGet64 (PcdFdBaseAddress);
> - VirtualMemoryTable[3].VirtualBase = VirtualMemoryTable[3].PhysicalBase;
> - VirtualMemoryTable[3].Length = FixedPcdGet32 (PcdFdSize);
> - VirtualMemoryTable[3].Attributes =
> ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
> + VirtualMemoryTable[2].PhysicalBase = PcdGet64 (PcdFdBaseAddress);
> + VirtualMemoryTable[2].VirtualBase = VirtualMemoryTable[2].PhysicalBase;
> + VirtualMemoryTable[2].Length = FixedPcdGet32 (PcdFdSize);
> + VirtualMemoryTable[2].Attributes =
> ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
>
>// End of Table
> - ZeroMem ([4], sizeof (ARM_MEMORY_REGION_DESCRIPTOR));
> + ZeroMem ([3], sizeof
Re: [edk2] [PATCH v3 11/16] ArmVirtPkg/PrePi: base GCD memory space size on CPU's PA range
On 28/11/18 15:33, Ard Biesheuvel wrote: > Derive the size of the GCD memory space map directly from the CPU's > information registers rather than from the PcdPrePiCpuMemorySize PCD, > which will be removed. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Reviewed-by: Philippe Mathieu-Daudé > --- > ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf | 1 - > ArmVirtPkg/PrePi/PrePi.c| 2 +- > 2 files changed, 1 insertion(+), 2 deletions(-) > > diff --git a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf > b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf > index 1587bd92f206..034ddb41cb48 100755 > --- a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf > +++ b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf > @@ -85,7 +85,6 @@ [FixedPcd] > >gArmPlatformTokenSpaceGuid.PcdCoreCount > > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize >gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize > >gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory > diff --git a/ArmVirtPkg/PrePi/PrePi.c b/ArmVirtPkg/PrePi/PrePi.c > index f6abe2f2016b..61de6cfd4ae6 100755 > --- a/ArmVirtPkg/PrePi/PrePi.c > +++ b/ArmVirtPkg/PrePi/PrePi.c > @@ -80,7 +80,7 @@ PrePiMain ( >BuildStackHob (StacksBase, StacksSize); > >//TODO: Call CpuPei as a library > - BuildCpuHob (PcdGet8 (PcdPrePiCpuMemorySize), PcdGet8 (PcdPrePiCpuIoSize)); > + BuildCpuHob (ArmGetPhysicalAddressBits (), PcdGet8 (PcdPrePiCpuIoSize)); > >// Set the Boot Mode >SetBootMode (BOOT_WITH_FULL_CONFIGURATION); > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 12/16] BeagleBoardPkg/PrePi: base GCD memory space size on CPU's PA range
On 28/11/18 15:33, Ard Biesheuvel wrote: > Derive the size of the GCD memory space map directly from the CPU's > information registers rather than from the PcdPrePiCpuMemorySize PCD, > which will be removed. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Reviewed-by: Philippe Mathieu-Daudé > --- > BeagleBoardPkg/PrePi/PeiUniCore.inf | 1 - > BeagleBoardPkg/PrePi/PrePi.c| 2 +- > 2 files changed, 1 insertion(+), 2 deletions(-) > > diff --git a/BeagleBoardPkg/PrePi/PeiUniCore.inf > b/BeagleBoardPkg/PrePi/PeiUniCore.inf > index 3d72bc5b46e1..53c71d8eafc2 100644 > --- a/BeagleBoardPkg/PrePi/PeiUniCore.inf > +++ b/BeagleBoardPkg/PrePi/PeiUniCore.inf > @@ -86,7 +86,6 @@ [FixedPcd] > >gArmPlatformTokenSpaceGuid.PcdCoreCount > > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize >gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize > >gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory > diff --git a/BeagleBoardPkg/PrePi/PrePi.c b/BeagleBoardPkg/PrePi/PrePi.c > index 46f63f40c46e..bc9b0c80b84c 100644 > --- a/BeagleBoardPkg/PrePi/PrePi.c > +++ b/BeagleBoardPkg/PrePi/PrePi.c > @@ -110,7 +110,7 @@ PrePiMain ( >BuildStackHob (StacksBase, StacksSize); > >//TODO: Call CpuPei as a library > - BuildCpuHob (PcdGet8 (PcdPrePiCpuMemorySize), PcdGet8 (PcdPrePiCpuIoSize)); > + BuildCpuHob (ArmGetPhysicalAddressBits (), PcdGet8 (PcdPrePiCpuIoSize)); > >// Store timer value logged at the beginning of firmware image execution >Performance.ResetEnd = GetTimeInNanoSecond (StartTimeStamp); > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 09/16] ArmPkg/CpuPei: base GCD memory space size on CPU's PA range
On 28/11/18 15:33, Ard Biesheuvel wrote: > Derive the size of the GCD memory space map directly from the CPU's > information registers rather than from the PcdPrePiCpuMemorySize PCD, > which will be removed. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > ArmPkg/Drivers/CpuPei/CpuPei.inf | 1 - > ArmPkg/Drivers/CpuPei/CpuPei.c | 2 +- > 2 files changed, 1 insertion(+), 2 deletions(-) > > diff --git a/ArmPkg/Drivers/CpuPei/CpuPei.inf > b/ArmPkg/Drivers/CpuPei/CpuPei.inf > index eafccd600983..dcea012fd8f9 100644 > --- a/ArmPkg/Drivers/CpuPei/CpuPei.inf > +++ b/ArmPkg/Drivers/CpuPei/CpuPei.inf > @@ -50,7 +50,6 @@ [Guids] >gArmMpCoreInfoGuid > > [FixedPcd] > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize >gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize > > [Depex] > diff --git a/ArmPkg/Drivers/CpuPei/CpuPei.c b/ArmPkg/Drivers/CpuPei/CpuPei.c > index d54f42acfcc8..e63519ff6481 100644 > --- a/ArmPkg/Drivers/CpuPei/CpuPei.c > +++ b/ArmPkg/Drivers/CpuPei/CpuPei.c > @@ -73,7 +73,7 @@ InitializeCpuPeim ( >ArmEnableBranchPrediction (); > >// Publish the CPU memory and io spaces sizes This comment is misleading, maybe 'sizes' -> 'addressable bits'? (not related to this series) > - BuildCpuHob (PcdGet8 (PcdPrePiCpuMemorySize), PcdGet8 (PcdPrePiCpuIoSize)); > + BuildCpuHob (ArmGetPhysicalAddressBits (), PcdGet8 (PcdPrePiCpuIoSize)); Reviewed-by: Philippe Mathieu-Daudé > >// Only MP Core platform need to produce gArmMpCoreInfoPpiGuid >Status = PeiServicesLocatePpi (, 0, NULL, > (VOID**)); > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 08/16] ArmPkg/ArmMmuLib: take the CPU supported maximum PA space into account
On 28/11/18 15:33, Ard Biesheuvel wrote: > In preparation of dropping PcdPrePiCpuMemorySize entirely, base the > maximum size of the identity map on the capabilities of the CPU. > Since that may exceed what is architecturally permitted when using > 4 KB pages, take MAX_ADDRESS into account as well. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Reviewed-by: Philippe Mathieu-Daudé > --- > ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf | 3 --- > ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf| 3 --- > ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c | 11 +-- > 3 files changed, 9 insertions(+), 8 deletions(-) > > diff --git a/ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf > b/ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf > index b9f264de8d26..246963361e45 100644 > --- a/ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf > +++ b/ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf > @@ -40,8 +40,5 @@ [LibraryClasses] >CacheMaintenanceLib >MemoryAllocationLib > > -[Pcd.AARCH64] > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize > - > [Pcd.ARM] >gArmTokenSpaceGuid.PcdNormalMemoryNonshareableOverride > diff --git a/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf > b/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf > index ecf13f790734..f689c193b862 100644 > --- a/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf > +++ b/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf > @@ -35,6 +35,3 @@ [LibraryClasses] >ArmLib >CacheMaintenanceLib >MemoryAllocationLib > - > -[Pcd.AARCH64] > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize > diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c > b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c > index 4b62ecb6a476..5403b8d4070e 100644 > --- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c > +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c > @@ -604,8 +604,15 @@ ArmConfigureMmu ( > return EFI_INVALID_PARAMETER; >} > > - // Cover the entire GCD memory space > - MaxAddress = (1UL << PcdGet8 (PcdPrePiCpuMemorySize)) - 1; > + // > + // Limit the virtual address space to what we can actually use: UEFI > + // mandates a 1:1 mapping, so no point in making the virtual address > + // space larger than the physical address space. We also have to take > + // into account the architectural limitations that result from UEFI's > + // use of 4 KB pages. > + // > + MaxAddress = MIN (LShiftU64 (1ULL, ArmGetPhysicalAddressBits ()) - 1, > +MAX_ADDRESS); > >// Lookup the Table Level to get the information >LookupAddresstoRootTable (MaxAddress, , ); > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 07/16] ArmVirtPkg/XenVirtMemInfoLib: refactor reading of the PA space size
On 28/11/18 15:33, Ard Biesheuvel wrote:
> Use the new ArmLib helper to read the CPU's physical address limit
> so we can drop our own homecooked one.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf | 6 ---
> ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c | 11 +++---
> ArmVirtPkg/Library/XenVirtMemInfoLib/AArch64/PhysAddrTop.S | 39
>
> ArmVirtPkg/Library/XenVirtMemInfoLib/Arm/PhysAddrTop.S | 24
Good diffstat :)
Reviewed-by: Philippe Mathieu-Daudé
> 4 files changed, 5 insertions(+), 75 deletions(-)
>
> diff --git a/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf
> b/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf
> index cd4c805a4db9..ae107810e927 100644
> --- a/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf
> +++ b/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf
> @@ -24,12 +24,6 @@ [Defines]
> [Sources]
>XenVirtMemInfoLib.c
>
> -[Sources.ARM]
> - Arm/PhysAddrTop.S
> -
> -[Sources.AARCH64]
> - AArch64/PhysAddrTop.S
> -
> [Packages]
>ArmPkg/ArmPkg.dec
>ArmVirtPkg/ArmVirtPkg.dec
> diff --git a/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c
> b/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c
> index 88ff3167cbfd..6701dec50ea8 100644
> --- a/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c
> +++ b/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c
> @@ -18,11 +18,6 @@
>
> STATIC ARM_MEMORY_REGION_DESCRIPTOR mVirtualMemoryTable[2];
>
> -EFI_PHYSICAL_ADDRESS
> -ArmGetPhysAddrTop (
> - VOID
> - );
> -
> /**
>Return the Virtual Memory Map of your platform
>
> @@ -42,8 +37,12 @@ ArmVirtGetMemoryMap (
>OUT ARM_MEMORY_REGION_DESCRIPTOR **VirtualMemoryMap
>)
> {
> + EFI_PHYSICAL_ADDRESS TopOfAddressSpace;
> +
>ASSERT (VirtualMemoryMap != NULL);
>
> + TopOfAddressSpace = LShiftU64 (1ULL, ArmGetPhysicalAddressBits ());
> +
>//
>// Map the entire physical memory space as cached. The only device
>// we care about is the GIC, which will be stage 2 mapped as a device
> @@ -51,7 +50,7 @@ ArmVirtGetMemoryMap (
>//
>mVirtualMemoryTable[0].PhysicalBase = 0x0;
>mVirtualMemoryTable[0].VirtualBase = 0x0;
> - mVirtualMemoryTable[0].Length = ArmGetPhysAddrTop ();
> + mVirtualMemoryTable[0].Length = TopOfAddressSpace;
>mVirtualMemoryTable[0].Attributes =
> ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
>
>mVirtualMemoryTable[1].PhysicalBase = 0x0;
> diff --git a/ArmVirtPkg/Library/XenVirtMemInfoLib/AArch64/PhysAddrTop.S
> b/ArmVirtPkg/Library/XenVirtMemInfoLib/AArch64/PhysAddrTop.S
> deleted file mode 100644
> index a1f6a194d59b..
> --- a/ArmVirtPkg/Library/XenVirtMemInfoLib/AArch64/PhysAddrTop.S
> +++ /dev/null
> @@ -1,39 +0,0 @@
> -#
> -# Copyright (c) 2011-2013, ARM Limited. All rights reserved.
> -# Copyright (c) 2016-2017, Linaro Limited. All rights reserved.
> -#
> -# This program and the accompanying materials
> -# are licensed and made available under the terms and conditions of the BSD
> License
> -# which accompanies this distribution. The full text of the license may be
> found at
> -# http://opensource.org/licenses/bsd-license.php
> -#
> -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> IMPLIED.
> -#
> -#
> -
> -#include
> -
> -//EFI_PHYSICAL_ADDRESS
> -//GetPhysAddrTop (
> -// VOID
> -// );
> -ASM_FUNC(ArmGetPhysAddrTop)
> - mrs x0, id_aa64mmfr0_el1
> - adr x1, .LPARanges
> - and x0, x0, #7
> - ldrb w1, [x1, x0]
> - mov x0, #1
> - lsl x0, x0, x1
> - ret
> -
> -//
> -// Bits 0..2 of the AA64MFR0_EL1 system register encode the size of the
> -// physical address space support on this CPU:
> -// 0 == 32 bits, 1 == 36 bits, etc etc
> -// 6 and 7 are reserved
> -//
> -.LPARanges:
> - .byte 32, 36, 40, 42, 44, 48, -1, -1
> -
> -ASM_FUNCTION_REMOVE_IF_UNREFERENCED
> diff --git a/ArmVirtPkg/Library/XenVirtMemInfoLib/Arm/PhysAddrTop.S
> b/ArmVirtPkg/Library/XenVirtMemInfoLib/Arm/PhysAddrTop.S
> deleted file mode 100644
> index 9cd81529fb3d..
> --- a/ArmVirtPkg/Library/XenVirtMemInfoLib/Arm/PhysAddrTop.S
> +++ /dev/null
> @@ -1,24 +0,0 @@
> -#
> -# Copyright (c) 2011-2013, ARM Limited. All rights reserved.
> -# Copyright (c) 2014-2017, Linaro Limited. All rights reserved.
> -#
> -# This program and the accompanying materials
> -# are licensed and made available under the terms and conditions of the BSD
> License
> -# which accompanies this distribution. The full text of the license may be
> found at
> -# http://opensource.org/licenses/bsd-license.php
> -#
> -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> IMPLIED.
> -#
Re: [edk2] [PATCH v3 06/16] ArmPkg/ArmLib: add support for reading the max physical address space size
On 28/11/18 15:33, Ard Biesheuvel wrote: > Add a helper function that returns the maximum physical address space > size as supported by the current CPU. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Reviewed-by: Philippe Mathieu-Daudé > --- > ArmPkg/Include/Library/ArmLib.h | 6 ++ > ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S | 17 + > ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S | 8 > ArmPkg/Library/ArmLib/Arm/ArmLibSupport.asm | 8 > 4 files changed, 39 insertions(+) > > diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h > index ffda50e9d767..9a804c15fdb6 100644 > --- a/ArmPkg/Include/Library/ArmLib.h > +++ b/ArmPkg/Include/Library/ArmLib.h > @@ -733,4 +733,10 @@ ArmWriteCntvOff ( >UINT64 Val >); > > +UINTN > +EFIAPI > +ArmGetPhysicalAddressBits ( > + VOID > + ); > + > #endif // __ARM_LIB__ > diff --git a/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > b/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > index 1ef2f61f5979..b7173e00b039 100644 > --- a/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > +++ b/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > @@ -196,4 +196,21 @@ ASM_FUNC(ArmWriteSctlr) > 3:msr sctlr_el3, x0 > 4:ret > > +ASM_FUNC(ArmGetPhysicalAddressBits) > + mrs x0, id_aa64mmfr0_el1 > + adr x1, .LPARanges > + and x0, x0, #0xf > + ldrb w0, [x1, x0] > + ret > + > +// > +// Bits 0..3 of the AA64MFR0_EL1 system register encode the size of the > +// physical address space support on this CPU: > +// 0 == 32 bits, 1 == 36 bits, etc etc > +// 7 and up are reserved > +// > +.LPARanges: > + .byte 32, 36, 40, 42, 44, 48, 52, 0 > + .byte 0, 0, 0, 0, 0, 0, 0, 0 > + > ASM_FUNCTION_REMOVE_IF_UNREFERENCED > diff --git a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > index f2a517671f0a..0e9f9d0453e4 100644 > --- a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > +++ b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > @@ -165,4 +165,12 @@ ASM_FUNC(ArmWriteCpuActlr) >isb >bx lr > > +ASM_FUNC (ArmGetPhysicalAddressBits) > + mrc p15, 0, r0, c0, c1, 4 // MMFR0 > + and r0, r0, #0xf// VMSA [3:0] > + cmp r0, #5 // >= 5 implies LPAE support > + movlt r0, #32 // 32 bits if no LPAE > + movge r0, #40 // 40 bits if LPAE > + bx lr > + > ASM_FUNCTION_REMOVE_IF_UNREFERENCED > diff --git a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.asm > b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.asm > index 219140c22b13..3eb52875971d 100644 > --- a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.asm > +++ b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.asm > @@ -169,4 +169,12 @@ >isb >bx lr > > + RVCT_ASM_EXPORT ArmGetPhysicalAddressBits > + mrc p15, 0, r0, c0, c1, 4 ; MMFR0 > + and r0, r0, #0xf; VMSA [3:0] > + cmp r0, #5 ; >= 5 implies LPAE support > + movlt r0, #32 ; 32 bits if no LPAE > + movge r0, #40 ; 40 bits if LPAE > + bx lr > + >END > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3 16/16] EmbeddedPkg/EmbeddedPkg.dec: drop PcdPrePiCpuMemorySize declarations
PcdPrePiCpuMemorySize is no longer used so drop the declarations from the package DEC file. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- EmbeddedPkg/EmbeddedPkg.dec | 4 1 file changed, 4 deletions(-) diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec index 28a143865d0e..ff5aab07d745 100644 --- a/EmbeddedPkg/EmbeddedPkg.dec +++ b/EmbeddedPkg/EmbeddedPkg.dec @@ -170,22 +170,18 @@ [PcdsFixedAtBuild.common] gEmbeddedTokenSpaceGuid.PcdAndroidBootDevicePath|L""|VOID*|0x0057 [PcdsFixedAtBuild.ARM] - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize|32|UINT8|0x0010 gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|0|UINT8|0x0011 # ISP1761 USB OTG Controller gEmbeddedTokenSpaceGuid.PcdIsp1761BaseAddress|0|UINT32|0x0021 [PcdsFixedAtBuild.AARCH64] - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize|48|UINT8|0x0010 gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|0|UINT8|0x0011 [PcdsFixedAtBuild.IA32] - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize|36|UINT8|0x0010 gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|16|UINT8|0x0011 [PcdsFixedAtBuild.X64] - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize|52|UINT8|0x0010 gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|16|UINT8|0x0011 [PcdsFixedAtBuild.common, PcdsDynamic.common] -- 2.19.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3 15/16] ArmVirtPkg: drop PcdPrePiCpuMemorySize assignments from all platforms
PcdPrePiCpuMemorySize is no longer used so drop the PCD overrides from all platform descriptions in ArmVirtPkg. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- ArmVirtPkg/ArmVirt.dsc.inc | 3 --- ArmVirtPkg/ArmVirtQemu.dsc | 4 ArmVirtPkg/ArmVirtQemuKernel.dsc | 4 3 files changed, 11 deletions(-) diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc index 70a0ac4d786c..fbdb5c982604 100644 --- a/ArmVirtPkg/ArmVirt.dsc.inc +++ b/ArmVirtPkg/ArmVirt.dsc.inc @@ -388,9 +388,6 @@ [PcdsFixedAtBuild.common] # gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE -[PcdsFixedAtBuild.ARM] - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize|40 - [Components.common] # # Ramdisk support diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc index 885c6b14b844..a107b6bb5104 100644 --- a/ArmVirtPkg/ArmVirtQemu.dsc +++ b/ArmVirtPkg/ArmVirtQemu.dsc @@ -143,10 +143,6 @@ [PcdsFixedAtBuild.common] gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|16 [PcdsFixedAtBuild.AARCH64] - # KVM limits it IPA space to 40 bits (1 TB), so there is no need to - # support anything bigger, even if the host hardware does - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize|40 - # Clearing BIT0 in this PCD prevents installing a 32-bit SMBIOS entry point, # if the entry point version is >= 3.0. AARCH64 OSes cannot assume the # presence of the 32-bit entry point anyway (because many AARCH64 systems diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc index 434d6861a56f..d8fbf14e8f4e 100644 --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc @@ -157,10 +157,6 @@ [PcdsFixedAtBuild.AARCH64] # gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|16 - # KVM limits it IPA space to 40 bits (1 TB), so there is no need to - # support anything bigger, even if the host hardware does - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize|40 - [PcdsDynamicDefault.common] gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3 -- 2.19.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3 14/16] EmbeddedPkg/PrePiLib: drop unused PCD reference
Drop the reference to gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize which is never used. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- EmbeddedPkg/Library/PrePiLib/PrePiLib.inf | 1 - 1 file changed, 1 deletion(-) diff --git a/EmbeddedPkg/Library/PrePiLib/PrePiLib.inf b/EmbeddedPkg/Library/PrePiLib/PrePiLib.inf index de68405098c0..3dba884b1f31 100644 --- a/EmbeddedPkg/Library/PrePiLib/PrePiLib.inf +++ b/EmbeddedPkg/Library/PrePiLib/PrePiLib.inf @@ -69,7 +69,6 @@ [Protocols] [FixedPcd.common] - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory -- 2.19.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3 08/16] ArmPkg/ArmMmuLib: take the CPU supported maximum PA space into account
In preparation of dropping PcdPrePiCpuMemorySize entirely, base the maximum size of the identity map on the capabilities of the CPU. Since that may exceed what is architecturally permitted when using 4 KB pages, take MAX_ADDRESS into account as well. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf | 3 --- ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf| 3 --- ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c | 11 +-- 3 files changed, 9 insertions(+), 8 deletions(-) diff --git a/ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf b/ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf index b9f264de8d26..246963361e45 100644 --- a/ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf +++ b/ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf @@ -40,8 +40,5 @@ [LibraryClasses] CacheMaintenanceLib MemoryAllocationLib -[Pcd.AARCH64] - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize - [Pcd.ARM] gArmTokenSpaceGuid.PcdNormalMemoryNonshareableOverride diff --git a/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf b/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf index ecf13f790734..f689c193b862 100644 --- a/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf +++ b/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf @@ -35,6 +35,3 @@ [LibraryClasses] ArmLib CacheMaintenanceLib MemoryAllocationLib - -[Pcd.AARCH64] - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c index 4b62ecb6a476..5403b8d4070e 100644 --- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c @@ -604,8 +604,15 @@ ArmConfigureMmu ( return EFI_INVALID_PARAMETER; } - // Cover the entire GCD memory space - MaxAddress = (1UL << PcdGet8 (PcdPrePiCpuMemorySize)) - 1; + // + // Limit the virtual address space to what we can actually use: UEFI + // mandates a 1:1 mapping, so no point in making the virtual address + // space larger than the physical address space. We also have to take + // into account the architectural limitations that result from UEFI's + // use of 4 KB pages. + // + MaxAddress = MIN (LShiftU64 (1ULL, ArmGetPhysicalAddressBits ()) - 1, +MAX_ADDRESS); // Lookup the Table Level to get the information LookupAddresstoRootTable (MaxAddress, , ); -- 2.19.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3 12/16] BeagleBoardPkg/PrePi: base GCD memory space size on CPU's PA range
Derive the size of the GCD memory space map directly from the CPU's information registers rather than from the PcdPrePiCpuMemorySize PCD, which will be removed. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- BeagleBoardPkg/PrePi/PeiUniCore.inf | 1 - BeagleBoardPkg/PrePi/PrePi.c| 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/BeagleBoardPkg/PrePi/PeiUniCore.inf b/BeagleBoardPkg/PrePi/PeiUniCore.inf index 3d72bc5b46e1..53c71d8eafc2 100644 --- a/BeagleBoardPkg/PrePi/PeiUniCore.inf +++ b/BeagleBoardPkg/PrePi/PeiUniCore.inf @@ -86,7 +86,6 @@ [FixedPcd] gArmPlatformTokenSpaceGuid.PcdCoreCount - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory diff --git a/BeagleBoardPkg/PrePi/PrePi.c b/BeagleBoardPkg/PrePi/PrePi.c index 46f63f40c46e..bc9b0c80b84c 100644 --- a/BeagleBoardPkg/PrePi/PrePi.c +++ b/BeagleBoardPkg/PrePi/PrePi.c @@ -110,7 +110,7 @@ PrePiMain ( BuildStackHob (StacksBase, StacksSize); //TODO: Call CpuPei as a library - BuildCpuHob (PcdGet8 (PcdPrePiCpuMemorySize), PcdGet8 (PcdPrePiCpuIoSize)); + BuildCpuHob (ArmGetPhysicalAddressBits (), PcdGet8 (PcdPrePiCpuIoSize)); // Store timer value logged at the beginning of firmware image execution Performance.ResetEnd = GetTimeInNanoSecond (StartTimeStamp); -- 2.19.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3 02/16] EmbeddedPkg/PrePiHobLib: drop CreateHobList() from library
Drop the declaration and the implementation of CreateHoblist(),
which is not used anywhere.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
EmbeddedPkg/Include/Library/PrePiLib.h | 18 -
EmbeddedPkg/Library/PrePiHobLib/Hob.c | 41
2 files changed, 59 deletions(-)
diff --git a/EmbeddedPkg/Include/Library/PrePiLib.h
b/EmbeddedPkg/Include/Library/PrePiLib.h
index cf70fca3b619..a857308ecec2 100644
--- a/EmbeddedPkg/Include/Library/PrePiLib.h
+++ b/EmbeddedPkg/Include/Library/PrePiLib.h
@@ -274,24 +274,6 @@ HobConstructor (
IN VOID *EfiFreeMemoryTop
);
-/**
- Retrieves the magic value from the PE/COFF header.
-
- @param Hdr The buffer in which to return the PE32, PE32+, or TE
header.
-
- @return EFI_IMAGE_NT_OPTIONAL_HDR32_MAGIC - Image is PE32
- @return EFI_IMAGE_NT_OPTIONAL_HDR64_MAGIC - Image is PE32+
-
-**/
-VOID
-CreateHobList (
- IN VOID *MemoryBegin,
- IN UINTN MemoryLength,
- IN VOID *HobBase,
- IN VOID *StackBase
- );
-
-
/**
This service enables PEIMs to create various types of HOBs.
diff --git a/EmbeddedPkg/Library/PrePiHobLib/Hob.c
b/EmbeddedPkg/Library/PrePiHobLib/Hob.c
index aff8ea05797b..ba16899a9184 100644
--- a/EmbeddedPkg/Library/PrePiHobLib/Hob.c
+++ b/EmbeddedPkg/Library/PrePiHobLib/Hob.c
@@ -175,47 +175,6 @@ BuildResourceDescriptorHob (
Hob->ResourceLength= NumberOfBytes;
}
-/**
-
-
-**/
-VOID
-CreateHobList (
- IN VOID *MemoryBegin,
- IN UINTN MemoryLength,
- IN VOID *HobBase,
- IN VOID *StackBase
- )
-{
- EFI_HOB_HANDOFF_INFO_TABLE *Hob;
- EFI_RESOURCE_ATTRIBUTE_TYPE Attributes;
-
- Hob = HobConstructor (MemoryBegin,MemoryLength,HobBase,StackBase);
- SetHobList (Hob);
-
- BuildCpuHob (PcdGet8 (PcdPrePiCpuMemorySize), PcdGet8 (PcdPrePiCpuIoSize));
-
- Attributes =(
-EFI_RESOURCE_ATTRIBUTE_PRESENT |
-EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
-EFI_RESOURCE_ATTRIBUTE_TESTED |
-EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
-EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
-EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
-EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE
- );
-
- BuildResourceDescriptorHob (EFI_RESOURCE_SYSTEM_MEMORY, Attributes,
(UINTN)MemoryBegin, MemoryLength);
-
- BuildStackHob ((EFI_PHYSICAL_ADDRESS)(UINTN)StackBase, ((UINTN)MemoryBegin +
MemoryLength) - (UINTN)StackBase);
-
- if (FeaturePcdGet (PcdPrePiProduceMemoryTypeInformationHob)) {
-// Optional feature that helps prevent EFI memory map fragmentation.
-BuildMemoryTypeInformationHob ();
- }
-}
-
-
VOID
EFIAPI
BuildFvHobs (
--
2.19.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3 06/16] ArmPkg/ArmLib: add support for reading the max physical address space size
Add a helper function that returns the maximum physical address space size as supported by the current CPU. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- ArmPkg/Include/Library/ArmLib.h | 6 ++ ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S | 17 + ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S | 8 ArmPkg/Library/ArmLib/Arm/ArmLibSupport.asm | 8 4 files changed, 39 insertions(+) diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h index ffda50e9d767..9a804c15fdb6 100644 --- a/ArmPkg/Include/Library/ArmLib.h +++ b/ArmPkg/Include/Library/ArmLib.h @@ -733,4 +733,10 @@ ArmWriteCntvOff ( UINT64 Val ); +UINTN +EFIAPI +ArmGetPhysicalAddressBits ( + VOID + ); + #endif // __ARM_LIB__ diff --git a/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S b/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S index 1ef2f61f5979..b7173e00b039 100644 --- a/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S +++ b/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S @@ -196,4 +196,21 @@ ASM_FUNC(ArmWriteSctlr) 3:msr sctlr_el3, x0 4:ret +ASM_FUNC(ArmGetPhysicalAddressBits) + mrs x0, id_aa64mmfr0_el1 + adr x1, .LPARanges + and x0, x0, #0xf + ldrb w0, [x1, x0] + ret + +// +// Bits 0..3 of the AA64MFR0_EL1 system register encode the size of the +// physical address space support on this CPU: +// 0 == 32 bits, 1 == 36 bits, etc etc +// 7 and up are reserved +// +.LPARanges: + .byte 32, 36, 40, 42, 44, 48, 52, 0 + .byte 0, 0, 0, 0, 0, 0, 0, 0 + ASM_FUNCTION_REMOVE_IF_UNREFERENCED diff --git a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S index f2a517671f0a..0e9f9d0453e4 100644 --- a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S +++ b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S @@ -165,4 +165,12 @@ ASM_FUNC(ArmWriteCpuActlr) isb bx lr +ASM_FUNC (ArmGetPhysicalAddressBits) + mrc p15, 0, r0, c0, c1, 4 // MMFR0 + and r0, r0, #0xf// VMSA [3:0] + cmp r0, #5 // >= 5 implies LPAE support + movlt r0, #32 // 32 bits if no LPAE + movge r0, #40 // 40 bits if LPAE + bx lr + ASM_FUNCTION_REMOVE_IF_UNREFERENCED diff --git a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.asm b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.asm index 219140c22b13..3eb52875971d 100644 --- a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.asm +++ b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.asm @@ -169,4 +169,12 @@ isb bx lr + RVCT_ASM_EXPORT ArmGetPhysicalAddressBits + mrc p15, 0, r0, c0, c1, 4 ; MMFR0 + and r0, r0, #0xf; VMSA [3:0] + cmp r0, #5 ; >= 5 implies LPAE support + movlt r0, #32 ; 32 bits if no LPAE + movge r0, #40 ; 40 bits if LPAE + bx lr + END -- 2.19.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3 07/16] ArmVirtPkg/XenVirtMemInfoLib: refactor reading of the PA space size
Use the new ArmLib helper to read the CPU's physical address limit
so we can drop our own homecooked one.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf | 6 ---
ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c | 11 +++---
ArmVirtPkg/Library/XenVirtMemInfoLib/AArch64/PhysAddrTop.S | 39
ArmVirtPkg/Library/XenVirtMemInfoLib/Arm/PhysAddrTop.S | 24
4 files changed, 5 insertions(+), 75 deletions(-)
diff --git a/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf
b/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf
index cd4c805a4db9..ae107810e927 100644
--- a/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf
+++ b/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf
@@ -24,12 +24,6 @@ [Defines]
[Sources]
XenVirtMemInfoLib.c
-[Sources.ARM]
- Arm/PhysAddrTop.S
-
-[Sources.AARCH64]
- AArch64/PhysAddrTop.S
-
[Packages]
ArmPkg/ArmPkg.dec
ArmVirtPkg/ArmVirtPkg.dec
diff --git a/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c
b/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c
index 88ff3167cbfd..6701dec50ea8 100644
--- a/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c
+++ b/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c
@@ -18,11 +18,6 @@
STATIC ARM_MEMORY_REGION_DESCRIPTOR mVirtualMemoryTable[2];
-EFI_PHYSICAL_ADDRESS
-ArmGetPhysAddrTop (
- VOID
- );
-
/**
Return the Virtual Memory Map of your platform
@@ -42,8 +37,12 @@ ArmVirtGetMemoryMap (
OUT ARM_MEMORY_REGION_DESCRIPTOR **VirtualMemoryMap
)
{
+ EFI_PHYSICAL_ADDRESS TopOfAddressSpace;
+
ASSERT (VirtualMemoryMap != NULL);
+ TopOfAddressSpace = LShiftU64 (1ULL, ArmGetPhysicalAddressBits ());
+
//
// Map the entire physical memory space as cached. The only device
// we care about is the GIC, which will be stage 2 mapped as a device
@@ -51,7 +50,7 @@ ArmVirtGetMemoryMap (
//
mVirtualMemoryTable[0].PhysicalBase = 0x0;
mVirtualMemoryTable[0].VirtualBase = 0x0;
- mVirtualMemoryTable[0].Length = ArmGetPhysAddrTop ();
+ mVirtualMemoryTable[0].Length = TopOfAddressSpace;
mVirtualMemoryTable[0].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
mVirtualMemoryTable[1].PhysicalBase = 0x0;
diff --git a/ArmVirtPkg/Library/XenVirtMemInfoLib/AArch64/PhysAddrTop.S
b/ArmVirtPkg/Library/XenVirtMemInfoLib/AArch64/PhysAddrTop.S
deleted file mode 100644
index a1f6a194d59b..
--- a/ArmVirtPkg/Library/XenVirtMemInfoLib/AArch64/PhysAddrTop.S
+++ /dev/null
@@ -1,39 +0,0 @@
-#
-# Copyright (c) 2011-2013, ARM Limited. All rights reserved.
-# Copyright (c) 2016-2017, Linaro Limited. All rights reserved.
-#
-# This program and the accompanying materials
-# are licensed and made available under the terms and conditions of the BSD
License
-# which accompanies this distribution. The full text of the license may be
found at
-# http://opensource.org/licenses/bsd-license.php
-#
-# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
-#
-#
-
-#include
-
-//EFI_PHYSICAL_ADDRESS
-//GetPhysAddrTop (
-// VOID
-// );
-ASM_FUNC(ArmGetPhysAddrTop)
- mrs x0, id_aa64mmfr0_el1
- adr x1, .LPARanges
- and x0, x0, #7
- ldrb w1, [x1, x0]
- mov x0, #1
- lsl x0, x0, x1
- ret
-
-//
-// Bits 0..2 of the AA64MFR0_EL1 system register encode the size of the
-// physical address space support on this CPU:
-// 0 == 32 bits, 1 == 36 bits, etc etc
-// 6 and 7 are reserved
-//
-.LPARanges:
- .byte 32, 36, 40, 42, 44, 48, -1, -1
-
-ASM_FUNCTION_REMOVE_IF_UNREFERENCED
diff --git a/ArmVirtPkg/Library/XenVirtMemInfoLib/Arm/PhysAddrTop.S
b/ArmVirtPkg/Library/XenVirtMemInfoLib/Arm/PhysAddrTop.S
deleted file mode 100644
index 9cd81529fb3d..
--- a/ArmVirtPkg/Library/XenVirtMemInfoLib/Arm/PhysAddrTop.S
+++ /dev/null
@@ -1,24 +0,0 @@
-#
-# Copyright (c) 2011-2013, ARM Limited. All rights reserved.
-# Copyright (c) 2014-2017, Linaro Limited. All rights reserved.
-#
-# This program and the accompanying materials
-# are licensed and made available under the terms and conditions of the BSD
License
-# which accompanies this distribution. The full text of the license may be
found at
-# http://opensource.org/licenses/bsd-license.php
-#
-# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
-#
-#
-
-#include
-
-//EFI_PHYSICAL_ADDRESS
-//GetPhysAddrTop (
-// VOID
-// );
-ASM_FUNC(ArmGetPhysAddrTop)
- mov r0, #0x
- mov r1, #0x1
- bxlr
--
2.19.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3 04/16] ArmVirtPkg/QemuVirtMemInfoLib: remove 1:1 mapping of top of PA range
Currently, we map DRAM as EFI_MEMORY_WB, and the remainder of the
entire virtual address space is mapped with EFI_MEMORY_UC attributes,
regardless of whether any devices actually reside there.
Now that we are relaxing the address space limit to more than 40 bits,
mapping all that address space actually takes up more space in page
tables than we have so far made available as temporary RAM. So let's
get rid of the mapping rather than increasing the available RAM, given
that the mapping is not particularly useful anyway.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf| 7
ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf | 7
ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c | 25
+++--
ArmVirtPkg/Library/QemuVirtMemInfoLib/AArch64/PhysAddrTop.S | 39
ArmVirtPkg/Library/QemuVirtMemInfoLib/Arm/PhysAddrTop.S | 24
5 files changed, 5 insertions(+), 97 deletions(-)
diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf
b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf
index c72a97f9e78a..5c5b841051ad 100644
--- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf
+++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf
@@ -24,12 +24,6 @@ [Defines]
[Sources]
QemuVirtMemInfoLib.c
-[Sources.ARM]
- Arm/PhysAddrTop.S
-
-[Sources.AARCH64]
- AArch64/PhysAddrTop.S
-
[Packages]
ArmPkg/ArmPkg.dec
ArmVirtPkg/ArmVirtPkg.dec
@@ -51,4 +45,3 @@ [Pcd]
[FixedPcd]
gArmTokenSpaceGuid.PcdFdSize
- gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize
diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
index e4032d3efb53..d12089760b22 100644
--- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
+++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
@@ -26,12 +26,6 @@ [Sources]
QemuVirtMemInfoLib.c
QemuVirtMemInfoPeiLibConstructor.c
-[Sources.ARM]
- Arm/PhysAddrTop.S
-
-[Sources.AARCH64]
- AArch64/PhysAddrTop.S
-
[Packages]
ArmPkg/ArmPkg.dec
ArmVirtPkg/ArmVirtPkg.dec
@@ -55,4 +49,3 @@ [Pcd]
[FixedPcd]
gArmTokenSpaceGuid.PcdFdSize
gArmVirtTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress
- gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize
diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
index 760bcc169cf4..0285a11b1d77 100644
--- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
+++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
@@ -21,11 +21,6 @@
// Number of Virtual Memory Map Descriptors
#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS 5
-EFI_PHYSICAL_ADDRESS
-ArmGetPhysAddrTop (
- VOID
- );
-
/**
Return the Virtual Memory Map of your platform
@@ -45,7 +40,6 @@ ArmVirtGetMemoryMap (
)
{
ARM_MEMORY_REGION_DESCRIPTOR *VirtualMemoryTable;
- UINT64TopOfMemory;
ASSERT (VirtualMemoryMap != NULL);
@@ -78,23 +72,14 @@ ArmVirtGetMemoryMap (
VirtualMemoryTable[1].Length = VirtualMemoryTable[0].PhysicalBase;
VirtualMemoryTable[1].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
- // Peripheral space after DRAM
- TopOfMemory = MIN (1ULL << FixedPcdGet8 (PcdPrePiCpuMemorySize),
- ArmGetPhysAddrTop ());
- VirtualMemoryTable[2].PhysicalBase = VirtualMemoryTable[0].Length +
VirtualMemoryTable[1].Length;
- VirtualMemoryTable[2].VirtualBase = VirtualMemoryTable[2].PhysicalBase;
- VirtualMemoryTable[2].Length = TopOfMemory -
- VirtualMemoryTable[2].PhysicalBase;
- VirtualMemoryTable[2].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
-
// Remap the FD region as normal executable memory
- VirtualMemoryTable[3].PhysicalBase = PcdGet64 (PcdFdBaseAddress);
- VirtualMemoryTable[3].VirtualBase = VirtualMemoryTable[3].PhysicalBase;
- VirtualMemoryTable[3].Length = FixedPcdGet32 (PcdFdSize);
- VirtualMemoryTable[3].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
+ VirtualMemoryTable[2].PhysicalBase = PcdGet64 (PcdFdBaseAddress);
+ VirtualMemoryTable[2].VirtualBase = VirtualMemoryTable[2].PhysicalBase;
+ VirtualMemoryTable[2].Length = FixedPcdGet32 (PcdFdSize);
+ VirtualMemoryTable[2].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
// End of Table
- ZeroMem ([4], sizeof (ARM_MEMORY_REGION_DESCRIPTOR));
+ ZeroMem ([3], sizeof (ARM_MEMORY_REGION_DESCRIPTOR));
*VirtualMemoryMap = VirtualMemoryTable;
}
diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/AArch64/PhysAddrTop.S
b/ArmVirtPkg/Library/QemuVirtMemInfoLib/AArch64/PhysAddrTop.S
deleted file mode 100644
index a1f6a194d59b..
---
[edk2] [PATCH v3 05/16] MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits
AArch64 supports the use of more than 48 bits for physical and/or virtual addressing, but only if the page size is set to 64 KB, which is not supported by UEFI. So redefine MAX_ADDRESS to cover only 48 address bits. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm --- MdePkg/Include/AArch64/ProcessorBind.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MdePkg/Include/AArch64/ProcessorBind.h b/MdePkg/Include/AArch64/ProcessorBind.h index 968c18f915ae..dad75df1c579 100644 --- a/MdePkg/Include/AArch64/ProcessorBind.h +++ b/MdePkg/Include/AArch64/ProcessorBind.h @@ -138,9 +138,9 @@ typedef INT64 INTN; #define MAX_2_BITS 0xC000ULL /// -/// Maximum legal AARCH64 address +/// Maximum legal AARCH64 address (48 bits for 4 KB page size) /// -#define MAX_ADDRESS 0xULL +#define MAX_ADDRESS 0xULL /// /// Maximum legal AArch64 INTN and UINTN values. -- 2.19.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3 10/16] ArmPlatformPkg/PrePi: base GCD memory space size on CPU's PA range
Derive the size of the GCD memory space map directly from the CPU's
information registers rather than from the PcdPrePiCpuMemorySize PCD,
which will be removed.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
ArmPlatformPkg/PrePi/PeiMPCore.inf | 1 -
ArmPlatformPkg/PrePi/PeiUniCore.inf | 1 -
ArmPlatformPkg/PrePi/PrePi.c| 2 +-
3 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/ArmPlatformPkg/PrePi/PeiMPCore.inf
b/ArmPlatformPkg/PrePi/PeiMPCore.inf
index 242b03175536..7e2ad6fc483d 100644
--- a/ArmPlatformPkg/PrePi/PeiMPCore.inf
+++ b/ArmPlatformPkg/PrePi/PeiMPCore.inf
@@ -97,7 +97,6 @@ [FixedPcd]
gArmPlatformTokenSpaceGuid.PcdCoreCount
- gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize
gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize
gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory
diff --git a/ArmPlatformPkg/PrePi/PeiUniCore.inf
b/ArmPlatformPkg/PrePi/PeiUniCore.inf
index a45cdef4ed91..26328b7e8f67 100644
--- a/ArmPlatformPkg/PrePi/PeiUniCore.inf
+++ b/ArmPlatformPkg/PrePi/PeiUniCore.inf
@@ -90,7 +90,6 @@ [FixedPcd]
gArmPlatformTokenSpaceGuid.PcdCoreCount
- gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize
gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize
gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory
diff --git a/ArmPlatformPkg/PrePi/PrePi.c b/ArmPlatformPkg/PrePi/PrePi.c
index 02cff7ddc204..245bdded1eb3 100644
--- a/ArmPlatformPkg/PrePi/PrePi.c
+++ b/ArmPlatformPkg/PrePi/PrePi.c
@@ -115,7 +115,7 @@ PrePiMain (
BuildStackHob (StacksBase, StacksSize);
//TODO: Call CpuPei as a library
- BuildCpuHob (PcdGet8 (PcdPrePiCpuMemorySize), PcdGet8 (PcdPrePiCpuIoSize));
+ BuildCpuHob (ArmGetPhysicalAddressBits (), PcdGet8 (PcdPrePiCpuIoSize));
if (ArmIsMpCore ()) {
// Only MP Core platform need to produce gArmMpCoreInfoPpiGuid
--
2.19.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3 09/16] ArmPkg/CpuPei: base GCD memory space size on CPU's PA range
Derive the size of the GCD memory space map directly from the CPU's information registers rather than from the PcdPrePiCpuMemorySize PCD, which will be removed. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- ArmPkg/Drivers/CpuPei/CpuPei.inf | 1 - ArmPkg/Drivers/CpuPei/CpuPei.c | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/ArmPkg/Drivers/CpuPei/CpuPei.inf b/ArmPkg/Drivers/CpuPei/CpuPei.inf index eafccd600983..dcea012fd8f9 100644 --- a/ArmPkg/Drivers/CpuPei/CpuPei.inf +++ b/ArmPkg/Drivers/CpuPei/CpuPei.inf @@ -50,7 +50,6 @@ [Guids] gArmMpCoreInfoGuid [FixedPcd] - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize [Depex] diff --git a/ArmPkg/Drivers/CpuPei/CpuPei.c b/ArmPkg/Drivers/CpuPei/CpuPei.c index d54f42acfcc8..e63519ff6481 100644 --- a/ArmPkg/Drivers/CpuPei/CpuPei.c +++ b/ArmPkg/Drivers/CpuPei/CpuPei.c @@ -73,7 +73,7 @@ InitializeCpuPeim ( ArmEnableBranchPrediction (); // Publish the CPU memory and io spaces sizes - BuildCpuHob (PcdGet8 (PcdPrePiCpuMemorySize), PcdGet8 (PcdPrePiCpuIoSize)); + BuildCpuHob (ArmGetPhysicalAddressBits (), PcdGet8 (PcdPrePiCpuIoSize)); // Only MP Core platform need to produce gArmMpCoreInfoPpiGuid Status = PeiServicesLocatePpi (, 0, NULL, (VOID**)); -- 2.19.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3 00/16] [Arm|ArmVirt|MdePkg|Embedded]Pkg: lift 40-bit IPA space limit
This v3 subsumes and/or supersedes [PATCH v2 00/13] ArmPkg, ArmVirtPkg: lift 40-bit IPA space limit [PATCH] MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits [PATCH v2 0/2] ArmVirtPkg: remove high peripheral space mapping The ArmVirtQemu targets currently limit the size of the IPA space to 40 bits because that is all what KVM supports. However, this is about to change, and so we need to update the code if we want to ensure that our UEFI firmware builds can keep running on systems that set values other than 40 (which could be > 40 or < 40) This series refactors how we handle the maximum size of the physical address space supported by the CPU in relation with the size of UEFI's 1:1 mapping and the size of the GCD memory space map, taking the following observations into account: - the range of the linear mapping can be tied to whatever the CPU supports (as long as it doesn't exceed what the architecture permits for 4k pages) since we mostly already use the maximum of 4 levels anyway, and there is no memory cost involved beyond that - there is usually no point in mapping the entire address space, which does involve a memory cost - the GCD memory space may be required to cover more than what UEFI can address itself, since it is the based for the UEFI memory map that is provided to the OS Patches #1 and #2 remove some unused code to avoid having to fix it. Patches #3 and #4 update ArmVirtQemu and ArmVirtQemuKernel to drop the high peripheral space mapping, and map whatever may reside there explicitly (currently only the ECAM space in practice, but the MMIO view of the PCI I/O space is mapped explicitly as well) Patch #5 was sent out before individually, and sets MAX_ADDRESS to the maximum value AArch64 can map in UEFI which runs with 4k pages. Patch #6 adds a helper to ArmLib to read the number of supported address bits and take this into account in the page table code (#8), which allows PcdPrePiCpuMemorySize to assume a value that exceeds the capabilities of the CPU. Patch #7 is mostly a cleanup patch, to switch to the new helper added in patch #6. No functional changes intended. Patches #9 to #12 modify building of the CPU hob (and thus the size of the GCD memory space) based on the CPU capabilities rather than the value of PcdPrePiCpuMemorySize, which is dropped in the last patch. Pacthes #13 and #14 remove some needless references to PcdPrePiCpuMemorySize Patch #15 drops the overrides of PcdPrePiCpuMemorySize from all ArmVirtPkg platforms. Cc: Laszlo Ersek Cc: Leif Lindholm Cc: Eric Auger Cc: Andrew Jones Cc: Philippe Mathieu-Daude Cc: Julien Grall Ard Biesheuvel (16): EmbeddedPkg/TemplateSec: remove unused module EmbeddedPkg/PrePiHobLib: drop CreateHobList() from library ArmVirtPkg/FdtPciHostBridgeLib: map ECAM and I/O spaces in GCD memory map ArmVirtPkg/QemuVirtMemInfoLib: remove 1:1 mapping of top of PA range MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits ArmPkg/ArmLib: add support for reading the max physical address space size ArmVirtPkg/XenVirtMemInfoLib: refactor reading of the PA space size ArmPkg/ArmMmuLib: take the CPU supported maximum PA space into account ArmPkg/CpuPei: base GCD memory space size on CPU's PA range ArmPlatformPkg/PrePi: base GCD memory space size on CPU's PA range ArmVirtPkg/PrePi: base GCD memory space size on CPU's PA range BeagleBoardPkg/PrePi: base GCD memory space size on CPU's PA range ArmPlatformPkg/PlatformPei: drop unused PCD references EmbeddedPkg/PrePiLib: drop unused PCD reference ArmVirtPkg: drop PcdPrePiCpuMemorySize assignments from all platforms EmbeddedPkg/EmbeddedPkg.dec: drop PcdPrePiCpuMemorySize declarations EmbeddedPkg/EmbeddedPkg.dec | 4 - ArmVirtPkg/ArmVirt.dsc.inc| 3 - ArmVirtPkg/ArmVirtQemu.dsc| 4 - ArmVirtPkg/ArmVirtQemuKernel.dsc | 4 - ArmPkg/Drivers/CpuPei/CpuPei.inf | 1 - ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf| 3 - ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf | 3 - ArmPlatformPkg/PlatformPei/PlatformPeiLib.inf | 3 - ArmPlatformPkg/PlatformPei/PlatformPeim.inf | 3 - ArmPlatformPkg/PrePi/PeiMPCore.inf| 1 - ArmPlatformPkg/PrePi/PeiUniCore.inf | 1 - .../FdtPciHostBridgeLib.inf | 1 + .../QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf | 7 -- .../QemuVirtMemInfoPeiLib.inf | 7 -- .../XenVirtMemInfoLib/XenVirtMemInfoLib.inf | 6 -- .../PrePi/ArmVirtPrePiUniCoreRelocatable.inf | 1 - BeagleBoardPkg/PrePi/PeiUniCore.inf | 1 - EmbeddedPkg/Library/PrePiLib/PrePiLib.inf | 1 - EmbeddedPkg/TemplateSec/TemplateSec.inf | 65 ArmPkg/Include/Library/ArmLib.h | 6 ++ EmbeddedPkg/Include/Library/PrePiLib.h| 18 - MdePkg/Include/AArch64/ProcessorBind.h| 4 +- ArmPkg/Drivers/CpuPei/CpuPei.c| 2 +-
[edk2] [PATCH v3 03/16] ArmVirtPkg/FdtPciHostBridgeLib: map ECAM and I/O spaces in GCD memory map
Up until now, we have been getting away with not declaring the ECAM
and translated I/O spaces at all in the GCD memory map, simply because
we map the entire address space with device attributes in the early PEI
code, and so the ECAM space will be mapped wherever it ends up.
Now that we are about to make changes to how ArmVirtQemu reasons
about the size of the address space, it would be better to get rid
of this mapping of the entire address space, since it can get
arbitrarily large without real benefit.
So start by mapping the ECAM and translated I/O spaces explicitly,
instead of relying on the early PEI mapping.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Laszlo Ersek
---
ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf | 1 +
ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c | 46
+++-
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
index 0995f4b7a156..4011336a353b 100644
--- a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
+++ b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
@@ -42,6 +42,7 @@ [Packages]
[LibraryClasses]
DebugLib
DevicePathLib
+ DxeServicesTableLib
MemoryAllocationLib
PciPcdProducerLib
diff --git a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
index 5b9c887db35d..ebfa14a349f4 100644
--- a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
+++ b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -82,6 +83,33 @@ typedef struct {
#define DTB_PCI_HOST_RANGE_IO BIT24
#define DTB_PCI_HOST_RANGE_TYPEMASK (BIT31 | BIT30 | BIT29 | BIT25 | BIT24)
+STATIC
+EFI_STATUS
+MapGcdMmioSpace (
+ INUINT64Base,
+ INUINT64Size
+ )
+{
+ EFI_STATUSStatus;
+
+ Status = gDS->AddMemorySpace (EfiGcdMemoryTypeMemoryMappedIo, Base, Size,
+ EFI_MEMORY_UC);
+ if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR,
+ "%a: failed to add GCD memory space for region [0x%Lx+0x%Lx)\n",
+ __FUNCTION__, Base, Size));
+return Status;
+ }
+
+ Status = gDS->SetMemorySpaceAttributes (Base, Size, EFI_MEMORY_UC);
+ if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR,
+ "%a: failed to set memory space attributes for region [0x%Lx+0x%Lx)\n",
+ __FUNCTION__, Base, Size));
+ }
+ return Status;
+}
+
STATIC
EFI_STATUS
ProcessPciHost (
@@ -266,7 +294,23 @@ ProcessPciHost (
"Io[0x%Lx+0x%Lx)@0x%Lx Mem32[0x%Lx+0x%Lx)@0x0 Mem64[0x%Lx+0x%Lx)@0x0\n",
__FUNCTION__, ConfigBase, ConfigSize, *BusMin, *BusMax, *IoBase, *IoSize,
IoTranslation, *Mmio32Base, *Mmio32Size, *Mmio64Base, *Mmio64Size));
- return EFI_SUCCESS;
+
+ // Map the ECAM space in the GCD memory map
+ Status = MapGcdMmioSpace (ConfigBase, ConfigSize);
+ ASSERT_EFI_ERROR (Status);
+ if (EFI_ERROR (Status)) {
+return Status;
+ }
+
+ //
+ // Map the MMIO window that provides I/O access - the PCI host bridge code
+ // is not aware of this translation and so it will only map the I/O view
+ // in the GCD I/O map.
+ //
+ Status = MapGcdMmioSpace (*IoBase + IoTranslation, *IoSize);
+ ASSERT_EFI_ERROR (Status);
+
+ return Status;
}
STATIC PCI_ROOT_BRIDGE mRootBridge;
--
2.19.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3 01/16] EmbeddedPkg/TemplateSec: remove unused module
Remove this module: it is unused, and should not be used as an
example going forward.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
EmbeddedPkg/TemplateSec/TemplateSec.inf | 65 -
EmbeddedPkg/TemplateSec/TemplateSec.c | 76
2 files changed, 141 deletions(-)
diff --git a/EmbeddedPkg/TemplateSec/TemplateSec.inf
b/EmbeddedPkg/TemplateSec/TemplateSec.inf
deleted file mode 100644
index 3a63e59294d3..
--- a/EmbeddedPkg/TemplateSec/TemplateSec.inf
+++ /dev/null
@@ -1,65 +0,0 @@
-#/** @file
-#
-#Component description file for DxeIpl module
-#
-# The responsibility of this module is to load the DXE Core from a Firmware
Volume. This implementation i used to load a 32-bit DXE Core.
-#
-# Copyright (c) 2006 - 2008, 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 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.
-#
-#**/
-
-[Defines]
- INF_VERSION= 0x00010005
- BASE_NAME = TemplateSec
- FILE_GUID = 1D6F730F-5A55-4078-869B-E0A18324BDC8
- MODULE_TYPE= SEC
- VERSION_STRING = 1.0
-
-
-#
-# The following information is for reference only and not required by the
build tools.
-#
-# VALID_ARCHITECTURES = IA32 X64 ARM
-#
-
-[Sources.common]
- TemplateSec.c
-
-[Sources.Ia32]
-# Ia32/ResetVector.asm | MSFT
-# Ia32/ResetVector.S | GCC
-
-[Sources.X64]
-# X64/ResetVector.asm | MSFT
-# X64/ResetVector.S | GCC
-
-[Sources.ARM]
-# Arm/ResetVector.asm | RVCT
-# Arm/ResetVector.S | GCC
-
-[Packages]
- MdePkg/MdePkg.dec
- MdeModulePkg/MdeModulePkg.dec
- EmbeddedPkg/EmbeddedPkg.dec
-
-
-[LibraryClasses]
- BaseLib
- DebugLib
- BaseMemoryLib
- UefiDecompressLib
- PeCoffLib
- CacheMaintenanceLib
- PrePiLib
-
-[Pcd]
- gEmbeddedTokenSpaceGuid.PcdEmbeddedFdBaseAddress
- gEmbeddedTokenSpaceGuid.PcdEmbeddedFdSize
-
diff --git a/EmbeddedPkg/TemplateSec/TemplateSec.c
b/EmbeddedPkg/TemplateSec/TemplateSec.c
deleted file mode 100644
index c63adbb6f90f..
--- a/EmbeddedPkg/TemplateSec/TemplateSec.c
+++ /dev/null
@@ -1,76 +0,0 @@
-/** @file
-
- Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
-
- This program and the accompanying materials
- are licensed and made available under the terms and conditions of the BSD
License
- which accompanies this distribution. The full text of the license may be
found at
- http://opensource.org/licenses/bsd-license.php
-
- THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
- WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#include
-
-#include
-#include
-#include
-
-#include
-
-VOID
-_ModuleEntryPoint (
- VOID
- )
-{
-}
-
-VOID
-CEntryPoint (
- VOID*MemoryBase,
- UINTN MemorySize,
- VOID*StackBase,
- UINTN StackSize
- )
-{
- EFI_PHYSICAL_ADDRESS MemoryBegin;
- UINT64MemoryLength;
- VOID *HobBase;
-
- //
- // Boot strap the C environment so the other library services will work
properly.
- //
- MemoryBegin = (EFI_PHYSICAL_ADDRESS)(UINTN)MemoryBase;
- MemoryLength = (UINT64)MemorySize;
- HobBase = (VOID *)(UINTN)(FixedPcdGet32(PcdEmbeddedFdBaseAddress) +
FixedPcdGet32(PcdEmbeddedFdSize));
- CreateHobList (MemoryBase, MemorySize, HobBase, StackBase);
-
- MemoryBegin = (EFI_PHYSICAL_ADDRESS)(UINTN)StackBase;
- MemoryLength = (UINT64)StackSize;
- UpdateStackHob (MemoryBegin, MemoryLength);
-
- DEBUG ((DEBUG_ERROR, "CEntryPoint (%x,%x,%x,%x)\n", MemoryBase, MemorySize,
StackBase, StackSize));
-
- //
- // Add your C code stuff here
- //
-
-
- //
- // Load the DXE Core and transfer control to it
- //
-
- // Give the DXE Core access to our DEBUG and ASSERT infrastructure so this
will work prior
- // to the DXE version being loaded. Thus we close the debugging gap between
phases.
- AddDxeCoreReportStatusCodeCallback ();
-
- //BuildFvHobs (PcdBfvBase, PcdBfvSize, NULL);
-
- LoadDxeCoreFromFv (NULL, 0);
-
- // DXE Core should always load and never return
- ASSERT (FALSE);
-}
-
--
2.19.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] SecurityPkg: Remove dead code and inf redundant definitions.
Hi Chen Chen:
TCG part is good to me. For Opal part, please include Eric Dong as reviewer.
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Chen A
Chen
Sent: Wednesday, November 28, 2018 2:27 PM
To: edk2-devel@lists.01.org
Cc: Zhang, Chao B
Subject: [edk2] [PATCH] SecurityPkg: Remove dead code and inf redundant
definitions.
Fix BZ1065, https://bugzilla.tianocore.org/show_bug.cgi?id=1065
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chen A Chen
Cc: Zhang Chao B
---
SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf | 1 -
SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.c | 52
SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.h | 23 --
SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.h| 11 -
.../Tcg/Opal/OpalPassword/OpalHiiCallbacks.c | 87 --
SecurityPkg/Tcg/Opal/OpalPassword/OpalNvmeMode.c | 321 -
SecurityPkg/Tcg/Opal/OpalPassword/OpalNvmeMode.h | 128
.../Tcg/Opal/OpalPassword/OpalPasswordDxe.inf | 2 -
.../Tcg/Opal/OpalPassword/OpalPasswordPei.inf | 1 -
SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf | 1 -
SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf| 1 -
SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf| 1 -
SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDxe.inf | 1 -
.../SecureBootConfigDxe/SecureBootConfigDxe.inf| 2 -
14 files changed, 632 deletions(-)
diff --git a/SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf
b/SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf
index 6f9a77b868..a17fa4046d 100644
--- a/SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf
+++ b/SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf
@@ -43,7 +43,6 @@
UefiDriverEntryPoint
UefiBootServicesTableLib
UefiRuntimeServicesTableLib
- ReportStatusCodeLib
DebugLib
UefiLib
MemoryAllocationLib
diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.c
b/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.c
index d51865380f..0c4edd5346 100644
--- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.c
+++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.c
@@ -969,58 +969,6 @@ AhciReset (
}
-/**
- Send Buffer cmd to specific device.
-
- @param[in] AhciContext The pointer to the AHCI_CONTEXT.
- @param[in] PortThe port number of attached ATA device.
- @param[in] PortMultiplier The port number of port multiplier of
attached ATA device.
- @param[in, out] Buffer The Data Buffer to store IDENTIFY PACKET
Data.
-
- @retval EFI_DEVICE_ERRORThe cmd abort with error occurs.
- @retval EFI_TIMEOUT The operation is time out.
- @retval EFI_UNSUPPORTED The device is not ready for executing.
- @retval EFI_SUCCESS The cmd executes successfully.
-
-**/
-EFI_STATUS
-EFIAPI
-AhciIdentify (
- IN AHCI_CONTEXT *AhciContext,
- IN UINT8Port,
- IN UINT8PortMultiplier,
- IN OUT ATA_IDENTIFY_DATA*Buffer
- )
-{
- EFI_STATUS Status;
- EFI_ATA_COMMAND_BLOCKAtaCommandBlock;
-
- if (AhciContext == NULL || Buffer == NULL) {
-return EFI_INVALID_PARAMETER;
- }
-
- ZeroMem (, sizeof (EFI_ATA_COMMAND_BLOCK));
-
- AtaCommandBlock.AtaCommand = ATA_CMD_IDENTIFY_DRIVE;
- AtaCommandBlock.AtaSectorCount = 1;
-
- Status = AhciPioTransfer (
- AhciContext,
- Port,
- PortMultiplier,
- NULL,
- 0,
- TRUE,
- ,
- NULL,
- Buffer,
- sizeof (ATA_IDENTIFY_DATA),
- ATA_TIMEOUT
- );
-
- return Status;
-}
-
/**
Allocate transfer-related data struct which is used at AHCI mode.
diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.h
b/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.h
index 037f81ac24..2076b0411b 100644
--- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.h
+++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.h
@@ -293,29 +293,6 @@ typedef struct {
UINT32AhciBar;
} AHCI_CONTEXT;
-/**
- Send Buffer cmd to specific device.
-
- @param AhciContext The pointer to the AHCI_CONTEXT.
- @param PortThe number of port.
- @param PortMultiplier The timeout Value of stop.
- @param Buffer The Data Buffer to store IDENTIFY PACKET Data.
-
- @retval EFI_DEVICE_ERRORThe cmd abort with error occurs.
- @retval EFI_TIMEOUT The operation is time out.
- @retval EFI_UNSUPPORTED The device is not ready for executing.
- @retval EFI_SUCCESS The cmd executes successfully.
-
-**/
-EFI_STATUS
-EFIAPI
-AhciIdentify (
- IN AHCI_CONTEXT *AhciContext,
- IN UINT8Port,
- IN UINT8PortMultiplier,
- IN OUT ATA_IDENTIFY_DATA*Buffer
- );
-
/**
Allocate transfer-related data struct which is used at AHCI mode.
diff --git
[edk2] [Patch v2] Maintainers.txt: Add the rule to hand over the package maintain role
In V2, change his to the, and add new maintainers follow up. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao --- Maintainers.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Maintainers.txt b/Maintainers.txt index 91a4657adc..e102114c34 100644 --- a/Maintainers.txt +++ b/Maintainers.txt @@ -6,7 +6,10 @@ EDK II. In general, you should not privately email the maintainer. You should email the edk2-devel list, and Cc the package maintainers and -reviewers. +reviewers. If the package maintainer wants to hand over the role to +other people, the package maintainer should send the patch to update +Maintainers.txt with new maintainer, and the new maintainer should +follow up with an Acked-by or a Reviewed-by. Descriptions of section entries: -- 2.13.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] Vlv2TbltDevicePkg: ECP Cleanup.
Great work! After this update, there is no platform to consume
EdkCompatibilityPkg. We can finally remove EdkCompatibilityPkg it from edk2
trunk.
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of zwei4
> Sent: Wednesday, November 28, 2018 9:38 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Wei, David
> ; Qian, Yi
> Subject: [edk2] [Patch] Vlv2TbltDevicePkg: ECP Cleanup.
>
> Remove modules of EdkCompatibilityPkg from DSC/FDF of Vlv2TbltDevicePkg to
> make this platform ECP free.
>
> Test: Boot to 64-bit Windows 10.
>
> Cc: Zailiang Sun
> Cc: Yi Qian
> Cc: Michael Kinney
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: David Wei
> ---
> Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c | 8 +-
> Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.inf| 4 +-
> Vlv2TbltDevicePkg/PciPlatform/PciPlatform.c| 8 +-
> Vlv2TbltDevicePkg/PciPlatform/PciPlatform.inf | 4 +-
> Vlv2TbltDevicePkg/PlatformPei/BootMode.c | 56 +
> Vlv2TbltDevicePkg/PlatformPei/PlatformPei.inf | 4 +-
> Vlv2TbltDevicePkg/PlatformPkg.fdf | 11 +--
> Vlv2TbltDevicePkg/PlatformPkgGcc.fdf | 10 ---
> Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc| 87 -
> Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 91
> +-
> Vlv2TbltDevicePkg/PlatformPkgX64.dsc | 87 -
> Vlv2TbltDevicePkg/PlatformSmm/PlatformSmm.inf | 6 +-
> Vlv2TbltDevicePkg/VlvPlatformInitDxe/IgdOpRegion.c | 10 +--
> .../VlvPlatformInitDxe/VlvPlatformInitDxe.inf | 6 +-
> 14 files changed, 30 insertions(+), 362 deletions(-)
>
> diff --git a/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
> b/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
> index 4a913eb723..d575533319 100644
> --- a/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
> +++ b/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
> @@ -1,6 +1,6 @@
> /** @file
>
> - Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
> + Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
>
>
>This program and the accompanying materials are licensed and made
> available under
> @@ -35,7 +35,7 @@ Abstract:
>
> #include
> #include
> -#include
> +#include
> #include "AcpiPlatform.h"
> #include "AcpiPlatformHooks.h"
> #include "AcpiPlatformHooksLib.h"
> @@ -785,7 +785,7 @@ AcpiPlatformEntryPoint (
>EFI_STATUSStatus;
>EFI_STATUSAcpiStatus;
>EFI_ACPI_SUPPORT_PROTOCOL *AcpiSupport;
> - EFI_FIRMWARE_VOLUME_PROTOCOL *FwVol;
> + EFI_FIRMWARE_VOLUME2_PROTOCOL *FwVol;
>INTN Instance;
>EFI_ACPI_COMMON_HEADER*CurrentTable;
>UINTN TableHandle;
> @@ -856,7 +856,7 @@ AcpiPlatformEntryPoint (
>//
>// Locate the firmware volume protocol.
>//
> - Status = LocateSupportProtocol (, (VOID **)
> , 1);
> + Status = LocateSupportProtocol (, (VOID
> **) , 1);
>ASSERT_EFI_ERROR (Status);
>
>//
> diff --git a/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.inf
> b/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.inf
> index 24fa913b33..74a531369d 100644
> --- a/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.inf
> +++ b/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.inf
> @@ -1,6 +1,6 @@
> #
> #
> -# Copyright (c) 1999 - 2014, Intel Corporation. All rights reserved
> +# Copyright (c) 1999 - 2018, 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 that accompanies this
> distribution.
>
> @@ -77,7 +77,7 @@
>gEfiMpServiceProtocolGuid
>gEfiGlobalNvsAreaProtocolGuid
>gEfiTcgProtocolGuid
> - gEfiFirmwareVolumeProtocolGuid
> + gEfiFirmwareVolume2ProtocolGuid
>gIgdOpRegionProtocolGuid
>
> [Pcd]
> diff --git a/Vlv2TbltDevicePkg/PciPlatform/PciPlatform.c
> b/Vlv2TbltDevicePkg/PciPlatform/PciPlatform.c
> index 08f5df2a25..27ae9de7a0 100644
> --- a/Vlv2TbltDevicePkg/PciPlatform/PciPlatform.c
> +++ b/Vlv2TbltDevicePkg/PciPlatform/PciPlatform.c
> @@ -36,7 +36,7 @@ Abstract:
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
>
> @@ -66,12 +66,12 @@ GetRawImage (
>EFI_HANDLE*HandleBuffer;
>UINTN HandleCount;
>UINTN Index;
> - EFI_FIRMWARE_VOLUME_PROTOCOL *Fv;
> + EFI_FIRMWARE_VOLUME2_PROTOCOL *Fv;
>UINT32AuthenticationStatus;
>
>Status = gBS->LocateHandleBuffer (
>ByProtocol,
> - ,
> + ,
>NULL,
>,
>
> @@ -86,7 +86,7 @@ GetRawImage (
>for (Index = 0; Index < HandleCount; Index++) {
> Status =
[edk2] [Patch] Vlv2TbltDevicePkg: ECP Cleanup.
Remove modules of EdkCompatibilityPkg from DSC/FDF of Vlv2TbltDevicePkg to make
this platform ECP free.
Test: Boot to 64-bit Windows 10.
Cc: Zailiang Sun
Cc: Yi Qian
Cc: Michael Kinney
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: David Wei
---
Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c | 8 +-
Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.inf| 4 +-
Vlv2TbltDevicePkg/PciPlatform/PciPlatform.c| 8 +-
Vlv2TbltDevicePkg/PciPlatform/PciPlatform.inf | 4 +-
Vlv2TbltDevicePkg/PlatformPei/BootMode.c | 56 +
Vlv2TbltDevicePkg/PlatformPei/PlatformPei.inf | 4 +-
Vlv2TbltDevicePkg/PlatformPkg.fdf | 11 +--
Vlv2TbltDevicePkg/PlatformPkgGcc.fdf | 10 ---
Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc| 87 -
Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 91 +-
Vlv2TbltDevicePkg/PlatformPkgX64.dsc | 87 -
Vlv2TbltDevicePkg/PlatformSmm/PlatformSmm.inf | 6 +-
Vlv2TbltDevicePkg/VlvPlatformInitDxe/IgdOpRegion.c | 10 +--
.../VlvPlatformInitDxe/VlvPlatformInitDxe.inf | 6 +-
14 files changed, 30 insertions(+), 362 deletions(-)
diff --git a/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
b/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
index 4a913eb723..d575533319 100644
--- a/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
+++ b/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
@@ -1,6 +1,6 @@
/** @file
- Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
+ Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
This program and the accompanying materials are licensed and made available
under
@@ -35,7 +35,7 @@ Abstract:
#include
#include
-#include
+#include
#include "AcpiPlatform.h"
#include "AcpiPlatformHooks.h"
#include "AcpiPlatformHooksLib.h"
@@ -785,7 +785,7 @@ AcpiPlatformEntryPoint (
EFI_STATUSStatus;
EFI_STATUSAcpiStatus;
EFI_ACPI_SUPPORT_PROTOCOL *AcpiSupport;
- EFI_FIRMWARE_VOLUME_PROTOCOL *FwVol;
+ EFI_FIRMWARE_VOLUME2_PROTOCOL *FwVol;
INTN Instance;
EFI_ACPI_COMMON_HEADER*CurrentTable;
UINTN TableHandle;
@@ -856,7 +856,7 @@ AcpiPlatformEntryPoint (
//
// Locate the firmware volume protocol.
//
- Status = LocateSupportProtocol (, (VOID **)
, 1);
+ Status = LocateSupportProtocol (, (VOID **)
, 1);
ASSERT_EFI_ERROR (Status);
//
diff --git a/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.inf
b/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.inf
index 24fa913b33..74a531369d 100644
--- a/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.inf
+++ b/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.inf
@@ -1,6 +1,6 @@
#
#
-# Copyright (c) 1999 - 2014, Intel Corporation. All rights reserved
+# Copyright (c) 1999 - 2018, 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 that accompanies this
distribution.
@@ -77,7 +77,7 @@
gEfiMpServiceProtocolGuid
gEfiGlobalNvsAreaProtocolGuid
gEfiTcgProtocolGuid
- gEfiFirmwareVolumeProtocolGuid
+ gEfiFirmwareVolume2ProtocolGuid
gIgdOpRegionProtocolGuid
[Pcd]
diff --git a/Vlv2TbltDevicePkg/PciPlatform/PciPlatform.c
b/Vlv2TbltDevicePkg/PciPlatform/PciPlatform.c
index 08f5df2a25..27ae9de7a0 100644
--- a/Vlv2TbltDevicePkg/PciPlatform/PciPlatform.c
+++ b/Vlv2TbltDevicePkg/PciPlatform/PciPlatform.c
@@ -36,7 +36,7 @@ Abstract:
#include
#include
#include
-#include
+#include
#include
#include
@@ -66,12 +66,12 @@ GetRawImage (
EFI_HANDLE*HandleBuffer;
UINTN HandleCount;
UINTN Index;
- EFI_FIRMWARE_VOLUME_PROTOCOL *Fv;
+ EFI_FIRMWARE_VOLUME2_PROTOCOL *Fv;
UINT32AuthenticationStatus;
Status = gBS->LocateHandleBuffer (
ByProtocol,
- ,
+ ,
NULL,
,
@@ -86,7 +86,7 @@ GetRawImage (
for (Index = 0; Index < HandleCount; Index++) {
Status = gBS->HandleProtocol(
HandleBuffer[Index],
-,
+,
(VOID **)
);
diff --git a/Vlv2TbltDevicePkg/PciPlatform/PciPlatform.inf
b/Vlv2TbltDevicePkg/PciPlatform/PciPlatform.inf
index a296c24b75..ce3140f830 100644
--- a/Vlv2TbltDevicePkg/PciPlatform/PciPlatform.inf
+++ b/Vlv2TbltDevicePkg/PciPlatform/PciPlatform.inf
@@ -1,6 +1,6 @@
#/*++
#
-# Copyright (c) 2003 - 2014, Intel Corporation. All rights reserved
+# Copyright (c) 2003 - 2018, Intel Corporation. All rights reserved
#
Re: [edk2] [PATCH v2 2/2] ArmVirtPkg/QemuVirtMemInfoLib: remove 1:1 mapping of top of PA range
On 11/27/18 22:18, Ard Biesheuvel wrote: > On Tue, 27 Nov 2018 at 21:25, Laszlo Ersek wrote: >> >> On 11/27/18 18:52, Ard Biesheuvel wrote: >>> On Tue, 27 Nov 2018 at 18:26, Laszlo Ersek wrote: On 11/27/18 15:54, Ard Biesheuvel wrote: > Currently, we map DRAM as EFI_MEMORY_WB, and the remainder of the > entire virtual address space is mapped with EFI_MEMORY_UC attributes, > regardless of whether any devices actually reside there. > > Now that we are relaxing the address space limit to more than 40 bits, > mapping all that address space actually takes up more space in page > tables than we have so far made available as temporary RAM. So let's > get rid of the mapping rather than increasing the available RAM, given > that the mapping is not particularly useful anyway. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c | 17 > + > 1 file changed, 5 insertions(+), 12 deletions(-) > > diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c > b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c > index 815ca145b644..70863abb2e7b 100644 > --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c > +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c > @@ -73,21 +73,14 @@ ArmVirtGetMemoryMap ( >VirtualMemoryTable[1].Length = > VirtualMemoryTable[0].PhysicalBase; >VirtualMemoryTable[1].Attributes = > ARM_MEMORY_REGION_ATTRIBUTE_DEVICE; > > - // Peripheral space after DRAM > - VirtualMemoryTable[2].PhysicalBase = VirtualMemoryTable[0].Length + > VirtualMemoryTable[1].Length; > - VirtualMemoryTable[2].VirtualBase = > VirtualMemoryTable[2].PhysicalBase; > - VirtualMemoryTable[2].Length = TopOfAddressSpace - > - > VirtualMemoryTable[2].PhysicalBase; > - VirtualMemoryTable[2].Attributes = > ARM_MEMORY_REGION_ATTRIBUTE_DEVICE; > - >// Remap the FD region as normal executable memory > - VirtualMemoryTable[3].PhysicalBase = PcdGet64 (PcdFdBaseAddress); > - VirtualMemoryTable[3].VirtualBase = > VirtualMemoryTable[3].PhysicalBase; > - VirtualMemoryTable[3].Length = FixedPcdGet32 (PcdFdSize); > - VirtualMemoryTable[3].Attributes = > ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK; > + VirtualMemoryTable[2].PhysicalBase = PcdGet64 (PcdFdBaseAddress); > + VirtualMemoryTable[2].VirtualBase = > VirtualMemoryTable[2].PhysicalBase; > + VirtualMemoryTable[2].Length = FixedPcdGet32 (PcdFdSize); > + VirtualMemoryTable[2].Attributes = > ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK; > >// End of Table > - ZeroMem ([4], sizeof > (ARM_MEMORY_REGION_DESCRIPTOR)); > + ZeroMem ([3], sizeof > (ARM_MEMORY_REGION_DESCRIPTOR)); > >*VirtualMemoryMap = VirtualMemoryTable; > } > (1) This supplants your other series "[PATCH v2 00/13] ArmPkg, ArmVirtPkg: lift 40-bit IPA space limit" minimally due to a contextual conflict; is that right? >>> >>> Not quite. It complements it, in the sense that is should fix the >>> issue reported by Eric when mapping the entire address 48-bit address >>> space. >> >> Oh, you meant this one *on top* of that? In particular, on top of: >> >> [edk2] [PATCH v2 11/13] ArmVirtPkg/QemuVirtMemInfoLib: ignore >> PcdPrePiCpuMemorySize >> >> That wasn't clear to me, sorry. >> > > No, the other way around actually :-) How so? Patch v2 11/13 removes: > - VirtualMemoryTable[2].Length = TopOfMemory - and adds: > + VirtualMemoryTable[2].Length = TopOfAddressSpace - and in the current patch, you remove > - VirtualMemoryTable[2].Length = TopOfAddressSpace - So the current patch wouldn't apply before v2 11/13. Anyway, this is not so important :) > Apologies, I managed to confuse myself a bit as well, so I understand > this may be slightly difficult to follow. Yeah :) >> If this one comes on top of the v2 13-part series, do you ultimately >> need v2 11/13 as a separate patch -- in that form anyway? It seems that >> you could squash this patch into v2 11/13, and eliminate the dependency >> on PcdPrePiCpuMemorySize *by* killing the entry that maps the Peripheral >> space after DRAM. >> > > Indeed. So after applying these two patches, I will need to respin > that series once more, and now that I think of it, it might make sense > to simplify those changes signficantly, given that only the Xen code > needs to access the CPU's capability registers in the platform MMU > setup code. Thank you for explaining. I'll wait for the one and only v3 then. Thanks! Laszlo ___ edk2-devel mailing list
Re: [edk2] [Patch] Maintainers.txt: Add the rule to hand over the package maintain role
On 11/28/18 08:31, Liming Gao wrote: > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Liming Gao > --- > Maintainers.txt | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Maintainers.txt b/Maintainers.txt > index 91a4657adc..d75bbe278d 100644 > --- a/Maintainers.txt > +++ b/Maintainers.txt > @@ -6,7 +6,9 @@ EDK II. > > In general, you should not privately email the maintainer. You should > email the edk2-devel list, and Cc the package maintainers and > -reviewers. > +reviewers. If the package maintainer wants to hand over his role to > +other people, the package maintainer should send the patch to update > +Maintainers.txt with new maintainer. > > Descriptions of section entries: > > (1) Using "his" in the above context is grammatically correct English, as far as I know (note: I'm not a native speaker). However, given the TianoCore Code of Conduct at https://www.tianocore.org/coc.html I'm going to ask you to please replace "his" with "the". (2) Please append: "..., and the new maintainer should follow up with an Acked-by or a Reviewed-by". Thanks, Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-announce] Research Request
On 11/27/18 22:55, Brian J. Johnson wrote:
> On 11/27/18 6:53 AM, Laszlo Ersek wrote:
>> On 11/26/18 22:43, Jeremiah Cox via edk2-devel wrote:
>>> Feedback on GitHub as follows…
>>>
>>>
1. No Lock-In - What automated data export is available?
We want to be able to leave and take all our data with us. "Data" here
includes: review comments, pull requests / patches (including
metadata),
old (rejected) pull requests and metadata, issue tracker entries and
comments (if issue tracker included). This archiving should be
automated, not something we do by hand.
>>> Untested, but might these all be easily satisfied by subscribing a
>>> mailing list to GitHub notifications?
>>> https://help.github.com/articles/about-notifications/#watching-notifications
>>>
>>> https://help.github.com/articles/about-email-notifications/
>> No, they are insufficient.
>>
>> Following the last link above ("about-email-notifications"), one finds
>> several other links; and one of those is:
>>
>> https://help.github.com/articles/about-notifications/
>>
>> This article says,
>>
>> GitHub sends participating notifications when you're directly
>> involved in activities or conversations within a repository or a
>> team you're a member of. You'll receive a notification when:
>>
>> [...]
>>
>> - You open, comment on, or close an issue or pull request.
>>
>> [...]
>>
>> This is demonstrably false. I'm a member of the TianoCore organization,
>> I have commented on, and closed (rejected):
>>
>> https://github.com/tianocore/edk2/pull/133
>>
>> and I *never* received an email notification about my *own* comment /
>> action. I only received the initial email, about the pull request being
>> opened (attached for reference).
>
> Try going to the "Settings" item under the menu in the top-right corner,
> and clicking on the "Notifications" tab on the left. Under "Email
> notification preferences" there should be a checkbox for "Include your
> own updates". That may do what you need.
That did the trick. I checked the box and then went on to close PR#134.
I got two separate emails shortly after (attached), one about the
closure and another about the comment.
In my opinion, the default value for the setting in question is broken
(it should be "on" by default). However, to me anyway, it's a big plus
for GitHub that it actually supports this feature. If we are going to
adopt GitHub, then we can highlight the knob in our docs.
Regarding GitHub, what remains to be seen (for me) is if & how it
preserves old (unmerged) topic branches, and review comments made for
them, after the pull requestor rebases or deletes those branches in
his/her repo.
Can someone please send an artificial/test PR against my personal repo,
at ? Just change some lines in
OvmfPkg/README or something like that.
Thank you!
Laszlo
--- Begin Message ---
Closed #134.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tianocore/edk2/pull/134#event-1992063250--- End Message ---
--- Begin Message ---
Sorry about the late followup.
For now, please subscribe to the edk2-devel mailing list, and submit your patch
as a normal git patch email, for review.
https://lists.01.org/mailman/listinfo/edk2-devel
For now, I'm going to have to close this PR, but this action is entirely
independent of the topic & quality of your patch. I encourage you to submit
your patch to the list please.
The edk2 community is in the process of researching new methods to contribute,
which many developers might find more convenient than the mailing list based
workflow. Please refer to the wiki article at
https://github.com/tianocore/tianocore.github.io/wiki/Community-Virtual-Meetings
. Also, I recommend participating in the thread `[edk2] [edk2-announce]
Research Request`. The archive is at
https://lists.01.org/pipermail/edk2-devel/2018-November/032459.html .
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tianocore/edk2/pull/134#issuecomment-442401567--- End Message ---
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] FmpDeviceLib
Hi Mike, Thanks for looking at this. I was actually thinking of how I could contribute. I was thinking of drafting the following patches: 1. Move FmpDxe data storage into heap allocated FMP_DATA struct, retrieve using standard CR against the protocol treatment. Allocated by FmpInstall(). This might need registering FmpRemove() however. Alternatively register a ExitBootServices callback that uninstalls the FMP. 2. Create FmpDeviceInstanceLib prototype that works like FmpDeviceLib but passes a context parameter to each function. 3. Implement FmpDeviceInstanceGlobal library that pulls in FmpDeviceLib and produces a FmpDeviceInstanceLib 4. Change over FmpDxe from FmpDeviceLib to depend on FmpDeviceInstanceLib. This is not particularly urgent, but we are trying to implement FMP for our optionROM driver and it would be nice to be able to use the upstream cleanly rather than forking it in our driver. If you think the way forward seems okay, I am happy to put in the work. Cheers, Tom On 28/11/2018 01:15, Kinney, Michael D wrote: > Tom, > > Thanks for noticing this issue. I need a little > time to evaluate this use case and see what changes > are required to make this work for a UEFI driver > that manages many controllers. > > Thanks, > > Mike > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel- >> boun...@lists.01.org] On Behalf Of Tomas Pilar (tpilar) >> Sent: Tuesday, November 27, 2018 7:29 AM >> To: Gao, Liming ; edk2- >> de...@lists.01.org >> Subject: Re: [edk2] FmpDeviceLib >> >> Okay, so I just noticed that FmpDxe is full of module >> globals including the image descriptor, so it >> necessarily requires that the driver that includes it as >> a library can only ever control one controller. >> >> Cheers, >> Tom >> >> On 27/11/2018 15:23, Tomas Pilar (tpilar) wrote: >>> On 27/11/2018 14:33, Gao, Liming wrote: Tom: FmpDeviceLib can use UEFI driver model/driver >> binding protocol so it can install FMP on its device >> handle during the BDS/Device connection phase. It can >> implement RegisterFmpInstaller() to install FMP protocol >> in its device handle. In this way, FmpDeviceLib is like >> UEFI driver with UEFI driver binding protocol. Thanks Liming >>> Hi Liming, >>> >>> Sure, so now I can install FMP onto my >> ControllerHandle. Say that someone gets the FMP and >> calls GetImageSize. The FmpDxeLib does some checks and >> then it calls FmpDeviceLibGetImageSize() with no context >> parameter. This method is supposed to be implemented by >> me, the driver writer, but how is the code in this >> method meant to know which Controller are we getting the >> image size from? >>> So maybe I can define some module globals, declare >> them in a cross include file, include that in my driver >> and and have the driver populate the module globals >> during probe. This immediately limits the usefulness by >> requiring that each driver only ever drives one >> controller. >>> And then you consider how to do a SetImage without >> being even given the Handle of the Controller. Do you >> stuff the controller handle into a module global >> parameter that gets populated during the BDS phase? >>> I guess you could enumerate all FMP instances, see >> which one of them advertises your ImageTypeId and get >> the handle that the FMP is installed on that way. But >> that seems rather insane and would cause issues if you >> have two of the same device in the platform, unless you >> check the HardwareInstance as well? This seems insane. >>> Cheers, >>> Tom >>> > -Original Message- > From: edk2-devel [mailto:edk2-devel- >> boun...@lists.01.org] On Behalf Of Tomas Pilar (tpilar) > Sent: Tuesday, November 27, 2018 9:26 PM > To: edk2-devel@lists.01.org > Subject: [edk2] FmpDeviceLib > > Hi all, > > I am looking at using FmpDxeLib so I need to >> implement the FmpDeviceLib. However, it seems like the >> library functions do not take any > private struct as a parameter, so I am struggling to >> figure out how to read information off the hardware. >> FmpDxe does not even pass its > created protocol instance when calling the library >> functions, leading me to believe that the only way to do >> this is to assign a pointer to > private struct during library construction, but that >> means that a driver that uses the code can only ever >> service a single controller. > Can you offer any insights? > > 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] Maintainers.txt: Add the rule to hand over the package maintain role
On 11/28/2018 3:31 PM, Liming Gao wrote: Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao --- Maintainers.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Maintainers.txt b/Maintainers.txt index 91a4657adc..d75bbe278d 100644 --- a/Maintainers.txt +++ b/Maintainers.txt @@ -6,7 +6,9 @@ EDK II. In general, you should not privately email the maintainer. You should email the edk2-devel list, and Cc the package maintainers and -reviewers. +reviewers. If the package maintainer wants to hand over his role to the role instead of his role? :) +other people, the package maintainer should send the patch to update +Maintainers.txt with new maintainer. Descriptions of section entries: -- Thanks, Ray ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [RFC PATCH v3 11/11] CryptoPkg/BaseCryptLib: Hack to get time in MM Standalone mode
This is hack to get the time when executing in MM Standalone mode. It is
not clear how to implement a function that gets the current time. So
using this as a hack for now.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jagadeesh Ujja
---
CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf | 5
CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf| 5
CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c | 27 +++-
3 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
b/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
index c8aafefbab9c..df4aca6c20e2 100644
--- a/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
+++ b/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
@@ -76,6 +76,7 @@ [Sources.AARCH64]
[Packages]
MdePkg/MdePkg.dec
CryptoPkg/CryptoPkg.dec
+ StandaloneMmPkg/StandaloneMmPkg.dec
[LibraryClasses]
BaseLib
@@ -86,6 +87,10 @@ [LibraryClasses]
OpensslLib
IntrinsicLib
PrintLib
+ PcdLib
+
+[FeaturePcd]
+ gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable
#
# Remove these [BuildOptions] after this library is cleaned up
diff --git a/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
b/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
index 32628c8835a6..651a6736ba48 100644
--- a/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
+++ b/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
@@ -80,6 +80,7 @@ [Sources.AARCH64]
[Packages]
MdePkg/MdePkg.dec
CryptoPkg/CryptoPkg.dec
+ StandaloneMmPkg/StandaloneMmPkg.dec
[LibraryClasses]
BaseLib
@@ -91,6 +92,10 @@ [LibraryClasses]
OpensslLib
IntrinsicLib
PrintLib
+ PcdLib
+
+[FeaturePcd]
+ gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable
#
# Remove these [BuildOptions] after this library is cleaned up
diff --git a/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c
b/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c
index 5f9b0c20d75d..d01b5c5fc113 100644
--- a/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c
+++ b/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c
@@ -3,6 +3,7 @@
for OpenSSL-based Cryptographic Library (used in DXE & RUNTIME).
Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2018, ARM Limited. All rights reserved.
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
License
which accompanies this distribution. The full text of the license may be
found at
@@ -77,12 +78,26 @@ time_t time (time_t *timer)
time_t CalTime;
UINTN Year;
- //
- // Get the current time and date information
- //
- Status = gRT->GetTime (, NULL);
- if (EFI_ERROR (Status) || (Time.Year < 1970)) {
-return 0;
+ if (!PcdGetBool (PcdStandaloneMmEnable)) {
+//
+// Get the current time and date information
+//
+Status = gRT->GetTime (, NULL);
+if (EFI_ERROR (Status) || (Time.Year < 1970)) {
+ return 0;
+}
+ } else {
+//
+//[ToDo] Find out a way to get the current time for code executing as
MM_STANDALONE
+//
+Time.Year = 2007;
+Time.Month = 11;
+Time.Day = 29;
+Time.Hour = 17;
+Time.Minute = 43;
+Time.Second = 30;
+
+Year = (UINTN) (Time.Year % 100);
}
//
--
2.7.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [RFC PATCH v3 10/11] CryptoPkg/BaseCryptLib: allow MM_STANDALONE drivers to use this library
“BaseCryptLib” library can be used by MM_STANDALONE drivers as well. So add MM_STANDALONE as the module type this library supports Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jagadeesh Ujja --- CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf b/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf index f29445ce3402..c8aafefbab9c 100644 --- a/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf +++ b/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf @@ -7,6 +7,7 @@ # buffer overflow or integer overflow. # # Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved. +# Copyright (c) 2018, ARM Limited. All rights reserved. # This program and the accompanying materials # are licensed and made available under the terms and conditions of the BSD License # which accompanies this distribution. The full text of the license may be found at @@ -24,7 +25,7 @@ [Defines] FILE_GUID = be3bb803-91b6-4da0-bd91-a8b21c18ca5d MODULE_TYPE= DXE_DRIVER VERSION_STRING = 1.0 - LIBRARY_CLASS = BaseCryptLib|DXE_DRIVER DXE_CORE UEFI_APPLICATION UEFI_DRIVER + LIBRARY_CLASS = BaseCryptLib|DXE_DRIVER DXE_CORE UEFI_APPLICATION UEFI_DRIVER MM_STANDALONE # # The following information is for reference only and not required by the build tools. -- 2.7.4 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [RFC PATCH v3 09/11] MdeModulePkg/VarCheckLib: allow MM_STANDALONE drivers to use this library
“VarCheckLib” library can be used by MM_STANDALONE drivers as well. So add MM_STANDALONE as the module type this library supports Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jagadeesh Ujja --- MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf b/MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf index 099f83dd6aee..c8cf81063e06 100644 --- a/MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf +++ b/MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf @@ -2,6 +2,7 @@ # Provides variable check services and database management. # # Copyright (c) 2015, Intel Corporation. All rights reserved. +# Copyright (c) 2018, ARM Limited. All rights reserved. # # This program and the accompanying materials # are licensed and made available under the terms and conditions @@ -21,12 +22,12 @@ [Defines] FILE_GUID = 63E12D08-0C5D-47F8-95E4-09F89D7506C5 MODULE_TYPE= DXE_RUNTIME_DRIVER VERSION_STRING = 1.0 - LIBRARY_CLASS = VarCheckLib|DXE_RUNTIME_DRIVER DXE_SMM_DRIVER + LIBRARY_CLASS = VarCheckLib|DXE_RUNTIME_DRIVER DXE_SMM_DRIVER MM_STANDALONE # # The following information is for reference only and not required by the build tools. # -# VALID_ARCHITECTURES = IA32 X64 +# VALID_ARCHITECTURES = IA32 X64 AARCH64 # [Sources] -- 2.7.4 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [RFC PATCH v3 08/11] SecurityPkg/AuthVariableLib: allow MM_STANDALONE drivers to use this library
“AuthVariableLib” library can be used by MM_STANDALONE drivers as well. So add MM_STANDALONE as the module type this library supports Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jagadeesh Ujja Reviewed-by: Chao Zhang --- SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf b/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf index 572ba4e120d2..4294d3b1b0b8 100644 --- a/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf +++ b/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf @@ -2,6 +2,7 @@ # Provides authenticated variable services. # # Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved. +# Copyright (c) 2018, ARM Limited. All rights reserved. # # This program and the accompanying materials # are licensed and made available under the terms and conditions @@ -21,12 +22,12 @@ [Defines] FILE_GUID = B23CF5FB-6FCC-4422-B145-D855DBC05457 MODULE_TYPE= DXE_RUNTIME_DRIVER VERSION_STRING = 1.0 - LIBRARY_CLASS = AuthVariableLib|DXE_RUNTIME_DRIVER DXE_SMM_DRIVER + LIBRARY_CLASS = AuthVariableLib|DXE_RUNTIME_DRIVER DXE_SMM_DRIVER MM_STANDALONE # # The following information is for reference only and not required by the build tools. # -# VALID_ARCHITECTURES = IA32 X64 +# VALID_ARCHITECTURES = IA32 X64 AARCH64 # [Sources] -- 2.7.4 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [RFC PATCH v3 07/11] MdeModulePkg/Variable/RuntimeDxe: adapt as a MM Standalone driver
Adapt the variable runtime dxe driver to be used as a MM_STANDALONE
driver to provide variable storage service in MM Standalone mode.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jagadeesh Ujja
---
MdeModulePkg/Universal/Variable/RuntimeDxe/{VariableSmm.inf =>
VariableStandaloneMm.inf} | 43 ++---
MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
| 37 ++--
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
| 201
3 files changed, 195 insertions(+), 86 deletions(-)
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
similarity index 75%
copy from MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
copy to MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
index 2fe72ff8a442..35654f5cfc9d 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
@@ -1,24 +1,13 @@
## @file
-# Provides SMM variable service.
+# Provides MM variable service.
#
-# This module installs SMM variable protocol into SMM protocol database,
-# which can be used by SMM driver, and installs SMM variable protocol
-# into BS protocol database, which can be used to notify the SMM Runtime
-# Dxe driver that the SMM variable service is ready.
-# This module should be used with SMM Runtime DXE module together. The
-# SMM Runtime DXE module would install variable arch protocol and variable
-# write arch protocol based on SMM variable module.
-#
-# Caution: This module requires additional review when modified.
-# This driver will have external input - variable data and communicate buffer
in SMM mode.
-# This external input must be validated carefully to avoid security issues
such as
-# buffer overflow or integer overflow.
-#The whole SMM authentication variable design relies on the integrity of
flash part and SMM.
-# which is assumed to be protected by platform. All variable code and
metadata in flash/SMM Memory
+# The whole MM authentication variable design relies on the integrity of
flash part and MM.
+# which is assumed to be protected by platform. All variable code and
metadata in flash/MM Memory
# may not be modified without authorization. If platform fails to protect
these resources,
# the authentication service provided in this driver will be broken, and the
behavior is undefined.
#
# Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+# Copyright (c) 2018, ARM Limited. All rights reserved.
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD
License
# which accompanies this distribution. The full text of the license may be
found at
@@ -29,22 +18,21 @@
##
[Defines]
- INF_VERSION= 0x00010005
+ INF_VERSION= 0x0001000A
BASE_NAME = VariableSmm
MODULE_UNI_FILE= VariableSmm.uni
FILE_GUID = 23A089B3-EED5-4ac5-B2AB-43E3298C2343
- MODULE_TYPE= DXE_SMM_DRIVER
+ MODULE_TYPE= MM_STANDALONE
VERSION_STRING = 1.0
- PI_SPECIFICATION_VERSION = 0x0001000A
- ENTRY_POINT= VariableServiceInitialize
+ PI_SPECIFICATION_VERSION = 0x00010032
+ ENTRY_POINT= StandaloneMmVariableServiceInitialize
#
# The following information is for reference only and not required by the
build tools.
#
-# VALID_ARCHITECTURES = IA32 X64
+# VALID_ARCHITECTURES = IA32 X64 AARCH64
#
-
[Sources]
Reclaim.c
Variable.c
@@ -59,23 +47,21 @@ [Sources]
[Packages]
MdePkg/MdePkg.dec
MdeModulePkg/MdeModulePkg.dec
+ StandaloneMmPkg/StandaloneMmPkg.dec
[LibraryClasses]
- UefiDriverEntryPoint
+ StandaloneMmDriverEntryPoint
MemoryAllocationLib
BaseLib
SynchronizationLib
- UefiLib
- SmmServicesTableLib
BaseMemoryLib
DebugLib
- DxeServicesTableLib
HobLib
PcdLib
- SmmMemLib
AuthVariableLib
VarCheckLib
- UefiBootServicesTableLib
+ MemLib
+ MmServicesTableLib
[Protocols]
gEfiSmmFirmwareVolumeBlockProtocolGuid## CONSUMES
@@ -85,7 +71,7 @@ [Protocols]
## PRODUCES
## UNDEFINED # SmiHandlerRegister
gEfiSmmVariableProtocolGuid
- gEfiSmmEndOfDxeProtocolGuid ## NOTIFY
+ ##gEfiSmmEndOfDxeProtocolGuid ## NOTIFY
gEdkiiSmmVarCheckProtocolGuid ## PRODUCES
gEfiTcgProtocolGuid ## SOMETIMES_CONSUMES
gEfiTcg2ProtocolGuid ## SOMETIMES_CONSUMES
@@ -137,6 +123,7 @@ [Pcd]
[FeaturePcd]
gEfiMdeModulePkgTokenSpaceGuid.PcdVariableCollectStatistics##
CONSUMES # statistic the information of variable.
[edk2] [RFC PATCH v3 06/11] MdeModulePkg/Variable/RuntimeDxe: adapt for usability with MM Standalone
Adapt the VariableSmmRuntimeDxe driver to communicate with a VariableSmm
driver that is implemented as a MM Standalone driver.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jagadeesh Ujja
---
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf| 2 ++
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf | 4 +++
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c | 31
+---
3 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
index 868981ccaf30..f414b461d81c 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
@@ -51,6 +51,7 @@ [Sources]
[Packages]
MdePkg/MdePkg.dec
MdeModulePkg/MdeModulePkg.dec
+ StandaloneMmPkg/StandaloneMmPkg.dec
[LibraryClasses]
MemoryAllocationLib
@@ -135,6 +136,7 @@ [Pcd]
[FeaturePcd]
gEfiMdeModulePkgTokenSpaceGuid.PcdVariableCollectStatistics ## CONSUMES #
statistic the information of variable.
gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultLangDeprecate ## CONSUMES #
Auto update PlatformLang/Lang
+ gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable
[Depex]
TRUE
diff --git
a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
index bd73f7ac29f2..b409fa2f5844 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
@@ -48,6 +48,7 @@ [Sources]
[Packages]
MdePkg/MdePkg.dec
MdeModulePkg/MdeModulePkg.dec
+ StandaloneMmPkg/StandaloneMmPkg.dec
[LibraryClasses]
MemoryAllocationLib
@@ -87,6 +88,9 @@ [Guids]
## SOMETIMES_CONSUMES ## Variable:L"dbt"
gEfiImageSecurityDatabaseGuid
+[FeaturePcd]
+ gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable
+
[Depex]
gEfiSmmCommunicationProtocolGuid
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c
index 85d655dc19ff..da4af5f30ea2 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c
@@ -14,6 +14,8 @@
InitCommunicateBuffer() is really function to check the variable data size.
Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2018, ARM Limited. All rights reserved.
+
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
License
which accompanies this distribution. The full text of the license may be
found at
@@ -179,7 +181,11 @@ SendCommunicateBuffer (
SMM_VARIABLE_COMMUNICATE_HEADER *SmmVariableFunctionHeader;
CommSize = DataSize + SMM_COMMUNICATE_HEADER_SIZE +
SMM_VARIABLE_COMMUNICATE_HEADER_SIZE;
- Status = mSmmCommunication->Communicate (mSmmCommunication,
mVariableBufferPhysical, );
+ if (PcdGetBool (PcdStandaloneMmEnable)) {
+Status = mSmmCommunication->Communicate (mSmmCommunication,
mVariableBuffer, );
+ } else {
+Status = mSmmCommunication->Communicate (mSmmCommunication,
mVariableBufferPhysical, );
+ }
ASSERT_EFI_ERROR (Status);
SmmCommunicateHeader = (EFI_SMM_COMMUNICATE_HEADER *) mVariableBuffer;
@@ -991,9 +997,11 @@ SmmVariableReady (
{
EFI_STATUSStatus;
- Status = gBS->LocateProtocol (, NULL, (VOID
**));
- if (EFI_ERROR (Status)) {
-return;
+ if (!PcdGetBool (PcdStandaloneMmEnable)) {
+Status = gBS->LocateProtocol (, NULL, (VOID
**));
+if (EFI_ERROR (Status)) {
+ return;
+}
}
Status = gBS->LocateProtocol (, NULL, (VOID
**) );
@@ -1069,13 +1077,14 @@ SmmVariableWriteReady (
{
EFI_STATUSStatus;
VOID *ProtocolOps;
-
- //
- // Check whether the protocol is installed or not.
- //
- Status = gBS->LocateProtocol (, NULL, (VOID **)
);
- if (EFI_ERROR (Status)) {
-return;
+ if (!PcdGetBool (PcdStandaloneMmEnable)) {
+//
+// Check whether the protocol is installed or not.
+//
+Status = gBS->LocateProtocol (, NULL, (VOID **)
);
+if (EFI_ERROR (Status)) {
+ return;
+}
}
//
--
2.7.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [RFC PATCH v3 05/11] MdeModulePkg/FaultTolerantWriteDxe: allow reusability as a MM driver
Adapt the FaultTolerantWriteDxe driver to be used as a MM_STANDALONE
driver to provide UEFI fault tolerant write protocol functionality
for variable reclaim operation on EFI variables stored on a NOR flash
that is only accessible to code executing in MM Standalone mode.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jagadeesh Ujja
---
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
| 2 +
MdeModulePkg/Universal/FaultTolerantWriteDxe/{FaultTolerantWriteSmm.inf =>
FaultTolerantWriteStandaloneMm.inf} | 25 +--
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
| 203 +++-
MdeModulePkg/Universal/FaultTolerantWriteDxe/UpdateWorkingBlock.c
| 27 +--
4 files changed, 185 insertions(+), 72 deletions(-)
diff --git
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
index dcde58d63218..db45be0a9825 100644
--- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
+++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
@@ -41,6 +41,7 @@ [Sources]
[Packages]
MdePkg/MdePkg.dec
MdeModulePkg/MdeModulePkg.dec
+ StandaloneMmPkg/StandaloneMmPkg.dec
[LibraryClasses]
UefiBootServicesTableLib
@@ -69,6 +70,7 @@ [Protocols]
[FeaturePcd]
gEfiMdeModulePkgTokenSpaceGuid.PcdFullFtwServiceEnable## CONSUMES
+ gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable
[Pcd]
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase##
SOMETIMES_CONSUMES
diff --git
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
similarity index 79%
copy from MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
copy to
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
index 606cc2266bda..724534b09b1b 100644
--- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
+++
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
@@ -7,6 +7,7 @@
# flash access.
#
# Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+# Copyright (c) 2018, ARM Limited. All rights reserved.
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD
License
@@ -18,19 +19,19 @@
##
[Defines]
- INF_VERSION= 0x00010005
- BASE_NAME = SmmFaultTolerantWriteDxe
+ INF_VERSION= 0x0001001A
+ BASE_NAME = FaultTolerantWriteMmStandalone
MODULE_UNI_FILE= SmmFaultTolerantWriteDxe.uni
FILE_GUID = 470CB248-E8AC-473c-BB4F-81069A1FE6FD
- MODULE_TYPE= DXE_SMM_DRIVER
+ MODULE_TYPE= MM_STANDALONE
VERSION_STRING = 1.0
- PI_SPECIFICATION_VERSION = 0x0001000A
- ENTRY_POINT= SmmFaultTolerantWriteInitialize
+ PI_SPECIFICATION_VERSION = 0x00010032
+ ENTRY_POINT= StandaloneMmFaultTolerantWriteInitialize
#
# The following information is for reference only and not required by the
build tools.
#
-# VALID_ARCHITECTURES = IA32 X64
+# VALID_ARCHITECTURES = IA32 X64 AARCH64
#
[Sources]
@@ -44,18 +45,18 @@ [Sources]
[Packages]
MdePkg/MdePkg.dec
MdeModulePkg/MdeModulePkg.dec
+ StandaloneMmPkg/StandaloneMmPkg.dec
[LibraryClasses]
- SmmServicesTableLib
MemoryAllocationLib
BaseMemoryLib
- UefiDriverEntryPoint
DebugLib
- UefiLib
PcdLib
ReportStatusCodeLib
- SmmMemLib
+ MemLib
+ StandaloneMmDriverEntryPoint
BaseLib
+ MmServicesTableLib
[Guids]
#
@@ -77,6 +78,7 @@ [Protocols]
[FeaturePcd]
gEfiMdeModulePkgTokenSpaceGuid.PcdFullFtwServiceEnable## CONSUMES
+ gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable
[Pcd]
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase##
SOMETIMES_CONSUMES
@@ -93,7 +95,8 @@ [Pcd]
# So add gEfiRuntimeArchProtocolGuid Depex here.
#
[Depex]
- gEfiSmmFirmwareVolumeBlockProtocolGuid AND gEfiRuntimeArchProtocolGuid
+ TRUE
+ #gEfiSmmFirmwareVolumeBlockProtocolGuid AND gEfiRuntimeArchProtocolGuid
[UserExtensions.TianoCore."ExtraFiles"]
SmmFaultTolerantWriteDxeExtra.uni
diff --git
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
index fabd713c7411..ace39fd4d233 100644
--- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
+++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
@@ -44,6 +44,7 @@
This driver need to make sure the
[edk2] [RFC PATCH v3 04/11] ArmPlatformPkg/NorFlashDxe: allow reusability as a MM driver
Adapt the NorFlashDxe driver to be used as a MM_STANDALONE driver to
allow access to NOR flash for code executing in MM_STANDALONE mode.
This allows storing of EFI variables on NOR flash which is accessible
only via the MM STANDALONE mode software.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jagadeesh Ujja
---
ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
| 3 +
ArmPlatformPkg/Drivers/NorFlashDxe/{NorFlashDxe.inf =>
NorFlashStandaloneMm.inf} | 28 +--
ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
| 5 +-
ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashBlockIoDxe.c
| 2 +-
ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
| 211
ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvbDxe.c
| 88
6 files changed, 240 insertions(+), 97 deletions(-)
diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
index a59a21a03e0a..a704f69ef3aa 100644
--- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
+++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
@@ -32,6 +32,7 @@ [Packages]
MdeModulePkg/MdeModulePkg.dec
ArmPlatformPkg/ArmPlatformPkg.dec
EmbeddedPkg/EmbeddedPkg.dec
+ StandaloneMmPkg/StandaloneMmPkg.dec
[LibraryClasses]
IoLib
@@ -44,6 +45,7 @@ [LibraryClasses]
UefiBootServicesTableLib
UefiRuntimeLib
DxeServicesTableLib
+ StandaloneMmRuntimeDxe
[Guids]
gEfiSystemNvDataFvGuid
@@ -57,6 +59,7 @@ [Protocols]
gEfiDevicePathProtocolGuid
gEfiFirmwareVolumeBlockProtocolGuid
gEfiDiskIoProtocolGuid
+ gEfiSmmFirmwareVolumeBlockProtocolGuid
[Pcd.common]
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase
diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.inf
similarity index 71%
copy from ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
copy to ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.inf
index a59a21a03e0a..a6d0581b799c 100644
--- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
+++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.inf
@@ -2,7 +2,7 @@
#
# Component description file for NorFlashDxe module
#
-# Copyright (c) 2011 - 2014, ARM Ltd. All rights reserved.
+# Copyright (c) 2018, ARM Limited. All rights reserved.
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD
License
@@ -16,11 +16,12 @@
[Defines]
INF_VERSION= 0x00010005
- BASE_NAME = ArmVeNorFlashDxe
- FILE_GUID = 93E34C7E-B50E-11DF-9223-2443DFD72085
- MODULE_TYPE= DXE_RUNTIME_DRIVER
+ BASE_NAME = StandaloneMmNorFlash
+ FILE_GUID = 166F677B-DAC9-4AE4-AD34-2FF2504B0637
+ MODULE_TYPE= MM_STANDALONE
VERSION_STRING = 1.0
- ENTRY_POINT= NorFlashInitialise
+ PI_SPECIFICATION_VERSION = 0x00010032
+ ENTRY_POINT= StandaloneMmNorFlashInitialise
[Sources.common]
NorFlashDxe.c
@@ -32,18 +33,21 @@ [Packages]
MdeModulePkg/MdeModulePkg.dec
ArmPlatformPkg/ArmPlatformPkg.dec
EmbeddedPkg/EmbeddedPkg.dec
+ ArmPkg/ArmPkg.dec
+ StandaloneMmPkg/StandaloneMmPkg.dec
[LibraryClasses]
+ StandaloneMmDriverEntryPoint
+ BaseMemoryLib
+ ArmSvcLib
+ ArmLib
IoLib
BaseLib
DebugLib
HobLib
+ MemoryAllocationLib
NorFlashPlatformLib
- UefiLib
- UefiDriverEntryPoint
- UefiBootServicesTableLib
- UefiRuntimeLib
- DxeServicesTableLib
+ MmServicesTableLib
[Guids]
gEfiSystemNvDataFvGuid
@@ -55,7 +59,7 @@ [Guids]
[Protocols]
gEfiBlockIoProtocolGuid
gEfiDevicePathProtocolGuid
- gEfiFirmwareVolumeBlockProtocolGuid
+ gEfiSmmFirmwareVolumeBlockProtocolGuid
gEfiDiskIoProtocolGuid
[Pcd.common]
@@ -69,4 +73,4 @@ [Pcd.common]
gArmPlatformTokenSpaceGuid.PcdNorFlashCheckBlockLocked
[Depex]
- gEfiCpuArchProtocolGuid
+ TRUE
diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
index 5c07694fbfaa..e3932a190b27 100644
--- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
+++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
@@ -1,6 +1,6 @@
/** @file NorFlashDxe.h
- Copyright (c) 2011 - 2014, ARM Ltd. All rights reserved.
+ Copyright (c) 2011 - 2018, ARM Ltd. All rights reserved.
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
License
@@ -19,6 +19,7 @@
#include
#include
+#include
#include
#include
@@ -30,6 +31,8 @@
#include
#include
#include
+#include
+#include
#define NOR_FLASH_ERASE_RETRY 10
diff --git
[edk2] [RFC PATCH v3 03/11] MdeModulePkg/Library: Add StandaloneMmRuntimeDxe library
To resuse some the libraries in both MM and non-MM mode, a mechanism to
determine the execution mode is required, i.e, in MM or non-MM. Add a
new library for use by non-MM code to determine the current execution
mode.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jagadeesh Ujja
---
MdeModulePkg/Library/{AuthVariableLibNull/AuthVariableLibNull.inf =>
StandaloneMmRuntimeDxe/StandaloneMmRuntimeDxe.inf}
| 19 ++--
StandaloneMmPkg/Include/Library/StandaloneMmServicesTableLib.h =>
MdeModulePkg/Include/Library/StandaloneMmRuntimeDxe.h
| 86 -
StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c
=> MdeModulePkg/Library/StandaloneMmRuntimeDxe/StandaloneMmRuntimeDxe.c | 100
+++-
3 files changed, 86 insertions(+), 119 deletions(-)
diff --git a/MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
b/MdeModulePkg/Library/StandaloneMmRuntimeDxe/StandaloneMmRuntimeDxe.inf
similarity index 61%
copy from MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
copy to MdeModulePkg/Library/StandaloneMmRuntimeDxe/StandaloneMmRuntimeDxe.inf
index 900fef5d4989..5948fd27081c 100644
--- a/MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
+++ b/MdeModulePkg/Library/StandaloneMmRuntimeDxe/StandaloneMmRuntimeDxe.inf
@@ -1,7 +1,7 @@
## @file
-# Provides NULL authenticated variable services.
+# Provides StandaloneMmRuntimeDxe.
#
-# Copyright (c) 2015, Intel Corporation. All rights reserved.
+# Copyright (c) 2018, ARM Limited. All rights reserved.
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions
@@ -16,25 +16,28 @@
[Defines]
INF_VERSION= 0x00010005
- BASE_NAME = AuthVariableLibNull
- MODULE_UNI_FILE= AuthVariableLibNull.uni
- FILE_GUID = 435CB0E4-7C9A-4BB7-9907-8FD4643E978A
+ BASE_NAME = StandaloneMmRuntimeDxe
+ FILE_GUID = 8099cfbf-9564-4c9b-9052-e66b1da88930
MODULE_TYPE= DXE_RUNTIME_DRIVER
VERSION_STRING = 1.0
- LIBRARY_CLASS = AuthVariableLib|DXE_RUNTIME_DRIVER
DXE_SMM_DRIVER
+ LIBRARY_CLASS = StandaloneMmRuntimeDxe |DXE_RUNTIME_DRIVER
DXE_SMM_DRIVER MM_STANDALONE
#
# The following information is for reference only and not required by the
build tools.
#
-# VALID_ARCHITECTURES = IA32 X64
+# VALID_ARCHITECTURES = IA32 X64 AARCH64
#
[Sources]
- AuthVariableLibNull.c
+ StandaloneMmRuntimeDxe.c
[Packages]
MdePkg/MdePkg.dec
MdeModulePkg/MdeModulePkg.dec
[LibraryClasses]
+ BaseLib
+ BaseMemoryLib
DebugLib
+ MemoryAllocationLib
+
diff --git a/StandaloneMmPkg/Include/Library/StandaloneMmServicesTableLib.h
b/MdeModulePkg/Include/Library/StandaloneMmRuntimeDxe.h
similarity index 73%
copy from StandaloneMmPkg/Include/Library/StandaloneMmServicesTableLib.h
copy to MdeModulePkg/Include/Library/StandaloneMmRuntimeDxe.h
index e7a670d3636d..e4a61f6a7b21 100644
--- a/StandaloneMmPkg/Include/Library/StandaloneMmServicesTableLib.h
+++ b/MdeModulePkg/Include/Library/StandaloneMmRuntimeDxe.h
@@ -1,47 +1,39 @@
-/** @file
- Provides a service to retrieve a pointer to the Standalone MM Services Table.
- Only available to Standalone MM module types.
-
-Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
-Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
-
-This program and the accompanying materials
-are licensed and made available under the terms and conditions of the BSD
License
-which accompanies this distribution. The full text of the license may be
found at
-http://opensource.org/licenses/bsd-license.php
-
-THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#ifndef __MM_SERVICES_TABLE_LIB_H__
-#define __MM_SERVICES_TABLE_LIB_H__
-
-#include
-#include
-
-///
-/// Cache pointer to the Standalone MM Services Table
-
-extern EFI_MM_SYSTEM_TABLE *gMmst;
-
-
-/**
- This function allows the caller to determine if the driver is executing in
- Standalone Management Mode(SMM).
-
- This function returns TRUE if the driver is executing in SMM and FALSE if the
- driver is not executing in SMM.
-
- @retval TRUE The driver is executing in Standalone Management Mode (SMM).
- @retval FALSE The driver is not executing in Standalone Management Mode
(SMM).
-
-**/
-BOOLEAN
-EFIAPI
-InMm (
- VOID
- );
-
-#endif
+/** @file
+ Provides a service to retrieve a pointer to the Standalone MM Services Table.
+ Only available to Standalone MM module types.
+
+Copyright (c) 2018, ARM Limited. All rights reserved.
+
+This program and the accompanying materials
+are licensed and made
[edk2] [RFC PATCH v3 02/11] StandaloneMmPkg: Pull in additonal libraries from staging branch
Three additional library packages are being pulled into StandaloneMmPkg
from the staging area in order to support the secure variable service.
The three packages being pulled in are
- StandaloneMmHobLib
- StandaloneMmMemoryAllocationLib
- StandaloneMmServicesTableLib
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jagadeesh Ujja
---
StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf
| 2 +-
StandaloneMmPkg/Library/{StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf =>
StandaloneMmHobLib/StandaloneMmHobLib.inf}
| 11 +--
StandaloneMmPkg/Library/{StandaloneMmCoreMemoryAllocationLib/StandaloneMmCoreMemoryAllocationLib.inf
=> StandaloneMmMemoryAllocationLib/StandaloneMmMemoryAllocationLib.inf} | 14
++-
StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf
| 36
MdePkg/Include/Library/SmmServicesTableLib.h =>
StandaloneMmPkg/Include/Library/StandaloneMmServicesTableLib.h
| 90 ++--
StandaloneMmPkg/Library/{StandaloneMmCoreHobLib =>
StandaloneMmHobLib}/AArch64/StandaloneMmCoreHobLibInternal.c
| 4 +-
StandaloneMmPkg/Library/{StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.c =>
StandaloneMmHobLib/StandaloneMmHobLib.c}
| 55 +++-
MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c =>
StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/StandaloneMmMemoryAllocationLib.c
| 69 ---
MdeModulePkg/Library/PiSmmCoreSmmServicesTableLib/PiSmmCoreSmmServicesTableLib.c
=>
StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c
| 34
9 files changed, 203 insertions(+), 112 deletions(-)
diff --git
a/StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf
b/StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf
index db19d3c926e8..ac036e31cf5e 100644
--- a/StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf
+++ b/StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf
@@ -24,7 +24,7 @@ [Defines]
MODULE_TYPE= MM_CORE_STANDALONE
VERSION_STRING = 1.0
PI_SPECIFICATION_VERSION = 0x00010032
- LIBRARY_CLASS = HobLib|MM_CORE_STANDALONE MM_STANDALONE
+ LIBRARY_CLASS = HobLib|MM_CORE_STANDALONE
#
# VALID_ARCHITECTURES = AARCH64
diff --git
a/StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf
b/StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf
similarity index 79%
copy from
StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf
copy to StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf
index db19d3c926e8..d73188ec1b57 100644
--- a/StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf
+++ b/StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf
@@ -20,17 +20,17 @@
[Defines]
INF_VERSION= 0x0001001A
BASE_NAME = HobLib
- FILE_GUID = CF56EF2C-68D8-4BD5-9A8B-8A7BFCFF751C
- MODULE_TYPE= MM_CORE_STANDALONE
+ FILE_GUID = 8262551B-AB2D-4E76-99FC-5EBB83F4988E
+ MODULE_TYPE= MM_STANDALONE
VERSION_STRING = 1.0
PI_SPECIFICATION_VERSION = 0x00010032
- LIBRARY_CLASS = HobLib|MM_CORE_STANDALONE MM_STANDALONE
-
+ LIBRARY_CLASS = HobLib|MM_STANDALONE
+ CONSTRUCTOR= HobLibConstructor
#
# VALID_ARCHITECTURES = AARCH64
#
[Sources.Common]
- StandaloneMmCoreHobLib.c
+ StandaloneMmHobLib.c
[Sources.AARCH64]
AArch64/StandaloneMmCoreHobLibInternal.c
@@ -42,6 +42,7 @@ [Packages]
[LibraryClasses]
BaseMemoryLib
DebugLib
+ MmServicesTableLib
[Guids]
gEfiHobListGuid ## CONSUMES ## SystemTable
diff --git
a/StandaloneMmPkg/Library/StandaloneMmCoreMemoryAllocationLib/StandaloneMmCoreMemoryAllocationLib.inf
b/StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/StandaloneMmMemoryAllocationLib.inf
similarity index 76%
copy from
StandaloneMmPkg/Library/StandaloneMmCoreMemoryAllocationLib/StandaloneMmCoreMemoryAllocationLib.inf
copy to
StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/StandaloneMmMemoryAllocationLib.inf
index 3958655cb4cf..9ac03df4caad 100644
---
a/StandaloneMmPkg/Library/StandaloneMmCoreMemoryAllocationLib/StandaloneMmCoreMemoryAllocationLib.inf
