[PATCH] grub2 should not unzip Linux initramfs

2013-11-12 Thread Lukas Schwaighofer
Hi, the initramfs protocol (see [1]) supports multiple concatenated archives. Because of grub2's implicit unzipping of gz-compressed multiboot modules, a valid initramfs-file (e.g. in my case containing of two concatenated gz-files) may be rendered unbootable. I have attached the trivial patch a

Re: [PATCH] grub2 should not unzip Linux initramfs

2013-11-12 Thread Vladimir 'φ-coder/phcoder' Serbinenko
Committed, thanks. On 12.11.2013 11:25, Lukas Schwaighofer wrote: > Hi, > > the initramfs protocol (see [1]) supports multiple concatenated archives. > > Because of grub2's implicit unzipping of gz-compressed multiboot > modules, a valid initramfs-file (e.g. in my case containing of two > concate

Feature Request: add a command to get/set (U)EFI firmware variables

2013-11-12 Thread SevenBits
Greetings everyone: I want to request a feature for GRUB that will improve on its usability on the (U)EFI platform. Specifically, a command to get/set (U)EFI firmware variables using (U)EFI system calls. Let me take a moment to explain why it is necessary and what it could be used for. For those

[RFT] Use pair of shifts instead of and in ARM code

2013-11-12 Thread Vladimir 'φ-coder/phcoder' Serbinenko
1ff and 3fff can't be easily loaded on ARM. This patch replaces load+and with pair of shift to keep only wanted bits. diff --git a/grub-core/kern/arm/cache_armv7.S b/grub-core/kern/arm/cache_armv7.S index 0c16b10..454bad3 100644 --- a/grub-core/kern/arm/cache_armv7.S +++ b/grub-core/kern/arm/cache

[PATCH 3/4] efi: Support GRUB_MMAP_MALLOC_LOW in the EFI firmware allocator

2013-11-12 Thread Josh Triplett
EFI supports allocating memory below a specified address; use that to implement GRUB_MMAP_MALLOC_LOW by requesting memory below 1M. --- ChangeLog entry: 2013-11-13 Josh Triplett * include/grub/efi/memory.h (GRUB_MMAP_MALLOC_LOW): Define. * grub-core/mmap/efi/mmap.c (grub_mmap_

[PATCH 0/4] i386-efi and x86_64-efi fixes

2013-11-12 Thread Josh Triplett
The first three patches improve the EFI firmware allocator, fixing some bugs in the process. The last patch fixes many compilation-specific and firmware-specific crashes. To avoid unnecessary patch conflicts, I've included appropriately formatted ChangeLog entries for each patch separately in eac

[PATCH 2/4] efi: Fix requests to allocate GRUB_MEMORY_AVAILABLE

2013-11-12 Thread Josh Triplett
EFI firmware refuses to allocate memory of type GRUB_EFI_CONVENTIONAL_MEMORY, because that indicates a block of available memory that other allocations (or the OS) would then step on. Map GRUB_MEMORY_AVAILABLE to GRUB_EFI_LOADER_CODE instead. --- ChangeLog entry: 2013-11-13 Josh Triplett

[PATCH 1/4] efi: Fix firmware memory allocation to round to 4k pages, not 1k

2013-11-12 Thread Josh Triplett
EFI memory allocation operates in 4k pages, but the firmware memory allocator used 0x3ff in several places rather than 0xfff. --- ChangeLog entry: 2013-11-13 Josh Triplett * grub-core/mmap/efi/mmap.c (grub_mmap_register): Round up/down to 4k page boundaries as expected by fi

[PATCH 4/4] efi: On x86-64, align the stack to a 16-byte boundary as required by ABI

2013-11-12 Thread Josh Triplett
The x86-64 ABI specification requires a 16-byte-aligned stack. In some cases, GCC emits code that assumes this alignment, which crashes if not aligned. The EFI firmware is also entitled to assume that stack alignment without checking, and some firmware does make that assumption. --- ChangeLog en

Re: [PATCH 3/4] efi: Support GRUB_MMAP_MALLOC_LOW in the EFI firmware allocator

2013-11-12 Thread Andrey Borzenkov
В Tue, 12 Nov 2013 18:26:39 -0800 Josh Triplett пишет: > EFI supports allocating memory below a specified address; use that to > implement GRUB_MMAP_MALLOC_LOW by requesting memory below 1M. Out of curiosity - why would you need it on EFI? Your patch does not add any consumer of GRUB_MMAP_MALLOC