配置

系统选项子菜单允许您对引导、登录和网络过程的各个部分进行配置更改，以及其他一些系统级更改。

在此子菜单中，有以下选项可以启用/禁用：相机、SSH、VNC、SPI、I2C、串行、1 线和远程 GPIO。

在某些型号上，可以使用此工具对Raspberry Pi的 CPU 进行超频。您可以实现的超频会有所不同;超频过高可能会导致不稳定。选择此选项将显示以下警告：

*请注意，超频可能会缩短Raspberry Pi的使用寿命。*如果达到一定水平的超频导致系统不稳定，请尝试更适度的超频。在启动过程中按住 Shift 键可暂时禁用超频。

本地化子菜单为您提供了以下选项供您选择：键盘布局、时区、区域设置和无线 LAN 国家/地区代码。

将此工具更新到最新版本。

选择此选项将显示以下文本：

完成更改后使用此按钮。系统将询问您是否要重新启动。首次使用时，最好重新启动。如果您选择调整SD卡的大小，则重新启动将有延迟。

允许设置无线局域网SSID和密码。

hidden 0 = 可见，1 = 隐藏。默认为可见。 普通：如果 plain 是 1，则默认，密码短语被引用 例：

指定音频输出目标。

在此子菜单中，有以下选项可以启用/禁用：相机、SSH、VNC、SPI、I2C、串行、1-wire和远程 GPIO。

在某些型号上，可以使用此工具对Raspberry Pi的 CPU 进行超频。您可以实现的超频会有所不同;超频过高可能会导致不稳定。选择此选项将显示以下警告：

请注意，超频可能会缩短Raspberry Pi的使用寿命。 如果达到一定水平的超频导致系统不稳定，请尝试更适度的超频。在启动过程中按住 Shift 键可暂时禁用超频。

设置是以下设置之一: - None - 默认 - Modest - 超频至最大值的50% - Medium - 超频至最大值的 75% - High - 超频至最大值的100% - Turbo - 超频至最大值的 125%

本地化子菜单为您提供了以下选项供您选择：键盘布局、时区、区域设置和无线 LAN 国家/地区代码。

将此工具更新到最新版本。

启用无线网络的最快方法是使用命令行工具 raspi-config。

sudo raspi-config

从菜单中选择 Localisation Options，然后选择 Change wireless country 选项。在全新安装中，出于监管目的，您需要指定使用设备的国家/地区。然后设置网络的 SSID 和网络的密码。如果您不知道要连接的网络的 SSID，请参阅下一节，了解如何在raspi-config运行之前列出可用网络。

请注意， raspi-config 它不提供用于设置无线网络的完整选项集;如果raspi-config无法将Raspberry Pi连接到您请求的网络，您可能需要参考下面的额外部分以获取更多详细信息。

要扫描无线网络，请使用命令 sudo iwlist wlan0 scan 。这将列出所有可用的无线网络以及其他有用信息。注意：

在 nano 中打开配置文件 wpa-supplicant：

sudo nano /etc/wpa_supplicant/wpa_supplicant.conf

转到文件底部并添加以下内容：

密码可以配置为 ASCII 表示形式、根据上述示例用引号表示形式或预加密的 32 字节十六进制数。您可以使用该 wpa_passphrase 实用程序生成加密的 PSK。这将获取 SSID 和密码，并生成加密的 PSK。通过上面的示例，您可以使用 wpa_passphrase "testing" .然后，系统将要求您输入无线网络的密码（在这种情况下testingPassword）。输出如下：

请注意，代码的纯文本版本存在，但已注释掉。您应该从 wpa_supplicant 最终文件中删除此行以提高安全性。

该 wpa_passphrase 工具需要 8 到 63 个字符的密码。要使用更复杂的密码，可以提取文本文件的内容并将其用作 wpa_passphrase 的输入。将密码存储在文本文件中，并通过调用 wpa_passphrase "testing"<file_where_password_is_stored 将其输入到 wpa_passphrase 。为了提高安全性，您应该删除 file_where_password_is_stored 之后的，因此系统上没有原始密码的纯文本副本。 要使用 wpa_passphrase --encrypted 的 PSK，您可以将加密的 PSK 复制并粘贴到文件 wpa_supplicant.conf 中，或者通过以下两种方式之一将工具的输出重定向到配置文件：

如果要使用这两个选项之一，请确保使用 >>，或者使用 tee -a — 两者都会将文本附加到现有文件。使用单个 > ，或者在使用 tee 时省略 -a ，将擦除所有内容，然后将输出附加到指定的文件。

现在通过按 Ctrl+X 保存文件 ，然后按 Y ，最后按 Enter。

使用 `wpa_cli -i wlan0 reconfigure`重新配置接口.

您可以使用ifconfig wlan0 验证它是否已成功连接。如果字段。inet addr旁边有地址，则Raspberry Pi已连接到网络。如果没有，请检查您的密码和 ESSID 是否正确

您可以使用 ifconfig wlan0 验证它是否已成功连接。如果字段。 inet addr 旁边有地址，则Raspberry Pi已连接到网络。如果没有，请检查您的密码和 ESSID 是否正确

在Raspberry Pi3B+和Raspberry Pi4B上，您还需要设置国家/地区代码，以便5GHz网络可以选择正确的频段。您可以使用该 raspi-config 应用程序执行此操作：选择“本地化选项”菜单，然后选择 'Change Wi-Fi Country' 。或者，您可以编辑 wpa_supplicant.conf 文件并添加以下内容。（注意：您需要将“GB”替换为您所在国家/地区的 2 个字母的 ISO 代码。请参阅 维基百科 以获取 2 个字母的 ISO 3166-1 国家/地区代码列表。

请注意，对于最新的Buster Raspberry Pi OS版本，您必须确保该 wpa_supplicant.conf 文件在顶部包含以下信息：

如果要连接到的网络不使用密码，则 wpa_supplican 网络的条目需要包含正确的 tkey_mgmt 条目。 例如

如果您使用的是隐藏网络，则 wpa_supplicant file, scan_ssid 中的额外选项可能有助于连接。

您可以使用 ifconfig wlan0 验证它是否已成功连接。如果字段 inet addr 旁边有地址，则Raspberry Pi已连接到网络。如果没有，请检查您的密码和ESSID是否正确。

在最新版本的Raspberry Pi操作系统上，可以为无线网络设置多个配置。例如，您可以为家庭设置一个，为学校设置一个。

例如

如果范围内有两个网络，则可以添加优先级选项以在它们之间进行选择。范围内具有最高优先级的网络将是连接的网络。

Raspberry Pi为无线网络运行DHCP服务器;这需要Raspberry Pi中无线接口 （wlan0） 的静态 IP 配置。 Raspberry Pi还充当无线网络上的路由器，按照惯例，我们将为其提供网络中的第一个 IP 地址: 192.168.4.1.

要配置静态 IP 地址，请使用以下命令编辑dhcpcd配置文件：

转到文件末尾并添加以下内容：

本节将 Raspberry Pi 配置为允许无线客户端访问主（以太网）网络上的计算机，并从那里访问互联网。

要启用路由，即允许流量在Raspberry Pi中从一个网络流向另一个网络，请使用以下命令创建一个文件，内容如下：

文件内容：

启用路由将允许来自网络 192.168.4.0/24 的主机到达 LAN 和主路由器，连接互联网。为了允许此外部无线网络上的客户端与互联网之间的流量而不更改主路由器的配置，Raspberry Pi可以使用“伪装”防火墙规则将无线客户端的IP地址替换为LAN上自己的IP地址。

Raspberry Pi将接收所有传入流量，替换 IP 地址，并将流量转发到原始无线客户端。

现在保存 IPv4（包括上述规则）和 IPv6 的当前防火墙规则，以便在 netfilter-persistent 服务启动时加载：

过滤规则将保存到目录 /etc/iptables/ 中。如果将来更改防火墙的配置，请确保在重新启动之前保存配置。

DHCP 和 DNS 服务由 dnsmasq 提供。默认配置文件用作所有可能的配置选项的模板，而我们只需要几个。从空文件开始更容易。

重命名默认配置文件并编辑一个新配置文件：

将以下内容添加到文件并保存：

Raspberry Pi将在 192.168.4.2 和 192.168.4.20 之间提供 IP 地址，租用时间为 24 小时，到无线 DHCP 客户端。您应该能够从无线客户端以该gw.wlan名称访问Raspberry Pi。

还有 dnsmasq 更多选项 ;有关详细信息，请参阅默认配置文件 （/etc/dnsmasq.conf） 或http://www.thekelleys.org.uk/dnsmasq/doc.html[联机文档]。

通过使用以下命令创建文件来添加网桥网络设备br0，内容如下：

文件内容：

为了将以太网网络与无线网络桥接，首先通过创建以下文件将内置以太网接口 （eth0） 添加为网桥成员：

文件内容：

接入点软件将在服务启动时将无线接口wlan0添加到网桥。无需为该接口创建文件。这种情况特定于无线 LAN 接口。

