Re: [edk2] [PATCH]: CorebootPayloadPkg: Remove data alignment restriction to support GCC49

Another question. Why did you send this to ml01.01.org rather than lists.01.org? It seems that either works, but as far as I can see the list page indicates that the domain is lists.01.org. (I'm just wondering if we need to change some web page that lists the other domain...) Thanks, -Jordan On

Re: [edk2] [PATCH]: CorebootPayloadPkg: Remove data alignment restriction to support GCC49

On 2015-07-17 21:23:16, Scott Duplichan wrote: > Gcc 4.9 produces data alignments of up to 64 bytes. Previous gcc > versions align data at up to 32 bytes. With GCC49, this difference > causes CorebootPayloadPkg to hang after PeCoffLoaderLoadImage() sets > ImageError to IMAGE_ERROR_INVALID_SECTION_A

[edk2] [PATCH]: CorebootPayloadPkg: Remove data alignment restriction to support GCC49

Gcc 4.9 produces data alignments of up to 64 bytes. Previous gcc versions align data at up to 32 bytes. With GCC49, this difference causes CorebootPayloadPkg to hang after PeCoffLoaderLoadImage() sets ImageError to IMAGE_ERROR_INVALID_SECTION_ALIGNMENT and returns an error. This change removes the

Re: [edk2] Boot fail with gcc 4.9

Laszlo Ersek [mailto:ler...@redhat.com] wrote: ]Sent: Friday, July 17, 2015 04:20 PM ]To: Scott Duplichan ]Cc: Ni, Ruiyu ; 'Jordan Justen' ; 'edk2-devel@lists.01.org' ]; 'Maurice Ma' ; 'Yingke D Liu' ; ]'Prince Agyeman' ]Subject: Re: [edk2] Boot fail with gcc 4.9 ] ]On 07/17/15 22:36, Scott D

Re: [edk2] [PATCH] EmbeddedPkg: Added Marvell Yukon Ethernet support

On 2015-07-17 07:43:09, Leif Lindholm wrote: > On Thu, Jul 16, 2015 at 10:22:02AM -0700, Jordan Justen wrote: > > On 2015-07-16 09:11:38, Olivier Martin wrote: > > > This change adds support for the PCI Marvell Yukon Ethernet > > > controller. > > > This ethernet controller can be found on the ARM

Re: [edk2] [edk2-devel] 1 day until new edk2-devel email list transition

On 07/17/15 21:27, Gabriel L. Somlo wrote: > On Fri, Jul 17, 2015 at 12:02:12PM -0700, Jordan Justen wrote: >> Do you promise to never reply to a digest? :) > > Yes Sir, I do !!! :) > >> Replies to digests seem fairly useless to me. The digest process >> messes up the In-reply-to header, so the r

Re: [edk2] Boot fail with gcc 4.9

On 07/17/15 22:36, Scott Duplichan wrote: > I am seeing a boot hang after building CorebootPayloadPkg using gcc 4.9. > Gcc 4.8 and gcc5 don't have this problem. The hang is because of a sanity > check in BasePeCoff.c: > > // > // Make sure the allocated space has the proper section alignment >

Re: [edk2] Boot fail with gcc 4.9

There are recent related BaseTools commits: edd7249/r18016 BaseTools: Fixed incorrect alignment bug. 0c5645e/r17728 BaseTools: Update GenFw to support 4K alignment. f384efd/r17727 BaseTools: Updated tool_def to support 4K alignment. These were make for 4k alignment support, but maybe they could

[edk2] Boot fail with gcc 4.9

I am seeing a boot hang after building CorebootPayloadPkg using gcc 4.9. Gcc 4.8 and gcc5 don't have this problem. The hang is because of a sanity check in BasePeCoff.c: // // Make sure the allocated space has the proper section alignment // if (!(ImageContext->IsTeImage)) { if ((Image

Re: [edk2] [RFC PATCH 0/8] small C model and LLVM/clang support for AARCH64

On 17 July 2015 at 21:53, Andrew Fish wrote: > > On Jul 17, 2015, at 12:37 PM, Ard Biesheuvel > wrote: > > On 17 July 2015 at 21:28, Andrew Fish wrote: > > > On Jul 17, 2015, at 12:07 PM, Cohen, Eugene wrote: > > Ard, > > The bottom line is that we are still losing around 40 KB on padding in >

