Configure Wi-Fi SSID and passphrase.

Specify the audio output destination.

Change your password.

For more information, see Change a user’s password.

Set the visible mDNS name for this Raspberry Pi on a network.

Boot to console or desktop with the option of an automatic login to your current user account.

Wait for a network connection before proceeding with boot.

Enable or disable the splash screen displayed at boot time.

If your Raspberry Pi model allows, change the behaviour of the power LED.

Change the default web browser.

If the initial text shown on the screen disappears off the edge, enable overscan to adjust the border. On some displays, particularly monitors, disabling overscan will make the picture fill the whole screen and remove the black border.

Enable or disable screen blanking.

Define the video resolution to use in headless setups.

Enable or disable composite video.

Enable or disable 4Kp60 resolution for HDMI outputs.

Enable or disable remote terminal access to your Raspberry Pi using SSH.

SSH allows you to remotely access the command line of the Raspberry Pi from another computer. SSH is disabled by default. For more information about SSH, see the SSH documentation.

Enable or disable Raspberry Pi Connect, which provides the ability to access your Raspberry Pi remotely with no manual network configuration.

Enable or disable the WayVNC or RealVNC virtual network computing server.

Enable or disable SPI interfaces and automatic loading of the SPI kernel module.

Enable or disable I2C interfaces and automatic loading of the I2C kernel module.

Enable or disable shell and kernel messages on the serial connection.

Enable or disable the Dallas 1-wire interface, often used for DS18B20 temperature sensors.

Enable or disable remote access to the GPIO pins.

If your Raspberry Pi model allows, overclock the CPU. Overclocking potential varies between individual Raspberry Pi devices, even within the same model. Overclocking too high may result in instability.

Change the amount of memory made available to the GPU.

Enable or disable a read-only filesystem.

Customise the behaviour of the GPIO-connected Raspberry Pi 4 Case Fan. Not applicable to other fan models.

Select a locale, for example en_GB.UTF-8 UTF-8.

Set your local time zone in the format Region/City, for example 'Europe/London'. Type a letter to jump to that letter in the list.

Open a menu where you can select your keyboard layout. Changes usually take effect immediately, but may require a reboot. Type a letter to jump to that letter in the list.

Set the country code for your wireless network.

Expand your OS partition to fill the whole storage device, giving you more space to use for files. Reboot your Raspberry Pi to complete this action. Normally, Raspberry Pi OS runs this action on first boot. This option can be useful if you clone your OS to a separate storage device with more capacity than the original.

Enable or disable predictable network interface names.

Configure the network’s proxy settings.

On Raspberry Pi 4 and later, specify whether to boot from USB or network when no SD card or SSD has been detected. For more information, see bootloader configuration.

On the Raspberry Pi 4 and later, switch to the latest boot ROM software. Alternatively, you can revert to the factory default if the latest version causes problems.

Switch between the X11 and Wayland backends, and choose a window manager. Since Raspberry Pi OS Bookworm, all Raspberry Pi models run Wayland using labwc by default.

Switch between the PulseAudio and PipeWire audio backends. Prior to Raspberry Pi OS Bookworm, Raspberry Pi OS used PulseAudio.

Configure Wi-Fi SSID and passphrase.

Pass a wireless network name (SSID) and passphrase, if required. The following flags are optional:

The <hidden> option indicates the visibility of the SSID. If the network broadcasts an open SSID, pass 0 or omit the option. If your SSID is hidden, pass 1. Defaults to 0.

The <plain> option indicates whether you intend to pass the passphrase as plaintext. If your passphrase includes a space or a special character like !, you must pass 0 and use quotes around your passphrase. Otherwise, you can pass 1 or omit the option. Defaults to 1. To pass this option, you must specify a value for <hidden>.

For example, run the following commands to connect to a:

Specify the audio output destination.

On Raspberry Pi 4B, you can use the following options:

For a full list of possible <N> values, see the numbers used in the interactive raspi-config version of this option.

Change your password.

For more information, see Change a user’s password.

Set the visible mDNS name for this Raspberry Pi on a network.

Select the following behaviour at boot time:

Wait for a network connection before letting boot proceed.

Enable or disable the splash screen displayed at boot time.

If your Raspberry Pi model allows, change the behaviour of the power LED.

