[PATCH RESEND] efi_stub: update documentation on dtb= parameter

documentation to reflect the current usage. Signed-off-by: Grant Likely Reviewed-by: Alexander Graf Acked-by: Leif Lindholm Acked-by: Olof Johansson Cc: Ard Biesheuvel Cc: Jonathan Corbet --- Resending because original post included Arm corporate disclaimer. Documentation/efi-stub.txt | 17

Re: [PATCH] efi_stub: update documentation on dtb= parameter

> On 6 Sep 2018, at 16:51, Jonathan Corbet wrote: > > On Wed, 5 Sep 2018 20:07:50 +0100 > Grant Likely wrote: > >> The dtb= parameter is no longer the primary mechanism for providing a >> devicetree to the kernel. Now either firmware or the boot selector (

[PATCH] efi_stub: update documentation on dtb= parameter

documentation to reflect the current usage. Signed-off-by: Grant Likely Cc: Ard Biesheuvel Cc: Jonathan Corbet --- Documentation/efi-stub.txt | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt index 41df801f9a50

Re: [PATCH 2/2] drivers: firmware: efi: install new fdt in configuration table

On 25/04/2018 15:48, Udit Kumar wrote: -Original Message- From: Leif Lindholm [mailto:leif.lindh...@linaro.org] Sent: Wednesday, April 25, 2018 4:20 PM To: Grant Likely <grant.lik...@arm.com> Cc: Udit Kumar <udit.ku...@nxp.com>; Ard Biesheuvel <ard.biesheu...@lina

Re: [PATCH 2/2] drivers: firmware: efi: install new fdt in configuration table

On 25/04/2018 07:49, Udit Kumar wrote: 2) Kernel provides/overrides DTB The kernel always has the option of loading it's own DTB, either because firmware doesn't provide one, or it needs a newer DTB. This is similar to CONFIG_ACPI_CUSTOM_DSDT in ACPI land. However, if the kernel is overriding

Re: [PATCH 2/2] drivers: firmware: efi: install new fdt in configuration table

ser intervention DTB override is needed However, if the DTB update mechanism is standard, and if we have a common database of DTBs, it would be possible for the distribution to automatically manage DTB updates. More inline please Regards Udit -Original Message- From: Grant Lik

Re: [PATCH 2/2] drivers: firmware: efi: install new fdt in configuration table

On 18/04/2018 09:44, Udit Kumar wrote: -Original Message- From: Grant Likely [mailto:grant.lik...@arm.com] Sent: Monday, March 26, 2018 4:10 PM To: Ard Biesheuvel <ard.biesheu...@linaro.org>; Pankaj Bansal <pankaj.ban...@nxp.com>; mark.rutl...@arm.com; leif.lindh...@l

Re: [PATCH 2/2] drivers: firmware: efi: install new fdt in configuration table

On 25/03/2018 16:29, Ard Biesheuvel wrote: On 25 Mar 2018, at 14:56, Pankaj Bansal wrote: Bootloader may need to fixup the device tree before OS can use it. e.g. a UEFI/DXE driver that has initialized a controller can add controller's clock frequency in controller

Re: [PATCH 4/6] arm64/efi: move SetVirtualAddressMap() to UEFI stub

On Fri, Oct 24, 2014 at 1:39 PM, Ard Biesheuvel ard.biesheu...@linaro.org wrote: In order to support kexec, the kernel needs to be able to deal with the state of the UEFI firmware after SetVirtualAddressMap() has been called. To avoid having separate code paths for non-kexec and kexec, let's

Re: [PATCH 6/6] arm64/efi: remove idmap manipulations from UEFI code

On Fri, Oct 24, 2014 at 1:39 PM, Ard Biesheuvel ard.biesheu...@linaro.org wrote: Now that we have moved the call to SetVirtualAddressMap() to the stub, UEFI has no use for the ID map, so we can drop the code that installs ID mappings for UEFI memory regions. Signed-off-by: Ard Biesheuvel

Re: [PATCH v3 1/3] Documentation: arm: add UEFI support documentation

