Documentation: Fix typos

I used codespell to find typos in the documentation. Signed-off-by: Alan C. Assis <[email protected]>
acassis · Oct 28, 2023 · 1a4a6fc · 1a4a6fc
1 parent 3fd3612
commit 1a4a6fc
Show file tree

Hide file tree

Showing 40 changed files with 62 additions and 63 deletions.
diff --git a/Documentation/applications/examples/mcuboot/index.rst b/Documentation/applications/examples/mcuboot/index.rst
@@ -8,7 +8,7 @@
 Description
 ~~~~~~~~~~~
 
-MCUboot Swap Image is an application to demostrate firmware upgrade using
+MCUboot Swap Image is an application to demonstrate firmware upgrade using
 internal flash memory. It simulate MCUboot API steps to switch between two
 valid images.
 
@@ -19,7 +19,7 @@ signed. Consult your board documentation page to get instructions how to do it.
 How to build and flash
 ......................
 
-First step is build your board configuraton using ``mcuboot-loader`` as target.
+First step is build your board configuration using ``mcuboot-loader`` as target.
 That create the bootloader itself. The ``nuttx.bin`` must be flash as usual.
 
 After that, clean up environment and set ``mcuboot-swap-test`` as target. The
@@ -73,7 +73,7 @@ step that must be executed if you ran ``imgtool.py`` without optional parameter
   Application Image successfully confirmed!
   nsh>
 
-Third step (let's reboot and see whats happen)::
+Third step (let's reboot and see what's happen)::
 
   nsh> reboot
   *** Booting MCUboot build 7c890f4b075aed73e4c825ccf875b2fb9ebf2ded ***
@@ -92,7 +92,7 @@ Fourth step (let's switch image)::
   Image version 2.0.0.0
   nsh>
 
-Now, we switched from image version 1.0.0 to image 2.0.0. However, we intentionaly
+Now, we switched from image version 1.0.0 to image 2.0.0. However, we intentionally
 will not run ``mcuboot_confirm`` app::
 
   nsh> reboot

diff --git a/Documentation/applications/examples/tcp_ipc_client/index.rst b/Documentation/applications/examples/tcp_ipc_client/index.rst
@@ -20,7 +20,7 @@ How do I use this?
 
 In order to test tcp_ipc_client & tcp_ipc_server together, there are two ways to proceed:
 
-- Init server manually (command: SERVER &), and after successfull server init, also init client manually (CLIENT 127.0.0.1)
+- Init server manually (command: SERVER &), and after successful server init, also init client manually (CLIENT 127.0.0.1)
 - init server automatically after boot using NuttShell start up scripts (check: https://nuttx.apache.org/docs/latest/applications/nsh/installation.html#nuttshell-start-up-scripts )
 
 Additional info

diff --git a/Documentation/applications/examples/tcp_ipc_server/index.rst b/Documentation/applications/examples/tcp_ipc_server/index.rst
@@ -22,7 +22,7 @@ How do I use this?
 
 In order to test client_tcp & server_tcp together, there are two ways to proceed:
 
-- Init server manually (command: SERVER &), and after successfull server init, also init client manually (CLIENT 127.0.0.1)
+- Init server manually (command: SERVER &), and after successful server init, also init client manually (CLIENT 127.0.0.1)
 - init server automatically after boot using NuttShell start up scripts (check: https://nuttx.apache.org/docs/latest/applications/nsh/installation.html#nuttshell-start-up-scripts )
 
 Additional info

diff --git a/Documentation/applications/games/brickmatch/index.rst b/Documentation/applications/games/brickmatch/index.rst
@@ -8,7 +8,7 @@ Crush. It is a 6x6 matrix with blocks (cells) with different colors.
 Your goal is to move the blocks of the board to unite three or
 more with the same color.
 
-Everytime that three of more blocks with the same color match that block
+Every time that three of more blocks with the same color match that block
 will blink and it will be removed from the board, leaving more space
 for movements.
 

diff --git a/Documentation/applications/netutils/iptables/index.rst b/Documentation/applications/netutils/iptables/index.rst
@@ -1,3 +1,3 @@
-============================
-``iptables`` iptables libary
-============================
+=============================
+``iptables`` iptables library
+=============================
diff --git a/Documentation/applications/nsh/commands.rst b/Documentation/applications/nsh/commands.rst
@@ -64,7 +64,7 @@ notation. In that case, the netmask need not be provided.
 
 ::
 
-  nsh> addroute addroute 11.0.0.0 255.255.255.0 10.0.0.2
+  nsh> addroute 11.0.0.0 255.255.255.0 10.0.0.2
 
 which is equivalent to
 

diff --git a/Documentation/applications/system/libuv/index.rst b/Documentation/applications/system/libuv/index.rst
@@ -4,7 +4,7 @@
 
 Most features of libuv are supported by current port, except SIGPROF relative function (loop_configure).
 
-Nearly full libuv's test suite avaliable on NuttX, but some known case can't run on sim:
+Nearly full libuv's test suite available on NuttX, but some known case can't run on sim:
 
 * ``loop_update_time``
 * ``idle_starvation``

diff --git a/Documentation/applications/system/ymodem/index.rst b/Documentation/applications/system/ymodem/index.rst
@@ -2,7 +2,7 @@
 ``ymodem`` YMODEM
 =================
 
-This is `ymodem protocal <http://pauillac.inria.fr/~doligez/zmodem/ymodem.txt>`_.
+This is `ymodem protocol <http://pauillac.inria.fr/~doligez/zmodem/ymodem.txt>`_.
 According to it, the sb rb application is realized, which is used to send files and receive files respectively
 
 Usage
@@ -25,8 +25,7 @@ and you need ``sbrb.py`` -k to set the same length as the board. According to my
 when using -k 32, it can reach 93% of the baud rate,
 and is fully compatible with the original ymodem protocol.
 First, you need to add a soft link to sbrb.py, for example ``sudo ln -s /home/<name>/.../<nuttxwork>/apps/system/ymodem/sbrb.py /usr/bin``
-and then sbrb.py can be configured into minicom.``<Ctrl + a> z o`` then chose ``File transfer protocols`` and
-crate two option cmd is 'sbrb.py -k 32'. like this
+and then sbrb.py can be configured into minicom.``<Ctrl + a> z o`` then chose ``File transfer protocols`` and create two option cmd is 'sbrb.py -k 32'. like this
 
 =========== ============= ==== === ======= ======= =====
 Name        Program       Name U/D FullScr IO-Red. Multi

diff --git a/Documentation/components/drivers/index.rst b/Documentation/components/drivers/index.rst
@@ -185,7 +185,7 @@ Subdirectories of ``nuttx/drivers``
 
 * ``power/`` :doc:`special/power/index`
 
-  Various drivers related to power managament.
+  Various drivers related to power management.
 
 * ``rc/`` :doc:`character/rc`
 

diff --git a/Documentation/components/filesystem/partition.rst b/Documentation/components/filesystem/partition.rst
@@ -14,7 +14,7 @@ TXTABLE - A text based partition table stored in last eraseblock
 #. The 2nd and remaining lines are partition entries(min: one)
    in format: "%s %zx %zx"(means name, size and offset (byte)(in hex)).
 #. Size or offset can be default zero(means zero(for 1st entry) or
-   caculate(for others)), and will be caculated by the parser refs to previous
+   calculated(for others)), and will be calculated by the parser refs to previous
    and next entries.
 #. The last eraseblock will be registered as pseudo partition named "txtable".
    If the last eraseblock included by the last real partition, it will be
@@ -26,7 +26,7 @@ partition table maybe out of sync.
 And it's easier:
 
 1. Text format with simple rules(name + size + offset).
-#. Size or offset can be default(caculated refs to previous
+#. Size or offset can be default(calculated refs to previous
    and next entries).
 #. Support backup table(eg. /etc/txtable.txt in ROMFS)
 
@@ -99,7 +99,7 @@ More than one not set size or offset
 
 * Parsed
 
-  | Size of partition[2,3,4,6] and data are caculated, and gap between
+  | Size of partition[2,3,4,6] and data are calculated, and gap between
     partition7 and data is kept.
 
   ::

diff --git a/Documentation/guides/coredump.rst b/Documentation/guides/coredump.rst
@@ -29,7 +29,7 @@ Enable Kconfig
       CONFIG_BOARD_COREDUMP_COMPRESSION=y /* Default y, enable Coredump compression to
                                              reduce the size of the original core image */
 
-      CONFIG_BOARD_COREDUMP_FULL=y        /* Default y, save all task informations */
+      CONFIG_BOARD_COREDUMP_FULL=y        /* Default y, save all task information */
 
 2. Run Coredump on nsh (CONFIG_SYSTEM_COREDUMP=y)
 

diff --git a/Documentation/guides/gdbwithpython.rst b/Documentation/guides/gdbwithpython.rst
@@ -23,5 +23,5 @@ How to write a GDB python script
 Here is an article to introduce, read it to understand the most basic principles of python,
 `Automate Debugging with GDB Python API <https://interrupt.memfault.com/blog/automate-debugging-with-gdb-python-api>`_.
 
-For more documentation on gdb pyhton, please refer to the official documentation of gdb
-`GDB with pyhton <https://interrupt.memfault.com/blog/automate-debugging-with-gdb-python-api>`_.
+For more documentation on gdb python, please refer to the official documentation of gdb
+`GDB with python <https://interrupt.memfault.com/blog/automate-debugging-with-gdb-python-api>`_.
diff --git a/Documentation/guides/nestedinterrupts.rst b/Documentation/guides/nestedinterrupts.rst
@@ -78,7 +78,7 @@ nested interrupt handling. Here is one technical approach to do that:
    atomic in any case.
 
 **NOTE 1**: The ARMv7-M could also be configured to use separate MSP and
-PSP stacks with the interupt processing using the MSP stack and the
+PSP stacks with the interrupt processing using the MSP stack and the
 tasks all using the PSP stacks. This is not compatible with certain
 parts of the existing design and would be more effort, but could result
 in a better solution.
@@ -140,7 +140,7 @@ assume that interrupts are enabled.
    
     /* Current regs non-zero indicates that we are processing an interrupt;
      * regs holds the state of the interrupted logic; current_regs holds the
-     * state of the interrupted user task.  current_regs should, therefor,
+     * state of the interrupted user task.  current_regs should, therefore,
      * only be modified for outermost interrupt handler (when g_nestlevel == 0)
      */
    

diff --git a/Documentation/guides/ofloader.rst b/Documentation/guides/ofloader.rst
@@ -21,7 +21,7 @@ CONFIGURATION
 ```CONFIG_DISABLE_IDLE_LOOP`` is used to disable the idle loop in NuttX.
 ```CONFIG_SYSTEM_OFLOADER``` is used to enable the Open Flash Loader.
 ```CONFIG_SYSTEM_OFLOADER_TABLE``` is used to configure the flash device
-frist parameter is the device name, second parameter is the start address.
+first parameter is the device name, second parameter is the start address.
 
 The reference configuration "stm32f429i-disco:ofloader" is designed
 to be used with the STM32F429I-DISCO board in NuttX,

diff --git a/Documentation/guides/rndis.rst b/Documentation/guides/rndis.rst
@@ -105,7 +105,7 @@ Setup RNDIS in your computer
 
    Click on "Apply"
 
-   Disconect and connect the USB cable to force it to get IP.
+   Disconnect and connect the USB cable to force it to get IP.
 
 #. Identify what IP address your board got:
 

diff --git a/Documentation/platforms/arm/imxrt/index.rst b/Documentation/platforms/arm/imxrt/index.rst
@@ -87,9 +87,9 @@ ADC
 ADC driver with the successive approximation analog/digital converter. The lower-half of
 this driver is initialize by calling :c:func:`imxrt_adcinitialize`.
 
-ADC module can use either continous trigger (next conversion is started as soon as the
+ADC module can use either continuous trigger (next conversion is started as soon as the
 previous is finished) or hardware trigger. This option is selected by IMXRT_ADCx_ETC
-(x = 1, 2) config option. If IMXRT_ADCx_ETC = -1 then continous trigger is used. If
+(x = 1, 2) config option. If IMXRT_ADCx_ETC = -1 then continuous trigger is used. If
 corresponding XBAR number is put in IMXRT_ADCx_ETC then that signal is used to trigger
 the ADC conversion (for example PWM signal can be used as a source). For PWM XBAR options
 please refer to PWM chapter of this documentation.

diff --git a/Documentation/platforms/arm/nrf52/boards/nrf52840-dk/index.rst b/Documentation/platforms/arm/nrf52/boards/nrf52840-dk/index.rst
@@ -83,7 +83,7 @@ NuttShell configuration with support for CDC/ACM with RNDIS composite driver.
 highpri
 -------
 
-This application demonstrates high priorty interrupt feature of the NuttX.
+This application demonstrates high priority interrupt feature of the NuttX.
 
 nsh
 ----

diff --git a/Documentation/platforms/arm/nrf52/boards/nrf52840-dongle/index.rst b/Documentation/platforms/arm/nrf52/boards/nrf52840-dongle/index.rst
@@ -3,7 +3,7 @@ nRF52840-dongle
 ===============
 
 The `nRF52840-dongle (PCA10059) <https://www.nordicsemi.com/Products/Development-hardware/nrf52840-dongle>`_
-is a a small, low-cost USB dongle based on nRF52840 fron Nordic.
+is a a small, low-cost USB dongle based on nRF52840 from Nordic.
 
 Serial Console
 ==============
@@ -59,5 +59,5 @@ Basic NuttShell configuration (CDCACM console enabled in USB Port, at 115200 bps
 Flash & Debug
 =============
 
-Both flashing and debuing is possible only with an external debug proble.
+Both flashing and debuing is possible only with an external debug probe.
 
diff --git a/Documentation/platforms/arm/nrf52/boards/thingy52/index.rst b/Documentation/platforms/arm/nrf52/boards/thingy52/index.rst
@@ -68,4 +68,4 @@ Basic NuttShell configuration (console enabled on Segger RTT channel).
 Flash & Debug
 =============
 
-Both flashing and debuing is possible only with an external debug proble.
+Both flashing and debuing is possible only with an external debug probe.
diff --git a/Documentation/platforms/arm/nrf53/boards/thingy53/index.rst b/Documentation/platforms/arm/nrf53/boards/thingy53/index.rst
@@ -79,4 +79,4 @@ exposed via J-Link VCOM1, at 115200 bps).
 Flash & Debug
 =============
 
-Both flashing and debuing is possible only with an external debug proble.
+Both flashing and debuing is possible only with an external debug probe.
diff --git a/Documentation/platforms/arm/nrf91/boards/thingy91/index.rst b/Documentation/platforms/arm/nrf91/boards/thingy91/index.rst
@@ -42,4 +42,4 @@ TODO
 Flash & Debug
 =============
 
-Both flashing and debuing is possible only with an external debug proble.
+Both flashing and debuing is possible only with an external debug probe.
diff --git a/Documentation/platforms/arm/rp2040/boards/adafruit-feather-rp2040/index.rst b/Documentation/platforms/arm/rp2040/boards/adafruit-feather-rp2040/index.rst
@@ -47,7 +47,7 @@ connected LiPo cell.
 There is a BOOT button which if held down when power is first
 applied or the RESET button is pressed will cause the RP2040 to
 boot into program mode and appear as a storage device to
-a USB connecte .  Saving a .UF2 file to this device will 
+a USB connector.  Saving a .UF2 file to this device will 
 replace the Flash ROM contents on the RP2040.
 
 A RESET button that allows rebooting the board without disconnecting

diff --git a/Documentation/platforms/arm/rp2040/boards/adafruit-kb2040/index.rst b/Documentation/platforms/arm/rp2040/boards/adafruit-kb2040/index.rst
@@ -40,7 +40,7 @@ Buttons and LEDs
 There is a BOOT button which if held down when power is first
 applied or the RESET button is pressed will cause the RP2040 to
 boot into program mode and appear as a storage device to
-a USB connecte .  Saving a .UF2 file to this device will 
+a USB connector.  Saving a .UF2 file to this device will 
 replace the Flash ROM contents on the RP2040.
 
 A RESET button that allows rebooting the board without disconnecting

diff --git a/Documentation/platforms/arm/s32k1xx/boards/rddrone-bms772/index.rst b/Documentation/platforms/arm/s32k1xx/boards/rddrone-bms772/index.rst
@@ -2,7 +2,7 @@
 NXP RDDRONE-BMS772
 ==================
 
-`NXP RDDRONE-BMS772 <https://www.nxp.com/design/designs/smart-battery-management-for-mobile-robotics:RDDRONE-BMS772>`_ is a Battery Management System (BMS) reference design for mobile robotics, such as drones and rovers. Design files are available on the NXP website and may be used to develop your own BMS. RDDRONE-BMS772 is configurable and supports batteries of 3 to 6 cells, which it can monitor individually. The board features the `NXP S32K144 <https://www.nxp.com/products/processors-and-microcontrollers/s32-automotive-platform/s32k-general-purpose-mcus/s32k1-microcontrollers-for-general-purpose:S32K1>`_ MCU, which can monitor the `NXP MC33772B <https://www.nxp.com/products/power-management/battery-management/battery-cell-controllers/6-channel-li-ion-battery-cell-controller-ic:MC33772B>`_ Battery Cell Controller (BCC) and may commmunicates with the Vehicle Management Unit (VMU). When faults are detected the battery output can be disconnected to prevent further damage. Status information may be communicated over I2C/SMBus, CAN or NFC.
+`NXP RDDRONE-BMS772 <https://www.nxp.com/design/designs/smart-battery-management-for-mobile-robotics:RDDRONE-BMS772>`_ is a Battery Management System (BMS) reference design for mobile robotics, such as drones and rovers. Design files are available on the NXP website and may be used to develop your own BMS. RDDRONE-BMS772 is configurable and supports batteries of 3 to 6 cells, which it can monitor individually. The board features the `NXP S32K144 <https://www.nxp.com/products/processors-and-microcontrollers/s32-automotive-platform/s32k-general-purpose-mcus/s32k1-microcontrollers-for-general-purpose:S32K1>`_ MCU, which can monitor the `NXP MC33772B <https://www.nxp.com/products/power-management/battery-management/battery-cell-controllers/6-channel-li-ion-battery-cell-controller-ic:MC33772B>`_ Battery Cell Controller (BCC) and may communicates with the Vehicle Management Unit (VMU). When faults are detected the battery output can be disconnected to prevent further damage. Status information may be communicated over I2C/SMBus, CAN or NFC.
 
 NuttX contains basic board support RDDRONE-BMS772, which allows the S32K144 MCU to be initialized. A NuttX-compatible smart battery application for RDDRONE-BMS772 is also available. It contains additional drivers and example software to use most features of the battery management system. This application is currently published in a `separate repository <https://github.com/NXPHoverGames/RDDRONE-BMS772>`_, but (parts) may eventually be upstreamed to Apache NuttX.
 

diff --git a/Documentation/platforms/arm/s32k1xx/index.rst b/Documentation/platforms/arm/s32k1xx/index.rst
@@ -36,7 +36,7 @@ Peripheral  Support  Comments
 ADC         No
 CMP         No
 eDMA        No
-EEEPROM     Yes      EEPROM emulated by FlexRAM
+EEPROM     Yes      EEPROM emulated by FlexRAM
 ENET        Yes
 FlexCAN     Yes      SocketCAN-compatible
 FlexIO      No
@@ -66,7 +66,7 @@ eDMA
 
 Enhanced Direct Memory Access module. There is a driver that was copied from the i.MX RT port, but this was not tested on S32K1XX.
 
-EEEPROM
+EEPROM
 -------
 
 Emulated EEPROM (implemented by FlexRAM module). A basic block driver is available to read and write data.

diff --git a/Documentation/platforms/arm/s32k3xx/index.rst b/Documentation/platforms/arm/s32k3xx/index.rst
@@ -2,7 +2,7 @@
 NXP S32K3XX
 ===========
 
-The `S32K3XX series <https://www.nxp.com/products/processors-and-microcontrollers/s32-automotive-platform/s32k-general-purpose-mcus/s32k3-microcontrollers-for-general-purpose:S32K3>`_ is a family of automotive-grade general-purpose microcontrollers from NXP Semiconductors. The chips are based around single, dual (lock-step) or tripple Arm Cortex-M7 cores, running at clockspeeds up to 240 MHz.
+The `S32K3XX series <https://www.nxp.com/products/processors-and-microcontrollers/s32-automotive-platform/s32k-general-purpose-mcus/s32k3-microcontrollers-for-general-purpose:S32K3>`_ is a family of automotive-grade general-purpose microcontrollers from NXP Semiconductors. The chips are based around single, dual (lock-step) or triple Arm Cortex-M7 cores, running at clockspeeds up to 240 MHz.
 
 Supported MCUs
 ==============

diff --git a/Documentation/platforms/arm/stm32f1/boards/et-stm32-stamp/index.rst b/Documentation/platforms/arm/stm32f1/boards/et-stm32-stamp/index.rst
@@ -10,7 +10,7 @@ ET-STM32 Stamp board from Futurlec (https://www.futurlec.com/ET-STM32_Stamp.shtm
 - I/O Pins Out: 48
 - ADCs: 16 (at 12-bit resolution)
 - DACs: 2 (at 12-bit resolution)
-- Peripherals: RTC, 4 timers, 2 I2Cs, 3 SPI ports, 1 on-board UART (upto 5 channels)
+- Peripherals: RTC, 4 timers, 2 I2Cs, 3 SPI ports, 1 on-board UART (up to 5 channels)
 - Other: Sleep, stop, and standby modes; serial wire debug and JTAG interfaces
 
 Please see link below for board specific details:

diff --git a/Documentation/platforms/arm/stm32f4/boards/stm32f4discovery/index.rst b/Documentation/platforms/arm/stm32f4/boards/stm32f4discovery/index.rst
@@ -1164,7 +1164,7 @@ hciuart
 
 This configuration was used for test the HCI UART driver.  The HCI UART
 is enabled on USART3 as well as the test application at
-apps/wireless/bluetoot/btsak.
+apps/wireless/bluetooth/btsak.
 
 NOTES:
 
@@ -2177,6 +2177,6 @@ NOTES:
    The MSYS tools are probably also a option but are likely lower performance
    since they are based on Cygwin 1.3.
 
-   Host Compiler:  I use the MingGW compiler which can be downloaded from
+   Host Compiler:  I use the MingW compiler which can be downloaded from
    http://www.mingw.org/.  If you are using GNUWin32, then it is recommended
    the you not install the optional MSYS components as there may be conflicts.
diff --git a/Documentation/platforms/arm/stm32h7/boards/nucleo-h745zi/index.rst b/Documentation/platforms/arm/stm32h7/boards/nucleo-h745zi/index.rst
@@ -27,7 +27,7 @@ SERIAL_RX         PD9
 SERIAL_TX         PD8
 ================= ===
 
-Access to the Cortex-M4 core can be acheived using an additional UART port
+Access to the Cortex-M4 core can be achieved using an additional UART port
 or via RPMSG UART by setting ``CONFIG_RPMSG_UART_CONSOLE=y`` in CM4 configuration.
 
 If the RPMSG UART console is enabled, we can connect to it from CM7 using ``cu``::

diff --git a/Documentation/platforms/arm/stm32h7/index.rst b/Documentation/platforms/arm/stm32h7/index.rst
@@ -120,7 +120,7 @@ Interprocessor communication between cores is realized with the NuttX RPTUN
 device based on the OpenAMP framework. ``HSEM`` is used for synchronization and
 notification between cores.
 
-32kB of the SRAM3 is reseved for shared memory and this is the only available
+32kB of the SRAM3 is reserved for shared memory and this is the only available
 option at the moment.
 
 Supported Boards

diff --git a/Documentation/platforms/arm/stm32l5/boards/stm32l562e-dk/index.rst b/Documentation/platforms/arm/stm32l5/boards/stm32l562e-dk/index.rst
@@ -140,7 +140,7 @@ though.  Thus, this change::
      return TFM_PLAT_ERR_SUCCESS;
    }
 
-The third chage is required, since current NuttX does not support lazy FPU
+The third change is required, since current NuttX does not support lazy FPU
 register stacking any longer.  Thus, this must be disabled for the TF-M secure
 code as well::
 

diff --git a/Documentation/platforms/risc-v/esp32c3/boards/esp32c3-devkit/index.rst b/Documentation/platforms/risc-v/esp32c3/boards/esp32c3-devkit/index.rst
@@ -179,8 +179,8 @@ the ``/dev/crypto`` device file.
 cxx
 ---
 
-Development enviroment ready for C++ applications. You can check if the setup
-was successfull by running ``cxxtest``::
+Development environment ready for C++ applications. You can check if the setup
+was successful by running ``cxxtest``::
 
     nsh> cxxtest
     Test ofstream ================================

diff --git a/Documentation/platforms/sim/sim/boards/sim/index.rst b/Documentation/platforms/sim/sim/boards/sim/index.rst
@@ -1635,7 +1635,7 @@ This is a configuration with sim usbdev support.
 
   Make Raw Gadget:
   Run make in the raw_gadget and dummy_hcd directory. If raw_gadget build
-  fail, you need to check which register interface meets your kenel version,
+  fail, you need to check which register interface meets your kernel version,
   usb_gadget_probe_driver or usb_gadget_register_driver.
 
   Install Raw Gadget:
-Original file line number
+Diff line change
@@ Expand Up / @@ -64,7 +64,7 @@ notation. In that case, the netmask need not be provided. @@
     ::
-      nsh> addroute addroute 11.0.0.0 255.255.255.0 10.0.0.2
+      nsh> addroute 11.0.0.0 255.255.255.0 10.0.0.2
     which is equivalent to
@@ Expand Down @@