From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: barebox@lists.infradead.org
Cc: Ahmad Fatoum <a.fatoum@pengutronix.de>
Subject: [PATCH] Documentation: efi: fix typos
Date: Fri, 30 Aug 2019 14:40:01 +0200 [thread overview]
Message-ID: <20190830124001.32053-1-a.fatoum@pengutronix.de> (raw)
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
Documentation/boards/efi.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/boards/efi.rst b/Documentation/boards/efi.rst
index 3da2daac99ef..2178c9ab4293 100644
--- a/Documentation/boards/efi.rst
+++ b/Documentation/boards/efi.rst
@@ -43,7 +43,7 @@ name it ``BOOTx64.EFI`` on 64bit architectures and ``BOOTIA32.EFI`` on 32bit
architectures. Switching to USB boot in the BIOS should then be enough to
start barebox via USB. Some BIOSes allow to specify a path to a binary to
be executed, others have a "start UEFI shell" entry which executes
-EFI/Shellx64.efi on the :term:`ESP`. This can be a barebox binary aswell.
+EFI/Shellx64.efi on the :term:`ESP`. This can be a barebox binary as well.
To use the :ref:`state_framework`, the describing devicetree file ``state.dtb``
has to be put into the ``EFI/barebox/`` directory.
Supported backends for EFI are raw partitions that can be discovered via a
@@ -200,7 +200,7 @@ EFI device paths
In EFI each device can be pointed to using a device path. Device paths have multiple
components. The toplevel component on X86 systems will be the PCI root complex, on
-other systems this can be the physical memory space. Each component will now descrive
+other systems this can be the physical memory space. Each component will now describe
how to find the child component on the parent bus. Additional device path nodes can
describe network addresses or filenames on partitions. Device paths have a binary
representation and a clearly defined string representation. These characteristics make
@@ -274,7 +274,7 @@ Network Protocol GUID:
EFI_GUID( 0xA19832B9, 0xAC25, 0x11D3, 0x9A, 0x2D, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D )
Matching between EFI devices and drivers is done based on the Protocol GUIDs, so
-whenever a driver GUID matches one of the GUIDs a device imeplements the drivers
+whenever a driver GUID matches one of the GUIDs a device implements the drivers
probe function is called.
.. _efi_building_edk2:
--
2.23.0
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next reply other threads:[~2019-08-30 12:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-30 12:40 Ahmad Fatoum [this message]
2019-09-02 7:18 ` Sascha Hauer
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=20190830124001.32053-1-a.fatoum@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=barebox@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