On Fri, 6 Dec 2013 11:20:45 -0600, Matt Sealey n...@bakuhatsu.net wrote: On Wed, Dec 4, 2013 at 4:44 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Wed, Dec 04, 2013 at 03:06:47PM -0600, Matt Sealey wrote: Grant suggested I should propose some patches; sure, if I'm not otherwise busy.

Re: [PATCH v3 1/3] Documentation: arm: add UEFI support documentation

On Tue, 10 Dec 2013 10:29:34 -0800, Roy Franz roy.fr...@linaro.org wrote: On Tue, Dec 10, 2013 at 4:30 AM, Grant Likely grant.lik...@linaro.org wrote: On Fri, 6 Dec 2013 11:20:45 -0600, Matt Sealey n...@bakuhatsu.net wrote: On Wed, Dec 4, 2013 at 4:44 PM, Matthew Garrett mj...@srcf.ucam.org

Re: [PATCH 1/3] arm64: add EFI stub

limitations, only little endian kernels with 4K page sizes are supported at this time. Support in the COFF header for signed images was provided by Ard Biesheuvel. Signed-off-by: Mark Salter msal...@redhat.com Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org Reviewed-by: Grant Likely grant.lik

Re: [PATCH 1/3] arm64: add EFI stub

On Thu, 5 Dec 2013 15:28:06 +, Catalin Marinas catalin.mari...@arm.com wrote: On Thu, Dec 05, 2013 at 02:43:23PM +, Mark Salter wrote: On Thu, 2013-12-05 at 14:18 +, Catalin Marinas wrote: On Fri, Nov 29, 2013 at 10:05:10PM +, Mark Salter wrote: This patch adds PE/COFF

Re: [PATCH v3 1/3] Documentation: arm: add UEFI support documentation

On Mon, 2 Dec 2013 13:51:22 -0600, Matt Sealey n...@bakuhatsu.net wrote: +UEFI kernel support on ARM +== +UEFI kernel support on the ARM architectures (arm and arm64) is only available +when boot is performed through the stub. + +The stub populates the FDT

Re: [PATCH v3 1/3] Documentation: arm: add UEFI support documentation

On Wed, 4 Dec 2013 15:06:47 -0600, Matt Sealey n...@bakuhatsu.net wrote: If your platform has UEFI, then your platform has UEFI - if you built a multiplatform kernel that needs to boot on U-Boot, then you glued an EFI stub to it to make it boot. At some point between the stub and the runtime

Re: [PATCH v3 1/3] Documentation: arm: add UEFI support documentation

...@landley.net Cc: linux-...@vger.kernel.org Signed-off-by: Leif Lindholm leif.lindh...@linaro.org Acked-by: Grant Likely grant.lik...@linaro.org With a few minor comments below. g. --- Documentation/arm/00-INDEX |3 +++ Documentation/arm/uefi.txt | 61

Re: [PATCH v3 2/3] arm: Add [U]EFI runtime services support

, I've made a bunch of comments below. I've got concerns about the amount of casting going on in this code, but the rest are pretty minor Reviewed-by: Grant Likely grant.lik...@linaro.org --- arch/arm/Kconfig| 15 ++ arch/arm/include/asm/uefi.h | 22 ++ arch/arm/kernel/Makefile

Re: [PATCH v3 3/3] init: efi: arm: enable (U)EFI runtime services on arm

(); + + if (IS_ENABLED(CONFIG_ARM) efi_enabled(EFI_BOOT)) + efi_enter_virtual_mode(); + Personally, I would put the IS_ENABLED() and efi_enabled() tests into efi_enter_virtual_mode() itself (or an empty stub for the !IS_ENABLED() case), but that is mostly a nit. Acked-by: Grant

Re: [PATCH v3 0/3] (U)EFI runtime services for arm

On Fri, 29 Nov 2013 18:58:51 +0100, Leif Lindholm leif.lindh...@linaro.org wrote: On Fri, Nov 29, 2013 at 11:53:19AM +, Matt Fleming wrote: On Thu, 28 Nov, at 04:41:20PM, Leif Lindholm wrote: In systems based on [U]EFI-conformant firmware, runtime services provide a standardised way

Re: [PATCH V5 1/6] efi-stub.txt updates for ARM

On Wed, 27 Nov 2013 15:31:50 -0800, Roy Franz roy.fr...@linaro.org wrote: Update efi-stub.txt documentation to be more general and not x86 specific. Add ARM only dtb= command line option description. Signed-off-by: Roy Franz roy.fr...@linaro.org Acked-by: Grant Likely grant.lik

Re: [PATCH V5 2/6] Add shared update_fdt() function for ARM/ARM64

though. Acked-by: Grant Likely grant.lik...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH V5 2/6] Add shared update_fdt() function for ARM/ARM64

On Wed, 27 Nov 2013 15:31:51 -0800, Roy Franz roy.fr...@linaro.org wrote: Both ARM and ARM64 stubs will update the device tree that they pass to the kernel. In both cases they primarily need to add the same UEFI related information, so the function can be shared. Create a new FDT related

Re: [PATCH V5 4/6] Add EFI stub for ARM

patch ASAP. However, if you can I would still recommend respinning the series with the common bits split out right away since there's a much greater chance of getting the arm and arm64 maintainers to accept them. Acked-by: Grant Likely grant.lik...@linaro.org g. -- To unsubscribe from this list: send

Re: arm/arm64 UEFI boot protocol

On Wed, Nov 13, 2013 at 3:00 AM, Leif Lindholm leif.lindh...@linaro.org wrote: On Tue, Nov 12, 2013 at 04:42:41PM +, Will Deacon wrote: __ Name | Size | Description

Re: [PATCH 01/16] Move common EFI stub code from x86 arch code to common location

way to compile these functions as a separate .o file. Reviewed-by: Grant Likely grant.lik...@linaro.org g. -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/16] Add minimum address parameter to efi_low_alloc()

a flag to determine if low or high addresses should be preferred. g. Reviewed-by: Grant Likely grant.lik...@linaro.org Signed-off-by: Roy Franz roy.fr...@linaro.org --- arch/x86/boot/compressed/eboot.c | 11 ++- drivers/firmware/efi/efi-stub-helper.c |7 +-- 2

Re: [PATCH 09/16] Renames in handle_cmdline_files() to complete generalization.

On Fri, 9 Aug 2013 16:26:10 -0700, Roy Franz roy.fr...@linaro.org wrote: Rename variables to be not initrd specific, as now the function loads arbitrary files. Signed-off-by: Roy Franz roy.fr...@linaro.org Reviewed-by: Grant Likely grant.lik...@linaro.org --- drivers/firmware/efi/efi

Re: [PATCH 10/16] Move EFI_READ_CHUNK_SIZE define to shared location.

On Fri, 9 Aug 2013 16:26:11 -0700, Roy Franz roy.fr...@linaro.org wrote: This #define is only used the the shared code, so move it there. Signed-off-by: Roy Franz roy.fr...@linaro.org Can this be squashed into patch 1? g. --- arch/x86/boot/compressed/eboot.h |1 -

Re: [PATCH 13/16] resolve warnings found on ARM compile

On Fri, 9 Aug 2013 16:26:14 -0700, Roy Franz roy.fr...@linaro.org wrote: 2 unused labels 1 value computed is not used Signed-off-by: Roy Franz roy.fr...@linaro.org When posting a patch to fix compile errors or warnings, it is helpful inlude the output from the compiler with the

Re: [PATCH 15/16] Add EFI stub for ARM

On Fri, 9 Aug 2013 16:26:16 -0700, Roy Franz roy.fr...@linaro.org wrote: This patch adds EFI stub support for the ARM Linux kernel. The EFI stub operations similarly to the x86 stub: it is a shim between the EFI firmware and the normal zImage entry point, and sets up the environment that the

Re: [PATCH 12/16] Fix types in EFI calls to match EFI function definitions.

On Sat, Aug 31, 2013 at 12:12 AM, Roy Franz roy.fr...@linaro.org wrote: On Fri, Aug 30, 2013 at 6:39 AM, Grant Likely grant.lik...@secretlab.ca wrote: I think you need some description in the commit text about why the type of chunksize is changing. It's not clear why you're making this change

Re: [PATCH 1/4] Documentation: arm: [U]EFI runtime services

On Thu, Jun 27, 2013 at 2:32 AM, Matthew Garrett mj...@srcf.ucam.org wrote: On Wed, Jun 26, 2013 at 07:38:19AM -0700, James Bottomley wrote: The fixed virtual address scheme currently being looked at for x86_64 to make SetVirtualAddressMap() kexec invariant doesn't work on 32 bit because the

Re: [PATCH 1/4] Documentation: arm: [U]EFI runtime services

On Thu, Jun 27, 2013 at 7:33 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Thu, 2013-06-27 at 07:23 +0100, Grant Likely wrote: On Thu, Jun 27, 2013 at 2:32 AM, Matthew Garrett mj...@srcf.ucam.org wrote: On Wed, Jun 26, 2013 at 07:38:19AM -0700, James Bottomley wrote

Re: [PATCH 1/4] Documentation: arm: [U]EFI runtime services

On Thu, Jun 27, 2013 at 7:04 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 06/26/2013 01:31 PM, Leif Lindholm wrote: On Wed, Jun 26, 2013 at 12:32:30PM -0600, Stephen Warren wrote: What about ARMv8? Is the intention to have a separate definition for the UEFI bindings on ARMv8, so that

Re: [PATCH 1/4] Documentation: arm: [U]EFI runtime services

On Tue, Jun 25, 2013 at 7:11 PM, Leif Lindholm leif.lindh...@linaro.org wrote: This patch provides documentation of the [U]EFI runtime services and configuration features. Signed-off-by: Leif Lindholm leif.lindh...@linaro.org --- Documentation/arm/00-INDEX |3 +++

Re: [PATCH 1/4] Documentation: arm: [U]EFI runtime services

On Wed, Jun 26, 2013 at 12:42 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 06/25/2013 12:11 PM, Leif Lindholm wrote: This patch provides documentation of the [U]EFI runtime services and configuration features. diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt +The

Re: [PATCH 4/4] init: efi: arm: enable (U)EFI runtime services on arm

On Tue, Jun 25, 2013 at 7:11 PM, Leif Lindholm leif.lindh...@linaro.org wrote: Since the efi_set_virtual_address_map call has strict init ordering requirements, add an explicit hook in the required place. Signed-off-by: Leif Lindholm leif.lindh...@linaro.org --- init/main.c |6 ++

Re: [PATCH 2/4] x86: efi: break efi_lookup_mapped_addr out to generic code

memory map instead. Only + * callable after efi_enter_virtual_mode and before efi_free_boot_services. + */ +void __iomem *efi_lookup_mapped_addr(u64 phys_addr) Can be __init annotated. Although it's a good idea to do that in a separate patch. Otherwise looks good to me. Reviewed-by: Grant Likely

Re: [PATCH 3/4] arm: Add [U]EFI runtime services support

On Tue, Jun 25, 2013 at 7:11 PM, Leif Lindholm leif.lindh...@linaro.org wrote: This patch implements basic support for UEFI runtime services in the ARM architecture - a requirement for using efibootmgr to read and update the system boot configuration. It also locates any presented SMBIOS

Re: [PATCH 3/4] arm: Add [U]EFI runtime services support

On Tue, Jun 25, 2013 at 7:20 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Tue, Jun 25, 2013 at 07:11:02PM +0100, Leif Lindholm wrote: This patch implements basic support for UEFI runtime services in the ARM architecture - a requirement for using efibootmgr to read and update the system

Re: [PATCH 3/4] arm: Add [U]EFI runtime services support

On Wed, Jun 26, 2013 at 3:15 PM, Borislav Petkov b...@alien8.de wrote: On Wed, Jun 26, 2013 at 02:54:17PM +0100, Matt Fleming wrote: On Wed, 26 Jun, at 02:46:09PM, Grant Likely wrote: Eventually we'll need to look at how this interacts with kexec. A kexec'd kernel will need to use