linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: roy.franz@linaro.org (Roy Franz)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 01/17] EFI stub documentation updates
Date: Tue,  6 Aug 2013 20:44:57 -0700	[thread overview]
Message-ID: <1375847113-24884-2-git-send-email-roy.franz@linaro.org> (raw)
In-Reply-To: <1375847113-24884-1-git-send-email-roy.franz@linaro.org>

The ARM kernel also has an EFI stub which works largely the same way
as the x86 stub, so move the documentation out of x86 directory and
update to reflect that it is generic, and add ARM specific text.

Signed-off-by: Roy Franz <roy.franz@linaro.org>
---
 Documentation/efi-stub.txt     |   78 ++++++++++++++++++++++++++++++++++++++++
 Documentation/x86/efi-stub.txt |   65 ---------------------------------
 arch/x86/Kconfig               |    2 +-
 3 files changed, 79 insertions(+), 66 deletions(-)
 create mode 100644 Documentation/efi-stub.txt
 delete mode 100644 Documentation/x86/efi-stub.txt

diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt
new file mode 100644
index 0000000..19e897c
--- /dev/null
+++ b/Documentation/efi-stub.txt
@@ -0,0 +1,78 @@
+			  The EFI Boot Stub
+		     ---------------------------
+
+On the x86 and ARM platforms, a kernel zImage/bzImage can masquerade
+as a PE/COFF image, thereby convincing EFI firmware loaders to load
+it as an EFI executable. The code that modifies the bzImage header,
+along with the EFI-specific entry point that the firmware loader
+jumps to are collectively known as the "EFI boot stub", and live in
+arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c,
+respectively.  For ARM the EFI stub is implemented in
+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.
+
+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
+a certain sense it *IS* the boot loader.
+
+The EFI boot stub is enabled with the CONFIG_EFI_STUB kernel option.
+
+
+**** How to install bzImage.efi
+
+The bzImage located in arch/x86/boot/bzImage must be copied to the EFI
+System Partiion (ESP) and renamed with the extension ".efi". Without
+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.
+
+
+**** Passing kernel parameters from the EFI shell
+
+Arguments to the kernel can be passed after bzImage.efi, e.g.
+
+	fs0:> bzImage.efi console=ttyS0 root=/dev/sda4
+
+
+**** The "initrd=" option
+
+Like most boot loaders, the EFI stub allows the user to specify
+multiple initrd files using the "initrd=" option. This is the only EFI
+stub-specific command line parameter, everything else is passed to the
+kernel when it boots.
+
+The path to the initrd file must be an absolute path from the
+beginning of the ESP, relative path names do not work. Also, the path
+is an EFI-style path and directory elements must be separated with
+backslashes (\). For example, given the following directory layout,
+
+fs0:>
+	Kernels\
+			bzImage.efi
+			initrd-large.img
+
+	Ramdisks\
+			initrd-small.img
+			initrd-medium.img
+
+to boot with the initrd-large.img file if the current working
+directory is fs0:\Kernels, the following command must be used,
+
+	fs0:\Kernels> bzImage.efi initrd=\Kernels\initrd-large.img
+
+Notice how bzImage.efi can be specified with a relative path. That's
+because the image we're executing is interpreted by the EFI shell,
+which understands relative paths, whereas the rest of the command line
+is passed to bzImage.efi.
+
+
+**** The "dtb=" option
+
+For the ARM 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.
diff --git a/Documentation/x86/efi-stub.txt b/Documentation/x86/efi-stub.txt
deleted file mode 100644
index 44e6bb6..0000000
--- a/Documentation/x86/efi-stub.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-			  The EFI Boot Stub
-		     ---------------------------
-
-On the x86 platform, a bzImage can masquerade as a PE/COFF image,
-thereby convincing EFI firmware loaders to load it as an EFI
-executable. The code that modifies the bzImage header, along with the
-EFI-specific entry point that the firmware loader jumps to are
-collectively known as the "EFI boot stub", and live in
-arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c,
-respectively.
-
-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
-a certain sense it *IS* the boot loader.
-
-The EFI boot stub is enabled with the CONFIG_EFI_STUB kernel option.
-
-
-**** How to install bzImage.efi
-
-The bzImage located in arch/x86/boot/bzImage must be copied to the EFI
-System Partiion (ESP) and renamed with the extension ".efi". Without
-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.
-
-
-**** Passing kernel parameters from the EFI shell
-
-Arguments to the kernel can be passed after bzImage.efi, e.g.
-
-	fs0:> bzImage.efi console=ttyS0 root=/dev/sda4
-
-
-**** The "initrd=" option
-
-Like most boot loaders, the EFI stub allows the user to specify
-multiple initrd files using the "initrd=" option. This is the only EFI
-stub-specific command line parameter, everything else is passed to the
-kernel when it boots.
-
-The path to the initrd file must be an absolute path from the
-beginning of the ESP, relative path names do not work. Also, the path
-is an EFI-style path and directory elements must be separated with
-backslashes (\). For example, given the following directory layout,
-
-fs0:>
-	Kernels\
-			bzImage.efi
-			initrd-large.img
-
-	Ramdisks\
-			initrd-small.img
-			initrd-medium.img
-
-to boot with the initrd-large.img file if the current working
-directory is fs0:\Kernels, the following command must be used,
-
-	fs0:\Kernels> bzImage.efi initrd=\Kernels\initrd-large.img
-
-Notice how bzImage.efi can be specified with a relative path. That's
-because the image we're executing is interpreted by the EFI shell,
-which understands relative paths, whereas the rest of the command line
-is passed to bzImage.efi.
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b32ebf9..ec65b51 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1579,7 +1579,7 @@ config EFI_STUB
           This kernel feature allows a bzImage to be loaded directly
 	  by EFI firmware without the use of a bootloader.
 
-	  See Documentation/x86/efi-stub.txt for more information.
+	  See Documentation/efi-stub.txt for more information.
 
 config SECCOMP
 	def_bool y
-- 
1.7.10.4

  reply	other threads:[~2013-08-07  3:44 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-07  3:44 [PATCH V2 00/17] EFI stub for ARM Roy Franz
2013-08-07  3:44 ` Roy Franz [this message]
2013-08-07  3:44 ` [PATCH 02/17] Move common EFI stub code from x86 arch code to common location Roy Franz
2013-08-07  3:44 ` [PATCH 03/17] 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 Roy Franz
2013-08-07 13:08   ` Matt Fleming
2013-08-07 17:10     ` Roy Franz
2013-08-07 21:55       ` Matt Fleming
2013-08-07  3:45 ` [PATCH 04/17] Rename memory allocation/free functions Roy Franz
2013-08-07 13:09   ` Matt Fleming
2013-08-07 17:12     ` Roy Franz
2013-08-07  3:45 ` [PATCH 05/17] Add minimum address parameter to efi_low_alloc() Roy Franz
2013-08-07  3:45 ` [PATCH 06/17] 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 Roy Franz
2013-08-07  3:45 ` [PATCH 07/17] 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 Roy Franz
2013-08-07  3:45 ` [PATCH 08/17] Allow efi_free() to be called with size of 0, and do nothing in that case Roy Franz
2013-08-07  3:45 ` [PATCH 09/17] Generalize handle_ramdisks() and rename to handle_cmdline_files() Roy Franz
2013-08-07  3:45 ` [PATCH 10/17] Renames in handle_cmdline_files() to complete generalization Roy Franz
2013-08-07 13:09   ` Matt Fleming
2013-08-07  3:45 ` [PATCH 11/17] Move EFI_READ_CHUNK_SIZE define to shared location Roy Franz
2013-08-07  3:45 ` [PATCH 12/17] Add proper definitions for some EFI function pointers Roy Franz
2013-08-07 13:09   ` Matt Fleming
2013-08-07 17:20     ` Roy Franz
2013-08-09 14:10   ` Mark Salter
2013-08-09 14:13     ` Roy Franz
2013-08-07  3:45 ` [PATCH 13/17] Fix types in EFI calls to match EFI function definitions Roy Franz
2013-08-07  3:45 ` [PATCH 14/17] resolve warnings found on ARM compile Roy Franz
2013-08-07  3:45 ` [PATCH 15/17] Add strstr to compressed string.c for ARM Roy Franz
2013-08-07  3:45 ` [PATCH 16/17] Add EFI stub " Roy Franz
2013-08-07 18:05   ` Dave Martin
2013-08-07 18:33     ` Leif Lindholm
2013-08-08 21:57     ` Roy Franz
2013-08-09  0:53       ` Roy Franz
2013-08-13 14:21       ` Dave P Martin
2013-08-07  3:45 ` [PATCH 17/17] Add config EFI_STUB for ARM to Kconfig Roy Franz
2013-08-07  7:44 ` [PATCH V2 00/17] EFI stub for ARM Matt Fleming

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1375847113-24884-2-git-send-email-roy.franz@linaro.org \
    --to=roy.franz@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).