Fix typos found by codespell

IDE/IAR/README.md

@@ -76,7 +76,7 @@ Using the ST-LINK Utility, perform the following steps:
 *Erase the entire flash memory before uploading the binary files*
 
 
-	2. Upload `wolfboot.bin` to addess 0x08000000
+	2. Upload `wolfboot.bin` to address 0x08000000
 
 ![Upload bootloader](../../docs/png/windows_upload_1.png)
 

IDE/Renesas/e2studio/RA6M4/Readme.md

@@ -7,7 +7,7 @@ securely updated to v2. Both versions behave the same except displaying its vers
 They are compiled by e2Studio and running on the target board.
 
 In this demo, you may download two versions of application binary file by Renesas Flash Programmer.
-You can download and excute wolfBoot by e2Studio debugger. Use a USB connection between PC and the
+You can download and execute wolfBoot by e2Studio debugger. Use a USB connection between PC and the
 board for the debugger and flash programmer.
 
 Please see `Readme_wSCE.md` for Renesas SCE use case.
@@ -131,7 +131,7 @@ Project properties are preset for the demo.
 Need to set:
 #define BSP_FEATURE_FLASH_SUPPORTS_ACCESS_WINDOW          (1)\
 
-Code Origin and entry point is "0x00010200". app_RA.elf is gnerated under Debug. 
+Code Origin and entry point is "0x00010200". app_RA.elf is generated under Debug. 
 
 ### 4) Generate Signature for app V1
 You can derive bair binary file (app_RA.bin) by objcopy command as follows.
@@ -172,7 +172,7 @@ $ aarch64-none-elf-objcopy.exe -I binary -O srec --change-addresses=0x00010000 a
 ```
 
 
-### 6) Execute inital boot
+### 6) Execute initial boot
 
 Now, you can download and start wolfBoot program by e2Studio debugger.
 After starting the program, you can see the partition information as follows.

IDE/Renesas/e2studio/RA6M4/Readme_wSCE.md

@@ -7,7 +7,7 @@ securely updated to v2. Both versions behave the same except displaying its vers
 They are compiled by e2Studio and running on the target board.
 
 In this demo, you may download two versions of application binary file by Renesas Flash Programmer.
-You can download and excute wolfBoot by e2Studio debugger. Use a USB connection between PC and the
+You can download and execute wolfBoot by e2Studio debugger. Use a USB connection between PC and the
 board for the debugger and flash programmer.It is only available RSA with Renesas SCE now.
 
 ## 2. Components and Tools
@@ -95,7 +95,7 @@ Enabled `WOLFBOOT_RENESAS_SCEPROTECT` expects to use Renesas SCE.
 
 ### 3) Compile the sample application
 
-Open project under IDE/Renesas/e2studio/RA6M4/app_RA with e2Studio. Open `script` folder and copy orignal `fsp.ld` to `fsp.ld.org`. Copy `fsp_wsce.ld` to `fsp.ld`, and then build the project.
+Open project under IDE/Renesas/e2studio/RA6M4/app_RA with e2Studio. Open `script` folder and copy original `fsp.ld` to `fsp.ld.org`. Copy `fsp_wsce.ld` to `fsp.ld`, and then build the project.
 Project properties are preset for the demo.
 
  #### 3-1). Prepare SEGGER_RTT for logging
@@ -126,7 +126,7 @@ Project properties are preset for the demo.
 Need to set:
 #define BSP_FEATURE_FLASH_SUPPORTS_ACCESS_WINDOW          (1)\
 
-Code Origin and entry point is "0x00010200". app_RA.elf is gnerated under Debug. 
+Code Origin and entry point is "0x00010200". app_RA.elf is generated under Debug. 
 
 ### 4) Generate Wrapped Key for SCE
 
@@ -188,7 +188,7 @@ $ aarch64-none-elf-objcopy.exe -I binary -O srec --change-addresses=0x00020000 a
 ```
 
 
