[edk2] [PATCH v2 2/7] BaseTools/Tests: Always add BaseTools source to import path

This allows unit tests to easily include BaseTools python modules. This is very useful for writing unit tests. Actually, previously, we would do this when RunTests.py was executed, so unit tests could easily import BaseTools modules, so long as they were executed via RunTests. This change allows

[edk2] [PATCH v2 3/7] BaseTools/EdkLogger: Support unit tests with a SILENT log level

This allows the unit tests to run without the errors logging to the screen. Cc: Yingke D Liu Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen --- BaseTools/Source/Python/Common/EdkLogger.py | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff -

[edk2] [PATCH v2 1/7] BaseTools: Support UTF-8 string data in .uni files

Since UEFI only support UTF-16LE strings internally, this simply allows for another unicode the source file encoding. The strings are still converted to UTF-16LE data for use in EDK II source code. When .uni files contain UTF-16 data, it is impossible for unicode code points to be larger than 0xF

[edk2] [PATCH v2 5/7] BaseTools/Tests: Verify 32-bit UTF-8 chars are rejected

Since UTF-8 .uni unicode files might contain strings with unicode code points larger than 16-bits, and UEFI only supports UTF-16 characters, we need to make sure that BaseTools rejects these strings. Cc: Yingke D Liu Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Ju

[edk2] [PATCH v2 6/7] BaseTools/Tests: 32-bit unicode chars are allowed in comments

In .utf8 files, there is the possibility that 32-bit unicode code points might be used in comments. While a 32-bit unicode code points should be dissallowed in string data, it should be allowed in comments. Cc: Yingke D Liu Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: J

[edk2] [PATCH v2 0/7] Support UTF-8 in .uni string files

https://github.com/jljusten/edk2.git utf8-v2 v2: * Drop .utf8 extension. Use .uni file for UTF-8 data (mdkinney) The UTF-16 .uni files are fairly annoying to work with: * They must be checked in as 'binary' files * It is difficult to produce a diff of changes * UTF-8 is more likely to be support

[edk2] [PATCH v2 7/7] OvmfPkg/PlatformDxe: Convert Platform.uni to UTF-8

This command was used to convert the file: iconv -f UTF-16 -t UTF-8 \ -o OvmfPkg/PlatformDxe/Platform.uni \ OvmfPkg/PlatformDxe/Platform.uni Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen Reviewed-by: Laszlo Ersek --- Below shows a perfect example

[edk2] [PATCH v2 4/7] BaseTools/Tests: Add unit test for AutoGen.UniClassObject

This verifies that a UTF-16 data (with BOM) .uni file is successfully read. Cc: Yingke D Liu Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen --- BaseTools/Tests/CheckUnicodeSourceFiles.py | 77 ++ BaseTools/Tests/PythonToolsTests.

Re: [edk2] [PATCH v2 1/7] BaseTools: Support UTF-8 string data in .uni files

Jordan: BaseTools UPT (Source\Python\UPT\Library\UniClassObject.py) also parses UNI file. Could you update it together? Or, you expect UPT tool owner to follow up? Thanks Liming -Original Message- From: Jordan Justen [mailto:jordan.l.jus...@intel.com] Sent: Tuesday, May 05, 2015 3:09

Re: [edk2] [PATCH] BaseTools: add support for gcc 5.1 tool chain

Jordan: GCC number is mentioned as below. GCC 5.1 and 5.2 are from GCC 5 branch. If 5.1 is named to GCC5, what's name for 5.2? 5.1.0 for the first release from the GCC 5 branch 5.1.1 during development on the branch post the 5.1.0 release 5.2.0 for the second release from the GCC 5 branch 5.2.1

[edk2] Building the firmware with CSM

Hi, I was interested about building the firmware with CSM. I see that in IntelFrameworkModulePkg was some folders with drivers for Legacy Bios Module to support CSM. Problem: What I need to do for building the firmware with CSM ? Best regards, Anteja

Re: [edk2] update on SMM for OVMF

On 05/04/15 23:13, Jordan Justen wrote: > On 2015-05-04 11:03:08, Laszlo Ersek wrote: >> On 05/04/15 17:55, Paolo Bonzini wrote: >>> On 04/05/2015 15:58, Laszlo Ersek wrote: So here's the *specific* issues I'm facing (and need help with): * Problem #1 for task (4): Because

Re: [edk2] update on SMM for OVMF

On 04/05/2015 15:58, Laszlo Ersek wrote: > I audited all PCDs used by PiSmmCpuDxeSmm carefully. Most of them are > fixed or feature PCDs, fine. However, there are two dynamic PCDs that > carry important information (and we can't just go with a default): > - PcdCpuConfigContextBuffer > - PcdCpuS3D

[edk2] [PATCH 2/4] ArmVExpressPkg: use named GUIDs for all VExpress variants

Instead of using open coded GUIDs, define them only once, and refer to them by name everywhere else. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/AArch64/ArmFvpDxeAArch64.c | 17 - ArmPlatf

[edk2] [PATCH 1/4] ArmPkg: fix pointer indirection bug in BdsFirmwareVolumeLoadImage()

The EFI_FIRMWARE_VOLUME2_PROTOCOL::EFI_FV_READ_SECTION prototype takes a pointer to a pointer to an output buffer, so we should pass the address of the Image pointer and not its value. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- ArmPkg/Library/BdsLib

[edk2] [PATCH 0/4] ArmVExpressPkg: use embbeded DTBs for AArch64 FVP models

This enhances the recently introduced FDT loading support by adding and enabling support for embedded DTBs in the AArch64 FVP model platforms. Patch #1 fixes a bug in the BdsLoadImage() implementation. Patch #2 reworks some of the ArmVExpressPkg platform identification logic so that GUIDs are onl

[edk2] [PATCH 3/4] ArmPlatformPkg: add support for FV embedded device tree blobs

This adds support to the ArmVExpressPkg platforms to load their device tree binary from a Firmware Volume if one is found that matches the current platform. If none is found, the existing logic to find a FDT by name from a file system is retained as a fallback. Contributed-under: TianoCore Contrib

[edk2] [PATCH 4/4] ArmVExpressPkg: add embedded DTB blobs for all FVP AArch64 variants

This adds DTBs for all AArch64 FVP platform variants so that they can be loaded straight from the firmware image instead of from a file system. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf

[edk2] [PATCH] EmbeddedPkg: do not ASSERT() on valid external input

Since ASSERT()s are enabled even on all ArmPlatformPkg RELEASE builds, ASSERT()ing on a valid FDT header will crash the firmware if the user selects an incorrect file. Since ASSERT() is meant to catch internal inconsistencies in the firmware, its use here is inappropriate. Instead, handle it as a

Re: [edk2] [PATCH] EmbeddedPkg: do not ASSERT() on valid external input

Reviewed-By: Olivier Martin -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: 05 May 2015 13:19 To: Olivier Martin; edk2-devel@lists.sourceforge.net; Ronald Cron Cc: leif.lindh...@linaro.org; roy.fr...@linaro.org; Ard Biesheuvel Subject: [PATCH] EmbeddedPkg:

Re: [edk2] [PATCH 4/4] ArmVExpressPkg: add embedded DTB blobs for all FVP AArch64 variants

It is actually something I was planning to do at some point. The issue is the lack of coherence in the device tree repositories. At the moment, the device trees for ARM development platforms live in two locations: 1. Linux kernel repository 2. The ARM Trusted Firmware repository (https://github.com

Re: [edk2] [PATCH 4/4] ArmVExpressPkg: add embedded DTB blobs for all FVP AArch64 variants

On 5 May 2015 at 15:34, Olivier Martin wrote: > It is actually something I was planning to do at some point. The issue The reason we are proposing it now is that we are trying to eliminate the delta between the Linaro tree and upstream, and building the FVP/AArch64 platforms with the DTB already

Re: [edk2] [PATCH 4/4] ArmVExpressPkg: add embedded DTB blobs for all FVP AArch64 variants

I would be more happy with your new proposal (ie: "!ifdef $(DTB_DIR)"). :-) -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: 05 May 2015 15:15 To: Olivier Martin Cc: leif.lindh...@linaro.org; roy.fr...@linaro.org; edk2-devel@lists.sourceforge.net; ler...@re

[edk2] [PATCH 0/1] OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of PCI bridges

Public branch: https://github.com/lersek/edk2/commits/q35_bridges_boot_order Laszlo Ersek (1): OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of PCI bridges OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c | 118 +++- 1 file changed, 92 insertions(+), 26 deletions(-)

[edk2] [PATCH 1/1] OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of PCI bridges

When the Q35 machine type(s) of QEMU are used with libvirt, libvirt tends to place some devices behind PCI bridges. This is then reflected in the "bootorder" fw_cfg file. For example: /pci@i0cf8/pci-bridge@1e/pci-bridge@1/scsi@5/disk@0,0 /pci@i0cf8/pci-bridge@1e/pci-bridge@1/scsi@3/channel@0/d

Re: [edk2] [PATCH 1/4] ArmPkg: fix pointer indirection bug in BdsFirmwareVolumeLoadImage()

Reviewed-By: Olivier Martin -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: 05 May 2015 12:17 To: Olivier Martin; leif.lindh...@linaro.org; roy.fr...@linaro.org; edk2-devel@lists.sourceforge.net Cc: ler...@redhat.com; Ard Biesheuvel Subject: [PATCH 1/4] A

Re: [edk2] [PATCH] MdeModulePkg/PartitionDxe: Fix media probe

Any update on this patch? From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: 02 April 2015 10:44 To: Ni, Ruiyu; edk2-devel@lists.sourceforge.net Cc: Ronald Cron Subject: Re: [edk2] [PATCH] MdeModulePkg/PartitionDxe: Fix media probe It is likely your change will not test if there is a pres

[edk2] [PATCH 5/5] ArmVExpressPkg: add support for embedding DTBs for AArch64 variants

If DTB_DIR= is set during the build, incorporate DTBs from that path for all AArch64 FVP platform variants so that they can be loaded straight from the firmware image instead of from a file system. This relieves a user of having to keep a DTB file with the right name in the working directory of the

[edk2] [PATCH 4/5] ArmPlatformPkg: add support for FV embedded device tree blobs

This adds support to the ArmVExpressPkg platforms to load their device tree binary from a Firmware Volume if one is found that matches the current platform. If none is found, the existing logic to find a FDT by name from a file system is retained as a fallback. Contributed-under: TianoCore Contrib

[edk2] [PATCH 1/5] EmbeddedPkg: do not ASSERT() on valid external input

Since ASSERT()s are enabled even on all ArmPlatformPkg RELEASE builds, ASSERT()ing on a valid FDT header will crash the firmware if the user selects an incorrect file. Since ASSERT() is meant to catch internal inconsistencies in the firmware, its use here is inappropriate. Instead, handle it as a

[edk2] [PATCH 2/5] ArmPkg: fix pointer indirection bug in BdsFirmwareVolumeLoadImage()

The EFI_FIRMWARE_VOLUME2_PROTOCOL::EFI_FV_READ_SECTION prototype takes a pointer to a pointer to an output buffer, so we should not dereference Image (which is a pointer to pointer type itself) but pass its value directly. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Olivie

[edk2] [PATCH 3/5] ArmVExpressPkg: use named GUIDs for all VExpress variants

Instead of using open coded GUIDs, define them only once, and refer to them by name everywhere else. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/AArch64/ArmFvpDxeAArch64.c | 17 - ArmPlatf

Re: [edk2] [PATCH 3/5] ArmVExpressPkg: use named GUIDs for all VExpress variants

Reviewed-By: Olivier Martin -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: 05 May 2015 15:49 To: Olivier Martin; edk2-devel@lists.sourceforge.net; Ronald Cron Cc: leif.lindh...@linaro.org; roy.fr...@linaro.org; ler...@redhat.com; Ard Biesheuvel Subject:

[edk2] [PATCH 0/5] ArmVExpressPkg: use embbeded DTBs for AArch64 FVP models

Changes since v1: - added separate EmbeddedPkg patch to this series, since Olivier maintains all of it anyway - fix possible uninitialized use of FdtDevicePath in patch #4 - removed DTB blobs from patch #5, and instead use a build define 'DTB_DIR' which -if set- is interpreted as a path pointin

Re: [edk2] [PATCH 0/9] Support UTF-8 (.utf8) string files

On 05/04/2015 05:02 PM, Jordan Justen wrote: > On 2015-05-04 14:32:48, Brian J. Johnson wrote: >> Nice work, Jordan! > > Thanks Brian. Any Reviewed-by from you for the series? :) > > -Jordan > Sorry, my Python-fu is sorely lacking. -- Brian J. John