Change the default web browser. Choosing a web browser that isn’t currently installed won’t work.

If the initial text shown on the screen disappears off the edge, enable overscan to adjust the border. On some displays, particularly monitors, disabling overscan will make the picture fill the whole screen and remove the black border.

Device:

Enabled:

Enable or disable screen blanking.

Define the video resolution to use for VNC in headless setups.

Enable or disable composite video output.

On Raspberry Pi 4:

On other models:

Enable or disable remote terminal access to your Raspberry Pi using SSH.

SSH allows you to remotely access the command line of the Raspberry Pi from another computer. For more information about SSH, see the SSH documentation.

Enable or disable Raspberry Pi Connect, which provides the ability to access your Raspberry Pi remotely with no manual network configuration.

Enable or disable a Virtual Network Computing (VNC) server. For more information about VNC, see the VNC documentation.

Enable or disable SPI interfaces and automatic loading of the SPI kernel module.

Enable or disable I2C interfaces and automatic loading of the I2C kernel module.

Enable or disable the serial connection hardware.

Enable or disable shell and kernel messages on the serial connection.

Enable or disable the Dallas 1-wire interface. This is usually used for DS18B20 temperature sensors.

Enable or disable remote access to the GPIO pins.

If your Raspberry Pi model allows, overclock the CPU. Overclocking potential varies between individual Raspberry Pi devices, even within the same model. Overclocking too high may result in instability.

This command accepts the following <setting> values:

Change the amount of memory made available to the GPU.

Enable or disable a read-only filesystem.

Customise the behaviour of the GPIO-connected Raspberry Pi 4 Case Fan. This setting is inapplicable to other fan models.

gpio defaults to 14.

onTemp defaults to 80 degrees Celsius.

Select a locale, for example en_GB.UTF-8 UTF-8.

For a full list of possible <locale> values, see the abbreviations used in the interactive raspi-config version of this option.

Set your local time zone in the format Region/City, for example 'Europe/London'.

For a full list of possible <timezone> values, see the abbreviations used in the interactive raspi-config version of this option.

Set your keyboard layout. Changes usually take effect immediately, but may require a reboot.

For a full list of possible <keymap> values, see the the abbreviations used in the interactive raspi-config version of this option.

Set the country code for your wireless network.

For a full list of possible <country> values, see the abbreviations used in the interactive raspi-config version of this option.

Expand your OS partition to fill the whole storage device, giving you more space to use for files. Reboot the Raspberry Pi to complete this action. Normally, Raspberry Pi OS runs this action on first boot. This option can be useful if you clone your OS to a separate storage device with more capacity than the original.

Enable or disable predictable network interface names.

Configure the network’s proxy settings.

On the Raspberry Pi 4 and later, specify whether to boot from USB or network in absence of an SD card. See the bootloader configuration section for more information.

Depending on your device, you can choose from the following options:

On the Raspberry Pi 4 and later, switch to the latest boot ROM software. Alternatively, you can revert to the factory default if the latest version causes problems.

Switch between the X11 and Wayland backends, and choose a window manager. Since Raspberry Pi OS Bookworm, all Raspberry Pi models run Wayland using the labwc window manager by default.

Use this option to switch between the PulseAudio and PipeWire audio backends. Prior to Raspberry Pi OS Bookworm, Raspberry Pi OS used PulseAudio.

On the Raspberry Pi Desktop, open the Preferences menu and select the Screen Configuration utility. You should see a graphical representation of the displays connected to the Raspberry Pi. Right click on the display you wish to modify, and select an option. Click Apply to and close Screen Configuration to save your changes.

Use the following command to open the Screen Configuration utility:

You should see a graphical representation of the displays connected to the Raspberry Pi. Right click on the display you wish to modify, and select an option. Click Apply to and close Screen Configuration to save your changes.

To manually configure resolution and rotation, you’ll need to know the names of your display devices. To determine the device names, run the following command to display information about attached devices:

To set a custom resolution, use our Screen Configuration tool, raindrop. If your Raspberry Pi OS installation doesn’t already include raindrop (for instance, if you’re still using the previous Screen Configuration tool, arandr), you can download raindrop from apt or the Recommended Software GUI.