-### 6) Execute inital boot
+### 6) Execute initial boot
 
 Now, you can download and start wolfBoot program by e2Studio debugger.
 After starting the program, you can see the partition information as follows.

IDE/Renesas/e2studio/RX72N/Readme.md

@@ -7,7 +7,7 @@ securely updated to v2. Both versions behave the same except displaying its vers
 They are compiled by e2Studio and running on the target board.
 
 In this demo, you may download two versions of application binary file by Renesas Flash Programmer.
-You can download and excute wolfBoot by e2Studio debugger. Use a USB connection between PC and the
+You can download and execute wolfBoot by e2Studio debugger. Use a USB connection between PC and the
 board for the debugger and flash programmer.
 
 ## 2. Components and Tools
@@ -63,7 +63,7 @@ cerurely updated to v2. Both versions behave the same except displaying its vers
 They are compiled by e2Studio and running on the target board.
 
 In this demo, you may download two versions of application binary file by Renesas Flash Programmer.
-You can download and excute wolfBoot by e2Studio debugger. Use a USB connection between PC and the
+You can download and execute wolfBoot by e2Studio debugger. Use a USB connection between PC and the
 board for the debugger and flash programmer.
 
 
@@ -140,7 +140,7 @@ Pre-Include
 Code Origin and entry point (PResetPRG) is "0xffc10200" (See Section Viewer of Linker Section).
 ```
 
-app_RenesasRx01.x in ELF is gnerated under HardwareDebug. You can derive bair binary file 
+app_RenesasRx01.x in ELF is generated under HardwareDebug. You can derive bair binary file 
 (app_RenesasRx01.bin) by rx-elf-objcopy.exe command as follows. -R are for eliminate unnecessary
 secrions.
 
@@ -184,7 +184,7 @@ $ rx-elf-objcopy.exe -I binary -O srec --change-addresses=0xffc10000 app_Renesas
 ```
 
 
-### 3-7 Execute inital boot
+### 3-7 Execute initial boot
 
 Now, you can download and start wolfBoot program by e2Studio debugger.
 After starting the program, you can see the partition information as follows.
@@ -266,7 +266,7 @@ Firmware Update is triggered
 ```
 
 After you see the message, hit any key so that the application calls
-wolfBoot_update_trigger() whcih changes the partition status and triggers
+wolfBoot_update_trigger() which changes the partition status and triggers
 updating the firmware.
 
 Since this is just a trigger, the application can continue the process.

IDE/Renesas/e2studio/RX72N/x2hex.sh

@@ -59,7 +59,7 @@ case $4 in
     5) SIGN_METHOD=${ECC256_SIGN} ;;
     6) SIGN_METHOD=${ECC384_SIGN} ;;
     7) SIGN_METHOD=${ECC512_SIGN} ;;
-    *) echo "invalid signature mehtod $4. Please specifiy [0-8] for sign."
+    *) echo "invalid signature method $4. Please specify [0-8] for sign."
        exit 1 ;;
 esac
 

IDE/XilinxSDK/README.md

@@ -57,7 +57,7 @@ Xilinx uses a `bootgen` tool for generating a boot binary image that has Xilinx
 3. Import example project for programming eFuses:
     * New BSP project (program efuses , ZCU102_hw_platform, standalone, CPU: PSU_cortexa53_0)
     * Goto Xilinx Board Support Packet Settings.
-    * Scroll down to Supported Libraries and Check the xiskey libray
+    * Scroll down to Supported Libraries and Check the xiskey library
     * In the system.mss pane, scroll down to Libraries and click Import Examples.
     * Check the xilskey_esfuseps_zynqmp_example
 4. Edit `xilskey_efuseps_zynqmp_input.h`

config/examples/nxp-t2080-68ppc2.config

@@ -32,7 +32,7 @@ WOLFBOOT_SECTOR_SIZE=0x10000
 
 # wolfBoot start address
 WOLFBOOT_ORIGIN=0xEFF40000
-# wolfBoot parition size (custom)
+# wolfBoot partition size (custom)
 BOOTLOADER_PARTITION_SIZE=0x20000
 
 # Application Partition Size

docs/PubkeySealing.md

@@ -3,7 +3,7 @@
 ## NOTE: Currently only ecc256 keys are supported for policy sealing
 
 The pubkey that wolfBoot uses to verify its images can be stored in the TPM and tied to the boot partition digest. The key will be set to only be unsealed if the image digest is untampered, and then when signature verification is done the untampered signature proves an untampered image.
-To use this feature you need to define `WOLFBOOT_TPM_KEYSTORE?=1` and set `WOLFBOOT_TPM_KEYSTORE_NV_INDEX` and `WOLFBOOT_TPM_POLICY_NV_INDEX` to the NVM indicies supported by your TPM. You can also override the default PCR index by defining `WOLFBOOT_TPM_PCR_INDEX`
+To use this feature you need to define `WOLFBOOT_TPM_KEYSTORE?=1` and set `WOLFBOOT_TPM_KEYSTORE_NV_INDEX` and `WOLFBOOT_TPM_POLICY_NV_INDEX` to the NVM indices supported by your TPM. You can also override the default PCR index by defining `WOLFBOOT_TPM_PCR_INDEX`
 Then you need to generate two keys, our policy signing key and the regular image verification key. We also need to sign a Policy Signed signature from aHash, a TPM2 element. This can be done automatically with the tools/preseal/keygen command:
 
 ```