Re: [edk2] [Patch 1/3] MdePkg : Add Microsoft UX capsule GUID & layout

Forward reference declarations are not required for this file and should be removed. Also, the Image[1] field of the DISPLAY_DISPLAY_PAYLOAD structure should be declared as Image[]. That is the recommended style for new structure declarations that have a variable sized array as the last field

[edk2] Fedlet works well with Ia32 OVMF, please keep it alive [was: update on SMM for OVMF]

Hi Adam, On 05/05/15 10:30, Laszlo Ersek wrote: > (I think I can find an Ia32 UEFI > guest OS -- see eg. .) Not sure about your plans with Fedlet, but I just tested it (the 20141209 release [1]) with Ia32 OVMF (32-bit UEFI firmware for virtual mach

Re: [edk2] [Patch 1/3] MdePkg : Add Microsoft UX capsule GUID & layout

Hello Mike, On 05/05/15 17:35, Kinney, Michael D wrote: > Forward reference declarations are not required for this file and should be > removed. > > Also, the Image[1] field of the DISPLAY_DISPLAY_PAYLOAD structure > should be declared as Image[]. That is the recommended style for new > structu

Re: [edk2] [PATCH] BaseTools: add support for gcc 5.1 tool chain

On 2015-05-05 01:02:53, Gao, Liming wrote: > Jordan: > GCC number is mentioned as below. GCC 5.1 and 5.2 are from GCC 5 > branch. If 5.1 is named to GCC5, what's name for 5.2? > > 5.1.0 for the first release from the GCC 5 branch > 5.1.1 during development on the branch post the 5.1.0 release

Re: [edk2] [PATCH v2 1/7] BaseTools: Support UTF-8 string data in .uni files

Jordan, If we are going to add support for more UNI file formats, there are also EDK II specifications that must be updated. I am not sure I agree with only checking that the string value has supported Unicode characters. If the Name or Language elements have unsupported Unicode characters, t

Re: [edk2] [Patch V2 3/3] MdeModulePkg: Add match2 opcode support in SetupBrowserDxe and sample code in DriverSampleDxe

Changes look good and address my concerns. The entire series can be checked in. Thanks! Series Reviewed-by: Samer El-Haj-Mahmoud -Original Message- From: Eric Dong [mailto:eric.d...@intel.com] Sent: Sunday, May 03, 2015 9:48 PM To: edk2-devel@lists.sourceforge.net; liming@inte

Re: [edk2] [PATCH 1/2] MdePkg: Add UEFI2.5 bluetooth protocol/devicepath definition in MdePkg.

Hi Qiu, Need some help, how far is the Bluetooth supported in the new specs 2.5? Based on 2.4 errata B specs and UDK 2014 release, I have to add the BT stack (HCI/L2CAP) to support BT keyboards? If we know , the upcoming specs provide the Bluetooth protocol, then it will easy for us to add new

Re: [edk2] update on SMM for OVMF

On 05/04/2015 10:55 AM, Paolo Bonzini wrote: > The SMM entry vector will start in a 16-bit real mode code segment, > albeit with 4GB segment limits. So there must be yet another 32-bit > protected mode switching sequence somewhere. So my guess is: > > 1) you can add a 32->64-bit mode world switch