作为网桥设备成员的网络接口永远不会分配 IP 地址，因为它们通过网桥进行通信。桥接设备本身需要一个 IP 地址，以便您可以在网络上访问您的Raspberry Pi。

dhcpcd，Raspberry Pi上的 DHCP 客户端会自动为每个活动接口请求一个 IP 地址。因此，我们需要阻止处理 eth0 和 wlan0，并 dhcpcd 仅通过 DHCP 进行配置 br0。

在文件开头附近添加以下行（第一行上方interface xxx，如果有）：

Go to the end of the file and add the following:

使用此行，接口 br0 将通过 DHCP 根据默认值进行配置。保存文件以完成计算机的 IP 配置。

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：

这将打开配置屏幕：

选择 System Options （当前选项 1，但您的选项可能不同）并按 Enter 。

现在选择名为的选项 Audio （当前选项S2，但您的选项可能不同），然后按 Enter：

选择所需的模式，然后按 Enter 向右箭头键退出选项列表，然后选择 Finish 退出配置工具。

修改完音频设置后，您需要重新启动Raspberry Pi才能使更改生效。

'target is busy' 消息表示存储设备上有程序正在使用的文件。若要关闭文件，请使用以下过程。

+ 要使用 lsof：

+

设备树通常以称为设备树源 （DTS） 的文本形式编写，并存储在带有后缀的 .dts 文件中。DTS 语法类似于 C，每行末尾都有用于分组的大括号和分号。请注意，DTS 在右大括号后需要分号：考虑 C struct 而不是函数。编译的二进制格式称为平展设备树 （FDT） 或设备树 Blob （DTB），存储在.dtb文件中。

以下是 .dts 格式的简单树：

此树包含：

属性是简单的键值对，其中的值可以是空的，也可以包含任意字节流。虽然数据类型没有在数据结构中编码，但是有一些基本的数据表示可以在设备树源文件中表达。

文本字符串（以 NUL 结尾）用双引号表示：

单元格是用尖括号分隔的 32 位无符号整数：

任意字节数据用方括号分隔，并以十六进制输入：

不同表示形式的数据可以使用逗号连接：

逗号也用于创建字符串列表：

/include/ 指令导致简单的文本包含，很像C #的 #include 指令，但是设备树编译器的一个特性导致不同的使用模式。假定节点是命名的，可能带有绝对路径，则同一个节点可能会在DTS文件(及其包含文件)中出现两次。当这种情况发生时，节点和属性被组合，根据需要交错和覆盖属性(后面的值覆盖前面的值)。

在上面的示例中，第二次 /node2 出现会导致将新属性添加到原始属性：

因此， .dtsi 可以覆盖树中的多个位置或为树中的多个位置提供默认值。

树的一部分通常需要引用另一部分，有四种方法可以做到这一点：

如何构建设备树，以及如何最好地使用它来捕获某些硬件的配置，是一个庞大而复杂的主题。有许多可用的资源，下面列出了其中一些资源，但本文档中有几点值得一提：

compatible 属性是硬件描述和驱动程序软件之间的链接。当操作系统遇到具有 compatible 属性的节点时，它会在设备驱动程序数据库中查找，以找到最佳匹配。在Linux中，这通常会导致驱动程序模块被自动加载，前提是它已经被适当地标记并且没有被列入黑名单。

status 属性表示设备是启用还是禁用。如果 status 为 ok, okay 或 absent，则设备已启用。否则，应禁用状态，以便禁用设备。将状态设置为禁用的设备放在. dtsi 文件中会很有用。派生的配置可以包括该内容。.dtsi ，并将所需设备的状态设置为正常。

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:

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

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:

It is interesting to dump the contents of the DTB file to see what the compiler has generated:

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, 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 __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 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 step (i) occurs in the dtoverlay utility, and step (ii) 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 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 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:

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:

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

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:

As it is too time-consuming to document the individual overlays here, please refer to the README file found alongside the overlay .dtbo files in /boot/overlays. It is kept up-to-date with additions and changes.

boot-mode - 32-bit integer

The boot-mode used to load the kernel. See BOOT_ORDER.

partition - 32-bit integer

The partition number used during boot. If a boot.img ramdisk is loaded then this refers to partition that the ramdisk was loaded from rather than the partition number within the ramdisk.

pm_rsts - 32-bit integer

The value of the PM_RSTS register during boot.

tryboot - 32-bit integer

Set to 1 if the tryboot flag was set at boot.

