Re: [PATCH 2/3] doc: arm64: add description of EFI stub support

[Grant Likely]

On Fri, 29 Nov 2013 17:05:11 -0500, Mark Salter <msalter@xxxxxxxxxx> wrote:

Even documentation updates should have a mildly sane commit text. State
why these changes came about. Give a future reader at least some clues
as to why these changes were made now.

Otherwise:

Acked-by: Grant Likely <grant.likely@xxxxxxxxxx>

g.

> Signed-off-by: Mark Salter <msalter@xxxxxxxxxx>
> CC: Catalin Marinas <catalin.marinas@xxxxxxx>
> CC: Will Deacon <will.deacon@xxxxxxx>
> CC: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> CC: matt.fleming@xxxxxxxxx
> CC: linux-efi@xxxxxxxxxxxxxxx
> CC: linux-doc@xxxxxxxxxxxxxxx
> CC: Rob Landley <rob@xxxxxxxxxxx> 
> CC: Leif Lindholm <leif.lindholm@xxxxxxxxxx>
> CC: roy.franz@xxxxxxxxxx
> ---
>  Documentation/arm64/booting.txt |  4 ++++
>  Documentation/efi-stub.txt      | 10 ++++++++--
>  2 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt
> index a9691cc..aa95d38c 100644
> --- a/Documentation/arm64/booting.txt
> +++ b/Documentation/arm64/booting.txt
> @@ -85,6 +85,10 @@ The decompressed kernel image contains a 64-byte header as follows:
>  Header notes:
>  
>  - code0/code1 are responsible for branching to stext.
> +- when booting through EFI, code0/code1 are initially skipped.
> +  res5 is an offset to the PE header and the PE header has the EFI
> +  entry point (efi_stub_entry). When the stub has done its work, it
> +  jumps to code0 to resume the normal boot process.
>  
>  The image must be placed at the specified offset (currently 0x80000)
>  from the start of the system RAM and called there. The start of the
> diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt
> index 19e897c..c2a4b11 100644
> --- a/Documentation/efi-stub.txt
> +++ b/Documentation/efi-stub.txt
> @@ -12,6 +12,11 @@ arch/arm/boot/compressed/efi-header.S and
>  arch/arm/boot/compressed/efi-stub.c.  EFI stub code that is shared
>  between architectures is in drivers/firmware/efi/efi-stub-helper.c.
>  
> +For arm64, there is no compressed kernel support, so the Image itself
> +masquerades as a PE/COFF image and the EFI stub is linked into the
> +kernel. The arm64 EFI stub lives in arch/arm64/kernel/efi-entry.S
> +and arch/arm64/kernel/efi-stub.c.
> +
>  By using the EFI boot stub it's possible to boot a Linux kernel
>  without the use of a conventional EFI boot loader, such as grub or
>  elilo. Since the EFI boot stub performs the jobs of a boot loader, in
> @@ -28,7 +33,8 @@ the extension the EFI firmware loader will refuse to execute it. It's
>  not possible to execute bzImage.efi from the usual Linux file systems
>  because EFI firmware doesn't have support for them.  For ARM the
>  arch/arm/boot/zImage should be copied to the system partition, and it
> -may not need to be renamed.
> +may not need to be renamed. Similarly for arm64, arch/arm64/boot/Image
> +should be copied but not necessarily renamed.
>  
>  
>  **** Passing kernel parameters from the EFI shell
> @@ -72,7 +78,7 @@ is passed to bzImage.efi.
>  
>  **** The "dtb=" option
>  
> -For the ARM architecture, we also need to be able to provide a device
> +For ARM and arm64 architecture, we also need to be able to provide a device
>  tree to the kernel.  This is done with the "dtb=" command line option,
>  and is process in the same manner as the "initrd=" option that is described
>  above.
> -- 
> 1.8.3.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/