Fix a few typos (raspberrypi#697)

* Fix a few typos

* One additional typo

* copy edits

Author: HairyFotr

configuration/cmdline-txt.md

@@ -15,10 +15,10 @@ There are many kernel command line parameters, some of which are defined by the
  - console: defines the serial console. There are usually two entries:
      - `console=serial0,115200`
      - `console=tty1`
- - root: defines the location of the root filesystem, e.g. `root=/dev/mmcblk0p2` means multmedia card block 0 partition 2.
+ - root: defines the location of the root filesystem, e.g. `root=/dev/mmcblk0p2` means multimedia card block 0 partition 2.
  - rootfstype: defines what type of filesystem the rootfs uses, e.g. `rootfstype=ext4`
  - elevator: specifies the I/O scheduler to use. `elevator=deadline` means the kernel imposes a deadline on all I/O operations to prevent request starvation.
- - quiet: sets the default kernel log level to `KERN_WARNING`, which supresses all but very serious log messages during boot.
+ - quiet: sets the default kernel log level to `KERN_WARNING`, which suppresses all but very serious log messages during boot.
 
 
 #### Other Entries (not exhaustive)

configuration/config-txt/boot.md

@@ -31,7 +31,7 @@ Set the `disable_commandline_tags` command to `1` to stop `start.elf` from filli
 
 ### kernel
 
-`kernel` is the alternative filename on the boot partition to use when loading the kernel. The default value on the Pi 1, Pi Zero, and Compute Module is is `kernel.img`, and on the Pi 2, Pi 3, and Compute Module 3 it is `kernel7.img`. If `kernel8.img` is present on the Pi 3 or Compute Module 3, it will be loaded in preference and entered in 64-bit mode.
+`kernel` is the alternative filename on the boot partition to use when loading the kernel. The default value on the Pi 1, Pi Zero, and Compute Module is `kernel.img`, and on the Pi 2, Pi 3, and Compute Module 3 it is `kernel7.img`. If `kernel8.img` is present on the Pi 3 or Compute Module 3, it will be loaded in preference and entered in 64-bit mode.
 
 ### kernel_address
 

configuration/config-txt/overclocking.md

@@ -51,7 +51,7 @@ By default (`force_turbo=0`) the "On Demand" CPU frequency driver will raise clo
 
 #### never_over_voltage
 
-Sets a bit in the OTP memory (one time programmable) that prevents the device from being overvoltaged. This is intended to lock the device down so the the warranty bit cannot be set either inadvertently or maliciously by using an invalid overvoltage.
+Sets a bit in the OTP memory (one time programmable) that prevents the device from being overvoltaged. This is intended to lock the device down so the warranty bit cannot be set either inadvertently or maliciously by using an invalid overvoltage.
 
 #### disable_auto_turbo
 

configuration/config-txt/video.md

@@ -80,7 +80,7 @@ Setting `hdmi_ignore_cec` to `1` pretends that [CEC](https://en.wikipedia.org/wi
 
 #### cec_osd_name
 
-The `cec_osd_name` command sets the intial CEC name of the device. The default is Raspberry Pi.
+The `cec_osd_name` command sets the initial CEC name of the device. The default is Raspberry Pi.
 
 #### hdmi_pixel_encoding
 

configuration/device-tree.md

@@ -123,7 +123,7 @@ string-list = "red fish", "blue fish";
 
 The `/include/` directive results in simple textual inclusion, much like C's `#include` directive, but a feature of the Device Tree compiler leads to different usage patterns. Given that nodes are named, potentially with absolute paths, it is possible for the same node to appear twice in a DTS file (and its inclusions). When this happens, the nodes and properties are combined, interleaving and overwriting properties as required (later values override earlier ones).
 
-In the example above, the second appearanace of `/node2` causes a new property to be added to the original:
+In the example above, the second appearance of `/node2` causes a new property to be added to the original:
 
 ```
 /node2 {
@@ -686,7 +686,7 @@ dtc -I fs -O dtb -o base.dtb /proc/device-tree
 ```
 This will include any overlays and parameters you have applied so far, either in `config.txt` or by loading them at runtime, which may or may not be what you want. Alternatively...
 
-b) copy it from the source DTBs in /boot. This won't include overlays and parameters, but it also won't include any other modifications by the firmware. To allow testing of all overlays, the `dtmerge` utility will create some of the the board-specific aliases ("i2c_arm", etc.), but this means that the result of a merge will include more differences from the original DTB than you might expect. The solution to this is to use dtmerge to make the copy:
+b) copy it from the source DTBs in /boot. This won't include overlays and parameters, but it also won't include any other modifications by the firmware. To allow testing of all overlays, the `dtmerge` utility will create some of the board-specific aliases ("i2c_arm", etc.), but this means that the result of a merge will include more differences from the original DTB than you might expect. The solution to this is to use dtmerge to make the copy:
 
 ```
 dtmerge /boot/bcm2710-rpi-3-b.dtb base.dtb -

configuration/security.md

@@ -208,7 +208,7 @@ You can specify the service even if you do not know which port it uses. This exa
 sudo ufw allow ssh
 ```
 
