Ard: I did more discussion with Dennis. We don't think this update can resolve my case. We suggest to add SUB GUID section for FFS file that has only one SECTION with the specific alignment. If so, after GenFv adjusts SUB GUID section, it will have no impact on other section data. And, after this change, GenFv tool also requires to update FFS HEAD to remove alignment value, because the updated FFS doesn't meet with FFS alignment requirement.
Thanks Liming -----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Monday, July 27, 2015 3:04 AM To: Gao, Liming; Liu, Yingke D; edk2-devel@lists.01.org Cc: Leif Lindholm; eugene.co...@hp.com; Ard Biesheuvel Subject: Re: [PATCH 0/4] FFS/FV aligment optimization (was: [RFC] small C model and LLVM/clang support for AARCH64) On 22 July 2015 at 19:25, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 22 July 2015 at 19:21, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: >> These patches have been split off from the series 'small C model and >> LLVM/clang support for AARCH64', primarily because >> - I found out there is a tiny code model for GCC which is even better than >> the >> small model >> - there are better ways to implement the other size optimizations that apply >> to >> the ARM platform and virt packages. >> >> So this subset only deals with the basetools optimizations to get rid >> of excessive XIP alignment padding when using 2 KB or 4 KB alignment, >> which is common on AARCH64, since the exception vector table requires >> 2 KB alignment, and the small code model (which is the only one >> supported by the commercial LLVM based compiler supplied by ARM) >> requires 4 KB alignment. As it turns out, LLVM does support a large >> model, but it is even less suitable for PE/COFF conversion, because >> all absolute address are packed into series of moz/movk instructions, and >> are not relocatable using COFF fixups. >> >> Patches #1 and #2 (formerly #2 and #3) are unchanged. >> >> Patch #3 (formerly #4) has been updated to ensure that a special >> reducible padding section is only emitted right before the first >> section in a FFS that has alignment requirements. Reducing the size >> of such a section will shift all subsequent sections into alignment, >> provided that the size of the padding is sufficient. In some cases, >> for instance, when the padding section is based on a section that has >> a minimum alignment of 32 bytes, and is followed by a section which >> requires 4 KB alignment, the size of the padding section may be too >> small and the adjustment will not be possible. In this case, we >> simply proceed as if the padding section is an ordinary padding section, and >> everything will just work as before. >> > > Forgot to add: I dropped the GenSec changes, and only changed GenFfs > this time, since I don't need it for my use case, and section inside > other section may be a bit complicated to reason about right now. > >> Patch #4 is unchanged, except for a clarification in the comments, to >> explain that the misalignment is calculated based on the first byte >> of the FFS payload, and not of the aligned section. Since all FFS >> sections are padded out relative to the first byte of the FFS >> payload, compensating its misalignment will shift all sections into place. >> >> Ard Biesheuvel (4): >> BaseTools/GenFw: move .debug contents to .data to save space >> BaseTools/GenFw: move PE/COFF header closer to payload >> BaseTools: use GUID identifiable section for FFS alignment padding >> BaseTools/GenFv: optimize away redundant padding >> > > Branch is here: > https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/re > fs/heads/ffs-fv-alignment-optimization > @Dennis: may I kindly ask you to share your opinion on these patches as well? I think #1 and #2 are mostly uncontroversial (and Liming thinks they are fine), but #3 and #4 may require more discussion and careful review. Note that his series results in considerable space saving for PE/COFF binaries with 2 KB or 4 KB section alignment, so they are important for AARCH64. Kind regards, Ard. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
