raspberrypi · aallan · Feb 17, 2022 · Feb 7, 2022 · Feb 8, 2022 · Feb 8, 2022
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -16,9 +16,11 @@ Unless you are opening a pull request which will only make small corrections, fo
 
 Before starting writing your contribution to the documentation, you should take a look at the [style guide](https://github.com/raspberrypi/style-guide/blob/master/style-guide.md).
 
+**IMPORTANT**: Because the documentation makes use of the Asciidoc `include` statement, the `xref:` statements inside the documentation do not link back to the correct pages on Github, as Github does not support Asciidoc include functionality (see [#2005](https://github.com/raspberrypi/documentation/issues/2005)). However, these links work correctly when the HTML documentation is built and deployed. Please do not submit Pull Requests fixing link destinations unless you're sure that the link is broken [on the documentation site](https://www.raspberrypi.com/documentation/) itself.
+
 ## Type of Content
 
-We welcome contributions from the community, ranging from correcting small typos all the way through to adding entire new sections to the documentation. However, going forward we're going to be fairly targetted about what sort of content we add to the documentation. We are looking to keep the repository, and the documentation, focussed on Raspberry Pi-specific things, rather than having generic Linux or computing content.
+We welcome contributions from the community, ranging from correcting small typos all the way through to adding entire new sections to the documentation. However, going forward we're going to be fairly targeted about what sort of content we add to the documentation. We are looking to keep the repository, and the documentation, focused on Raspberry Pi-specific things, rather than having generic Linux or computing content.
 
 We are therefore deprecating the more generic documentation around using the Linux operating system, ahead of removing these sections entirely at some point in the future as part of a larger update to the documentation site. This move is happening as we feel these sort of more general topics are, ten years on from when the documentation was initially written, now much better covered elsewhere on the web.
 

diff --git a/documentation/asciidoc/accessories/build-hat/net-brick.adoc b/documentation/asciidoc/accessories/build-hat/net-brick.adoc
@@ -1,6 +1,6 @@
 === Using the Build HAT from .NET
 
-The Raspberry Pi Built HAT is refered to "Brick" in LEGO® parlance and you can talk directly to it from .NET using the https://datasheets.raspberrypi.com/build-hat/build-hat-serial-protocol.pdf[Build HAT Serial Protocol].
+The Raspberry Pi Built HAT is referred to "Brick" in LEGO® parlance and you can talk directly to it from .NET using the https://datasheets.raspberrypi.com/build-hat/build-hat-serial-protocol.pdf[Build HAT Serial Protocol].
 
 You can create a `brick` object as below,
 

diff --git a/documentation/asciidoc/accessories/build-hat/net-sensors.adoc b/documentation/asciidoc/accessories/build-hat/net-sensors.adoc
@@ -179,8 +179,8 @@ while (!Console.KeyAvailable)
 {
     var colorRead = colorSensor.GetColor();
     Console.WriteLine($"Color:     {colorRead}");
-    var relected = colorSensor.GetReflectedLight();
-    Console.WriteLine($"Reflected: {relected}");
+    var reflected = colorSensor.GetReflectedLight();
+    Console.WriteLine($"Reflected: {reflected}");
     var ambiant = colorSensor.GetAmbiantLight();
     Console.WriteLine($"Ambiant:   {ambiant}");
     var distance = colorSensor.GetDistance();
@@ -210,4 +210,4 @@ while(!console.KeyAvailable)
     console.WriteLine($"Distance: {distance.Distance} mm");
     Thread.Sleep(200);
 }
-----
+----
diff --git a/documentation/asciidoc/accessories/camera/libcamera_3rd_party_tuning.adoc b/documentation/asciidoc/accessories/camera/libcamera_3rd_party_tuning.adoc
@@ -2,7 +2,7 @@
 
 ==== The Camera Tuning File
 
-Most of the image procesing applied to frames from the sensor is done by the hardware ISP (Image Signal Procesor). This processing is governed by a set of _control algorithms_ and these in turn must have a wide range of parameters supplied to them. These parameters are tuned specifically for each sensor and are collected together in a JSON file known as the _camera tuning file_.
+Most of the image processing applied to frames from the sensor is done by the hardware ISP (Image Signal Processor). This processing is governed by a set of _control algorithms_ and these in turn must have a wide range of parameters supplied to them. These parameters are tuned specifically for each sensor and are collected together in a JSON file known as the _camera tuning file_.
 
 This _tuning file_ can be inspected and edited by users. Using the `--tuning-file` command line option, users can point the system at completely custom camera tuning files.
 

diff --git a/documentation/asciidoc/accessories/camera/libcamera_apps_intro.adoc b/documentation/asciidoc/accessories/camera/libcamera_apps_intro.adoc
@@ -4,7 +4,7 @@
 
 `libcamera` is a new software library aimed at supporting complex camera systems directly from the Linux operating system. In the case of the Raspberry Pi it enables us to drive the camera system directly from open source code running on ARM processors. The proprietary code running on the Broadcom GPU, and to which users have no access at all, is almost completely by-passed.
 
-`libcamera` presents a C++ API to applications and works at the level of configuring the camera and then allowing an application to request image frames. These image buffers reside in system memory and can be passed directly to still image encoders (such as JPEG) or to video encoders (such as h.264), though such ancilliary functions as encoding images or displaying them are strictly beyond the purview of `libcamera` itself.
+`libcamera` presents a C++ API to applications and works at the level of configuring the camera and then allowing an application to request image frames. These image buffers reside in system memory and can be passed directly to still image encoders (such as JPEG) or to video encoders (such as h.264), though such ancillary functions as encoding images or displaying them are strictly beyond the purview of `libcamera` itself.
 
 For this reason Raspberry Pi supplies a small set of example `libcamera-apps`. These are simple applications, built on top of `libcamera`, and are designed largely to emulate the function of the legacy stack built on Broadcom's propretary GPU code (some users will recognise these legacy applications as `raspstill` and `raspivid`). The applications we provide are:
 

diff --git a/documentation/asciidoc/accessories/camera/libcamera_options_vid.adoc b/documentation/asciidoc/accessories/camera/libcamera_options_vid.adoc
@@ -90,15 +90,15 @@ Example: `libcamera-vid -t 0 -o test.h264 -k --initial pause`
 	--split				Split multiple recordings into separate files
 ----
 
-This option should be used in conjunction with `--keypress` or `--signal` and causes each recording session (inbetween the pauses) to be written to a separate file.
+This option should be used in conjunction with `--keypress` or `--signal` and causes each recording session (in between the pauses) to be written to a separate file.
 
 Example: `libcamera-vid -t 0 --keypress --split --initial pause -o test%04d.h264`
 
 ----
 	--segment			Write the video recording into multiple segments <number>
 ----
 
-This option causes the video recording to be split accross multiple files where the parameter gives the approximate duration of each file in milliseconds.
+This option causes the video recording to be split across multiple files where the parameter gives the approximate duration of each file in milliseconds.
 
 One convenient little trick is to pass a very small duration parameter (namely, `--segment 1`) which will result in each frame being written to a separate output file. This makes it easy to do "burst" JPEG capture (using the MJPEG codec), or "burst" raw frame capture (using `libcamera-raw`).
 

diff --git a/documentation/asciidoc/accessories/camera/libcamera_vid.adoc b/documentation/asciidoc/accessories/camera/libcamera_vid.adoc
@@ -11,7 +11,7 @@ The resulting file can be played with `vlc` (among other applications)
 ----
 vlc test.h264
 ----
-Note that this is an unpackaged video bistream, it is not wrapped in any kind of container format (such as an mp4 file). The `--save-pts` option can be used to output frame timestamps so that the bitstream can subsequently be converted into an appropriate format using a tool like `mkvmerge`.
+Note that this is an unpackaged video bitstream, it is not wrapped in any kind of container format (such as an mp4 file). The `--save-pts` option can be used to output frame timestamps so that the bitstream can subsequently be converted into an appropriate format using a tool like `mkvmerge`.
 
 `libcamera-vid -o test.h264 --save-pts timestamps.txt`
 

diff --git a/documentation/asciidoc/accessories/display/display_intro.adoc b/documentation/asciidoc/accessories/display/display_intro.adoc
@@ -103,7 +103,7 @@ The options for the touchscreen are:
 | Invert Y coordinates
 
 | touchscreen-swapped-x-y
-| Swap X and Y cordinates
+| Swap X and Y coordinates
 |===
 
 === Troubleshooting

diff --git a/documentation/asciidoc/computers/config_txt/boot.adoc b/documentation/asciidoc/computers/config_txt/boot.adoc
@@ -41,9 +41,11 @@ Set the `disable_commandline_tags` command to `1` to stop `start.elf` from filli
 
 === `arm_64bit`
 
-If set to non-zero, forces the kernel loading system to assume a 64-bit kernel, starts the processors up in 64-bit mode, and sets `kernel8.img` to be the kernel image loaded, unless there is an explicit `kernel` option defined in which case that is used instead. Defaults to 0 on all platforms. *NOTE*: 64-bit kernels may be uncompressed image files or a gzip archive of an image (which can still be called kernel8.img; the bootloader will recognize the archive from the signature bytes at the beginning).
+If set to non-zero, forces the kernel loading system to assume a 64-bit kernel, starts the processors up in 64-bit mode, and sets `kernel8.img` to be the kernel image loaded, unless there is an explicit `kernel` option defined in which case that is used instead. Defaults to 0 on all platforms. 
 
-Note that the 64-bit kernel will only work on the Pi4, Pi3, and Pi2B rev1.2 boards with latest firmware.
+NOTE: 64-bit kernels may be uncompressed image files or a gzip archive of an image (which can still be called kernel8.img; the bootloader will recognize the archive from the signature bytes at the beginning).
+
+NOTE: The 64-bit kernel will only work on the Raspberry Pi 4, 3, and 2B rev 1.2 boards with latest firmware.
 
 === `arm_control`
 

diff --git a/documentation/asciidoc/computers/config_txt/overclocking.adoc b/documentation/asciidoc/computers/config_txt/overclocking.adoc
@@ -275,30 +275,6 @@ This table gives defaults for options that are the same across all models.
 
 The firmware uses Adaptive Voltage Scaling (AVS) to determine the optimum CPU/GPU core voltage in the range defined by `over_voltage` and `over_voltage_min`.
 
-|===
-| Model | Default | Resulting voltage
-
-| Pi 1
-| 0
-| 1.2V
-
-| Pi 2
-| 0
-| 1.2-1.3125V
-
-| Pi 3
-| 0
-| 1.2-1.3125V
-
-| Pi 4, Pi400, CM4
-| 0
-| 0.88V
-
-| Pi Zero
-| 6
-| 1.35V
-|===
-
 [discrete]
 ===== Specific to Raspberry Pi 4, Raspberry Pi 400 and CM4
 

diff --git a/documentation/asciidoc/computers/config_txt/video.adoc b/documentation/asciidoc/computers/config_txt/video.adoc
@@ -1405,7 +1405,7 @@ hdmi_timings=<h_active_pixels> <h_sync_polarity> <h_front_porch> <h_sync_pulse>
 ----
 <h_active_pixels> = horizontal pixels (width)
 <h_sync_polarity> = invert hsync polarity
-<h_front_porch>   = horizontal forward padding from DE acitve edge
+<h_front_porch>   = horizontal forward padding from DE active edge
 <h_sync_pulse>    = hsync pulse width in pixel clocks
 <h_back_porch>    = vertical back padding from DE active edge
 <v_active_lines>  = vertical pixels height (lines)
@@ -1568,7 +1568,7 @@ dpi_timings=<h_active_pixels> <h_sync_polarity> <h_front_porch> <h_sync_pulse> <
 ----
 <h_active_pixels> = horizontal pixels (width)
 <h_sync_polarity> = invert hsync polarity
-<h_front_porch>   = horizontal forward padding from DE acitve edge
+<h_front_porch>   = horizontal forward padding from DE active edge
 <h_sync_pulse>    = hsync pulse width in pixel clocks
 <h_back_porch>    = vertical back padding from DE active edge
 <v_active_lines>  = vertical pixels height (lines)

diff --git a/documentation/asciidoc/computers/configuration/access-point-routed.adoc b/documentation/asciidoc/computers/configuration/access-point-routed.adoc
@@ -58,7 +58,7 @@ In order to provide network management services (DNS, DHCP) to wireless clients,
 sudo apt install dnsmasq
 ----
 
-Finally, install `netfilter-persistent` and its plugin `iptables-persistent`. This utilty helps by saving firewall rules and restoring them when the Raspberry Pi boots:
+Finally, install `netfilter-persistent` and its plugin `iptables-persistent`. This utility helps by saving firewall rules and restoring them when the Raspberry Pi boots:
 
 ----
 sudo DEBIAN_FRONTEND=noninteractive apt install -y netfilter-persistent iptables-persistent

diff --git a/documentation/asciidoc/computers/configuration/device-tree.adoc b/documentation/asciidoc/computers/configuration/device-tree.adoc
@@ -723,7 +723,7 @@ The HAT overlay is automatically loaded by the firmware after the base DTB, so i
 [[part3.5]]
 ==== Dynamic Device Tree
 
-As of Linux 4.4, the RPi kernels support the dynamic loading of overlays and parameters. Compatible kernels manage a stack of overlays that are applied on top of the base DTB. Changes are immediately reflected in `/proc/device-tree` and can cause modules to be loaded and platform devices to be created and destroyed.
+As of Linux 4.4, Raspberry Pi kernels support the dynamic loading of overlays and parameters. Compatible kernels manage a stack of overlays that are applied on top of the base DTB. Changes are immediately reflected in `/proc/device-tree` and can cause modules to be loaded and platform devices to be created and destroyed.
 
 The use of the word "stack" above is important - overlays can only be added and removed at the top of the stack; changing something further down the stack requires that anything on top of it must first be removed.
 

diff --git a/documentation/asciidoc/computers/configuration/uart.adoc b/documentation/asciidoc/computers/configuration/uart.adoc
@@ -89,6 +89,10 @@ The following table summarises the assignment of the first two UARTs:
 | secondary (Bluetooth)
 | primary
 
+| Compute Module 3 & 3+
+| primary
+| secondary
+
 | Raspberry Pi 4
 | secondary (Bluetooth)
 | primary

diff --git a/documentation/asciidoc/computers/getting-started/network-installation.adoc b/documentation/asciidoc/computers/getting-started/network-installation.adoc
@@ -8,7 +8,7 @@ But how do you get the operating system onto your SD card if you don’t have an
 
 If you do not have another computer to run Raspberry Pi Imager you can start the application directly on a Raspberry Pi 4 or Raspberry Pi 400 by connecting it to the Internet with an Ethernet cable. This will allow you to install the operating system onto a **blank** SD Card directly from the network without using another computer.
 
-IMPORTANT: Network installation is only supported on Raspberry Pi 4 and Raspberry Pi 400. Additionally, to avoid slowing down “normal boot,” the network instllation feature is only enabled if there’s no bootable media present, and you have xref:raspberry-pi.adoc#usb-mass-storage-boot[USB mass storage boot] in your xref:raspberry-pi.adoc#BOOT_ORDER[boot order].
+IMPORTANT: Network installation is only supported on Raspberry Pi 4 and Raspberry Pi 400. Additionally, to avoid slowing down “normal boot,” the network installation feature is only enabled if there’s no bootable media present, and you have xref:raspberry-pi.adoc#usb-mass-storage-boot[USB mass storage boot] in your xref:raspberry-pi.adoc#BOOT_ORDER[boot order].
 
 === Updating to the BETA bootloader
 
@@ -20,7 +20,7 @@ WARNING: Installation of the beta bootloader should be fairly safe, but you shou
 
 The easiest way to update the bootloader on your Raspberry Pi 4 or 400 is by using the Raspberry Pi Imager, either running on your Raspberry Pi or another computer, to copy the required software onto an SD card. You’ll need a spare blank SD Card and, if you’re using a Raspberry Pi or another computer that doesn’t have an SD Card slot, a USB to SD Card dongle.
 
-You should be aware that the SD Card you’re using to update your Raspberry Pi’s bootloader will be wiped of any existing data, so you shouldn’t use the SD Card you are currently using with your Raspberry Pi.
+You should be aware that the SD Card you’re using to update your Raspberry Pi computer's bootloader will be wiped of any existing data, so you shouldn’t use the SD Card you are currently using with your Raspberry Pi.
 
 In the Imager application, click on the “Choose OS” button and scroll down the “Operating System” list in the pop-up window and select “Misc utility images”, then select “Beta Test Bootloader.”
 
@@ -51,11 +51,11 @@ You will need a keyboard to make use of the network installation feature. While
 
 video::b1SYVpM9lto[youtube]
 
-You should also insert a **blank** SD Card into the Raspberry Pi's SD Card slot.
+You should also insert a **blank** SD Card into the SD card slot of your Raspberry Pi.
 
 NOTE: You should make sure there isn't a bootable SD Card, or USB drive, attached to your Raspberry Pi.
 
-Power on your Raspberry Pi. As always it will first look for an SD Card, and then a USB drive, to find bootable media. However if you have a keyboard attached the Raspberry Pi will now show the network installation screen.
+Power on your Raspberry Pi. As always it will first look for an SD Card, and then a USB drive, to find bootable media. However if you have a keyboard attached, the Raspberry Pi will now show the network installation screen.
 
 image::images/network-install-1.png[width="80%"]
 
@@ -73,4 +73,4 @@ image::images/network-install-4.png[width="80%"]
 
 NOTE: More information can about using the Raspberry Pi Imager can be found in the section on xref:getting-started.adoc#installing-the-operating-system[installing your operating system].
 
-After installing the operating system onto your blank SD Card you will not longer see the network installation screen on boot. If you do want to run it, you just need to remove any bootable disks. You can re-insert them later when the Raspberry PI Imager is running. But take care not to overwrite any working disks that you want to keep!
+After installing the operating system onto your blank SD Card you will no longer see the network installation screen on boot. If you do want to run it, you just need to remove any bootable disks. You can re-insert them later when Raspberry Pi Imager is running. But take care not to overwrite any working disks that you want to keep!
diff --git a/documentation/asciidoc/computers/getting-started/setting-up.adoc b/documentation/asciidoc/computers/getting-started/setting-up.adoc
@@ -2,7 +2,7 @@
 
 To get started with your Raspberry Pi computer you'll need the following accessories:
 
-A computer monitor, or television. Most should work as a display for the Raspberry Pi, but for best results, you should use a display with HDMI input. You'll also need a appropriate xref:getting-started.adoc#connecting-a-display[display] cable, to connect your monitor to your Raspberry Pi.
+A computer monitor, or television. Most should work as a display for the Raspberry Pi, but for best results, you should use a display with HDMI input. You'll also need an appropriate xref:getting-started.adoc#connecting-a-display[display] cable, to connect your monitor to your Raspberry Pi.
 
 NOTE: If your display uses an HDMI connection and has built-in speakers, you can use it to output sound.