I2C, SPI, I2S, LIRC, PPS, stopped working? Read this. #piday #raspberrypi @Raspberry_Pi


Some useful tips for troubleshooting your pi from PhilE in the Raspberry Pi Forums.

The most recent Raspbian release, with Pi 2 support, switches to a new kernel (3.18), and includes a configuration change to enable Device Tree support by default. This has caused some previously working things to mysteriously stop working, but with a few configuration changes normal service should be resumed. I’ll tell you how to do that in a moment, but first a short history lesson. Skip forward to “TL;DR: Yeah, yeah, but how do I fix it?” if you don’t care.

In the early days of Linux it was distributed in source form, or as a bare-bones, generic kernel along with the source to build a better one. One of the steps in the installation process was configuring the kernel to your requirements, followed by the compilation phase. This was time consuming and potentially overwhelming for new users.

The Holy Grail of Linux Distributions is a platform-specific (ideally OS-neutral) loader (U-boot, GRUB etc.), a generic kernel (one per processor architecture) and a collection of loadable modules. Since not all hardware sits on discoverable (plug-and-play) buses like PCI and USB, what is missing from this picture is a mechanism to describe the rest of the hardware; Device Tree is that mechanism.

Device Tree (DT) is the recommended way to describe hardware on Linux platforms (although it is actually OS-independent). It is a hierarchical structure consisting of nodes, sub-nodes and properties. It is not unlike XML in some respects, but thankfully it is more readable, less verbose, and comes with a standard binary representation – Flattened Device Tree (FDT) – that is easy for programmes to parse and manipulate. Desktop processor platforms made the switch to DT years ago, and after years in the wilderness the ARM SoC platforms are catching up.

So DT is officially a “Thing”, but why should Raspberry Pi use it? The change is primarily a practical one. Until now, supporting some peripheral cards has required the addition of “struct platform_device” objects to the board support code. These are usually conditionally compiled based on the kernel configuration options, but in order to prevent regular users from having to compile their own kernel these options are turned on in the standard builds. As a result, at boot time many (typically unwanted) modules are loaded unless they added to the blacklist (which prevents the automatic loading but still allows subsequent manual loading). Insufficient blacklisting could lead to nasty contention for GPIO pins, usually experienced after a kernel update since the blacklist file (/etc/modprobe.d/raspi-blacklist.conf) isn’t a part of the kernel and hence doesn’t automatically get updated.

Device Tree turns this system on its head, by replacing those “struct platform_device”s with nodes in the DT, allowing users to control which devices are enabled and hence which modules get loaded. Adding a new device driver module to the kernel doesn’t automatically result in a module being loaded – the appropriate nodes must also be added to the DT.

TL;DR: Yeah, yeah, but how do I fix it?

If you are really impatient and just want out, or if for some reason your bit of hardware doesn’t yet have a suitable overlay, add “device_tree=” to your config.txt and reboot. But be aware that this option may not be supported indefinitely.

Writing Device Trees is hard, particularly if you’ve never encountered one before. It shouldn’t be necessary to write (or even edit) one in order to use commercial hardware. So the Raspberry Pi loader (start.elf, and its siblings) can combine a base DT Blob (DTB) with a number of overlays, each of which can be customised with a number of parameters. This is all controlled from /boot/config.txt.

The mechanism is described in a new README file (/boot/overlays/README – you may need to update your firmware). For convenience I’ll post the current version in a reply to this. Full documentation can be found here: http://www.raspberrypi.org/documentation/configuration/device-tree.md

Check out the full FAQ section here.

998Each Friday is PiDay here at Adafruit! Be sure to check out our posts, tutorials and new Raspberry Pi related products. Adafruit has the largest and best selection of Raspberry Pi accessories and all the code & tutorials to get you up and running in no time!

Make a robot friend with Adafruit’s CRICKIT – A Creative Robotics & Interactive Construction Kit. It’s an add-on to our popular Circuit Playground Express, FEATHER and other platforms to make and program robots with CircuitPython, MakeCode, and Arduino. Start controlling motors, servos, solenoids. You also get signal pins, capacitive touch sensors, a NeoPixel driver and amplified speaker output. It complements & extends your boards so you can still use all the goodies on the microcontroller, now you have a robotics playground as well.

Join 7,500+ makers on Adafruit’s Discord channels and be part of the community! http://adafru.it/discord

CircuitPython in 2018 – Python on Microcontrollers is here!

Have an amazing project to share? Join the SHOW-AND-TELL every Wednesday night at 7:30pm ET on Google+ Hangouts.

Join us every Wednesday night at 8pm ET for Ask an Engineer!

Follow Adafruit on Instagram for top secret new products, behinds the scenes and more https://www.instagram.com/adafruit/

Maker Business — Despite multiple bankruptcies, RadioShack continues to find ways to keep the lights on

Wearables — Molding with glue

Electronics — A few words on inductor resistance

Biohacking — Running Blades

Python for Microcontrollers — Help bring CircuitPython to other languages!

Get the only spam-free daily newsletter about wearables, running a "maker business", electronic tips and more! Subscribe at AdafruitDaily.com !

No Comments

No comments yet.

Sorry, the comment form is closed at this time.