Re: [edk2] update on SMM for OVMF

On 05/05/15 18:42, Brian J. Johnson wrote: > On 05/04/2015 10:55 AM, Paolo Bonzini wrote: >> The SMM entry vector will start in a 16-bit real mode code segment, >> albeit with 4GB segment limits. So there must be yet another 32-bit >> protected mode switching sequence somewhere. So my guess is: >

Re: [edk2] [Patch 1/3] MdePkg : Add Microsoft UX capsule GUID & layout

Laszlo, I agree with the general guidance from that thread. However, data structures with the last field being variable sized has several different styles in use in the UEFI Specifications, PI Specifications, and EDK II implementation. We did an evaluation and determined the flexible array me

Re: [edk2] [PATCH v2 1/7] BaseTools: Support UTF-8 string data in .uni files

On 2015-05-05 00:53:03, Gao, Liming wrote: > Jordan: > BaseTools UPT (Source\Python\UPT\Library\UniClassObject.py) also > parses UNI file. Could you update it together? Or, you expect UPT > tool owner to follow up? UPT doesn't attempt to use any common code? This seems like a waste of effor

Re: [edk2] [PATCH v2 1/7] BaseTools: Support UTF-8 string data in .uni files

On 2015-05-05 09:07:11, Kinney, Michael D wrote: > Jordan, > > If we are going to add support for more UNI file formats, there are > also EDK II specifications that must be updated. I don't know about that. I at least looked under BaseTools/UserManuals, and didn't find anything obvious to update.

