• Devices
  • SPI Devices
  • SPI
  • I2C
  • UART
• USB and Ethernet

See this page for a device tree overview describing how device trees are used with Rasbperry Pi, including modifications to config.txt.

If you are having trouble with device detection, you may want to try adding the dtc utility to your image for troubleshooting purposes, then using command

dtc -I fs -O dts /sys/firmware/devicetree/base

on a running system to obtain information about the current devicetree.

The compatible field can be used to figure out which driver is associated with the hardware you want to use. Searching the linux kernel source for this string will show you which driver references it in their match function. You can find a nice tutorial about this at this link.

Changes to config.txt can be performed either by accessing the first partition of the sdcard from another system, or you can mount the partition on a running system like this:

mkdir -p /tmp/mnt/p1
mount /dev/mmcblk0p1 /tmp/mnt/p1

You'll need to reboot after changing config.txt.

You should ultimately deploy config.txt changes with your buildroot project source code through a custom config.txt file

Recent builds of buildroot (2022.02.x and later, after this commit) allow you to customize the location and content of your config.txt file. Previous builds used a customization of post build script to customize which was modified for the reasons described in the commit linked above.

To customize a config.txt for your platform at image build time:

1. Copy the buildroot/board/raspberrypi/config_X.txt from the buildroot directory corresponding to the buildroot branch you are building into your base_external directory in a path such as base_external/configs/, where X corresponds to the specific buildroot platform you are targeting (for instance config_3.txt for raspberry pi 3.) You can find the default config.txt file for your default target by examining the setting for BR2_PACKAGE_RPI_FIRMWARE_CONFIG_FILE in the associated defconfig file at buildroot/configs (see the name matching your hardware plkatform).
2. Make a commit with the configuration unmodified in your base_external path so you can easily track the changes you make to this file.
3. Make modifications to the config.txt file in your base_external path to support the hardware you are configuring and commit with a descriptive message describing the change.
4. Use make menuconfig in the buildroot subdirectory to set BR2_PACKAGE_RPI_FIRMWARE_CONFIG_FILE to the full path to your configuration file in your base_external path.
5. Ideally perform a clean build to apply the changes. You may also be able to make rpi-firmware-rebuild to apply only the config.txt changes.

Look in 'buildroot/output/images/rpi-firmware/config.txt' to ensure your changes are applied there.

When changing buildroot branches, the content of the default config.txt file may change, requiring you to re-apply your changes.

You must kick off a clean build to setup initial configuration changes. See https://github.com/cu-ecen-aeld/buildroot-assignments-base/wiki/Raspberry-Pi-Hardware-Support#configuration-changes-and-buildroot-builds for the procedure to re-build after changing the buildroot branch.

Then, to re-apply your changes to the config.txt file on a new branch, If you've made modifications in the method described above, you may simply:

1. Copy the updated config.txt from the buildroot repository to your base_external directory, and make a commit with the default content of the file.
2. Re-apply your modification commit from step 3 above using git cherry-pick <commit hash corresponding to your config.txt file change> and fix any merge issues.

Use a similar mechanism to the one described above for modifying the cmdline.txt to modify the kernel boot command line for Raspberry Pi when necessary. The corresponding configuration is BR2_PACKAGE_RPI_FIRMWARE_CMDLINE_FILE and the base command line may be found in the board/raspberrypi/cmdline.txt file in the buildroot repository.

This section was last tested on Buildroot release 2019.05

You need to enable SPI in the device overlay by adding this line to config.txt using the instructions above:

dtparam=spi=on

and reboot.

After completing this step you should notice that your device tree shown with dtc looks like this:

                spi@7e204000 {
                        compatible = "brcm,bcm2835-spi";
                        clocks = < 0x08 0x14 >;
                        status = "okay";

instead of this:

                spi@7e204000 {
                        compatible = "brcm,bcm2835-spi";
                        clocks = < 0x08 0x14 >;
                        status = "disabled";

You then must load the associated drivers for the SPI controller and SPI devices:

                spi@7e204000 {
                        compatible = "brcm,bcm2835-spi";
...
                        spidev@1 {
                                compatible = "spidev";

which can be done with:

modprobe spi_bcm2835
modprobe spidev

where the "brcm,bcm2835-spi" string matches the spi_bcm2835 driver. You should make module loading automatic as a part of your custom software startup scripts.

Include dtparam=spi=on in your config.txt using the instructions above:

• In addition to the above modifications, some additional packages needs to be added for SPI:
• Move into Target Packges -> Hardware Handling -> then enable spi-tools
• Move into Target Packges -> Debugging, Profiling and Benchmark -> then enable spidev_test

Run save_config.sh to save the changes made above in base_external/configs/aesd_rpi_defconfig.
Verify the above changes by checking the file aesd_rpi_defconfig in base_external/configs folder.
It should have the fields as shown in the image below in addition to BR2_PACKAGE_SPI_TOOLS=y and BR2_PACKAGE_SPIDEV_TEST=y:

Making the above changes and then running build.sh will change the file at /output/images/rpi-firmware/config.txt to include dtparam=spi=on
Verify the change in this file after running build.sh, this will make sure that SPI driver is included in /dev.

After successful build, flash sdcard.img found at buildroot/output/images and insert into the RPI.
On the console enter:

modprobe spi-bcm2835  
modprobe spidev  

to insert the modules. Other way round would be to create a startup script to insert the required modules at boot up.

Include dtparam=i2c_arm=on in your config.txt using the instructions above:

• In addition to the above modifications, some additional packages needs to be added for I2C:
• Move into Target Packges -> then enable Show packages that are also provided by busybox
• Move into Target Packges -> Hardware Handling -> then enable i2c-tools

Run save_config.sh to save the changes made above in base_external/configs/aesd_rpi_defconfig.
Your config file should also include BR2_PACKAGE_BUSYBOX_SHOW_OTHERS=y and BR2_PACKAGE_I2C_TOOLS=y:
After successful build, flash sdcard.img found at buildroot/output/images and insert into the RPI.
On the console enter:

modprobe i2c-bcm2835  
modprobe i2c-dev  

to insert the modules. Other way round would be to create a startup script to insert the required modules at boot up.

See wiki page here for an overview on i2c troubleshooting steps.

See wiki page here for implementation guidance when using Python.

• Bluetooth complicates the serial port use on Raspberry Pi. By default, when Bluetooth is enabled the primary port is UART1 which is disabled by default so to enable it we assert enable_uart=1 in config.txt. However, enabling UART1 has a disadvantage that is it causes the Pi to draw a lot more current.

• So to enable UART0 and use Bluetooth we assert dtoverlay=pi3-miniuart-bt and enable_uart=1 in config.txt using the instructions above. Reboot the pi and run the loopback test code, UART0 should now work successfully.

On some Raspberry Pi hardware (including Raspberry Pi 3B+), USB and Ethernet use a shared controller. This is important because it means that USB won't work if Ethernet is disabled at boot.

Normally on an RPi with Ethernet, /etc/network/interfaces would have an entry for enabling eth0 by default. If this interface is not needed, it could be beneficial to disable eth0 to improve boot time. However, because it shares the controller with USB, removing eth0 from interfaces causes USB to not work on boot. As an alternative, leaving eth0 enabled but with a static IP address is a good alternative; it still brings up the device, but does not wait for link/dhcp. An example is below.

auto eth0
iface eth0 inet static
  address 192.168.51.2
  netmask 255.255.255.0
  network 192.168.51.0
  broadcast 192.168.51.255
  gateway 192.168.51.1
  wait-delay 5