Re: [edk2] [RFC PATCH 0/8] small C model and LLVM/clang support for AARCH64

> On Jul 17, 2015, at 12:37 PM, Ard Biesheuvel > wrote: > > On 17 July 2015 at 21:28, Andrew Fish > wrote: >> >>> On Jul 17, 2015, at 12:07 PM, Cohen, Eugene wrote: >>> >>> Ard, >>> The bottom line is that we are still losing around 40 KB on padding in to

Re: [edk2] [RFC PATCH 0/8] small C model and LLVM/clang support for AARCH64

On 17 July 2015 at 21:28, Andrew Fish wrote: > >> On Jul 17, 2015, at 12:07 PM, Cohen, Eugene wrote: >> >> Ard, >> >>> The bottom line is that we are still losing around 40 KB on padding in >>> total, >> >> If I understand correctly you're saying because of limitations in the >> AArch64 LLVM/cl

Re: [edk2] [RFC PATCH 0/8] small C model and LLVM/clang support for AARCH64

On 17 July 2015 at 21:07, Cohen, Eugene wrote: > Ard, > >> The bottom line is that we are still losing around 40 KB on padding in total, > > If I understand correctly you're saying because of limitations in the AArch64 > LLVM/clang toolchain we must suffer some sort of code size increase (of whic

Re: [edk2] [RFC PATCH 0/8] small C model and LLVM/clang support for AARCH64

> On Jul 17, 2015, at 12:07 PM, Cohen, Eugene wrote: > > Ard, > >> The bottom line is that we are still losing around 40 KB on padding in total, > > If I understand correctly you're saying because of limitations in the AArch64 > LLVM/clang toolchain we must suffer some sort of code size incre

Re: [edk2] [edk2-devel] 1 day until new edk2-devel email list transition

On Fri, Jul 17, 2015 at 12:02:12PM -0700, Jordan Justen wrote: > Do you promise to never reply to a digest? :) Yes Sir, I do !!! :) > Replies to digests seem fairly useless to me. The digest process > messes up the In-reply-to header, so the reply doesn't get threaded > properly. The reply subjec

Re: [edk2] [RFC PATCH 0/8] small C model and LLVM/clang support for AARCH64

Ard, > The bottom line is that we are still losing around 40 KB on padding in total, If I understand correctly you're saying because of limitations in the AArch64 LLVM/clang toolchain we must suffer some sort of code size increase (of which you made great progress in minimizing) because of its

Re: [edk2] [edk2-devel] 1 day until new edk2-devel email list transition

On 2015-07-17 07:45:24, Gabriel L. Somlo wrote: > Hi Jordan, > > > "The list administrator has disabled digest delivery for this list, so > > your delivery option has not been set. However your other options have > > been set successfully" > > Any chance that restriction can be lifted ? I like to

[edk2] [Patch] ShellPkg: Fix bad TimeZone (TZ) conversion.

EFI_UNSPECIFIED_TIMEZONE means display local time. TZ of 0 is UTC. Thus EFI_UNSPECIFIED_TIMEZONE means ignore TZ, 0 means UTC. When this code is fixed to adust file TZ to local TZ you need to preserve EFI_UNSPECIFIED_TIMEZONE. FAT always return EFI_UNSPECIFIED_TIMEZONE. Modern filesystems, HFS+, N

[edk2] [PATCH] BaseTools/Common: fix heap overrun in ReadMemoryFileLine ()

ReadMemoryFileLine () appends a NULL character to the string it returns, but it failed to account for it in the allocation. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Source/C/Common/MemoryFile.c | 2 +- 1 file changed, 1 insertion(+), 1 d

Re: [edk2] [PATCH] Maintainers.txt: ARM packages maintainer update

On 17 July 2015 at 16:59, Olivier Martin wrote: > Reviewed-by; Olivier Martin Thanks. > ... last email and last minutes at ARM Ltd! So long, good luck, and thanks for getting us going, and up to speed, with UEFI. ___ edk2-devel mailing list edk2-deve

Re: [edk2] [PATCH] Maintainers.txt: ARM packages maintainer update

On 17 July 2015 at 17:51, Leif Lindholm wrote: > Retire Olivier Martin as maintainer, and add in > Ard Biesheuvel as a co-maintainer for the ARM packages. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Leif Lindholm Reviewed-by: Ard Biesheuvel > --- > Maintainers

