Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Mon, Sep 2, 2013 at 3:33 AM, Matt Fleming wrote: > On Tue, 13 Aug, at 10:58:16AM, Roy Franz wrote: >> Hi Matt, >> >>Do you have any more feedback on the X86 and common code (patches >> 1-13) that needs to be addressed? Mark Salter has a working ARM64 EFI >> stub implemented based on these patches, so the common code has now >> been tested with another architecture, and he has acked these patches. >> If the current patches are OK, can this be queued for 3.12? (and into >> linux-next, if appropriate) >> The ARM portion may take a little longer based on the EFI runtime >> services patch dependencies, but getting the common code merged would >> allow the ARM64 EFI stub work to go forward independently. >> >> I can resend patches 1-13 as a new series of x86/common only changes >> if you would like. > > I think resending the common patches as a new series, including Acked-by > and Reviewed-by tags, and after addressing Grant's comments is the best > idea. > > We've missed the v3.12 merge window now, but we can certainly get these > into linux-next for some testing. > > -- > Matt Fleming, Intel Open Source Technology Center Thanks Matt - I'll split the common patches out to a new series and resubmit after taking care of Grant's feeback. Thanks, Roy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Tue, 13 Aug, at 10:58:16AM, Roy Franz wrote: > Hi Matt, > >Do you have any more feedback on the X86 and common code (patches > 1-13) that needs to be addressed? Mark Salter has a working ARM64 EFI > stub implemented based on these patches, so the common code has now > been tested with another architecture, and he has acked these patches. > If the current patches are OK, can this be queued for 3.12? (and into > linux-next, if appropriate) > The ARM portion may take a little longer based on the EFI runtime > services patch dependencies, but getting the common code merged would > allow the ARM64 EFI stub work to go forward independently. > > I can resend patches 1-13 as a new series of x86/common only changes > if you would like. I think resending the common patches as a new series, including Acked-by and Reviewed-by tags, and after addressing Grant's comments is the best idea. We've missed the v3.12 merge window now, but we can certainly get these into linux-next for some testing. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Fri, 23 Aug, at 03:40:04PM, Roy Franz wrote: > Hi Matt, > >Do you have a tree I can monitor to see if you have taken this? > Would you like me to split out the x86/common only changes into a > separate series from the ARM changes? I've just returned from my honeymoon. I'll reply to your emails asap. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Fri, 23 Aug, at 03:40:04PM, Roy Franz wrote: Hi Matt, Do you have a tree I can monitor to see if you have taken this? Would you like me to split out the x86/common only changes into a separate series from the ARM changes? I've just returned from my honeymoon. I'll reply to your emails asap. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Tue, 13 Aug, at 10:58:16AM, Roy Franz wrote: Hi Matt, Do you have any more feedback on the X86 and common code (patches 1-13) that needs to be addressed? Mark Salter has a working ARM64 EFI stub implemented based on these patches, so the common code has now been tested with another architecture, and he has acked these patches. If the current patches are OK, can this be queued for 3.12? (and into linux-next, if appropriate) The ARM portion may take a little longer based on the EFI runtime services patch dependencies, but getting the common code merged would allow the ARM64 EFI stub work to go forward independently. I can resend patches 1-13 as a new series of x86/common only changes if you would like. I think resending the common patches as a new series, including Acked-by and Reviewed-by tags, and after addressing Grant's comments is the best idea. We've missed the v3.12 merge window now, but we can certainly get these into linux-next for some testing. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Mon, Sep 2, 2013 at 3:33 AM, Matt Fleming m...@console-pimps.org wrote: On Tue, 13 Aug, at 10:58:16AM, Roy Franz wrote: Hi Matt, Do you have any more feedback on the X86 and common code (patches 1-13) that needs to be addressed? Mark Salter has a working ARM64 EFI stub implemented based on these patches, so the common code has now been tested with another architecture, and he has acked these patches. If the current patches are OK, can this be queued for 3.12? (and into linux-next, if appropriate) The ARM portion may take a little longer based on the EFI runtime services patch dependencies, but getting the common code merged would allow the ARM64 EFI stub work to go forward independently. I can resend patches 1-13 as a new series of x86/common only changes if you would like. I think resending the common patches as a new series, including Acked-by and Reviewed-by tags, and after addressing Grant's comments is the best idea. We've missed the v3.12 merge window now, but we can certainly get these into linux-next for some testing. -- Matt Fleming, Intel Open Source Technology Center Thanks Matt - I'll split the common patches out to a new series and resubmit after taking care of Grant's feeback. Thanks, Roy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Fri, Aug 16, 2013 at 5:16 PM, Roy Franz wrote: > On Tue, Aug 13, 2013 at 10:58 AM, Roy Franz wrote: >> On Fri, Aug 9, 2013 at 4:26 PM, Roy Franz wrote: >>> >>> This patch series adds EFI stub support for the ARM architecture. >>> Some code that was previously only used by x86/x86_64 is now shared >>> and has been made more general. The stub for ARM is implemented in >>> a similar manner to x86 in that it is a shim layer between EFI and >>> the normal zImage/bzImage boot process, and that an image with the >>> stub configured is bootable as both a zImage and EFI application. >>> >>> This patch now (new for v3) series depends on the >>> "arm: Add [U]EFI runtime services support" patches by >>> leif.lindh...@linaro.org. >>> The Kconfig option now depends on the "CONFIG_EFI" option that his series >>> adds, and this option will ensure a little endian configuration. Also, the >>> EFI support is used to handle the EFI memory map the stub passes to the >>> kernel. >>> There are some minor changes to be coordinated with the EFI runtime services >>> patch series, so I have put this back to RFC status. These changes should >>> be >>> minor and relate to final device tree bindings. >>> >>> Changes since v2: >>> * EFI bugfix "correct call to free_pages" that patch series >>> depends on now in mainline >>> * remove "-fno-stack-protector" from decompressor Makefile. The current >>> code doesn't >>> trigger the stack protection, so the decompressor now compiles with it >>> still >>> on. Note that there has never been any stack protection in the >>> decompressor >>> since the stack usage doesn't trigger the heuristic in GCC, so right now >>> the "-fno-stack-protector" is a noop. >>> * Changed EFI command line handling to not have a fixed limit. >>> * Change FDT memory allocation to retry with a larger allocation if >>> first educated guess is inadequate. >>> * Correctly set 'SizeOfCode' in PE/COFF header. >>> * Reviewed ".setup" section that is in x86 PE/COFF header. This is used >>> for x86 >>> to account for code that is not in the .text section. We don't need this >>> for ARM, as all of our code is in the .text section, or in the PE/COFF >>> header >>> itself. >>> * Moved EFI_STUB_ERROR #define to header file to share between stub C and >>> ASM. >>> * Variety of cleanups and fixes in head.S. >>> * Changed update_fdt_and_exit_boot() to just update the device tree, and >>> renamed appropriately. Memory allocations moved out of this function as >>> well, which enables the retries if the initial FDT size is too small. >>> Note that in order to do the retried allocations, the original FDT and >>> command line memory regions are left allocated. This is OK since the >>> kernel >>> has the memory map and will free these allocations along with the initrd >>> and new fdt allocations. >>> * Added prefix to all prints, reduced number of prints, and reviewed all >>> messages. >>> * Change mixed usage of dtb/fdt to all be fdt or "device tree" in efi-stub.c >>> * remove unnecessary zimage_size variable from relocate_kernel() >>> * correct return types on EFI functions - should be efi_status_t, not int. >>> >>> >>> >>> Changes since V1: >>> * Updated head.S based on feedback from Dave Martin. ARM/THUMB >>> switches now much cleaner. >>> * Broke up changes to x86 and common code into more patches. >>> 10 more patches in this series. >>> >>> Roy Franz (16): >>> Move common EFI stub code from x86 arch code to common location >>> Add system pointer argument to shared EFI stub related functions >>> so they no longer use global system table pointer as they did >>> when part of eboot.c. This code is now shared, so using a >>> global variable as part of the interface is not that nice. >>> Also, by avoiding any global variables in the ARM EFI stub, >>> this allows the code to be position independent without >>> requiring GOT fixups. >>> Rename memory allocation/free functions >>> Add minimum address parameter to efi_low_alloc() >>> rename __get_map() to efi_get_memory_map(), add parameter to >>> optionally return mmap key. The mmap key is required to exit >>> EFI boot services, and allows efi_get_memory_map() to be used >>> for getting final memory map. >>> Enforce minimum alignment of 1 page on allocations. The >>> efi_high_alloc() and efi_low_alloc() functions use the >>> EFI_ALLOCATE_ADDRESS option to the EFI function >>> allocate_pages(), which requires a minimum of page alignment, >>> and rejects all other requests. >>> Allow efi_free() to be called with size of 0, and do nothing in that >>> case. >>> Generalize handle_ramdisks() and rename to handle_cmdline_files(). >>> Renames in handle_cmdline_files() to complete generalization. >>> Move EFI_READ_CHUNK_SIZE define to shared location. >>> Add proper definitions for some EFI function pointers. >>>
Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Fri, Aug 16, 2013 at 5:16 PM, Roy Franz roy.fr...@linaro.org wrote: On Tue, Aug 13, 2013 at 10:58 AM, Roy Franz roy.fr...@linaro.org wrote: On Fri, Aug 9, 2013 at 4:26 PM, Roy Franz roy.fr...@linaro.org wrote: This patch series adds EFI stub support for the ARM architecture. Some code that was previously only used by x86/x86_64 is now shared and has been made more general. The stub for ARM is implemented in a similar manner to x86 in that it is a shim layer between EFI and the normal zImage/bzImage boot process, and that an image with the stub configured is bootable as both a zImage and EFI application. This patch now (new for v3) series depends on the arm: Add [U]EFI runtime services support patches by leif.lindh...@linaro.org. The Kconfig option now depends on the CONFIG_EFI option that his series adds, and this option will ensure a little endian configuration. Also, the EFI support is used to handle the EFI memory map the stub passes to the kernel. There are some minor changes to be coordinated with the EFI runtime services patch series, so I have put this back to RFC status. These changes should be minor and relate to final device tree bindings. Changes since v2: * EFI bugfix correct call to free_pages that patch series depends on now in mainline * remove -fno-stack-protector from decompressor Makefile. The current code doesn't trigger the stack protection, so the decompressor now compiles with it still on. Note that there has never been any stack protection in the decompressor since the stack usage doesn't trigger the heuristic in GCC, so right now the -fno-stack-protector is a noop. * Changed EFI command line handling to not have a fixed limit. * Change FDT memory allocation to retry with a larger allocation if first educated guess is inadequate. * Correctly set 'SizeOfCode' in PE/COFF header. * Reviewed .setup section that is in x86 PE/COFF header. This is used for x86 to account for code that is not in the .text section. We don't need this for ARM, as all of our code is in the .text section, or in the PE/COFF header itself. * Moved EFI_STUB_ERROR #define to header file to share between stub C and ASM. * Variety of cleanups and fixes in head.S. * Changed update_fdt_and_exit_boot() to just update the device tree, and renamed appropriately. Memory allocations moved out of this function as well, which enables the retries if the initial FDT size is too small. Note that in order to do the retried allocations, the original FDT and command line memory regions are left allocated. This is OK since the kernel has the memory map and will free these allocations along with the initrd and new fdt allocations. * Added prefix to all prints, reduced number of prints, and reviewed all messages. * Change mixed usage of dtb/fdt to all be fdt or device tree in efi-stub.c * remove unnecessary zimage_size variable from relocate_kernel() * correct return types on EFI functions - should be efi_status_t, not int. Changes since V1: * Updated head.S based on feedback from Dave Martin. ARM/THUMB switches now much cleaner. * Broke up changes to x86 and common code into more patches. 10 more patches in this series. Roy Franz (16): Move common EFI stub code from x86 arch code to common location Add system pointer argument to shared EFI stub related functions so they no longer use global system table pointer as they did when part of eboot.c. This code is now shared, so using a global variable as part of the interface is not that nice. Also, by avoiding any global variables in the ARM EFI stub, this allows the code to be position independent without requiring GOT fixups. Rename memory allocation/free functions Add minimum address parameter to efi_low_alloc() rename __get_map() to efi_get_memory_map(), add parameter to optionally return mmap key. The mmap key is required to exit EFI boot services, and allows efi_get_memory_map() to be used for getting final memory map. Enforce minimum alignment of 1 page on allocations. The efi_high_alloc() and efi_low_alloc() functions use the EFI_ALLOCATE_ADDRESS option to the EFI function allocate_pages(), which requires a minimum of page alignment, and rejects all other requests. Allow efi_free() to be called with size of 0, and do nothing in that case. Generalize handle_ramdisks() and rename to handle_cmdline_files(). Renames in handle_cmdline_files() to complete generalization. Move EFI_READ_CHUNK_SIZE define to shared location. Add proper definitions for some EFI function pointers. Fix types in EFI calls to match EFI function definitions. resolve warnings found on ARM compile Add strstr to compressed string.c for ARM. Add EFI stub for ARM Add config EFI_STUB for ARM to Kconfig arch/arm/Kconfig
Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Tue, Aug 13, 2013 at 10:58 AM, Roy Franz wrote: > On Fri, Aug 9, 2013 at 4:26 PM, Roy Franz wrote: >> >> This patch series adds EFI stub support for the ARM architecture. >> Some code that was previously only used by x86/x86_64 is now shared >> and has been made more general. The stub for ARM is implemented in >> a similar manner to x86 in that it is a shim layer between EFI and >> the normal zImage/bzImage boot process, and that an image with the >> stub configured is bootable as both a zImage and EFI application. >> >> This patch now (new for v3) series depends on the >> "arm: Add [U]EFI runtime services support" patches by >> leif.lindh...@linaro.org. >> The Kconfig option now depends on the "CONFIG_EFI" option that his series >> adds, and this option will ensure a little endian configuration. Also, the >> EFI support is used to handle the EFI memory map the stub passes to the >> kernel. >> There are some minor changes to be coordinated with the EFI runtime services >> patch series, so I have put this back to RFC status. These changes should be >> minor and relate to final device tree bindings. >> >> Changes since v2: >> * EFI bugfix "correct call to free_pages" that patch series >> depends on now in mainline >> * remove "-fno-stack-protector" from decompressor Makefile. The current >> code doesn't >> trigger the stack protection, so the decompressor now compiles with it >> still >> on. Note that there has never been any stack protection in the >> decompressor >> since the stack usage doesn't trigger the heuristic in GCC, so right now >> the "-fno-stack-protector" is a noop. >> * Changed EFI command line handling to not have a fixed limit. >> * Change FDT memory allocation to retry with a larger allocation if >> first educated guess is inadequate. >> * Correctly set 'SizeOfCode' in PE/COFF header. >> * Reviewed ".setup" section that is in x86 PE/COFF header. This is used for >> x86 >> to account for code that is not in the .text section. We don't need this >> for ARM, as all of our code is in the .text section, or in the PE/COFF >> header >> itself. >> * Moved EFI_STUB_ERROR #define to header file to share between stub C and >> ASM. >> * Variety of cleanups and fixes in head.S. >> * Changed update_fdt_and_exit_boot() to just update the device tree, and >> renamed appropriately. Memory allocations moved out of this function as >> well, which enables the retries if the initial FDT size is too small. >> Note that in order to do the retried allocations, the original FDT and >> command line memory regions are left allocated. This is OK since the >> kernel >> has the memory map and will free these allocations along with the initrd >> and new fdt allocations. >> * Added prefix to all prints, reduced number of prints, and reviewed all >> messages. >> * Change mixed usage of dtb/fdt to all be fdt or "device tree" in efi-stub.c >> * remove unnecessary zimage_size variable from relocate_kernel() >> * correct return types on EFI functions - should be efi_status_t, not int. >> >> >> >> Changes since V1: >> * Updated head.S based on feedback from Dave Martin. ARM/THUMB >> switches now much cleaner. >> * Broke up changes to x86 and common code into more patches. >> 10 more patches in this series. >> >> Roy Franz (16): >> Move common EFI stub code from x86 arch code to common location >> Add system pointer argument to shared EFI stub related functions >> so they no longer use global system table pointer as they did >> when part of eboot.c. This code is now shared, so using a >> global variable as part of the interface is not that nice. >> Also, by avoiding any global variables in the ARM EFI stub, >> this allows the code to be position independent without >> requiring GOT fixups. >> Rename memory allocation/free functions >> Add minimum address parameter to efi_low_alloc() >> rename __get_map() to efi_get_memory_map(), add parameter to >> optionally return mmap key. The mmap key is required to exit >> EFI boot services, and allows efi_get_memory_map() to be used >> for getting final memory map. >> Enforce minimum alignment of 1 page on allocations. The >> efi_high_alloc() and efi_low_alloc() functions use the >> EFI_ALLOCATE_ADDRESS option to the EFI function >> allocate_pages(), which requires a minimum of page alignment, >> and rejects all other requests. >> Allow efi_free() to be called with size of 0, and do nothing in that >> case. >> Generalize handle_ramdisks() and rename to handle_cmdline_files(). >> Renames in handle_cmdline_files() to complete generalization. >> Move EFI_READ_CHUNK_SIZE define to shared location. >> Add proper definitions for some EFI function pointers. >> Fix types in EFI calls to match EFI function definitions. >> resolve warnings found on ARM compile >> Add strstr to compressed string.c for ARM. >>
Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Tue, Aug 13, 2013 at 10:58 AM, Roy Franz roy.fr...@linaro.org wrote: On Fri, Aug 9, 2013 at 4:26 PM, Roy Franz roy.fr...@linaro.org wrote: This patch series adds EFI stub support for the ARM architecture. Some code that was previously only used by x86/x86_64 is now shared and has been made more general. The stub for ARM is implemented in a similar manner to x86 in that it is a shim layer between EFI and the normal zImage/bzImage boot process, and that an image with the stub configured is bootable as both a zImage and EFI application. This patch now (new for v3) series depends on the arm: Add [U]EFI runtime services support patches by leif.lindh...@linaro.org. The Kconfig option now depends on the CONFIG_EFI option that his series adds, and this option will ensure a little endian configuration. Also, the EFI support is used to handle the EFI memory map the stub passes to the kernel. There are some minor changes to be coordinated with the EFI runtime services patch series, so I have put this back to RFC status. These changes should be minor and relate to final device tree bindings. Changes since v2: * EFI bugfix correct call to free_pages that patch series depends on now in mainline * remove -fno-stack-protector from decompressor Makefile. The current code doesn't trigger the stack protection, so the decompressor now compiles with it still on. Note that there has never been any stack protection in the decompressor since the stack usage doesn't trigger the heuristic in GCC, so right now the -fno-stack-protector is a noop. * Changed EFI command line handling to not have a fixed limit. * Change FDT memory allocation to retry with a larger allocation if first educated guess is inadequate. * Correctly set 'SizeOfCode' in PE/COFF header. * Reviewed .setup section that is in x86 PE/COFF header. This is used for x86 to account for code that is not in the .text section. We don't need this for ARM, as all of our code is in the .text section, or in the PE/COFF header itself. * Moved EFI_STUB_ERROR #define to header file to share between stub C and ASM. * Variety of cleanups and fixes in head.S. * Changed update_fdt_and_exit_boot() to just update the device tree, and renamed appropriately. Memory allocations moved out of this function as well, which enables the retries if the initial FDT size is too small. Note that in order to do the retried allocations, the original FDT and command line memory regions are left allocated. This is OK since the kernel has the memory map and will free these allocations along with the initrd and new fdt allocations. * Added prefix to all prints, reduced number of prints, and reviewed all messages. * Change mixed usage of dtb/fdt to all be fdt or device tree in efi-stub.c * remove unnecessary zimage_size variable from relocate_kernel() * correct return types on EFI functions - should be efi_status_t, not int. Changes since V1: * Updated head.S based on feedback from Dave Martin. ARM/THUMB switches now much cleaner. * Broke up changes to x86 and common code into more patches. 10 more patches in this series. Roy Franz (16): Move common EFI stub code from x86 arch code to common location Add system pointer argument to shared EFI stub related functions so they no longer use global system table pointer as they did when part of eboot.c. This code is now shared, so using a global variable as part of the interface is not that nice. Also, by avoiding any global variables in the ARM EFI stub, this allows the code to be position independent without requiring GOT fixups. Rename memory allocation/free functions Add minimum address parameter to efi_low_alloc() rename __get_map() to efi_get_memory_map(), add parameter to optionally return mmap key. The mmap key is required to exit EFI boot services, and allows efi_get_memory_map() to be used for getting final memory map. Enforce minimum alignment of 1 page on allocations. The efi_high_alloc() and efi_low_alloc() functions use the EFI_ALLOCATE_ADDRESS option to the EFI function allocate_pages(), which requires a minimum of page alignment, and rejects all other requests. Allow efi_free() to be called with size of 0, and do nothing in that case. Generalize handle_ramdisks() and rename to handle_cmdline_files(). Renames in handle_cmdline_files() to complete generalization. Move EFI_READ_CHUNK_SIZE define to shared location. Add proper definitions for some EFI function pointers. Fix types in EFI calls to match EFI function definitions. resolve warnings found on ARM compile Add strstr to compressed string.c for ARM. Add EFI stub for ARM Add config EFI_STUB for ARM to Kconfig arch/arm/Kconfig | 11 + arch/arm/boot/compressed/Makefile | 15 +-
Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Fri, Aug 9, 2013 at 4:26 PM, Roy Franz wrote: > > This patch series adds EFI stub support for the ARM architecture. > Some code that was previously only used by x86/x86_64 is now shared > and has been made more general. The stub for ARM is implemented in > a similar manner to x86 in that it is a shim layer between EFI and > the normal zImage/bzImage boot process, and that an image with the > stub configured is bootable as both a zImage and EFI application. > > This patch now (new for v3) series depends on the > "arm: Add [U]EFI runtime services support" patches by > leif.lindh...@linaro.org. > The Kconfig option now depends on the "CONFIG_EFI" option that his series > adds, and this option will ensure a little endian configuration. Also, the > EFI support is used to handle the EFI memory map the stub passes to the > kernel. > There are some minor changes to be coordinated with the EFI runtime services > patch series, so I have put this back to RFC status. These changes should be > minor and relate to final device tree bindings. > > Changes since v2: > * EFI bugfix "correct call to free_pages" that patch series > depends on now in mainline > * remove "-fno-stack-protector" from decompressor Makefile. The current code > doesn't > trigger the stack protection, so the decompressor now compiles with it still > on. Note that there has never been any stack protection in the decompressor > since the stack usage doesn't trigger the heuristic in GCC, so right now > the "-fno-stack-protector" is a noop. > * Changed EFI command line handling to not have a fixed limit. > * Change FDT memory allocation to retry with a larger allocation if > first educated guess is inadequate. > * Correctly set 'SizeOfCode' in PE/COFF header. > * Reviewed ".setup" section that is in x86 PE/COFF header. This is used for > x86 > to account for code that is not in the .text section. We don't need this > for ARM, as all of our code is in the .text section, or in the PE/COFF > header > itself. > * Moved EFI_STUB_ERROR #define to header file to share between stub C and ASM. > * Variety of cleanups and fixes in head.S. > * Changed update_fdt_and_exit_boot() to just update the device tree, and > renamed appropriately. Memory allocations moved out of this function as > well, which enables the retries if the initial FDT size is too small. > Note that in order to do the retried allocations, the original FDT and > command line memory regions are left allocated. This is OK since the kernel > has the memory map and will free these allocations along with the initrd > and new fdt allocations. > * Added prefix to all prints, reduced number of prints, and reviewed all > messages. > * Change mixed usage of dtb/fdt to all be fdt or "device tree" in efi-stub.c > * remove unnecessary zimage_size variable from relocate_kernel() > * correct return types on EFI functions - should be efi_status_t, not int. > > > > Changes since V1: > * Updated head.S based on feedback from Dave Martin. ARM/THUMB > switches now much cleaner. > * Broke up changes to x86 and common code into more patches. > 10 more patches in this series. > > Roy Franz (16): > Move common EFI stub code from x86 arch code to common location > Add system pointer argument to shared EFI stub related functions > so they no longer use global system table pointer as they did > when part of eboot.c. This code is now shared, so using a > global variable as part of the interface is not that nice. > Also, by avoiding any global variables in the ARM EFI stub, > this allows the code to be position independent without > requiring GOT fixups. > Rename memory allocation/free functions > Add minimum address parameter to efi_low_alloc() > rename __get_map() to efi_get_memory_map(), add parameter to > optionally return mmap key. The mmap key is required to exit > EFI boot services, and allows efi_get_memory_map() to be used > for getting final memory map. > Enforce minimum alignment of 1 page on allocations. The > efi_high_alloc() and efi_low_alloc() functions use the > EFI_ALLOCATE_ADDRESS option to the EFI function > allocate_pages(), which requires a minimum of page alignment, > and rejects all other requests. > Allow efi_free() to be called with size of 0, and do nothing in that > case. > Generalize handle_ramdisks() and rename to handle_cmdline_files(). > Renames in handle_cmdline_files() to complete generalization. > Move EFI_READ_CHUNK_SIZE define to shared location. > Add proper definitions for some EFI function pointers. > Fix types in EFI calls to match EFI function definitions. > resolve warnings found on ARM compile > Add strstr to compressed string.c for ARM. > Add EFI stub for ARM > Add config EFI_STUB for ARM to Kconfig > > arch/arm/Kconfig | 11 + > arch/arm/boot/compressed/Makefile |
Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Mon, 2013-08-12 at 18:13 -0700, Roy Franz wrote:
> On Mon, Aug 12, 2013 at 7:02 AM, Mark Salter wrote:
> > On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote:
> >> * Change FDT memory allocation to retry with a larger allocation if
> >> first educated guess is inadequate.
> >
> > With this change, it looks like you no longer free the original cmdline
> > and fdt memory. The current flow looks like:
> >
> > retry:
> > allocate_memory_for_expanded_fdt
> > get_memory_map
> > if (update_fdt() fails) {
> > free new_fdt and memory_map
> > goto retry
> > }
> >
> > So, this keeps the original fdt around and uses it as a starting point
> > for newly allocated expanded fdt. You don't know if the new fdt is big
> > enough until update_fdt() succeeds. But at that point, you already wrote
> > the efi-runtime-mmap property with the memory_map still having the
> > original cmdline and fdt in it.
> >
> > I think you should be able to have an expand_fdt() function which bumps
> > the fdt size and uses the current fdt as the starting point instead of
> > the original fdt. That way you can free the original fdt on the first
> > iteration and free the original cmdline as soon as it is successfully
> > written. Then the last thing you do if get the memory_map and write it.
> >
> > --Mark
>
> Hi Mark,
>
> I think this will work with the current FDT fields that are being set
> by the stub. In earlier
> versions, I was also updating the reserved memory map using
> fdt_add_mem_rsv(), so
> iteratively updating the device tree wouldn't work. The reserved
> regions would change,
> and so the repeated updates would cause there to be repeated and
> incorrect reserved regions.
> I'm inclined to leave it as is, which should correctly update the
> device tree even if methods like
> fdt_add_mem_rsv() are used, with the tradeoff being there will be a
> few more memory regions
> for the kernel to free when it processes the EFI memory map. The
> kernel already needs to process
> the EFI memory map to free the buffers use to load the kernel and
> initrd, so these buffers will get freed, just not
> by the stub.
>
Got it. Thanks for the explanation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Mon, 2013-08-12 at 18:13 -0700, Roy Franz wrote:
On Mon, Aug 12, 2013 at 7:02 AM, Mark Salter msal...@redhat.com wrote:
On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote:
* Change FDT memory allocation to retry with a larger allocation if
first educated guess is inadequate.
With this change, it looks like you no longer free the original cmdline
and fdt memory. The current flow looks like:
retry:
allocate_memory_for_expanded_fdt
get_memory_map
if (update_fdt() fails) {
free new_fdt and memory_map
goto retry
}
So, this keeps the original fdt around and uses it as a starting point
for newly allocated expanded fdt. You don't know if the new fdt is big
enough until update_fdt() succeeds. But at that point, you already wrote
the efi-runtime-mmap property with the memory_map still having the
original cmdline and fdt in it.
I think you should be able to have an expand_fdt() function which bumps
the fdt size and uses the current fdt as the starting point instead of
the original fdt. That way you can free the original fdt on the first
iteration and free the original cmdline as soon as it is successfully
written. Then the last thing you do if get the memory_map and write it.
--Mark
Hi Mark,
I think this will work with the current FDT fields that are being set
by the stub. In earlier
versions, I was also updating the reserved memory map using
fdt_add_mem_rsv(), so
iteratively updating the device tree wouldn't work. The reserved
regions would change,
and so the repeated updates would cause there to be repeated and
incorrect reserved regions.
I'm inclined to leave it as is, which should correctly update the
device tree even if methods like
fdt_add_mem_rsv() are used, with the tradeoff being there will be a
few more memory regions
for the kernel to free when it processes the EFI memory map. The
kernel already needs to process
the EFI memory map to free the buffers use to load the kernel and
initrd, so these buffers will get freed, just not
by the stub.
Got it. Thanks for the explanation.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Fri, Aug 9, 2013 at 4:26 PM, Roy Franz roy.fr...@linaro.org wrote: This patch series adds EFI stub support for the ARM architecture. Some code that was previously only used by x86/x86_64 is now shared and has been made more general. The stub for ARM is implemented in a similar manner to x86 in that it is a shim layer between EFI and the normal zImage/bzImage boot process, and that an image with the stub configured is bootable as both a zImage and EFI application. This patch now (new for v3) series depends on the arm: Add [U]EFI runtime services support patches by leif.lindh...@linaro.org. The Kconfig option now depends on the CONFIG_EFI option that his series adds, and this option will ensure a little endian configuration. Also, the EFI support is used to handle the EFI memory map the stub passes to the kernel. There are some minor changes to be coordinated with the EFI runtime services patch series, so I have put this back to RFC status. These changes should be minor and relate to final device tree bindings. Changes since v2: * EFI bugfix correct call to free_pages that patch series depends on now in mainline * remove -fno-stack-protector from decompressor Makefile. The current code doesn't trigger the stack protection, so the decompressor now compiles with it still on. Note that there has never been any stack protection in the decompressor since the stack usage doesn't trigger the heuristic in GCC, so right now the -fno-stack-protector is a noop. * Changed EFI command line handling to not have a fixed limit. * Change FDT memory allocation to retry with a larger allocation if first educated guess is inadequate. * Correctly set 'SizeOfCode' in PE/COFF header. * Reviewed .setup section that is in x86 PE/COFF header. This is used for x86 to account for code that is not in the .text section. We don't need this for ARM, as all of our code is in the .text section, or in the PE/COFF header itself. * Moved EFI_STUB_ERROR #define to header file to share between stub C and ASM. * Variety of cleanups and fixes in head.S. * Changed update_fdt_and_exit_boot() to just update the device tree, and renamed appropriately. Memory allocations moved out of this function as well, which enables the retries if the initial FDT size is too small. Note that in order to do the retried allocations, the original FDT and command line memory regions are left allocated. This is OK since the kernel has the memory map and will free these allocations along with the initrd and new fdt allocations. * Added prefix to all prints, reduced number of prints, and reviewed all messages. * Change mixed usage of dtb/fdt to all be fdt or device tree in efi-stub.c * remove unnecessary zimage_size variable from relocate_kernel() * correct return types on EFI functions - should be efi_status_t, not int. Changes since V1: * Updated head.S based on feedback from Dave Martin. ARM/THUMB switches now much cleaner. * Broke up changes to x86 and common code into more patches. 10 more patches in this series. Roy Franz (16): Move common EFI stub code from x86 arch code to common location Add system pointer argument to shared EFI stub related functions so they no longer use global system table pointer as they did when part of eboot.c. This code is now shared, so using a global variable as part of the interface is not that nice. Also, by avoiding any global variables in the ARM EFI stub, this allows the code to be position independent without requiring GOT fixups. Rename memory allocation/free functions Add minimum address parameter to efi_low_alloc() rename __get_map() to efi_get_memory_map(), add parameter to optionally return mmap key. The mmap key is required to exit EFI boot services, and allows efi_get_memory_map() to be used for getting final memory map. Enforce minimum alignment of 1 page on allocations. The efi_high_alloc() and efi_low_alloc() functions use the EFI_ALLOCATE_ADDRESS option to the EFI function allocate_pages(), which requires a minimum of page alignment, and rejects all other requests. Allow efi_free() to be called with size of 0, and do nothing in that case. Generalize handle_ramdisks() and rename to handle_cmdline_files(). Renames in handle_cmdline_files() to complete generalization. Move EFI_READ_CHUNK_SIZE define to shared location. Add proper definitions for some EFI function pointers. Fix types in EFI calls to match EFI function definitions. resolve warnings found on ARM compile Add strstr to compressed string.c for ARM. Add EFI stub for ARM Add config EFI_STUB for ARM to Kconfig arch/arm/Kconfig | 11 + arch/arm/boot/compressed/Makefile | 15 +- arch/arm/boot/compressed/efi-header.S | 111 +++
Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Mon, Aug 12, 2013 at 7:02 AM, Mark Salter wrote:
> On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote:
>> * Change FDT memory allocation to retry with a larger allocation if
>> first educated guess is inadequate.
>
> With this change, it looks like you no longer free the original cmdline
> and fdt memory. The current flow looks like:
>
> retry:
> allocate_memory_for_expanded_fdt
> get_memory_map
> if (update_fdt() fails) {
> free new_fdt and memory_map
> goto retry
> }
>
> So, this keeps the original fdt around and uses it as a starting point
> for newly allocated expanded fdt. You don't know if the new fdt is big
> enough until update_fdt() succeeds. But at that point, you already wrote
> the efi-runtime-mmap property with the memory_map still having the
> original cmdline and fdt in it.
>
> I think you should be able to have an expand_fdt() function which bumps
> the fdt size and uses the current fdt as the starting point instead of
> the original fdt. That way you can free the original fdt on the first
> iteration and free the original cmdline as soon as it is successfully
> written. Then the last thing you do if get the memory_map and write it.
>
> --Mark
Hi Mark,
I think this will work with the current FDT fields that are being set
by the stub. In earlier
versions, I was also updating the reserved memory map using
fdt_add_mem_rsv(), so
iteratively updating the device tree wouldn't work. The reserved
regions would change,
and so the repeated updates would cause there to be repeated and
incorrect reserved regions.
I'm inclined to leave it as is, which should correctly update the
device tree even if methods like
fdt_add_mem_rsv() are used, with the tradeoff being there will be a
few more memory regions
for the kernel to free when it processes the EFI memory map. The
kernel already needs to process
the EFI memory map to free the buffers use to load the kernel and
initrd, so these buffers will get freed, just not
by the stub.
Roy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote:
> * Change FDT memory allocation to retry with a larger allocation if
> first educated guess is inadequate.
With this change, it looks like you no longer free the original cmdline
and fdt memory. The current flow looks like:
retry:
allocate_memory_for_expanded_fdt
get_memory_map
if (update_fdt() fails) {
free new_fdt and memory_map
goto retry
}
So, this keeps the original fdt around and uses it as a starting point
for newly allocated expanded fdt. You don't know if the new fdt is big
enough until update_fdt() succeeds. But at that point, you already wrote
the efi-runtime-mmap property with the memory_map still having the
original cmdline and fdt in it.
I think you should be able to have an expand_fdt() function which bumps
the fdt size and uses the current fdt as the starting point instead of
the original fdt. That way you can free the original fdt on the first
iteration and free the original cmdline as soon as it is successfully
written. Then the last thing you do if get the memory_map and write it.
--Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote:
* Change FDT memory allocation to retry with a larger allocation if
first educated guess is inadequate.
With this change, it looks like you no longer free the original cmdline
and fdt memory. The current flow looks like:
retry:
allocate_memory_for_expanded_fdt
get_memory_map
if (update_fdt() fails) {
free new_fdt and memory_map
goto retry
}
So, this keeps the original fdt around and uses it as a starting point
for newly allocated expanded fdt. You don't know if the new fdt is big
enough until update_fdt() succeeds. But at that point, you already wrote
the efi-runtime-mmap property with the memory_map still having the
original cmdline and fdt in it.
I think you should be able to have an expand_fdt() function which bumps
the fdt size and uses the current fdt as the starting point instead of
the original fdt. That way you can free the original fdt on the first
iteration and free the original cmdline as soon as it is successfully
written. Then the last thing you do if get the memory_map and write it.
--Mark
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Mon, Aug 12, 2013 at 7:02 AM, Mark Salter msal...@redhat.com wrote:
On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote:
* Change FDT memory allocation to retry with a larger allocation if
first educated guess is inadequate.
With this change, it looks like you no longer free the original cmdline
and fdt memory. The current flow looks like:
retry:
allocate_memory_for_expanded_fdt
get_memory_map
if (update_fdt() fails) {
free new_fdt and memory_map
goto retry
}
So, this keeps the original fdt around and uses it as a starting point
for newly allocated expanded fdt. You don't know if the new fdt is big
enough until update_fdt() succeeds. But at that point, you already wrote
the efi-runtime-mmap property with the memory_map still having the
original cmdline and fdt in it.
I think you should be able to have an expand_fdt() function which bumps
the fdt size and uses the current fdt as the starting point instead of
the original fdt. That way you can free the original fdt on the first
iteration and free the original cmdline as soon as it is successfully
written. Then the last thing you do if get the memory_map and write it.
--Mark
Hi Mark,
I think this will work with the current FDT fields that are being set
by the stub. In earlier
versions, I was also updating the reserved memory map using
fdt_add_mem_rsv(), so
iteratively updating the device tree wouldn't work. The reserved
regions would change,
and so the repeated updates would cause there to be repeated and
incorrect reserved regions.
I'm inclined to leave it as is, which should correctly update the
device tree even if methods like
fdt_add_mem_rsv() are used, with the tradeoff being there will be a
few more memory regions
for the kernel to free when it processes the EFI memory map. The
kernel already needs to process
the EFI memory map to free the buffers use to load the kernel and
initrd, so these buffers will get freed, just not
by the stub.
Roy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 RFC 00/16] EFI stub for ARM
This patch series adds EFI stub support for the ARM architecture. Some code that was previously only used by x86/x86_64 is now shared and has been made more general. The stub for ARM is implemented in a similar manner to x86 in that it is a shim layer between EFI and the normal zImage/bzImage boot process, and that an image with the stub configured is bootable as both a zImage and EFI application. This patch now (new for v3) series depends on the "arm: Add [U]EFI runtime services support" patches by leif.lindh...@linaro.org. The Kconfig option now depends on the "CONFIG_EFI" option that his series adds, and this option will ensure a little endian configuration. Also, the EFI support is used to handle the EFI memory map the stub passes to the kernel. There are some minor changes to be coordinated with the EFI runtime services patch series, so I have put this back to RFC status. These changes should be minor and relate to final device tree bindings. Changes since v2: * EFI bugfix "correct call to free_pages" that patch series depends on now in mainline * remove "-fno-stack-protector" from decompressor Makefile. The current code doesn't trigger the stack protection, so the decompressor now compiles with it still on. Note that there has never been any stack protection in the decompressor since the stack usage doesn't trigger the heuristic in GCC, so right now the "-fno-stack-protector" is a noop. * Changed EFI command line handling to not have a fixed limit. * Change FDT memory allocation to retry with a larger allocation if first educated guess is inadequate. * Correctly set 'SizeOfCode' in PE/COFF header. * Reviewed ".setup" section that is in x86 PE/COFF header. This is used for x86 to account for code that is not in the .text section. We don't need this for ARM, as all of our code is in the .text section, or in the PE/COFF header itself. * Moved EFI_STUB_ERROR #define to header file to share between stub C and ASM. * Variety of cleanups and fixes in head.S. * Changed update_fdt_and_exit_boot() to just update the device tree, and renamed appropriately. Memory allocations moved out of this function as well, which enables the retries if the initial FDT size is too small. Note that in order to do the retried allocations, the original FDT and command line memory regions are left allocated. This is OK since the kernel has the memory map and will free these allocations along with the initrd and new fdt allocations. * Added prefix to all prints, reduced number of prints, and reviewed all messages. * Change mixed usage of dtb/fdt to all be fdt or "device tree" in efi-stub.c * remove unnecessary zimage_size variable from relocate_kernel() * correct return types on EFI functions - should be efi_status_t, not int. Changes since V1: * Updated head.S based on feedback from Dave Martin. ARM/THUMB switches now much cleaner. * Broke up changes to x86 and common code into more patches. 10 more patches in this series. Roy Franz (16): Move common EFI stub code from x86 arch code to common location Add system pointer argument to shared EFI stub related functions so they no longer use global system table pointer as they did when part of eboot.c. This code is now shared, so using a global variable as part of the interface is not that nice. Also, by avoiding any global variables in the ARM EFI stub, this allows the code to be position independent without requiring GOT fixups. Rename memory allocation/free functions Add minimum address parameter to efi_low_alloc() rename __get_map() to efi_get_memory_map(), add parameter to optionally return mmap key. The mmap key is required to exit EFI boot services, and allows efi_get_memory_map() to be used for getting final memory map. Enforce minimum alignment of 1 page on allocations. The efi_high_alloc() and efi_low_alloc() functions use the EFI_ALLOCATE_ADDRESS option to the EFI function allocate_pages(), which requires a minimum of page alignment, and rejects all other requests. Allow efi_free() to be called with size of 0, and do nothing in that case. Generalize handle_ramdisks() and rename to handle_cmdline_files(). Renames in handle_cmdline_files() to complete generalization. Move EFI_READ_CHUNK_SIZE define to shared location. Add proper definitions for some EFI function pointers. Fix types in EFI calls to match EFI function definitions. resolve warnings found on ARM compile Add strstr to compressed string.c for ARM. Add EFI stub for ARM Add config EFI_STUB for ARM to Kconfig arch/arm/Kconfig | 11 + arch/arm/boot/compressed/Makefile | 15 +- arch/arm/boot/compressed/efi-header.S | 111 +++ arch/arm/boot/compressed/efi-stub.c| 448 arch/arm/boot/compressed/efi-stub.h|5 + arch/arm/boot/compressed/head.S
[PATCH V3 RFC 00/16] EFI stub for ARM
This patch series adds EFI stub support for the ARM architecture. Some code that was previously only used by x86/x86_64 is now shared and has been made more general. The stub for ARM is implemented in a similar manner to x86 in that it is a shim layer between EFI and the normal zImage/bzImage boot process, and that an image with the stub configured is bootable as both a zImage and EFI application. This patch now (new for v3) series depends on the arm: Add [U]EFI runtime services support patches by leif.lindh...@linaro.org. The Kconfig option now depends on the CONFIG_EFI option that his series adds, and this option will ensure a little endian configuration. Also, the EFI support is used to handle the EFI memory map the stub passes to the kernel. There are some minor changes to be coordinated with the EFI runtime services patch series, so I have put this back to RFC status. These changes should be minor and relate to final device tree bindings. Changes since v2: * EFI bugfix correct call to free_pages that patch series depends on now in mainline * remove -fno-stack-protector from decompressor Makefile. The current code doesn't trigger the stack protection, so the decompressor now compiles with it still on. Note that there has never been any stack protection in the decompressor since the stack usage doesn't trigger the heuristic in GCC, so right now the -fno-stack-protector is a noop. * Changed EFI command line handling to not have a fixed limit. * Change FDT memory allocation to retry with a larger allocation if first educated guess is inadequate. * Correctly set 'SizeOfCode' in PE/COFF header. * Reviewed .setup section that is in x86 PE/COFF header. This is used for x86 to account for code that is not in the .text section. We don't need this for ARM, as all of our code is in the .text section, or in the PE/COFF header itself. * Moved EFI_STUB_ERROR #define to header file to share between stub C and ASM. * Variety of cleanups and fixes in head.S. * Changed update_fdt_and_exit_boot() to just update the device tree, and renamed appropriately. Memory allocations moved out of this function as well, which enables the retries if the initial FDT size is too small. Note that in order to do the retried allocations, the original FDT and command line memory regions are left allocated. This is OK since the kernel has the memory map and will free these allocations along with the initrd and new fdt allocations. * Added prefix to all prints, reduced number of prints, and reviewed all messages. * Change mixed usage of dtb/fdt to all be fdt or device tree in efi-stub.c * remove unnecessary zimage_size variable from relocate_kernel() * correct return types on EFI functions - should be efi_status_t, not int. Changes since V1: * Updated head.S based on feedback from Dave Martin. ARM/THUMB switches now much cleaner. * Broke up changes to x86 and common code into more patches. 10 more patches in this series. Roy Franz (16): Move common EFI stub code from x86 arch code to common location Add system pointer argument to shared EFI stub related functions so they no longer use global system table pointer as they did when part of eboot.c. This code is now shared, so using a global variable as part of the interface is not that nice. Also, by avoiding any global variables in the ARM EFI stub, this allows the code to be position independent without requiring GOT fixups. Rename memory allocation/free functions Add minimum address parameter to efi_low_alloc() rename __get_map() to efi_get_memory_map(), add parameter to optionally return mmap key. The mmap key is required to exit EFI boot services, and allows efi_get_memory_map() to be used for getting final memory map. Enforce minimum alignment of 1 page on allocations. The efi_high_alloc() and efi_low_alloc() functions use the EFI_ALLOCATE_ADDRESS option to the EFI function allocate_pages(), which requires a minimum of page alignment, and rejects all other requests. Allow efi_free() to be called with size of 0, and do nothing in that case. Generalize handle_ramdisks() and rename to handle_cmdline_files(). Renames in handle_cmdline_files() to complete generalization. Move EFI_READ_CHUNK_SIZE define to shared location. Add proper definitions for some EFI function pointers. Fix types in EFI calls to match EFI function definitions. resolve warnings found on ARM compile Add strstr to compressed string.c for ARM. Add EFI stub for ARM Add config EFI_STUB for ARM to Kconfig arch/arm/Kconfig | 11 + arch/arm/boot/compressed/Makefile | 15 +- arch/arm/boot/compressed/efi-header.S | 111 +++ arch/arm/boot/compressed/efi-stub.c| 448 arch/arm/boot/compressed/efi-stub.h|5 + arch/arm/boot/compressed/head.S| 90
