[edk2] [PATCH] MdePkg: Refine UefiFileHandleLib to avoid write non-ASCII char into ASCII file.

Cc: Jaben Carsey Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Qiu Shumin --- MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 7 +++ 1 file changed, 7 insertions(+) diff

Re: [edk2] Help debugging PEIM on Minnowboard Max

Hi, Eric >From XHCI spec view, there is no data buffer alignment requirement for control >transfer (you can refer to XHCI1.0 section 6.4.1.2.2 Table 72). So I don't know why you found 16 byte alignment issue for reading usb device/config descriptor. Did you ensure the device descriptor you get

Re: [edk2] [PATCH] MdeModulePkg: ScsiDiskDxe: adapt SectorCount when shortening transfers

On 08/09/2015 09:02, Tian, Feng wrote: > Hi, Laszlo > > 1. I don't think the code in VirtioScsi.c is correct. It hardcodes > the block size as 512bytes. The driver should send READ_CAPACITY cmd to get > block size, then convert it to InTransferLength & OutTransferLength. This is the

Re: [edk2] [PATCH] ArmPlatformPkg/ArmJunoPkg/Madt.aslc: Fix MADT header version

Fair enough. Sudeep - can you point me to how I can verify the behaviour of these patches? Has Al's sanity checking gone into 4.3 merge window, or do I need to add it from elsewhere? Regards, Leif On Mon, Sep 07, 2015 at 06:53:55PM +0100, Ryan Harkin wrote: > Hi Sudeep, > > I'm not involved

Re: [edk2] [PATCH] ArmPlatformPkg/ArmJunoPkg/Madt.aslc: Fix MADT header version

On 08/09/15 11:02, Leif Lindholm wrote: Fair enough. Sudeep - can you point me to how I can verify the behaviour of these patches? Has Al's sanity checking gone into 4.3 merge window, or do I need to add it from elsewhere? No, not yet made to upstream kernel, but I briefly checked now and

[edk2] How do I get rid of /ALIGN:32 ?

Seems to be a linker option by default when I compile EDK2. I want to get rid of it.         "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Vc\bin\x86_amd64\link.exe" /OUT:c:\edk2\myworkspace\Build\DuetPkgX64\DEBUG_VS2010x86\X64\MdeModulePkg\Application\testPTU\testPTU\DEBUG\testPTU.dll

Re: [edk2] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/08/15 19:26, Anthony PERARD wrote: > On Fri, Aug 28, 2015 at 10:17:28AM +0200, Laszlo Ersek wrote: >> On 08/08/15 02:02, Zeng, Star wrote: -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo Ersek Sent: Saturday, August

[edk2] [PATCH v2 2/4] BaseTools/GenFw: make ARM's .data adhere to PE/COFF section alignment

There is a special case in the ElfConvert code where ARM's .data is not aligned to section alignment, presumably to preserve the relative offset between .text and .data in the presence of relative relocations that are not recomputed at PE/COFF conversion time. This violates the PE/COFF spec, so

[edk2] [PATCH v2 1/4] BaseTools/GenFw: remove ARM and RVCT references from ELF64 code

ARM and RVCT apply to 32-bit code only, so remove any references to them from the 64-bit version of ElfConvert.c Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Source/C/GenFw/Elf64Convert.c | 17 + 1

[edk2] [PATCH v2 3/4] BaseTools/ARM: move to unified GCC linker script

Instead of using the ARM builtin linker script for GNU ld, use the new unified one instead. This will allow us to increase the section alignment for DXE_RUNTIME_MODULEs, which is a prerequisite for enabling the UEFIv2.5 Properties Table memory protection feature. Also, remove the

[edk2] [PATCH v2 4/4] ArmVirtPkg: use 4 KB section alignment for ARM DXE_RUNTIME modules

In order to support the Properties Table memory protection feature on 32-bit ARM, build DXE_RUNTIME_MODULE type binaries with 4 KB section alignment by setting the common-page-size linker command line option. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel

Re: [edk2] [PATCH] MdePkg: Refine UefiFileHandleLib to avoid write non-ASCII char into ASCII file.

Reviewed-by: Jaben Carsey > -Original Message- > From: Qiu, Shumin > Sent: Tuesday, September 08, 2015 12:05 AM > To: edk2-devel@lists.01.org > Cc: Qiu, Shumin ; Carsey, Jaben > ; Gao, Liming >

Re: [edk2] How do I get rid of /ALIGN:32 ?

Shubha: You can override it in [BuildOptions] section of your DSC file. You can see the example in Nt32Pkg\Nt32Pkg.dsc file that overrides its value to 4096. [BuildOptions] DEBUG_*_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x1 /ALIGN:4096 /FILEALIGN:4096