-The status commmand lists all current settings for the firewall:
+The status command lists all current settings for the firewall:
 
 ```
 sudo ufw status
@@ -222,7 +222,7 @@ Limit login attempts on ssh port using tcp: this denies connection if an IP addr
 sudo ufw limit ssh/tcp
 ```
 
-Deny access to port 30 from IP adress 192.168.2.1
+Deny access to port 30 from IP address 192.168.2.1
 
 ```
 sudo ufw deny from 192.168.2.1 port 30

configuration/uart.md

@@ -4,11 +4,11 @@ The SoCs used on the Raspberry Pis have two built-in UARTs, a [PL011](http://inf
 
 By default, on Raspberry Pis equipped with the wireless/Bluetooth module (Raspberry Pi 3 and Raspberry Pi Zero W), the PL011 UART is connected to the BT module, while the mini UART is used for Linux console output. On all other models the PL011 is used for the Linux console output. 
 
-In Linux device terms, by default, /dev/ttyS0 refers to to the mini UART, and /dev/ttyAMA0 refers to the PL011. The primary UART is that assigned to the Linux console, which depends on the Raspberry Pi model as described above, and can be accessed via /dev/serial0.
+In Linux device terms, by default, /dev/ttyS0 refers to the mini UART, and /dev/ttyAMA0 refers to the PL011. The primary UART is that assigned to the Linux console, which depends on the Raspberry Pi model as described above, and can be accessed via /dev/serial0.
 
 ## Mini UART and CPU core frequency
 
-The baud rate of the mini UART is linked to the core frequency of the VPU on the VC4 GPU. This means that as the VPU frequency governor varies the core frequency, the baud rate of the UART also changes. This makes the UART of limited use in the default state. Also, when the linux console uses the mini UART (Raspberry Pi 3, Raspberry Pi Zero W), as a consequence of the UART being disabled, the console is also disabled.
+The baud rate of the mini UART is linked to the core frequency of the VPU on the VC4 GPU. This means that as the VPU frequency governor varies the core frequency, the baud rate of the UART also changes. This makes the UART of limited use in the default state. Also, when the Linux console uses the mini UART (Raspberry Pi 3, Raspberry Pi Zero W), as a consequence of the UART being disabled, the console is also disabled.
 
 The Linux console can be re-enabled by adding `enable_uart=1` to config.txt. This also fixes the core_freq to 250Mhz (unless force_turbo is set, when it will fixed to 400Mhz), which means that the UART baud rate stays consistent. 
 

configuration/wireless/access-point.md

@@ -138,7 +138,7 @@ By this point, the Raspberry Pi is acting as an access point, and other devices
 <a name="internet-sharing"></a>
 ## Using the Raspberry Pi as an access point to share an internet connection
 
-One common use of the Raspberry Pi as an access point is to provide wireless conections to a wired Ethernet connection, so that anyone logged into the access point can access the internet, providing of course that the wired Ethernet on the Pi can connect to the internet via some sort of router.
+One common use of the Raspberry Pi as an access point is to provide wireless connections to a wired Ethernet connection, so that anyone logged into the access point can access the internet, providing of course that the wired Ethernet on the Pi can connect to the internet via some sort of router.
 
 To do this, a 'bridge' needs to put in place between the wireless device and the Ethernet device on the access point Raspberry Pi. This bridge will pass all traffic between the two interfaces. Install the following packages to enable the access point setup and bridging.
 

hardware/computemodule/cm-peri-sw-guide.md

@@ -85,7 +85,7 @@ Note that `dt-blob.bin` is in compiled device tree format, but is only read by t
 A guide to creating dt-blob.bin is [here](../../configuration/pin-configuration.md).
 A comprehensive guide to the Linux Device Tree for Raspberry Pi is [here](../../configuration/device-tree.md).
 
-During boot, the user can specify a specific ARM device tree to use via the `device_tree` parameter in `config.txt`, for example adding the line `device_tree=mydt.dtb` to `config.txt` where `mydt.dtb` is the dtb file to load instead of one of the standard ARM dtb files. While a user can create a full device tree for his or her Compute Module product, the recommended way to add hardware is to use overlays (see next section).
+During boot, the user can specify a specific ARM device tree to use via the `device_tree` parameter in `config.txt`, for example adding the line `device_tree=mydt.dtb` to `config.txt` where `mydt.dtb` is the dtb file to load instead of one of the standard ARM dtb files. While a user can create a full device tree for their Compute Module product, the recommended way to add hardware is to use overlays (see next section).
 
 In addition to loading an ARM dtb, `start.elf` supports loading additional Device Tree 'overlays' via the `dtoverlay` parameter in `config.txt`, for example adding as many `dtoverlay=myoverlay` lines as required as overlays to `config.txt`, noting that overlays live in `/overlays` and are suffixed `-overlay.dtb` e.g. `/overlays/myoverlay-overlay.dtb`. Overlays are merged with the base dtb file before the data is passed to the Linux kernel when it starts.
 

hardware/display/README.md

@@ -26,7 +26,7 @@ NB: With the display connected to the GPIO I2C pins, the GPU will assume control
 
 ## Screen Orientation
 
-LCD displays have an optimum viewing angle, and depending on how the screen is mounted it may be necessary to change the orientation of the display to give the best results. By default, the Raspbery Pi display and Raspberry Pi are set up to work best when viewed from slightly above, for example on a desktop. If viewing from below, you can physically rotate the display, and then tell the system software to compensate by running the screen upside down.
+LCD displays have an optimum viewing angle, and depending on how the screen is mounted it may be necessary to change the orientation of the display to give the best results. By default, the Raspberry Pi display and Raspberry Pi are set up to work best when viewed from slightly above, for example on a desktop. If viewing from below, you can physically rotate the display, and then tell the system software to compensate by running the screen upside down.
 
 To flip the display, add, anywhere in the file `\boot\config.txt`, the following line:
 

hardware/raspberrypi/bootmodes/msd.md

@@ -34,7 +34,7 @@ Ensure the output `0x3020000a` is shown. If it is not, then the OTP bit has not
 If you wish, you can remove the `program_usb_boot_mode` line from config.txt, so that if you put the SD card in another Raspberry Pi, it won't program USB boot mode. Make sure there is no blank line at the end of config.txt. You can edit config.txt using the nano editor using the command `sudo nano /boot/config.txt`, for example.
 
 ## Prepare the USB mass storage device
-Starting with the 2017-04-10 release of Raspbian you can install a working Rasbian system to a USB mass storage device by copying the operating system image directly onto your USB device, in the same way that you would for an SD card. To perform this step, follow the instructions [here](../../../installation/installing-images/README.md), remembering to select the drive that corresponds to your USB mass storage device.
+Starting with the 2017-04-10 release of Raspbian you can install a working Raspbian system to a USB mass storage device by copying the operating system image directly onto your USB device, in the same way that you would for an SD card. To perform this step, follow the instructions [here](../../../installation/installing-images/README.md), remembering to select the drive that corresponds to your USB mass storage device.
 
 Once you have finished imaging your USB mass storage device, remove it from your computer and insert it into your Raspberry Pi 3.
 

hardware/raspberrypi/dpi/README.md

@@ -6,7 +6,7 @@ This interface is controlled by the GPU firmware and can be programmed by a user
 
 ## GPIO Pins
 
-One of the alternate functions selectable on bank 0 of the Raspbery Pi GPIO is DPI (Display Parallel Interface) which is a simple clocked parallel interface (up to 8 bits of R, G and B; clock, enable, hsync, and vsync). This interface is available as alternate function 2 (ALT2) on GPIO bank 0:
+One of the alternate functions selectable on bank 0 of the Raspberry Pi GPIO is DPI (Display Parallel Interface) which is a simple clocked parallel interface (up to 8 bits of R, G and B; clock, enable, hsync, and vsync). This interface is available as alternate function 2 (ALT2) on GPIO bank 0:
 
 ![DPI Alternate GPIO function](dpi-altfn2.png)
 

linux/filesystem/backup.md

@@ -61,13 +61,13 @@ sudo dd bs=4M if=raspbian.img of=/dev/sdb
 These files can be very large, and compress well. To compress, you can pipe the output of `dd` to `gzip` to get a compressed file that is significantly smaller than the original size:
 
 ```bash
-sudo dd bs=4M if=/dev/sdb | gzip > rasbian.img.gz
+sudo dd bs=4M if=/dev/sdb | gzip > raspbian.img.gz
 ```
 
 To restore, pipe the output of `gunzip` to `dd`:
 
 ```bash
-gunzip --stdout rasbian.img.gz | sudo dd bs=4M of=/dev/sdb
+gunzip --stdout raspbian.img.gz | sudo dd bs=4M of=/dev/sdb
 ```
 
 If you are using a Mac, the commands used are almost exactly the same, but `4M` in the above examples should be replaced with `4m`, with a lower case letter.

linux/usage/bashrc.md

@@ -28,7 +28,7 @@ More variations of `ls` are also provided:
 #alias l='ls -CF'
 ```
 
-Ubuntu users may be familar with these as they are provided by default on that distribution. Uncomment these lines to have access to these aliases in future.
+Ubuntu users may be familiar with these as they are provided by default on that distribution. Uncomment these lines to have access to these aliases in future.
 
 `.bashrc` also contains a reference to a `.bash_aliases` file, which does not exist by default. You can add it to provide a handy way of keeping all your aliases in a separate file.
 

raspbian/applications/omxplayer.md

@@ -8,19 +8,19 @@ OMXPlayer uses the OpenMAX (omx) hardware acceleration interface (API) which is
 
 ## Basic usage
 