The following properties are specific to BCM2711 SPI EEPROM bootloader.

build_timestamp - 32-bit integer

The UTC build time for the EEPROM bootloader.

capabilities - 32-bit integer

This bit-field describes the features supported by the current bootloader. This may be used to check whether a feature (e.g. USB boot) is supported before enabling it in the bootloader EEPROM config.

update_timestamp - 32-bit integer

The UTC update timestamp set by rpi-eeprom-update.

signed_boot - 32-bit integer

If secure-boot is enabled then this bit-field will be non-zero. The individual bits indicate the current secure-boot configuration.

version - string

The Git version string for the bootloader.

The following properties are defined if the system was booted from USB. These may be used to uniquely identify the USB boot device.

usb-version - 32-bit integer

The USB major protocol version (2 or 3).

route-string - 32-bit integer The USB route-string identifier for the device as defined by the USB 3.0 specification.

root-hub-port-number - 32-bit integer

The root hub port number that the boot device is connected to - possibly via other USB hubs.

lun - 32-bit integer

The Logical Unit Number for the mass-storage device.

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

blconfig

The blconfig alias refers to an NVMEM device that stores a copy of the bootloader EEPROM config file.

blpubkey

The blpubkey alias points to an NVMEM device that stores a copy of the bootloader EEPROM public key (if defined) in binary format. The rpi-bootloader-key-convert utility can be used to convert the data into PEM format for use with OpenSSL.

See also: 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:

a) 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…​

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:

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

Since the switch to the 4.4 kernel and the use of more upstream drivers, Device Tree usage is required in Raspberry Pi Linux kernels. However, for bare metal and other OSs, the method of disabling DT usage is to add:

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.

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 Raspberry Pi 3, 4, 400, Zero W and Zero 2 W, 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.

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.

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

The most important thing to do is ensure you have a very robust password. If your Raspberry Pi is exposed to the internet, the password needs to be very secure. This will help to avoid dictionary attacks or the like.

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 you will need to restart the sshd service using sudo systemctl restart ssh or reboot so the changes take effect.

Key pairs are two cryptographically secure keys. One is private, and one is public. They can be used to authenticate a client to an SSH server (in this case the Raspberry Pi).

The client generates two keys, which are cryptographically linked to each other. The private key should never be released, but the public key can be freely shared. The SSH server takes a copy of the public key, and, when a link is requested, uses this key to send the client a challenge message, which the client will encrypt using the private key. If the server can use the public key to decrypt this message back to the original challenge message, then the identity of the client can be confirmed.

Generating a key pair in Linux is done using the ssh-keygen command on the client; the keys are stored by default in the .ssh folder in the user’s home directory. The private key will be called id_rsa and the associated public key will be called id_rsa.pub. The key will be 2048 bits long: breaking the encryption on a key of that length would take an extremely long time, so it is very secure. You can make longer keys if the situation demands it. Note that you should only do the generation process once: if repeated, it will overwrite any previous generated keys. Anything relying on those old keys will need to be updated to the new keys.

You will be prompted for a passphrase during key generation: this is an extra level of security. For the moment, leave this blank.

The public key now needs to be moved on to the server: see Copy your public key to your Raspberry Pi.

Finally, we need to disable password logins, so that all authentication is done by the key pairs.

There are three lines that need to be changed to no, if they are not set that way already:

Save the file and either restart the ssh system with sudo service ssh reload or reboot.

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.

These are binary blobs (firmware) that are loaded on to the VideoCore GPU in the SoC, which then take over the boot process. start.elf is the basic firmware, start_x.elf also includes camera drivers and codecs, start_db.elf can be used for debugging purposes and start_cd.elf is a cut-down version of the firmware. start_cd.elf removes support for hardware blocks such as cameras, codecs and 3D as well as having initial framebuffer limitations. The cut-down firmware is automatically used when gpu_mem=16 is specified in config.txt.

start4.elf, start4x.elf, start4db.elf and start4cd.elf are equivalent firmware files specific to the Raspberry Pi 4-series (Model 4B, Pi 400, Compute Module 4 and Compute Module 4S).

More information on how to use these files can be found in the config.txt section.

These are linker files and are matched pairs with the start*.elf files listed in the previous section.

The kernel command line passed in to the kernel when it boots.

Contains many configuration parameters for setting up the Raspberry Pi. See the config.txt section.

Some text-based housekeeping information containing the date and git commit ID of the distribution.

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.

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.

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 Raspberry Pi model is detected.

The boot folder will contain various kernel image files, used for the different Raspberry Pi models: