Inhaltsverzeichnis
The Raspberry Pi features a Broadcom BCM2835 .
The SoC is not Open Hardware.
Broadcom VideoCore IV
An open-source graphics driver is available though.
The Video Core still requires a proprietary firmware, however Broadcom released specifications, so a FOSS firmware could still be made.
OMXPlayer is a small and simple video player for the Raspberry Pi.
It does support and use Broadcom's OpenMAX libraries out-of-the-box.
Read more:
apt-get install omxplayer
if needed:
ln -s /usr/lib/arm-linux-gnueabi/libpcre.so /usr/lib/omxplayer/libpcre.so.1
omxplayer big_buck_bunny_480p_h264.mov
worked for me, plays the video very nicely on top of the console (to framebuffer?)
last time I tried, I wouldn't play a http video stream, apparently this does work in the recent version
As the player is quite small and simple, you might feel an urge to add features. You may do so by compiling a personalized version:
apt-get install git fbset libpcre3-dev libboost-dev
get the source code
git clone :huceke/omxplayer.git
after two fixes, compiles on Raspberry Pi
gstreamer-1.0 features gst-omx, a module which can do hardware-accelerated video decoding on the Raspberry Pi.
An experimental version of gst-omx for gstreamer-0.10 is available too,
but last time I tried, I didn't get it to work.
gst-omx is not included in the main Raspbian package repository (neither is gstreamer-1.0).
So, you either need to compile it from source or download vontaene.de's precompiled version.
gstreamer-1.0 ...
apt-get install autoconf automake libtool gtk-doc-tools libglib2.0-dev
cd gst-omx
./autogen.sh
I attempted to compile gstreamer-1.0 with gst-omx (),
however the resulting ,
resulting in lags and poor video quality. Please comment on GitHub, if you experience or don't experience this problem anymore.
add the following line to /etc/apt/sources.list
apt-get update
apt-get install libgstreamer1.0-0-dbg gstreamer1.0-tools libgstreamer-plugins-base1.0-0 \
gstreamer1.0-plugins-good gstreamer1.0-plugins-bad-dbg gstreamer1.0-omx gstreamer1.0-alsa
gst-launch-1.0 playbin uri=big_buck_bunny.avi
seed video using:
cvlc v4l2:///dev/video1:chroma=h264:width=800 --sout '#rtp{sdp=rtsp://:8080/stream.sdp}' -vv
play back video without audio:
gst-launch-1.0 rtspsrc location=rtsp://192.168.2.112:8080/stream.sdp ! rtph264depay ! h264parse ! omxh264dec ! autovideosink
Might also be interesting for H.264 fans: , which allows handling webcam encoded H.264 video streams
some example gstreamer commands:Changing the default pin configuration - Raspberry Pi Documentation
& pin-configuration
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.
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-get 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:
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:
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_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.
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.
pin@pinname
This section can contain any combination of the following items:
active_high
active_low
termination
no_pulling
startup_state
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.
are valid values.
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 {
freq = &&; };
chan@APER {
clock@GPCLK0 { pll = "PLLA"; chan = "APER"; };
clock_setup {
clock@PWM { freq = &2400000&; };
clock@GPCLK0 { freq = &&; };
clock@GPCLK1 { freq = &&; };
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 Hz 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.1. Configuration Hacks - Raspberry Pi Hacks [Book]
Stay ahead with the world's most comprehensive technology and business learning platform.
With Safari, you learn the way you learn best. Get unlimited access to videos, live online training,
learning paths, books, tutorials, and more.
No credit card required
Chapter 1. Configuration HacksThey say the beginning is usually a good place to start anything, but this is a Hacks book. You’re likely to skip around to things with interesting titles, or perhaps the one that starts in Old English because you were flipping through the pages and it looked like the book had some terrible printing errors.That said, there are some things that it’s nice to keep in the back of your head before you start building things, and the Raspberry Pi has a few unexpected quirks that it’s good to be aware of. If you’re entirely new to Linux, electronics hacking, or both, it’s a good idea to give this chapter a read-through before proceeding with any of the other hacks. You just might learn something that will save your Pi (and the $35 of having to replace it).Hack 1. Choose and Format the Right SD CardThe Raspberry Pi does not have any built- it needs an SD card to do anything. Picking the right one might seem simple, but we’re here to help you make the right choice.Your SD card choice is an important one. After all, when it comes to the Raspberry Pi, it’s the equivalent of choosing a hard drive. Being able to change the entire system quickly by inserting a new SD card is also one of the Pi’s most interesting strengths, especially when it comes to education. A few factors should weigh into your card selection, though, and even if you think you’ve chosen well, you might still need to troubleshoot minor problems.SD cards are sold with a class number (e.g., 4, 6, 10), in which a higher class number equates to a faster card. Most high-quality, Class-4-or-greater SDHC cards (i.e., a recognized name brand) should work for most purposes. Vendors that sell cards with a Linux distribution meant for the Raspberry Pi largely use SanDisk or Kingston brand SDHC Class 4 cards. You can find a thorough list of known, tested cards (as well as cards that don’t work) at . That said, a faster card can as much as double your transfer rate (in terms of MB/sec), so if speed is critical to your use, you should go with a higher class card.Class 10 Too Classy?The early Raspberry Pi firmware and bootloader didn’t like Class 10 SD cards. This problem is supposed to have been fixed, but you’ll still see people occasionally running into problems with Class 10 cards, so just be aware that it’s a potential issue. If you have your heart set on a Class 10 card and the first one doesn’t work, try a different brand. In addition, overclocking has been found to cause errors with Class 6 and Class 10 SD cards, regardless of size or brand, and the errors might not appear for a few days or weeks. Keep this in mind if you plan to overclock your Pi.If decision making isn’t your strong suit, you can also keep multiple cards around, each with a different purpose, for a single Raspberry Pi. If you’d like easy peace of mind, several vendors sell SD cards preloaded with Linux distributions for the Raspberry Pi, including a card containing NOOBS (New Out-Of-Box Software), which has several distro options on it. RS Components and element14 offer a card preloaded with NOOBS as an add-on when you purchase a Raspberry Pi.NOOBSNOOBS was designed to make setting up a Raspberry Pi super easy. It supports multiple OS installations and re-installations, as well as config file editing and web browsing (to research answers to boot problems) in a pre-boot environment. After all, this thing was designed for education, and you’re not going to learn much if you can’t even get started. It fits on a 4 GB card and gives you multiple choices about which distro you’d like to set up. After you’ve chosen, you can always return to the menu and make a different selection by holding down Shift during boot, either to try something new or to get a mulligan on a corrupted card. If you don’t buy it on a preloaded card, you can download it from .If you used one of the SD cards that’s known to work and you’re still having problems, you should check a few other things. Be sure that you’ve updated the firmware on the Pi (see ). If it was not a new SD card, be sure you fully formatted it first, and make sure you do so for the whole card and not just a partition.First, find the card’s device name:$ su -c 'fdisk -ls'or:$ df -hYou’re looking for something like /dev/sdd or /dev/mmcblk0 with the size of your SD card. To format, run the mkdosfs command, replacing /dev/mmcblk0 with the location of your card:$ mkdosfs -I -F32 /dev/mmcblk0This will make a single FAT formatted partition on the SD card. To be honest, it really doesn’t matter very much how you format or partition the SD card in most cases, because when installing any of the system images for Raspberry Pi OS distributions that include partitions (such as Pidora or Raspbian), the partition table on the SD card will be completely overwritten by the installed OS image. The exception to that is NOOBS. By partitioning the disk with a single FAT partition, it is possible to install NOOBS to the SD card by simply copying the NOOBS files directly onto the SD card.If you find that you have, say, an 8 GB card, and your computer thinks it’s only 2 GB, you need to “grow” it to match. Or you might have found that your card’s device name ends in p1 (followed by p2 and so forth):/dev/mmcblk0p2
97% /run/media/wwatson/rootfs
/dev/mmcblk0p1
35% /run/media/wwatson/bootThis means your card is partitioned, and you should get down to one partition before formatting. Adjusting partitions and their sizes is most easily accomplished with a GUI tool called , a visual version of the command-line parted.Hack 2. Mount the SD CardWhile you can certainly access the files on the Raspberry Pi directly from within a running instance, mounting the SD card on a separate computer with an SD card reader makes many tasks (such as adding or editing files) easier.The Raspberry Pi is a standalone Linux computer, but it really helps to have another computer on hand. In some cases, it might even be necessary. Fortunately, many computers now come with SD card readers built in, and if yours didn’t, they’re inexpensive and easy to come by. So, even if you buy your SD cards preloaded, you should probably still have an SD card reader and a second computer for interacting with your Raspberry Pi build.Most Linux distributions for the Raspberry Pi create at least two partitions on the SD card. The first partition is always /boot, because the Raspberry Pi GPU reads its firmware from the beginning of the SD card. The second partition is usually / (also known as the root partition).Pidora labels the partitions on the SD card boot and root, but Raspbian does not use disk labels, so it is especially important to note the device names for that distribution.Modern Linux distributions (on your separate computer), such as Fedora or Ubuntu, will auto-mount the partitions on the SD card when it is inserted and provide some sort of notification of this event. However, if you’re not sure, running the mount command should list all mounted partitions on the system. You are looking for something like /dev/mmcblk0p1, which means the first partition (p1) on the MMC block (mmcblk) device:[spot@wolverine ~]$ mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
/dev/sda3 on / type ext4 (rw,relatime,data=ordered)
/dev/sda1 on /boot type ext4 (rw,relatime,data=ordered)
/dev/mmcblk0p1 on /run/media/spot/boot type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
/dev/mmcblk0p2 on /run/media/spot/rootfs type ext4 (rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2)The last two lines in the output identify the MMC block device partitions mounted in /run/media/spot/boot and /run/media/spot/rootfs, respectively.Linux uses the term MMC to describe the driver for both MultiMediaCard and Secure Digital (SD) formats.If your SD card is not mounted automatically, make sure it’s inserted and look at the output from the dmesg command. You do not need to pass any options to dmesg (although piping it through less is always a good idea). When you run it, it will print out quite a bit of stuff, but the output is in order from the last time you have booted your Linux system.You’ll want to look at the end of the output. Specifically, you look toward the end of the output to figure out the name of the MMC block device.
shows an example of the sort of messages you are looking for.Figure 1-1. Output from dmesg on Fedora 19, with the MMC block device messages highlightedIn , the MMC block device name is mmcblk0, and it has two partitions, p0 and p1. This gives you enough information to determine the Linux device names for these partitions: /dev/mmcblk0p0 and /dev/mmcblk0p1. You can confirm these are the correct device names by running:brw-rw---- 1 root disk 179, 1 Aug 20 20:42 /dev/mmcblk0p1
brw-rw---- 1 root disk 179, 2 Aug 20 20:42 /dev/mmcblk0p2If they exist, they’re probably the ones you want (unless you have multiple SD cards inserted into your system somehow).SD card readers connected via SPI interfaces are generally designated /dev/mmc*, but SD card readers connected via USB are designated /dev/sd* (and some laptops’ internal SD card readers are connected via USB). Be careful when accessing a /dev/sd* device, as it’s then much easier to accidentally specify a hard disk drive instead.Once you’ve identified the Linux device names for the MMC block device partitions on your system, you should be able to manually mount them by creating two mount point directories (as root):$ su -c 'mkdir /mnt/raspi-boot'
$ su -c 'mkdir /mnt/raspi-root'These directories will serve as anchors for mounting the partitions from the MMC block device.Then, use the mount command to mount the boot and root partitions:$ su -c 'mount /dev/mmcblk0p1 /mnt/raspi-boot'
$ su -c 'mount /dev/mmcblk0p2 /mnt/raspi-root'If these mount commands return without errors, it means they have mounted successfully. You can confirm they have mounted by running mount again and piping the output through a grep for the MMC block device name (mmcblk0):$ mount | grep mmcblk0
/dev/mmcblk0p1 on /mnt/raspi-boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
/dev/mmcblk0p2 on /mnt/raspi-root type ext4 (rw,relatime,data=ordered)You should also now be able to see files in the /mnt/raspi-boot and /mnt/raspi-root directories.It is also possible to mount the /boot partition inside the mounted / partition, but we recommend keeping them separate. That way, if you forget to mount the boot partition, it is more obvious, and you avoid the problem of accidentally copying files into the /boot directory on the root partition. Remember, Linux mounts the boot partition on top of that /boot directory, and any files that get copied into that directory when the boot partition is not mounted are not visible!Mounting the SD card is especially useful to make quick changes to the config.txt file that lives in the Raspberry Pi Linux /boot partition. If you need to change the ouput display settings for a new monitor (or an old HDMI TV with less than amusing quirks), it’s a lot easier to do it from a mounted SD card than from a headless Raspberry Pi.Just make sure the boot partition is mounted, and then change into that directory (/mnt/raspi-boot) and directly edit config.txt (as root). Save your changes, and then run sync to make sure the buffers get written back to the SD card.When that finishes, change out of the directory (if you do not, Linux will not let you cleanly unmount the partition) and unmount both of the partitions (as root) with the umount command:$ cd /mnt/raspi-boot/
$ su -c 'vi config.txt'
$ su -c 'umount /mnt/raspi-boot'
$ su -c 'umount /mnt/raspi-root'If the umount commands both return without any errors, it is now safe to remove your SD card. Just put it back in your Raspberry Pi, power it on, and hope for the best.Hack 3. Decode the LEDsEach Raspberry Pi has a set of LEDs in one corner that give you clues about what’s happening (or not happening!) with the device. The Model A had only two lights, but the Model B offers a lot more insight and valuable troubleshooting information.The Raspberry Pi Model B has five status LEDs (shown in
and described in ) that will help you troubleshoot problems when it won’t boot or other problems arise. Since the Pi has no BIOS, the screen won’t show you anything at all until the Pi successfully boots. That’s where these little lights come in handy.Figure 1-2. Model B LEDsTable 1-1. Status LEDs on the Raspberry Pi Model BNumberLabelColorFunctionD5OK (Rev 1.0) ACT (Rev 2.0)GreenSD card access, connected to GPIO 16D6PWRRed3.3 V Power, connected to 3.3 VD7FDXGreenFull Duplex LAND8LNKGreenLink/Activity LAND910M (Rev 1.0) 100 (Rev 2.0)Yellow10/100Mbit LANThe first two lights (D5 and D6) are the most important pair when you want to make sure that your problem isn’t as simple as “it’s not plugged in.”
describes the most common indicators you’ll see on these lights.Table 1-2. Common LED Error CodesLight indicationMost likely problemRed PWR light offNo powerRed PWR light on, green OK light offThe Pi can’t read the image on the card. The voltage is below 5V.Green OK light blinks 3 times*start.elf was not foundGreen OK light blinks 4 times*start.elf did not launchGreen OK light blinks 7 times*kernel.img was not foundNote that the flash patterns identified with an asterisk in
are accurate for the firmware available since October 20, 2012. Earlier firmware used different patterns, and later firmware may change these indicators as well.The two files it’s looking for, start.elf and kernel.img, absolutely must be on the boot partition. The first, start.elf, is the GPU binary firmware image, and kernel.img, as its name implies, is the Linux kernel. If the red PWR light is on,
then it’s up to the green light to tell you what’s gone wrong.If the green light doesn’t flash at all, the first thing you shuld do is check your SD card in another computer. Make sure that the image is written correctly. If all of the filenames look like somebody leaned on the keyboard, it did not write correctly! Format it and start again. If it does look OK, plug in nothing but the power and the SD card, then each of your other peripherals one at a time to see which is causing the problem.If the green light does blink, refer to
for information about what has gone wrong. Note that once start.elf has loaded, you’ll see “the rainbow” (four large squares of color bleeding together). It should quickly go away as your Linux distro continues to boot, but if it doesn’t, your problem is in the kernel.img file.Blink Your IP Address Through the LEDsPidora offers some features specifically for running in headless mode, including the use of the LEDs to communicate your IP address. See
to learn how. The firmware your Raspberry Pi requires comes with any Linux distribution you choose, but it’s frequently updated upstream, and your project might benefit from (or require) a more recent version.The Raspberry Pi is a little different from your laptop, and even different from a lot of traditional embedded computers. The heart of the Raspberry Pi is the Broadcom BCM2835 system-on-chip, which is the CPU, GPU, and memory all combined in a single component. This detail is important, because the Raspberry Pi actually boots from the BCM2835 GPU. When you provide power to the Raspberry Pi, the CPU in the BCM2835 system-on-chip is actually disabled! The Raspberry Pi boots like this:
First-stage bootloader: A bootloader programmed into the BCM2835 system-on-chip hardware mounts the FAT32 boot partition from the Linux distribution on the SD card. Note that this first-stage bootloader is programmed at manufacture time and is not modifiable or replaceable. A small, dedicated RISC core on the Raspberry Pi GPU starts this process.
Second-stage bootloader: Read off the boot partition on the SD card, this firmware (bootcode.bin) accesses the additional GPU firmware files, programs those firmware files into the Raspberry Pi GPU, and then starts it.
GPU firmware: This firmware (start.elf) allows the GPU to enable the CPU. An additional file, fixup.dat, configures the SDRAM partition between the GPU and the CPU. At this point, the CPU is released, and execution is transferred to it from the GPU.
User code: The CPU boots any supported binary, but the Linux kernel is the default. It assumes the filename is kernel.img, but you can be override the default in config.txt.
Versions of the Raspberry Pi firmware prior to October 19, 2012 contained an additional third-stage bootloader (loader.bin), but this is no longer required or used. Previous builds also had different versions of the GPU firmware that had to be swapped in and out to enable different memory splits between the ARM CPU and GPU, but this is now configured in config.txt.Because of how the Raspberry Pi boots, you must use an SD card to boot the Raspberry Pi; you cannot boot it from any other device (such as network or USB storage) alone. But this is a good thing. It prevents you from rendering the device unusable, because you cannot override the first-stage bootloader. If you end up with damaged, broken, or incomplete firmware, you can simply start over with a clean SD card.The Raspberry Pi Foundation provides the firmware files that the GPU loads, which then enable the Raspberry Pi to boot a specially formatted Linux kernel image. All the Linux distribution images intended for use on the Raspberry Pi come with a copy of this firmware, but it is constantly updated upstream. To enable new functionality (or boot newer Linux kernels), you will want to make sure you are running the latest revision of the firmware.The upstream home for the Raspberry Pi firmware is . There is currently no source code available for these firmware files, so this repository contains only binary versions. Because the Raspberry Pi is so slow (especially for Git operations), we strongly recommend that you check out these files to your x86 laptop.First, you need to make sure you have a Git client installed by running the following command on Fedora:$ yum install gitor this command on Debian/Ubuntu:$ apt-get install git-coreNext, create a working directory for Raspberry Pi related files, such as ~/raspi:
$ mkdir ~/raspiGo into the raspi directory:
$ cd ~/raspiUse Git to get a local copy of the firmware files:
$ git clone https://github.com/raspberrypi/firmware.gitThis will create a checkout in a new directory, named firmware. By default, this checks out the master branch, which at the time of this writing was synced up to the version of the firmware currently used by the Raspbian Linux kernel (3.2). If you are using a 3.2 kernel, this is the firmware you want to use. Another branch (named next) enables the updated drivers in the 3.6 Linux kernel. If you want to use this branch, change into the firmware directory and enter:
$ git checkout nextTo switch back to the master branch, enter:
$ git checkout masterIf you want to update your firmware again later, you don’t need to check out this tree again. Simply go to the top-level checkout directory (~/raspi/firmware) and enter:
$ git pullRemember, this will pull changes for the current branch only. If you want to pull changes for the other branch, you will need to switch to the other branch with the Git checkout command and run git pull there as well.Now that you have checked out the repository and chosen your branch, your next step is to copy the boot firmware onto the SD card that has the Raspberry Pi Linux distribution image. To do this, you’ll need to make sure the partitions on that SD card are properly mounted (covered in detail in ).From here on, we will assume that the boot partition from your SD card with the Raspberry Pi Linux distribution image is mounted at /mnt/raspbi-boot. Current versions of Fedora (including Pidora) will automount it to /run/media/$USERNAME/boot, where $USERNAME is your username, so if you have it mounted somewhere else, substitute that mount point in the next set of instructions.To update the firmware on the boot partition, all you need to do is copy the right files from the firmware/boot directory into the mounted boot partition (as root).You probably do not want to copy all of the files from this directory.You’re looking for these critical firmware files in the firmware/boot directory:
bootcode.bin
We strongly recommend that you back up the existing (and presumably) working copies of these files at this point. You can accomplish this by renaming these files (as root) in the mounted boot partition first:$ su -c 'mv /mnt/raspi-boot/bootcode.bin /mnt/raspi-boot/bootcode.bin.backup'
$ su -c 'mv /mnt/raspi-boot/fixup.dat /mnt/raspi-boot/fixup.dat.backup'
$ su -c 'mv /mnt/raspi-boot/start.elf /mnt/raspi-boot/start.elf.backup'Copy each of these firmware files (as root) into the mounted boot partition:$ cd ~/raspi/firmware/boot/
$ su -c 'cp -a bootcode.bin fixup.dat start.elf /mnt/raspi-boot/'The command example used here for copying firmware files (along with most other command examples in this book) use su. The su command will prompt you for the root password of your Linux laptop. If you have configured sudo for use on your Linux laptop, you can replace the su -c command with sudo and the command to copy the firmware files (as root) will look like this instead:$ sudo cp -a bootcode.bin fixup.dat start.elf /mnt/raspi-boot/Whichever method you prefer is fine, as they are both valid methods for Linux operations as the root user. We use the su -c syntax in most examples throughout the book for all root operations because it will work in all cases, whereas sudo works only if it is configured for your user on that Linux distribution. If you an encounter instructions prefaced with sudo, know that su is an option when you don’t have sudo configured.When the new Raspberry Pi firmware finishes copying onto the boot partition, run the sync command to ensure the data has all arrived onto the SD card:
$ syncThen it should be safe to unmount the SD card partition(s) and eject the SD card. You can unmount these partitions from the GUI interface of your Linux laptop, or you can manually unmount them from the terminal by changing into a directory that is not in either of the mounted partitions and then enter:
$ su -c 'umount /mnt/raspi-boot'
$ su -c 'umount /mnt/raspi-root'At this point, the SD card will contain the new firmware. You’ll know that the update worked if the Raspberry Pi still boots into the Linux image, but at a minimum, the firmware will draw a multicolored “rainbow” box (see
sidebar) to the configured output device (usually an HDMI connected one) as its first step in the boot process (unless you have explicitly disabled this behavior in config.txt). If that occurs, the firmware is properly installed onto the SD card.Hopefully, if everything goes well with your Raspberry Pi, you’ll never have to see the “rainbow” screen (shown in ) for more than a fraction of a second when it boots up. The screen is generated by the Raspberry Pi firmware as it initializes the GPU component of the BCM2835 system-on-chip.To test that the output works successfully, the GPU draws four pixels on the screen and then scales those pixels to be very large, resulting in the multicolor screen. If your Raspberry Pi ever refuses to go over the rainbow and into a proper Linux boot, it means that the configured Linux kernel image (default: kernel.img) was not able to boot.Figure 1-3. The “rainbow” screen (uploaded to
by user Popcornmix and shared under the terms of the Creative Commons Attribution-ShareAlike 3.0 Unported License)Some optional versions exist for some of the Raspberry Pi firmware files. It is possible to configure the Raspberry Pi to dedicate the minimum amount of memory to the GPU (16 MB). When this is done, the Raspberry Pi Second Stage Bootloader looks for start_cd.elf and fixup_cd.dat instead of start.elf and fixup.dat.
provides a longer discussion on GPU/CPU memory splitting.Hack 5. Monitor the Raspberry Pi HardwareWorried that your Pi is throwing wild parties while you’re out of the house? Here’s how to point a webcam at it and stream the video to the Internet. Just kidding! These tools can monitor the physical state of your tiny hardware.A “normal” Linux computer would likely include onboard health monitoring sensors. Quite a few monitoring chips and components are used in various systems, but on the Raspberry Pi, all of that hardware is entirely hidden inside the Broadcom system-on-chip, so you can’t access it with those usual methods.To reach those components to monitor your Pi’s health, you need to use the vcgencmd utility. It should be preinstalled with any of the general-purpose Raspberry Pi Linux distributions available, but if it’s not, you can get a copy from the firmware tree at . If your distribution is compiled for ARM hardware floating point, look in the hardfp/ otherwise, look in the opt/ subdirectory.At the time of this writing, most Linux distributions (including Pidora, Raspbian, Occidentalis, OpenELEC, and RaspBMC) are built for the ARMv6 hard-float architecture, because that gives the best possible performance on the Raspberry Pi. However, some older releases of these targets (and other OS platforms) were built with optimization for ARMv6 soft-float. These two optimization levels are not compatible with each other. On Linux, there is a good way to check for support for ARMv6 hard-float, using the readelf command:$ readelf -a /usr/lib/libc.so.6
| grep FPYou can run this command directly on the Raspberry Pi Linux distribution
(you might need to install the elfutils package first), or you can copy
a binary or library from within the Raspberry Pi Linux distribution and
onto another system with readelf handy.If the binary has support for ARMv6 hard-float optimization, you will
get output that looks like this:
Tag_FP_arch: VFPv2
Tag_ABI_FP_rounding: Needed
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_HardFP_use: SP and DP
Tag_ABI_VFP_args: VFP registersThe important line is the last one, Tag_ABI_VFP_args: VFP registers.
It will show up only if the binary being checked is built with ARMv6
hard-float optimization.Once you’ve installed it (if necessary), look at the options that vcgencmd offers:
$ vcgencmd commandsThis will output a list of all the commands that you can pass to the vcgencmd tool:
commands="vcos, ap_output_control, ap_output_post_processing, vchi_test_init, vchi_test_exit, pm_set_policy, pm_get_status, pm_show_stats, pm_start_logging, pm_stop_logging, version, commands, set_vll_dir, led_control, set_backlight, set_logging, get_lcd_info, set_bus_arbiter_mode, cache_flush, otp_dump, codec_enabled, get_camera, get_mem, measure_clock, measure_volts, measure_temp, get_config, hdmi_ntsc_freqs, hdmi_status_show, render_bar, disk_notify, inuse_notify, sus_suspend, sus_status, sus_is_enabled, sus_stop_test_thread, egl_platform_switch, mem_validate, mem_oom, mem_reloc_stats, file, vctest_memmap, vctest_start, vctest_stop, vctest_set, vctest_get"Unfortunately, it doesn’t actually tell you anything about those commands or what they do. Some of them seem obvious, but then when you run them, they return things like this:
error=2 error_msg="Invalid arguments"The tool is poorly documented, but the Raspberry Pi community has come together and figured some of them out.The vcgencmd measure_volts command shows the voltage for some of the key Raspberry Pi components, specifically:
The GPU processor core
The SDRAM controller
The SDRAM input/output (I/O)
The SDRAM physical memory
Each of these components can be passed as an option to the vcgencmd measure_volts command (if you don’t specify one, it will return the value for core).You might be wondering why you’d care about measuring these voltages, and in most cases, you probably don’t. They’ll sit happily as shown in .Table 1-3. Components voltageComponentVoltagecore1.20sdram_c1.20sdram_i1.20sdram_p1.23The only time you might care about the component voltages is if you decide you want to overclock your Raspberry Pi. All of these voltages are configurable (as covered in detail in ).You might expect this command to return the system board voltage (which varies between 4.75V and 5.25V under normal conditions), but it doesn’t. See
for how to do that manually.Measure TemperatureThe vcgencmd measure_temp command reports the core temperature of the BCM2835 system-on-chip on your Raspberry Pi (in Celsius):
temp=44.4'CAlternatively, you can get the same temperature reading by reading this value directly from /sys/class/thermal/thermal_zone0/temp:$ cat /sys/class/thermal/thermal_zone0/temp
44388To convert that value to the Celsius temperature, simply divide it by 1,000. To get Fahrenheit, multiply the Celsius temperature by 1.8 and add 32. To get Kelvin, add 273.15 to the Celsius temperature. Is it getting hot in here, or is it just us?From the perspective of monitoring the Raspberry Pi hardware, this reading is probably sufficient. Since there is really no separation of the CPU/GPU (at least not from a physical or heating perspective), this gives you an idea of how hot the board is running. That said, if you want a more detailed (or just an additional) temperature reading, you can wire in an additional temperature sensor, as described in .Monitor Memory SplitWhether hardcoded or dynamically allocated, the vcgencmd get_mem command returns the value for either the ARM CPU or the video GPU.To see the amount of memory currently split off for the ARM CPU, run:$ su -c 'vcgencmd get_mem arm'
arm=448MTo see the amount of memory currently split to the video GPU, run:$ su -c 'vcgencmd get_mem gpu'
gpu=64MCheck Custom Configuration OverridesHave you forgotten what configuration changes you have made to your Raspberry Pi? Specifically, the ones that change settings in the firmware? While you could look in /boot/config.txt, the vcgencmd get_config command is here to help you.To see all configurations with a number (integer) datatype, run:$ su -c 'vcgencmd get_config int'
arm_freq=900To see all configurations with a text (string) datatype, run:$ su -c 'vcgencmd get_config str'There are very, very few configuration options that store string values instead of integers. Don’t be too surprised if the vcgencmd get_config str command doesn’t return anything.If you just want to check the value of a specific configuration, pass that config name instead:$ su -c 'vcgencmd get_config arm_freq'
arm_freq=900The vcgencmd utility is not the most user-friendly tool, but it does have a deep connection into the inner workings of the Raspberry Pi. Since this tool is open source (and the source code is available in the aforementioned Raspberry Pi GitHub firmware checkout), if you want to go very deep into the inner workings of the Raspberry Pi hardware, looking at the vcgencmd source code is a good jumping-off point.Hack 6. Overclock Your PiThe Raspberry Pi is not a notably fast computer. For most projects, it is more than capable of providing enough performance to get the job done, but for other projects, you might want to overclock the hardware to get a little bit more horsepower.The Raspberry Pi hardware is preconfigured to what the manufacturer believes is the best balance of reliability and performance. Now that we’ve stated that for the record, it also comes with a lot of tuning knobs, and if you are feeling brave, you can turn them up to get extra performance out of the hardware.This is what the cool kids call overclocking. People have been overclocking their computers since the beginning of the PC era, but it really became common when owners realized that the only difference between the high-end and low-end model of the same Intel CPU was whether it passed speed tests. The ones that passed got labeled at the higher clock speed, while the rest got the lower clock speed. If you were lucky, you could adjust settings to get a higher clock speed.These days, overclocking refers to changing any sort of setting to get performance above and beyond the default configuration of the hardware. As an example, some people have resorted to any number of tricks and hacks to get a performance boost, including immersing the entire system in liquid nitrogen cooled Flourinert. Some people are crazy.This is an excellent time to warn you: trying to overclock your Raspberry Pi will almost certainly make the hardware burn out quicker, possibly immediately. It will also probably not double your performance, and if by some miracle it did, you probably wouldn’t be able to run anything reliably on the overclocked Raspberry Pi.Then again, this is a $35 PC. You live only once. (When you decide to really take that advice to heart, try .)Remember that the heart of the Raspberry Pi is a Broadcom system-on-chip, with an ARM CPU, a Videocore IV GPU, and 512 MB of RAM. Each of these parts have its own clock frequencies, and the GPU has adjustable clock frequencies for its subcomponents. Specifically, the GPU has a core frequency, an H264 frequency (the H264 hardware video decoder block), a 3D processor frequency, and an image sensor processor frequency.You can tweak all of these settings by changing options in /boot/config.txt. This file
if it does not, just create a new empty file.Increase ARM CPU FrequencyLet’s start with the most obvious overclock: the ARM CPU. The frequency of the ARM CPU (arm_freq) defaults to 700 MHz. To speed it to 900 MHz, add this line to /boot/config.txt:
arm_freq=900Then, when you reboot, the hardware will try its best to honor your request. But remember, this isn’t magic. No matter how badly you want to put
as the frequency, it isn’t going to work. People with a lot of experience overclocking hardware have determined that the Raspberry Pi does not usually successfully overclock beyond 900 MHz, unless you use overvolting (see ).Increase SDRAM FrequencyAnother simple way to overclock is to increase the frequency of the SDRAM memory. The frequency of the SDRAM memory (sdram_freq) defaults to 400 MHz. You can usually increase this value to 500 Mhz without issue by adding this line to /boot/config.txt:sdram_freq=500Just like with arm_freq, you’ll need to reboot your Raspberry Pi for this to take effect.Increase GPU FrequencyYour last major overclocking option is the GPU components, the frequencies of which are all defined by gpu_freq and default to 250 MHz.gpu_freq is a sort of super setting. Setting it assigns the same value to the core_freq (GPU processor core frequency), h264_freq (hardware video block frequency), isp_freq (image sensor pipeline block frequency), and v3d_freq (3D block frequency). If you have a GPU-intensive task, you might get some extra performance by increasing the gpu_freq to 325. You can do this by adding this line to /boot/config.txt:gpu_freq=325That said, we don’t recommend changing the gpu_freq value, because it will take performance away from the CPU.
Instead, you might try just changing the core_freq value. If you do this, it is important to keep all of the GPU frequencies (listed previously) either the same or different by a factor of an integer multiplier. If you do not do this, the GPU components will receive a mixture of incompatible pulses and things will stop working very quickly.However, because the core_freq value also includes the L2 cache and some of the SDRAM memory clock cycles, increasing just that value could give the ARM CPU a performance boost. Multiply the default value by 2 (the largest integer that will really work) and set the value to 500 in /boot/config.txt like this:core_freq=500Note that this might not work. Some people report success, while others report failure. If you try to mix this core_freq change in with the other overclocking features, it might work only when they are set low (or left at the default).We cannot emphasize this enough: sometimes, when overclocking fails, it does so in less-than-obvious ways. Reliable programs become buggy, hardware devices stop working at random, and the system might just reboot for no good reason.When you do overclock, you’ll want to have a quantifiable test case that you can run over and over again to see what gives you the best performance for the workload that you care about on your specific Raspberry Pi. Do not simply download a canned benchmark and trust it. A benchmark designed to show GPU performance will not help you optimize your overclocked Raspberry Pi system for tasks that are CPU-bound.Pretested Overclock PresetsNewer versions of the Raspberry Pi firmware contain the option to choose between five overclock (turbo) presets that try to get the most performance out of the SoC without impairing the lifetime of the Pi. This is done by monitoring the core temperature of the chip and the CPU load and dynamically adjusting clock speeds and the core voltage.So, when there is a low demand on the CPU, or it is getting too hot, the performance is throttled down, but if the CPU has much to do, and the chip’s temperature allows it, performance is temporarily increased, with clock speeds up to 1 GHz, depending on the individual board and which of the turbo settings is used.
details the current settings of the five overclock presets.Table 1-4. Overclock presetsPresetARMCoreSDRAMOvervoltNone7002504000Modest8002504000Medium9002504502High9502504506Turbo10005006006If you are running a current version of Raspbian, you will notice that the raspi-config tool has support for configuring your Pi into any of these five presets. For other distributions, you will need to define the preset you want to use in /boot/config.txt by passing the values for each option individually. For example, to set the Medium preset, add these lines to your /boot/config.txt:
arm_freq=900
core_freq=250
sdram_freq=450
over_voltage=2Also, just because the Turbo setting has been known to work with some Raspberry Pi units, that doesn’t mean it will work with yours. Quite a few users have reported SD card corruption when trying to run their Raspberry Pi at that overclock preset.Hack 7. Overvolt for Higher PerformanceOvervolting, also known as “dynamic voltage scaling to increase voltage,” is a trick to get more performance out of an electrical component.The circuits in your Raspberry Pi are made up of transistors that act as logic gates or switches. The voltage at these nodes switches between a high voltage and a low voltage during normal operation. When the switch changes, the capacitance of the transistor and the voltage applied affect how quickly the switch output changes. Configuring a circuit to use higher voltage (“overvolting”) allows the circuit to react faster, which permits you to overclock the hardware further than what would normally be possible.The Raspberry Pi firmware exposes some configurable voltages, which map up with the following values in /boot/config.txt:
over_voltage (core)
over_voltage_sdram_c
over_voltage_sdram_i
over_voltage_sdram_p
If you do overvolt your Raspberry Pi by changing any of these settings, it might permanently set a fuse in your BCM2805 system on chip. That means that the vendor will know if you overvolt the hardware, it burns out, and you try to return it as defective. We shouldn’t have to say that it’s not OK to return things as defective when you were responsible, but you should be aware that this is warranty-voiding behavior.The biggest change comes from adjusting the over_voltage value, which is the core voltage for the ARM CPU and GPU in the BCM2835. The possible values for over_voltage run from -16 (0.8 V) to 8 (1.4 V), with default value at 0 (1.2 V). Each integer above (or below) 0 steps the voltage by 0.025 V. You cannot go over 6 without also setting force_turbo=1 (note that this will probably trip the “warranty voided fuse”).The over_voltage configuration setting is a super-setting; changing it applies the value to the over_voltage_sdram_c (SDRAM controller voltage), over_voltage_sdram_i (SDRAM I/O voltage), and over_voltage_sdram_p (SDRAM physical voltage) settings. It is possible to set those settings independently, but you are far more likely to get them wrong (or mismatched) and end up with memory corruption, so we strongly recommend that you use the over_voltate super-setting instead.If you decide to overvolt, just set these configuration options in /boot/config.txt, and then reboot.When you’re overvolting (or overclocking as well), monitoring the voltage levels of the components you’ve bumped up suddenly makes more sense. These methods can nudge out a tiny bit more performance from the hardware, but you’re trading that extra bit of performance for a reduction in hardware lifetime (and possibly stability as well).Hack 8. Get More USB PortsThe Raspberry Pi Model B has two dedicated USB connector ports, but really, that just isn’t enough for an awful lot of use cases. Here’s how you can hack in a few more.Universal Standard Bus (USB) has become the de facto standard connector for computing accessories. Keyboards, mice, hard drives, joysticks, flashlights, and even foam missile launchers all connect via USB. The Raspberry Pi (Model B) comes with two dedicated USB 2.0 ports to allow you access to this wide world of peripheral goodness, but these ports get used up quickly. The normal use case of a keyboard and mouse will use up both of these connectors, and you’re left with no place to put anything else!This is not a new problem for computer users. Laptops usually come with one to three USB connectors as well, even though a single USB host controller can support many more devices running simultaneously on the same BUS (up to 127 devices, to be precise). The trick to getting more is to use a USB hub.Once upon a time, USB hubs were expensive. That time is long past. In fact, they’re regularly given away for free. But there is a catch with these USB hubs. They come in two flavors:
Bus powered
This type of USB hub draws all its power from the host computer’s USB interface and is the type you’re likely to acquire as a free giveaway or in the cheap-stuff bin at the electronics store.
Externally powered
Also known as self-powered, this type of USB hub has an external power supply and uses it to provide full power to each USB connector on the hub.
USB 2.0 current is allocated in units of 100 mA (called unit loads), up to a maximum total of 500 mA per port. This means that if you are using a bus-powered hub, in the best possible scenario (getting 500 mA from the host computer), it can power four devices. That’s what the specification says, so it must be true, right? But in the real world, this isn’t quite the case.For starters, the USB hub needs some power to run, so it won’t be able to take the 500 mA from the host computer and give it all to the ports. Even if we assume it is an extremely efficient device (they usually are not), that means it can provide one unit load to four devices at once. But that’s not the whole story.The USB specification is pretty loose as specifications go (partially as a result of its ubiquity), and lots and lots of devices want more than 100 mA to work properly—most notably, wireless networking USB devices and keyboards with fancy features (LCD displays, integrated USB hubs, backlights, blenders, etc.). These devices are classified as high-power USB devices and can use up to the maximum of five unit loads (500 mA) per port. They are rarely (if ever) labeled as such, and they look visually identical to low-power (single-unit load) devices.On top of all that, the dedicated USB connectors on the Raspberry Pi provide only one unit load (100 mA) per port instead of the five unit loads that a “normal” computer would. This amount isn’t nearly enough to power a bus-powered hub with anything else connected to it, so that won’t work for you at all. The free (or extremely cheap) USB 2.0 hubs? They are always bus powered. Sorry. You’re going to have to buy something a little nicer.This is why if you connect a high-power USB device directly to the Raspberry Pi, it will either attempt to operate in low-power mode (sometimes these devices can do that), or the Raspberry Pi will simply power off or refuse to see the device. The majority of high-power devices will detect at low power, then try to pull additional power when put into active use (this is particularly common with wireless devices), resulting in a confusing scenario where the device appears to work, and the Linux kernel drivers load, but it doesn’t actually work reliably or properly.The solution to this problem space for the Raspberry Pi is to use an externally powered USB hub. You will want to use a good one, though, because there are plenty of awful choices here as well. It is common for the manufacturers of these USB hubs to cut corners and design the hub to run off of a low-amperage power supply. They do this because they assume that most of the devices you will connect to it are low powered and that you will not have all of the ports used at once.It is not uncommon for inexpensive, seven-port hubs to use a 1 A power supply. If each of those seven ports is connected to a high-power (five unit loads, 500 mA) device, they would need a 3.5 A power supply. More, really, because the hub needs power too!To be safe, you should assume the opposite from what these cost-cutting manufacturers do. Just assume that any USB device you
want to connect to your Raspberry Pi is high powered and that each port in your USB hub will have a high-powered device connected to it. Then it is a simple math problem to confirm if a USB hub will be a good choice:
Take the number of ports on the USB hub, and add 1 (to account for the USB hub itself).
Multiply that number by the size of a high-power load (.5).
The result will be the number of amps that the power supply for your USB hub should be providing (at a minimum).Even if you do use an externally powered USB hub, you might still run into issues using it with the Raspberry Pi. Some hubs will send power across the USB interconnect cable (the cable connecting the USB hub to the Raspberry Pi). This is called backpower.The standard says that hubs aren’t supposed to do this, but plenty of them do. Backpower can result in a situation where the connected USB hub has power before the Raspberry Pi has power (across the standard micro-USB power connector), which would cause the Raspberry Pi to be in a partially powered-on state. While partially powered on, your Raspberry Pi might start to make unwanted writes to the SD card.To avoid this, you can plug the USB hub’s power supply and the power supply for your Raspberry Pi into the same power strip, then use the switch on the power strip to power them on simultaneously.The Pi Hut sells a
designed specifically to be ideal for the Raspberry Pi. It avoids the need for careful power-on ordering, because it will never feed any power back over the interconnect cable. Sadly, however, it has only a 2 A power supply, which means you can have high-power devices (using five unit loads) on only three ports at once, with the leftover power going to the hub. Still, this unit is designed not to backpower, so you’ll never have to worry about that.There is also a
that is known to not have backpower issues. Even though it also has a 2 A power supply, you’re arguably less likely to exceed that on a four-port USB hub than you would be on a seven-port USB hub.The best hub for the Raspberry Pi that we’ve seen so far is the . It is a four-port externally powered hub with a 3 A power supply, and it is in the shape of the Raspberry Pi logo. They don’t have a U.S. version at the time of this writing, but they say it is coming soon!Hack 9. Troubleshoot Power ProblemsThe Pi doesn’t need a lot of power, but that also means that it needs what it’s asking for, and you can run into trouble when it gets too much or too little.The Raspberry Pi runs off a 5 V (DC) power source, pulled either from a dedicated Micro USB Type B port (labeled as Power on the board) or via the GPIO expansion (labeled as P1 on the board) pins, specifically the 5 V pins at P1-02 and P1-04.If you have a charger for most Android phones, you have the Pi’s power cable (sorry, iPhone fans). It is possible (but not the best scenario and might not work at all) to plug the other end into the USB port of your computer rather than the wall. And for other projects, you’ll want to get power through the GPIO. That said…Think Twice Before Using the GPIO to Power the PiBefore you rush to input 5 V over the GPIO pin, remember that when you do this you’re bypassing the hardware’s input fuse. That fuse is there to protect your hardware in case of malice or stupidity.For example, imagine that you think you’re passing 5 V, but you’re actually passing more than that into the Raspberry Pi via the GPIO. That might be because you weren’t entirely clear on what you were doing, or it could just be an accident. Either way, out comes magic smoke! And by “magic,” we mean, “that project just disappeared like a bunny in a hat!”Plenty of power supplies aren’t perfectly “clean,” meaning it might say “5 V,” but what it means is “more or less 5 Vish.” Even if it just spikes above 5 V, you’re bypassing the transient-voltage-suppression (TVS) diode!That diode is what would normally protect the Raspberry Pi from those unexpected voltage spikes (by shunting away the excess current when it exceeds the avalanche breakdown potential), but you’re just going right around it. And then out comes the magic smoke.Last, but not least, you have to put regulated 5 V into the GPIO, and most power adapters do not output regulated voltage. This means you need to have a voltage regulator circuit between the GPIO pin and the power adapter.For all of these reasons, we highly recommend you just feed power into the Micro USB Type B port, unless you have a truly excellent reason not to.Do Not Backpower the Pi over USB explains how some USB hubs will backpower over the interconnect cable, which can actually partially power the Raspberry Pi. Do not do this.USB hubs are not supposed to backpower. This is not regulated or reliable power in any real sense. It can (and likely will) result in unpredictable behavior including (but not limited to) unexpected program failures, kernel panics, and SD card corruption.OK, fine. There is a reasonably reliable way to do this. Some industrious hackers in Australia had a custom USB 3.0 hub produced with the explicit purpose of providing backpower for a Raspberry Pi.Specifically, the interconnect port on their hub will send over the 1000 mA (1 A) that the Raspberry Pi needs for normal operation. This will power the Pi entirely off the connection to the USB hub (no separate power source is necessary). You can check it out here:The only downside to using this hub is that it has only a 2 A power supply, and 1 A is going to the Raspberry Pi, leaving a little less than 1 A (some of that needs to go to the hub itself) for the connected devices. That doesn’t leave a lot of room for too many high-power devices (.5 A at maximum five-unit load).Get Power Through GPIO SafelyNote that there is a big difference between using the Raspberry Pi GPIO pins to power an attached device and pushing 5 V into the GPIO to power the Raspberry Pi. Lots of the hacks in this book need to draw some current from the GPIO pins, and this is safe to do.There are 3.3 V pins (P1-01 and P1-17), in addition to the 5 V pins (P1-02 and P1-04). Maximum permitted current draw from the 3.3 V pins is 50 mA. Maximum permitted current draw from the 5 V pins varies between the Raspberry Pi Model A and Model B hardware. The value for the maximum permitted current draw from the 5 V pins is calculated by starting with the USB input current (nominally 1 A), then subtracting the current draw from the rest of the board.On the Model A, the board has a current draw of 500 mA, so the max current draw off the 5 V pin is 500 mA. On the Model B, because it has a higher current draw on the board of 700 mA, the max current draw off the 5 V pin is 300 mA.Remember, be very, very careful with those 5 V pins! If you short 5 V to any of the other GPIO P1 pins, you’re likely to fry the entire Raspberry Pi. While deep-fried raspberry pie sounds like a delightful carnival snack, a fried Raspberry Pi circuit board is neither tasty or desirable.Solve Power ProblemsNow that you’ve reviewed your power options, you have to figure out what to do when things go awry.When the power is too low (or the current is too low), the Raspberry Pi starts to act… well, the technical term is “weird.” USB devices might not show up, or they might blink in and out randomly. Software might not run reliably. Cats and dogs living together, mass hysteria!If things are just being “weird,” there’s a good chance insufficient power is to blame. There are two main reasons why this can happen, even when you think you’ve done everything right: a subpar power supply or a faulty Micro USB cable.Get a better power supplyIt’s the opposite of that power spiking problem mentioned in . It says “5 V,” but what it means is, “I might consider delivering 5 V on my best day when all the stars are aligned and you perfectly hum the Doctor Who theme song backward to appease my cranky nature.” But they couldn’t fit all those words on the plug, so they just put “5 V.” (Or at least that’s our theory.)Sadly, this is a common scenario. A lot of cheap Micro USB cell phone chargers are cheap for a good reason: they don’t work very well. (Did you buy it at a dollar store? That could be a clue it’s a cheap one.)When it’s for your phone, it’s no big deal. It just takes longer to charge your battery. But the Raspberry Pi won’t take so kindly to the drop in desired power.The best way to avoid this is to buy a proven reliable power supply. For example, Adafruit sells an excellent
that actually outputs 5.25, which makes up for any voltage drop across the resistance of the USB cable between the power supply and the Raspberry Pi.Get a better micro USB cableYour Micro USB cable is less likely to be subpar in quality than the power supply, but it does happen. Cables have conductors in them that provide some resistance, but that’s usually irrelevant.For example, at 5 ohms and 50 mA of current, the voltage drop across the cable might be about 250 mV. Most devices are OK with that, because the USB specifications require that they be tolerant of voltage drops of that amount. However, some devices, like the Raspberry Pi, want more power (especially if you have some hungry USB devices plugged directly into the Raspberry Pi’s USB ports).As mentioned previously in this hack, the Model B draws a peak current of 700 mA, so if your USB cable has 5 ohms of resistance, it would result in a 3.5 V voltage drop. As far as the Pi is concerned, that’s huge.The good news is that most USB cables don’t have 5 ohms of resistance, and the really good ones will be very close to 0. We haven’t really had problems with cables that came with modern phones, which seems to be most people’s source of such cables.If you need to purchase a USB Micro B cable, Mediabridge’s “USB charging cables” test with a low resistance and are available on Amazon. Adafruit’s USB Micro B cables also work fine in peak-current draw on the Model B.Hotplugging (plugging in a USB device when the Pi is already running) will often cause the Pi to reboot. Plugging in the device causes a power spike, which means a drop in power to the Pi, which leads to the reboot.The Rev 1 board had two 140 mA polyfuses on the USB ports that prevented this but caused other problems, so Rev 2 boards do not. If you do anticipate the need to hotplug a device, do it through a powered USB hub.Test Your Cable’s ResistanceIf you have a cheap power supply, you can almost guarantee that’s your problem. But if you think you have a problem with your cable and want to test its resistance, you can either take the cable apart or you can use an accessible Micro USB Type B device (something that has ground pins on it).The USB Type A connector is big enough that you can get to the ground pin directly. (It’s Pin 4, the first pin on the left if you’re looking down the cable with the hollow space at the top of the connector.) Measure resistance with a calibrated multimeter set to the lowest ohm setting from ground on the Micro USB-B connected device to ground on the USB Type A connector to get a good idea of the cable’s resistance.You can also get a little hardware tool to simplify this. Bitwizard B.V. makes a
just for this purpose.Some people have even made their own cables by soldering low-resistance wires to a power supply and a Micro USB Type B connector. This is a neat hack if you just want to try making cables, but it’s not really necessary.Most modern USB cables do not seem to have serious resistance issues. If it will charge a Micro USB Type B cell phone quickly and reliably, it is probably good enough for the Raspberry Pi. If it won’t, a new one is generally easy and cheap to come by.Hack 10. Unbreak Your Raspberry PiThe Raspberry Pi hardware is pretty rugged for its size, but it does have one notable weak point that you might discover. Here’s how to find it and how to hack it back to life if it breaks.The Raspberry Pi comes with a built-in self-destruct button that many people have accidentally triggered the first time they plugged it in. OK, that’s not precisely true. But the placement of one of the Pi’s fragile components makes it really e