Re: [edk2] [RFC PATCH] MdeModulePkg: account for disjoint code and data regions in runtime relocations

On 16 July 2015 at 15:57, Matt Fleming wrote: > On Fri, 10 Jul, at 04:23:58PM, Ard Biesheuvel wrote: >> >> Is there a reason to set strict permissions at all on the 1:1 mapping? >> Does it stick around after having called SVAM () ? >> >> My (naive) suggestion would be to apply the strict permissio

[edk2] [PATCH] Maintainers.txt: ARM packages maintainer update

Retire Olivier Martin as maintainer, and add in Ard Biesheuvel as a co-maintainer for the ARM packages. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Leif Lindholm --- Maintainers.txt | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Maintain

Re: [edk2] [edk2-devel] 1 day until new edk2-devel email list transition

Hi Jordan, > "The list administrator has disabled digest delivery for this list, so > your delivery option has not been set. However your other options have > been set successfully" Any chance that restriction can be lifted ? I like to keep an eye on the developments by skimming through the messa

Re: [edk2] [PATCH] EmbeddedPkg: Added Marvell Yukon Ethernet support

On Thu, Jul 16, 2015 at 10:22:02AM -0700, Jordan Justen wrote: > On 2015-07-16 09:11:38, Olivier Martin wrote: > > This change adds support for the PCI Marvell Yukon Ethernet > > controller. > > This ethernet controller can be found on the ARM Juno development > > platform. > > The UEFI driver has

Re: [edk2] [RFC PATCH 6/8] ArmVirtPkg: merge .text and .data in 4 KB section aligned XIP modules

On 07/17/15 15:44, Ard Biesheuvel wrote: > On 17 July 2015 at 14:51, Laszlo Ersek wrote: >> On 07/17/15 14:21, Ard Biesheuvel wrote: >>> To prevent the bloat associated with rounding when using 4 KB section >>> alignment, merge the .text and .data section for XIP modules, by >>> providing a dedica

Re: [edk2] [RFC PATCH 6/8] ArmVirtPkg: merge .text and .data in 4 KB section aligned XIP modules

On 17 July 2015 at 14:51, Laszlo Ersek wrote: > On 07/17/15 14:21, Ard Biesheuvel wrote: >> To prevent the bloat associated with rounding when using 4 KB section >> alignment, merge the .text and .data section for XIP modules, by >> providing a dedicated linker script, and wiring it up in the .DSC

Re: [edk2] [RFC PATCH 6/8] ArmVirtPkg: merge .text and .data in 4 KB section aligned XIP modules

On 07/17/15 14:21, Ard Biesheuvel wrote: > To prevent the bloat associated with rounding when using 4 KB section > alignment, merge the .text and .data section for XIP modules, by > providing a dedicated linker script, and wiring it up in the .DSC. > > Contributed-under: TianoCore Contribution Agr

Re: [edk2] [RFC PATCH 0/8] small C model and LLVM/clang support for AARCH64

BTW code is available here: https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/basetools-te-alignment On 17 July 2015 at 14:21, Ard Biesheuvel wrote: > Warning: long email ahead. TL;DR: with some reshuffling of the binaries, we > can > mitigate the fallout of increas

Re: [edk2] [RFC PATCH 1/8] ArmVirtPkg: use 'auto' alignment for XIP modules

First observation: this mailing list doesn't strip Cc's from reflected messages. Yay! Second observation: matching my settings on the list's web UI, I've got two copies (and my new filter filed each correctly in the right folder). Hurrah! On 07/17/15 14:21, Ard Biesheuvel wrote: > AARCH64 XIP cod

Re: [edk2] repo hosting, sigh

On Fri, Jul 17, 2015 at 01:48:59PM +0200, Laszlo Ersek wrote: > I know that we're getting what we've paid for. But seriously... Not really: sourceforge is well-known as the worst of the worst for open source hosting nowadays. At this point it's almost as if we're deliberately sabotaging our own pr

[edk2] [RFC PATCH 8/8] BaseTools: enable small C model for AARCH64/GCC

This enables the use of the small C model for AARCH64. Since this requires 4 KB section alignment, the linker script is updated as well. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Conf/tools_def.template | 2 +- BaseTools/Scripts/gcc

[edk2] [RFC PATCH 7/8] BaseTools/GenFw: allow AArch64 small model relocations

The AArch64 small C model makes extensive use of ADRP/ADD and ADRP/{LDR,STR} pairs to emit PC-relative symbol references with a +/- 4 GB range. Since the relocation pair splits the relative offset into a relative page offset and an absolute offset into a 4 KB page, we need to take extra care to ens

[edk2] [RFC PATCH 6/8] ArmVirtPkg: merge .text and .data in 4 KB section aligned XIP modules

To prevent the bloat associated with rounding when using 4 KB section alignment, merge the .text and .data section for XIP modules, by providing a dedicated linker script, and wiring it up in the .DSC. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- ArmV

[edk2] [RFC PATCH 2/8] BaseTools/GenFw: move .debug contents to .data to save space

In order to reduce the memory footprint of PE/COFF images when using large values for the PE/COFF section alignment, move the contents of the .debug section to data, and point the debug data directory entry to it. This allows us to drop the .debug section entirely, as well as any associated roundin

[edk2] [RFC PATCH 4/8] BaseTools: use GUID identifiable section for FFS alignment padding

Instead of using anonymous sections of type EFI_SECTION_RAW for padding out FFS TE sections to adhere to the global file alignment, use a section with a dedicated GUID if the size of the padding permits it. This allows for more flexibility when placing such FFS images in a firmware volume, because

[edk2] [RFC PATCH 5/8] BaseTools/GenFv: optimize away redundant padding

To prevent double padding of XIP modules leading to excessive waste of FV space, try to adjust existing padding rather than adding more. Instead of adding a pad file to the FV to line up an FFS file that itself may contain padding to line up the payload, try to find a dedicated padding section in

[edk2] [RFC PATCH 3/8] BaseTools/GenFw: move PE/COFF header closer to payload

The secondary header (not the DOS header) of a PE/COFF binary does not reside at a fixed offset. Instead, its offset into the file is recorded in the DOS header. This gives us the flexibility to move it, along with the section headers, to right before the first section if there is considerable spa

[edk2] [RFC PATCH 0/8] small C model and LLVM/clang support for AARCH64

Warning: long email ahead. TL;DR: with some reshuffling of the binaries, we can mitigate the fallout of increasing the section alignment to 4 KB, which is a prerequisite for proper support of LLVM and the GCC small C model for AArch64. This is an RFC series, although there are few controversial ch

[edk2] [RFC PATCH 1/8] ArmVirtPkg: use 'auto' alignment for XIP modules

AARCH64 XIP code may require 2 KB alignment if it contains exception vector tables, so ensure that the PE/COFF images are correctly aligned when added to the firmware volume. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- ArmVirtPkg/ArmVirtQemu.fdf | 6

Re: [edk2] repo hosting, sigh

> On Jul 17, 2015, at 4:48 AM, Laszlo Ersek wrote: > > Sourceforge.net developer services have been down for almost a day now. > I could not access the web based version, to browse code. Now it makes sense. Thanks, Andrew Fish > https://twitter.com/sfnet_ops > > I cannot access SVN. > >

[edk2] repo hosting, sigh

Sourceforge.net developer services have been down for almost a day now. https://twitter.com/sfnet_ops I cannot access SVN. I know that we're getting what we've paid for. But seriously... Here's another data point. In last September I filed a ticket with sf.net (#8529 -- "unable to commit to EDK

Re: [edk2] [PATCH 2/6] OvmfPkg: SmbiosPlatformDxe: restrict current Xen code to IA32/X64

On 17 July 2015 at 09:44, Jordan Justen wrote: > (Changed to the new list. Hopefully all interested parties have > subscribed...) > > On 2015-07-16 23:45:31, Ard Biesheuvel wrote: >> On 17 July 2015 at 01:11, Laszlo Ersek wrote: >> > So, the GUID-ed HOB that stores various Xen info is X86 specifi

Re: [edk2] [PATCH 2/6] OvmfPkg: SmbiosPlatformDxe: restrict current Xen code to IA32/X64

(Changed to the new list. Hopefully all interested parties have subscribed...) On 2015-07-16 23:45:31, Ard Biesheuvel wrote: > On 17 July 2015 at 01:11, Laszlo Ersek wrote: > > So, the GUID-ed HOB that stores various Xen info is X86 specific. Code > > that depends on the HOB (or looks for the HOB