-The simplest command line is `omxplayer <name of media file>`. The media file can be audio or video or both. For the examples below, we used an H264 video file that is included with the standard Rasbian installation.
+The simplest command line is `omxplayer <name of media file>`. The media file can be audio or video or both. For the examples below, we used an H264 video file that is included with the standard Raspbian installation.
 
 ```
 omxplayer /opt/vc/src/hello_pi/hello_video/test.h264
 ```
 
-By default the audio is sent to the analog port. If you are using a HDMI-equiped display device with speakers, you need to tell omxplayer to send the audio signal over the HDMI link.
+By default the audio is sent to the analog port. If you are using a HDMI-equipped display device with speakers, you need to tell omxplayer to send the audio signal over the HDMI link.
 
 ```
 omxplayer -adev hdmi /opt/vc/src/hello_pi/hello_video/test.h264
 ```
 
-When displaying video, the whole display will be used as output. You can specifiy which part of the display you want the video to be on using the window option.
+When displaying video, the whole display will be used as output. You can specify which part of the display you want the video to be on using the window option.
 
 ```
 omxplayer --win 0,0,640,480 /opt/vc/src/hello_pi/hello_video/test.h264

usage/scratch/gpio/README.md

@@ -195,7 +195,7 @@ There are also eight input sensor variables, named `Input1` to `Input8`, which h
 
 This provides a nice big red button, three large LEDs, four digital inputs, four digital outputs, and a loud buzzer. To use this board, set `AddOn` to `Pibrella`.
 
-#####Commands suported
+#####Commands supported
 
 - `[ red | yellow | green ] + [ on | high | off | low ]` e.g. `yellowhigh`
 - `Buzzer + (0 .. 4000)` e.g. `buzzer2100`

using-github.md

@@ -4,7 +4,7 @@ The sources for all the Raspberry Pi documentation is stored online on a site ca
 
 https://github.com/raspberrypi/documentation
 
-Although you won't be able to directly change documentation on the official repository, you can take a look at all the source files and see how everything is arranged. The sources files and folders follow the hierachical documentation as found on the Raspberry Pi website.
+Although you won't be able to directly change documentation on the official repository, you can take a look at all the source files and see how everything is arranged. The sources files and folders follow the hierarchical documentation as found on the Raspberry Pi website.
 
 Before making any changes, it is wise to find out whether your contribution is likely to be accepted by checking [here](https://www.raspberrypi.org/documentation/CONTRIBUTING.md).