Re: [edk2] [PATCH] MdeModulePkg: add PartitionName protocol

My concern is the name string is also not reliable. Different partition tools may have different naming rules. Yes, "private protocol" I meant is using it as your local implementation. Last, still has a little curious on your usage model, could you explain it more? Maybe there is a better way

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

I agreed ScsiDisk misses the handling for EFI_BAD_BUFFER_SIZE. That's why I proposed a patch although it's not good:-) The uncertain part from my side at previous discussion is about the value of In/OutTransferLength when EFI_BAD_BUFFER_SIZE is returned. In UEFI spec, there are two sentences

Re: [edk2] [patch] MdeModulePkg: PXE Driver's LoadFile protocol should check FilePath

Reviewed-by: Fu Siyuan -Original Message- From: Zhang, Lubo Sent: Wednesday, September 9, 2015 5:09 PM To: edk2-devel@lists.01.org Cc: Fu, Siyuan ; Ye, Ting Subject: [patch] MdeModulePkg: PXE Driver's LoadFile protocol

Re: [edk2] [PATCH] MdeModulePkg: add PartitionName protocol

Michael, IMHO, I don't think it's valuable to introducing this new protocol to get a name string. It's too burden. If only you have this use case, I would suggest you implement it as a private protocol rather than the public one. PS: Why UniquePartitionGUID doesn't work for your case? Thanks

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

On 09/09/15 09:11, Tian, Feng wrote: > I agreed ScsiDisk misses the handling for EFI_BAD_BUFFER_SIZE. That's why I > proposed a patch although it's not good:-) > > The uncertain part from my side at previous discussion is about the value of > In/OutTransferLength when EFI_BAD_BUFFER_SIZE is

[edk2] [patch] MdeModulePkg: PXE Driver's LoadFile protocol should check FilePath

PXE driver's LoadFile protocol should check the input parameter FilePath to see whether it's a supported device path.If not, it should return invalid parameter, do not continue PXE boot. Cc: Fu Siyuan Cc: Ye Ting Contributed-under: TianoCore Contribution

[edk2] Why I get assert in PCD\Dxe\Service.c

Dear PCD module owner, I have meet an assert in PCDDXE UDK2014 revision. The Assert happens when PCDdxe initlize. ASSERT e:\code\MdeModulePkg\Universal\PCD\Dxe\Service.c(1137): TokenNumber + 1 < mPcdTotalTokenCount + 1 it seems that build tool automatically generate PEI and DXE token number

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

Reviewed-by: Liming Gao -Original Message- From: Qiu, Shumin Sent: Tuesday, September 08, 2015 3:05 PM To: edk2-devel@lists.01.org Cc: Qiu, Shumin; Carsey, Jaben; Gao, Liming Subject: [PATCH] MdePkg: Refine UefiFileHandleLib to avoid write non-ASCII char into

Re: [edk2] OVMF BoF @ KVM Forum 2015

On 08/10/15 18:24, Laszlo Ersek wrote: > Hi. > > Let's do an OVMF BoF at this year's KVM Forum too. Here's a preliminary task list, after some off-list discussion (I tried to incorporate comments): - create GPL'd fork called "ovmf" for expediting virt development (OvmfPkg, ArmVirtPkg) -

[edk2] [patch] NetworkPkg: PXE Driver's LoadFile protocol should check FilePath

PXE driver's LoadFile protocol should check the input parameter FilePath to see whether it's a supported device path.If not, it should return invalid parameter, do not continue PXE boot. Cc: Fu Siyuan Cc: Ye Ting Contributed-under: TianoCore Contribution

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

On 2015/9/9 13:34, Tian Feng wrote: 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

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

Unfortunately I missed the replies but I debugged this problem further and the Problem is that GenFw set's the alignment based on "sh_addralign" in the Elf header. The 'common-page-size' flag doesn't change the value of this field though. what it does change is the Alignment value of the Program

Re: [edk2] [PATCH] MdeModulePkg: add PartitionName protocol

UniquePartitionGUID isn't suitable because the device vendor's don't set proper values(they're auto generated each time the partition table changes). Instead names like "boot" are used so you can find the correct partition. by "Implement it as a private protocol" do u just mean "use your own

Re: [edk2] [PATCH] BaseTools/GenFw: align RVA of debug

On 9 September 2015 at 11:46, Gao, Liming wrote: > Ard: > Dose this patch fix Section Alignment of elf binaries compiled with > GCC(Linux) reported by Michael Zimmermann ? > No. This fixes a problem on 32-bit ARM where the debug entry is

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

On 09/09/15 11:37, Ian Campbell wrote: > On Wed, 2015-09-09 at 01:06 -0600, Jan Beulich wrote: > On 09.09.15 at 00:23, wrote: >>> On 09/08/15 19:26, Anthony PERARD wrote: And I get this on the console: Welcome to GRUB! X64 Exception Type - 0E(#PF -

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

On 09/09/2015 13:07, Ian Campbell wrote: > I have a question: What attack vector is setting the stack as Nx in OVMF > (or even UEFI generally) trying to protect against? Or is this being done > for a reason other than security? > > I understand why it is done for kernels and apps, but where

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

On 09/09/15 13:07, Ian Campbell wrote: > On Wed, 2015-09-09 at 12:48 +0200, Laszlo Ersek wrote: > > Thanks for all the info, I think I get it (although its not clear to me > whether how an app can claim to be UEFI 2.5 capable and what the transition > plan for legacy applications was going to

[edk2] [PATCH v2 1/2] MdeModulePkg: ScsiDiskDxe: recognize EFI_BAD_BUFFER_SIZE

Acting specifically upon this error condition from UefiScsiLib (and ultimately from EFI_EXT_SCSI_PASS_THRU_PROTOCOL.PassThru()) in the - ScsiDiskRead10(), - ScsiDiskWrite10(), - ScsiDiskRead16(), - ScsiDiskWrite16() functions allows us to retry these operations from ScsiDiskReadSectors() and

[edk2] [PATCH v2 0/2] MdeModulePkg: ScsiDiskDxe: handle EFI_BAD_BUFFER_SIZE from SCSI host adapter

No changes in either patch, relative to what has been discussed / proposed in the v1 thread. I *think* Feng's Reviewed-by in already covers both patches, but I'm not 100% sure, therefore I'm reposting in order for Feng to

[edk2] [PATCH v2 2/2] MdeModulePkg: ScsiDiskDxe: adapt SectorCount when shortening transfers

The specification of the EFI_EXT_SCSI_PASS_THRU_PROTOCOL.PassThru() function documents the EFI_BAD_BUFFER_SIZE return status, and the EFI_EXT_SCSI_STATUS_HOST_ADAPTER_DATA_OVERRUN_UNDERRUN host adapter status. These allow an EFI_EXT_SCSI_PASS_THRU_PROTOCOL implementation to request higher layers

Re: [edk2] [PATCH v2 5/5] ArmPkg/Mmu: Fix potential page table memory leak

On 9 September 2015 at 11:53, Heyi Guo wrote: > During page entry attribute update, if there are table entries > between starting BlockEntry and LastBlockEntry, table entries will be > set as block entries and the allocated memory of the tables will be > leaked. > > so we

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

On 09/09/15 13:30, Paolo Bonzini wrote: > > > On 09/09/2015 13:07, Ian Campbell wrote: >> I have a question: What attack vector is setting the stack as Nx in OVMF >> (or even UEFI generally) trying to protect against? Or is this being done >> for a reason other than security? >> >> I understand

[edk2] [PATCH v2 2/5] ArmPkg/Mmu: Fix page level calculation bug

The bug can be triggered when alignment of Base is larger than Length by 2 level of page granularity, e.g. Base is 0x4000_, Length is 0x1000 The original code will change 2MB page level and we will get a negative remaining length. Contributed-under: TianoCore Contribution Agreement 1.0

[edk2] [PATCH v2 5/5] ArmPkg/Mmu: Fix potential page table memory leak

During page entry attribute update, if there are table entries between starting BlockEntry and LastBlockEntry, table entries will be set as block entries and the allocated memory of the tables will be leaked. so we break the inner loop when we find a table entry and run outer loop again to step

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

The code has a simple bug on calculating aligned page table address. We can just use AllocateAlignedPages in MemoryAllocationLib instead. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Heyi Guo Cc: Leif Lindholm Cc: Ard

[edk2] [PATCH] BaseTools/GenFw: align RVA of debug

SVN commit r18077 ("BaseTools/GenFw: move .debug contents to .data to save space") removed the separate .debug section after moving its contents into .text or .data. However, this change does not take into account that some of these contents need to appear at a 32-bit aligned offset. So align the

Re: [edk2] [PATCH] BaseTools/GenFw: align RVA of debug

On 9 September 2015 at 11:54, Gao, Liming wrote: > Ard: > He reports that the 'common-page-size' flag doesn't work. When he > configures its value to 4096, the alignment in the converted EFI image is > still default 32. Could you help check it? > > The detail report is

Re: [edk2] [PATCH] BaseTools/GenFw: align RVA of debug

Ard: Dose this patch fix Section Alignment of elf binaries compiled with GCC(Linux) reported by Michael Zimmermann ? Thanks Liming -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Wednesday, September 09, 2015 5:44 PM To:

Re: [edk2] [PATCH v2 3/5] ArmPkg/Mmu: Fix literal number left shift bug

On 9 September 2015 at 11:53, Heyi Guo wrote: > There is a hidden bug for below code: > > (1 << BaseAddressAlignment) & *BlockEntrySize > > From disassembly code, we can the literal number 1 will be treated as > INT32 by compiler by default, and we'll get 0x8000

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

On 9 September 2015 at 11:53, Heyi Guo wrote: > The code has a simple bug on calculating aligned page table address. > We can just use AllocateAlignedPages in MemoryAllocationLib instead. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Heyi Guo

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

On 09/08/15 19:35, Ard Biesheuvel wrote: > 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

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

On 09/08/15 19:35, Ard Biesheuvel wrote: > 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

Re: [edk2] [PATCH v2 5/5] ArmPkg/Mmu: Fix potential page table memory leak

On 9 September 2015 at 12:35, Ard Biesheuvel wrote: > On 9 September 2015 at 11:53, Heyi Guo wrote: >> During page entry attribute update, if there are table entries >> between starting BlockEntry and LastBlockEntry, table entries will be >> set as

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

On 9 September 2015 at 15:59, Laszlo Ersek wrote: > On 09/08/15 19:35, Ard Biesheuvel wrote: >> 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:

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

On Tue, Sep 08, 2015 at 07:35:40PM +0200, Ard Biesheuvel wrote: > 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 >

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

On 09/09/15 14:08, Jan Beulich wrote: On 09.09.15 at 12:48, wrote: >> Personally I think that this dynamic approach is overkill (mainly >> because I'm fine with being unable to install Debian Wheezy guests, both >> wearing and not wearing my red fedora; and because the

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

On 09/08/15 19:35, Ard Biesheuvel wrote: > 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

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

On Wed, Sep 09, 2015 at 05:11:33PM +0200, Ard Biesheuvel wrote: > On 9 September 2015 at 16:53, Leif Lindholm wrote: > > On Wed, Sep 09, 2015 at 04:38:08PM +0200, Ard Biesheuvel wrote: > >> On 9 September 2015 at 16:31, Leif Lindholm > >>

Re: [edk2] Why I get assert in PCD\Dxe\Service.c

> On Sep 9, 2015, at 12:28 AM, 王晓峰 wrote: > > Dear PCD module owner, > I have meet an assert in PCDDXE UDK2014 revision. The Assert happens when > PCDdxe initlize. > ASSERT e:\code\MdeModulePkg\Universal\PCD\Dxe\Service.c(1137): TokenNumber + > 1 < mPcdTotalTokenCount

Re: [edk2] [PATCH 2/2] ShellPkg: Fix Shell fail with redundant space following delay number.

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 2/2] ShellPkg: Fix

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

On 09/09/15 18:17, Jordan Justen wrote: > On 2015-09-09 01:57:51, Laszlo Ersek wrote: >> On 08/10/15 18:24, Laszlo Ersek wrote: >>> Hi. >>> >>> Let's do an OVMF BoF at this year's KVM Forum too. >> >> Here's a preliminary task list, after some off-list discussion (I tried >> to incorporate

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

Yes I'm using 32bit ARM :) thx for the patches - unfortunatelythe patches fail for me. On Wed, Sep 9, 2015 at 5:33 PM, Ard Biesheuvel wrote: > On 9 September 2015 at 17:26, Gao, Liming wrote: > > Michael: > > Do you use the linker script

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

> On Sep 9, 2015, at 7:38 AM, Ard Biesheuvel wrote: > > On 9 September 2015 at 16:31, Leif Lindholm > wrote: >> On Tue, Sep 08, 2015 at 07:35:40PM +0200, Ard Biesheuvel wrote: >>> Make sure that the PEI

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

what I meant is that git am fails: Applying: BaseTools/GenFw: remove ARM and RVCT references from ELF64 code error: patch failed: BaseTools/Source/C/GenFw/Elf64Convert.c:360 error: BaseTools/Source/C/GenFw/Elf64Convert.c: patch does not apply Patch failed at 0001 BaseTools/GenFw: remove ARM and

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

On Wed, Sep 09, 2015 at 04:38:08PM +0200, Ard Biesheuvel wrote: > On 9 September 2015 at 16:31, Leif Lindholm wrote: > > On Tue, Sep 08, 2015 at 07:35:40PM +0200, Ard Biesheuvel wrote: > >> Make sure that the PEI memory region is carved out of memory that is > >> 32-bit

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

On 9 September 2015 at 16:53, Leif Lindholm wrote: > On Wed, Sep 09, 2015 at 04:38:08PM +0200, Ard Biesheuvel wrote: >> On 9 September 2015 at 16:31, Leif Lindholm wrote: >> > On Tue, Sep 08, 2015 at 07:35:40PM +0200, Ard Biesheuvel wrote: >>

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

Michael: Do you use the linker script BaseTools/Scripts/GccBase.lds and -z common-page-size=4096? Thanks Liming From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com] Sent: Wednesday, September 9, 2015 3:22 PM To: Yao, Jiewen Cc: Gao, Liming; edk2-devel@lists.01.org Subject: Re: [edk2]

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

On 9 September 2015 at 16:31, Leif Lindholm wrote: > On Tue, Sep 08, 2015 at 07:35:40PM +0200, Ard Biesheuvel wrote: >> 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

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

On 9 September 2015 at 17:26, Gao, Liming wrote: > Michael: > Do you use the linker script BaseTools/Scripts/GccBase.lds and -z > common-page-size=4096? > Are you building for 32-bit ARM by any chance? That does not have this feature wired up yet. I posted a v2 of my

[edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

On 2015-09-09 01:57:51, Laszlo Ersek wrote: > On 08/10/15 18:24, Laszlo Ersek wrote: > > Hi. > > > > Let's do an OVMF BoF at this year's KVM Forum too. > > Here's a preliminary task list, after some off-list discussion (I tried > to incorporate comments): > > - create GPL'd fork called "ovmf"

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

> On 9 sep. 2015, at 18:10, Michael Zimmermann wrote: > > Yes I'm using 32bit ARM :) > thx for the patches - unfortunatelythe patches fail for me. > Did you regenerate Conf/tools_def.txt and rebuild the BaseTools/ ? >> On Wed, Sep 9, 2015 at 5:33 PM, Ard

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

> I don’t understand the issue BSD licensed code? > It should be compatible with the GPL? > The GPL code could merge bug fixes from the BSD > source base as needed. It is just the BDS source > base that can not take back GPL code. I'm not sure I understand, I presume you understand all BSD/GPL

Re: [edk2] [Xen-devel] OVMF BoF @ KVM Forum 2015

On 09/09/15 18:34, Ian Campbell wrote: > On Wed, 2015-09-09 at 10:57 +0200, Laszlo Ersek wrote: >> On 08/10/15 18:24, Laszlo Ersek wrote: >>> Hi. >>> >>> Let's do an OVMF BoF at this year's KVM Forum too. >> >> Here's a preliminary task list > > Thanks for including xen-devel in this. Was anyone

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

> On Sep 9, 2015, at 3:24 PM, Jordan Justen wrote: > > On 2015-09-09 12:11:26, El-Haj-Mahmoud, Samer wrote: >> The recent expansions beyond BSD where all permissive licenses (BSD >> like) as far as I can tell. >> >> I agree with Andrew, opening the door for GPL

Re: [edk2] [PATCH v2 0/2] MdeModulePkg: ScsiDiskDxe: handle EFI_BAD_BUFFER_SIZE from SCSI host adapter

Series Reviewed-by: Feng Tian Thanks Feng -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Wednesday, September 09, 2015 17:39 To: edk2-de...@ml01.01.org Cc: Tian, Feng Subject: [PATCH v2 0/2] MdeModulePkg: ScsiDiskDxe: handle

Re: [edk2] [PATCH] MdeModulePkg: add PartitionName protocol

Michael Is there a spec about the GPT partition naming rule in Android world? Could you share the link? If these GPT partitions have special naming rules (boot, recovery…), why they don’t define specific partition type guid just like EFI SYSTEM PARTITION to distinguish them? For example, EFI

Re: [edk2] [patch] NetworkPkg: PXE Driver's LoadFile protocol should check FilePath

Reviewed-by: Ye Ting -Original Message- From: Zhang, Lubo Sent: Wednesday, September 09, 2015 5:10 PM To: edk2-devel@lists.01.org Cc: Fu, Siyuan; Ye, Ting Subject: [patch] NetworkPkg: PXE Driver's LoadFile protocol should check FilePath PXE driver's LoadFile

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

On 2015-09-09 20:26:54, Andrew Fish wrote: > > On Sep 9, 2015, at 5:41 PM, Jordan Justen wrote: > > On 2015-09-09 16:05:20, Andrew Fish wrote: > >> So you have a legal degree and are speaking on behalf of your > >> employer on this subject? > > > > No and no. How about

Re: [edk2] UEFI and NIST SP-147 compliance

Of all the gin joints in all the towns in all the world, Blibbet had to walk into mine at 11:14:29 on Wednesday 09 September 2015 and say: > I have some questions about UEFI and the below excerpts from NIST > SP-147, from sections 3.1.1 and 3.2. > > Is this "gold master image" possible with

Re: [edk2] [Xen-devel] OVMF BoF @ KVM Forum 2015

On 09/09/15 18:34, Ian Campbell wrote: > On Wed, 2015-09-09 at 10:57 +0200, Laszlo Ersek wrote: >> On 08/10/15 18:24, Laszlo Ersek wrote: >>> Hi. >>> >>> Let's do an OVMF BoF at this year's KVM Forum too. >> >> Here's a preliminary task list > > Thanks for including xen-devel in this. Was anyone

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

> On Sep 9, 2015, at 9:17 AM, Jordan Justen wrote: > > On 2015-09-09 01:57:51, Laszlo Ersek wrote: >> On 08/10/15 18:24, Laszlo Ersek wrote: >>> Hi. >>> >>> Let's do an OVMF BoF at this year's KVM Forum too. >> >> Here's a preliminary task list, after some off-list

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

yes, I tested it and it works. I use Linaro's linux-gnueabi 4.9 toolchain from here: http://releases.linaro.org/15.05/components/toolchain/binaries/arm-linux-gnueabi/ I've copied the manifest info so you don't have to download the toolchain: http://pastebin.com/jvyPcMkz On Wed, Sep 9, 2015 at

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

Short term an OVMF-centric solution is good. But long term, I think Linux needs a Linux-friendly IBV to build native UEFI -- as well as OVMF-flavored UEFI -- with non-BSD licensed community code. If you restrict this to just OVMF, any GPL innovations will only happen at virtual level. Right now,

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

On 09/09/15 18:21, Michael Zimmermann wrote: > what I meant is that git am fails: > Applying: BaseTools/GenFw: remove ARM and RVCT references from ELF64 code > error: patch failed: BaseTools/Source/C/GenFw/Elf64Convert.c:360 > error: BaseTools/Source/C/GenFw/Elf64Convert.c: patch does not apply >

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

thx, the patches work just fine.(they apply and the runtime warnings are gone). if edk2 patches aren't that usable, how the maintainers test it? because usually people don't post git links. On Wed, Sep 9, 2015 at 6:31 PM, Ard Biesheuvel wrote: > On 9 September 2015 at

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

On 9 September 2015 at 18:49, Michael Zimmermann wrote: > thx, the patches work just fine.(they apply and the runtime warnings are > gone). OK, great. May I take that as a tested-by? Which GCC version are you using btw? > if edk2 patches aren't that usable, how the

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

On 2015-09-09 10:04:50, Andrew Fish wrote: > > > On Sep 9, 2015, at 9:17 AM, Jordan Justen wrote: > > > > So, related to this, I wonder how the community would feel about a > > GplDriverPkg. Would the community allow it as a new package in EDK II > > directly, or

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

> On Sep 9, 2015, at 10:02 AM, Ard Biesheuvel wrote: > >> >> >> The 1:1 mapping only goes to 4 GB, so anything beyond that is never >> mapped anyway. >> >> >> This is the state when you hand off to the OS, but it is possible as part of >> the boot process to have

Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)

On 09/09/15 18:49, Michael Zimmermann wrote: > thx, the patches work just fine.(they apply and the runtime warnings are > gone). > if edk2 patches aren't that usable, how the maintainers test it? because > usually people don't post git links. For shorter series, they are willing to mangle some

[edk2] [PATCH] ArmPlatformPkg/ARMJunoPkg: Correct Interrupt Numbers for PCIe Root port

Support for PCI IO range with ACPI on JUNO. Interrupt Number Reference: http://www.arm.com/files/pdf/DDI0515D1a_juno_arm_development_platform_soc_trm.pdf table 3-3 page 3-7 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Supreeth Venkatesh

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

Well, FatPkg is only superficially permissive and not even open source, so there is a precedent. (A precedent that, I might add, happens to violate SourceForge's the off service). When we import edk2 into Fedora we just remove FatBinPkg. We would think twice before contributing to it, but do

Re: [edk2] UEFI and NIST SP-147 compliance

On 09/09/2015 11:49 AM, Bill Paul wrote: [...] > Oh sure, no pressure. > > As you say, the closed source nature of most BIOSes makes complying with these > requirements nearly impossible for most organizations. The only exceptions I > can think of are big companies with connections to the IBVs