I agree those changes really make sense for better alignment, under both
1.0.2xx and 1.1 HEAD. The final out-of-box support will be wonderful.
The updates (http://git.infradead.org/users/dwmw2/edk2.git) looks good to me.
And I will follow more validations, and start the next integration
step-by
Reviewed-by: Jeff Fan
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael
Kinney
Sent: Friday, February 19, 2016 9:54 AM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen; Laszlo Ersek; Fan, Jeff
Subject: [edk2] [Patch v2] UefiCpuPkg/PiSmmCpuDxeSmm
Reviewed-by: Jeff Fan
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael
Kinney
Sent: Friday, February 19, 2016 10:36 AM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen; Fan, Jeff
Subject: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Enable/Restore
On 19 February 2016 at 01:43, Yao, Jiewen wrote:
> Thanks. It seems my misunderstanding.
>
> Just want to double confirm: It is expected to see memory attribute table
> like below. Right?
>
Correct.
> 0x00013c0e-0x00013c0e [Runtime Code |RUN| |XP| | | ]
> 0x00013c0f-0x0001
Reviewed-by: Liming Gao
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yonghong
Zhu
Sent: Wednesday, February 17, 2016 6:33 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch] BaseTools/Trim: Fix the bug for stripping when no line
directive
when has next line to draw, should not overwrite the BltX
to 0, instead should keep the BltX value that pass into
StringToImage function.
Cc: Liming Gao
Cc: Eric Dong
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi
---
MdeModulePkg/Universal/HiiDatabaseDxe/Font
Jeremy,
On 2016/2/19 5:07, Jeremy Linton wrote:
Update the BDS frontpage to pull the RAM ranges from the
smbios extended size fields when applicable. The RAM calculation
also needs to take into account all the RAM ranges being provided
as many machines have multiple physical address ranges.
Con
If XD is supported, then SMM enables it. The non-SMM execution
environment can choose to enable or disable XD, so the state of
XD must be detected in each SMI and be enabled/restored.
Cc: Jeff Fan
Cc: Jiewen Yao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinn
Reviewed-by: Ruiyu Ni
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Samer El-Haj-Mahmoud
> Sent: Friday, February 19, 2016 8:01 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Samer
> El-Haj-Mahmoud ; Gao, Liming
> Subject: [
Yes I'm also investigating this approach, it will bring a lot of code changes,
we need to check whether it will bring other unexpected problem.
From: Kinney, Michael D
Sent: Friday, February 19, 2016 10:19 AM
To: Fu, Siyuan ; Kinney, Michael D
Cc: Subramanian, Sriram (EG Servers Platform SW) ;
Siyuan,
>From the flow chart, it looks like a design issue in the current
>implementation. The UEFI Spec defines config protocols, but there is a use
>case for a newly added NIC that does not allow the platform to use the config
>protocols before the configuration information is used to start
Some platform doesn't use CPU(HOST)/Device 1:1 mapping for PCI Bus.
But PCI IO doesn't have interface to tell caller (device driver)
whether the address returned by GetBarAttributes() is HOST address
or device address.
UEFI Spec 2.6 addresses this issue by clarifying the address returned
is HOST ad
Some platform doesn't use CPU(HOST)/Device 1:1 mapping for PCI Bus.
But PCI IO doesn't have interface to tell caller (device driver)
whether the address returned by GetBarAttributes() is HOST address
or device address.
UEFI Spec 2.6 addresses this issue by clarifying the address returned
is HOST ad
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Feng Tian
Cc: Jeff Fan
---
MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c | 70 --
1 file changed, 24 insertions(+), 46 deletions(-)
diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
Reviewed-by: Eric Dong
> -Original Message-
> From: Bi, Dandan
> Sent: Wednesday, February 17, 2016 6:15 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming; Dong, Eric
> Subject: [patch] MdeModulePkg: Refine the code in BootMaintenanceManagerUiLib
>
> Refine the code in function Var_Upda
The function CheckFeatureSupported() is used as an EFI_AP_PROCEDURE
in the MP Services Protocol service StartAllAPs(). Any function
used as an EFI_AP_PROCEDURE must use EFIAPI calling convention.
Cc: Laszlo Ersek
Cc: Jeff Fan
Cc: Jiewen Yao
Contributed-under: TianoCore Contribution Agreement 1
Correct a typo
If a PCD should NOT be used from the UEFI compliance point of view,
From: Fu, Siyuan
Sent: Friday, February 19, 2016 9:40 AM
To: Kinney, Michael D
Cc: Subramanian, Sriram (EG Servers Platform SW) ;
El-Haj-Mahmoud, Samer ; Wu, Jiaxin
; Hegde, Nagaraj P ; Zimmer,
Vincent ; Li, Rut
Jiaxin,
The UEFI network stack is produces by UEFI Drivers that follow the UEFI Driver
Model. The IPv4 and IPv6 stack can be produced by UEFI drivers loaded from
system FLASH or loaded from Drivers Options or loaded from Shell or loaded from
PCI Option ROMs.
Since the UEFI Spec 2.6 was update
Hi, Mike
Seems HP have some special use case that couldn't apply the fast boot, so let's
just put it aside and let me describe more clearly why the problem couldn't be
solved by a platform driver/PCD or a platform HII configuration.
First, the "default policy" here we are talking about, mea
The immediate advantage of using these PCDs is that the platform can change the
default behavior for all started NICs, that will not be limited to the
additional setting.
Thanks.
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Sub
Laszlo,
Good catch. I agree it should be
VOID
EFIAPI
CheckFeatureSupported (
IN OUT VOID *Buffer
);
Jeff
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Friday, February 19, 2016 4:09 AM
To: Kinney, Michael D; edk2-de...@ml01.01.org
Cc: Yao, Jiewen; Fan, Jeff
Shumin:
Could you use HiiLib HiiGetString() API to get string value instead of parse
HII string package？
Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Qiu
Shumin
Sent: Saturday, February 6, 2016 3:22 PM
To: edk2-devel@lists.01.o
Thanks Laszlo. I agree with you. We had better drop unnecessary cast and fix
parameter mismatch.
Reviewed-by: jiewen@intel.com
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Friday, February 19, 2016 4:09 AM
To: Kinney, Michael D; edk2-de...@ml01.01.org
Cc:
Reviewed-by: Jeff Fan
-Original Message-
From: Kinney, Michael D
Sent: Friday, February 19, 2016 3:42 AM
To: edk2-devel@lists.01.org
Cc: Fan, Jeff; Yao, Jiewen
Subject: [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add EFIAPI to
CheckFeatureSupported()
The function CheckFeatureSupported() is used
Fix a bug in BmpHeader parameter check
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud
---
MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MdeModulePkg/Library/BmpImageD
> From: Felix Poludov [mailto:fel...@ami.com]
> Sent: Thursday, February 18, 2016 1:11 PM
> To: Bjorge, Erik C ; edk2-devel@lists.01.org
> Subject: RE: BaseTools build number after transition to git
>
> Eric,
>
> Using git commit hash or a truncated version of hash, as proposed by
> Laszlo, is mo
Add new HttpUtilLib that contains helper functions for HTTP
Request/Response processing.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud
---
MdeModulePkg/Include/Library/HttpUtilLib.h | 140 ++
.../Library/DxeHttpUtilLib/DxeHttpUtilLib.c
Reviewed-by: jiewen@intel.com
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Anbazhagan, Baraneedharan
Sent: Friday, February 19, 2016 6:15 AM
To: edk2-devel@lists.01.org
Cc: Zhang, Chao B
Subject: [edk2] [PATCH] SecurityPkg: Change TPM MMIO
Thanks. It seems my misunderstanding.
Just want to double confirm: It is expected to see memory attribute table like
below. Right?
0x00013c0e-0x00013c0e [Runtime Code |RUN| |XP| | | ]
0x00013c0f-0x00013c0f [Runtime Code |RUN| | | | |RO]
0x00013c10-0x00013c12
Yes, below set but not used local variable will cause GCC build error. I agree
this change.
Reviewed-by: Jiaxin Wu mailto:jiaxin...@intel.com>>
Thanks.
Jiaxin
From: Shivamurthy Shastri [mailto:shivamurthy.shas...@linaro.org]
Sent: Thursday, February 18, 2016 7:18 PM
To: Leahy, Leroy P ; fr
The HeaderLog field of the PCIe Extended Capabilities Advanced Error
Reporting structure was incorrectly defined as a 32-bit field. The PCIe
2.1 Base Specification, section 7.10, lists this as 16 bytes, or 4
DWORDs.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Ha
Rename gEfiProcessorSpecificErrorSectionGuid to
gEfiIa32X64ErrorSectionGuid and introduce gEfiArmErrorSectionGuid to
match the definition in the UEFI 2.6 specification Table 249.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud
---
MdePkg/Include/Guid/C
On Thu, 2016-02-18 at 17:36 +, Long, Qin wrote:
> I think I also need to apologize, that it's my decision to pending
> some part of Dave's patch series posted in last year (with simple
> sync-up with Dave), which includes some changes for include path,
> build process, etc.
I agreed with that
Change HttpDxe and HttpBootDxe to use the standard definitions from
Http11.h instead of private duplicate definitions.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud
---
NetworkPkg/HttpBootDxe/HttpBootClient.c | 7 ---
NetworkPkg/HttpBootDxe/Http
Add additional HTTP 1.1 definitions that are useful in HTTP
applications, such as User-Agent, Location, and x-Auth-Token
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud
---
MdePkg/Include/IndustryStandard/Http11.h | 54 +---
Changes made to TrEE SMM module is not ported to TCG2 SMM module
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Baraneedharan Anbazhagan
---
SecurityPkg/Tcg/Tcg2Smm/Tpm.asl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
On Thu, 2016-02-18 at 18:02 +0100, Laszlo Ersek wrote:
> I briefly skimmed your enormous patch in your github repo -- I see that
> there are several changes to OvmfPkg/QemuVideoDxe. Some of them seem to
> relate directly to the PciIo change (= address translation), while other
> changes in the driv
On Thu, 2016-02-18 at 18:02 +0100, Laszlo Ersek wrote:
>
> with Ray's change in the generic PCI bus driver, *must* all PciIo-based
> device drivers be updated? Is this a (bug-)compatible change, or does it
> regress existing drivers (perhaps by triggering their hidden bugs)?
I wouldn't expect exi
On 02/17/2016 10:25 PM, Andrew Fish wrote:
On Feb 17, 2016, at 6:50 PM, Dong, Eric wrote:
Hi All,
Thanks for your comments. I add my explanation below:
Only hook ReadyToBoot event is not enough. Different drivers may hook this
event and some may update string package in their callback func
Eric,
Using git commit hash or a truncated version of hash, as proposed by Laszlo, is
mostly fine.
The only inconvenience of git hashes is that they cannot be compared.
Unlike SVN revision, it's impossible to tell which commit is newer, by just
looking at git hash.
I suggest using git hash plus
Update the BDS frontpage to pull the RAM ranges from the
smbios extended size fields when applicable. The RAM calculation
also needs to take into account all the RAM ranges being provided
as many machines have multiple physical address ranges.
Contributed-under: TianoCore Contribution Agreement 1.
On 02/18/16 21:16, Ard Biesheuvel wrote:
> On 18 February 2016 at 21:14, Laszlo Ersek wrote:
>> On 02/18/16 21:03, Ard Biesheuvel wrote:
>>> The ACPI spec predates the AARCH64 architecture by 5 versions, so there
>>> is no point in supporting anything below v5.0. So set the PCD that
>>> controls t
On 18 February 2016 at 21:16, Ard Biesheuvel wrote:
> On 18 February 2016 at 21:14, Laszlo Ersek wrote:
>> On 02/18/16 21:03, Ard Biesheuvel wrote:
>>> The ACPI spec predates the AARCH64 architecture by 5 versions, so there
>>> is no point in supporting anything below v5.0. So set the PCD that
>>
On 18 February 2016 at 21:14, Laszlo Ersek wrote:
> On 02/18/16 21:03, Ard Biesheuvel wrote:
>> The ACPI spec predates the AARCH64 architecture by 5 versions, so there
>> is no point in supporting anything below v5.0. So set the PCD that
>> controls the ACPI table generation to the appropriate val
On 02/18/16 21:03, Ard Biesheuvel wrote:
> The ACPI spec predates the AARCH64 architecture by 5 versions, so there
> is no point in supporting anything below v5.0. So set the PCD that
> controls the ACPI table generation to the appropriate value.
>
> Note that the current consumers of this PCD onl
On 02/18/16 20:41, Michael Kinney wrote:
> The function CheckFeatureSupported() is used as an EFI_AP_PROCEDURE
> in the MP Services Protocol service StartAllAPs(). Any function
> used as an EFI_AP_SERVICE must use EFIAPI calling convention.
I think "EFI_AP_SERVICE" should be "EFI_AP_PROCEDURE" he
On AARCH64, there is no requirement to support OSes that can only access
ACPI tables in low memory (i.e., below 4 GB), and there are reasons to
prefer allocations higher up. First of all, so DMA capable devices may
only be able to access 32-bit addressable memory. Additionally, keeping
memory reser
The ACPI spec predates the AARCH64 architecture by 5 versions, so there
is no point in supporting anything below v5.0. So set the PCD that
controls the ACPI table generation to the appropriate value.
Note that the current consumers of this PCD only check whether bit 1
is set or not (i.e., ACPI v1.
It is not entirely clear from the code why, but the reserved region
for storing performance data is allocated below 4 GB, and the variable
to hold the address of the allocation is called 'AcpiLowMemoryBase'
(which is the only mention of ACPI in the entire file).
Let's make this allocation dependen
AARCH64 systems never require compatibility with legacy ACPI OSes, and
may not have any 32-bit addressable system RAM. To support ACPI on these
systems, we need to be able to relax the 4 GB allocation restriction.
Since systems that do have 32-bit addressable RAM may prefer to reserve it
for DMA bu
The function CheckFeatureSupported() is used as an EFI_AP_PROCEDURE
in the MP Services Protocol service StartAllAPs(). Any function
used as an EFI_AP_SERVICE must use EFIAPI calling convention.
Cc: Jeff Fan
Cc: Jiewen Yao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Mi
On 14 February 2016 at 06:44, Yao, Jiewen wrote:
> HI
> Thanks to discuss this properties table issue.
> The purpose of this patch is to *add* UEFI2.6 memory attributes table. This
> patch does not handle any UEFI2.5 properties table.
> If we want to change EDKII code for properties table, I sugg
Wow, I just noticed these were so many discussion against this, with so many
tech scopes. :-), Thanks for them, Dave & Laszlo.
I think I also need to apologize, that it's my decision to pending some part of
Dave's patch series posted in last year (with simple sync-up with Dave), which
includes s
On 02/18/16 16:45, David Woodhouse wrote:
> On Thu, 2016-02-18 at 14:27 +, David Woodhouse wrote:
>> On Thu, 2016-02-18 at 14:58 +0100, Laszlo Ersek wrote:
>>>
>>> Then I gave my R-b to this patch, admitting that I couldn't verify the
>>> edk2-only customizations against the 1.0.2f release.
>
On 02/18/16 15:27, David Woodhouse wrote:
> On Thu, 2016-02-18 at 14:58 +0100, Laszlo Ersek wrote:
>>
>> Then I gave my R-b to this patch, admitting that I couldn't verify the
>> edk2-only customizations against the 1.0.2f release.
>>
>> Turns out those customizations are indeed no longer correct,
On 02/18/16 15:18, Benjamin Herrenschmidt wrote:
> On Thu, 2016-02-18 at 06:55 +, Ni, Ruiyu wrote:
>> Ben,
>> I just had a look at your changes. Nice feeling that our codes are
>> quite similar, except yours are in a separate function.
>> I thought about separating it to a sub function but late
On 02/18/16 15:20, Yao, Jiewen wrote:
> Hi
> Thanks to bring this 4G issue again. I have several thought for your
> consideration.
>
> 1) At 12/16/2015, Samer El-Haj-Mahmoud
> submitted a patch:
> [edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get
> installed above 4GB
>
>
Adding Ruiyu Ni
--
Thanks and Regards,
Shivamurthy Shastri,
M: +919742508553, IRC: shivamurthy,
*Linaro.org* |Open Source Software for ARM SOCs
On 18 February 2016 at 16:50, Shivamurthy Shastri <
shivamurthy.shas...@linaro.org> wrote:
> Hi All,
>
> Please let me know your opinion about this
That sounds good to me.
> -Original Message-
> From: jim_dai...@dell.com [mailto:jim_dai...@dell.com]
> Sent: Thursday, February 18, 2016 8:26 AM
> To: Carsey, Jaben
> Cc: Qiu, Shumin ; edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH] ShellPkg: Increase reallocation size for temp
> m
Dell - Internal Use - Confidential
>> +#define MEM_WRITE_REALLOC_SIZE 1024
>
> Could this name change to something more clear? This is not the
> allocate size, this is more like the reallocated overhead that is
> allocated extra in case we have a sequence of reallocates...
I have no problem wi
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> jim_dai...@dell.com
> Sent: Thursday, February 18, 2016 7:52 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Qiu, Shumin
>
> Subject: [edk2] [PATCH] ShellPkg: Increase reallocation size
I agree.
The version support is mess in this driver. There is some historic reason which
makes code like this today.
Just differentiate 1_0B and other is good enough, it matched UEFI spec, too.
UEFI spec only defines "ACPI1.0b" and "ACPI2.0+above" in configuration table.
Again, thanks for your c
ShellPkg: Increase reallocation size for temp memory files
If data of any real size were to be piped from one command to another, an
inordinate amount of time could be taken up by reallocating memory that is only
10 bytes bigger than what is currently needed. Also, this could cause unwelcome
me
On 18 February 2016 at 16:44, Yao, Jiewen wrote:
> I found PI spec vol 5 has below definition in EFI_ACPI_SDT_PROTOCOL. Maybe we
> can define PcdAcpiTableVersion to match this.
>
> #define UINT32 EFI_ACPI_TABLE_VERSION;
> #define EFI_ACPI_TABLE_VERSION_NONE (1 << 0)
> #define EFI_ACPI_TABLE_VERSI
On Thu, 2016-02-18 at 14:27 +, David Woodhouse wrote:
> On Thu, 2016-02-18 at 14:58 +0100, Laszlo Ersek wrote:
> >
> > Then I gave my R-b to this patch, admitting that I couldn't verify the
> > edk2-only customizations against the 1.0.2f release.
> >
> > Turns out those customizations are ind
I found PI spec vol 5 has below definition in EFI_ACPI_SDT_PROTOCOL. Maybe we
can define PcdAcpiTableVersion to match this.
#define UINT32 EFI_ACPI_TABLE_VERSION;
#define EFI_ACPI_TABLE_VERSION_NONE (1 << 0)
#define EFI_ACPI_TABLE_VERSION_1_0B (1 << 1)
#define EFI_ACPI_TABLE_VERSION_2_0 (1 << 2)
XSDT is introduced in ACPI2.0.
ACPI1.0/ACPI1.0b only defined 32bit address range. ACPI2.0 resolved 4G issue
immediately, but in order to keep compatibility, most platform produced both
DSDT and XSDT, and with FADT1.0 and FADT2.0, at that time.
For now, I believe most OSes support ACPI2.0 and abo
On 18 February 2016 at 16:07, Yao, Jiewen wrote:
> Or PcdAcpiSupportVersion, bit0 as ACPI1.0.
> Bit0 set means allocation Below4G.
> Bit0 clear means allocation from everywhere.
>
That is also fine with me. But I think it was ACPI 5.0 that introduced
XSDT, right? So if you clear this bit, you wou
Or PcdAcpiSupportVersion, bit0 as ACPI1.0.
Bit0 set means allocation Below4G.
Bit0 clear means allocation from everywhere.
-Original Message-
From: Yao, Jiewen
Sent: Thursday, February 18, 2016 11:05 PM
To: Ard Biesheuvel
Cc: Tian, Feng; Graeme Gregory; edk2-devel@lists.01.org; Leif Lind
Thanks to detail explain. I understand and I agree with you that fragmentation
is problem.
So basically, I agree on PCD solution to choose preferred location of
allocation.
Maybe you can consider adding fragmentation issue as description to help more
people on why we need this PCD.
I also thin
ShellPkg: Do not write the UNICODE BOM on ConOut.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jim Dailey
---
ShellPkg/Application/Shell/FileHandleWrappers.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/ShellPkg/Application/Shell/FileHandleW
ShellPkg: Add FileSize member to shell memory file structure.
The shell uses the memory file structure to manage temporary files in
memory that support piping of output from one command into the the
input of another command. The BufferSize member is the size of the
internal buffer, not the size o
Thanks Jiewen. On ARCH64 systems, it is possible not to have any memory below
4GB at all.
Ard,
Are you OK with a solution that does not use a PCD?
-Original Message-
From: Yao, Jiewen [mailto:jiewen@intel.com]
Sent: Thursday, February 18, 2016 8:35 AM
To: El-Haj-Mahmoud, Samer ;
On 18 February 2016 at 15:20, Yao, Jiewen wrote:
> Hi
> Thanks to bring this 4G issue again. I have several thought for your
> consideration.
>
> 1) At 12/16/2015, Samer El-Haj-Mahmoud
> submitted a patch:
> [edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get
> installed ab
Yes. Good question: to PCD or not to PCD. :-)
If it is 2010, I will choose PCD, because I want the flexibility.
But now, when more and more people working on that, they start complaining the
number of *possible* configuration. So we are trying to not add too much PCD,
unless it is necessary.
Tha
On Thu, 2016-02-18 at 14:58 +0100, Laszlo Ersek wrote:
>
> Then I gave my R-b to this patch, admitting that I couldn't verify the
> edk2-only customizations against the 1.0.2f release.
>
> Turns out those customizations are indeed no longer correct, so my R-b
> was in error.
Er, aren't they? Are
Jiewen,
I think ACPI and SMBIOS solutions could be the same, or could be different. The
SMBIOS 3.0 spec allows SMBIOS table to be above 4GB, and some platforms may
chose that even if they have memory below 4GB.
For the ACPI patch, it looks like Ard's feedback and yours are contradictory.
Ard
Hi
Thanks to bring this 4G issue again. I have several thought for your
consideration.
1) At 12/16/2015, Samer El-Haj-Mahmoud submitted
a patch:
[edk2] [PATCH] IntelFrameworkModulePkg : Allow ACPI tables to get
installed above 4GB
Some ARM systems do not have available memory below 4GB,
On Thu, 2016-02-18 at 06:55 +, Ni, Ruiyu wrote:
> Ben,
> I just had a look at your changes. Nice feeling that our codes are
> quite similar, except yours are in a separate function.
> I thought about separating it to a sub function but later didn't do
> that because this sub function is only ca
ShellPkg: Do not write the UNICODE BOM on ConOut.
When UNICODE data is being written to ConOut, skip over any BOM that is
present at the beginning of the buffer to be written (that is, do not
output the BOM to the screen).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by:
On Thu, 2016-02-18 at 14:43 +0100, Laszlo Ersek wrote:
>
> > Actually, in practice is *isn't* so bad. Given that we don't update our
> > EDKII_openssl-1.0.2X.patch very often (if at all) between OpenSSL
> > releases, what happens is that your build tree ends up with *multiple*
> > CryptoPkg/Librar
On 02/18/16 13:14, Laszlo Ersek wrote:
> Okay, I'm done ranting.
>
> Reviewed-by: Laszlo Ersek
So let me review how my comments have worked out for this posting.
First I nacked it, because I thought the fact was not sufficiently
appreciated that David had posted a conflicting / more comprehens
On 02/18/16 14:19, David Woodhouse wrote:
> Doesn't git
> convert automatically if it finds LF in the files it checks out, on
> Windows?
No clue. Never used git on Windows.
> And if things do get checked out with LF-only line endings on
> Windows, isn't that *also* harmless?
I don't think so. I
On 02/18/16 13:59, David Woodhouse wrote:
[snip ;)]
> Please trim citations. You didn't have to cite the *entire* patch just
> to say that it seems right!
>
> You aren't one of the Outlook-afflicted. We need you to set an example
> of how email is actually *supposed* to be used :)
Some people t
On Thu, 2016-02-18 at 14:12 +0100, Laszlo Ersek wrote:
>
> > And even if we've missed the chance to do it "in retrospect" for
> > historical commits in our canonical git repository, we could still make
> > a commit now which *changes* the line endings to what git expects, and
> > quite soon this w
On 02/18/16 13:59, David Woodhouse wrote:
> On Thu, 2016-02-18 at 13:40 +0100, Laszlo Ersek wrote:
>>> We should not be carrying patches which *differ* from the fixes that
>>> went into OpenSSL upstream.
>>
>> So yeah, I guess the recent irrelevance of this edk2-only hunk should
>> have been "obvio
On Thu, 2016-02-18 at 13:14 +0100, Laszlo Ersek wrote:
> This patch seems right.
Please trim citations. You didn't have to cite the *entire* patch just
to say that it seems right!
You aren't one of the Outlook-afflicted. We need you to set an example
of how email is actually *supposed* to be used
On Thu, 2016-02-18 at 13:40 +0100, Laszlo Ersek wrote:
> > We should not be carrying patches which *differ* from the fixes that
> > went into OpenSSL upstream.
>
> So yeah, I guess the recent irrelevance of this edk2-only hunk should
> have been "obvious" from the 3000-line diff between OpenSSL 1.
tangent:
On 02/18/16 13:40, Laszlo Ersek wrote:
> https://github.com/lersek/edk2/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#maint-07
> https://github.com/lersek/edk2/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-05
Sigh. Clearly I paste
On 02/18/16 12:40, David Woodhouse wrote:
> On Thu, 2016-02-18 at 00:33 +0800, Qin Long wrote:
>>
>> crypto/pkcs7/pk7_smime.c Thu Jun 11 21:01:06 2015
>> -+++ crypto/pkcs7/pk7_smime.c Fri Jun 12 11:23:38 2015
>> +--- crypto/pkcs7/pk7_smime.c Thu Jan 28 21:56:08 2016
>> crypto/pkcs7/
On 18 February 2016 at 13:17, Laszlo Ersek wrote:
> On 02/18/16 12:56, Ard Biesheuvel wrote:
>> The PropertiesTable feature is poorly named, since the feature this PCD
>> controls is only a single bit in its MemoryProtectionAttribute member,
>> called EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_E
On 02/18/16 12:56, Ard Biesheuvel wrote:
> The PropertiesTable feature is poorly named, since the feature this PCD
> controls is only a single bit in its MemoryProtectionAttribute member,
> called EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA.
>
> This feature causes breakage on
On 02/17/16 17:33, Qin Long wrote:
> OpenSSL has released version 1.0.2f with two security fixes
> (http://www.openssl.org/news/secadv/20160128.txt) at 28-Jan-2016.
> Upgrade the supported OpenSSL version in CryptoPkg/OpensslLib
> to catch the latest release 1.0.2f.
> (NOTE: The patch file was just
On 10 February 2016 at 14:07, Shivamurthy Shastri
wrote:
> error: pNicDevice variable set but not used
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Shivamurthy Shastri
Whilst I don't use this, I can see the variable is indeed set but not used.
Reviewed-by: Ryan H
The PropertiesTable feature is poorly named, since the feature this PCD
controls is only a single bit in its MemoryProtectionAttribute member,
called EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA.
This feature causes breakage on legacy OSes that assume that each memory
region in
On Thu, 2016-02-18 at 00:33 +0800, Qin Long wrote:
>
> crypto/pkcs7/pk7_smime.c Thu Jun 11 21:01:06 2015
> -+++ crypto/pkcs7/pk7_smime.c Fri Jun 12 11:23:38 2015
> +--- crypto/pkcs7/pk7_smime.c Thu Jan 28 21:56:08 2016
> crypto/pkcs7/pk7_smime.c Wed Feb 17 16:22:45 2016
> @@ -25
On 02/18/16 12:21, Shivamurthy Shastri wrote:
> Hi All,
>
> Please let me know your opinion about this patch.
The subject of your patch doesn't identify the top-level package that
the patch touches: OptionRomPkg.
You also didn't CC the maintainer(s) of OptionRomPkg on your posting
(see "Maintain
On 02/18/16 12:20, David Woodhouse wrote:
> On Thu, 2016-02-18 at 09:50 +0100, Laszlo Ersek wrote:
>> On 02/18/16 09:44, Long, Qin wrote:
>>> Thanks for raising this, Laszlo.
>>>
>>> Exactly, the posted patch series from David also included one
>> 1.0.2f enabling. The patch series will bring one
Hi All,
Please let me know your opinion about this patch.
--
Thanks and Regards,
Shivamurthy Shastri,
M: +919742508553, IRC: shiva_murthy,
*Linaro.org* |Open Source Software for ARM SOCs
-- Forwarded message --
From: Shivamurthy Shastri
Date: 10 February 2016 at 19:42
Subjec
On Thu, 2016-02-18 at 09:50 +0100, Laszlo Ersek wrote:
> On 02/18/16 09:44, Long, Qin wrote:
> > Thanks for raising this, Laszlo.
> >
> > Exactly, the posted patch series from David also included one
> 1.0.2f enabling. The patch series will bring one direct / smooth
> supports for EDKII-CryptoPkg
1 - 100 of 121 matches
Mail list logo