Re: [edk2] [Patch 1/2] BaseTools: Enhance the check for numeric opcode with EFI_IFR_DISPLAY_INT_DEC attribute.

Hi Eric, The patch looks good. Best Regards, Aaron From: "Dong, Eric" To: "aaron@congatec.com" , Cc: "edk2-devel@lists.sourceforge.net" , "Gao, Liming" Date: 05/04/2015 10:16 PM Subject:RE: [edk2] [Patch 1/2] BaseTools: Enhance the check for numeric opcode with EF

Re: [edk2] Replacement EDK2 email list coming soon

On 2015-05-04 13:21:38, Peterson, Joe wrote: >Due to community feedback, a new mailing list is being set up to replace >this one. The new list will be hosted on Lists.01.org and should be more >stable and consistent than this one. > >The host has an opt-in policy and will not allow

Re: [edk2] [Patch 1/3] MdePkg : Add Microsoft UX capsule GUID & layout

On 05/05/15 19:34, Kinney, Michael D wrote: > Laszlo, > > I agree with the general guidance from that thread. However, data > structures with the last field being variable sized has several > different styles in use in the UEFI Specifications, PI > Specifications, and EDK II implementation. We d

[edk2] Question about SetPcd

I'm declaring a Pcd with some default value as [PcdsPatchableInModule.common], and here are my observations: 1) In PEIM module1 after SetPcdXX() with a new value and can read back the new value with GetPcdXX() 2) However, from PEIM module2 (which runs later) GetPcdXX() returns the d

Re: [edk2] Question about SetPcd

Leo - PatchableInModule is not what you want, you need DynamicEx. Although Dynamic would also work, I wouldn't recommend it. PatchableInModule builds the value into the .exe data section. In this case, SetPcd only changes that module 's data, not the other modules data. Tim Sent from my Window

Re: [edk2] [Patch 1/3] MdePkg : Add Microsoft UX capsule GUID & layout

Laszlo, Yes. We have verified that this feature is supported by VS toolchains, but we do have to disable warning 4200. I will prepare that patch for review. Thanks, Mike -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Tuesday, May 05, 2015 11:00 AM To: Kinney,

Re: [edk2] Question about SetPcd

Of course, I meant: I'm declaring a Pcd with some default value as [PcdsPatchableInModule.common], and here are my observations: 1) In PEIM module1 after PcdSetXX() with a new value and can read back the new value with PcdGetXX() 2) However, from PEIM module2 (which runs later) PcdGe

Re: [edk2] [PATCH v2 1/7] BaseTools: Support UTF-8 string data in .uni files

Jordan, Here is the link to the EDK II spec that states that UNI files must be UTF16-LE http://sourceforge.net/projects/edk2/files/Specifications/UNI_File_Spec_v1_2_Errata_A.pdf/download I think there are good reasons to verify that the entire UNI file only contains UCS-2 characters. Editors

Re: [edk2] [Patch 1/3] MdePkg : Add Microsoft UX capsule GUID & layout

> The flexible array member is a C99 feature. Is it generally allowed for > edk2 code, as a universally supported extension to the otherwise > mandated C95? > > http://thread.gmane.org/gmane.comp.bios.tianocore.devel/2339/focus=2359 Microsoft C doesn't support C99. Microsoft C is needed for nearly

Re: [edk2] [Patch 1/3] MdePkg : Add Microsoft UX capsule GUID & layout

On 05/05/2015 01:24 PM, Kinney, Michael D wrote: > Laszlo, > > Yes. We have verified that this feature is supported by VS > toolchains, but we do have to disable warning 4200. I will prepare > that patch for review. How about the old WINDDK 3790.1830? It's still a supported toolchain, and is i

Re: [edk2] [PATCH v2 1/7] BaseTools: Support UTF-8 string data in .uni files