Re: [edk2] [PATCH 1/4] ArmPkg/Mmu: Fix bug of aligning new allocated page table

On 09/07/2015 06:17 PM, Ard Biesheuvel wrote: On 7 September 2015 at 10:41, Heyi Guo wrote: On 09/06/2015 07:43 PM, Ard Biesheuvel wrote: On 6 September 2015 at 10:15, Heyi Guo wrote: The code has a simple bug on calculating aligned page table

Re: [edk2] [PATCH 1/2] ShellPkg: Fix 'for' command fail with multiple fields.

Reviewed-by: Jaben Carsey > -Original Message- > From: Qiu, Shumin > Sent: Sunday, September 06, 2015 8:06 PM > To: edk2-devel@lists.01.org > Cc: Qiu, Shumin ; Carsey, Jaben > > Subject: [PATCH 1/2] ShellPkg: Fix

[edk2] [PATCH 0/3] large memory support for 32-bit ARM

Some changes are needed to support memory over the 4 GB mark on 32-bit ARM, e.g., qemu with more than 3 GB. Ard Biesheuvel (3): ArmPlatformPkg/MemoryInitPeim: handle memory above 4 GB on 32-bit ARM ArmVirtPkg/ArmVirtMemoryInitPeiLib: handle memory above 4 GB on 32-bit ARM ArmVirtPkg:

[edk2] [PATCH 1/3] ArmPlatformPkg/MemoryInitPeim: handle memory above 4 GB on 32-bit ARM

Make sure that the PEI memory region is carved out of memory that is 32-bit addressable, by taking MAX_ADDRESS into account (which is defined as '4 GB - 1' on ARM) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ---

[edk2] [PATCH 3/3] ArmVirtPkg: set max physical address width to 40 bits

When executing on a LPAE capable 32-bit ARM platform, we support up to 40 bits of physical address space so set PcdPrePiCpuMemorySize accordingly. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- ArmVirtPkg/ArmVirt.dsc.inc | 3

[edk2] [PATCH 2/3] ArmVirtPkg/ArmVirtMemoryInitPeiLib: handle memory above 4 GB on 32-bit ARM

On 32-bit ARM, split system memory into a region below (and up to) 4 GB and a region above 4 GB. This is necessary to get the DXE core to consider the former as the resource descriptor that describes the primary memory region that also covers the PHIT region. Contributed-under: TianoCore

[edk2] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [PATCH] OvmfPkg: prevent code execution from DXE stack)

On Fri, Aug 28, 2015 at 10:17:28AM +0200, Laszlo Ersek wrote: > On 08/08/15 02:02, Zeng, Star wrote: > >> -Original Message- > >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > >> Laszlo Ersek > >> Sent: Saturday, August 8, 2015 12:00 AM > >> To: edk2-devel-01 >

Re: [edk2] [PATCH 1/4] ArmPkg/Mmu: Fix bug of aligning new allocated page table

On 9 September 2015 at 05:16, Heyi Guo wrote: > > > On 09/07/2015 06:17 PM, Ard Biesheuvel wrote: >> >> On 7 September 2015 at 10:41, Heyi Guo wrote: >>> >>> >>> On 09/06/2015 07:43 PM, Ard Biesheuvel wrote: On 6 September 2015 at 10:15, Heyi

Re: [edk2] [Patch] MdeModulePkg: Fix a performance data buffer overrun issue

On 2015/9/9 13:36, Ruiyu Ni wrote: The mBmPerfHeader.Count isn't reset to 0 in BmWriteBootToOsPerformanceData() so when the actual performance data entry count exceeds the LimitCount, the performance data collection breaks on condition if (mBmPerfHeader.Count == LimitCount), but 2nd time calling

[edk2] [patch] MdePkg/UefiScsiLib: comments update to add EFI_INVALID_PARAMETER status

EFI_SCSI_IO_PROTOCOL has alignment requirement on any data buffer used in SCSI data transfer. As a wrap of this protocol, UefiScsiLib have same request. Adding EFI_INVALID_PARAMETER return status in function comments to ask the caller to guarantee this alignment. Contributed-under: TianoCore

[edk2] [Patch] MdeModulePkg: Fix a performance data buffer overrun issue

The mBmPerfHeader.Count isn't reset to 0 in BmWriteBootToOsPerformanceData() so when the actual performance data entry count exceeds the LimitCount, the performance data collection breaks on condition if (mBmPerfHeader.Count == LimitCount), but 2nd time calling this function will not break on