diff --git a/doc/develop/process.rst b/doc/develop/process.rst
index 0fa0143..92477d0 100644
--- a/doc/develop/process.rst
+++ b/doc/develop/process.rst
@@ -165,8 +165,8 @@
   <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes>`_
   and similar additional tags.
 
-* Reviewed-by: The patch has been reviewed and found acceptible according to
-  the `Reveiwer's statement of oversight
+* Reviewed-by: The patch has been reviewed and found acceptable according to
+  the `Reviewer's statement of oversight
   <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#reviewer-s-statement-of-oversight>`_.
   A *Reviewed-by:* tag is a statement of opinion that the patch is an
   appropriate modification of the code without any remaining serious technical
@@ -193,8 +193,8 @@
 
 * Cc: If a person should have the opportunity to comment on a patch, you may
   optionally add a *Cc:* tag to the patch. Git tools (git send-email) will then
-  automatically arrange that they receives a copy of the patch when you submit it
-  to the mainling list. This is the only tag which might be added without an
+  automatically arrange that they receives a copy of the patch when you submit
+  it to the mailing list. This is the only tag which might be added without an
   explicit action by the person it names. This tag documents that potentially
   interested parties have been included in the discussion.
   For example, when your change affects a specific board or driver, then makes
@@ -209,7 +209,7 @@
 #. The responsible custodian inspects this patch, especially for:
 
    #. The commit message is useful, descriptive and makes correct and
-      appropraite usage of required *git tags*.
+      appropriate usage of required *git tags*.
 
    #. :doc:`codingstyle`
 
@@ -251,7 +251,7 @@
    workflows and environments however.
 
 #. Although a custodian is supposed to perform their own tests it is a
-   well-known and accepted fact that they needs help from other developers who
+   well-known and accepted fact that they need help from other developers who
    - for example - have access to the required hardware or other relevant
    environments.  Custodians are expected to ask for assistance with testing
    when required.
diff --git a/doc/develop/sending_patches.rst b/doc/develop/sending_patches.rst
index 1730756..ba73d0d 100644
--- a/doc/develop/sending_patches.rst
+++ b/doc/develop/sending_patches.rst
@@ -20,8 +20,8 @@
 Using patman
 ------------
 
-You can use a tool called patman to prepare, check and sent patches. It creates
-change logs, cover letters and patch notes. It also simplified the process of
+You can use a tool called patman to prepare, check and send patches. It creates
+change logs, cover letters and patch notes. It also simplifies the process of
 sending multiple versions of a series.
 
 See more details at :doc:`patman`.
@@ -41,7 +41,7 @@
   past commits might have input to your change, so also CC them if you think
   they may have feedback.
 
-* Patches should always contain exactly one complete logical change, i. e.
+* Patches should always contain exactly one complete logical change, i.e.
 
    * Changes that contain different, unrelated modifications shall be submitted
      as *separate* patches, one patch per changeset.
@@ -68,7 +68,7 @@
      as such -- that *precedes* your substantive patch.
 
    * For minor modifications (e.g. changed arguments of a function call),
-     adhere to the present codingstyle of the module. Relating checkpatch
+     adhere to the present coding style of the module. Relating checkpatch
      warnings can be ignored in this case. A respective note in the commit or
      cover letter why they are ignored is desired.
 
@@ -93,7 +93,7 @@
   visible as headline of your commit message. Make sure the subject does not
   exceed 60 characters or so.
 
-* The start of the subject should be a meaningfull tag (arm:, ppc:, tegra:,
+* The start of the subject should be a meaningful tag (arm:, ppc:, tegra:,
   net:, ext2:, etc)
 
 * Include the string "PATCH" in the Subject: line of your message, e. g.
@@ -247,14 +247,14 @@
 to observe the following rules.
 
 * Make an appropriate note that this is a re-submission in the subject line,
-  eg. "[PATCH v2] Add support for feature X". ``git format-patch
+  e.g. "[PATCH v2] Add support for feature X". ``git format-patch
   --subject-prefix="PATCH v2"`` can be used in this case (see the example
   below).
 
-* Please make sure to keep a "change log", i. e. a description of what you have
+* Please make sure to keep a "change log", i.e. a description of what you have
   changed compared to previous versions of this patch. This change log should
   be added below the "---" line in the patch, which starts the "comment
-  section", i. e. which contains text that does not get included into the
+  section", i.e. which contains text that does not get included into the
   actual commit message.
   Note: it is *not* sufficient to provide a change log in some cover letter
   that gets sent as a separate message with the patch series. The reason is
@@ -312,7 +312,7 @@
 2. All code must follow the :doc:`codingstyle` requirements.
 
 3. Before sending the patch, you *must* run some form of local testing.
-   Submitting a patch that does not build or function correct is a mistake. For
+   Submitting a patch that does not build or function correctly is a mistake. For
    non-trivial patches, either building a number of platforms locally or making
    use of :doc:`ci_testing` is strongly encouraged in order to avoid problems
    that can be found when attempting to merge the patch.
diff --git a/doc/develop/system_configuration.rst b/doc/develop/system_configuration.rst
index 52e4e1d..40be46b 100644
--- a/doc/develop/system_configuration.rst
+++ b/doc/develop/system_configuration.rst
@@ -86,12 +86,12 @@
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 While there are some cases where it should be fairly obvious where to use each
-mechanism, as for example a command would done via Kconfig, a new I2C driver
+mechanism, as for example a command would be done via Kconfig, a new I2C driver
 should use Kconfig and be configured via driver model and a header of values
 generated by an external tool should be ``CFG``, there will be cases where it's
 less clear and one needs to take care when implementing it. In general,
 configuration *options* should be done in Kconfig and configuration *settings*
-should done in driver model or ``CFG``. Let us discuss things to keep in mind
+should be done in driver model or ``CFG``. Let us discuss things to keep in mind
 when picking the appropriate mechanism.
 
 A thing to keep in mind is that we have a strong preference for using Kconfig as
@@ -122,7 +122,7 @@
 constructed values, resulting in less clear code. Consider the example of a set
 of register values for a memory controller. Defining this as a series of logical
 ORs and shifts based on other defines is more clear than the Kconfig entry that
-set the calculated value alone.
+sets the calculated value alone.
 
 When it has been determined that the practical solution is to utilize the
 ``CFG`` mechanism, the next decision is where to place these settings. It is
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index e0835be..a944c0f 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -14,7 +14,7 @@
 ------------------
 
 The implementation of UEFI in U-Boot strives to reach the requirements described
-in the "Embedded Base Boot Requirements (EBBR) Specification - Release v1.0"
+in the "Embedded Base Boot Requirements (EBBR) Specification - Release v2.1.0"
 [2]. The "Server Base Boot Requirements System Software on ARM Platforms" [3]
 describes a superset of the EBBR specification and may be used as further
 reference.
@@ -799,8 +799,8 @@
 -----
 
 * [1] http://uefi.org/specifications - UEFI specifications
-* [2] https://github.com/ARM-software/ebbr/releases/download/v1.0/ebbr-v1.0.pdf -
-  Embedded Base Boot Requirements (EBBR) Specification - Release v1.0
+* [2] https://github.com/ARM-software/ebbr/releases/download/v2.1.0/ebbr-v2.1.0.pdf -
+  Embedded Base Boot Requirements (EBBR) Specification - Release v2.1.0
 * [3] https://developer.arm.com/docs/den0044/latest/server-base-boot-requirements-system-software-on-arm-platforms-version-11 -
   Server Base Boot Requirements System Software on ARM Platforms - Version 1.1
 * [4] :doc:`iscsi`
diff --git a/doc/sphinx/requirements.txt b/doc/sphinx/requirements.txt
index 5baec4d..f9f6cc6 100644
--- a/doc/sphinx/requirements.txt
+++ b/doc/sphinx/requirements.txt
@@ -1,6 +1,6 @@
 alabaster==0.7.12
 Babel==2.9.1
-certifi==2021.10.8
+certifi==2022.12.7
 charset-normalizer==2.0.12
 docutils==0.16
 idna==3.3
diff --git a/include/efi_api.h b/include/efi_api.h
index 9bb0d44..00c98e0 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -232,7 +232,7 @@
 
 #define EFI_CONFORMANCE_PROFILES_TABLE_VERSION 1
 
-#define EFI_CONFORMANCE_PROFILE_EBBR_2_0_GUID \
+#define EFI_CONFORMANCE_PROFILE_EBBR_2_1_GUID \
 	EFI_GUID(0xcce33c35, 0x74ac, 0x4087, 0xbc, 0xe7, \
 		 0x8b, 0x29, 0xb0, 0x2e, 0xeb, 0x27)
 
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index e2b6438..b498c72 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -384,8 +384,8 @@
 	help
 	  Enabling this option created the ECPT UEFI table.
 
-config EFI_EBBR_2_0_CONFORMANCE
-	bool "Add the EBBRv2.0 conformance entry to the ECPT table"
+config EFI_EBBR_2_1_CONFORMANCE
+	bool "Add the EBBRv2.1 conformance entry to the ECPT table"
 	depends on EFI_ECPT
 	depends on EFI_LOADER_HII
 	depends on EFI_RISCV_BOOT_PROTOCOL || !RISCV
@@ -393,7 +393,7 @@
 	depends on EFI_UNICODE_COLLATION_PROTOCOL2
 	default y
 	help
-	  Enabling this option adds the EBBRv2.0 conformance entry to the ECPT UEFI table.
+	  Enabling this option adds the EBBRv2.1 conformance entry to the ECPT UEFI table.
 
 config EFI_RISCV_BOOT_PROTOCOL
 	bool "RISCV_EFI_BOOT_PROTOCOL support"
diff --git a/lib/efi_loader/efi_conformance.c b/lib/efi_loader/efi_conformance.c
index a49aae9..3036d46 100644
--- a/lib/efi_loader/efi_conformance.c
+++ b/lib/efi_loader/efi_conformance.c
@@ -12,8 +12,8 @@
 #include <malloc.h>
 
 static const efi_guid_t efi_ecpt_guid = EFI_CONFORMANCE_PROFILES_TABLE_GUID;
-static const efi_guid_t efi_ebbr_2_0_guid =
-	EFI_CONFORMANCE_PROFILE_EBBR_2_0_GUID;
+static const efi_guid_t efi_ebbr_2_1_guid =
+	EFI_CONFORMANCE_PROFILE_EBBR_2_1_GUID;
 
 /**
  * efi_ecpt_register() - Install the ECPT system table.
@@ -38,9 +38,9 @@
 		return ret;
 	}
 
-	if (CONFIG_IS_ENABLED(EFI_EBBR_2_0_CONFORMANCE))
+	if (CONFIG_IS_ENABLED(EFI_EBBR_2_1_CONFORMANCE))
 		guidcpy(&ecpt->conformance_profiles[num_entries++],
-			&efi_ebbr_2_0_guid);
+			&efi_ebbr_2_1_guid);
 
 	ecpt->version = EFI_CONFORMANCE_PROFILES_TABLE_VERSION;
 	ecpt->number_of_profiles = num_entries;
diff --git a/lib/efi_selftest/efi_selftest_ecpt.c b/lib/efi_selftest/efi_selftest_ecpt.c
index e8cc135..09c5e96 100644
--- a/lib/efi_selftest/efi_selftest_ecpt.c
+++ b/lib/efi_selftest/efi_selftest_ecpt.c
@@ -10,7 +10,7 @@
 #include <efi_selftest.h>
 
 static const efi_guid_t guid_ecpt = EFI_CONFORMANCE_PROFILES_TABLE_GUID;
-static const efi_guid_t guid_ebbr_2_0 = EFI_CONFORMANCE_PROFILE_EBBR_2_0_GUID;
+static const efi_guid_t guid_ebbr_2_1 = EFI_CONFORMANCE_PROFILE_EBBR_2_1_GUID;
 
 /*
  * ecpt_find_guid() - find GUID in EFI Conformance Profile Table
@@ -53,9 +53,9 @@
 		return EFI_ST_FAILURE;
 	}
 
-	if (CONFIG_IS_ENABLED(EFI_EBBR_2_0_CONFORMANCE)) {
+	if (CONFIG_IS_ENABLED(EFI_EBBR_2_1_CONFORMANCE)) {
 		++expected_entries;
-		if (ecpt_find_guid(ecpt, &guid_ebbr_2_0))
+		if (ecpt_find_guid(ecpt, &guid_ebbr_2_1))
 			return EFI_ST_FAILURE;
 	}