@@ -35,7 +35,7 @@ Next you need to create the image using the sign keytool with the --manual-sign
 tools/keytools/sign --ecc256 --sha256 --manual-sign --policy-signed MY_IMAGE policy-public-key.raw 1 image-signature.raw policy-signed.raw
 ```
 
-Lastly, the pubkey needs to be sealed to the TPM. Note that the previous commands could be run from a seperate system, this one must be run on a system connected to the TPM:
+Lastly, the pubkey needs to be sealed to the TPM. Note that the previous commands could be run from a separate system, this one must be run on a system connected to the TPM:
 
 ```
 tools/preseal/preseal public-key.raw policy-public-key.raw policy-signed.raw test-app/image_v1_digest.bin 25166336 25166337 16

docs/Targets.md

@@ -743,7 +743,7 @@ The STM32H7 build can be built using:
 make TARGET=stm32h7 SIGN=ECC256
 ```
 
-The STM32H7 also supports using the QSPI for external flash. To enable use `QSPI_FLASH=1` in your configuration. The pins are defined in `hal/spi/spi_drv_stm32.h`. A built-in alternate pin configuration can be used with `QSPI_ALT_CONFIGURATION`. The flash and QSPI parameters are defined in `src/qspi_flash.c` and can be overrriden at build time.
+The STM32H7 also supports using the QSPI for external flash. To enable use `QSPI_FLASH=1` in your configuration. The pins are defined in `hal/spi/spi_drv_stm32.h`. A built-in alternate pin configuration can be used with `QSPI_ALT_CONFIGURATION`. The flash and QSPI parameters are defined in `src/qspi_flash.c` and can be overridden at build time.
 
 ### STM32H7 Programming
 
@@ -840,7 +840,7 @@ arm-none-eabi-gdb wolfboot.elf -ex "target remote localhost:3333"
 
 Tested using `https://github.com/raspberrypi/linux` on Ubuntu 20
 
-Prerequsites: `sudo apt install gcc-aarch64-linux-gnu qemu-system-aarch64`
+Prerequisites: `sudo apt install gcc-aarch64-linux-gnu qemu-system-aarch64`
 
 ### Compiling the kernel
 
@@ -1100,15 +1100,15 @@ Firmware can be directly uploaded to the target by copying `factory.bin` to the
 
 Supports K64 and K82 with crypto hardware acceleration.
 
-### Buld options
+### Build options
 
 See [/config/examples/kinetis-k82f.config](/config/examples/kinetis-k82f.config) for example configuration.
 
 The TARGET is `kinetis`. For LTC PKA support set `PKA=`.
 
 Set `MCUXPRESSO`, `MCUXPRESSO_CPU`, `MCUXPRESSO_DRIVERS` and `MCUXPRESSO_CMSIS` for MCUXpresso configuration.
 
-### Example partioning for K82
+### Example partitioning for K82
 
 ```
 WOLFBOOT_PARTITION_SIZE?=0x7A000
@@ -1256,7 +1256,7 @@ Flash Layout (with files):
 | ----------- | ---- | ------- |
 | Reset Configuration Word (RCW) | `68PPC2_RCW_v0p7.bin` | `0xE8000000` |
 | Frame Manager Microcode | `fsl_fman_ucode_t2080_r1.0.bin` | `0xE8020000` |
-| Signed Aplication | `test-app/image_v1_signed.bin` | `0xE8080000` |
+| Signed Application | `test-app/image_v1_signed.bin` | `0xE8080000` |
 | wolfBoot | `wolfboot.bin` | `0xEFF40000` |
 | Boot Entry Point (with offset jump to init code) |  | `0xEFFFFFFC` |
 
@@ -1509,7 +1509,7 @@ optionally an external flash. The build will produce an executable ELF file
 `wolfBoot.elf`. You can provide another executable ELF as firmware image and it
 will be executed. The command-line arguments of `wolfBoot.elf` are forwarded to
 the application. The example application `test-app\app_sim.c` uses the arguments
-to interact with `libwolfboot.c` and automatize functional testing.  You can
+to interact with `libwolfboot.c` and automate functional testing.  You can
 find an example configuration in `config/examples/sim.config`.
 
 An example of using the `test-app/sim.c` to test firmware update:
@@ -1537,7 +1537,7 @@ securely updated to v2. Both versions behave the same except displaying its vers
 They are compiled by e2Studio and running on the target board.
 
 In this demo, you may download two versions of application binary file by Renesas Flash Programmer.
-You can download and excute wolfBoot by e2Studio debugger. Use a USB connection between PC and the
+You can download and execute wolfBoot by e2Studio debugger. Use a USB connection between PC and the
 board for the debugger and flash programmer.
 
 Flash Allocation:
@@ -1567,7 +1567,7 @@ securely updated to v2. Both versions behave the same except displaying its vers
 They are compiled by e2Studio and running on the target board.
 
 In this demo, you may download two versions of application binary file by Renesas Flash Programmer.
-You can download and excute wolfBoot by e2Studio debugger. Use a USB connection between PC and the
+You can download and execute wolfBoot by e2Studio debugger. Use a USB connection between PC and the
 board for the debugger and flash programmer.
 
 Flash Allocation:

docs/compile.md

@@ -72,7 +72,7 @@ beginning of the external memory addressable space.
  - `WOLFBOOT_PARTITION_SWAP_ADDRESS`
 
 The address for the swap spaced used by wolfBoot to swap the two firmware images in place,
-in order to perform a reversable update. The size of the SWAP partition is exactly one sector on the flash.
+in order to perform a reversible update. The size of the SWAP partition is exactly one sector on the flash.
 If an external memory is used, the variable contains the offset of the SWAP area from the beginning
 of its addressable space.
 

docs/encrypted_partitions.md

@@ -13,7 +13,7 @@ Encryption of external partition works at the level of the external flash interf
 All write calls to external partitions from the bootloader perform an additional encryption step
 to hide the actual content of the external non-volatile memory.
 
-Viceversa, all read operations will decrypt the data stored when the feature is enabled.
+Vice-versa, all read operations will decrypt the data stored when the feature is enabled.
 
 An extra option is provided to the `sign.py` sign tool to encrypt the firmware update after signing it, so
 that it can be stored as is in the external memory by the application, and will be decrypted by the bootloader

docs/firmware_image.md

@@ -14,7 +14,7 @@ of 256B from the beginning of the flash partition.
 
 ## Firmware image header
 
-Each (signed) firmware image is pre-pended with a fixed-size **image header**, containing
+Each (signed) firmware image is prepended with a fixed-size **image header**, containing
 useful information about the firmware. The **image header** is padded to fit in 256B, in order
 to guarantee that the entry point of the actual firmware is stored on the flash starting from
 a 256-Bytes aligned address. This ensures that the bootloader can relocate the vector table before

docs/firmware_update.md

@@ -71,7 +71,7 @@ operates almost the same as firmware update with a few key
 differences. The header of the update is marked as a bootloader
 update (use `--wolfboot-update` for the sign tools).
 
-The new signed wolfBoot image is loaded into the UPDATE parition and
+The new signed wolfBoot image is loaded into the UPDATE partition and
 triggered the same as a firmware update. Instead of performing a swap,
 after the image is validated and signature verified, the bootloader is
 erased and the new image is written to flash. This operation is _not_

docs/measured_boot.md

@@ -15,16 +15,16 @@ during and after boot.
 
 ## Concept
 
-Typically, systems use Secure Boot to guarantee that the correct and geniune
+Typically, systems use Secure Boot to guarantee that the correct and genuine
 firmware is booted by verifying its signature. Afterwards, this knowledge is
-unknown to the sytem. The application does not know if the system started in
+unknown to the system. The application does not know if the system started in
 a good known state. Sometimes, this guarantee is needed by the firmware itself.
 To provide such mechanism the concept of Measured Boot exist.
 
 Measured Boot can be used to check every start-up component, including settings
 and user information(user partition). The result of the checks is then stored
 into special registers called PCR. This process is called PCR Extend and is
-refered to as a TPM measurement. PCR registers can be reset only on TPM power-on.
+referred to as a TPM measurement. PCR registers can be reset only on TPM power-on.
 
 Having TPM measurements provide a way for the firmware or Operating System(OS),
 like Windows or Linux, to know that the software loaded before it gained control
@@ -64,7 +64,7 @@ Any TPM has a minimum of 24 PCR registers. Their typical use is as follows:
 
 Recommendations for choosing a PCR index:
 
-- During development it is recommended to use PCR16 that is intented for testing.
+- During development it is recommended to use PCR16 that is intended for testing.
 - In production, if you are running a bare-metal firmware or RTOS, you could use
 almost all PCRs(PCR0-15), except the one for DRTM and Trusted OS(PCR17-23).
 - If you are running Linux or Windows, PCR12-15 can be chosen for production

hal/kinetis.c

@@ -257,7 +257,7 @@ void BOARD_BootClockHSRUN(void)
  * 1.set CLKDIV1 to safe divider value.
     * 2.set the PLL or FLL output target frequency for HSRUN mode.
     * 3.switch to HSRUN mode.
-    * 4.switch to HSRUN mode target requency value.
+    * 4.switch to HSRUN mode target frequency value.
     */
 
     /* Set the system clock dividers in SIM to safe value. */

hal/nxp_p1021.c

@@ -413,7 +413,7 @@ enum elbc_amask_sizes {
 #define ESPI_SPCOM_TRANLEN(x) (((x) - 1) << 0) /* Transaction length */
 
 #define ESPI_SPIE_DON        (1 << 14) /* Last character was transmitted */
-#define ESPI_SPIE_RNE        (1 << 9) /* recevie not empty */
+#define ESPI_SPIE_RNE        (1 << 9) /* receive not empty */
 #define ESPI_SPIE_TNF        (1 << 8) /* transmit not full */
 
 #define ESPI_CSMODE_CI       0x80000000 /* Inactive high */
@@ -965,7 +965,7 @@ static void config_io_pin(uint8_t port, uint8_t pin, int dir, int open_drain,
     uint32_t pin_2bit_mask, pin_2bit_dir, pin_2bit_assign;
     uint32_t pin_1bit_mask, tmp_val;
 
-    /* Caculate pin location and 2bit mask and dir */
+    /* Calculate pin location and 2bit mask and dir */
     pin_2bit_mask = (uint32_t)(0x3 << (NUM_OF_PINS -
         (pin % (NUM_OF_PINS / 2) + 1) * 2));
     pin_2bit_dir =  (uint32_t)(dir << (NUM_OF_PINS -
@@ -1459,7 +1459,7 @@ static int test_flash(void)
 #endif
 int test_tpm(void)
 {
-    /* Read 4 bytes at TIS addresss D40F00. Assumes 0 wait state on TPM */
+    /* Read 4 bytes at TIS address D40F00. Assumes 0 wait state on TPM */
     uint8_t tx[8] = {0x83, 0xD4, 0x0F, 0x00,
                      0x00, 0x00, 0x00, 0x00};
     uint8_t rx[8] = {0};

hal/renesas-ra.c

@@ -59,7 +59,7 @@ void hal_init(void)
     fsp_err_t err;
 
 #if defined(WOLFBOOT_RENESAS_SCEPROTECT) && !defined(WOLFBOOT_RENESAS_APP)
-    /* retrive installed pubkey from flash */
+    /* retrieve installed pubkey from flash */
     uint32_t *pubkey = keystore_get_buffer(0);
 #endif
     err = R_FLASH_HP_Close(&g_flash0_ctrl);

hal/spi/spi_drv_stm32.h

@@ -469,7 +469,7 @@
 #define OCTOSPI_CR_FMODE_MASK     (0x3 << 28)
 #define OCTOSPI_CR_FMODE(fmode)   (((fmode) & 0x3) << 28)  /* Functional Mode (0=indirect write, 1=indirect read, 2=auto poll, 3=mem mapped) */
 #define OCTOSPI_CR_FTIE           (1 << 18)                /* FIFO threshold interrupt enable */
-#define OCTOSPI_CR_TCIE           (1 << 17)                /* Transfer complete inerrupt enable */
+#define OCTOSPI_CR_TCIE           (1 << 17)                /* Transfer complete interrupt enable */
 #define OCTOSPI_CR_FTHRES_MASK    (0x1F << 8)
 #define OCTOSPI_CR_FTHRES(thr)    ((((thr)-1) & 0x1F) << 8) /* FIFO threshold level */
 #define OCTOSPI_CR_FSEL           (1 << 7)                 /* 0=Flash 1 or 1=Flash 2 */

hal/stm32u5.c

@@ -515,7 +515,7 @@ static void clock_pll_on(int powersave)
     PWR_VOSR &= ~( (PWR_VOSR_VOS_1 << PWR_VOSR_VOS_SHIFT) | PWR_VOSR_BOOSTEN );
     PWR_VOSR|= ((PWR_VOSR_VOS_1<< PWR_VOSR_VOS_SHIFT) | PWR_VOSR_BOOSTEN);
 
-    /* Wait until VOSRDY is rised */
+    /* Wait until VOSRDY is raised */
     reg32 = PWR_VOSR;
     while ((PWR_VOSR & PWR_VOSR_VOSRDY) == 0) {};
 

hal/stm32u5_ns.c

@@ -388,7 +388,7 @@ static void clock_pll_on(int powersave)
     PWR_VOSR &= ~( (PWR_VOSR_VOS_1 << PWR_VOSR_VOS_SHIFT) | PWR_VOSR_BOOSTEN );
     PWR_VOSR|= ((PWR_VOSR_VOS_1<< PWR_VOSR_VOS_SHIFT) | PWR_VOSR_BOOSTEN);
 
-    /* Wait until VOSRDY is rised */
+    /* Wait until VOSRDY is raised */
     reg32 = PWR_VOSR;
     while ((PWR_VOSR & PWR_VOSR_VOSRDY) == 0) {};