On 2015-05-05 11:32:57, Kinney, Michael D wrote: > Jordan, > > Here is the link to the EDK II spec that states that UNI files must > be UTF16-LE > > http://sourceforge.net/projects/edk2/files/Specifications/UNI_File_Spec_v1_2_Errata_A.pdf/download I don't know where the source code is for this d

Re: [edk2] Question about SetPcd

> On May 5, 2015, at 11:26 AM, Duran, Leo wrote: > > Of course, I meant: > > I’m declaring a Pcd with some default value as > [PcdsPatchableInModule.common], and here are my observations: > 1) In PEIM module1 after PcdSetXX() with a new value and can read back > the new value with PcdGe

Re: [edk2] [PATCH v2 1/7] BaseTools: Support UTF-8 string data in .uni files

Jordan, My main point about the spec is that both need to be updated if this concept is accepted. Not that one has to be done before the other. Mike -Original Message- From: Justen, Jordan L Sent: Tuesday, May 05, 2015 11:52 AM To: Kinney, Michael D; edk2-devel@lists.sourceforge.net C

Re: [edk2] Question about SetPcd

> > From: Duran, Leo > > Sent: Tuesday, May 05, 2015 12:49 PM > > To: 'edk2-devel@lists.sourceforge.net' > > Subject: Question about SetPcd > > > > I'm declaring a Pcd with some default value as > [PcdsPatchableInModule.common], and here are my observations: > > 1) In PEIM module1 after PcdSet

[edk2] Question about WinDbg Support-- Target with USB->Serial Adapter.

Hi, Need small clarification, to connect to Host running WinDbg/UEFI debugger tool , do we have support for "USB->Serial Adapter" on Target ? What I see "DebugCommunicationLibSerialPort" is hardcoded to 0x3F8 base address? Unfortunately some of the DELL laptops, doesn't have serial port or us

Re: [edk2] Question about SetPcd

> On May 5, 2015, at 1:16 PM, Duran, Leo wrote: > > Thanks Tim & Andrew. > The PCD lingo can be a confusing. > 1) The .DEC file declares the PCD as: > [PcdsFixedAtBuild.common, PcdsDynamic.common, PcdsPatchableInModule.common] > The .DEC declares the existence of the PCD and the mappings t

Re: [edk2] [PATCH v2 1/7] BaseTools: Support UTF-8 string data in .uni files

On 2015-05-05 13:20:59, Kinney, Michael D wrote: > My main point about the spec is that both need to be updated if this > concept is accepted. Not that one has to be done before the other. Ok. I'll look into the changes you recommended for the code. Regarding the specs, it is too bad that they ar

Re: [edk2] Question about SetPcd

> Date: Tue, 05 May 2015 13:50:38 -0700 > From: Andrew Fish > Subject: Re: [edk2] Question about SetPcd > To: edk2-devel@lists.sourceforge.net > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > > > On May 5, 2015, at 1:16 PM, Duran, Leo wrote: > > > > Thanks Tim & Andrew. > > >

Re: [edk2] [Patch] MdePkg: Add EFI_LOAD_OPTION definition.

Mike, Andrew, I fully agree with your comments that the C structure is not useful in code. I will not add this C structure. All, Any concerns? Thanks, Ray -Original Message- From: Andrew Fish [mailto:af...@apple.com] Sent: Saturday, May 2, 2015 1:49 AM To: edk2-devel@lists.sourceforge.

Re: [edk2] [Patch 1/3] MdePkg : Add Microsoft UX capsule GUID & layout

Brian, Yes. DDK3790 toolchain works when warning 4200 is disabled. Mike -Original Message- From: Brian J. Johnson [mailto:bjohn...@sgi.com] Sent: Tuesday, May 05, 2015 11:43 AM To: edk2-devel@lists.sourceforge.net; Laszlo Ersek; Kinney, Michael D Cc: Zhang, Chao B Subject: Re: [edk2] [

[edk2] [Patch] MdePkg/Include: Add support for flexible array members

Use pragma to disable warning 4200 for all VS* and DDK* toolchains to support data structure declarations where the last field of the data structure is a flexible array member. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney mailto:michael.d.kin...@intel.co

Re: [edk2] [PATCH] BaseTools: add support for gcc 5.1 tool chain

Jordan: Got it. Thanks! -Original Message- From: Justen, Jordan L Sent: Wednesday, May 06, 2015 12:06 AM To: Gao, Liming; edk2-devel@lists.sourceforge.net; Scott Duplichan Subject: Re: [edk2] [PATCH] BaseTools: add support for gcc 5.1 tool chain On 2015-05-05 01:02:53, Gao, Liming wrot

Re: [edk2] [PATCH] MdeModulePkg/PartitionDxe: Fix media probe

Martin, I agree that your patch works. Just wanted to figure out a better patch. But I haven't got chance to do the investigation yet. Thanks, Ray From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Tuesday, May 5, 2015 10:46 PM To: edk2-devel@lists.sourceforge.net; Ni, Ruiyu Cc: Ronald C

Re: [edk2] [Patch] MdePkg/Include: Add support for flexible array members

Hi Mike: I tried VS2008. UINTN Image[] can pass build. Thanks for the patch From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] Sent: Wednesday, May 06, 2015 9:59 AM To: edk2-devel@lists.sourceforge.net Subject: [edk2] [Patch] MdePkg/Include: Add

Re: [edk2] [PATCH] MdeModulePkg: avoid unaligned writes in PcdDxe driver

What is the meaning of "Even if someone decides later on that the PCD database format should use natural alignment for all values, it is still wrong to cast a pointer to void back to a pointer a larger type."? About "Since this patch fixes an actual problem on 32-bit ARM running under virtualiz

Re: [edk2] [PATCH] MdeModulePkg: avoid unaligned writes in PcdDxe driver

On 6 May 2015 at 05:40, Zeng, Star wrote: > What is the meaning of "Even if someone decides later on that the PCD > database format should use natural alignment for all values, it is still > wrong to cast a pointer to void back to a pointer a larger type."? > I am referring to the BaseTools cha

Re: [edk2] [PATCH] MdeModulePkg: avoid unaligned writes in PcdDxe driver

InternalData pointer is from PcdDb + Offset, Offset is from LocalTokenNumber & PCD_DATABASE_OFFSET_MASK, LocalTokenNumber is from TokenNumber. In SetWorker() of Service.c has below code to ensure correct size and then correct aligned internal data to be referenced. if (*Size != DxePcdGetSiz

Re: [edk2] [PATCH] MdeModulePkg: avoid unaligned writes in PcdDxe driver

On 6 May 2015 at 07:40, Zeng, Star wrote: > InternalData pointer is from PcdDb + Offset, Offset is from LocalTokenNumber > & PCD_DATABASE_OFFSET_MASK, LocalTokenNumber is from TokenNumber. > PCD_DATABASE_OFFSET_MASK does not mask any low bits, and TokenNumber is an external input to the function

Re: [edk2] [Patch V2 3/3] MdeModulePkg: Add match2 opcode support in SetupBrowserDxe and sample code in DriverSampleDxe

Eric: The patch is good. Reviewed-by: Liming Gao Thanks Liming -Original Message- From: Dong, Eric Sent: Monday, May 04, 2015 10:48 AM To: edk2-devel@lists.sourceforge.net; Gao, Liming; samer.el-haj-mahm...@hp.com Subject: [Patch V2 3/3] MdeModulePkg: Add match2 opcode support in Setu

[edk2] [Patch 2/2] MdeModulePkg/SmmCore: SMM register protocol notify function clarify

PI 1.4 clarified SMM register protocol notify function return status as below: EFI_SUCCESS Successfully returned the registration record that has been added or unhooked EFI_INVALID_PARAMETER Protocol is NULL or Registration is NULL The implementation of SmmRegisterPr

[edk2] [Patch 0/2] SMM register protocol notify function clarify

PI 1.4 clarified SMM register protocol notify function return status as below: EFI_SUCCESS Successfully returned the registration record that has been added or unhooked EFI_INVALID_PARAMETER Protocol is NULL or Registration is NULL The implementation of SmmRegisterPr

[edk2] [Patch 1/2] MdePkg/PiSmmCis.h: SMM register protocol notify function clarify

PI 1.4 clarified SMM register protocol notify function return status as below: EFI_SUCCESS Successfully returned the registration record that has been added or unhooked EFI_INVALID_PARAMETER Protocol is NULL or Registration is NULL Contributed-under: TianoCore Contr