To set a custom resolution, use our Screen Configuration tool, raindrop. If your Raspberry Pi OS installation doesn’t already include raindrop (for instance, if you’re still using the previous Screen Configuration tool, arandr), you can download raindrop from apt or the Recommended Software GUI.

If you run the Wayland desktop compositor, you can set a custom display rotation with wlr-randr. The following commands rotate the display by 0°, 90°, 180°, and 270°:

The --output option specifies the device to be rotated.

You can also use one of the following --transform options to mirror the display at the same time as rotating it: flipped, flipped-90, flipped-180, flipped-270.

Right-click the volume icon on the system tray to open the audio output selector. This interface lets you choose an audio output device. Click an audio output device to switch audio output to that device.

To change your audio output using raspi-config, run the following command:

You should see a configuration screen. Complete the following steps to change your audio output:

Access Network Manager via the network icon at the right-hand end of the menu bar. If you are using a Raspberry Pi with built-in wireless connectivity, or if a wireless dongle is plugged in, click this icon to bring up a list of available wireless networks. If you see the message 'No APs found - scanning…​', wait a few seconds, and Network Manager should find your network.

The icons on the right show whether a network is secured or not, and give an indication of signal strength. Click the network that you want to connect to. If the network is secured, a dialogue box will prompt you to enter the network key:

Enter the key and click OK, then wait a couple of seconds. The network icon will flash briefly to show that a connection is being made. When connected, the icon will stop flashing and show the signal strength.

This guide will help you configure a wireless connection on your Raspberry Pi from a terminal without using graphical tools. No additional software is required.

Click the Raspberry Pi button in the menu bar. Navigate to Preferences > Raspberry Pi Configuration.

Select the Display tab. Toggle the Screen Blanking radio button into the on position. Press OK to confirm your selection.

You can enable and disable screen blanking with the raspi-config CLI tool. Run the following command to open the tool:

Use the arrow keys to navigate and the Enter key to select. Select Display Options > Screen Blanking. Choose yes with the arrow keys to enable screen blanking, or no to disable screen blanking.

To change the console mode screen blanking configuration, open /boot/firmware/cmdline.txt in a text editor as an administrator:

You can adjust the number of seconds before Raspberry Pi OS blanks the console here. For instance, add consoleblank=600 to disable display output after 600 seconds of inactivity. Set the value to 0 to never blank the screen.

Changes to cmdline.txt only take effect after a reboot. Use the following command to reboot your Raspberry Pi:

You can display the current console blank time in seconds with the following command:

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.

Close any program which has open files on the storage device. 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.

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:

To use lsof:

The legacy firmware and FKMS display modes used in earlier versions of Raspberry Pi OS are no longer supported. Instead, recent OS versions use KMS (Kernel Mode Setting).

If no video entry is present in cmdline.txt, Raspberry Pi OS uses the EDID of the HDMI-connected monitor to automatically pick the best resolution supported by your display based on information in the Linux kernel. In Raspberry Pi OS Lite or console mode, you must customise the video entry to control resolution and rotation.

In addition, it is possible to add rotation and reflect parameters as documented in the standard Linux framebuffer documentation. The following example defines a display named HDMI-A-1 at a resolution of 1080p, a refresh rate of 60Hz, 90 degrees of rotation, and a reflection over the X axis:

You must specify the resolution explicitly when specifying rotation and reflection parameters.

Possible options for the display type - the first part of the video= entry - include:

This section contains some of the other entries you can use in the kernel command line. This list is not exhaustive.

You can also allow or deny specific users by altering the sshd configuration.

Add, edit, or append to the end of the file the following line, which contains the usernames you wish to allow to log in:

You can also use DenyUsers to specifically stop some usernames from logging in:

After the change, restart the sshd service with the following command to put your changes into effect:

At the root of the first partion of your SD card (the filesystem labeled bootfs), create a file named userconf.txt.

This file should contain a single line of text, consisting of <username>:<password>: your desired username, followed immediately by a colon, followed immediately by an encrypted representation of the password you want to use.

To generate the encrypted password, use OpenSSL on another computer. Open a terminal and enter the following:

When prompted, enter your password and verify it. This command will then output an encrypted version of the supplied password.

Device Trees are usually written in a textual form known as Device Tree Source (DTS), and are 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 structs 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:

This tree contains:

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:

Cells are 32-bit unsigned integers delimited by angle brackets:

Arbitrary byte data is delimited with square brackets, and entered in hex:

Data of differing representations can be concatenated using a comma:

Commas are also used to create lists of strings:

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:

It is therefore possible for one .dtsi to overwrite, or provide defaults for, multiple places in a tree.

It is often necessary for one part of the tree to refer to another, and there are four ways to do this:

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 highlighting:

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:

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 Raspberry Pi 4 then brcm,bcm2711 is the correct value to use, otherwise brcm,bcm2835 can be used for all Raspberry 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:

With a sufficiently new version of dtc you can write the example exactly as above and get identical output, but some homegrown tools don’t understand this format yet. Any overlay that you might want to see 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:

…​you will get an error:

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):

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:

Dump the contents of the DTB file to see what the compiler has generated:

This should output something similar to the following:

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:

Back in section 1.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.

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.

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).

Sometimes 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 __exports__ node:

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.

Under most circumstances it shouldn’t matter in 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:

This split is particularly important for runtime overlays, since the first step occurs in the dtoverlay utility, and the second is performed by the kernel (which can’t handle intra-overlay fragments).

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/firmware/ 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.

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:

This will cause the loader to look for overlays/acme-board.dtbo in the firmware partition, which Raspberry Pi OS mounts on /boot/firmware/. 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 multiple ways to tell that the kernel is using Device Tree:

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).

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:

If you have an overlay that defines some parameters, they can be specified either on subsequent lines like this:

…​or appended to the overlay line like this:

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; it’s recommended that you avoid doing this. To expose the parameter exported by the base DTB instead, end the current overlay scope using:

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 Raspberry Pis, the firmware creates some board-specific DT parameters. These are:

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 Raspberry Pi Camera or Raspberry Pi Touch 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:

Any overlays using the numeric variants will be modified to use the new aliases.

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.

As of Linux 4.4, Raspberry Pi kernels support the dynamic loading of overlays and parameters. Compatible kernels manage a stack of overlays that are applied on top of the base DTB. Changes are immediately reflected in /proc/device-tree and can cause modules to be loaded and platform devices to be created and destroyed.

The use of the word "stack" above is important - overlays can only be added and removed at the top of the stack; changing something further down the stack requires that anything on top of it must first be removed.

There are some new commands for managing overlays:

For a list of supported overlays and parameters, see the README file found alongside the overlay .dtbo files in /boot/firmware/overlays. It is kept up-to-date with additions and changes.

Each property is stored as a 32-bit integer unless indicated otherwise.

Raspberry Pi 5 only. Each property is stored as a 32-bit integer unless indicated otherwise.

The format is defined by the USB Power Delivery specification.

The following properties are specific to the BCM2711 and BCM2712 SPI EEPROM bootloaders. Each property is stored as a 32-bit integer unless indicated otherwise.

The following properties are defined if the system was booted from USB. These may be used to uniquely identify the USB boot device. Each property is stored as a 32-bit integer.

The firmware provides read-only, in-memory copies of portions of the bootloader EEPROM via the NVMEM subsystem.

Each region appears as an NVMEM device under /sys/bus/nvmem/devices/ with a named alias under /sys/firmware/devicetree/base/aliases.

Example shell script code for reading an NVMEM mode from rpi-eeprom-update:

For more information, see secure-boot.

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:

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:

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/<version>/modules.alias for the compatible value. Otherwise, your driver is probably missing either:

or:

Failing that, depmod has failed or the updated modules haven’t been installed on the target filesystem.

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:

Generate it from the live DT state in /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:

Copy it from the source DTBs in /boot/firmware/. 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:

(the - indicates an absent overlay name).

You can now try applying an overlay or parameter:

which will return:

You can also compare different overlays or parameters.

to get:

The 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.

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 usage is required in Raspberry Pi Linux kernels. For bare metal and other OSs, DT usage can be disabled by adding:

to config.txt.

The loader understands a few shortcuts:

can be shortened to:

(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.

Further ports can be controlled by the DT. For more details see section 3.

If you’ve read through this document and have 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 forum.

This section contains all of the VideoCore blob information. All subsequent sections must be enclosed within this section.

There are a number of separate pins_* sections, based on particular Raspberry Pi models, namely: