diff --git a/.github/actions/deploy-action/action.yml b/.github/actions/deploy-action/action.yml
new file mode 100644
index 0000000000..ac777a7daf
--- /dev/null
+++ b/.github/actions/deploy-action/action.yml
@@ -0,0 +1,58 @@
+name: Deploy via Bastion Host
+description: "Deploy specified files and directories to a primary and secondary server via a bastion host"
+inputs:
+ private_ssh_key:
+ description: "The private SSH key used to authenticate with the remote servers"
+ required: true
+
+ public_bastion_host_keys:
+ description: "The public SSH host keys for the bastion server"
+ required: true
+
+ bastion_host:
+ description: "The [user@]hostname of the bastion server"
+ required: true
+
+ primary_host:
+ description: "The [user@]hostname of the primary web server"
+ required: true
+
+ secondary_host:
+ description: "The [user@]hostname of the secondary web server"
+ required: true
+
+ source:
+ description: "The files and directories to copy from the workspace"
+ required: true
+
+ destination:
+ description: "The destination to copy the source files and directories to"
+ required: true
+
+runs:
+ using: "composite"
+ steps:
+ - name: Configure ssh-agent for subsequent steps
+ run: echo "SSH_AUTH_SOCK=/tmp/ssh_agent.sock" >> $GITHUB_ENV
+ shell: bash
+
+ - name: Start ssh-agent with SSH key
+ run: |
+ ssh-agent -a $SSH_AUTH_SOCK
+ ssh-add - <<< "${{ inputs.private_ssh_key }}"
+ shell: bash
+
+ - name: Populate known hosts
+ run: |
+ mkdir -m 700 -p ~/.ssh
+ printf "${{ inputs.public_bastion_host_keys }}" >> ~/.ssh/known_hosts
+ chmod 600 ~/.ssh/known_hosts
+ shell: bash
+
+ - name: Deploy to primary server
+ run: rsync -avz --delete -e 'ssh -A ${{ inputs.bastion_host }} ssh' ${{ inputs.source }} ${{ inputs.primary_host }}:${{ inputs.destination }}
+ shell: bash
+
+ - name: Deploy to secondary server
+ run: rsync -avz --delete -e 'ssh -A ${{ inputs.bastion_host }} ssh' ${{ inputs.source }} ${{ inputs.secondary_host }}:${{ inputs.destination }}
+ shell: bash
diff --git a/.github/dependabot.yml b/.github/dependabot.yml
new file mode 100644
index 0000000000..4d1565e612
--- /dev/null
+++ b/.github/dependabot.yml
@@ -0,0 +1,17 @@
+version: 2
+updates:
+ - package-ecosystem: "bundler"
+ directory: "/"
+ schedule:
+ interval: "weekly"
+ target-branch: "develop"
+ - package-ecosystem: "github-actions"
+ directory: "/"
+ schedule:
+ interval: "weekly"
+ target-branch: "develop"
+ - package-ecosystem: "pip"
+ directory: "/"
+ schedule:
+ interval: "weekly"
+ target-branch: "develop"
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
new file mode 100644
index 0000000000..a81b5f78cb
--- /dev/null
+++ b/.github/workflows/build.yml
@@ -0,0 +1,56 @@
+name: Build
+
+on:
+ push:
+ branches:
+ - master
+ pull_request:
+
+jobs:
+ build:
+ runs-on: ubuntu-latest
+ steps:
+ - name: Only allow pull requests based on master from the develop branch of the current repository
+ if: ${{ github.base_ref == 'master' && !(github.head_ref == 'develop' && github.event.pull_request.head.repo.full_name == github.repository) }}
+ run: |
+ echo "Pull requests based on master can only come from the develop branch of this repository"
+ echo "Please check your base branch as it should be develop by default"
+ exit 1
+ - uses: actions/checkout@v4
+ - uses: actions/setup-python@v5
+ with:
+ python-version: 3.9
+ - name: Install Python dependencies
+ uses: py-actions/py-dependency-install@v4
+ - name: Install Python libs
+ run: pip3 install -r ./requirements.txt
+ - uses: ruby/setup-ruby@v1
+ with:
+ ruby-version: 3.2
+ bundler-cache: true
+ - uses: seanmiddleditch/gha-setup-ninja@v6
+ with:
+ version: 1.10.2
+ - name: Install arm-none-eabi-gcc GNU Arm Embedded Toolchain
+ uses: carlosperate/arm-none-eabi-gcc-action@v1.10.1
+ - name: Install Doxygen
+ run: |
+ wget https://www.doxygen.nl/files/doxygen-1.10.0.linux.bin.tar.gz
+ tar xf doxygen-1.10.0.linux.bin.tar.gz -C "$HOME"
+ echo "$HOME/doxygen-1.10.0/bin" >> $GITHUB_PATH
+ - name: Build Doxygen documentation
+ run: make build_doxygen_adoc
+ - name: Build documentation
+ run: make -j 2
+ - name: Deploy to Mythic Beasts
+ if: ${{ github.ref == 'refs/heads/master' }}
+ uses: ./.github/actions/deploy-action
+ with:
+ private_ssh_key: ${{ secrets.DEPLOY_SSH_KEY }}
+ public_bastion_host_keys: ${{ secrets.DEPLOY_KNOWN_HOSTS }}
+ bastion_host: ${{ secrets.DEPLOY_BASTION_HOST }}
+ primary_host: ${{ secrets.DEPLOY_PRIMARY_HOST }}
+ secondary_host: ${{ secrets.DEPLOY_SECONDARY_HOST }}
+ # this needs to match destination: in _config.yml
+ source: documentation/html/
+ destination: documentation
diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
new file mode 100644
index 0000000000..9ffb99cfcc
--- /dev/null
+++ b/.github/workflows/stale.yml
@@ -0,0 +1,26 @@
+name: Mark stale issues and pull requests
+
+on:
+ schedule:
+ - cron: '15 2 * * SUN'
+
+jobs:
+ stale:
+
+ runs-on: ubuntu-latest
+ permissions:
+ issues: write
+ pull-requests: write
+
+ steps:
+ - uses: actions/stale@v9
+ with:
+ repo-token: ${{ secrets.GITHUB_TOKEN }}
+ stale-issue-message: 'This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.'
+ stale-pr-message: 'This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.'
+ stale-issue-label: 'stale issue'
+ stale-pr-label: 'stale pull request'
+ exempt-issue-labels: 'ready to merge,ready for copy-edit,paused,in progress,linked pull request,backlog'
+ exempt-pr-labels: 'ready to merge,ready for copy-edit,paused,in progress,backlog'
+ days-before-stale: 60
+ days-before-close: 7
diff --git a/.gitignore b/.gitignore
index a39bfd14c8..1d7ee958d6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,7 @@
-_build/
-Gemfile.lock
.DS_Store
+__pycache__
+build
+build-pico-sdk-docs
+documentation/html
+documentation/asciidoc/pico-sdk
+.venv
diff --git a/.gitmodules b/.gitmodules
new file mode 100644
index 0000000000..9f315972ef
--- /dev/null
+++ b/.gitmodules
@@ -0,0 +1,13 @@
+[submodule "documentation/pico-sdk"]
+ path = lib/pico-sdk
+ url = https://github.com/raspberrypi/pico-sdk
+ branch = master
+[submodule "documentation/pico-examples"]
+ path = lib/pico-examples
+ url = https://github.com/raspberrypi/pico-examples.git
+ branch = master
+
+[submodule "doxygentoasciidoc"]
+ path = lib/doxygentoasciidoc
+ url = https://github.com/raspberrypi/doxygentoasciidoc.git
+ branch = main
diff --git a/BUILD.md b/BUILD.md
new file mode 100644
index 0000000000..2d5ac2c6e3
--- /dev/null
+++ b/BUILD.md
@@ -0,0 +1,103 @@
+# Making the documentation
+
+A brief overview of the files in this repo, and the make-targets in the `Makefile`, and how it all hangs together to build the final output html files from the initial adoc input files.
+
+**TL;DR version**: To build the 'regular' documentation site, run `make clean; make`. To build the documentation site with pico-sdk API docs included, run `make clean; make build_doxygen_adoc; make`.
+
+## Files in the repo
+
+* `documentation/asciidoc/` all our "regular" asciidoc documentation (referred to as `$(ASCIIDOC_DIR)` in the `Makefile`)
+* `documentation/images/` the images shown on the "boxes"
+* `documentation/pico-sdk/` [pico-sdk](https://github.com/raspberrypi/pico-sdk) submodule (initially empty) (referred to as `$(PICO_SDK_DIR)` in the `Makefile`)
+* `documentation/pico-examples/` [pico-examples](https://github.com/raspberrypi/pico-examples) submodule (initially empty) (referred to as `$(PICO_EXAMPLES_DIR)` in the `Makefile`)
+* `jekyll-assets/` various styling stuff used by the jekyll build (referred to as `$(JEKYLL_ASSETS_DIR)` in the `Makefile`)
+* `scripts/` various Python build-scripts (referred to as `$(SCRIPTS_DIR)` in the `Makefile`)
+* `Makefile` top-level Makefile that runs the build
+
+## When you clone the repo and run `make`
+
+1. `.DEFAULT_GOAL := html` is set in the `Makefile`, which means that `make` actually does `make html`.
+ 1. The `html` target has the `run_ninja` target as a prerequisite
+ 1. The `run_ninja` target has `$(AUTO_NINJABUILD)` (i.e. `build/autogenerated.ninja`) as a prerequisite
+ 1. `build/autogenerated.ninja` has `$(BUILD_DIR)` (i.e. `build/`) as a prerequisite
+ 1. So the `build/` directory gets created
+ 1. Then `build/autogenerated.ninja` gets created
+ 1. Then `ninja` gets invoked, which uses `build.ninja` (which includes `build/autogenerated.ninja`) to create a whole bunch of files in the `build/` directory
+ 1. Then `jekyll` gets invoked, which uses all the files in the `build/` directory to create all the final output files in the `$(HTML_DIR)` (i.e. `documentation/html/`) directory
+
+If you run `make` a second time, then `make` and `ninja` will spot that everything is up to date, and only re-run the `jekyll` stage.
+
+## When you run `make clean`
+
+1. The `clean` target has the `clean_html` and `clean_doxygen_adoc` targets as prerequisites
+ 1. In this case `clean_doxygen_adoc` doesn't do anything, but `clean_html` deletes the `documentation/html/` directory
+1. Then the `build/` directory is deleted
+
+## When you run `make build_doxygen_adoc`
+
+1. The `build_doxygen_adoc` target has `$(ASCIIDOC_DOXYGEN_DIR)/index_doxygen.adoc` (i.e. `documentation/asciidoc/pico-sdk/index_doxygen.adoc`) as a prerequisite
+ 1. `documentation/asciidoc/pico-sdk/index_doxygen.adoc` has `$(DOXYGEN_HTML_DIR)` (i.e. `build-pico-sdk-docs/docs/doxygen/html/`) and `$(ASCIIDOC_DOXYGEN_DIR)` (i.e. `documentation/asciidoc/pico-sdk/`) as prerequisites
+ 1. So the `documentation/asciidoc/pico-sdk/` directory gets created
+ 1. `build-pico-sdk-docs/docs/doxygen/html/` has `$(ALL_SUBMODULE_CMAKELISTS)` (i.e. `documentation/pico-sdk/CMakeLists.txt` and `documentation/pico-examples/CMakeLists.txt`) and `$(DOXYGEN_PICO_SDK_BUILD_DIR)` (i.e. `build-pico-sdk-docs/`) as prerequisites
+ 1. So the `build-pico-sdk-docs/` directory gets created
+ 1. `documentation/pico-sdk/CMakeLists.txt` gets created by initialising the `pico-sdk` submodule
+ 1. `documentation/pico-examples/CMakeLists.txt` gets created by initialising the `pico-examples` submodule
+ 1. Then `cmake` gets invoked for `pico-sdk/`, which creates `build-pico-sdk-docs/Makefile`
+ 1. Then we run the `docs` target in `build-pico-sdk-docs/Makefile` which runs `doxygen` and creates a bunch of HTML files in `build-pico-sdk-docs/docs/doxygen/html/` (referred to as `$(DOXYGEN_HTML_DIR)` in the `Makefile`)
+1. Then we run the new `scripts/transform_doxygen_html.py` to convert the HTML files from `build-pico-sdk-docs/docs/doxygen/html/` into adoc files in `documentation/asciidoc/pico-sdk/`
+
+If you run `make build_doxygen_adoc` a second time, then `make` will detect that everything is already up to date, and so not do anything.
+
+If we **now** run `make` (see the `make html` description above), it will now find `documentation/asciidoc/pico-sdk/` and include that in the "tabs" in the output html files in `documentation/html/`.
+
+And if we then run a `make clean`, the presence of `documentation/asciidoc/pico-sdk/` will cause the `clean_doxygen_adoc` target to delete the files in the `build/` directory (to prevent things getting into an "invalid state"), and then delete the `documentation/asciidoc/pico-sdk/` directory.
+Note that `build-pico-sdk-docs/` (the raw Doxygen output) **isn't** deleted by `make clean`, because it's basically "static content" which can take a while to regenerate. To _also_ get rid of `build-pico-sdk-docs/` you can either `make clean_doxygen_html` or `make clean_everything` (with the latter also deinitialising the submodules).
+
+## Makefile targets
+
+Targets which might be useful for getting things to / from a particular state.
+
+* `make fetch_submodules` populates (initialises) the `documentation/pico-sdk/` and `documentation/pico-examples/` submodule directories
+* `make clean_submodules` deinitialises the submodule directories, i.e. is the opposite of `fetch_submodules`
+* `make build_doxygen_html` runs the `cmake` and `make` steps required to create the Doxygen HTML files (in `build-pico-sdk-docs/docs/doxygen/html/`) from the `pico-sdk` submodule
+* `make clean_doxygen_html` deletes the `build-pico-sdk-docs/` directory i.e. is the opposite of `build_doxygen_html`
+* `make build_doxygen_adoc` described in an earlier section, converts html files from `build-pico-sdk-docs/docs/doxygen/html/` to adoc files in `documentation/asciidoc/pico-sdk/`
+* `make clean_doxygen_adoc` deletes the `documentation/asciidoc/pico-sdk/` directory i.e. is the opposite of `build_doxygen_adoc`
+* `make run_ninja` converts adoc files from `documentation/asciidoc/` into adoc files in `build/`
+* `make clean_ninja` deletes the files in `build/` i.e. is the opposite of `run_ninja`
+* `make html` described in an earlier section, converts adoc files from `build/` into html files in `documentation/html/`. The default target invoked when no explicit target is given.
+* `make clean_html` deletes the `documentation/html/` directory, i.e. is the opposite of `html`
+* `make serve_html` converts adoc files from `build/` into html files in `documentation/html/` and then runs a mini webserver so that you can preview the output
+* `make clean` runs both of `clean_html` & `clean_doxygen_adoc` and also deletes `build/`
+* `make clean_everything` runs all of `clean_submodules`, `clean_doxygen_html` and `clean` i.e. returns your local directory to a fairly pristine state
+
+Note that for day-to-day usage, you'll typically only use the `make clean`, `make`, `make build_doxygen_adoc` and `make serve_html` commands - the dependencies in the `Makefile` are all set up so that any necessary intermediate steps are performed automatically.
+
+Bad ASCII-art time:
+
+```
++---------------+
+| 'clean' state |--> make build_doxygen_adoc
++---------------+ |
+ | | ^ V
+ | V | +-----------------------------------------+
+ | make make clean <---| documentation/asciidoc/pico-sdk/ exists |
+ | | ^ +-----------------------------------------+
+ | | | | |
+ | | | V |
+ | V | make |
+ | +----------------------------+ | |
+ | | documentation/html/ exists |<---+ |
+ | +----------------------------+ |
+ | | ^ |
+ | V | |
+ +---> make serve_html <-----------------------+
+ | |
+ | Ctrl-C
+ | ^
+ V |
++----------------------------------------------------------+
+| documentation/html/ exists and preview webserver running |
++----------------------------------------------------------+
+```
+
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index ab01251239..37fef6b8ea 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,32 +1,163 @@
-# Contributing
+# Contributing to the Raspberry Pi Documentation
-Please read our contribution guidelines before creating an issue or pull request.
+The Raspberry Pi Documentation website is built from Asciidoc source using:
-**Please note that the issue tracker on this repository is for issues with *the contents of the documentation*, not support queries. Please post support queries in the [forums](https://www.raspberrypi.org/forums/).**
+* [Asciidoctor](https://asciidoctor.org/)
+* [Jekyll](https://jekyllrb.com/)
+* [jekyll-asciidoc](https://github.com/asciidoctor/jekyll-asciidoc)
+* Python
-When creating an issue, please:
+The website automatically deploys to [www.raspberrypi.com/documentation](https://www.raspberrypi.com/documentation) using GitHub Actions when new commits appear in the `master` branch.
-- Explain the issue as clearly as possible
-- Include a link to the page(s) to which your issue relates
-- Use [Markdown](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) to format your issue, particularly for blocks of code
+## Contribute
-Creating a pull request:
+To contribute or update documentation:
-- If your contribution regards typos and spelling mistakes, feel free to fix these, and they'll be merged if they accord with our [in-house style guide](https://github.com/raspberrypilearning/style-guide/blob/master/style-guide.md). Otherwise, always open an issue first. This will allow us to determine whether or not the change should take place. Explain your issue, and we will discuss it with you. If we agree the change is necessary, we will mark it as 'TODO'. Then we will either fix it when we get a chance, or allow a member of the community to supply the change with a pull request.
-- Note that this documentation is intended to be a short and concise set of helpful resources aimed at the majority of users. We will only feature our recommended distribution, Raspberry Pi OS, in detail; in order to keep the documentation manageable, we will not accept additions covering alternative distributions.
+1. Create a fork of this repository on your GitHub account.
-Find a short tutorial on making changes using GitHub [here](using-github.md).
+1. Make changes in your fork. Start from the default `develop` branch.
-**Please be aware we are not able to deal with all issues and pull requests immediately, so please have patience.**
+1. Read our [style guide](https://github.com/raspberrypi/style-guide/blob/master/style-guide.md) to ensure that your changes are consistent with the rest of our documentation. Since Raspberry Pi is a British company, be sure to include all of your extra `u`s and transfigure those `z`s (pronounced 'zeds') into `s`s!
-## Derivatives
+1. [Open a pull request](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork) against this repository.
-The licence must remain in all derivatives of this work.
+1. The maintainers will assess and copy-edit the PR. This can take anywhere from a few minutes to a few days, depending on the size of your PR, the time of year, and the availability of the maintainers.
-## Licence
+1. After making any requested improvements to your PR, the maintainers will accept the PR and merge your changes into `develop`.
-[](http://creativecommons.org/licenses/by-sa/4.0/)
+1. When the maintainers next release the documentation by merging `develop` into `master`, your changes will go public on the production documentation site.
-***Raspberry Pi Documentation*** by the [Raspberry Pi Foundation](https://www.raspberrypi.org/) is licensed under a [Creative Commons Attribution 4.0 International Licence](http://creativecommons.org/licenses/by-sa/4.0/).
+Alternatively, [open an issue](https://github.com/raspberrypi/documentation/issues) to discuss proposed changes.
+
+## Build
+
+### Install dependencies
+
+To build the Raspberry Pi documentation locally, you'll need Ruby, Python, and the Ninja build system.
+
+#### Linux
+
+Use `apt` to install the dependencies:
+
+```console
+$ sudo apt install -y ruby ruby-dev python3 python3-pip make ninja-build
+```
+
+Then, append the following lines to your `~/.bashrc` file (or equivalent shell configuration):
+
+```bash
+export GEM_HOME="$(ruby -e 'puts Gem.user_dir')"
+export PATH="$PATH:$GEM_HOME/bin"
+```
+
+Close and re-launch your terminal window to use the new dependencies and configuration.
+
+#### macOS
+
+If you don't already have it, we recommend installing the [Homebrew](https://brew.sh/) package manager:
+
+```console
+$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
+```
+
+Next, use Homebrew to install Ruby:
+
+```console
+$ brew install ruby
+```
+
+After installing Ruby, follow the instructions provided by Homebrew to make your new Ruby version easily accessible from the command line.
+
+Then, use Homebrew to install the most recent version of Python:
+
+```console
+$ brew install python
+```
+
+Then, install the [Ninja build system](https://formulae.brew.sh/formula/ninja#default):
+
+```console
+$ brew install ninja
+```
+
+### Set up environment
+
+Use the `gem` package manager to install the [Ruby bundler](https://bundler.io/), which this repository uses to manage Ruby dependencies:
+
+```console
+$ gem install bundler
+```
+
+And then install the required Ruby gems:
+
+```console
+$ bundle install
+```
+
+Configure a Python virtual environment for this project:
+
+```console
+$ python -m venv .env
+```
+
+Activate the virtual environment:
+
+```console
+$ source .env/bin/activate
+```
+
+> [!TIP]
+> When you're using a virtual environment, you should see a `(.env)` prefix at the start of your terminal prompt. At any time, run the `deactivate` command to exit the virtual environment.
+
+In the virtual environment, install the required Python modules:
+
+```console
+$ pip3 install -r requirements.txt
+```
+
+### Build HTML
+
+> [!IMPORTANT]
+> If you configured a Python virtual environment as recommended in the previous step, **always** run `source .env/bin/activate` before building. You must activate the virtual environment to access to all of the Python dependencies installed in that virtual environment.
+
+To build the documentation and start a local server to preview the built site, run the following command:
+
+```console
+$ make serve_html
+```
+
+You can access the virtual server at [http://127.0.0.1:4000/documentation/](http://127.0.0.1:4000/documentation/).
+
+> [!TIP]
+> To delete and rebuild the documentation site, run `make clean`, then re-run the build command. You'll need to do this every time you add or remove an Asciidoc, image, or video file.
+
+
+### Build the Pico C SDK Doxygen documentation
+
+The Raspberry Pi documentation site includes a section of generated Asciidoc that we build from the [Doxygen Pico SDK documentation](https://github.com/raspberrypi/pico-sdk).
+
+We use the tooling in this repository and [doxygentoasciidoc](https://github.com/raspberrypi/doxygentoasciidoc) to generate that documentation section. By default, local documentation builds don't include this section because it takes a bit longer to build (tens of seconds) than the rest of the site.
+
+Building the Pico C SDK Doxygen documentation requires the following additional package dependencies:
+
+```console
+$ sudo apt install -y cmake gcc-arm-none-eabi doxygen graphviz
+```
+
+Then, initialise the Git submodules used in the Pico C SDK section build:
+
+```console
+$ git submodule update --init
+```
+
+Run the following command to build the Pico C SDK section Asciidoc files from the Doxygen source:
+
+```console
+$ make build_doxygen_adoc
+```
+
+The next time you build the documentation site, you'll see the Pico C SDK section in your local preview.
+
+> [!TIP]
+> To delete and rebuild the generated files, run `make clean_doxygen_xml`, then re-run the build command.
-Based on a work at https://github.com/raspberrypi/documentation
diff --git a/Gemfile b/Gemfile
new file mode 100644
index 0000000000..bb73401e41
--- /dev/null
+++ b/Gemfile
@@ -0,0 +1,42 @@
+source "https://rubygems.org"
+
+# Hello! This is where you manage which Jekyll version is used to run.
+# When you want to use a different version, change it below, save the
+# file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
+#
+# bundle exec jekyll serve
+#
+# This will help ensure the proper Jekyll version is running.
+# Happy Jekylling!
+gem "jekyll", "~> 4.4.1"
+
+# This is the default theme for new Jekyll sites. You may change this to anything you like.
+gem "minima", "~> 2.5"
+
+# If you want to use GitHub Pages, remove the "gem "jekyll"" above and
+# uncomment the line below. To upgrade, run `bundle update github-pages`.
+# gem "github-pages", group: :jekyll_plugins
+
+# If you have any plugins, put them here!
+group :jekyll_plugins do
+ gem "jekyll-feed", "~> 0.17"
+ gem 'jekyll-asciidoc'
+ gem 'asciidoctor'
+ gem 'asciidoctor-tabs', ">= 1.0.0.beta.6"
+end
+
+# Windows does not include zoneinfo files, so bundle the tzinfo-data gem
+# and associated library.
+install_if -> { RUBY_PLATFORM =~ %r!mingw|mswin|java! } do
+ gem "tzinfo", "~> 2.0"
+ gem "tzinfo-data"
+end
+
+# Performance-booster for watching directories on Windows
+gem "wdm", "~> 0.2.0", :install_if => Gem.win_platform?
+
+gem "nokogiri", "~> 1.18"
+
+# So we can add custom element templates
+gem 'slim', '~> 5.2.1'
+gem 'thread_safe', '~> 0.3.5'
diff --git a/Gemfile.lock b/Gemfile.lock
new file mode 100644
index 0000000000..385a34392c
--- /dev/null
+++ b/Gemfile.lock
@@ -0,0 +1,122 @@
+GEM
+ remote: https://rubygems.org/
+ specs:
+ addressable (2.8.7)
+ public_suffix (>= 2.0.2, < 7.0)
+ asciidoctor (2.0.23)
+ asciidoctor-tabs (1.0.0.beta.6)
+ asciidoctor (>= 2.0.0, < 3.0.0)
+ base64 (0.2.0)
+ bigdecimal (3.1.9)
+ colorator (1.1.0)
+ concurrent-ruby (1.3.5)
+ csv (3.3.2)
+ em-websocket (0.5.3)
+ eventmachine (>= 0.12.9)
+ http_parser.rb (~> 0)
+ eventmachine (1.2.7)
+ ffi (1.17.1)
+ forwardable-extended (2.6.0)
+ google-protobuf (4.29.3)
+ bigdecimal
+ rake (>= 13)
+ http_parser.rb (0.8.0)
+ i18n (1.14.7)
+ concurrent-ruby (~> 1.0)
+ jekyll (4.4.1)
+ addressable (~> 2.4)
+ base64 (~> 0.2)
+ colorator (~> 1.0)
+ csv (~> 3.0)
+ em-websocket (~> 0.5)
+ i18n (~> 1.0)
+ jekyll-sass-converter (>= 2.0, < 4.0)
+ jekyll-watch (~> 2.0)
+ json (~> 2.6)
+ kramdown (~> 2.3, >= 2.3.1)
+ kramdown-parser-gfm (~> 1.0)
+ liquid (~> 4.0)
+ mercenary (~> 0.3, >= 0.3.6)
+ pathutil (~> 0.9)
+ rouge (>= 3.0, < 5.0)
+ safe_yaml (~> 1.0)
+ terminal-table (>= 1.8, < 4.0)
+ webrick (~> 1.7)
+ jekyll-asciidoc (3.0.1)
+ asciidoctor (>= 1.5.0, < 3.0.0)
+ jekyll (>= 3.0.0)
+ jekyll-feed (0.17.0)
+ jekyll (>= 3.7, < 5.0)
+ jekyll-sass-converter (3.1.0)
+ sass-embedded (~> 1.75)
+ jekyll-seo-tag (2.8.0)
+ jekyll (>= 3.8, < 5.0)
+ jekyll-watch (2.2.1)
+ listen (~> 3.0)
+ json (2.9.1)
+ kramdown (2.5.1)
+ rexml (>= 3.3.9)
+ kramdown-parser-gfm (1.1.0)
+ kramdown (~> 2.0)
+ liquid (4.0.4)
+ listen (3.9.0)
+ rb-fsevent (~> 0.10, >= 0.10.3)
+ rb-inotify (~> 0.9, >= 0.9.10)
+ mercenary (0.4.0)
+ mini_portile2 (2.8.8)
+ minima (2.5.2)
+ jekyll (>= 3.5, < 5.0)
+ jekyll-feed (~> 0.9)
+ jekyll-seo-tag (~> 2.1)
+ nokogiri (1.18.8)
+ mini_portile2 (~> 2.8.2)
+ racc (~> 1.4)
+ pathutil (0.16.2)
+ forwardable-extended (~> 2.6)
+ public_suffix (6.0.1)
+ racc (1.8.1)
+ rake (13.2.1)
+ rb-fsevent (0.11.2)
+ rb-inotify (0.11.1)
+ ffi (~> 1.0)
+ rexml (3.4.0)
+ rouge (4.5.1)
+ safe_yaml (1.0.5)
+ sass-embedded (1.83.4)
+ google-protobuf (~> 4.29)
+ rake (>= 13)
+ slim (5.2.1)
+ temple (~> 0.10.0)
+ tilt (>= 2.1.0)
+ temple (0.10.3)
+ terminal-table (3.0.2)
+ unicode-display_width (>= 1.1.1, < 3)
+ thread_safe (0.3.6)
+ tilt (2.3.0)
+ tzinfo (2.0.6)
+ concurrent-ruby (~> 1.0)
+ tzinfo-data (1.2025.2)
+ tzinfo (>= 1.0.0)
+ unicode-display_width (2.6.0)
+ wdm (0.2.0)
+ webrick (1.9.1)
+
+PLATFORMS
+ ruby
+
+DEPENDENCIES
+ asciidoctor
+ asciidoctor-tabs (>= 1.0.0.beta.6)
+ jekyll (~> 4.4.1)
+ jekyll-asciidoc
+ jekyll-feed (~> 0.17)
+ minima (~> 2.5)
+ nokogiri (~> 1.18)
+ slim (~> 5.2.1)
+ thread_safe (~> 0.3.5)
+ tzinfo (~> 2.0)
+ tzinfo-data
+ wdm (~> 0.2.0)
+
+BUNDLED WITH
+ 2.3.22
diff --git a/LICENCE.md b/LICENCE.md
deleted file mode 100644
index 24d47f39ca..0000000000
--- a/LICENCE.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Licence
-
-Unless otherwise specified, everything in this repository is covered by the following licence:
-
-[](http://creativecommons.org/licenses/by-sa/4.0/)
-
-***Raspberry Pi Documentation*** by the [Raspberry Pi Foundation](https://www.raspberrypi.org/) is licensed under a [Creative Commons Attribution 4.0 International Licence](http://creativecommons.org/licenses/by-sa/4.0/).
-
-Based on a work at https://github.com/raspberrypi/documentation
diff --git a/LICENSE.md b/LICENSE.md
new file mode 100644
index 0000000000..4b2db9cd3d
--- /dev/null
+++ b/LICENSE.md
@@ -0,0 +1,175 @@
+# Licence
+
+The Raspberry Pi documentation is licensed under a [Creative Commons Attribution 4.0 International Licence](http://creativecommons.org/licenses/by-sa/4.0/).
+
+# Creative Commons Attribution-ShareAlike 4.0 International
+
+Creative Commons Corporation ("Creative Commons") is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an "as-is" basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible.
+
+### Using Creative Commons Public Licenses
+
+Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses.
+
+* __Considerations for licensors:__ Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. [More considerations for licensors](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensors).
+
+* __Considerations for the public:__ By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor's permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described. Although not required by our licenses, you are encouraged to respect those requests where reasonable. [More considerations for the public](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensees).
+
+## Creative Commons Attribution-ShareAlike 4.0 International Public License
+
+By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions.
+
+### Section 1 – Definitions.
+
+a. __Adapted Material__ means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image.
+
+b. __Adapter's License__ means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License.
+
+c. __BY-SA Compatible License__ means a license listed at [creativecommons.org/compatiblelicenses](http://creativecommons.org/compatiblelicenses), approved by Creative Commons as essentially the equivalent of this Public License.
+
+d. __Copyright and Similar Rights__ means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights.
+
+e. __Effective Technological Measures__ means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements.
+
+f. __Exceptions and Limitations__ means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material.
+
+g. __License Elements__ means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike.
+
+h. __Licensed Material__ means the artistic or literary work, database, or other material to which the Licensor applied this Public License.
+
+i. __Licensed Rights__ means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license.
+
+j. __Licensor__ means the individual(s) or entity(ies) granting rights under this Public License.
+
+k. __Share__ means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them.
+
+l. __Sui Generis Database Rights__ means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world.
+
+m. __You__ means the individual or entity exercising the Licensed Rights under this Public License. __Your__ has a corresponding meaning.
+
+### Section 2 – Scope.
+
+a. ___License grant.___
+
+ 1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to:
+
+ A. reproduce and Share the Licensed Material, in whole or in part; and
+
+ B. produce, reproduce, and Share Adapted Material.
+
+ 2. __Exceptions and Limitations.__ For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions.
+
+ 3. __Term.__ The term of this Public License is specified in Section 6(a).
+
+ 4. __Media and formats; technical modifications allowed.__ The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material.
+
+ 5. __Downstream recipients.__
+
+ A. __Offer from the Licensor – Licensed Material.__ Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License.
+
+ B. __Additional offer from the Licensor – Adapted Material.__ Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter's License You apply.
+
+ C. __No downstream restrictions.__ You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material.
+
+ 6. __No endorsement.__ Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i).
+
+b. ___Other rights.___
+
+ 1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise.
+
+ 2. Patent and trademark rights are not licensed under this Public License.
+
+ 3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties.
+
+### Section 3 – License Conditions.
+
+Your exercise of the Licensed Rights is expressly made subject to the following conditions.
+
+a. ___Attribution.___
+
+ 1. If You Share the Licensed Material (including in modified form), You must:
+
+ A. retain the following if it is supplied by the Licensor with the Licensed Material:
+
+ i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated);
+
+ ii. a copyright notice;
+
+ iii. a notice that refers to this Public License;
+
+ iv. a notice that refers to the disclaimer of warranties;
+
+ v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable;
+
+ B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and
+
+ C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License.
+
+ 2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information.
+
+ 3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable.
+
+b. ___ShareAlike.___
+
+In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply.
+
+1. The Adapter's License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License.
+
+2. You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material.
+
+3. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply.
+
+### Section 4 – Sui Generis Database Rights.
+
+Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material:
+
+a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database;
+
+b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and
+
+c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database.
+
+For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights.
+
+### Section 5 – Disclaimer of Warranties and Limitation of Liability.
+
+a. __Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.__
+
+b. __To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.__
+
+c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability.
+
+### Section 6 – Term and Termination.
+
+a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically.
+
+b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates:
+
+ 1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or
+
+ 2. upon express reinstatement by the Licensor.
+
+ For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License.
+
+c. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License.
+
+d. Sections 1, 5, 6, 7, and 8 survive termination of this Public License.
+
+### Section 7 – Other Terms and Conditions.
+
+a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed.
+
+b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License.
+
+### Section 8 – Interpretation.
+
+a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License.
+
+b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions.
+
+c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor.
+
+d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority.
+
+> Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the "Licensor." The text of the Creative Commons public licenses is dedicated to the public domain under the [CC0 Public Domain Dedication](https://creativecommons.org/publicdomain/zero/1.0/legalcode). Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at [creativecommons.org/policies](http://creativecommons.org/policies), Creative Commons does not authorize the use of the trademark "Creative Commons" or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses.
+>
+> Creative Commons may be contacted at creativecommons.org.
\ No newline at end of file
diff --git a/Makefile b/Makefile
new file mode 100644
index 0000000000..711219f453
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,125 @@
+# The top-level Makefile which builds everything
+
+ASCIIDOC_DIR = documentation/asciidoc
+HTML_DIR = documentation/html
+IMAGES_DIR = documentation/images
+JEKYLL_ASSETS_DIR = jekyll-assets
+SCRIPTS_DIR = scripts
+DOCUMENTATION_REDIRECTS_DIR = documentation/redirects
+DOCUMENTATION_INDEX = documentation/index.json
+SITE_CONFIG = _config.yml
+
+BUILD_DIR = build
+ASCIIDOC_BUILD_DIR = $(BUILD_DIR)/jekyll
+ASCIIDOC_INCLUDES_DIR = $(BUILD_DIR)/adoc_includes
+AUTO_NINJABUILD = $(BUILD_DIR)/autogenerated.ninja
+
+PICO_SDK_DIR = lib/pico-sdk
+PICO_EXAMPLES_DIR = lib/pico-examples
+DOXYGEN_TO_ASCIIDOC_DIR = lib/doxygentoasciidoc
+ALL_SUBMODULE_CMAKELISTS = $(PICO_SDK_DIR)/CMakeLists.txt $(PICO_EXAMPLES_DIR)/CMakeLists.txt
+DOXYGEN_PICO_SDK_BUILD_DIR = build-pico-sdk-docs
+DOXYGEN_XML_DIR = $(DOXYGEN_PICO_SDK_BUILD_DIR)/combined/docs/doxygen/xml
+# The pico-sdk here needs to match up with the "from_json" entry in index.json
+ASCIIDOC_DOXYGEN_DIR = $(ASCIIDOC_DIR)/pico-sdk
+
+JEKYLL_CMD = bundle exec jekyll
+
+.DEFAULT_GOAL := html
+
+.PHONY: clean run_ninja clean_ninja html serve_html clean_html build_doxygen_xml clean_doxygen_xml build_doxygen_adoc clean_doxygen_adoc fetch_submodules clean_submodules clean_everything
+
+$(BUILD_DIR):
+ @mkdir -p $@
+
+$(DOXYGEN_PICO_SDK_BUILD_DIR):
+ mkdir $@
+
+$(ASCIIDOC_DOXYGEN_DIR): | $(ASCIIDOC_DIR)
+ mkdir $@
+
+# Delete all autogenerated files
+clean: clean_html clean_doxygen_adoc
+ rm -rf $(BUILD_DIR)
+
+# Initialise pico-sdk submodule (and the subnmodules that it uses)
+$(PICO_SDK_DIR)/CMakeLists.txt $(PICO_SDK_DIR)/docs/index.h: | $(PICO_SDK_DIR)
+ git submodule update --init $(PICO_SDK_DIR)
+ git -C $(PICO_SDK_DIR) submodule update --init
+
+# Initialise pico-examples submodule
+$(PICO_EXAMPLES_DIR)/CMakeLists.txt: | $(PICO_SDK_DIR)/CMakeLists.txt $(PICO_EXAMPLES_DIR)
+ git submodule update --init $(PICO_EXAMPLES_DIR)
+
+# Initialise doxygentoasciidoc submodule
+$(DOXYGEN_TO_ASCIIDOC_DIR)/__main__.py:
+ git submodule update --init $(DOXYGEN_TO_ASCIIDOC_DIR)
+
+fetch_submodules: $(ALL_SUBMODULE_CMAKELISTS) $(DOXYGEN_TO_ASCIIDOC_DIR)/__main__.py
+
+# Get rid of the submodules
+clean_submodules:
+ git submodule deinit --all
+
+# Create the pico-sdk Doxygen XML files
+$(DOXYGEN_XML_DIR) $(DOXYGEN_XML_DIR)/index.xml: | $(ALL_SUBMODULE_CMAKELISTS) $(DOXYGEN_PICO_SDK_BUILD_DIR)
+ cmake -S $(PICO_SDK_DIR) -B $(DOXYGEN_PICO_SDK_BUILD_DIR)/combined -D PICO_EXAMPLES_PATH=../../$(PICO_EXAMPLES_DIR) -D PICO_NO_PICOTOOL=1 -D PICO_PLATFORM=combined-docs
+ cmake -S $(PICO_SDK_DIR) -B $(DOXYGEN_PICO_SDK_BUILD_DIR)/PICO_RP2040 -D PICO_EXAMPLES_PATH=../../$(PICO_EXAMPLES_DIR) -D PICO_NO_PICOTOOL=1 -D PICO_PLATFORM=rp2040
+ cmake -S $(PICO_SDK_DIR) -B $(DOXYGEN_PICO_SDK_BUILD_DIR)/PICO_RP2350 -D PICO_EXAMPLES_PATH=../../$(PICO_EXAMPLES_DIR) -D PICO_NO_PICOTOOL=1 -D PICO_PLATFORM=rp2350
+ $(MAKE) -C $(DOXYGEN_PICO_SDK_BUILD_DIR)/combined docs
+ $(MAKE) -C $(DOXYGEN_PICO_SDK_BUILD_DIR)/PICO_RP2040 docs
+ $(MAKE) -C $(DOXYGEN_PICO_SDK_BUILD_DIR)/PICO_RP2350 docs
+ python3 $(SCRIPTS_DIR)/postprocess_doxygen_xml.py $(DOXYGEN_PICO_SDK_BUILD_DIR)
+
+$(DOXYGEN_PICO_SDK_BUILD_DIR)/combined/docs/Doxyfile: | $(DOXYGEN_XML_DIR)
+
+build_doxygen_xml: | $(DOXYGEN_XML_DIR)
+
+# Clean all the Doxygen HTML files
+clean_doxygen_xml:
+ rm -rf $(DOXYGEN_PICO_SDK_BUILD_DIR)
+
+# create the sdk adoc and the json file
+$(ASCIIDOC_DOXYGEN_DIR)/picosdk_index.json $(ASCIIDOC_DOXYGEN_DIR)/index_doxygen.adoc: $(ASCIIDOC_DOXYGEN_DIR) $(DOXYGEN_XML_DIR)/index.xml $(DOXYGEN_TO_ASCIIDOC_DIR)/__main__.py $(DOXYGEN_TO_ASCIIDOC_DIR)/cli.py $(DOXYGEN_TO_ASCIIDOC_DIR)/nodes.py $(DOXYGEN_TO_ASCIIDOC_DIR)/helpers.py | $(BUILD_DIR) $(DOXYGEN_TO_ASCIIDOC_DIR)/requirements.txt
+ $(MAKE) clean_ninja
+ pip3 install -r $(DOXYGEN_TO_ASCIIDOC_DIR)/requirements.txt
+ PYTHONPATH=$(DOXYGEN_TO_ASCIIDOC_DIR)/.. python3 -m doxygentoasciidoc -o $(ASCIIDOC_DOXYGEN_DIR)/all_groups.adoc $(DOXYGEN_XML_DIR)/index.xml
+ PYTHONPATH=$(DOXYGEN_TO_ASCIIDOC_DIR)/.. python3 -m doxygentoasciidoc -c -o $(ASCIIDOC_DOXYGEN_DIR)/index_doxygen.adoc $(DOXYGEN_XML_DIR)/indexpage.xml
+ PYTHONPATH=$(DOXYGEN_TO_ASCIIDOC_DIR)/.. python3 -m doxygentoasciidoc -c -o $(ASCIIDOC_DOXYGEN_DIR)/examples_page.adoc $(DOXYGEN_XML_DIR)/examples_page.xml
+ python3 $(SCRIPTS_DIR)/postprocess_doxygen_adoc.py $(ASCIIDOC_DOXYGEN_DIR)
+ -cp $(DOXYGEN_XML_DIR)/*.png $(ASCIIDOC_DOXYGEN_DIR) 2>/dev/null || true
+
+build_doxygen_adoc: $(ASCIIDOC_DOXYGEN_DIR)/index_doxygen.adoc
+
+# Clean all the Doxygen asciidoc files
+clean_doxygen_adoc:
+ if [ -d $(ASCIIDOC_DOXYGEN_DIR) ]; then $(MAKE) clean_ninja; fi
+ rm -rf $(ASCIIDOC_DOXYGEN_DIR)
+
+clean_everything: clean_submodules clean_doxygen_xml clean
+
+# AUTO_NINJABUILD contains all the parts of the ninjabuild where the rules themselves depend on other files
+$(AUTO_NINJABUILD): $(SCRIPTS_DIR)/create_auto_ninjabuild.py $(DOCUMENTATION_INDEX) $(SITE_CONFIG) | $(BUILD_DIR)
+ $< $(DOCUMENTATION_INDEX) $(SITE_CONFIG) $(ASCIIDOC_DIR) $(SCRIPTS_DIR) $(ASCIIDOC_BUILD_DIR) $(ASCIIDOC_INCLUDES_DIR) $(JEKYLL_ASSETS_DIR) $(DOXYGEN_PICO_SDK_BUILD_DIR) $(DOCUMENTATION_REDIRECTS_DIR) $(IMAGES_DIR) $@
+
+# This runs ninjabuild to build everything in the ASCIIDOC_BUILD_DIR (and ASCIIDOC_INCLUDES_DIR)
+run_ninja: $(AUTO_NINJABUILD)
+ ninja
+
+# Delete all the files created by the 'run_ninja' target
+clean_ninja:
+ rm -rf $(ASCIIDOC_BUILD_DIR)
+ rm -rf $(ASCIIDOC_INCLUDES_DIR)
+ rm -f $(AUTO_NINJABUILD)
+
+# Build the html output files
+html: run_ninja
+ $(JEKYLL_CMD) build
+
+# Build the html output files and additionally run a small webserver for local previews
+serve_html: run_ninja
+ $(JEKYLL_CMD) serve --watch
+
+# Delete all the files created by the 'html' target
+clean_html:
+ rm -rf $(HTML_DIR)
diff --git a/README.md b/README.md
index 3ce1d12985..69df3a28f8 100644
--- a/README.md
+++ b/README.md
@@ -1,44 +1,22 @@
-# Raspberry Pi Documentation
+
+
+
+
+
+
-This is the official documentation for the Raspberry Pi, written by the [Raspberry Pi Foundation](https://www.raspberrypi.org/) with community contributions.
+[Website][Raspberry Pi] | [Getting started] | [Documentation] | [Contribute]
+
-## Contents
+This repository contains the source and tools used to build the [Raspberry Pi Documentation](https://www.raspberrypi.com/documentation/).
-- [Setup / Quickstart](setup/README.md)
- - Getting started with your Raspberry Pi, including what you need and how to get it booted
-- [Installation](installation/README.md)
- - Installing an operating system on your Raspberry Pi
-- [Usage Guide](usage/README.md)
- - Explore the desktop and try out all the main applications
-- [Configuration](configuration/README.md)
- - Configuring the Pi's settings to suit your needs
-- [Remote Access](remote-access/README.md)
- - Accessing your Pi remotely via SSH, VNC or over the web
-- [Linux](linux/README.md)
- - Fundamental Linux usage for beginners and more advanced information for power users
-- [Raspberry Pi OS](raspbian/README.md)
- - Information about the recommended operating system for Raspberry Pi
-- [Hardware](hardware/README.md)
- - Technical specifications about the Raspberry Pi hardware and the camera module
-
-## General Documentation Help
-
-In addition to the topics above, we have a set of [Frequently Asked Questions](faqs/README.md), and a [Glossary](glossary/README.md) to help with any technical terms you may encounter in our documentation.
-
-## Contributions
-
-If you have anything to fix or details to add, first [file an issue](https://github.com/raspberrypi/documentation/issues) on GitHub to see if it is likely to be accepted, then file a pull request with your change (one PR per issue).
-
-This is not intended to be an open wiki; we want to keep it concise and minimal but will accept fixes and suitable additions.
-
-See our [contributing policy](CONTRIBUTING.md).
+[Raspberry Pi]: https://www.raspberrypi.com/
+[Getting Started]: https://www.raspberrypi.com/documentation/computers/getting-started.html
+[Documentation]: https://www.raspberrypi.com/documentation/
+[Contribute]: CONTRIBUTING.md
## Licence
-Unless otherwise specified, everything in this repository is covered by the following licence:
-
-[](https://creativecommons.org/licenses/by-sa/4.0/)
-
-***Raspberry Pi Documentation*** by the [Raspberry Pi Foundation](https://www.raspberrypi.org/) is licensed under a [Creative Commons Attribution 4.0 International Licence](https://creativecommons.org/licenses/by-sa/4.0/).
-
-Based on a work at https://github.com/raspberrypi/documentation
+The Raspberry Pi documentation is [licensed](https://github.com/raspberrypi/documentation/blob/develop/LICENSE.md) under a Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA). Documentation tools (everything outside of the `documentation/` subdirectory) are licensed under the [BSD 3-Clause](https://opensource.org/licenses/BSD-3-Clause) licence.
diff --git a/_config.yml b/_config.yml
new file mode 100644
index 0000000000..4d740515b5
--- /dev/null
+++ b/_config.yml
@@ -0,0 +1,56 @@
+# Welcome to Jekyll!
+#
+# This config file is meant for settings that affect your whole blog, values
+# which you are expected to set up once and rarely edit after that. If you find
+# yourself editing this file very often, consider using Jekyll's data files
+# feature for the data you need to update frequently.
+#
+# For technical reasons, this file is *NOT* reloaded automatically when you use
+# 'bundle exec jekyll serve'. If you change this file, please restart the server process.
+
+# Site settings
+# These are used to personalize your new site. If you look in the HTML files,
+# you will see them accessed via {{ site.title }}, {{ site.email }}, and so on.
+# You can create any custom variable you would like, and they will be accessible
+# in the templates via {{ site.myvariable }}.
+title: Raspberry Pi Documentation
+description: >- # this means to ignore newlines until "baseurl:"
+ Raspberry Pi Documentation.
+baseurl: "/documentation" # the subpath of your site, e.g. /blog
+url: "https://www.raspberrypi.com/documentation" # the base hostname & protocol for your site, e.g. http://example.com
+githuburl: "https://github.com/raspberrypi/documentation/"
+mainsite: https://raspberrypi.com/
+githubbranch: master
+githubbranch_edit: develop
+
+# Build settings
+theme: minima
+plugins:
+ - asciidoctor-tabs
+ - jekyll-asciidoc
+ - jekyll-feed
+
+# this corresponds to ASCIIDOC_BUILD_DIR in Makefile
+source: build/jekyll
+
+# this corresponds to HTML_DIR in Makefile
+destination: documentation/html
+
+sass:
+ sass_dir: css
+ quiet_deps: true
+
+asciidoctor:
+ template_dir: build/jekyll/_templates
+
+# Exclude from processing.
+# The following items will not be processed, by default. Create a custom list
+# to override the default setting.
+# exclude:
+# - Gemfile
+# - Gemfile.lock
+# - node_modules
+# - vendor/bundle/
+# - vendor/cache/
+# - vendor/gems/
+# - vendor/ruby/
diff --git a/build.ninja b/build.ninja
new file mode 100644
index 0000000000..56acd19aef
--- /dev/null
+++ b/build.ninja
@@ -0,0 +1,52 @@
+# All the static (non-changing) parts of the ninjabuild
+
+# These uppercase variables are used in autogenerated.ninja
+DOCUMENTATION_IMAGES_DIR = documentation/images
+GITHUB_EDIT_TEMPLATE = jekyll-assets/_includes/github_edit.adoc
+HTACCESS_EXTRA = documentation/htaccess_extra.txt
+DOXYGEN_PICOSDK_INDEX_JSON = documentation/asciidoc/pico-sdk/picosdk_index.json
+
+# this corresponds to BUILD_DIR in Makefile
+builddir = build
+
+rule copy
+ command = cp $in $out
+
+rule create_categories_page
+ command = echo "---\nlayout: boxes\n---\n:doctitle: $title" > $out
+
+rule create_toc
+ command = $scripts_dir/create_nav.py $in $src_dir $out
+
+rule create_output_supplemental_data
+ command = $scripts_dir/create_output_supplemental_data.py $in $out
+
+rule create_build_adoc
+ command = $scripts_dir/create_build_adoc.py $documentation_index $site_config $GITHUB_EDIT_TEMPLATE $in $inc_dir $out
+
+rule create_build_adoc_doxygen
+ command = $scripts_dir/create_build_adoc_doxygen.py $documentation_index $site_config $in $DOXYGEN_PICOSDK_INDEX_JSON $out_dir $out
+
+rule create_build_adoc_include
+ command = $scripts_dir/create_build_adoc_include.py $site_config $GITHUB_EDIT_TEMPLATE $in $out
+
+rule create_htaccess
+ command = $scripts_dir/create_htaccess.py $in $redirects_dir $out
+
+rule create_index_json
+ command = $scripts_dir/create_output_index_json.py $in $out $src_dir $DOCUMENTATION_IMAGES_DIR
+
+rule create_edit_warning
+ command = echo "Do not edit any files in this directory. Everything will get overwritten when you run 'make'" > $out
+
+# created (as AUTO_NINJABUILD) in Makefile before invoking ninja
+include $builddir/autogenerated.ninja
+
+build $out_dir/_data/index.json: create_index_json $documentation_index | $scripts_dir/create_output_index_json.py
+default $out_dir/_data/index.json
+
+build $out_dir/images/opensocial.png: copy $DOCUMENTATION_IMAGES_DIR/opensocial.png
+default $out_dir/images/opensocial.png
+
+build $out_dir/DO_NOT_EDIT.txt: create_edit_warning
+default $out_dir/DO_NOT_EDIT.txt
diff --git a/configuration/README.md b/configuration/README.md
deleted file mode 100644
index 0d7600c4cf..0000000000
--- a/configuration/README.md
+++ /dev/null
@@ -1,50 +0,0 @@
-# Configuration
-
-Some basic guides to configuring your Raspberry Pi.
-
-## Contents
-
-- [raspi-config](raspi-config.md)
- - The Raspberry Pi configuration tool in Raspberry Pi OS, which allows you to easily enable features such as the camera, and to change your specific settings such as keyboard layout
-- [config.txt](config-txt/README.md)
- - The Raspberry Pi configuration file
-- [TCP/IP networking](tcpip/README.md)
- - Configuring the TCP/IP network stack on the Raspberry Pi
-- [Connect to a wireless network](wireless/README.md)
- - Configuring your Pi to connect to a wireless network using the Raspberry Pi 4, Raspberry Pi 3 or Pi Zero W's inbuilt wireless connectivity, or a USB wireless dongle
-- [Wireless access point](wireless/access-point-routed.md)
- - Configuring your Pi as a wireless access point using the Raspberry Pi 4, Raspberry Pi 3, or Raspberry Pi Zero W's inbuilt wireless connectivity, or a USB wireless dongle
-- [Using a proxy](use-a-proxy.md)
- - Setting up your Pi to access the internet via a proxy server
-- [HDMI Config](hdmi-config.md)
- - Setting up your HDMI device, including custom settings
-- [Screen Configuration Editor](arandr.md)
- - Setting up your display device's resolution, frequency and orientation using the provided graphical editor
-- [Audio config](audio-config.md)
- - Switching your audio output between HDMI and the 3.5mm jack
-- [Camera config](camera.md)
- - Installing and setting up the Raspberry Pi camera board
-- [External storage config](external-storage.md)
- - Mounting and setting up external storage on a Raspberry Pi
-- [Localisation](localisation.md)
- - Setting up your Pi to work in your local language and time zone
-- [Default pin configuration](pin-configuration.md)
- - Changing the default pin states.
-- [Device Trees config](device-tree.md)
- - Device Trees, overlays, and parameters
-- [Kernel command line](cmdline-txt.md)
- - Setting options in the kernel command line
-- [UART configuration](uart.md)
- - Setting up the on-board UARTs
-- [Firmware warning icons](warning-icons.md)
- - Description of warning icons displayed if the firmware detects issues
-- [LED warning flash codes](led_blink_warnings.md)
- - Description of LED warning flashes that are shown if a Pi fails to boot or has to shut down
-- [Securing your Raspberry Pi](security.md)
- - Some basic advice for making your Raspberry Pi more secure
-- [Screensaver](screensaver.md)
- - Configuring the screen saver and screen blanking
-- [The boot folder](boot_folder.md)
- - What it's for and what's in it
-- [Network File System (NFS)](nfs.md)
- - How to set up a NFS and connect clients to it
diff --git a/configuration/arandr.md b/configuration/arandr.md
deleted file mode 100644
index ce532c89ce..0000000000
--- a/configuration/arandr.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# Screen Configuration
-
-The Screen Configuration tool (`arandr` on the command line) is a graphical tool for selecting display modes and setting up multiple displays.
-
-You can find this tool in the desktop Preferences menu, but only if the 3D graphics driver is being used, as it is this driver that provides the required mode setting functionality.
-
-On the whole, the editor is self-explanatory: use the Configure menu option to select the screen, resolution, and orientation. If you're using a multi-screen setup, drag around the displays to any position you want. When you have the required setup, click the Tick button to apply the settings.
diff --git a/configuration/audio-config.md b/configuration/audio-config.md
deleted file mode 100644
index 78cafdae51..0000000000
--- a/configuration/audio-config.md
+++ /dev/null
@@ -1,36 +0,0 @@
-# Audio configuration
-
-The Raspberry Pi has up to three audio output modes: HDMI 1 and 2, if present, and a headphone jack. You can switch between these modes at any time.
-
-If your HDMI monitor or TV has built-in speakers, the audio can be played over the HDMI cable, but you can switch it to a set of headphones or other speakers plugged into the headphone jack. If your display claims to have speakers, sound is output via HDMI by default; if not, it is output via the headphone jack. This may not be the desired output setup, or the auto-detection is inaccurate, in which case you can manually switch the output.
-
-## Changing the audio output
-
-There are two ways of setting the audio output.
-
-### Desktop volume control
-
-Right-clicking the volume icon on the desktop taskbar brings up the audio output selector; this allows you to select between the internal audio outputs. It also allows you to select any external audio devices, such as USB sound cards and Bluetooth audio devices. A green tick is shown against the currently selected audio output device — simply left-click the desired output in the pop-up menu to change this. The volume control and mute operate on the currently selected device.
-
-### raspi-config
-
-Open up [raspi-config](raspi-config.md) by entering the following into the command line:
-
-```
-sudo raspi-config
-```
-
-This will open the configuration screen:
-
-Select `System Options` (Currently option 1, but yours may be different) and press `Enter`.
-
-Now select the Option named, `Audio` (Currently option S2, but yours may be different) and press `Enter`:
-
-Select your required mode, press `Enter` and press the right arrow key to exit the options list, then select `Finish` to exit the configuration tool.
-
-After you have finished modifying your audio settings, you need to restart your Raspberry Pi in order for your changes to take effect.
-
-
-## If you're still not getting sound via HDMI
-
-In some rare cases, it is necessary to edit `config.txt` to force HDMI mode (as opposed to DVI mode, which does not send sound). You can do this by editing `/boot/config.txt` and setting `hdmi_drive=2`, then rebooting for the change to take effect.
diff --git a/configuration/boot_folder.md b/configuration/boot_folder.md
deleted file mode 100644
index aa54a625ba..0000000000
--- a/configuration/boot_folder.md
+++ /dev/null
@@ -1,67 +0,0 @@
-# The boot folder
-
-In a basic [Raspberry Pi OS](../raspbian/README.md) install, the boot files are stored on the first partition of the SD card, which is formatted with the FAT file system. This means that it can be read on Windows, macOS, and Linux devices.
-
-When the Raspberry Pi is powered on, it loads various files from the boot partition/folder in order to start up the various processors, then it boots the Linux kernel.
-
-Once Linux has booted, the boot partition is mounted as `/boot`.
-
-## Boot folder contents
-
-### bootcode.bin
-
-This is the bootloader, which is loaded by the SoC on boot, does some very basic setup, and then loads one of the `start*.elf` files. `bootcode.bin` is not used on the Raspberry Pi 4, because it has been replaced by boot code in the [onboard EEPROM](../hardware/raspberrypi/booteeprom.md).
-
-### start.elf, start_x.elf, start_db.elf, start_cd.elf, start4.elf, start4x.elf, start4cd.elf, start4db.elf
-
-These are binary blobs (firmware) that are loaded on to the VideoCore in the SoC, which then take over the boot process.
-`start.elf` is the basic firmware, `start_x.elf` includes camera drivers and codec, `start_db.elf` is a debug version of the firmware, and `start_cd.elf` is a cut-down version with no support hardware blocks like codecs and 3D, and for use when `gpu_mem=16` is specified in `config.txt`. More information on how to use these can be found in [the `config.txt` section](./config-txt/boot.md).
-
-`start4.elf`, `start4x.elf`, `start4cd.elf`, and `start4db.elf` are firmware files specific to the Pi 4.
-
-### fixup*.dat
-
-These are linker files and are matched pairs with the `start*.elf` files listed in the previous section.
-
-### cmdline.txt
-
-The kernel command line passed in to the kernel when it boots.
-
-### config.txt
-
-Contains many configuration parameters for setting up the Pi. See [the `config.txt` section](./config-txt/README.md).
-
-### issue.txt
-
-Some text-based housekeeping information containing the date and git commit ID of the distribution.
-
-### ssh or ssh.txt
-
-When this file is present, SSH will be enabled on boot. The contents don't matter, it can be empty. SSH is otherwise disabled by default.
-
-### wpa_supplicant.conf
-
-This is the file to configure wireless network settings (if the hardware is capable of it). Edit the country code and the network part to fit your case. More information on how to use this file can be found in [the `wireless/headless` section](./wireless/headless.md).
-
-### Device Tree files
-
-There are various Device Tree blob files, which have the extension `.dtb`. These contain the hardware definitions of the various models of Raspberry Pi, and are used on boot to set up the kernel according to which Pi model is detected. More [details here](device-tree.md#part3.1).
-
-### Kernel Files
-
-The boot folder will contain various [kernel](../linux/kernel/README.md) image files, used for the different Raspberry Pi models:
-
-| Filename | Processor | Raspberry Pi model | Notes |
-| ---------| ----------|-----------------|-------|
-| kernel.img | BCM2835 | Pi Zero, Pi 1 | |
-| kernel7.img| BCM2836, BCM2837 | Pi 2, Pi 3 | Later Pi 2 uses the BCM2837 |
-| kernel7l.img | BCM2711 | Pi 4 | Large Physical Address Extension (LPAE)|
-| kernel8.img | BCM2837, BCM2711 | Pi 2, Pi 3, Pi 4 | Beta 64 bit kernel1. Earlier Pi 2 with BCM2836 do not support 64-bit. |
-
-1 Information on booting a 64-bit kernel can be found [here](config-txt/boot.md).
-
-Note: The architecture reported by `lscpu` is `armv7l` for 32-bit systems (i.e. everything except kernel8.img), and `aarch64` for 64-bit systems. The `l` in the `armv7l` case refers to the architecture being little-endian, not `LPAE` as is indicated by the `l` in the `kernel7l.img` filename.
-
-## Device Tree overlays
-
-The `overlays` sub-folder contains Device Tree overlays. These are used to configure various hardware devices that may be attached to the system, for example the Raspberry Pi Touch Display or third-party sound boards. These overlays are selected using entries in `config.txt` — see ['Device Trees, overlays and parameters, part 2' for more info](device-tree.md#part2).
diff --git a/configuration/camera.md b/configuration/camera.md
deleted file mode 100644
index 7b19977b8e..0000000000
--- a/configuration/camera.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# Camera configuration
-
-## Setting up the camera hardware
-
-**Warning**: Cameras are sensitive to static. Earth yourself prior to handling the PCB. A sink tap or similar should suffice if you don’t have an earthing strap.
-
-The camera board attaches to the Raspberry Pi via a 15-way ribbon cable. There are only two connections to make: the ribbon cable needs to be attached to the camera PCB, and to the Raspberry Pi itself. You need to get the cable the right way round, or the camera will not work. On the camera PCB, the blue backing on the cable should face away from the PCB, and on the Raspberry Pi it should face towards the Ethernet connection (or where the Ethernet connector would be if you're using a model A).
-
-Although the connectors on the PCB and the Pi are different, they work in a similar way. On the Raspberry Pi itself, pull up the tabs on each end of the connector. It should slide up easily, and be able to pivot around slightly. Fully insert the ribbon cable into the slot, ensuring it is set straight, then gently press down the tabs to clip it into place. The camera PCB connector also requires you to pull the tabs away from the board, gently insert the cable, then push the tabs back. The PCB connector can be a little more awkward than the one on the Pi itself.
-
-## Setting up the camera software
-
-Execute the following instructions on the command line to download and install the latest kernel, GPU firmware, and applications. You'll need an internet connection for this to work correctly.
-
-```bash
-sudo apt update
-sudo apt full-upgrade
-```
-
-Now you need to enable camera support using the `raspi-config` program you will have used when you first set up your Raspberry Pi.
-
-```bash
-sudo raspi-config
-```
-
-Use the cursor keys to select and open *Interfacing Options*, and then select *Camera* and follow the prompt to enable the camera.
-
-Upon exiting `raspi-config`, it will ask to reboot. The enable option will ensure that on reboot the correct GPU firmware will be running with the camera driver and tuning, and the GPU memory split is sufficient to allow the camera to acquire enough memory to run correctly.
-
-To test that the system is installed and working, try the following command:
-
-```bash
-raspistill -v -o test.jpg
-```
-
-The display should show a five-second preview from the camera and then take a picture, saved to the file `test.jpg`, whilst displaying various informational messages.
-
-## More Information
-
-See [Camera Software](../raspbian/applications/camera.md).
diff --git a/configuration/cmdline-txt.md b/configuration/cmdline-txt.md
deleted file mode 100644
index 9733a241b9..0000000000
--- a/configuration/cmdline-txt.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# The Kernel Command Line
-
-The Linux kernel accepts a command line of parameters during boot. On the Raspberry Pi, this command line is defined in a file in the boot partition, called cmdline.txt. This is a simple text file that can be edited using any text editor, e.g. Nano.
-```
-sudo nano /boot/cmdline.txt
-```
-Note that we have to use `sudo` to edit anything in the boot partition, and that all parameters in `cmdline.txt` must be on the same line (no carriage returns).
-
-The command line that was passed to the kernel at boot time can be displayed using `cat /proc/cmdline`. It will not be exactly the same as that in `cmdline.txt` as the firmware can make changes to it prior to launching the kernel.
-
-## Command Line Options
-
-There are many kernel command line parameters, some of which are defined by the kernel. Others are defined by code that the kernel may be using, such as the Plymouth splash screen system.
-
-#### Standard Entries
-
- - 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 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 suppresses all but very serious log messages during boot.
-
-#### Display Entries in FKMS and KMS modes
-
-The firmware automatically adds a preferred resolution and overscan settings via an entry such as:
-
-```video=HDMI-A-1:1920x1080M@60,margin_left=0,margin_right=0,margin_top=0,margin_bottom=0```
-
-This default entry can be modified by duplicating the entry above manually in /boot/cmdline.txt and making required changes to the margin parameters. In addition, it is possible to add rotation and reflect parameters as documented in the standard [Linux framebuffer documentation](https://github.com/raspberrypi/linux/blob/rpi-5.4.y/Documentation/fb/modedb.rst). By default the `margin_*` options are set from the `overscan` entries in config.txt, if present. The firmware can be prevented from making any KMS specific changes to the command line by adding `disable_fw_kms_setup=1` to `config.txt`
-
-An example entry may be as follows:
-
-```video=HDMI-A-1:1920x1080M@60,margin_left=0,margin_right=0,margin_top=0,margin_bottom=0,rotate=90,reflect_x```
-
-Possible options for the display type, the first part of the `video=` entry, are as follows:
-
-| video option | Display |
-|:---:|:---|
-| HDMI-A-1 | HDMI 1 (HDMI 0 on silkscreen of Pi4B, HDMI on single HDMI boards) |
-| HDMI-A-2 | HDMI 2 (HDMI 1 on silkscreen of Pi4B) |
-| DSI-1 | DSI or DPI |
-| Composite-1 | Composite |
-
-#### Other Entries (not exhaustive)
-
- - splash: tells the boot to use a splash screen via the Plymouth module.
- - plymouth.ignore-serial-consoles: normally if the Plymouth module is enabled it will prevent boot messages from appearing on any serial console which may be present. This flag tells Plymouth to ignore all serial consoles, making boot messages visible again, as they would be if Plymouth was not running.
- - dwc_otg.lpm_enable: turns off Link Power Management (LPM) in the dwc_otg driver; the dwc_otg driver is the driver for the USB controller built into the Raspberry Pi.
- - dwc_otg.speed: sets the speed of the USB controller. `dwc_otg.speed=1` will set it to full speed (USB 1.0), which is slower than high speed (USB 2.0). This option should not be set except during troubleshooting of problems with USB devices.
- - smsc95xx.turbo_mode: enables/disables the wired networking driver turbo mode. `smsc95xx.turbo_mode=N` turns turbo mode off.
- - usbhid.mousepoll: specifies the mouse polling interval. If you have problems with a slow or erratic wireless mouse, setting this to 0 might help: `usbhid.mousepoll=0`.
-
diff --git a/configuration/config-txt.md b/configuration/config-txt.md
deleted file mode 100644
index ff3c4c8f92..0000000000
--- a/configuration/config-txt.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# config.txt
-
-This file has moved to [config-txt/README.md](config-txt/README.md)
diff --git a/configuration/config-txt/README.md b/configuration/config-txt/README.md
deleted file mode 100644
index 3c80d55448..0000000000
--- a/configuration/config-txt/README.md
+++ /dev/null
@@ -1,56 +0,0 @@
-# config.txt
-
-The Raspberry Pi uses a configuration file instead of the [BIOS](https://en.wikipedia.org/wiki/BIOS) you would expect to find on a conventional PC. The system configuration parameters, which would traditionally be edited and stored using a BIOS, are stored instead in an optional text file named `config.txt`. This is read by the GPU before the ARM CPU and Linux are initialised. It must therefore be located on the first (boot) partition of your SD card, alongside `bootcode.bin` and `start.elf`. This file is normally accessible as `/boot/config.txt` from Linux, and must be edited as [root](../../linux/usage/root.md). From Windows or OS X it is visible as a file in the only accessible part of the card. If you need to apply some of the config settings below, but you don't have a `config.txt` on your boot partition yet, simply create it as a new text file.
-
-Any changes will only take effect after you have rebooted your Raspberry Pi. After Linux has booted, you can view the current active settings using the following commands:
-
-- `vcgencmd get_config `: this displays a specific config value, e.g. `vcgencmd get_config arm_freq`.
-
-- `vcgencmd get_config int`: this lists all the integer config options that are set (non-zero).
-
-- `vcgencmd get_config str`: this lists all the string config options that are set (non-null).
-
-Note that there are a few config settings that cannot be retrieved using `vcgencmd`.
-
-## File format
-
-The `config.txt` file is read by the early-stage boot firmware, so it has a very simple file format. The format is a single `property=value` statement on each line, where `value` is either an integer or a string. Comments may be added, or existing config values may be commented out and disabled, by starting a line with the `#` character.
-
-There is an 80 character line length limit to entries, any characters past this limit will be ignored.
-
-Here is an example file:
-
-```
-# Force the monitor to HDMI mode so that sound will be sent over HDMI cable
-hdmi_drive=2
-# Set monitor mode to DMT
-hdmi_group=2
-# Set monitor resolution to 1024x768 XGA 60Hz (HDMI_DMT_XGA_60)
-hdmi_mode=16
-# Make display smaller to stop text spilling off the screen
-overscan_left=20
-overscan_right=12
-overscan_top=10
-overscan_bottom=10
-```
-
-## config.txt Options
-
-A range of options can be specified using the config.txt file. These are split into different sections, indexed below:
-
-- [Memory](memory.md)
-- [Licence Keys/Codecs](codeclicence.md)
-- [Video/Display](video.md)
-- [Audio](audio.md)
-- [Camera](camera.md)
-- [Boot](boot.md)
-- [Ports and Device Tree](../device-tree.md#part4.6)
-- [GPIOs](gpio.md)
-- [Overclocking](overclocking.md)
-- [Conditional Filters](conditional.md)
-- [Miscellaneous](misc.md)
-
-
-
-
-*This article uses content from the eLinux wiki page [RPiconfig](http://elinux.org/RPiconfig), which is shared under the [Creative Commons Attribution-ShareAlike 3.0 Unported license](http://creativecommons.org/licenses/by-sa/3.0/)*
diff --git a/configuration/config-txt/audio.md b/configuration/config-txt/audio.md
deleted file mode 100644
index b2df27c7f5..0000000000
--- a/configuration/config-txt/audio.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# Onboard analogue audio options in config.txt (3.5mm jack)
-
-The onboard audio output uses config options to change the way the analogue audio is driven, and whether some firmware features are enabled or not.
-
-## disable_audio_dither
-
-By default, a 1.0LSB dither is applied to the audio stream if it is routed to the analogue audio output. This can create audible background "hiss" in some situations, for example when the ALSA volume is set to a low level. Set `disable_audio_dither` to `1` to disable dither application.
-
-## enable_audio_dither
-
-Audio dither (see disable_audio_dither above) is normally disabled when the audio samples are larger than 16 bits. Set this option to `1` to force the use of dithering for all bit depths.
-
-## pwm_sample_bits
-
-The `pwm_sample_bits` command adjusts the bit depth of the analogue audio output. The default bit depth is `11`. Selecting bit depths below `8` will result in nonfunctional audio, as settings below `8` result in a PLL frequency too low to support. This is generally only useful as a demonstration of how bit depth affects quantisation noise.
-
-
-
-
-*This article uses content from the eLinux wiki page [RPiconfig](http://elinux.org/RPiconfig), which is shared under the [Creative Commons Attribution-ShareAlike 3.0 Unported license](http://creativecommons.org/licenses/by-sa/3.0/)*
diff --git a/configuration/config-txt/boot.md b/configuration/config-txt/boot.md
deleted file mode 100644
index 9fb805f7fd..0000000000
--- a/configuration/config-txt/boot.md
+++ /dev/null
@@ -1,151 +0,0 @@
-# Boot options in config.txt
-
-## start_file, fixup_file
-
-These options specify the firmware files transferred to the VideoCore GPU prior to booting.
-
-`start_file` specifies the VideoCore firmware file to use.
-`fixup_file` specifies the file used to fix up memory locations used in the `start_file` to match the GPU memory split. Note that the `start_file` and the `fixup_file` are a matched pair - using unmatched files will stop the board from booting. This is an advanced option, so we advise that you use `start_x` and `start_debug` rather than this option.
-
-## start_x, start_debug
-
-These provide a shortcut to some alternative `start_file` and `fixup_file` settings, and are the recommended methods for selecting firmware configurations.
-
-`start_x=1` implies
- `start_file=start_x.elf`
- `fixup_file=fixup_x.dat`
-
- On the Pi 4, if the files `start4x.elf` and `fixup4x.dat` are present, these files will be used instead.
-
-`start_debug=1` implies
- `start_file=start_db.elf`
- `fixup_file=fixup_db.dat`
-
-There is no specific handling for the Pi 4, so if you wish to use the Pi 4 debug firmware files, you need to manually specify `start_file` and `fixup_file`.
-
-`start_x=1` should be specified when using the camera module. Enabling the camera via `raspi-config` will set this automatically.
-
-## disable_commandline_tags
-
-Set the `disable_commandline_tags` command to `1` to stop `start.elf` from filling in ATAGS (memory from `0x100`) before launching the kernel.
-
-## cmdline
-
-`cmdline` is the alternative filename on the boot partition from which to read the kernel command line string; the default value is `cmdline.txt`.
-
-## 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 `kernel.img`, and on the Pi 2, Pi 3, and Compute Module 3 it is `kernel7.img`. On the Pi4, it is `kernel7l.img`.
-
-## 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 must be uncompressed image files.
-
-Note that the 64-bit kernel will only work on the Pi4, Pi3, and Pi2B rev1.2 boards with latest firmware.
-
-## arm_control
-
-**DEPRECATED - use arm_64bit to enable 64-bit kernels**.
-
-Sets board-specific control bits.
-
-## armstub
-
-`armstub` is the filename on the boot partition from which to load the ARM stub. The default ARM stub is stored in firmware and is selected automatically based on the Pi model and various settings.
-
-The stub is a small piece of ARM code that is run before the kernel. Its job is to set up low-level hardware like the interrupt controller before passing control to the kernel.
-
-## arm_peri_high
-
-Set `arm_peri_high` to `1` to enable "High Peripheral" mode on the Pi 4. It is set automatically if a suitable DTB is loaded.
-
-**NOTE**: Enabling "High Peripheral" mode without a compatible device tree will make your system fail to boot. Currently ARM stub support is missing, so you will also need to load a suitable file using `armstub`.
-
-## kernel_address
-
-`kernel_address` is the memory address to which the kernel image should be loaded. 32-bit kernels are loaded to address `0x8000` by default, and 64-bit kernels to address `0x80000`. If `kernel_old` is set, kernels are loaded to the address `0x0`.
-
-## kernel_old
-
-Set `kernel_old` to `1` to load the kernel to the memory address `0x0`.
-
-## ramfsfile
-
-`ramfsfile` is the optional filename on the boot partition of a ramfs to load. N.B. Sufficiently new firmware supports the loading of multiple ramfs files - separate the multiple file names with commas, taking care not to exceed the 80-character line length limit. All the loaded files are concatenated in memory and treated as a single ramfs blob. More information is available [here](https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=10532).
-
-## ramfsaddr
-
-`ramfsaddr` is the memory address to which the `ramfsfile` should be loaded.
-
-## initramfs
-
-The `initramfs` command specifies both the ramfs filename **and** the memory address to which to load it. It performs the actions of both `ramfsfile` and `ramfsaddr` in one parameter. The address can also be `followkernel` (or `0`) to place it in memory after the kernel image. Example values are: `initramfs initramf.gz 0x00800000` or `initramfs init.gz followkernel`. As with `ramfsfile`, newer firmwares allow the loading of multiple files by comma-separating their names. **NOTE:** This option uses different syntax from all the other options, and you should not use a `=` character here.
-
-## init_uart_baud
-
-`init_uart_baud` is the initial UART baud rate. The default value is `115200`.
-
-## init_uart_clock
-
-`init_uart_clock` is the initial UART clock frequency. The default value is `48000000` (48MHz). Note that this clock only applies to UART0 (ttyAMA0 in Linux), and that the maximum baudrate for the UART is limited to 1/16th of the clock. The default UART on the Pi 3 and Pi Zero is UART1 (ttyS0 in Linux), and its clock is the core VPU clock - at least 250MHz.
-
-## bootcode_delay
-
-The `bootcode_delay` command delays for a given number of seconds in `bootcode.bin` before loading `start.elf`: the default value is `0`.
-
-This is particularly useful to insert a delay before reading the EDID of the monitor, for example if the Pi and monitor are powered from the same source, but the monitor takes longer to start up than the Pi. Try setting this value if the display detection is wrong on initial boot, but is correct if you soft-reboot the Pi without removing power from the monitor.
-
-## boot_delay
-
-The `boot_delay` command instructs to wait for a given number of seconds in `start.elf` before loading the kernel: the default value is `1`. The total delay in milliseconds is calculated as `(1000 x boot_delay) + boot_delay_ms`. This can be useful if your SD card needs a while to get ready before Linux is able to boot from it.
-
-## boot_delay_ms
-
-The `boot_delay_ms` command means wait for a given number of milliseconds in `start.elf`, together with `boot_delay`, before loading the kernel. The default value is `0`.
-
-## disable_splash
-
-If `disable_splash` is set to `1`, the rainbow splash screen will not be shown on boot. The default value is `0`.
-
-## enable_gic (Pi 4B only)
-
-On the Raspberry Pi 4B, if this value is set to `0` then the interrupts will be routed to the ARM cores using the legacy interrupt controller, rather than via the GIC-400. The default value is `1`.
-
-## force_eeprom_read
-
-Set this option to `0` to prevent the firmware from trying to read an I2C HAT EEPROM (connected to pins ID_SD & ID_SC) at powerup.
-
-## os_prefix
-
-
-`os_prefix` is an optional setting that allows you to choose between multiple versions of the kernel and Device Tree files installed on the same card. Any value in `os_prefix` is prepended to (stuck in front of) the name of any operating system files loaded by the firmware, where "operating system files" is defined to mean kernels, initramfs, cmdline.txt, .dtbs and overlays. The prefix would commonly be a directory name, but it could also be part of the filename such as "test-". For this reason, directory prefixes must include the trailing `/` character.
-
-In an attempt to reduce the chance of a non-bootable system, the firmware first tests the supplied prefix value for viability - unless the expected kernel and .dtb can be found at the new location/name, the prefix is ignored (set to ""). A special case of this viability test is applied to overlays, which will only be loaded from `${os_prefix}${overlay_prefix}` (where the default value of [`overlay_prefix`](#overlay_prefix) is "overlays/") if `${os_prefix}${overlay_prefix}README` exists, otherwise it ignores `os_prefix` and treats overlays as shared.
-
-(The reason the firmware checks for the existence of key files rather than directories when checking prefixes is twofold - the prefix may not be a directory, and not all boot methods support testing for the existence of a directory.)
-
-N.B. Any user-specified OS file can bypass all prefixes by using an absolute path (with respect to the boot partition) - just start the file path with a `/`, e.g. `kernel=/my_common_kernel.img`.
-
-See also [`overlay_prefix`](#overlay_prefix) and [`upstream_kernel`](#upstream_kernel).
-
-## overlay_prefix
-
-
-Specifies a subdirectory/prefix from which to load overlays - defaults to `overlays/` (note the trailing `/`). If used in conjunction with [`os_prefix`](#os_prefix), the `os_prefix` comes before the `overlay_prefix`, i.e. `dtoverlay=disable-bt` will attempt to load `${os_prefix}${overlay_prefix}disable-bt.dtbo`.
-
-Note that unless `${os_prefix}${overlay_prefix}README` exists, overlays are shared with the main OS (i.e. `os_prefix` is ignored).
-
-## uart_2ndstage
-
-Setting `uart_2ndstage=1` causes the second-stage loader (`bootcode.bin` on devices prior to the Raspberry Pi 4, or the boot code in the EEPROM for Raspberry Pi 4 devices) and the main firmware (`start*.elf`) to output diagnostic information to UART0.
-
-Be aware that output is likely to interfere with Bluetooth operation unless it is disabled (`dtoverlay=disable-bt`) or switched to the other UART (`dtoverlay=miniuart-bt`), and if the UART is accessed simultaneously to output from Linux then data loss can occur leading to corrupted output. This feature should only be required when trying to diagnose an early boot loading problem.
-
-## upstream_kernel
-
-
-If `upstream_kernel=1` is used, the firmware sets [`os_prefix`](#os_prefix) to "upstream/", unless it has been explicitly set to something else, but like other `os_prefix` values it will be ignored if the required kernel and .dtb file can't be found when using the prefix.
-
-The firmware will also prefer upstream Linux names for DTBs (`bcm2837-rpi-3-b.dtb` instead of `bcm2710-rpi-3-b.dtb`, for example). If the upstream file isn't found the firmware will load the downstream variant instead and automatically apply the "upstream" overlay to make some adjustments. Note that this process happens _after_ the `os_prefix` has been finalised.
-
-*This article uses content from the eLinux wiki page [RPiconfig](http://elinux.org/RPiconfig), which is shared under the [Creative Commons Attribution-ShareAlike 3.0 Unported license](http://creativecommons.org/licenses/by-sa/3.0/)*
diff --git a/configuration/config-txt/camera.md b/configuration/config-txt/camera.md
deleted file mode 100644
index fd2c83a936..0000000000
--- a/configuration/config-txt/camera.md
+++ /dev/null
@@ -1,10 +0,0 @@
-# Camera Settings in config.txt
-
-## disable_camera_led
-
-Setting `disable_camera_led` to `1` prevents the red camera LED from turning on when recording video or taking a still picture. This is useful for preventing reflections when the camera is facing a window, for example.
-
-Setting `awb_auto_is_greyworld`to `1` allows libraries or applications that do not support the greyworld option internally to capture valid images and videos with NoIR cameras. It switches "auto" awb mode to use the "greyworld" algorithm. This should only be be needed for NoIR cameras, or when the High Quality camera has had its IR filter removed. (see [here](../../hardware/camera/hqcam_filter_removal.md).
-
-
-*This article uses content from the eLinux wiki page [RPiconfig](http://elinux.org/RPiconfig), which is shared under the [Creative Commons Attribution-ShareAlike 3.0 Unported license](http://creativecommons.org/licenses/by-sa/3.0/)*
diff --git a/configuration/config-txt/codeclicence.md b/configuration/config-txt/codeclicence.md
deleted file mode 100644
index ead3a732d0..0000000000
--- a/configuration/config-txt/codeclicence.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# Licence key and codec options in config.txt
-
-Hardware decoding of additional codecs on the Pi 3 and earlier models can be enabled by [purchasing a licence](http://swag.raspberrypi.org/collections/software) that is locked to the CPU serial number of your Raspberry Pi.
-
-On the Raspberry Pi 4, the hardware codecs for MPEG2 or VC1 are permanently disabled and cannot be enabled even with a licence key; on the Pi 4, thanks to its increased processing power compared to earlier models, MPEG2 and VC1 can be decoded in software via applications such as VLC. Therefore, a hardware codec licence key is not needed if you're using a Pi 4.
-
-## decode_MPG2
-
-`decode_MPG2` is a licence key to allow hardware MPEG-2 decoding, e.g. `decode_MPG2=0x12345678`.
-
-## decode_WVC1
-
-`decode_WVC1` is a licence key to allow hardware VC-1 decoding, e.g. `decode_WVC1=0x12345678`.
-
-If you have multiple Raspberry Pis and you've bought a codec licence for each of them, you can list up to eight licence keys in a single `config.txt`, for example `decode_MPG2=0x12345678,0xabcdabcd,0x87654321`. This enables you to swap the same SD card between the different Pis without having to edit `config.txt` each time.
-
-
-
-
-*This article uses content from the eLinux wiki page [RPiconfig](http://elinux.org/RPiconfig), which is shared under the [Creative Commons Attribution-ShareAlike 3.0 Unported license](http://creativecommons.org/licenses/by-sa/3.0/)*
diff --git a/configuration/config-txt/conditional.md b/configuration/config-txt/conditional.md
deleted file mode 100644
index 0f261cd49a..0000000000
--- a/configuration/config-txt/conditional.md
+++ /dev/null
@@ -1,145 +0,0 @@
-# Conditional filters in config.txt
-
-When a single SD card (or card image) is being used with one Pi and one monitor, it is easy to set `config.txt` as required for that specific combination and keep it that way, amending it only when something changes.
-
-
-However, if one Pi is swapped between different monitors, or if the SD card (or card image) is being swapped between multiple Pis, a single set of settings may no longer be sufficient. Conditional filters allow you to define certain sections of the config file to be used only in specific cases, allowing a single `config.txt` to create different configurations when read by different hardware.
-
-## The `[all]` filter
-
-This is the most basic filter. It resets all previously set filters and allows any settings listed below it to be applied to all hardware.
-
-
- [all]
-
-It is usually a good idea to add an `[all]` filter at the end of groups of filtered settings to avoid unintentionally combining filters (see below).
-
-## The `[pi1]` and `[pi2]` (etc.) model filters
-
-The conditional model filters are applied according to the following table.
-
-| Filter | Applicable model(s) |
-|--------|------------------|
-| [pi1] | Model A, Model B, Compute Module |
-| [pi2] | Model 2B (BCM2836- or BCM2837-based) |
-| [pi3] | Model 3B, Model 3B+, Model 3A+, Compute Module 3 |
-| [pi3+]| Model 3A+, Model 3B+ |
-| [pi4]| Model 4B |
-| [pi0] | Zero, Zero W, Zero WH |
-| [pi0w]| Zero W, Zero WH |
-
-These are particularly useful for defining different `kernel`, `initramfs`, and `cmdline` settings, as the Pi 1 and Pi 2 require different kernels. They can also be useful to define different overclocking settings, as the Pi 1 and Pi 2 have different default speeds. For example, to define separate `initramfs` images for each:
-
- [pi1]
- initramfs initrd.img-3.18.7+ followkernel
- [pi2]
- initramfs initrd.img-3.18.7-v7+ followkernel
- [all]
-
-Remember to use the `[all]` filter at the end, so that any subsequent settings aren't limited to Pi 2 hardware only.
-
-It is important to note that the Raspberry Pi Zero W will see the contents of [pi0w] AND [pi0]. Likewise, a Raspberry Pi 3B Plus sees [pi3+] AND [pi3]. If you want a setting to apply only to Pi Zero or Pi 3B you need to follow it (order is important) with a setting in the [pi0w] or [pi3+] section that reverts it.
-
-
-## The `[none]` filter
-
-The `[none]` filter prevents any settings that follow from being applied to any hardware. Although there is nothing that you can't do without `[none]`, it can be a useful way to keep groups of unused settings in config.txt without having to comment out every line.
-
- [none]
-
-## The `[EDID=*]` filter
-
-When switching between multiple monitors while using a single SD card in your Pi, and where a blank config isn't sufficient to automatically select the desired resolution for each one, this allows specific settings to be chosen based on the monitors' EDID names.
-
-To view the EDID name of an attached monitor, run the following command:
-
- tvservice -n
-
-This will print something like this:
-
- device_name=VSC-TD2220
-
-You can then specify settings that apply only to this monitor:
-
- [EDID=VSC-TD2220]
- hdmi_group=2
- hdmi_mode=82
- [all]
-
-This forces 1920x1080 DVT mode for the specified monitor, without affecting any other monitors.
-
-Note that these settings apply only at boot, so the monitor must be connected at boot time and the Pi must be able to read its EDID information to find the correct name. Hotplugging a different monitor into the Pi after boot will not select different settings.
-
-On the Pi 4, if both HDMI ports are in use, then the EDID will be checked against both of them, and subsequent configuration applied only to the first matching device. You can determine the EDID names for both ports by first running `tvservice -l` in a terminal window to list all attached devices and then using the returned numerical IDs in `tvservice -v -n` to find the EDID name for a specific display ID.
-
-## The serial number filter
-
-Sometimes settings should only be applied to a single specific Pi, even if you swap the SD card to a different one. Examples include licence keys and overclocking settings (although the licence keys already support SD card swapping in a different way). You can also use this to select different display settings, even if the EDID identification above is not possible, provided that you don't swap monitors between your Pis. For example, if your monitor doesn't supply a usable EDID name, or if you are using composite output (for which EDID cannot be read).
-
-To view the serial number of your Pi, run the following command:
-
- cat /proc/cpuinfo
-
-The serial will be shown as a 16-digit hex value at the bottom. For example, if you see:
-
- Serial : 0000000012345678
-
-then you can define settings that will only be applied to this specific Pi:
-
- [0x12345678]
- # settings here are applied only to the Pi with this serial
- [all]
- # settings here are applied to all hardware
-
-## The GPIO filter
-
-You can also filter depending on the state of a GPIO. For example
-
- [gpio4=1]
- # Settings here are applied if GPIO 4 is high
-
- [gpio2=0]
- # Settings here are applied if GPIO 2 is low
-
- [all]
- # settings here are applied to all hardware
-
-## The `[HDMI:*]` filter — Pi 4 only
-
-The Raspberry Pi 4 has two HDMI ports, and for many `config.txt` commands related to HDMI, it is necessary to specify which HDMI port is being referred to. The HDMI conditional filters subsequent HDMI configurations to the specific port.
-
- [HDMI:0]
- hdmi_group=2
- hdmi_mode=45
- [HDMI:1]
- hdmi_group=2
- hdmi_mode=67
-
-An alternative `variable:index` syntax is available on all port-specific HDMI commands. You could use the following, which is the same as the previous example:
-
- hdmi_group:0=2
- hdmi_mode:0=45
- hdmi_group:1=2
- hdmi_mode:1=67
-
-## Combining conditional filters
-
-Filters of the same type replace each other, so `[pi2]` overrides `[pi1]`, because it is not possible for both to be true at once.
-
-Filters of different types can be combined simply by listing them one after the other, for example:
-
- # settings here are applied to all hardware
- [EDID=VSC-TD2220]
- # settings here are applied only if monitor VSC-TD2220 is connected
- [pi2]
- # settings here are applied only if monitor VSC-TD2220 is connected *and* on a Pi 2
- [all]
- # settings here are applied to all hardware
-
-Use the `[all]` filter to reset all previous filters and avoid unintentionally combining different filter types.
-
-
-
-
-
-*This article uses content from the eLinux wiki page [RPiconfig](http://elinux.org/RPiconfig), which is shared under the [Creative Commons Attribution-ShareAlike 3.0 Unported license](http://creativecommons.org/licenses/by-sa/3.0/)*
diff --git a/configuration/config-txt/gpio.md b/configuration/config-txt/gpio.md
deleted file mode 100644
index 5932cda0e9..0000000000
--- a/configuration/config-txt/gpio.md
+++ /dev/null
@@ -1,56 +0,0 @@
-# GPIO control in config.txt
-
-## `gpio`
-The `gpio` directive allows GPIO pins to be set to specific modes and values at boot time in a way that would
-previously have needed a custom `dt-blob.bin` file. Each line applies the same settings (or at least makes the same
-changes) to a set of pins, either a single pin (`3`), a range of pins (`3-4`), or a comma-separated list of either (`3-4,6,8`).
-The pin set is followed by an `=` and one or more comma-separated attributes from this list:
-
-* `ip` - Input
-* `op` - Output
-* `a0-a5` - Alt0-Alt5
-* `dh` - Driving high (for outputs)
-* `dl` - Driving low (for outputs)
-* `pu` - Pull up
-* `pd` - Pull down
-* `pn/np` - No pull
-
-`gpio` settings are applied in order, so those appearing later override those appearing earlier.
-
-Examples:
-```
-# Select Alt2 for GPIO pins 0 to 27 (for DPI24)
-gpio=0-27=a2
-
-# Set GPIO12 to be an output set to 1
-gpio=12=op,dh
-
-# Change the pull on (input) pins 18 and 20
-gpio=18,20=pu
-
-# Make pins 17 to 21 inputs
-gpio=17-21=ip
-```
-
-The `gpio` directive respects the "[...]" section headers in `config.txt`, so it is possible to use different settings
-based on the model, serial number, and EDID.
-
-GPIO changes made through this mechanism do not have any direct effect on the kernel — they don't cause GPIO pins to
-be exported to the sysfs interface, and they can be overridden by pinctrl entries in the Device Tree as well as
-utilities like `raspi-gpio`.
-
-Note also that there is a delay of a few seconds between power being applied and the changes taking effect — longer
-if booting over the network or from a USB mass storage device.
-
-## `enable_jtag_gpio`
-
-Setting `enable_jtag_gpio=1` selects Alt4 mode for GPIO pins 22-27, and sets up some internal SoC connections, thus enabling the JTAG interface for the ARM CPU. It works on all models of Raspberry Pi.
-
-| Pin # | Function |
-| ------ | -------- |
-| GPIO22 | ARM_TRST |
-| GPIO23 | ARM_RTCK |
-| GPIO24 | ARM_TDO |
-| GPIO25 | ARM_TCK |
-| GPIO26 | ARM_TDI |
-| GPIO27 | ARM_TMS |
diff --git a/configuration/config-txt/memory.md b/configuration/config-txt/memory.md
deleted file mode 100644
index 9d7bd625f1..0000000000
--- a/configuration/config-txt/memory.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# Memory options in config.txt
-
-## gpu_mem
-
-Specifies how much memory, in megabytes, to reserve for the exclusive use of the GPU: the remaining memory is allocated to the ARM CPU for use by the OS. For Pis with less than 1GB of memory, the default is `64`; for Pis with 1GB or more of memory the default is `76`.
-
-The memory allocated to the GPU is used for display, 3D, Codec and camera purposes as well as some basic firmware housekeeping. The maximums specified below assume you are using all these features. If you are not, then smaller values of gpu_mem can be used.
-
-To ensure the best performance of Linux, you should set `gpu_mem` to the lowest possible value. If a particular graphics feature is not working correctly, try increasing the value of `gpu_mem`, being mindful of the recommended maximums shown below. Unlike GPU's found on x86 machines, where increasing memory can improve 3D performance, the architecture of the VideoCore means **there is no performance advantage from specifying values larger than is necessary**, and in fact it can harm performance.
-
-On the Raspberry Pi 4 the 3D component of the GPU has its own memory management unit (MMU), and does not use memory from the `gpu_mem` allocation. Instead memory is allocated dynamically within Linux. This allows a smaller value to be specified for `gpu_mem` on the Pi 4, compared to previous models.
-
-The recommended maximum values are as follows:
-
-| total RAM | `gpu_mem` recommended maximum |
-|-----------|-------------------------------|
-| 256MB | `128` |
-| 512MB | `384` |
-| 1GB or greater | `512`, `256` on the Pi4 |
-
-It is possible to set `gpu_mem` to larger values, however this should be avoided since it can cause problems, such as preventing Linux from booting. The minimum value is `16`, however this disables certain GPU features.
-
-You can also use `gpu_mem_256`, `gpu_mem_512`, and `gpu_mem_1024` to allow swapping the same SD card between Pis with different amounts of RAM without having to edit `config.txt` each time:
-
-## gpu_mem_256
-
-The `gpu_mem_256` command sets the GPU memory in megabytes for Raspberry Pis with 256MB of memory. (It is ignored if memory size is not 256MB). This overrides `gpu_mem`.
-
-## gpu_mem_512
-
-The `gpu_mem_512` command sets the GPU memory in megabytes for Raspberry Pis with 512MB of memory. (It is ignored if memory size is not 512MB). This overrides `gpu_mem`.
-
-## gpu_mem_1024
-
-The `gpu_mem_1024` command sets the GPU memory in megabytes for Raspberry Pis with 1GB or more of memory. (It is ignored if memory size is smaller than 1GB). This overrides `gpu_mem`.
-
-## total_mem
-
-This parameter can be used to force a Raspberry Pi to limit its memory capacity: specify the total amount of RAM, im megabytes, you wish the Pi to use. For example, to make a 4GB Raspberry Pi 4B behave as though it were a 1GB model, use the following:
-
-```
-total_mem=1024
-```
-
-This value will be clamped between a minimum of 128MB, and a maximum of the total memory installed on the board.
-
-## disable_l2cache
-
-Setting this to `1` disables the CPU's access to the GPU's L2 cache and requires a corresponding L2 disabled kernel. Default value on BCM2835 is `0`. On BCM2836, BCM2837, and BCM2711, the ARMs have their own L2 cache and therefore the default is `1`. The standard Pi kernel.img and kernel7.img builds reflect this difference in cache setting.
-
-*This article uses content from the eLinux wiki page [RPiconfig](http://elinux.org/RPiconfig), which is shared under the [Creative Commons Attribution-ShareAlike 3.0 Unported license](http://creativecommons.org/licenses/by-sa/3.0/)*
diff --git a/configuration/config-txt/misc.md b/configuration/config-txt/misc.md
deleted file mode 100644
index 20b837020d..0000000000
--- a/configuration/config-txt/misc.md
+++ /dev/null
@@ -1,24 +0,0 @@
-# Miscellaneous options in config.txt
-
-## avoid_warnings
-
-The [warning symbols](../warning-icons.md) can be disabled using this option, although this is not advised.
-
-`avoid_warnings=1` disables the warning overlays.
-`avoid_warnings=2` disables the warning overlays, but additionally allows turbo mode even when low-voltage is present.
-
-## logging_level
-
-Sets the VideoCore logging level. The value is a VideoCore-specific bitmask.
-
-## include
-
-Causes the content of the specified file to be inserted into the current file.
-
-For example, adding the line `include extraconfig.txt` to `config.txt` will include the content of `extraconfig.txt` file in the `config.txt` file.
-
-**Include directives are not supported by bootcode.bin or the EEPROM bootloader**
-
-## max_usb_current
-
-**This command is now deprecated and has no effect.** Originally certain models of Raspberry Pi limited the USB ports to a maximum of 600mA. Setting `max_usb_current=1` changed this default to 1200mA. However, all firmware now has this flag set by default, so it is no longer necessary to use this option.
diff --git a/configuration/config-txt/overclocking.md b/configuration/config-txt/overclocking.md
deleted file mode 100644
index 65cfa7b751..0000000000
--- a/configuration/config-txt/overclocking.md
+++ /dev/null
@@ -1,142 +0,0 @@
-# Overclocking options in config.txt
-
-**NOTE:** Setting any overclocking parameters to values other than those used by [raspi-config](../raspi-config.md#overclock) may set a permanent bit within the SoC, making it possible to detect that your Pi has been overclocked. The specific circumstances where the overclock bit is set are if `force_turbo` is set to `1` and any of the `over_voltage_*` options are set to a value > `0`. See the [blog post on Turbo Mode](https://www.raspberrypi.org/blog/introducing-turbo-mode-up-to-50-more-performance-for-free/) for more information. **Pi 4** overclocking options may be subject to change in the future.
-
-The latest kernel has a [cpufreq](http://www.pantz.org/software/cpufreq/usingcpufreqonlinux.html) kernel driver with the "ondemand" governor enabled by default. It has no effect if you have no overclock settings, but if you overclock, the CPU frequency will vary with processor load. Non-default values are only used when required, according to the governor. You can adjust the minimum values with the `*_min` config options (only values lower than default are applied) or disable dynamic clocking (and force overclocking) with `force_turbo=1`. For more information [see this section of the documentation](../../hardware/raspberrypi/frequency-management.md).
-
-Overclocking and overvoltage will be disabled at runtime when the SoC reaches 85°C, in order to cool the SoC down. You should not hit this limit with Raspberry Pi Models 1 or 2, but you are more likely to with Raspberry Pi 3 and Raspberry Pi 4B. For more information [see this section of the documentation](../../hardware/raspberrypi/frequency-management.md). Overclocking and overvoltage are also disabled when an undervoltage situation is detected.
-
-## Overclocking options
-
-| Option | Description |
-| --- | --- |
-| arm_freq | Frequency of the ARM CPU in MHz. |
-| gpu_freq | Sets `core_freq`, `h264_freq`, `isp_freq`, `v3d_freq` and `hevc_freq` together |
-| core_freq | Frequency of the GPU processor core in MHz, influences CPU performance because it drives the L2 cache and memory bus; the L2 cache benefits only Pi Zero/Pi Zero W/ Pi 1, there is a small benefit for SDRAM on Pi 2/Pi 3. See section below for use on the Pi 4.|
-| h264_freq | Frequency of the hardware video block in MHz; individual override of the `gpu_freq` setting |
-| isp_freq | Frequency of the image sensor pipeline block in MHz; individual override of the `gpu_freq` setting |
-| v3d_freq | Frequency of the 3D block in MHz; individual override of the `gpu_freq` setting |
-| hevc_freq | Frequency of the High Efficiency Video Codec block in MHz; individual override of the `gpu_freq` setting. Pi 4 only. |
-| sdram_freq | Frequency of the SDRAM in MHz. SDRAM overclocking on Pi 4B is not currently supported|
-| over_voltage | CPU/GPU core voltage adjustment. The value should be in the range [-16, 8] which equates to the range [0.8V, 1.4V] with 0.025V steps. In other words, specifying -16 will give 0.8V as the GPU/core voltage, and specifying 8 will give 1.4V. For defaults see table below. Values above 6 are only allowed when `force_turbo` is specified: this sets the warranty bit if `over_voltage_*` is also set. |
-| over_voltage_sdram | Sets `over_voltage_sdram_c`, `over_voltage_sdram_i`, and `over_voltage_sdram_p` together. |
-| over_voltage_sdram_c | SDRAM controller voltage adjustment. [-16,8] equates to [0.8V,1.4V] with 0.025V steps. |
-| over_voltage_sdram_i | SDRAM I/O voltage adjustment. [-16,8] equates to [0.8V,1.4V] with 0.025V steps. |
-| over_voltage_sdram_p | SDRAM phy voltage adjustment. [-16,8] equates to [0.8V,1.4V] with 0.025V steps. |
-| force_turbo | Forces turbo mode frequencies even when the ARM cores are not busy. Enabling this may set the warranty bit if `over_voltage_*` is also set. |
-| initial_turbo | Enables turbo mode from boot for the given value in seconds, or until cpufreq sets a frequency. For more information [see here](https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=6201&start=425#p180099). The maximum value is `60`. |
-| arm_freq_min | Minimum value of `arm_freq` used for dynamic frequency clocking. |
-| core_freq_min | Minimum value of `core_freq` used for dynamic frequency clocking. |
-| gpu_freq_min | Minimum value of `gpu_freq` used for dynamic frequency clocking. |
-| h264_freq_min | Minimum value of `h264_freq` used for dynamic frequency clocking. |
-| isp_freq_min | Minimum value of `isp_freq` used for dynamic frequency clocking. |
-| v3d_freq_min | Minimum value of `v3d_freq` used for dynamic frequency clocking. |
-| hevc_freq_min | Minimum value of `hevc_freq` used for dynamic frequency clocking. |
-| sdram_freq_min | Minimum value of `sdram_freq` used for dynamic frequency clocking. |
-| over_voltage_min | Minimum value of `over_voltage` used for dynamic frequency clocking. |
-| temp_limit | Overheat protection. This sets the clocks and voltages to default when the SoC reaches this value in Celsius. Values over 85 are clamped to 85. |
-| temp_soft_limit | **3A+/3B+ only**. CPU speed throttle control. This sets the temperature at which the CPU clock speed throttling system activates. At this temperature, the clock speed is reduced from 1400MHz to 1200MHz. Defaults to `60`, can be raised to a maximum of `70`, but this may cause instability. |
-
-This table gives the default values for the options on various Raspberry Pi Models, all frequencies are stated in MHz.
-
-| Option | Pi 0/W | Pi1 | Pi2 | Pi3 | Pi3A+/Pi3B+ | Pi4 |
-| --- | :---: | :---: | :---: | :----: | :-----: | :----: |
-| arm_freq | 1000 | 700 | 900 | 1200 | 1400 | 1500 |
-| core_freq | 400 | 250 | 250 | 400 | 400 | 500/550/360 |
-| h264_freq | 300 | 250 | 250 | 400 | 400 | 500/550/360 |
-| isp_freq | 300 | 250 | 250 | 400 | 400 | 500/550/360 |
-| v3d_freq | 300 | 250 | 250 | 400 | 400 | 500/550/360 |
-| hevc_freq | N/A | N/A | N/A | N/A | N/A | 500/550/360 |
-| sdram_freq | 450 | 400 | 450 | 450 | 500 | 3200 |
-| arm_freq_min | 700 | 700 | 600 | 600 | 600 | 600 |
-| core_freq_min| 250 | 250 | 250 | 250 | 250 | 250/275 |
-| gpu_freq_min | 250 | 250 | 250 | 250 | 250 | 500 |
-| h264_freq_min| 250 | 250 | 250 | 250 | 250 | 500 |
-| isp_freq_min | 250 | 250 | 250 | 250 | 250 | 500 |
-| v3d_freq_min | 250 | 250 | 250 | 250 | 250 | 500 |
-| sdram_freq_min |400 | 400 | 400 | 400 | 400 | 400 |
-
-This table gives defaults for options that are the same across all models.
-
-| Option | Default |
-| --- | :---: |
-| initial_turbo | 0 |
-| overvoltage_min | 0 |
-| temp_limit | 85 |
-| over_voltage_sdram_c | 0 (1.2V) |
-| over_voltage_sdram_i | 0 (1.2V) |
-| over_voltage_sdram_p | 0 (1.2V) |
-
-This table lists the default `over_voltage` settings for the various Pi models. The firmware uses Adaptive Voltage Scaling (AVS) to determine the optimum voltage to set. Note that for each integer rise in `over_voltage`, the voltage will be 25mV higher.
-
-| Model | Default | Resulting voltage |
-| --- | --- | --- |
-| Pi 1 | 0 | 1.2V |
-| Pi 2 | 0 | 1.2-1.3125V |
-| Pi 3 | 0 | 1.2-1.3125V |
-| Pi Zero | 6 | 1.35V |
-
-#### Specific to Pi 4B
-
-The `core_freq` of the Raspberry Pi 4 can change from the default if either `hdmi_enable_4kp60` or `enable_tvout` are used, due to relationship between internal clocks and the particular requirements of the requested display modes.
-
-| Display option | Frequency |
-| -------------- | --------: |
-| Default | 500 |
-| enable_tvout | 360 |
-| hdmi_enable_4kp60 | 550 |
-
-Changing `core_freq` in `config.txt` is not supported on the Pi 4, any change from the default will almost certainly cause a failure to boot.
-
-It is recommended when overclocking to use the individual frequency settings (`isp_freq`, `v3d_freq` etc) rather than `gpu_freq`, as since it attempts to set `core_freq` (which cannot be changed on the Pi 4), it is not likely to have the desired effect.
-
-### force_turbo
-
-By default (`force_turbo=0`) the "On Demand" CPU frequency driver will raise clocks to their maximum frequencies when the ARM cores are busy and will lower them to the minimum frequencies when the ARM cores are idle.
-
-`force_turbo=1` overrides this behaviour and forces maximum frequencies even when the ARM cores are not busy.
-
-### 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 warranty bit cannot be set either inadvertently or maliciously by using an invalid overvoltage.
-
-### disable_auto_turbo
-
-On Pi 2/Pi 3, setting this flag will disable the GPU from moving into turbo mode, which it can do in particular load cases.
-
-## Clocks relationship
-
-The GPU core, CPU, SDRAM and GPU each have their own PLLs and can have unrelated frequencies. The h264, v3d and ISP blocks share a PLL. For more information [see here](https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=6201&start=275#p168042).
-
-To view the Pi's current frequency in KHz, type: `cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq`. Divide the result by 1000 to find the value in MHz. Note that this frequency is the kernel *requested* frequency, and it is possible that any throttling (for example at high temperatures) may mean the CPU is actually running more slowly than reported. An instantaneous measurement of the actual ARM CPU frequency can be retrieved using the vcgencmd `vcgencmd measure_clock arm`. This is displayed in Hertz.
-
-## Monitoring core temperature
-
-To view the Pi's temperature, type `cat /sys/class/thermal/thermal_zone0/temp`. Divide the result by 1000 to find the value in degrees Celsius. Alternatively, there is a vcgencmd, `vcgencmd measure_temp` that interrogates the GPU directly for its temperature.
-
-Whilst hitting the temperature limit is not harmful to the SoC, it will cause CPU throttling. A heatsink can help to control the core temperature and therefore performance. This is especially useful if the Pi is running inside a case. Airflow over the heatsink will make cooling more efficient.
-
-With firmware from 12th September 2016 or later, when the core temperature is between 80'C and 85'C, a warning icon showing a red half-filled thermometer will be displayed, and the ARM cores will be throttled back. If the temperature exceeds 85'C, an icon showing a fully-filled thermometer will be displayed, and both the ARM cores and the GPU will be throttled back.
-
-For the Raspberry Pi 3 Model B+, the PCB technology has been changed to provide better heat dissipation and increased thermal mass. In addition, a soft temperature limit has been introduced, with the goal of maximising the time for which a device can "sprint" before reaching the hard limit at 85°C. When the soft limit is reached, the clock speed is reduced from 1.4GHz to 1.2GHz, and the operating voltage is reduced slightly. This reduces the rate of temperature increase: we trade a short period at 1.4GHz for a longer period at 1.2GHz. By default, the soft limit is 60°C, and this can be changed via the `temp_soft_limit` setting in config.txt.
-
-See the page on [warning icons](../warning-icons.md) for more details.
-
-## Monitoring voltage
-
-It is essential to keep the supply voltage above 4.8V for reliable performance. Note that the voltage from some USB chargers/power supplies can fall as low as 4.2V. This is because they are usually designed to charge a 3.7V LiPo battery, not to supply 5V to a computer.
-
-To monitor the Pi's PSU voltage, you will need to use a multimeter to measure between the VCC and GND pins on the GPIO. More information is available in [power](../../hardware/raspberrypi/power/README.md).
-
-If the voltage drops below 4.63V (+-5%), recent versions of the firmware will show a yellow lightning bolt symbol on the display to indicate a lack of power, and a message indicating the low voltage state will be added to the kernel log.
-
-See the page on [warning icons](../warning-icons.md) for more details.
-
-## Overclocking problems
-
-Most overclocking issues show up immediately with a failure to boot. If this occurs, hold down the `shift` key during the next boot. This will temporarily disable all overclocking, allowing you to boot successfully and then edit your settings.
-
-
-
-
-*This article uses content from the eLinux wiki page [RPiconfig](http://elinux.org/RPiconfig), which is shared under the [Creative Commons Attribution-ShareAlike 3.0 Unported license](http://creativecommons.org/licenses/by-sa/3.0/)*
diff --git a/configuration/config-txt/pi4-hdmi.md b/configuration/config-txt/pi4-hdmi.md
deleted file mode 100644
index e11cb219e5..0000000000
--- a/configuration/config-txt/pi4-hdmi.md
+++ /dev/null
@@ -1,24 +0,0 @@
-# Raspberry Pi 4 HDMI pipeline
-
-In order to support dual displays, and modes up to 4k60, the Raspberry Pi 4 has updated the HDMI composition pipeline hardware in a number of ways. One of the major changes is that it generates 2 output pixels for every clock cycle.
-
-Every HDMI mode has a list of timings that control all the parameters around sync pulse durations. These are typically defined via a pixel clock, and then a number of active pixels, a front porch, sync pulse, and back porch for each of the horizontal and vertical directions.
-
-Running everything at 2 pixels per clock means that the Pi4 can not support a timing where _any_ of the horizontal timings are not divisible by 2. The firmware and Linux kernel will filter out any mode that does not fulfill this criteria.
-
-There is only one mode in the CEA and DMT standards that falls into this category - DMT mode 81, which is 1366x768 @ 60Hz. This mode has odd values for the horizontal sync and back porch timings. It's also an unusual mode for having a width that isn't divisible by 8.
-
-If your monitor is of this resolution, then the Pi4 will automatically drop down to the next mode that is advertised by the monitor; this is typically 1280x720.
-
-On some monitors it is possible to configure them to use 1360x768 @ 60Hz. They typically do not advertise this mode via their EDID so the selection can't be made automatically, but it can be manually chosen by adding
-
-```
-hdmi_group=2
-hdmi_mode=87
-hdmi_cvt=1360 768 60
-```
-to [config.txt](./video.md).
-
-Timings specified manually via a `hdmi_timings=` line in `config.txt` will also need to comply with the restriction of all horizontal timing parameters being divisible by 2.
-
-`dpi_timings=` are not restricted in the same way as that pipeline still only runs at a single pixel per clock cycle.
diff --git a/configuration/config-txt/video.md b/configuration/config-txt/video.md
deleted file mode 100644
index c49eb87cb0..0000000000
--- a/configuration/config-txt/video.md
+++ /dev/null
@@ -1,701 +0,0 @@
-# Video options in config.txt
-
-## Composite video mode options
-
-### sdtv_mode
-
-The `sdtv_mode` command defines the TV standard used for composite video output. On the original Raspberry Pi, composite video is output on the RCA socket. On other Raspberry Pi's, except for Pi Zero and Compute Module, composite video is output along with sound on the 4 pole TRRS ("headphone") socket. On the Pi Zero, there is an unpopulated header labelled "TV" which outputs composite video. On the Compute Module, composite video is available via the TVDAC pin. The default value of `sdtv_mode` is `0`.
-
-| sdtv_mode | result |
-| --- | --- |
-| 0 | Normal NTSC |
-| 1 | Japanese version of NTSC – no pedestal |
-| 2 | Normal PAL |
-| 3 | Brazilian version of PAL – 525/60 rather than 625/50, different subcarrier |
-| 16 | Progressive scan NTSC |
-| 18 | Progressive scan PAL |
-
-### sdtv_aspect
-
-The `sdtv_aspect` command defines the aspect ratio for composite video output. The default value is `1`.
-
-| sdtv_aspect | result |
-| --- | --- |
-| 1 | 4:3 |
-| 2 | 14:9 |
-| 3 | 16:9 |
-
-### sdtv_disable_colourburst
-
-Setting `sdtv_disable_colourburst` to `1` disables colourburst on composite video output. The picture will be displayed in monochrome, but it may appear sharper.
-
-### enable_tvout (Pi 4B only)
-
-On the Raspberry Pi 4, composite output is disabled by default, due to the way the internal clocks are interrelated and allocated. Because composite video requires a very specific clock, setting that clock to the required speed on the Pi 4 means that other clocks connected to it are detrimentally affected, which slightly slows down the entire system. Since composite video is a less commonly used function, we decided to disable it by default to prevent this system slowdown.
-
-To enable composite output, use the `enable_tvout=1` option. As described above, this will detrimentally affect performance to a small degree.
-
-On older Pi models, the composite behaviour remains the same.
-
-## HDMI mode options
-
-**Note for Raspberry Pi4B users:** Because the Raspberry Pi 4B has two HDMI ports, some HDMI commands can be applied to either port. You can use the syntax `:`, where port is 0 or 1, to specify which port the setting should apply to. If no port is specified, the default is 0. If you specify a port number on a command that does not require a port number, the port is ignored. Further details on the syntax and alternatives mechanisms can be found in the HDMI section on the [conditionals page](./conditional.md) of the documentation.
-
-In order to support dual 4k displays, the Raspberrry Pi 4 has updated video hardware, which imposes minor restrictions on the modes supported. Please see
-[here](./pi4-hdmi.md) for more details.
-
-### hdmi_safe
-
-Setting `hdmi_safe` to `1` will lead to "safe mode" settings being used to try to boot with maximum HDMI compatibility. This is the same as setting the following parameters:
-
-```
-hdmi_force_hotplug=1
-hdmi_ignore_edid=0xa5000080
-config_hdmi_boost=4
-hdmi_group=2
-hdmi_mode=4
-disable_overscan=0
-overscan_left=24
-overscan_right=24
-overscan_top=24
-overscan_bottom=24
-```
-
-### hdmi_ignore_edid
-
-Setting `hdmi_ignore_edid` to `0xa5000080` enables the ignoring of EDID/display data if your display does not have an accurate [EDID](https://en.wikipedia.org/wiki/Extended_display_identification_data). It requires this unusual value to ensure that it is not triggered accidentally.
-
-### hdmi_edid_file
-
-Setting `hdmi_edid_file` to `1` will cause the GPU to read EDID data from the `edid.dat` file, located in the boot partition, instead of reading it from the monitor. More information is available [here](https://www.raspberrypi.org/forums/viewtopic.php?p=173430#p173430).
-
-### hdmi_edid_filename
-
-On the Raspberry Pi 4B, you can use the `hdmi_edid_filename` command to specify the filename of the EDID file to use, and also to specify which port the file is to be applied to. This also requires `hdmi_edid_file=1` to enable EDID files.
-
-For example:
-
-```
-hdmi_edid_file=1
-hdmi_edid_filename:0=FileForPortZero.edid
-hdmi_edid_filename:1=FileForPortOne.edid
-```
-
-### hdmi_force_edid_audio
-
-Setting `hdmi_force_edid_audio` to `1` pretends that all audio formats are supported by the display, allowing passthrough of DTS/AC3 even when this is not reported as supported.
-
-### hdmi_ignore_edid_audio
-
-Setting `hdmi_ignore_edid_audio` to `1` pretends that all audio formats are unsupported by the display. This means ALSA will default to the analogue audio (headphone) jack.
-
-### hdmi_force_edid_3d
-
-Setting `hdmi_force_edid_3d` to `1` pretends that all CEA modes support 3D, even when the EDID does not indicate support for this.
-
-### hdmi_ignore_cec_init
-
-Setting `hdmi_ignore_cec_init` to `1` will stop the initial active source message being sent during bootup. This prevents a CEC-enabled TV from coming out of standby and channel-switching when you are rebooting your Raspberry Pi.
-
-### hdmi_ignore_cec
-
-Setting `hdmi_ignore_cec` to `1` pretends that [CEC](https://en.wikipedia.org/wiki/Consumer_Electronics_Control#CEC) is not supported at all by the TV. No CEC functions will be supported.
-
-### cec_osd_name
-
-The `cec_osd_name` command sets the initial CEC name of the device. The default is Raspberry Pi.
-
-### hdmi_pixel_encoding
-
-The `hdmi_pixel_encoding` command forces the pixel encoding mode. By default, it will use the mode requested from the EDID, so you shouldn't need to change it.
-
-| hdmi_pixel_encoding | result |
-| --- | --- |
-| 0 | default (RGB limited for CEA, RGB full for DMT) |
-| 1 | RGB limited (16-235) |
-| 2 | RGB full (0-255) |
-| 3 | YCbCr limited (16-235) |
-| 4 | YCbCr full (0-255) |
-
-### hdmi_max_pixel_freq
-
-The pixel frequency is used by the firmware and KMS to filter HDMI modes. Note, this is not the same as the frame rate. It specifies the maximum frequency that a valid mode can have, thereby culling out higher frequency modes. The frequencies for all the HDMI modes can he found on the Wiki page [here](https://en.wikipedia.org/wiki/Extended_Display_Identification_Data#CEA_EDID_Timing_Extension_data_format_-_Version_3), section "CEA/EIA-861 standard resolutions and timings".
-
-So for example, if you wish to disable all 4K modes, you could specify a maximum frequency of 200000000, since all 4K modes have frequencies greater than this.
-
-### hdmi_blanking
-
-The `hdmi_blanking` command controls what happens when the operating system asks for the display to be put into standby mode, using DPMS, to save power. If this option is not set or set to 0, the HDMI output is blanked but not switched off. In order to mimic the behaviour of other computers, you can set the HDMI output to switch off as well by setting this option to 1: the attached display will go into a low power standby mode.
-
-**On the Raspberry Pi 4, setting hdmi_blanking=1 will not cause the HDMI output to be switched off, since this feature has not yet been implemented.**
-
-**NOTE:** This feature may cause issues when using applications which don't use the framebuffer, such as omxplayer.
-
-| hdmi_blanking | result |
-| --- | --- |
-| 0 | HDMI output will be blanked |
-| 1 | HDMI output will be switched off and blanked |
-
-### hdmi_drive
-
-The `hdmi_drive` command allows you to choose between HDMI and DVI output modes.
-
-| hdmi_drive | result |
-| --- | --- |
-| 1 | Normal DVI mode (no sound) |
-| 2 | Normal HDMI mode (sound will be sent if supported and enabled) |
-
-### config_hdmi_boost
-
-Configures the signal strength of the HDMI interface. The minimum value is `0` and the maximum is `11`.
-
-The default value for the original Model B and A is `2`. The default value for the Model B+ and all later models is `5`.
-
-If you are seeing HDMI issues (speckling, interference) then try `7`. Very long HDMI cables may need up to `11`, but values this high should not be used unless absolutely necessary.
-
-This option is ignored on the Raspberry Pi 4.
-
-### hdmi_group
-
-The `hdmi_group` command defines the HDMI output group to be either CEA (Consumer Electronics Association, the standard typically used by TVs) or DMT (Display Monitor Timings, the standard typically used by monitors). This setting should be used in conjunction with `hdmi_mode`.
-
-| hdmi_group | result |
-| --- | --- |
-| 0 | Auto-detect from EDID |
-| 1 | CEA |
-| 2 | DMT |
-
-### hdmi_mode
-
-Together with `hdmi_group`, `hdmi_mode` defines the HDMI output format. Format mode numbers are derived from the CTA specification found [here](https://web.archive.org/web/20171201033424/https://standards.cta.tech/kwspub/published_docs/CTA-861-G_FINAL_revised_2017.pdf)
-
-To set a custom display mode not listed here, see [this thread](https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=24679).
-
-Note that not all modes are available on all models.
-
-These values are valid if `hdmi_group=1` (CEA):
-
-| hdmi_mode | Resolution | Frequency | Screen Aspect | Notes |
-| --------- | --------- | ----------| :-----------: |------ |
-| 1 | VGA (640x480) | 60Hz | 4:3 | |
-| 2 | 480p | 60Hz | 4:3 | |
-| 3 | 480p | 60Hz | 16:9 | |
-| 4 | 720p | 60Hz | 16:9 | |
-| 5 | 1080i | 60Hz | 16:9 | |
-| 6 | 480i | 60Hz | 4:3 | |
-| 7 | 480i | 60Hz | 16:9 | |
-| 8 | 240p | 60Hz | 4:3 | |
-| 9 | 240p | 60Hz | 16:9 | |
-| 10 | 480i | 60Hz | 4:3 | pixel quadrupling |
-| 11 | 480i | 60Hz | 16:9 | pixel quadrupling |
-| 12 | 240p | 60Hz | 4:3 | pixel quadrupling |
-| 13 | 240p | 60Hz | 16:9 |pixel quadrupling|
-| 14 | 480p | 60Hz | 4:3 | pixel doubling |
-| 15 | 480p | 60Hz | 16:9 | pixel doubling |
-| 16 | 1080p | 60Hz | 16:9 | |
-| 17 | 576p | 50Hz | 4:3 | |
-| 18 | 576p | 50Hz | 16:9 | |
-| 19 | 720p | 50Hz | 16:9 | |
-| 20 | 1080i | 50Hz | 16:9 | |
-| 21 | 576i | 50Hz | 4:3 | |
-| 22 | 576i | 50Hz | 16:9 | |
-| 23 | 288p | 50Hz | 4:3 | |
-| 24 | 288p | 50Hz | 16:9 | |
-| 25 | 576i | 50Hz | 4:3 | pixel quadrupling |
-| 26 | 576i | 50Hz | 16:9 | pixel quadrupling |
-| 27 | 288p | 50Hz | 4:3 | pixel quadrupling |
-| 28 | 288p | 50Hz | 16:9 | pixel quadrupling |
-| 29 | 576p | 50Hz | 4:3 | pixel doubling |
-| 30 | 576p | 50Hz | 16:9 | pixel doubling |
-| 31 | 1080p | 50Hz | 16:9 | |
-| 32 | 1080p | 24Hz | 16:9 | |
-| 33 | 1080p | 25Hz | 16:9 | |
-| 34 | 1080p | 30Hz | 16:9 | |
-| 35 | 480p | 60Hz | 4:3 | pixel quadrupling |
-| 36 | 480p | 60Hz | 16:9 | pixel quadrupling |
-| 37 | 576p | 50Hz | 4:3 | pixel quadrupling |
-| 38 | 576p | 50Hz | 16:9 | pixel quadrupling |
-| 39 | 1080i | 50Hz | 16:9 | reduced blanking |
-| 40 | 1080i | 100Hz | 16:9 | |
-| 41 | 720p | 100Hz | 16:9 | |
-| 42 | 576p | 100Hz | 4:3 | |
-| 43 | 576p | 100Hz | 16:9 | |
-| 44 | 576i | 100Hz | 4:3 | |
-| 45 | 576i | 100Hz | 16:9 | |
-| 46 | 1080i | 120Hz | 16:9 | |
-| 47 | 720p | 120Hz | 16:9 | |
-| 48 | 480p | 120Hz | 4:3 | |
-| 49 | 480p | 120Hz | 16:9 | |
-| 50 | 480i | 120Hz | 4:3 | |
-| 51 | 480i | 120Hz | 16:9 | |
-| 52 | 576p | 200Hz | 4:3 | |
-| 53 | 576p | 200Hz | 16:9 | |
-| 54 | 576i | 200Hz | 4:3 | |
-| 55 | 576i | 200Hz | 16:9 | |
-| 56 | 480p | 240Hz | 4:3 | |
-| 57 | 480p | 240Hz | 16:9 | |
-| 58 | 480i | 240Hz | 4:3 | |
-| 59 | 480i | 240Hz | 16:9 | |
-| 60 | 720p | 24Hz | 16:9 | |
-| 61 | 720p | 25Hz | 16:9 | |
-| 62 | 720p | 30Hz | 16:9 | |
-| 63 | 1080p | 120Hz | 16:9 | |
-| 64 | 1080p | 100Hz | 16:9 | |
-| 65 | Custom | | | |
-| 66 | 720p | 25Hz | 64:27 | Pi 4|
-| 67 | 720p | 30Hz | 64:27 | Pi 4 |
-| 68 | 720p | 50Hz | 64:27 | Pi 4 |
-| 69 | 720p | 60Hz | 64:27 | Pi 4 |
-| 70 | 720p | 100Hz | 64:27 | Pi 4 |
-| 71 | 720p | 120Hz | 64:27 | Pi 4 |
-| 72 | 1080p | 24Hz | 64:27 | Pi 4 |
-| 73 | 1080p | 25Hz | 64:27 | Pi 4 |
-| 74 | 1080p | 30Hz | 64:27 | Pi 4 |
-| 75 | 1080p | 50Hz | 64:27 | Pi 4 |
-| 76 | 1080p | 60Hz | 64:27 | Pi 4 |
-| 77 | 1080p | 100Hz | 64:27 | Pi 4 |
-| 78 | 1080p | 120Hz | 64:27 | Pi 4 |
-| 79 | 1680x720 | 24Hz | 64:27 | Pi 4 |
-| 80 | 1680x720 | 25z | 64:27 | Pi 4 |
-| 81 | 1680x720 | 30Hz | 64:27 | Pi 4 |
-| 82 | 1680x720 | 50Hz | 64:27 | Pi 4 |
-| 83 | 1680x720 | 60Hz | 64:27 | Pi 4 |
-| 84 | 1680x720 | 100Hz | 64:27 | Pi 4 |
-| 85 | 1680x720 | 120Hz | 64:27 | Pi 4 |
-| 86 | 2560x720 | 24Hz | 64:27 | Pi 4 |
-| 87 | 2560x720 | 25Hz | 64:27| Pi 4 |
-| 88 | 2560x720 | 30Hz | 64:27 | Pi 4 |
-| 89 | 2560x720 | 50Hz | 64:27 | Pi 4 |
-| 90 | 2560x720 | 60Hz | 64:27 | Pi 4 |
-| 91 | 2560x720| 100Hz | 64:27 | Pi 4 |
-| 92 | 2560x720 | 120Hz | 64:27 | Pi 4 |
-| 93 | 2160p | 24Hz | 16:9 | Pi 4 |
-| 94 | 2160p | 25Hz | 16:9 | Pi 4 |
-| 95 | 2160p | 30Hz | 16:9 | Pi 4 |
-| 96 | 2160p | 50Hz | 16:9 | Pi 4|
-| 97 | 2160p | 60Hz | 16:9 | Pi 4|
-| 98 | 4096x2160 | 24Hz | 256:135 | Pi 4 |
-| 99 | 4096x2160 | 25Hz | 256:135 | Pi 4 |
-| 100 | 4096x2160 | 30Hz | 256:135 | Pi 4 |
-| 101 | 4096x2160 | 50Hz | 256:135 | Pi 4 |
-| 102 | 4096x2160 | 60Hz | 256:135 | Pi 4 |
-| 103 | 2160p | 24Hz | 64:27 | Pi 4 |
-| 104 | 2160p | 25Hz | 64:27 | Pi 4 |
-| 105 | 2160p | 30Hz | 64:27 | Pi 4 |
-| 106 | 2160p | 50Hz | 64:27 | Pi 4 |
-| 107 | 2160p | 60Hz | 64:27 | Pi 4 |
-
-Pixel doubling and quadrupling indicates a higher clock rate, with each pixel repeated two or four times respectively.
-
-These values are valid if `hdmi_group=2` (DMT):
-
-| hdmi_mode | Resolution | Frequency | Screen Aspect | Notes |
-| --------- | --------- | ----------| :-----------: |------ |
-| 1 | 640x350 | 85Hz | | |
-| 2 | 640x400 | 85Hz | 16:10 | |
-| 3 | 720x400 | 85Hz | | |
-| 4 | 640x480 | 60Hz | 4:3 | |
-| 5 | 640x480 | 72Hz | 4:3 | |
-| 6 | 640x480 | 75Hz | 4:3 | |
-| 7 | 640x480 | 85Hz | 4:3 | |
-| 8 | 800x600 | 56Hz | 4:3 | |
-| 9 | 800x600 | 60Hz | 4:3 | |
-| 10 | 800x600 | 72Hz | 4:3 | |
-| 11 | 800x600 | 75Hz | 4:3 | |
-| 12 | 800x600 | 85Hz | 4:3 | |
-| 13 | 800x600 | 120Hz | 4:3 | |
-| 14 | 848x480 | 60Hz |16:9| |
-| 15 | 1024x768 | 43Hz | 4:3 |incompatible with the Raspberry Pi |
-| 16 | 1024x768 | 60Hz | 4:3 | |
-| 17 | 1024x768 | 70Hz | 4:3 | |
-| 18 | 1024x768 | 75Hz | 4:3 | |
-| 19 | 1024x768 | 85Hz | 4:3 | |
-| 20 | 1024x768 | 120Hz | 4:3 | |
-| 21 | 1152x864 | 75Hz | 4:3 | |
-| 22 | 1280x768 | 60Hz| 15:9 | reduced blanking |
-| 23 | 1280x768 | 60Hz | 15:9 | |
-| 24 | 1280x768 | 75Hz | 15:9 | |
-| 25 | 1280x768 | 85Hz | 15:9 | |
-| 26 | 1280x768 | 120Hz | 15:9 | reduced blanking |
-| 27 | 1280x800 | 60 | 16:10 | reduced blanking |
-| 28 | 1280x800 | 60Hz | 16:10 | |
-| 29 | 1280x800 | 75Hz | 16:10 | |
-| 30 | 1280x800 | 85Hz | 16:10 | |
-| 31 | 1280x800 | 120Hz | 16:10 |reduced blanking |
-| 32 | 1280x960 | 60Hz | 4:3 | |
-| 33 | 1280x960 | 85Hz | 4:3 | |
-| 34 | 1280x960 | 120Hz | 4:3 |reduced blanking |
-| 35 | 1280x1024 | 60Hz | 5:4 | |
-| 36 | 1280x1024 | 75Hz | 5:4 | |
-| 37 | 1280x1024 | 85Hz | 5:4 | |
-| 38 | 1280x1024 | 120Hz | 5:4 | reduced blanking |
-| 39 | 1360x768 | 60Hz | 16:9 | |
-| 40 | 1360x768 | 120Hz | 16:9 | reduced blanking |
-| 41 | 1400x1050 | 60Hz| 4:3 | reduced blanking |
-| 42 | 1400x1050 | 60Hz | 4:3 | |
-| 43 | 1400x1050 | 75Hz | 4:3 | |
-| 44 | 1400x1050 | 85Hz | 4:3 | |
-| 45 | 1400x1050 | 120Hz | 4:3 | reduced blanking |
-| 46 | 1440x900 | 60Hz | 16:10 | reduced blanking |
-| 47 | 1440x900 | 60Hz | 16:10 | |
-| 48 | 1440x900 | 75Hz | 16:10 | |
-| 49 | 1440x900 | 85Hz | 16:10 | |
-| 50 | 1440x900 | 120Hz | 16:10 |reduced blanking |
-| 51 | 1600x1200 | 60Hz | 4:3 | |
-| 52 | 1600x1200 | 65Hz | 4:3 | |
-| 53 | 1600x1200 | 70Hz | 4:3 | |
-| 54 | 1600x1200 | 75Hz | 4:3 | |
-| 55 | 1600x1200 | 85Hz | 4:3 | |
-| 56 | 1600x1200 | 120Hz | 4:3 | reduced blanking |
-| 57 | 1680x1050 | 60Hz | 16:10 | reduced blanking |
-| 58 | 1680x1050 | 60Hz | 16:10 | |
-| 59 | 1680x1050 | 75Hz | 16:10 | |
-| 60 | 1680x1050 | 85Hz | 16:10 | |
-| 61 | 1680x1050 | 120Hz | 16:10 | reduced blanking |
-| 62 | 1792x1344 | 60Hz | 4:3 | |
-| 63 | 1792x1344 | 75Hz | 4:3 | |
-| 64 | 1792x1344 | 120Hz | 4:3 | reduced blanking |
-| 65 | 1856x1392 | 60Hz | 4:3 | |
-| 66 | 1856x1392 | 75Hz | 4:3 | |
-| 67 | 1856x1392 | 120Hz | 4:3 | reduced blanking |
-| 68 | 1920x1200 | 60Hz | 16:10 |reduced blanking |
-| 69 | 1920x1200 | 60Hz | 16:10 | |
-| 70 | 1920x1200 | 75Hz | 16:10 | |
-| 71 | 1920x1200 | 85Hz | 16:10 | |
-| 72 | 1920x1200 | 120Hz | 16:10 |reduced blanking |
-| 73 | 1920x1440 | 60Hz | 4:3 | |
-| 74 | 1920x1440 | 75Hz | 4:3 | |
-| 75 | 1920x1440 | 120Hz | 4:3 | reduced blanking |
-| 76 | 2560x1600 | 60Hz| 16:10 | reduced blanking |
-| 77 | 2560x1600 | 60Hz | 16:10 | |
-| 78 | 2560x1600 | 75Hz | 16:10 | |
-| 79 | 2560x1600 | 85Hz | 16:10 | |
-| 80 | 2560x1600 | 120Hz | 16:10 | reduced blanking |
-| 81 | 1366x768 | 60Hz | 16:9 | [NOT on Pi4](./pi4-hdmi.md) |
-| 82 | 1920x1080 | 60Hz | 16:9 | 1080p |
-| 83 | 1600x900 | 60Hz | 16:9 | reduced blanking |
-| 84 | 2048x1152 | 60Hz | 16:9 | reduced blanking |
-| 85 | 1280x720 | 60Hz | 16:9 | 720p |
-| 86 | 1366x768 | 60Hz | 16:9 | reduced blanking |
-
-Note that there is a [pixel clock limit](https://www.raspberrypi.org/forums/viewtopic.php?f=26&t=20155&p=195443#p195443).The highest supported mode on models prior to the Raspberry Pi 4 is 1920x1200 at 60Hz with reduced blanking, whilst the Raspberry Pi 4 can support up to 4096x2160 (known as 4k) at 60Hz. Also note that if you are using both HDMI ports of the Raspberry Pi 4 for 4k output, then you are limited to 30Hz on both.
-
-### hdmi_timings
-
-This allows setting of raw HDMI timing values for a custom mode, selected using `hdmi_group=2` and `hdmi_mode=87`.
-
-```
-hdmi_timings=
-```
-
-```
- = horizontal pixels (width)
- = invert hsync polarity
- = horizontal forward padding from DE acitve edge
- = hsync pulse width in pixel clocks
- = vertical back padding from DE active edge
- = vertical pixels height (lines)
- = invert vsync polarity
- = vertical forward padding from DE active edge
- = vsync pulse width in pixel clocks
- = vertical back padding from DE active edge
- = leave at zero
- = leave at zero
- = leave at zero
- = screen refresh rate in Hz
- = leave at zero
- = clock frequency (width*height*framerate)
- = *
-```
-
-`*` The aspect ratio can be set to one of eight values (choose the closest for your screen):
-
-```
-HDMI_ASPECT_4_3 = 1
-HDMI_ASPECT_14_9 = 2
-HDMI_ASPECT_16_9 = 3
-HDMI_ASPECT_5_4 = 4
-HDMI_ASPECT_16_10 = 5
-HDMI_ASPECT_15_9 = 6
-HDMI_ASPECT_21_9 = 7
-HDMI_ASPECT_64_27 = 8
-```
-
-### hdmi_force_mode
-
-Setting to `1` will remove all other modes except the ones specified by `hdmi_mode` and `hdmi_group` from the internal list, meaning they will not appear in any enumerated lists of modes. This option may help if a display seems to be ignoring the `hdmi_mode` and `hdmi_group` settings.
-
-### edid_content_type
-
-Forces the EDID content type to a specific value.
-
-The options are:
- - `0` = `EDID_ContentType_NODATA`, content type none.
- - `1` = `EDID_ContentType_Graphics`, content type graphics, ITC must be set to 1
- - `2` = `EDID_ContentType_Photo`, content type photo
- - `3` = `EDID_ContentType_Cinema`, content type cinema
- - `4` = `EDID_ContentType_Game`, content type game
-
-### hdmi_enable_4kp60 (Pi 4B only)
-
-By default, when connected to a 4K monitor, the Raspberry Pi 4B will select a 30hz refresh rate. Use this option to allow selection of 60Hz refresh rates. Note, this will increase power consumption and increase the temperature of the Raspberry Pi. It is not possible to output 4Kp60 on both micro HDMI ports simultaneously.
-
-## Which values are valid for my monitor?
-
-Your HDMI monitor may only support a limited set of formats. To find out which formats are supported, use the following method:
-
- 1. Set the output format to VGA 60Hz (`hdmi_group=1` and `hdmi_mode=1`) and boot up your Raspberry Pi
- 1. Enter the following command to give a list of CEA-supported modes: `/opt/vc/bin/tvservice -m CEA`
- 1. Enter the following command to give a list of DMT-supported modes: `/opt/vc/bin/tvservice -m DMT`
- 1. Enter the following command to show your current state: `/opt/vc/bin/tvservice -s`
- 1. Enter the following commands to dump more detailed information from your monitor: `/opt/vc/bin/tvservice -d edid.dat; /opt/vc/bin/edidparser edid.dat`
-
-The `edid.dat` should also be provided when troubleshooting problems with the default HDMI mode.
-
-## Custom mode
-
-If your monitor requires a mode that is not in one of the tables above, then it's possible to define a custom [CVT](https://en.wikipedia.org/wiki/Coordinated_Video_Timings) mode for it instead:
-
-```
-hdmi_cvt=
-```
-
-| Value | Default | Description |
-| --- | --- | --- |
-| width | (required) | width in pixels |
-| height | (required) | height in pixels |
-| framerate | (required) | framerate in Hz |
-| aspect | 3 | aspect ratio 1=4:3, 2=14:9, 3=16:9, 4=5:4, 5=16:10, 6=15:9 |
-| margins | 0 | 0=margins disabled, 1=margins enabled |
-| interlace | 0 | 0=progressive, 1=interlaced |
-| rb | 0 | 0=normal, 1=reduced blanking |
-
-Fields at the end can be omitted to use the default values.
-
-Note that this simply **creates** the mode (group 2 mode 87). In order to make the Pi use this by default, you must add some additional settings. For example, the following selects an 800 × 480 resolution and enables audio drive:
-
-```
-hdmi_cvt=800 480 60 6
-hdmi_group=2
-hdmi_mode=87
-hdmi_drive=2
-```
-
-This may not work if your monitor does not support standard CVT timings.
-
-## LCD display/touchscreen options
-
-### ignore_lcd
-
-By default the Raspberry Pi LCD display is used when it is detected on the I2C bus. `ignore_lcd=1` will skip this detection phase, and therefore the LCD display will not be used.
-
-### display_default_lcd
-
-If a Raspberry Pi DSI LCD is detected it will be used as the default display and will show the framebuffer. Setting `display_default_lcd=0` will ensure the LCD is not the default display, which usually implies the HDMI output will be the default. The LCD can still be used by choosing its display number from supported applications, for example, omxplayer.
-
-### lcd_framerate
-
-Specify the framerate of the Raspberry Pi LCD display, in Hertz/fps. Defaults to 60Hz.
-
-### lcd_rotate
-
-This flips the display using the LCD's inbuilt flip functionality, which is a cheaper operation that using the GPU-based rotate operation.
-
-For example, `lcd_rotate=2` will compensate for an upside down display.
-
-### disable_touchscreen
-
-Enable/disable the touchscreen.
-
-`disable_touchscreen=1` will disable the touchscreen on the official Raspberry Pi LCD display.
-
-### enable_dpi_lcd
-
-Enable LCD displays attached to the DPI GPIOs. This is to allow the use of third-party LCD displays using the parallel display interface.
-
-### dpi_group, dpi_mode, dpi_output_format
-
-The `dpi_group` and `dpi_mode` config.txt parameters are used to set either predetermined modes (DMT or CEA modes as used by HDMI above). A user can generate custom modes in much the same way as for HDMI (see `dpi_timings` section).
-
-`dpi_output_format` is a bitmask specifying various parameters used to set up the display format.
-
-More details on using the DPI modes and the output format can be found [here](../../hardware/raspberrypi/dpi/README.md).
-
-### dpi_timings
-
-This allows setting of raw DPI timing values for a custom mode, selected using `dpi_group=2` and `dpi_mode=87`.
-
-```
-dpi_timings=
-```
-
-```
- = horizontal pixels (width)
- = invert hsync polarity
- = horizontal forward padding from DE acitve edge
- = hsync pulse width in pixel clocks
- = vertical back padding from DE active edge
- = vertical pixels height (lines)
- = invert vsync polarity
- = vertical forward padding from DE active edge
- = vsync pulse width in pixel clocks
- = vertical back padding from DE active edge
- = leave at zero
- = leave at zero
- = leave at zero
- = screen refresh rate in Hz
- = leave at zero
- = clock frequency (width*height*framerate)
- = *
-```
-
-`*` The aspect ratio can be set to one of eight values (choose the closest for your screen):
-
-```
-HDMI_ASPECT_4_3 = 1
-HDMI_ASPECT_14_9 = 2
-HDMI_ASPECT_16_9 = 3
-HDMI_ASPECT_5_4 = 4
-HDMI_ASPECT_16_10 = 5
-HDMI_ASPECT_15_9 = 6
-HDMI_ASPECT_21_9 = 7
-HDMI_ASPECT_64_27 = 8
-```
-
-## Generic display options
-
-### hdmi_force_hotplug
-
-Setting `hdmi_force_hotplug` to `1` pretends that the HDMI hotplug signal is asserted, so it appears that a HDMI display is attached. In other words, HDMI output mode will be used, even if no HDMI monitor is detected.
-
-### hdmi_ignore_hotplug
-
-Setting `hdmi_ignore_hotplug` to `1` pretends that the HDMI hotplug signal is not asserted, so it appears that a HDMI display is not attached. In other words, composite output mode will be used, even if an HDMI monitor is detected.
-
-### disable_overscan
-
-Set `disable_overscan` to `1` to disable the default values of [overscan](../raspi-config.md#overscan) that is set by the firmware. The default value of overscan for the left, right, top, and bottom edges is `48` for HD CEA modes, `32` for SD CEA modes, and `0` for DMT modes. The default value for `disable_overscan` is `0`.
-
-**NOTE:** any further additional overscan options such as `overscan_scale` or overscan edges can still be applied after this option.
-
-### overscan_left
-
-The `overscan_left` command specifies the number of pixels to add to the firmware default value of overscan on the left edge of the screen. The default value is `0`.
-
-Increase this value if the text flows off the left edge of the screen; decrease it if there is a black border between the left edge of the screen and the text.
-
-### overscan_right
-
-The `overscan_right` command specifies the number of pixels to add to the firmware default value of overscan on the right edge of the screen. The default value is `0`.
-
-Increase this value if the text flows off the right edge of the screen; decrease it if there is a black border between the right edge of the screen and the text.
-
-### overscan_top
-
-The `overscan_top` command specifies the number of pixels to add to the firmware default value of overscan on the top edge of the screen. The default value is `0`.
-
-Increase this value if the text flows off the top edge of the screen; decrease it if there is a black border between the top edge of the screen and the text.
-
-### overscan_bottom
-
-The `overscan_bottom` command specifies the number of pixels to add to the firmware default value of overscan on the bottom edge of the screen. The default value is `0`.
-
-Increase this value if the text flows off the bottom edge of the screen; decrease it if there is a black border between the bottom edge of the screen and the text.
-
-### overscan_scale
-
-Set `overscan_scale` to `1` to force any non-framebuffer layers to conform to the overscan settings. The default value is `0`.
-
-**NOTE:** this feature is generally not recommended: it can reduce image quality because all layers on the display will be scaled by the GPU. Disabling overscan on the display itself is the recommended option to avoid images being scaled twice (by the GPU and the display).
-
-### framebuffer_width
-
-The `framebuffer_width` command specifies the console framebuffer width in pixels. The default is the display width minus the total horizontal overscan.
-
-### framebuffer_height
-
-The `framebuffer_height` command specifies the console framebuffer height in pixels. The default is the display height minus the total vertical overscan.
-C4
-### max_framebuffer_height, max_framebuffer_width
-
-Specifies the maximum dimensions that the internal frame buffer is allowed to be.
-
-### framebuffer_depth
-
-Use `framebuffer_depth` to specify the console framebuffer depth in bits per pixel. The default value is `16`.
-
-| framebuffer_depth | result | notes |
-| --- | --- | --- |
-| 8 | 8bit framebuffer | Default RGB palette makes screen unreadable |
-| 16 | 16bit framebuffer | |
-| 24 | 24bit framebuffer | May result in a corrupted display |
-| 32 | 32bit framebuffer | May need to be used in conjunction with `framebuffer_ignore_alpha=1` |
-
-### framebuffer_ignore_alpha
-
-Set `framebuffer_ignore_alpha` to `1` to disable the alpha channel. Can help with the display of a 32bit `framebuffer_depth`.
-
-### framebuffer_priority
-
-In a system with multiple displays, using the legacy (pre-KMS) graphics driver, this forces a specific internal display device to be the first Linux framebuffer (i.e./dev/fb0).
-
-The options that can be set are:
-
-| Display | ID |
-| --- | --- |
-|Main LCD | 0 |
-|Secondary LCD | 1 |
-|HDMI 0 | 2 |
-|Composite | 3 |
-|HDMI 1 | 7 |
-
-### max_framebuffers
-
-This configuration entry sets the maximum number of firmware framebuffers that can be created. Valid options are 0,1, and 2. By default on devices before the Pi4 this is set to 1, so will need to be increased to 2 when using more than one display, for example HDMI and a DSI or DPI display. The Raspberry Pi4 configuration sets this to 2 by default as it has two HDMI ports.
-
-Generally in most cases it is safe to set this to 2, as framebuffers will only be created when an attached device is actually detected.
-
-Setting this value to 0 can be used to reduce memory requirements when used in headless mode as it will prevent any framebuffers from being allocated.
-
-### test_mode
-
-The `test_mode` command displays a test image and sound during boot (over the composite video and analogue audio outputs only) for the given number of seconds, before continuing to boot the OS as normal. This is used as a manufacturing test; the default value is `0`.
-
-### display_hdmi_rotate
-
-Use `display_hdmi_rotate` to rotate or flip the HDMI display orientation. The default value is `0`.
-
-| display_hdmi_rotate | result |
-| --- | --- |
-| 0 | no rotation |
-| 1 | rotate 90 degrees clockwise |
-| 2 | rotate 180 degrees clockwise |
-| 3 | rotate 270 degrees clockwise |
-| 0x10000 | horizontal flip |
-| 0x20000 | vertical flip |
-
-Note that the 90 and 270 degree rotation options require additional memory on the GPU, so these will not work with the 16MB GPU split.
-
-If using the VC4 FKMS V3D driver (this is the default on the Raspberry Pi 4), then 90 and 270 degree rotations are not supported. The Screen Configuration utility provides display rotations for this driver. See this [page](../display_rotation.md) for more information.
-
-### display_lcd_rotate
-
-For the legacy graphics driver (default on models prior to the Pi4), use `display_lcd_rotate` to rotate or flip the LCD orientation. Parameters are the same as `display_hdmi_rotate`. See also `lcd_rotate`.
-
-### display_rotate
-
-`display_rotate` is deprecated in the latest firmware but has been retained for backwards compatibility. Please use `display_lcd_rotate` and `display_hdmi_rotate` instead.
-
-Use `display_rotate` to rotate or flip the screen orientation. Parameters are the same as `display_hdmi_rotate`.
-
-### disable_fw_kms_setup
-
-By default, the firmware parses the EDID of any HDMI attached display, picks an appropriate video mode, then passes the resolution and frame rate of the mode, along with overscan parameters, to the Linux kernel via settings on the kernel command line. In rare circumstances, this can have the effect of choosing a mode that is not in the EDID, and may be incompatible with the device. You can use `disable_fw_kms_setup=1` to disable the passing of these parameters and avoid this problem. The Linux video mode system (KMS) will then parse the EDID itself and pick an appropriate mode.
-
-## Other options
-
-### dispmanx_offline
-
-Forces dispmanx composition to be done offline in two offscreen framebuffers. This can allow more dispmanx elements to be composited, but is slower and may limit screen framerate to typically 30fps.
-
-*This article uses content from the eLinux wiki page [RPiconfig](http://elinux.org/RPiconfig), which is shared under the [Creative Commons Attribution-ShareAlike 3.0 Unported license](http://creativecommons.org/licenses/by-sa/3.0/)*
diff --git a/configuration/device-tree.md b/configuration/device-tree.md
deleted file mode 100644
index 1f8dbcd09a..0000000000
--- a/configuration/device-tree.md
+++ /dev/null
@@ -1,982 +0,0 @@
-# Device Trees, overlays, and parameters
-
-Raspberry Pi kernels and firmware use a Device Tree (DT) to describe the hardware present in the Pi. These Device Trees may include DT parameters that provide a degree of control over some onboard features. DT overlays allow optional external hardware to be described and configured, and they also support parameters for more control.
-
-The firmware loader (`start.elf` and its variants) is responsible for loading the DTB (Device Tree Blob - a machine readable DT file). It chooses which one to load based on the board revision number, and makes certain modifications to further tailor it (memory size, Ethernet addresses etc.). This runtime customisation avoids the need for lots of DTBs with only minor differences.
-
-`config.txt` is scanned for user-provided parameters, along with any overlays and their parameters, which are then applied. The loader examines the result to learn (for example) which UART, if any, is to be used for the console. Finally it launches the kernel, passing a pointer to the merged DTB.
-
-
-## Device Trees
-
-A Device Tree (DT) is a description of the hardware in a system. It should include the name of the base CPU, its memory configuration, and any peripherals (internal and external). A DT should not be used to describe the software, although by listing the hardware modules it does usually cause driver modules to be loaded. It helps to remember that DTs are supposed to be OS-neutral, so anything which is Linux-specific probably shouldn't be there.
-
-A Device Tree represents the hardware configuration as a hierarchy of nodes. Each node may contain properties and subnodes. Properties are named arrays of bytes, which may contain strings, numbers (big-endian), arbitrary sequences of bytes, and any combination thereof. By analogy to a filesystem, nodes are directories and properties are files. The locations of nodes and properties within the tree can be described using a path, with slashes as separators and a single slash (`/`) to indicate the root.
-
-
-### 1.1: Basic DTS syntax
-
-Device Trees are usually written in a textual form known as Device Tree Source (DTS) and stored in files with a `.dts` suffix. DTS syntax is C-like, with braces for grouping and semicolons at the end of each line. Note that DTS requires semicolons after closing braces: think of C `struct`s rather than functions. The compiled binary format is referred to as Flattened Device Tree (FDT) or Device Tree Blob (DTB), and is stored in `.dtb` files.
-
-The following is a simple tree in the `.dts` format:
-
-```
-/dts-v1/;
-/include/ "common.dtsi";
-
-/ {
- node1 {
- a-string-property = "A string";
- a-string-list-property = "first string", "second string";
- a-byte-data-property = [0x01 0x23 0x34 0x56];
- cousin: child-node1 {
- first-child-property;
- second-child-property = <1>;
- a-string-property = "Hello, world";
- };
- child-node2 {
- };
- };
- node2 {
- an-empty-property;
- a-cell-property = <1 2 3 4>; /* each number (cell) is a uint32 */
- child-node1 {
- my-cousin = <&cousin>;
- };
- };
-};
-
-/node2 {
- another-property-for-node2;
-};
-```
-
-This tree contains:
-
- - a required header: `/dts-v1/`.
- - The inclusion of another DTS file, conventionally named `*.dtsi` and analogous to a `.h` header file in C - see _An aside about /include/_ below.
- - a single root node: `/`
- - a couple of child nodes: `node1` and `node2`
- - some children for node1: `child-node1` and `child-node2`
- - a label (`cousin`) and a reference to that label (`&cousin`): see _Labels and References_ below.
- - several properties scattered through the tree
- - a repeated node (`/node2`) - see _An aside about /include/_ below.
-
-Properties are simple key-value pairs where the value can either be empty or contain an arbitrary byte stream. While data types are not encoded in the data structure, there are a few fundamental data representations that can be expressed in a Device Tree source file.
-
-Text strings (NUL-terminated) are indicated with double quotes:
-
-```
-string-property = "a string";
-```
-
-Cells are 32-bit unsigned integers delimited by angle brackets:
-
-```
-cell-property = <0xbeef 123 0xabcd1234>;
-```
-
-Arbitrary byte data is delimited with square brackets, and entered in hex:
-
-```
-binary-property = [01 23 45 67 89 ab cd ef];
-```
-
-Data of differing representations can be concatenated using a comma:
-
-```
-mixed-property = "a string", [01 23 45 67], <0x12345678>;
-```
-
-Commas are also used to create lists of strings:
-
-```
-string-list = "red fish", "blue fish";
-```
-
-
-### 1.2: An aside about /include/
-
-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 appearance of `/node2` causes a new property to be added to the original:
-
-```
-/node2 {
- an-empty-property;
- a-cell-property = <1 2 3 4>; /* each number (cell) is a uint32 */
- another-property-for-node2;
- child-node1 {
- my-cousin = <&cousin>;
- };
-};
-```
-
-It is thus possible for one `.dtsi` to overwrite, or provide defaults for, multiple places in a tree.
-
-
-### 1.3: Labels and references
-
-It is often necessary for one part of the tree to refer to another, and there are four ways to do this:
-
-1. Path strings
-
- Paths should be self-explanatory, by analogy with a filesystem - `/soc/i2s@7e203000` is the full path to the I2S device in BCM2835 and BCM2836. Note that although it is easy to construct a path to a property (for example, `/soc/i2s@7e203000/status`), the standard APIs don't do that; you first find a node, then choose properties of that node.
-
-1. phandles
-
- A phandle is a unique 32-bit integer assigned to a node in its `phandle` property. For historical reasons, you may also see a redundant, matching `linux,phandle`. phandles are numbered sequentially, starting from 1; 0 is not a valid phandle. They are usually allocated by the DT compiler when it encounters a reference to a node in an integer context, usually in the form of a label (see below). References to nodes using phandles are simply encoded as the corresponding integer (cell) values; there is no markup to indicate that they should be interpreted as phandles, as that is application-defined.
-
-1. Labels
-
- Just as a label in C gives a name to a place in the code, a DT label assigns a name to a node in the hierarchy. The compiler takes references to labels and converts them into paths when used in string context (`&node`) and phandles in integer context (`<&node>`); the original labels do not appear in the compiled output. Note that labels contain no structure; they are just tokens in a flat, global namespace.
-
-1. Aliases
-
- Aliases are similar to labels, except that they do appear in the FDT output as a form of index. They are stored as properties of the `/aliases` node, with each property mapping an alias name to a path string. Although the aliases node appears in the source, the path strings usually appear as references to labels (`&node`), rather then being written out in full. DT APIs that resolve a path string to a node typically look at the first character of the path, treating paths that do not start with a slash as aliases that must first be converted to a path using the `/aliases` table.
-
-
-### 1.4: Device Tree semantics
-
-How to construct a Device Tree, and how best to use it to capture the configuration of some hardware, is a large and complex subject. There are many resources available, some of which are listed below, but several points deserve mentioning in this document:
-
-`compatible` properties are the link between the hardware description and the driver software. When an OS encounters a node with a `compatible` property, it looks it up in its database of device drivers to find the best match. In Linux, this usually results in the driver module being automatically loaded, provided it has been appropriately labelled and not blacklisted.
-
-The `status` property indicates whether a device is enabled or disabled. If the `status` is `ok`, `okay` or absent, then the device is enabled. Otherwise, `status` should be `disabled`, so that the device is disabled. It can be useful to place devices in a `.dtsi` file with the status set to `disabled`. A derived configuration can then include that `.dtsi` and set the status for the devices which are needed to `okay`.
-
-
-## Part 2: Device Tree overlays
-
-A modern SoC (System on a Chip) is a very complicated device; a complete Device Tree could be hundreds of lines long. Taking that one step further and placing the SoC on a board with other components only makes matters worse. To keep that manageable, particularly if there are related devices that share components, it makes sense to put the common elements in `.dtsi` files, to be included from possibly multiple `.dts` files.
-
-When a system like Raspberry Pi also supports optional plug-in accessories such as HATs, the problem grows. Ultimately, each possible configuration requires a Device Tree to describe it, but once you factor in all the different base models and the large number of available accessories, the number of combinations starts to multiply rapidly.
-
-What is needed is a way to describe these optional components using a partial Device Tree, and then to be able to build a complete tree by taking a base DT and adding a number of optional elements. You can do this, and these optional elements are called "overlays".
-
-Unless you want to learn how to write overlays for Raspberry Pis, you might prefer to skip on to [Part 3: Using Device Trees on Raspberry Pi](#part3).
-
-
-### 2.1: Fragments
-
-A DT overlay comprises a number of fragments, each of which targets one node and its subnodes. Although the concept sounds simple enough, the syntax seems rather strange at first:
-
-```
-// Enable the i2s interface
-/dts-v1/;
-/plugin/;
-
-/ {
- compatible = "brcm,bcm2835";
-
- fragment@0 {
- target = <&i2s>;
- __overlay__ {
- status = "okay";
- test_ref = <&test_label>;
- test_label: test_subnode {
- dummy;
- };
- };
- };
-};
-```
-
-The `compatible` string identifies this as being for BCM2835, which is the base architecture for the Raspberry Pi SoCs; if the overlay makes use of features of a Pi 4 then `brcm,bcm2711` is the correct value to use, otherwise `brcm,bcm2835` can be used for all Pi overlays. Then comes the first (and in this case only) fragment. Fragments should be numbered sequentially from zero. Failure to adhere to this may cause some or all of your fragments to be missed.
-
-Each fragment consists of two parts: a `target` property, identifying the node to apply the overlay to; and the `__overlay__` itself, the body of which is added to the target node. The example above can be interpreted as if it were written like this:
-
-```
-/dts-v1/;
-/plugin/;
-
-/ {
- compatible = "brcm,bcm2835";
-};
-
-&i2s {
- status = "okay";
- test_ref = <&test_label>;
- test_label: test_subnode {
- dummy;
- };
-};
-```
-(In fact, with a sufficiently new version of `dtc` you can write it exactly like that and get identical output, but some homegrown tools don't understand this format yet so any overlay that you might want to be included in the standard Raspberry Pi OS kernel should be written in the old format for now).
-
-The effect of merging that overlay with a standard Raspberry Pi base Device Tree (e.g. `bcm2708-rpi-b-plus.dtb`), provided the overlay is loaded afterwards, would be to enable the I2S interface by changing its status to `okay`. But if you try to compile this overlay using:
-
-```
-dtc -I dts -O dtb -o 2nd.dtbo 2nd-overlay.dts
-```
-
-you will get an error:
-
-```
-Label or path i2s not found
-```
-
-This shouldn't be too unexpected, since there is no reference to the base `.dtb` or `.dts` file to allow the compiler to find the `i2s` label.
-
-Trying again, this time using the original example and adding the `-@` option to allow unresolved references (and `-Hepapr` to remove some clutter):
-
-```
-dtc -@ -Hepapr -I dts -O dtb -o 1st.dtbo 1st-overlay.dts
-```
-
-If `dtc` returns an error about the third line, it doesn't have the extensions required for overlay work. Run `sudo apt install device-tree-compiler` and try again - this time, compilation should complete successfully. Note that a suitable compiler is also available in the kernel tree as `scripts/dtc/dtc`, built when the `dtbs` make target is used:
-```
-make ARCH=arm dtbs
-```
-
-It is interesting to dump the contents of the DTB file to see what the compiler has generated:
-
-```
-$ fdtdump 1st.dtbo
-/dts-v1/;
-// magic: 0xd00dfeed
-// totalsize: 0x207 (519)
-// off_dt_struct: 0x38
-// off_dt_strings: 0x1c8
-// off_mem_rsvmap: 0x28
-// version: 17
-// last_comp_version: 16
-// boot_cpuid_phys: 0x0
-// size_dt_strings: 0x3f
-// size_dt_struct: 0x190
-
-/ {
- compatible = "brcm,bcm2835";
- fragment@0 {
- target = <0xffffffff>;
- __overlay__ {
- status = "okay";
- test_ref = <0x00000001>;
- test_subnode {
- dummy;
- phandle = <0x00000001>;
- };
- };
- };
- __symbols__ {
- test_label = "/fragment@0/__overlay__/test_subnode";
- };
- __fixups__ {
- i2s = "/fragment@0:target:0";
- };
- __local_fixups__ {
- fragment@0 {
- __overlay__ {
- test_ref = <0x00000000>;
- };
- };
- };
-};
-```
-
-After the verbose description of the file structure there is our fragment. But look carefully - where we wrote `&i2s` it now says `0xffffffff`, a clue that something strange has happened (older versions of dtc might say `0xdeadbeef` instead). The compiler has also added a `phandle` property containing a unique (to this overlay) small integer to indicate that the node has a label, and replaced all references to the label with the same small integer.
-
-After the fragment there are three new nodes:
-* `__symbols__` lists the labels used in the overlay (`test_label` here), and the path to the labelled node. This node is the key to how unresolved symbols are dealt with.
-* `__fixups__` contains a list of properties mapping the names of unresolved symbols to lists of paths to cells within the fragments that need patching with the phandle of the target node, once that target has been located. In this case, the path is to the `0xffffffff` value of `target`, but fragments can contain other unresolved references which would require additional fixes.
-* `__local_fixups__` holds the locations of any references to labels that exist within the overlay - the `test_ref` property. This is required because the program performing the merge will have to ensure that phandle numbers are sequential and unique.
-
-Back in [section 1.3](#part1_3) it says that "the original labels do not appear in the compiled output", but this isn't true when using the `-@` switch. Instead, every label results in a property in the `__symbols__` node, mapping a label to a path, exactly like the `aliases` node. In fact, the mechanism is so similar that when resolving symbols, the Raspberry Pi loader will search the "aliases" node in the absence of a `__symbols__` node. This was useful at one time because providing sufficient aliases allowed very old versions of `dtc` to be used to build the base DTB files, but fortunately that is ancient history now.
-
-
-### 2.2: Device Tree parameters
-
-To avoid the need for lots of Device Tree overlays, and to reduce the need for users of peripherals to modify DTS files, the Raspberry Pi loader supports a new feature - Device Tree parameters. This permits small changes to the DT using named parameters, similar to the way kernel modules receive parameters from `modprobe` and the kernel command line. Parameters can be exposed by the base DTBs and by overlays, including HAT overlays.
-
-Parameters are defined in the DTS by adding an `__overrides__` node to the root. It contains properties whose names are the chosen parameter names, and whose values are a sequence comprising a phandle (reference to a label) for the target node, and a string indicating the target property; string, integer (cell) and boolean properties are supported.
-
-
-#### 2.2.1: String parameters
-
-String parameters are declared like this:
-
-```
-name = <&label>,"property";
-```
-
-where `label` and `property` are replaced by suitable values. String parameters can cause their target properties to grow, shrink, or be created.
-
-Note that properties called `status` are treated specially; non-zero/true/yes/on values are converted to the string `"okay"`, while zero/false/no/off becomes `"disabled"`.
-
-
-#### 2.2.2: Integer parameters
-
-Integer parameters are declared like this:
-
-```
-name = <&label>,"property.offset"; // 8-bit
-name = <&label>,"property;offset"; // 16-bit
-name = <&label>,"property:offset"; // 32-bit
-name = <&label>,"property#offset"; // 64-bit
-```
-
-where `label`, `property` and `offset` are replaced by suitable values; the offset is specified in bytes relative to the start of the property (in decimal by default), and the preceding separator dictates the size of the parameter. In a change from earlier implementations, integer parameters may refer to non-existent properties or to offsets beyond the end of an existing property.
-
-
-#### 2.2.3: Boolean parameters
-
-Device Tree encodes boolean values as zero-length properties; if present then the property is true, otherwise it is false. They are defined like this:
-
-```
-boolean_property; // Set 'boolean_property' to true
-```
-
-Note that a property is assigned the value `false` by not defining it. Boolean parameters are declared like this:
-
-```
-name = <&label>,"property?";
-```
-
-where `label` and `property` are replaced by suitable values.
-
-Inverted booleans invert the input value before applying it in the same was as a regular boolean; they are declared similarly, but use `!` to indicate the inversion:
-
-```
-name = <&label>,"property!";
-```
-
-Boolean parameters can cause properties to be created or deleted, but they can't delete a property that already exists in the base DTB.
-
-
-#### 2.2.4: Byte string parameters
-
-Byte string properties are arbitrary sequences of bytes, e.g. MAC addresses. They accept strings of hexadecimal bytes, with or without colons between the bytes.
-
-```
-mac_address = <ðernet0>,"local_mac_address[";
-```
-The `[` was chosen to match the DT syntax for declaring a byte string:
-```
-local_mac_address = [aa bb cc dd ee ff];
-```
-
-
-#### 2.2.5: Parameters with multiple targets
-
-There are some situations where it is convenient to be able to set the same value in multiple locations within the Device Tree. Rather than the ungainly approach of creating multiple parameters, it is possible to add multiple targets to a single parameter by concatenating them, like this:
-
-```
- __overrides__ {
- gpiopin = <&w1>,"gpios:4",
- <&w1_pins>,"brcm,pins:0";
- ...
- };
-```
-
-(example taken from the `w1-gpio` overlay)
-
-Note that it is even possible to target properties of different types with a single parameter. You could reasonably connect an "enable" parameter to a `status` string, cells containing zero or one, and a proper boolean property.
-
-
-#### 2.2.6: Literal assignments
-
-As seen in [2.2.5](#part2.2.5), the DT parameter mechanism allows multiple targets to be patched from the same parameter, but the utility is limited by the fact that the same value has to be written to all locations (except for format conversion and the negation available from inverted booleans). The addition of embedded literal assignments allows a parameter to write arbitrary values, regardless of the parameter value supplied by the user.
-
-Assignments appear at the end of a declaration, and are indicated by a `=`:
-
-```
-str_val = <&target>,"strprop=value"; // 1
-int_val = <&target>,"intprop:0=42 // 2
-int_val2 = <&target>,"intprop:0=",<42>; // 3
-bytes = <&target>,"bytestr[=b8:27:eb:01:23:45"; // 4
-```
-Lines 1, 2 and 4 are fairly obvious, but line 3 is more interesting because the value appears as an integer (cell) value. The DT compiler evaluates integer expressions at compile time, which might be convenient (particularly if macro values are used), but the cell can also contain a reference to a label:
-```
-// Force an LED to use a GPIO on the internal GPIO controller.
-exp_led = <&led1>,"gpios:0=",<&gpio>,
- <&led1>,"gpios:4";
-```
-When the overlay is applied, the label will be resolved against the base DTB in the usual way. Note that it is a good idea to split multi-part parameters over multiple lines like this to make them easier to read - something that becomes more necessary with the addition of cell value assignments like this.
-
-Bear in mind that parameters do nothing unless they are applied - a default value in a lookup table is ignored unless the parameter name is used without assigning a value.
-
-
-#### 2.2.7: Lookup tables
-
-Lookup tables allow parameter input values to be transformed before they are used. They act as associative arrays, rather like switch/case statements:
-```
-phonetic = <&node>,"letter{a=alpha,b=bravo,c=charlie,d,e,='tango uniform'}";
-bus = <&fragment>,"target:0{0=",<&i2c0>,"1=",<&i2c1>,"}";
-```
-A key with no `=value` means to use the key as the value, an `=` with no key before it is the default value in the case of no match, and starting or ending the list with a comma (or an empty key=value pair anywhere) indicates that the unmatched input value should be used unaltered; otherwise, not finding a match is an error.
-
-Note that the comma separator within the table string after a cell integer value is implicit - adding one explicitly creates an empty pair (see above).
-
-N.B. As lookup tables operate on input values and literal assigments ignore them, it's not possible to combine the two - characters after the closing `}` in the lookup declaration are treated as an error.
-
-
-#### 2.2.8 Overlay/fragment parameters
-
-The DT parameter mechanism as described has a number of limitations, including the inability to change the name of a node and to write arbitrary values to arbitrary properties when a parameter is used. One way to overcome some of these limitations is to conditionally include or exclude certain fragments.
-
-A fragment can be excluded from the final merge process (disabled) by renaming the `__overlay__` node to `__dormant__`. The parameter declaration syntax has been extended to allow the otherwise illegal zero target phandle to indicate that the following string contains operations at fragment or overlay scope. So far, four operations have been implemented:
-
-```
-+ // Enable fragment
-- // Disable fragment
-= // Enable fragment if the assigned parameter value is true, otherwise disable it
-! // Enable fragment if the assigned parameter value is false, otherwise disable it
-```
-
-Examples:
-```
-just_one = <0>,"+1-2"; // Enable 1, disable 2
-conditional = <0>,"=3!4"; // Enable 3, disable 4 if value is true,
- // otherwise disable 3, enable 4.
-```
-The `i2c-rtc` overlay uses this technique.
-
-
-#### 2.2.9 Special properties
-
-A few property names, when targeted by a parameter, get special handling. One you may have noticed already - `status` - which will convert a boolean to either `okay` for true and `disabled` for false.
-
-Assigning to the `bootargs` property appends to it rather than overwriting it - this is how settings can be added to the kernel command line.
-
-The `reg` property is used to specify device addresses - the location of a memory-mapped hardware block, the address on an I2C bus, etc. The names of child nodes should be qualified with their addresses in hexadecimal, using `@` as a separator:
-```
- bmp280@76 {
- reg = <0x77>;
- ...
- };
-```
-When assigning to the `reg` property, the address portion of the parent node name will be replaced with the assigned value. This can be used to prevent a node name clash when using the same overlay multiple times - a technique used by the `i2c-gpio` overlay.
-
-The `name` property is a pseudo-property - it shouldn't appear in a DT, but assigning to it causes the name of its parent node to be changed to the assigned value. Like the `reg` property, this can be used to give nodes unique names.
-
-
-#### 2.2.10 The overlay map file
-
-The introduction of the Pi 4, built around the BCM2711 SoC, brought with it many changes; some of these changes are additional interfaces, and some are modifications to (or removals of) existing interfaces. There are new overlays intended specifically for the Pi 4 that don't make sense on older hardware, e.g. overlays that enable the new SPI, I2C and UART interfaces, but other overlays don't apply correctly even though they control features that are still relevant on the new device.
-
-There is therefore a need for a method of tailoring an overlay to multiple platforms with differing hardware. Supporting them all in a single .dtbo file would require heavy use of hidden ("dormant") fragments and a switch to an on-demand symbol resolution mechanism so that a missing symbol that isn't needed doesn't cause a failure. A simpler solution is to add a facility to map an overlay name to one of several implementation files depending on the current platform.
-
-The overlay map, which is rolling out with the switch to Linux 5.4, is a file that gets loaded by the firmware at bootup. It is written in DTS source format - `overlay_map.dts`, compiled to `overlay_map.dtb` and stored in the overlays directory.
-
-This is an edited version of the current map file (the full version is available [here](https://github.com/raspberrypi/linux/blob/rpi-5.4.y/arch/arm/boot/dts/overlays/overlay_map.dts)):
-
-```
-/ {
- vc4-kms-v3d {
- bcm2835;
- bcm2711 = "vc4-kms-v3d-pi4";
- };
-
- vc4-kms-v3d-pi4 {
- bcm2711;
- };
-
- uart5 {
- bcm2711;
- };
-
- pi3-disable-bt {
- renamed = "disable-bt";
- };
-
- lirc-rpi {
- deprecated = "use gpio-ir";
- };
-};
-```
-
-Each node has the name of an overlay that requires special handling. The properties of each node are either platform names or one of a small number of special directives. The current supported platforms are `bcm2835`, which includes all Pis built around the BCM2835, BCM2836 and BCM2837 SoCs, and `bcm2711` for Pi 4B.
-
-A platform name with no value (an empty property) indicates that the current overlay is compatible with the platform; for example, `vc4-kms-v3d` is compatible with the `bcm2835` platform. A non-empty value for a platform is the name of an alternative overlay to use in place of the requested one; asking for `vc4-kms-v3d` on BCM2711 results in `vc4-kms-v3d-pi4` being loaded instead. Any platform not included in an overlay's node is not compatible with that overlay.
-
-The second example node - `vc4-kms-v3d-pi4` - could be inferred from the content of `vc4-kms-v3d`, but that intelligence goes into the construction of the file, not its interpretation.
-
-In the event that a platform is not listed for an overlay, one of the special directives may apply:
-
-* The `renamed` directive indicates the new name of the overlay (which should be largely compatible with the original), but also logs a warning about the rename.
-
-* The `deprecated` directive contains a brief explanatory error message which will be logged after the common prefix `overlay '...' is deprecated:`.
-
-Remember: only exceptions need to be listed - the absence of a node for an overlay means that the default file should be used for all platforms.
-
-Accessing diagnostic messages from the firmware is covered in [Debugging](#part4.1).
-
-The `dtoverlay` and `dtmerge` utilities have been extended to support the map file:
-* `dtmerge` extracts the platform name from the compatible string in the base DTB.
-* `dtoverlay` reads the compatible string from the live Device Tree at `/proc/device-tree`, but you can use the `-p` option to supply an alternate platform name (useful for dry runs on a different platform).
-
-They both send errors, warnings and any debug output to STDERR.
-
-
-#### 2.2.11 Examples
-
-Here are some examples of different types of properties, with parameters to modify them:
-
-```
-/ {
- fragment@0 {
- target-path = "/";
- __overlay__ {
-
- test: test_node {
- string = "hello";
- status = "disabled";
- bytes = /bits/ 8 <0x67 0x89>;
- u16s = /bits/ 16 <0xabcd 0xef01>;
- u32s = /bits/ 32 <0xfedcba98 0x76543210>;
- u64s = /bits/ 64 < 0xaaaaa5a55a5a5555 0x0000111122223333>;
- bool1; // Defaults to true
- // bool2 defaults to false
- mac = [01 23 45 67 89 ab];
- spi = <&spi0>;
- };
- };
- };
-
- fragment@1 {
- target-path = "/";
- __overlay__ {
- frag1;
- };
- };
-
- fragment@2 {
- target-path = "/";
- __dormant__ {
- frag2;
- };
- };
-
- __overrides__ {
- string = <&test>,"string";
- enable = <&test>,"status";
- byte_0 = <&test>,"bytes.0";
- byte_1 = <&test>,"bytes.1";
- u16_0 = <&test>,"u16s;0";
- u16_1 = <&test>,"u16s;2";
- u32_0 = <&test>,"u32s:0";
- u32_1 = <&test>,"u32s:4";
- u64_0 = <&test>,"u64s#0";
- u64_1 = <&test>,"u64s#8";
- bool1 = <&test>,"bool1!";
- bool2 = <&test>,"bool2?";
- entofr = <&test>,"english",
- <&test>,"french{hello=bonjour,goodbye='au revoir',weekend}";
- pi_mac = <&test>,"mac[{1=b8273bfedcba,2=b8273b987654}";
- spibus = <&test>,"spi:0[0=",<&spi0>,"1=",<&spi1>,"2=",<&spi2>;
-
- only1 = <0>,"+1-2";
- only2 = <0>,"-1+2";
- enable1 = <0>,"=1";
- disable2 = <0>,"!2";
- };
-};
-```
-
-For further examples, there is a large collection of overlay source files hosted in the Raspberry Pi Linux GitHub repository [here](https://github.com/raspberrypi/linux/tree/rpi-5.4.y/arch/arm/boot/dts/overlays).
-
-
-### 2.3: Exporting labels
-
-The overlay handling in the firmware and the run-time overlay application using the `dtoverlay` utility treat labels defined in an overlay as being private to that overlay. This avoids the need to invent globally unique names for labels (which keeps them short), and it allows the same overlay to be used multiple times without clashing (provided some tricks are used - see [Special properties](#part2.2.9)).
-
-Sometimes, however, it is very useful to be able to create a label with one overlay and use it from another. Firmware released since 14th February 2020 has the ability to declare some labels as being global - the `__export__` node:
-```
- ...
- public: ...
-
- __exports__ {
- public; // Export the label 'public' to the base DT
- };
-};
-```
-When this overlay is applied, the loader strips out all symbols except those that have been exported, in this case `public`, and rewrites the path to make it relative to the target of the fragment containing the label. Overlays loaded after this one can then refer to `&public`.
-
-
-### 2.4: Overlay application order
-
-Under most circumstances it shouldn't matter which order the fragments are applied, but for overlays that patch themselves (where the target of a fragment is a label in the overlay, known as an intra-overlay fragment) it becomes important. In older firmware, fragments are applied strictly in order, top to bottom. With firmware released since 14th February 2020, fragments are applied in two passes:
-
-i. First the fragments that target other fragments are applied and hidden.
-ii. Then the regular fragments are applied.
-
-This split is particularly important for runtime overlays, since step (i) occurs in the `dtoverlay` utility, and step (ii) is performed by the kernel (which can't handle intra-overlay fragments).
-
-
-## Part 3: Using Device Trees on Raspberry Pi
-
-
-### 3.1: DTBs, overlays and config.txt
-
-On a Raspberry Pi it is the job of the loader (one of the `start.elf` images) to combine overlays with an appropriate base device tree, and then to pass a fully resolved Device Tree to the kernel. The base Device Trees are located alongside `start.elf` in the FAT partition (/boot from Linux), named `bcm2711-rpi-4-b.dtb`, `bcm2710-rpi-3-b-plus.dtb`, etc. Note that some models (3A+, A, A+) will use the "b" equivalents (3B+, B, B+), respectively. This selection is automatic, and allows the same SD card image to be used in a variety of devices.
-
-Note that DT and ATAGs are mutually exclusive, and passing a DT blob to a kernel that doesn't understand it will cause a boot failure. The firmware will always try to load the DT and pass it to the kernel, since all kernels since rpi-4.4.y will not function without a DTB. You can override this by adding `device_tree=` in config.txt, which forces the use of ATAGs, which can be useful for simple "bare-metal" kernels.
-
-[ The firmware used to look for a trailer appended to kernels by the `mkknlimg` utility, but support for this has been withdrawn. ]
-
-The loader now supports builds using bcm2835_defconfig, which selects the upstreamed BCM2835 support. This configuration will cause `bcm2835-rpi-b.dtb` and `bcm2835-rpi-b-plus.dtb` to be built. If these files are copied with the kernel, then the loader will attempt to load one of those DTBs by default.
-
-In order to manage Device Tree and overlays, the loader supports a number of `config.txt` directives:
-
-```
-dtoverlay=acme-board
-dtparam=foo=bar,level=42
-```
-
-This will cause the loader to look for `overlays/acme-board.dtbo` in the firmware partition, which Raspberry Pi OS mounts on `/boot`. It will then search for parameters `foo` and `level`, and assign the indicated values to them.
-
-The loader will also search for an attached HAT with a programmed EEPROM, and load the supporting overlay from there - either directly or by name from the "overlays" directory; this happens without any user intervention.
-
-There are several ways to tell that the kernel is using Device Tree:
-
-1. The "Machine model:" kernel message during bootup has a board-specific value such as "Raspberry Pi 2 Model B", rather than "BCM2709".
-2. `/proc/device-tree` exists, and contains subdirectories and files that exactly mirror the nodes and properties of the DT.
-
-With a Device Tree, the kernel will automatically search for and load modules that support the indicated enabled devices. As a result, by creating an appropriate DT overlay for a device you save users of the device from having to edit `/etc/modules`; all of the configuration goes in `config.txt`, and in the case of a HAT, even that step is unnecessary. Note, however, that layered modules such as `i2c-dev` still need to be loaded explicitly.
-
-The flipside is that because platform devices don't get created unless requested by the DTB, it should no longer be necessary to blacklist modules that used to be loaded as a result of platform devices defined in the board support code. In fact, current Raspberry Pi OS images ship with no blacklist files (except for some WLAN devices where multiple drivers are available).
-
-
-### 3.2: DT parameters
-
-As described above, DT parameters are a convenient way to make small changes to a device's configuration. The current base DTBs support parameters for enabling and controlling the onboard audio, I2C, I2S and SPI interfaces without using dedicated overlays. In use, parameters look like this:
-
-```
-dtparam=audio=on,i2c_arm=on,i2c_arm_baudrate=400000,spi=on
-```
-
-Note that multiple assignments can be placed on the same line, but ensure you don't exceed the 80-character limit.
-
-If you have an overlay that defines some parameters, they can be specified either on subsequent lines like this:
-
-```
-dtoverlay=lirc-rpi
-dtparam=gpio_out_pin=16
-dtparam=gpio_in_pin=17
-dtparam=gpio_in_pull=down
-```
-
-or appended to the overlay line like this:
-
-```
-dtoverlay=lirc-rpi,gpio_out_pin=16,gpio_in_pin=17,gpio_in_pull=down
-```
-
-Overlay parameters are only in scope until the next overlay is loaded. In the event of a parameter with the same name being exported by both the overlay and the base, the parameter in the overlay takes precedence; for clarity, it's recommended that you avoid doing this. To expose the parameter exported by the base DTB instead, end the current overlay scope using:
-
-```
-dtoverlay=
-```
-
-
-### 3.3: Board-specific labels and parameters
-
-Raspberry Pi boards have two I2C interfaces. These are nominally split: one for the ARM, and one for VideoCore (the "GPU"). On almost all models, `i2c1` belongs to the ARM and `i2c0` to VC, where it is used to control the camera and read the HAT EEPROM. However, there are two early revisions of the Model B that have those roles reversed.
-
-To make it possible to use one set of overlays and parameters with all Pis, the firmware creates some board-specific DT parameters. These are:
-
-```
-i2c/i2c_arm
-i2c_vc
-i2c_baudrate/i2c_arm_baudrate
-i2c_vc_baudrate
-```
-
-These are aliases for `i2c0`, `i2c1`, `i2c0_baudrate`, and `i2c1_baudrate`. It is recommended that you only use `i2c_vc` and `i2c_vc_baudrate` if you really need to - for example, if you are programming a HAT EEPROM (which is better done using a software I2C bus using the `i2c-gpio` overlay). Enabling `i2c_vc` can stop the Pi Camera or 7" DSI display functioning correctly.
-
-For people writing overlays, the same aliasing has been applied to the labels on the I2C DT nodes. Thus, you should write:
-
-```
-fragment@0 {
- target = <&i2c_arm>;
- __overlay__ {
- status = "okay";
- };
-};
-```
-
-Any overlays using the numeric variants will be modified to use the new aliases.
-
-
-### 3.4: HATs and Device Tree
-
-A Raspberry Pi HAT is an add-on board with an embedded EEPROM designed for a Raspberry Pi with a 40-pin header. The EEPROM includes any DT overlay required to enable the board (or the name of an overlay to load from the filing system), and this overlay can also expose parameters.
-
-The HAT overlay is automatically loaded by the firmware after the base DTB, so its parameters are accessible until any other overlays are loaded, or until the overlay scope is ended using `dtoverlay=`. If for some reason you want to suppress the loading of the HAT overlay, put `dtoverlay=` before any other `dtoverlay` or `dtparam` directive.
-
-
-### 3.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.
-
-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.
-
-There are some new commands for managing overlays:
-
-
-#### 3.5.1 The dtoverlay command
-
-`dtoverlay` is a command line utility that loads and removes overlays while the system is running, as well as listing the available overlays and displaying their help information:
-
-```
-pi@raspberrypi ~ $ dtoverlay -h
-Usage:
- dtoverlay [=...]
- Add an overlay (with parameters)
- dtoverlay -D [] Dry-run (prepare overlay, but don't apply -
- save it as dry-run.dtbo)
- dtoverlay -r [] Remove an overlay (by name, index or the last)
- dtoverlay -R [] Remove from an overlay (by name, index or all)
- dtoverlay -l List active overlays/params
- dtoverlay -a List all overlays (marking the active)
- dtoverlay -h Show this usage message
- dtoverlay -h Display help on an overlay
- dtoverlay -h .. Or its parameters
- where is the name of an overlay or 'dtparam' for dtparams
-Options applicable to most variants:
- -d Specify an alternate location for the overlays
- (defaults to /boot/overlays or /flash/overlays)
- -v Verbose operation
-```
-
-Unlike the `config.txt` equivalent, all parameters to an overlay must be included in the same command line - the [dtparam](#part3.5.2) command is only for parameters of the base DTB.
-
-Two points to note:
-1. Command variants that change kernel state (adding and removing things) require root privilege, so you may need to prefix the command with `sudo`.
-
-2. Only overlays and parameters applied at run-time can be unloaded - an overlay or parameter applied by the firmware becomes "baked in" such that it won't be listed by `dtoverlay` and can't be removed.
-
-
-#### 3.5.2 The dtparam command
-
-`dtparam` creates and loads an overlay that has largely the same effect as using a dtparam directive in `config.txt`. In usage it is largely equivalent to `dtoverlay` with an overlay name of `-`, but there are a few differences:
-
-1. `dtparam` will list the help information for all known parameters of the base DTB. Help on the dtparam command is still available using `dtparam -h`.
-
-2. When indicating a parameter for removal, only index numbers can be used (not names).
-
-3. Not all Linux subsystems respond to the addition of devices at runtime - I2C, SPI and sound devices work, but some won't.
-
-
-#### 3.5.3 Guidelines for writing runtime-capable overlays
-
-This area is poorly documented, but here are some accumulated tips:
-
-* The creation or deletion of a device object is triggered by a node being added or removed, or by the status of a node changing from disabled to enabled or vice versa. Beware - the absence of a "status" property means the node is enabled.
-
-* Don't create a node within a fragment that will overwrite an existing node in the base DTB - the kernel will rename the new node to make it unique. If you want to change the properties of an existing node, create a fragment that targets it.
-
-* ALSA doesn't prevent its codecs and other components from being unloaded while they are in use. Removing an overlay can cause a kernel exception if it deletes a codec that is still being used by a sound card. Experimentation found that devices are deleted in the reverse of fragment order in the overlay, so placing the node for the card after the nodes for the components allows an orderly shutdown.
-
-
-#### 3.5.4 Caveats
-
-The loading of overlays at runtime is a recent addition to the kernel, and so far there is no accepted way to do this from userspace. By hiding the details of this mechanism behind commands the aim is to insulate users from changes in the event that a different kernel interface becomes standardised.
-
-* Some overlays work better at run-time than others. Parts of the Device Tree are only used at boot time - changing them using an overlay will not have any effect.
-
-* Applying or removing some overlays may cause unexpected behaviour, so it should be done with caution. This is one of the reasons it requires `sudo`.
-
-* Unloading the overlay for an ALSA card can stall if something is actively using ALSA - the LXPanel volume slider plugin demonstrates this effect. To enable overlays for sound cards to be removed, the `lxpanelctl` utility has been given two new options - `alsastop` and `alsastart` - and these are called from the auxiliary scripts `dtoverlay-pre` and `dtoverlay-post` before and after overlays are loaded or unloaded, respectively.
-
-* Removing an overlay will not cause a loaded module to be unloaded, but it may cause the reference count of some modules to drop to zero. Running `rmmod -a` twice will cause unused modules to be unloaded.
-
-* Overlays have to be removed in reverse order. The commands will allow you to remove an earlier one, but all the intermediate ones will be removed and re-applied, which may have unintended consequences.
-
-* Only Device Tree nodes at the top level of the tree and children of a bus node will be probed. For nodes added at run-time there is the further limitation that the bus must register for notifications of the addition and removal of children. However, there are exceptions that break this rule and cause confusion: the kernel explicitly scans the entire tree for some device types - clocks and interrupt controller being the two main ones - in order to (for clocks) initialise them early and/or (for interrupt controllers) in a particular order. This search mechanism only happens during booting and so doesn't work for nodes added by an overlay at run-time. It is therefore recommended for overlays to place fixed-clock nodes in the root of the tree unless it is guaranteed that the overlay will not be used at run-time.
-
-
-### 3.6: Supported overlays and parameters
-
-As it is too time-consuming to document the individual overlays here, please refer to the [README](https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README) file found alongside the overlay `.dtbo` files in `/boot/overlays`. It is kept up-to-date with additions and changes.
-
-
-## Part 4: Troubleshooting and pro tips
-
-
-### 4.1: Debugging
-
-The loader will skip over missing overlays and bad parameters, but if there are serious errors, such as a missing or corrupt base DTB or a failed overlay merge, then the loader will fall back to a non-DT boot. If this happens, or if your settings don't behave as you expect, it is worth checking for warnings or errors from the loader:
-
-```
-sudo vcdbg log msg
-```
-
-Extra debugging can be enabled by adding `dtdebug=1` to `config.txt`.
-
-You can create a human-readable representation of the current state of DT like this:
-
-```
-dtc -I fs /proc/device-tree
-```
-
-This can be useful to see the effect of merging overlays onto the underlying tree.
-
-If kernel modules don't load as expected, check that they aren't blacklisted in `/etc/modprobe.d/raspi-blacklist.conf`; blacklisting shouldn't be necessary when using Device Tree. If that shows nothing untoward, you can also check that the module is exporting the correct aliases by searching `/lib/modules//modules.alias` for the `compatible` value. Otherwise, your driver is probably missing either:
-
-```
-.of_match_table = xxx_of_match,
-```
-
-or:
-
-```
-MODULE_DEVICE_TABLE(of, xxx_of_match);
-```
-
-Failing that, `depmod` has failed or the updated modules haven't been installed on the target filesystem.
-
-
-### 4.2: Testing overlays using dtmerge, dtdiff and ovmerge
-
-Alongside the `dtoverlay` and `dtparam` commands is a utility for applying an overlay to a DTB - `dtmerge`. To use it you first need to obtain your base DTB, which can be obtained in one of two ways:
-
-a) generate it from the live DT state in `/proc/device-tree`:
-```
-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 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 -
-```
-
-(the `-` indicates an absent overlay name).
-
-You can now try applying an overlay or parameter:
-
-```
-dtmerge base.dtb merged.dtb - sd_overclock=62
-dtdiff base.dtb merged.dtb
-```
-
-which will return:
-```
---- /dev/fd/63 2016-05-16 14:48:26.396024813 +0100
-+++ /dev/fd/62 2016-05-16 14:48:26.396024813 +0100
-@@ -594,7 +594,7 @@
- };
-
- sdhost@7e202000 {
-- brcm,overclock-50 = <0x0>;
-+ brcm,overclock-50 = <0x3e>;
- brcm,pio-limit = <0x1>;
- bus-width = <0x4>;
- clocks = <0x8>;
-```
-
-You can also compare different overlays or parameters.
-
-```
-dtmerge base.dtb merged1.dtb /boot/overlays/spi1-1cs.dtbo
-dtmerge base.dtb merged2.dtb /boot/overlays/spi1-2cs.dtbo
-dtdiff merged1.dtb merged2.dtb
-```
-
-to get:
-
-```
---- /dev/fd/63 2016-05-16 14:18:56.189634286 +0100
-+++ /dev/fd/62 2016-05-16 14:18:56.189634286 +0100
-@@ -453,7 +453,7 @@
-
- spi1_cs_pins {
- brcm,function = <0x1>;
-- brcm,pins = <0x12>;
-+ brcm,pins = <0x12 0x11>;
- phandle = <0x3e>;
- };
-
-@@ -725,7 +725,7 @@
- #size-cells = <0x0>;
- clocks = <0x13 0x1>;
- compatible = "brcm,bcm2835-aux-spi";
-- cs-gpios = <0xc 0x12 0x1>;
-+ cs-gpios = <0xc 0x12 0x1 0xc 0x11 0x1>;
- interrupts = <0x1 0x1d>;
- linux,phandle = <0x30>;
- phandle = <0x30>;
-@@ -743,6 +743,16 @@
- spi-max-frequency = <0x7a120>;
- status = "okay";
- };
-+
-+ spidev@1 {
-+ #address-cells = <0x1>;
-+ #size-cells = <0x0>;
-+ compatible = "spidev";
-+ phandle = <0x41>;
-+ reg = <0x1>;
-+ spi-max-frequency = <0x7a120>;
-+ status = "okay";
-+ };
- };
-
- spi@7e2150C0 {
-```
-
-The [Utils](https://github.com/raspberrypi/utils) repo includes another DT utility - `ovmerge`. Unlike `dtmerge`, `ovmerge` combines file and applies overlays in source form. Because the overlay is never compiled, labels are preserved and the result is usually more readable. It also has a number of other tricks, such as the ability to list the order of file inclusion.
-
-
-### 4.3: Forcing a specific Device Tree
-
-If you have very specific needs that aren't supported by the default DTBs, or if you just want to experiment with writing your own DTs, you can tell the loader to load an alternate DTB file like this:
-
-```
-device_tree=my-pi.dtb
-```
-
-
-### 4.4: Disabling Device Tree usage
-
-Since the switch to the 4.4 kernel and the use of more upstream drivers, Device Tree usage is required in Pi Linux kernels. However, for bare metal and other OSs, the method of disabling DT usage is to add:
-
-```
-device_tree=
-```
-
-to `config.txt`.
-
-
-### 4.5: Shortcuts and syntax variants
-
-The loader understands a few shortcuts:
-
-```
-dtparam=i2c_arm=on
-dtparam=i2s=on
-```
-
-can be shortened to:
-
-```
-dtparam=i2c,i2s
-```
-
-(`i2c` is an alias of `i2c_arm`, and the `=on` is assumed). It also still accepts the long-form versions: `device_tree_overlay` and `device_tree_param`.
-
-
-### 4.6: Other DT commands available in config.txt
-
-`device_tree_address`
-This is used to override the address where the firmware loads the device tree (not dt-blob). By default the firmware will choose a suitable place.
-
-`device_tree_end`
-This sets an (exclusive) limit to the loaded device tree. By default the device tree can grow to the end of usable memory, which is almost certainly what is required.
-
-`dtdebug`
-If non-zero, turn on some extra logging for the firmware's device tree processing.
-
-`enable_uart`
-Enable the primary/console UART (ttyS0 on a Pi 3, ttyAMA0 otherwise - unless swapped with an overlay such as miniuart-bt). If the primary UART is ttyAMA0 then enable_uart defaults to 1 (enabled), otherwise it defaults to 0 (disabled). This is because it is necessary to stop the core frequency from changing which would make ttyS0 unusable, so `enable_uart=1` implies core_freq=250 (unless force_turbo=1). In some cases this is a performance hit, so it is off by default. More details on UARTs can be found [here](uart.md)
-
-`overlay_prefix`
-Specifies a subdirectory/prefix from which to load overlays - defaults to "overlays/". Note the trailing "/". If desired you can add something after the final "/" to add a prefix to each file, although this is not likely to be needed.
-
-Further ports can be controlled by the DT, for more details see [section 3](#part3).
-
-
-### 4.7 Further help
-
-If you've read through this document and not found the answer to a Device Tree problem, there is help available. The author can usually be found on Raspberry Pi forums, particularly the [Device Tree](https://www.raspberrypi.org/forums/viewforum.php?f=107) forum.
diff --git a/configuration/display_rotation.md b/configuration/display_rotation.md
deleted file mode 100644
index ed497146df..0000000000
--- a/configuration/display_rotation.md
+++ /dev/null
@@ -1,45 +0,0 @@
-## How to rotate your display
-
-The options to rotate the display of your Raspberry Pi depend on which display driver software it is running, which may also depend on which Raspberry Pi you are using.
-
-### Fake or Full KMS graphics driver (Default on Pi4)
-
-If you are running the Raspberry Pi desktop then rotation is achieved by using the `Screen Configuration Utility` from the desktop `Preferences` menu. This will bring up a graphical representation of the display or displays connected to the Raspberry Pi. Right click on the display you wish to rotate and select the required option.
-
-It is also possible to change these settings using the command line `xrandr` option. The following commands give 0°, -90°, +90° and 180° rotations respectively.
-
-```bash
-xrandr --output HDMI-1 --rotate normal
-xrandr --output HDMI-1 --rotate left
-xrandr --output HDMI-1 --rotate right
-xrandr --output HDMI-1 --rotate inverted
-```
-
-Note that the `--output` entry specifies to which device the rotation applies. You can determine the device name by simply typing `xrandr` on the command line which will display information, including the name, for all attached devices.
-
-You can also use the command line to mirror the display using the `--reflect` option. Reflection can be one of 'normal' 'x', 'y' or 'xy'. This causes the output contents to be reflected across the specified axes. E.g.
-
-```bash
-xrandr --output HDMI-1 --reflect x
-```
-
-If you are using the console only (no graphical desktop) then you will need to set the appropriate kernel command line flags. Change the console settings as described on the [this page](./cmdline-txt.md).
-
-### Legacy graphics driver (default on models prior to the Pi4)
-
-There are `config.txt` options for rotating when using the legacy display drivers.
-
-`display_hdmi_rotate` is used to rotate the HDMI display, `display_lcd_rotate` is used to rotate any attached LCD panel (using the DSI or DPI interface). These options rotate both the desktop and console. Each option takes one of the following parameters :
-
-| display_*_rotate | result |
-| --- | --- |
-| 0 | no rotation |
-| 1 | rotate 90 degrees clockwise |
-| 2 | rotate 180 degrees clockwise |
-| 3 | rotate 270 degrees clockwise |
-| 0x10000 | horizontal flip |
-| 0x20000 | vertical flip |
-
-Note that the 90 and 270 degree rotation options require additional memory on the GPU, so these will not work with the 16MB GPU split.
-
-You can combine the rotation settings with the flips by adding them together. You can also have both horizontal and vertical flips in the same way. E.g. A 180 degree rotation with a vertical and horizontal flip will be 0x20000 + 0x10000 + 2 = 0x30002.
diff --git a/configuration/external-storage.md b/configuration/external-storage.md
deleted file mode 100644
index 33615fcf6d..0000000000
--- a/configuration/external-storage.md
+++ /dev/null
@@ -1,110 +0,0 @@
-# External storage configuration
-You can connect your external hard disk, SSD, or USB stick to any of the USB ports on the Raspberry Pi, and mount the file system to access the data stored on it.
-
-By default, your Raspberry Pi automatically mounts some of the popular file systems such as FAT, NTFS, and HFS+ at the `/media/pi/` location.
-
-To set up your storage device so that it always mounts to a specific location of your choice, you must mount it manually.
-
-## Mounting a storage device
-You can mount your storage device at a specific folder location. It is conventional to do this within the /mnt folder, for example /mnt/mydisk. Note that the folder must be empty.
-
-1. Plug the storage device into a USB port on the Raspberry Pi.
-2. List all the disk partitions on the Pi using the following command:
-
- ```
- sudo lsblk -o UUID,NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL,MODEL
- ```
- The Raspberry Pi uses mount points `/` and `/boot`. Your storage device will show up in this list, along with any other connected storage.
-3. Use the SIZE, LABEL, and MODEL columns to identify the name of the disk partition that points to your storage device. For example, `sda1`.
-4. The FSTYPE column contains the filesystem type. If your storage device uses an exFAT file system, install the exFAT driver:
-
- ```
- sudo apt update
- sudo apt install exfat-fuse
- ```
-5. If your storage device uses an NTFS file system, you will have read-only access to it. If you want to write to the device, you can install the ntfs-3g driver:
-
- ```
- sudo apt update
- sudo apt install ntfs-3g
- ```
-6. Run the following command to get the location of the disk partition:
-
- ```
- sudo blkid
- ```
- For example, `/dev/sda1`.
-7. Create a target folder to be the mount point of the storage device.
- The mount point name used in this case is `mydisk`. You can specify a name of your choice:
-
- ```
- sudo mkdir /mnt/mydisk
- ```
-8. Mount the storage device at the mount point you created:
-
- ```
- sudo mount /dev/sda1 /mnt/mydisk
- ```
-9. Verify that the storage device is mounted successfully by listing the contents:
-
- ```
- ls /mnt/mydisk
- ```
-
-## Setting up automatic mounting
-You can modify the `fstab` file to define the location where the storage device will be automatically mounted when the Raspberry Pi starts up. In the `fstab` file, the disk partition is identified by the universally unique identifier (UUID).
-
-1. Get the UUID of the disk partition:
-
- ```
- sudo blkid
- ```
-2. Find the disk partition from the list and note the UUID. For example, `5C24-1453`.
-3. Open the fstab file using a command line editor such as nano:
-
- ```
- sudo nano /etc/fstab
- ```
-4. Add the following line in the `fstab` file:
-
- ```
- UUID=5C24-1453 /mnt/mydisk fstype defaults,auto,users,rw,nofail 0 0
- ```
- Replace `fstype` with the type of your file system, which you found in step 2 of 'Mounting a storage device' above, for example: `ntfs`.
-
-5. If the filesystem type is FAT or NTFS, add `,umask=000` immediately after `nofail` - this will allow all users full read/write access to every file on the storage device.
-
-Now that you have set an entry in `fstab`, you can start up your Raspberry Pi with or without the storage device attached. Before you unplug the device you must either shut down the Pi, or manually unmount it using the steps in 'Unmounting a storage device' below.
-
-**Note:** if you do not have the storage device attached when the Pi starts, the Pi will take an extra 90 seconds to start up. You can shorten this by adding `,x-systemd.device-timeout=30` immediately after `nofail` in step 4. This will change the timeout to 30 seconds, meaning the system will only wait 30 seconds before giving up trying to mount the disk.
-
-For more information on each Linux command, refer to the specific manual page using the `man` command. For example, `man fstab`.
-
-## Unmounting a storage device
-
-When the Raspberry Pi shuts down, the system takes care of unmounting the storage device so that it is safe to unplug it. If you want to manually unmount a device, you can use the following command:
-
-```
-sudo umount /mnt/mydisk
-```
-If you receive an error that the 'target is busy', this means that the storage device was not unmounted. If no error was displayed, you can now safely unplug the device.
-
-### Dealing with 'target is busy'
-
-The 'target is busy' message means there are files on the storage device that are in use by a program. To close the files, use the following procedure.
-
-1. Close any program which has open files on the storage device.
-
-2. If you have a terminal open, make sure that you are not in the folder where the storage device is mounted, or in a sub-folder of it.
-
-3. If you are still unable to unmount the storage device, you can use the `lsof` tool to check which program has files open on the device. You need to first install `lsof` using `apt`:
-
- ```
- sudo apt update
- sudo apt install lsof
- ```
- To use lsof:
-
- ```
- lsof /mnt/mydisk
- ```
diff --git a/configuration/hdmi-config.md b/configuration/hdmi-config.md
deleted file mode 100644
index 7eef8ce06b..0000000000
--- a/configuration/hdmi-config.md
+++ /dev/null
@@ -1,93 +0,0 @@
-## HDMI configuration
-
-In the vast majority of cases, simply plugging your HDMI-equipped monitor into the Raspberry Pi using a standard HDMI cable will automatically lead to the Pi using the best resolution the monitor supports. The Raspberry Pi Zero uses a mini HDMI port, so you will need a mini-HDMI-to-full-size-HDMI lead or adapter. On the Raspberry Pi 4 there are two micro HDMI ports, so you will need either one or two micro-HDMI-to-full-size-HDMI leads or adapters, depending on how many displays you wish to attach. You should connect any HDMI leads before turning on the Raspberry Pi.
-
-The Raspberry Pi 4 can drive up to two displays, with a resolution up to 1080p at a 60Hz refresh rate. At 4K resolution, if you connect two displays then you are limited to a 30Hz refresh rate. You can also drive a single display at 4K with a 60Hz refresh rate: this requires that the display is attached to the HDMI port adjacent to the USB-C power input (labelled HDMI0). You must also enable 4Kp60 output by setting the `hdmi_enable_4kp60=1` flag in config.txt. This flag can also be set using the 'Raspberry Pi Configuration' tool within the desktop environment.
-
-If you are running the 3D graphics driver (also known as the FKMS driver), then in the Preferences menu you will find a graphical application for setting up standard displays, including multi-display setups. See [instructions for using the tool here](arandr.md).
-
-If you are using legacy graphics drivers, or find yourself in circumstances where the Raspberry Pi may not be able to determine the best mode, or you may specifically wish to set a non-default resolution, the rest of this page may be useful.
-
-Note that all the commands on this page are documented fully in the config.txt [Video](config-txt/video.md) documentation.
-
-### HDMI groups and mode
-
-HDMI has two common groups: CEA (Consumer Electronics Association, the standard typically used by TVs) and DMT (Display Monitor Timings, the standard typically used by monitors). Each group advertises a particular set of modes, where a mode describes the resolution, frame rate, clock rate, and aspect ratio of the output.
-
-### What modes does my device support?
-
-You can use the `tvservice` application on the command line to determine which modes are supported by your device, along with other useful data:
-
-+ `tvservice -s` displays the current HDMI status, including mode and resolution
-+ `tvservice -m CEA` lists all supported CEA modes
-+ `tvservice -m DMT` lists all supported DMT modes
-
-If you are using a Pi 4 with more than one display attached, then `tvservice` needs to be told which device to ask for information. You can get display IDs for all attached devices by using:
-
-`tvservice -l`
-
-You can specify which display `tvservice` uses by adding `-v ` to the `tvservice` command, e.g:
-
-+ `tvservice -v 7 -m CEA`, lists all supported CEA modes for display ID 7
-
-### Setting a specific HDMI mode
-
-Setting a specific mode is done using the `hdmi_group` and `hdmi_mode` config.txt entries. The group entry selects between CEA or DMT, and the mode selects the resolution and frame rate. You can find tables of modes on the config.txt [Video Configuration](config-txt/video.md) page, but you should use the `tvservice` command described above to find out exactly which modes your device supports.
-
-On the Pi 4, to specify the HDMI port, add an index identifier to the `hdmi_group` or `hdmi_mode` entry in config.txt, e.g. `hdmi_mode:0` or `hdmi_group:1`.
-
-### Setting a custom HDMI mode
-
-There are two options for setting a custom mode: `hdmi_cvt` and `hdmi_timings`.
-
-`hdmi_cvt` sets a custom Coordinated Video Timing entry, which is described fully here: [Video Configuration](config-txt/video.md#Custom%20Mode)
-
-In certain rare cases it may be necessary to define the exact clock requirements of the HDMI signal. This is a fully custom mode, and it is activated by setting `hdmi_group=2` and `hdmi_mode=87`. You can then use the `hdmi_timings` config.txt command to set the specific parameters for your display.
-`hdmi_timings` specifies all the timings that an HDMI signal needs to use. These timings are usually found in the datasheet of the display being used.
-
-`hdmi_timings= v_front_porch> `
-
-| Timing | Purpose |
-| ------------- | ------------- |
-| `h_active_pixels` | The horizontal resolution |
-| `h_sync_polarity` | 0 or 1 to define the horizontal sync polarity |
-| `h_front_porch` | Number of horizontal front porch pixels |
-| `h_sync_pulse` | Width of horizontal sync pulse |
-| `h_back_porch` | Number of horizontal back porch pixels |
-| `v_active_lines` | The vertical resolution |
-| `v_sync_polarity` | 0 or 1 to define the vertical sync polarity |
-| `v_front_porch` | Number of vertical front porch pixels |
-| `v_sync_pulse` | Width of vertical sync pulse |
-| `v_back_porch` | Number of vertical back porch pixels |
-| `v_sync_offset_a` | Leave at 0 |
-| `v_sync_offset_b` | Leave at 0 |
-| `pixel_rep` | Leave at 0 |
-| `frame_rate` | Frame rate of mode |
-| `interlaced` | 0 for non-interlaced, 1 for interlaced |
-| `pixel_freq` | The mode pixel frequency |
-| `aspect_ratio` | The aspect ratio required |
-
-`aspect_ratio` should be one of the following:
-
-| Ratio | `aspect_ratio` ID |
-|-------|----|
-| `4:3` | 1 |
-|`14:9` | 2 |
-|`16:9` | 3 |
-|`5:4` | 4 |
-|`16:10`| 5 |
-|`15:9` | 6 |
-|`21:9` | 7 |
-|`64:27`| 8 |
-
-For the Pi4, to specify the HDMI port, you can add an index identifier to the config.txt. e.g. `hdmi_cvt:0=...` or `hdmi_timings:1=...`. If no port identifier is specified, the settings are applied to port 0.
-
-### Display Rotation
-
-Please see the [Display Rotation Page](./display_rotation.md) for details.
-
-### HDMI not working properly?
-
-In some rare cases you may need to increase the HDMI drive strength, for example when there is speckling on the display or when you are using very long cables. There is a config.txt item to do this, `config_hdmi_boost`, which is documented on the [config.txt video page](config-txt/video.md).
-
-The Raspberry Pi 4B does not yet support `config_hdmi_boost`, support for this option will be added in a future software update.
diff --git a/configuration/images/proxy-edit-sudoers.png b/configuration/images/proxy-edit-sudoers.png
deleted file mode 100644
index 3a76f38a37..0000000000
Binary files a/configuration/images/proxy-edit-sudoers.png and /dev/null differ
diff --git a/configuration/images/proxy-environment-variables.png b/configuration/images/proxy-environment-variables.png
deleted file mode 100644
index 137484c735..0000000000
Binary files a/configuration/images/proxy-environment-variables.png and /dev/null differ
diff --git a/configuration/images/proxy-open-environment.png b/configuration/images/proxy-open-environment.png
deleted file mode 100644
index 0c469ab414..0000000000
Binary files a/configuration/images/proxy-open-environment.png and /dev/null differ
diff --git a/configuration/images/raspi-config-audio-selection.png b/configuration/images/raspi-config-audio-selection.png
deleted file mode 100644
index b6d0227fb8..0000000000
Binary files a/configuration/images/raspi-config-audio-selection.png and /dev/null differ
diff --git a/configuration/images/raspi-config-audio.png b/configuration/images/raspi-config-audio.png
deleted file mode 100644
index 9cc224734e..0000000000
Binary files a/configuration/images/raspi-config-audio.png and /dev/null differ
diff --git a/configuration/images/raspi-config.png b/configuration/images/raspi-config.png
deleted file mode 100644
index 2aff53913a..0000000000
Binary files a/configuration/images/raspi-config.png and /dev/null differ
diff --git a/configuration/led_blink_warnings.md b/configuration/led_blink_warnings.md
deleted file mode 100644
index 69308a1a71..0000000000
--- a/configuration/led_blink_warnings.md
+++ /dev/null
@@ -1,22 +0,0 @@
-## LED warning flash codes
-
-If a Pi fails to boot for some reason, or has to shut down, in many cases an LED will be flashed a specific number of times to indicate what happened. The LED will blink for a number of long flashes (0 or more), then short flashes, to indicate the exact status. In most cases, the pattern will repeat after a 2 second gap.
-
-| Long flashes | Short flashes | Status |
-|:------------:|:-------------:|--------|
-| 0 | 3 | Generic failure to boot |
-| 0 | 4 | start*.elf not found |
-| 0 | 7 | Kernel image not found |
-| 0 | 8 | SDRAM failure |
-| 0 | 9 | Insufficient SDRAM |
-| 0 | 10 | In HALT state |
-| 2 | 1 | Partition not FAT |
-| 2 | 2 | Failed to read from partition |
-| 2 | 3 | Extended partition not FAT |
-| 2 | 4 | File signature/hash mismatch - Pi 4 |
-| 3 | 1 | SPI EEPROM error - Pi 4 |
-| 3 | 2 | SPI EEPROM is write protected - Pi 4 |
-| 4 | 4 | Unsupported board type |
-| 4 | 5 | Fatal firmware error |
-| 4 | 6 | Power failure type A |
-| 4 | 7 | Power failure type B |
diff --git a/configuration/localisation.md b/configuration/localisation.md
deleted file mode 100644
index 58c157197a..0000000000
--- a/configuration/localisation.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# Localisation
-
-Set your Raspberry Pi up to match your regional settings.
-
-
-## Language
-
-### NOOBS
-
-To change the language used by NOOBS, you can either press the `L` key on your keyboard, press the up/down arrows to choose the language you want, and then press `Enter`; or you can do the same thing using the mouse. NOOBS will remember your selection, and will use the same language again next time.
-
-Alternatively, you can pre-select the language before booting NOOBS for the first time. See [here](https://github.com/raspberrypi/noobs/blob/master/README.md#how-to-change-the-default-language-keyboard-layout-display-mode-or-boot-partition).
-
-### Raspberry Pi OS
-
-If you've installed Raspberry Pi OS using NOOBS, it should automatically pick up the same language you were using within NOOBS. But if you want to select a different language, or if you've installed Raspberry Pi OS from a standalone image, use [raspi-config](raspi-config.md#change-locale).
-
-
-## Keyboard
-
-### NOOBS
-
-To change the keyboard layout used by NOOBS, you can either press the `9` key on your keyboard, press the up/down arrows to choose the keyboard you want, and then press `Enter`; or you can do the same thing using the mouse. Note that changing the language (as described above) may automatically change the keyboard layout as appropriate too. NOOBS will remember your selection and use the same keyboard layout again next time.
-
-Alternatively, you can pre-select the keyboard before booting NOOBS for the first time. See [here](https://github.com/raspberrypi/noobs/blob/master/README.md#how-to-change-the-default-language-keyboard-layout-display-mode-or-boot-partition).
-
-### Raspberry Pi OS
-
-If you've installed Raspberry Pi OS using NOOBS, it should automatically pick up the same keyboard you were using in NOOBS. But if you want to select a different keyboard, or if you've installed Raspberry Pi OS from a standalone image, use [raspi-config](raspi-config.md#change-keyboard-layout).
-
-
-## Timezone
-
-### NOOBS
-
-No part of NOOBS uses the time; consequently there is no option for changing the timezone.
-
-### Raspberry Pi OS
-
-Once again, this is something you can change using the [raspi-config](raspi-config.md#change-timezone) tool.
diff --git a/configuration/nfs.md b/configuration/nfs.md
deleted file mode 100644
index be82527ada..0000000000
--- a/configuration/nfs.md
+++ /dev/null
@@ -1,304 +0,0 @@
-# Network File System (NFS)
-
-A **Network File System** (NFS) allows you to share a directory located on one networked computer with other computers or devices on the same network. The computer where the directory is located is called the **server**, and computers or devices connecting to that server are called **clients**. Clients usually `mount` the shared directory to make it a part of their own directory structure. The shared directory is an example of a shared resource or network share.
-
-For smaller networks, an NFS is perfect for creating a simple NAS (Network-attached storage) in a Linux/Unix environment.
-
-An NFS is perhaps best suited to more permanent network-mounted directories, such as `/home` directories or regularly-accessed shared resources. If you want a network share that guest users can easily connect to, Samba is better suited to the task. This is because tools to temporarily mount and detach from Samba shares are more readily available across old and proprietary operating systems.
-
-Before deploying an NFS, you should be familiar with:
-
-* Linux file and directory permissions
-* mounting and unmounting filesystems
-
-## Set up a basic NFS server
-
-Install the packages required using the command below:
-
-```bash
-sudo apt install nfs-kernel-server
-```
-
-For easier maintenance, we will isolate all NFS exports in single directory, into which the real directories will be mounted with the `--bind` option.
-
-Suppose we want to export our users' home directories, which are in `/home/users`. First we create the export filesystem:
-
-```bash
-sudo mkdir -p /export/users
-```
-
-Note that `/export` and `/export/users` will need 777 permissions, as we will be accessing the NFS share from the client without LDAP/NIS authentication. This will not apply if using authentication (see below). Now mount the real `users` directory with:
-
-```bash
-sudo mount --bind /home/users /export/users
-```
-
-To save us from retyping this after every reboot, we add the following line to `/etc/fstab`:
-
-```
-/home/users /export/users none bind 0 0
-```
-
-There are three configuration files that relate to an NFS server:
-
-1. `/etc/default/nfs-kernel-server`
-1. `/etc/default/nfs-common`
-1. `/etc/exports`
-
-The only important option in `/etc/default/nfs-kernel-server` for now is `NEED_SVCGSSD`. It is set to `"no"` by default, which is fine, because we are not activating NFSv4 security this time.
-
-In order for the ID names to be automatically mapped, the file `/etc/idmapd.conf` must exist on both the client and the server with the same contents and with the correct domain names. Furthermore, this file should have the following lines in the `Mapping` section:
-
-```
-[Mapping]
-
-Nobody-User = nobody
-Nobody-Group = nogroup
-```
-
-However, note that the client may have different requirements for the Nobody-User and Nobody-Group. For example, on RedHat variants, it is `nfsnobody` for both. If you're not sure, check via the following commands to see if `nobody` and `nogroup` are there:
-
-```bash
-cat /etc/passwd
-cat /etc/group
-```
-
-This way, server and client do not need the users to share same UID/GUID. For those who use LDAP-based authentication, add the following lines to the `idmapd.conf` of your clients:
-
-```
-[Translation]
-
-Method = nsswitch
-```
-
-This will cause `idmapd` to know to look at `nsswitch.conf` to determine where it should look for credential information. If you have LDAP authentication already working, `nsswitch` shouldn't require further explanation.
-
-To export our directories to a local network `192.168.1.0/24`, we add the following two lines to `/etc/exports`:
-
-```
-/export 192.168.1.0/24(rw,fsid=0,insecure,no_subtree_check,async)
-/export/users 192.168.1.0/24(rw,nohide,insecure,no_subtree_check,async)
-```
-
-### Portmap lockdown (optional)
-The files on your NFS are open to anyone on the network. As a security measure, you can restrict access to specified clients.
-
-Add the following line to `/etc/hosts.deny`:
-
-```
-rpcbind mountd nfsd statd lockd rquotad : ALL
-```
-
-By blocking all clients first, only clients in `/etc/hosts.allow` (added below) will be allowed to access the server.
-
-Now add the following line to `/etc/hosts.allow`:
-
-```
-rpcbind mountd nfsd statd lockd rquotad :
-```
-
-where `` is a list of the IP addresses of the server and all clients. (These have to be IP addresses because of a limitation in `rpcbind`, which doesn't like hostnames.) Note that if you have NIS set up, you can just add these to the same line.
-
-Please ensure that the list of authorised IP addresses includes the `localhost` address (`127.0.0.1`), as the startup scripts in recent versions of Ubuntu use the `rpcinfo` command to discover NFSv3 support, and this will be disabled if `localhost` is unable to connect.
-
-Finally, to make your changes take effect, restart the service:
-
-```bash
-sudo systemctl restart nfs-kernel-server
-```
-
-## Set up an NFSv4 client
-
-Now that your server is running, you need to set up any clients to be able to access it. To start, install the required packages:
-
-```bash
-sudo apt install nfs-common
-```
-
-On the client, we can mount the complete export tree with one command:
-
-```bash
-mount -t nfs -o proto=tcp,port=2049 :/ /mnt
-```
-
-You can also specify the NFS server hostname instead of its IP address, but in this case you need to ensure that the hostname can be resolved to an IP on the client side. A robust way of ensuring that this will always resolve is to use the `/etc/hosts` file.
-
-Note that `:/export` is not necessary in NFSv4, as it was in NFSv3. The root export `:/` defaults to export with `fsid=0`.
-
-We can also mount an exported subtree with:
-
-```bash
-mount -t nfs -o proto=tcp,port=2049 :/users /home/users
-```
-
-To ensure this is mounted on every reboot, add the following line to `/etc/fstab`:
-
-```
-:/ /mnt nfs auto 0 0
-```
-
-If, after mounting, the entry in `/proc/mounts appears` as `://` (with two slashes), then you might need to specify two slashes in `/etc/fstab`, or else `umount` might complain that it cannot find the mount.
-
-### Portmap lockdown (optional)
-
-Add the following line to `/etc/hosts.deny`:
-
-```
-rpcbind : ALL
-```
-
-By blocking all clients first, only clients in `/etc/hosts.allow` (added below) will be allowed to access the server.
-
-Now add the following line to `/etc/hosts.allow`:
-
-```
-rpcbind :
-```
-
-where `` is the IP address of the server.
-
-## NFS server with complex user permissions
-
-NFS user permissions are based on user ID (UID). UIDs of any users on the client must match those on the server in order for the users to have access. The typical ways of doing this are:
-
-* Manual password file synchronisation
-* Use of LDAP
-* Use of DNS
-* Use of NIS
-
-Note that you have to be careful on systems where the main user has root access: that user can change UIDs on the system to allow themselves access to anyone's files. This page assumes that the administrative team is the only group with root access and that they are all trusted. Anything else represents a more advanced configuration, and will not be addressed here.
-
-### Group permissions
-
-A user's file access is determined by their membership of groups on the client, not on the server. However, there is an important limitation: a maximum of 16 groups are passed from the client to the server, and if a user is member of more than 16 groups on the client, some files or directories might be unexpectedly inaccessible.
-
-### DNS (optional, only if using DNS)
-
-Add any client name and IP addresses to `/etc/hosts`. (The IP address of the server should already be there.) This ensures that NFS will still work even if DNS goes down. Alternatively you can rely on DNS if you want - it's up to you.
-
-### NIS (optional, only if using NIS)
-
-This applies to clients using NIS. Otherwise you can't use netgroups, and should specify individual IPs or hostnames in `/etc/exports`. Read the BUGS section in `man netgroup` for more information.
-
-First, edit `/etc/netgroup` and add a line to classify your clients (this step is not necessary, but is for convenience):
-
-```
-myclients (client1,,) (client2,,) ...
-```
-
-where `myclients` is the netgroup name.
-
-Next run this command to rebuild the NIS database:
-
-```bash
-sudo make -C /var/yp
-```
-
-The filename `yp` refers to Yellow Pages, the former name of NIS.
-
-### Portmap lockdown (optional)
-
-Add the following line to `/etc/hosts.deny`:
-
-```
-rpcbind mountd nfsd statd lockd rquotad : ALL
-```
-
-By blocking all clients first, only clients in `/etc/hosts.allow` (added below) will be allowed to access the server.
-
-Consider adding the following line to `/etc/hosts.allow`:
-
-```
-rpcbind mountd nfsd statd lockd rquotad :
-```
-
-where `` is a list of the IP addresses of the server and all clients. These have to be IP addresses because of a limitation in `rpcbind`. Note that if you have NIS set up, you can just add these to the same line.
-
-### Package installation and configuration
-
-Install the necessary packages:
-
-```bash
-sudo apt install rpcbind nfs-kernel-server
-```
-
-Edit `/etc/exports` and add the shares:
-
-```
-/home @myclients(rw,sync,no_subtree_check)
-/usr/local @myclients(rw,sync,no_subtree_check)
-```
-
-The example above shares `/home` and `/usr/local` to all clients in the `myclients` netgroup.
-
-```
-/home 192.168.0.10(rw,sync,no_subtree_check) 192.168.0.11(rw,sync,no_subtree_check)
-/usr/local 192.168.0.10(rw,sync,no_subtree_check) 192.168.0.11(rw,sync,no_subtree_check)
-```
-
-The example above shares `/home` and `/usr/local` to two clients with static IP addresses. If you want instead to allow access to all clients in the private network falling within a designated IP address range, consider the following:
-
-```
-/home 192.168.0.0/255.255.255.0(rw,sync,no_subtree_check)
-/usr/local 192.168.0.0/255.255.255.0(rw,sync,no_subtree_check)
-```
-
-Here, `rw` makes the share read/write, and `sync` requires the server to only reply to requests once any changes have been flushed to disk. This is the safest option; `async` is faster, but dangerous. It is strongly recommended that you read `man exports` if you are considering other options.
-
-After setting up `/etc/exports`, export the shares:
-
-```bash
-sudo exportfs -ra
-```
-
-You'll want to run this command whenever `/etc/exports` is modified.
-
-### Restart services
-
-By default, `rpcbind` only binds to the loopback interface. To enable access to `rpcbind` from remote machines, you need to change `/etc/conf.d/rpcbind` to get rid of either `-l` or `-i 127.0.0.1`.
-
-If any changes are made, rpcbind and NFS will need to be restarted:
-
-```bash
-sudo systemctl restart rpcbind
-sudo systemctl restart nfs-kernel-server
-```
-
-### Security items to consider
-
-Aside from the UID issues discussed above, it should be noted that an attacker could potentially masquerade as a machine that is allowed to map the share, which allows them to create arbitrary UIDs to access your files. One potential solution to this is IPSec. You can set up all your domain members to talk to each other only over IPSec, which will effectively authenticate that your client is who it says it is.
-
-IPSec works by encrypting traffic to the server with the server's public key, and the server sends back all replies encrypted with the client's public key. The traffic is decrypted with the respective private keys. If the client doesn't have the keys that it is supposed to have, it can't send or receive data.
-
-An alternative to IPSec is physically separate networks. This requires a separate network switch and separate Ethernet cards, and physical security of that network.
-
-## Troubleshooting
-
-Mounting an NFS share inside an encrypted home directory will only work after you are successfully logged in and your home is decrypted. This means that using /etc/fstab to mount NFS shares on boot will not work, because your home has not been decrypted at the time of mounting. There is a simple way around this using symbolic links:
-
-1. Create an alternative directory to mount the NFS shares in:
-
-```bash
-sudo mkdir /nfs
-sudo mkdir /nfs/music
-```
-
-2. Edit `/etc/fstab` to mount the NFS share into that directory instead:
-
-```
-nfsServer:music /nfs/music nfs auto 0 0
-```
-
-3. Create a symbolic link inside your home, pointing to the actual mount location. For example, and in this case deleting the `Music` directory already existing there first:
-
-```bash
-rmdir /home/user/Music
-ln -s /nfs/music/ /home/user/Music
-```
-
-## Author information
-
-This guide is based on documents on the official Ubuntu wiki:
-
-1. https://help.ubuntu.com/community/SettingUpNFSHowTo
-1. https://help.ubuntu.com/stable/serverguide/network-file-system.html
diff --git a/configuration/pin-configuration.md b/configuration/pin-configuration.md
deleted file mode 100644
index 05c9cd81ba..0000000000
--- a/configuration/pin-configuration.md
+++ /dev/null
@@ -1,142 +0,0 @@
-# Changing the default pin configuration
-
-**This feature is intended for advanced users.**
-
-As of 15 July 2014, the Raspberry Pi firmware supports custom default pin configurations through a user-provided Device Tree blob file. To find out whether your firmware is recent enough, please run `vcgencmd version`.
-
-## Actions on device pins during boot sequence
-
-During the bootup sequence, the GPIO pins go through various actions.
-
-1. Power-on — pins default to inputs with default pulls; the default pulls for each pin are described in the [datasheet](../hardware/raspberrypi/bcm2835/BCM2835-ARM-Peripherals.pdf)
-1. Setting by the bootrom
-1. Setting by `bootcode.bin`
-1. Setting by `dt-blob.bin` (this page)
-1. Setting by the GPIO command in `config.txt` (see [here](config-txt/gpio.md))
-1. Additional firmware pins (e.g. UARTS)
-1. Kernel/Device Tree
-
-On a soft reset, the same procedure applies, except for default pulls, which are only applied on a power-on reset.
-
-Note that it may take a few seconds to get from stage 1 to stage 4. During that time, the GPIO pins may not be in the state expected by attached peripherals (as defined in `dtblob.bin` or `config.txt`). Since different GPIO pins have different default pulls, you should do **one of the following** for your peripheral:
-* Choose a GPIO pins that defaults to pulls as required by the peripheral on reset
-* Delay the peripheral's startup until stage 4/5 has been reached
-* Add an appropriate pull-up/-down resistor
-
-
-## Providing a custom Device Tree blob
-
-In order to compile a Device Tree source (`.dts`) file into a Device Tree blob (`.dtb`) file, the Device Tree compiler must be installed by running `sudo apt install device-tree-compiler`. The `dtc` command can then be used as follows:
-
-```
-sudo dtc -I dts -O dtb -o /boot/dt-blob.bin dt-blob.dts
-```
-
-**NOTE:** In the case of NOOBS installs, the DTB file should be placed on the recovery partition instead.
-
-Similarly, a `.dtb` file can be converted back to a `.dts` file, if required.
-
-```
-dtc -I dtb -O dts -o dt-blob.dts /boot/dt-blob.bin
-```
-
-## Sections of the dt-blob
-
-The `dt-blob.bin` is used to configure the binary blob (VideoCore) at boot time. It is not currently used by the Linux kernel, but a kernel section will be added at a later stage, when we reconfigure the Raspberry Pi kernel to use a dt-blob for configuration. The dt-blob can configure all versions of the Raspberry Pi, including the Compute Module, to use the alternative settings. The following sections are valid in the dt-blob:
-
-1. `videocore`
-
- This section contains all of the VideoCore blob information. All subsequent sections must be enclosed within this section.
-
-2. `pins_*`
-
- There are a number of separate `pins_*` sections, based on particular Raspberry Pi models, namely:
-
- - **pins_rev1** Rev1 pin setup. There are some differences because of the moved I2C pins.
- - **pins_rev2** Rev2 pin setup. This includes the additional codec pins on P5.
- - **pins_bplus1** Model B+ rev 1.1, including the full 40pin connector.
- - **pins_bplus2** Model B+ rev 1.2, swapping the low-power and lan-run pins.
- - **pins_aplus** Model A+, lacking Ethernet.
- - **pins_2b1** Pi 2 Model B rev 1.0; controls the SMPS via I2C0.
- - **pins_2b2** Pi 2 Model B rev 1.1; controls the SMPS via software I2C on 42 and 43.
- - **pins_3b1** Pi 3 Model B rev 1.0
- - **pins_3b2** Pi 3 Model B rev 1.2
- - **pins_3bplus** Pi 3 Model B+
- - **pins_3aplus** Pi 3 Model A+
- - **pins_pi0** The Pi Zero
- - **pins_pi0w** The Pi Zero W
- - **pins_cm** The Compute Module. The default for this is the default for the chip, so it is a useful source of information about default pull ups/downs on the chip.
- - **pins_cm3** The Compute Module version 3
-
- Each `pins_*` section can contain `pin_config` and `pin_defines` sections.
-
-3. `pin_config`
-
- The `pin_config` section is used to configure the individual pins. Each item in this section must be a named pin section, such as `pin@p32`, meaning GPIO32. There is a special section `pin@default`, which contains the default settings for anything not specifically named in the pin_config section.
-
-4. `pin@pinname`
-
- This section can contain any combination of the following items:
-
- 1. `polarity`
- * `active_high`
- * `active_low`
- 2. `termination`
- * `pull_up`
- * `pull_down`
- * `no_pulling`
- 3. `startup_state`
- * `active`
- * `inactive`
- 4. `function`
- * `input`
- * `output`
- * `sdcard`
- * `i2c0`
- * `i2c1`
- * `spi`
- * `spi1`
- * `spi2`
- * `smi`
- * `dpi`
- * `pcm`
- * `pwm`
- * `uart0`
- * `uart1`
- * `gp_clk`
- * `emmc`
- * `arm_jtag`
- 5. `drive_strength_mA`
- The drive strength is used to set a strength for the pins. Please note that you can only specify a single drive strength for the bank. <8> and <16> are valid values.
-
-5. `pin_defines`
-
- This section is used to set specific VideoCore functionality to particular pins. This enables the user to move the camera power enable pin to somewhere different, or move the HDMI hotplug position: things that Linux does not control. Please refer to the example DTS file below.
-
-## Clock configuration
-
-It is possible to change the configuration of the clocks through this interface, although it can be difficult to predict the results! The configuration of the clocking system is very complex. There are five separate PLLs, and each one has its own fixed (or variable, in the case of PLLC) VCO frequency. Each VCO then has a number of different channels which can be set up with a different division of the VCO frequency. Each of the clock destinations can be configured to come from one of the clock channels, although there is a restricted mapping of source to destination, so not all channels can be routed to all clock destinations.
-
-Here are a couple of example configurations that you can use to alter specific clocks. We will add to this resource when requests for clock configurations are made.
-
-```
-clock_routing {
- vco@PLLA { freq = <1966080000>; };
- chan@APER { div = <4>; };
- clock@GPCLK0 { pll = "PLLA"; chan = "APER"; };
-};
-
-clock_setup {
- clock@PWM { freq = <2400000>; };
- clock@GPCLK0 { freq = <12288000>; };
- clock@GPCLK1 { freq = <25000000>; };
-};
-```
-
-The above will set the PLLA to a source VCO running at 1.96608GHz (the limits for this VCO are 600MHz - 2.4GHz), change the APER channel to /4, and configure GPCLK0 to be sourced from PLLA through APER. This is used to give an audio codec the 12288000Hz it needs to produce the 48000 range of frequencies.
-
-## Sample Device Tree source file
-
-This example file comes from the firmware repository. It is the master Raspberry Pi blob, from which others are usually derived.
-
-https://github.com/raspberrypi/firmware/blob/master/extra/dt-blob.dts
diff --git a/configuration/raspi-config.md b/configuration/raspi-config.md
deleted file mode 100644
index e5a4ad634a..0000000000
--- a/configuration/raspi-config.md
+++ /dev/null
@@ -1,291 +0,0 @@
-# raspi-config
-
-This page describes the console based raspi-config application. If you are using the Raspberry Pi desktop then you can use the graphical `Raspberry Pi Configuration` application from the `Preferences` menu to configure your Raspberry Pi.
-
-`raspi-config` is the Raspberry Pi configuration tool originally written by [Alex Bradbury](https://github.com/asb). It targets Raspberry Pi OS.
-
-
-## Usage
-
-You will be shown `raspi-config` on first booting into Raspberry Pi OS. To open the configuration tool after this, simply run the following from the command line:
-
-```
-sudo raspi-config
-```
-
-The `sudo` is required because you will be changing files that you do not own as the `pi` user.
-
-You should see a blue screen with options in a grey box:
-
-
-
-Note that the menu shown may differ slightly.
-
-It has the following top level options available:
-
-```
-┌───────────────────┤ Raspberry Pi Software Configuration Tool (raspi-config) ├────────────────────┐
-│ │
-│ 1 System Options Configure system settings │
-│ 2 Display Options Configure display settings │
-│ 3 Interface Options Configure connections to peripherals │
-│ 4 Performance Options Configure performance settings │
-│ 5 Localisation Options Configure language and regional settings │
-│ 6 Advanced Options Configure advanced settings │ │
-│ 8 Update Update this tool to the latest version │
-│ 9 About raspi-config Information about this configuration tool │
-│ │
-│ │
-│