[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <524D9726.6080501@gmail.com>
Date: Thu, 03 Oct 2013 11:11:18 -0500
From: Rob Herring <robherring2@...il.com>
To: Leif Lindholm <leif.lindholm@...aro.org>
CC: linux-arm-kernel@...ts.infradead.org, roy.franz@...aro.org,
linux-efi@...r.kernel.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, grant.likely@...retlab.ca,
matt.fleming@...el.com, msalter@...hat.com,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 1/3] Documentation: arm: add UEFI support documentation
Adding devicetree list since you are defining bindings...
On 10/03/2013 06:24 AM, Leif Lindholm wrote:
> This patch provides documentation of the [U]EFI runtime services and
> configuration features.
>
> Cc: linux-doc@...r.kernel.org
> Signed-off-by: Leif Lindholm <leif.lindholm@...aro.org>
> Acked-by: Rob Landley <rob@...dley.net>
> ---
> Documentation/arm/00-INDEX | 3 +++
> Documentation/arm/uefi.txt | 47 ++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 50 insertions(+)
> create mode 100644 Documentation/arm/uefi.txt
>
> diff --git a/Documentation/arm/00-INDEX b/Documentation/arm/00-INDEX
> index 4978456..87e01d1 100644
> --- a/Documentation/arm/00-INDEX
> +++ b/Documentation/arm/00-INDEX
> @@ -36,3 +36,6 @@ nwfpe/
> - NWFPE floating point emulator documentation
> swp_emulation
> - SWP/SWPB emulation handler/logging description
> +
> +uefi.txt
> + - [U]EFI configuration and runtime services documentation
> diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt
> new file mode 100644
> index 0000000..e6e4d41
> --- /dev/null
> +++ b/Documentation/arm/uefi.txt
> @@ -0,0 +1,47 @@
> +UEFI, the Unified Extensible Firmware Interface is a speifcication
> +governing the behaviours of compatible firmware interfaces. It is
> +maintained by the UEFI Forum - http://www.uefi.org/.
> +
> +Since UEFI is an evolution of its predecessor 'EFI', the terms EFI and
> +UEFI are used somewhat interchangeably in this document and associated
> +source code.
> +
> +The implementation depends on receiving the UEFI runtime memory map and a
> +pointer to the System Table in a Flattened Device Tree - so is only available
> +with CONFIG_OF.
> +
> +It parses the FDT /chosen node for the following parameters:
DT bindings should be documented in Documentation/devicetree/bindings.
I also wonder if this would be more appropriately placed in a /firmware
node.
> +- 'linux,efi-system-table':
> + Physical address of the system table. (required)
> + 64-bit value since an ARMv7 plattform may support LPAE, and to facilitate
> + code sharing with arm64. Top 32 bits will be ignored, since UEFI specification
> + mandates a 1:1 mapping of all RAM.
> +- 'linux,efi-mmap':
> + The EFI memory map as an embedded property. (required)
> + An array of type EFI_MEMORY_DESCRIPTOR as described by the UEFI
> + specification, current version described in Linux by efi_memory_desc_t.
Is that too complex to describe here?
> + The memory map is represented in little-endian, not DT, byte order.
> + This map needs to contain at least the regions to be preserved for runtime
> + services, but would normally just be the map retreieved by calling UEFI
> + GetMemoryMap() immediately before ExitBootServices().
> +- 'linux,efi-mmap-desc-size':
> + Size of each descriptor in the memory map. (override default)
32-bit value?
> +- 'linux,efi-mmap-desc-ver':
> + Memory descriptor format version. (override default)
String? Number?
Are these all generated by UEFI at runtime or could they be statically
set in a platform's DTB?
How would other OS's get this information? Is this really linux specific?
Rob
> +
> +It also depends on early_memremap() to parse the UEFI configuration tables.
> +
> +For actually enabling [U]EFI support, enable:
> +- CONFIG_EFI=y
> +- CONFIG_EFI_VARS=y or m
> +
> +After the kernel has mapped the required regions into its address space,
> +a SetVirtualAddressMap() call is made into UEFI in order to update
> +relocations. This call must be performed with all the code in a 1:1
> +mapping. This implementation achieves this by temporarily disabling the
> +MMU for the duration of this call. This can only be done safely:
> +- before secondary CPUs are brought online.
> +- after early_initcalls have completed, since it uses setup_mm_for_reboot().
> +
> +For verbose debug messages, specify 'uefi_debug' on the kernel command
> +line.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists