On 12/12/14 14:57, Peter Maydell wrote: > On 12 December 2014 at 13:52, Laszlo Ersek <ler...@redhat.com> wrote: >> On 12/12/14 14:20, Peter Maydell wrote: >>> If we have a real bootloader in the UEFI firmware, why do we need >>> to do decompression for it? We only do this in the builtin bootloader >>> because QEMU is acting as the bootloader and has to support the >>> feature itself. I would have thought that the UEFI builtin kernel >>> booting support already supported decompressing the kernel... >> >> The "UEFI builtin kernel booting support" will qualify as "builtin" only >> after my 2500 line patch series is merged in edk2. > > I had in mind the support for UEFI loading kernels off > hard disks, which presumably is already present.
Ah, I see. Sure, if you have a kernel image (with the EFI stub) that is an *immediately executable* EFI binary, then you can just go to the UEFI shell, navigate to the filesystem / directory that hosts that image, and run it. (Similarly, PXE boot it etc.) But in this case the EFI binary is compressed with gzip (for aarch64 kernels); you couldn't even run it from the UEFI shell. Or else, if you thought of grub2 loading a kernel from the disk with UEFI protocols -- that works too, but then it's grub that does the decompression. (There's a plethora of ways to boot UEFI kernels, and I've recently asked Matt Fleming if he could write up a comprehensive blog post or similar about all of them. Hopefully the community will be able to refer to an authoritative summary sometime next year.) > >> Zlib decompression is not present in edk2 (it only has a TianoCore >> variant of LZMA), and I didn't want to impede (in the community sense) >> my edk2 patchset even more (ie. beyond its current size) by importing >> libz too. > > Fair enough. This avoids odd inconsistency in compressed kernel > support between the f/w and non f/w setups, anyway. > > If you fix the stray space then > Reviewed-by: Peter Maydell <peter.mayd...@linaro.org> > > thanks > -- PMM > Awesome! Thanks Laszlo
