Raspberry Pi Hardware

The PCBs used in Raspberry Pi devices adhere to UL94-V0.

The Compliance Support programme is designed to eliminate the burden of navigating compliance issues and make it easier for companies to bring new products to consumers. It provides access to the same test engineers who worked on our Raspberry Pis during their compliance testing, connecting the user to a dedicated team at UL who assess and test the user’s product, facilitated by their in-depth knowledge of Raspberry Pi.

Find out more about the Raspberry Pi Compliance Support Programme.

The Powered by Raspberry Pi progamme provides a process for companies wanting to use a form of the Raspberry Pi logo, and covers products with Raspberry Pi computers or silicon inside, and services provided by a Raspberry Pi. If you wish to start the process to apply you can do so online.

Our list of approved design partners provide a set of consultancies that we work closely with and support so they can provide paid for design services across hardware, software, and mechanical.

Raspberry Pi 4 devices implement Dynamic Voltage and Frequency Scaling (DVFS). This technique allows Raspberry Pi 4 devices to run at lower temperatures whilst still providing the same performance.

Various clocks (e.g. ARM, Core, V3D, ISP, H264, HEVC) inside the SoC are monitored by the firmware, and whenever they are not running at full speed, the voltage supplied to the particular part of the chip driven by the clock is reduced relative to the reduction from full speed. In effect, only enough voltage is supplied to keep the block running correctly at the specific speed at which it is running. This can result in significant reductions in power used by the SoC, and therefore in the overall heat being produced.

Due to possible system stability problems involved with running an undervoltage, especially when using undervoltaged fixed clock peripherals (eg. PCIe), three DVFS modes are available and can be configured in /boot/config.txt with the below properties. Most systems should use dvfs=3, headless systems may benefit from a small power reduction with dvfs=1 at the risk of PCIe stability issues.

In addition, a more stepped CPU governor is also used to produce finer-grained control of ARM core frequencies, which means the DVFS is more effective. The steps are now 1500MHz, 1000MHz, 750MHz, and 600MHz. These steps can also help when the SoC is being throttled, and mean that throttling all the way back to 600MHz is much less likely, giving an overall increase in fully loaded performance.

The default CPU governor is ondemand, the governor can be manually changed with the cpufreq-set command (from the cpufrequtils package) to reduce idle power consumption:

Due to the architecture of the SoCs used on the Raspberry Pi range, and the use of the upstream temperature monitoring code in the Raspberry Pi OS distribution, Linux-based temperature measurements can be inaccurate. However, the vcgencmd command provides an accurate and instantaneous reading of the current SoC temperature as it communicates with the GPU directly:

Whilst heatsinks are not necessary to prevent overheating damage to the SoC — the thermal throttling mechanism handles that — a heatsink or small fan will help if you wish to reduce the amount of thermal throttling that takes place. Depending on the exact circumstances, mounting the Raspberry Pi vertically can also help with heat dissipation, as doing so can improve air flow.

If an error occurs during boot then an error code will be displayed via the green LED. Newer versions of the bootloader will display a diagnostic message which will be shown on both HDMI displays.

The boot behaviour (e.g. SD or USB boot) is controlled by a configuration file embedded in the EEPROM image and can be modified via the rpi-eeprom-config tool.

Please see the Bootloader Configuration sections for details of the configuration.

The rpi-eeprom-update systemd service runs at startup and applies an update if a new image is available, automatically migrating the current bootloader configuration.

To disable automatic updates:

To re-enable automatic updates:

The firmware release status corresponds to a particular subdirectory of bootloader firmware images (/lib/firmware/raspberrypi/bootloader/...), and can be changed to select a different release stream.

Since the release status string is just a subdirectory name, then it is possible to create your own release streams e.g. a pinned release or custom network boot configuration.

N.B. default and latest are symbolic links to the older release names of critical and stable.

USB host and Ethernet boot can be performed by BCM2837-based Raspberry Pis - that is, Raspberry Pi 2B version 1.2, Raspberry Pi 3B, and Raspberry Pi 3B+ (Raspberry Pi 3A+ cannot net boot since it does not have a built-in Ethernet interface). In addition, all Raspberry Pi models except Raspberry Pi 4B can use a new bootcode.bin-only method to enable USB host boot.

Format an SD card as FAT32 and copy on the latest bootcode.bin. The SD card must be present in the Raspberry Pi for it to boot. Once bootcode.bin is loaded from the SD card, the Raspberry Pi continues booting using USB host mode.

This is useful for the Raspberry Pi 1, 2, and Zero models, which are based on the BCM2835 and BCM2836 chips, and in situations where a Raspberry Pi 3 fails to boot (the latest bootcode.bin includes additional bugfixes for the Raspberry Pi 3B, compared to the boot code burned into the BCM2837A0).

If you have a problem with a mass storage device still not working, even with this bootcode.bin, then please add a new file 'timeout' to the SD card. This will extend to six seconds the time for which it waits for the mass storage device to initialise.

For information on enabling the UART on the Raspberry Pi 4 bootloader, please see this page.

It is possible to enable an early stage UART to debug booting issues (useful with the above bootcode.bin only boot mode). To do this, make sure you’ve got a recent version of the firmware (including bootcode.bin). To check if UART is supported in your current firmware:

To enable UART from bootcode.bin use:

Next, connect a suitable USB serial cable to your host computer (a Raspberry Pi will work, although I find the easiest path is to use a USB serial cable since it’ll work out the box without any pesky config.txt settings). Use the standard pins 6, 8 and 10 (GND, GPIO14, GPIO15) on a Raspberry Pi or Compute Module board.

Then use screen on linux or a Mac or putty on windows to connect to the serial.

Setup your serial to receive at 115200-8-N-1, and then boot your Raspberry Pi / Compute Module. You should get an immediate serial output from the device as bootcode.bin runs.

The boot flow for the ROM (first stage) is as follows:-

This section describes the high-level flow of the second stage bootloader.

Please see the bootloader configuration page for more information about each boot mode and the boot folder page for a description of the GPU firmware files loaded by this stage.

The bootloader may also be updated before the firmware is started if a pieeprom.upd file is found. Please see the bootloader EEPROM page for more information about bootloader updates.

The bootloader/firmware provide a one-shot flag which, if set, is cleared but causes tryboot.txt to be loaded instead of config.txt. This alternate config would specify the pending OS update firmware, cmdline, kernel and os_prefix parameters. Since the flag is cleared before starting the firmware, a crash or reset will cause the original config.txt file to be loaded on the next reboot.

To set the tryboot flag add tryboot after the partition number in the reboot command. Normally, the partition number defaults to zero but it must be specified if extra arguments are added.

tryboot is supported on all Raspberry Pi models, however, on Raspberry Pi 4 Model B revision 1.0 and 1.1 the EEPROM must not be write protected. This is because older Raspberry Pi 4B devices have to reset the power supply (losing the tryboot state) so this is stored inside the EEPROM instead.

If secure-boot is enabled then tryboot mode will cause tryboot.img to be loaded instead of boot.img.

Before editing the bootloader configuration, update your system to get the latest version of the rpi-eeprom package.

To view the current EEPROM configuration:
rpi-eeprom-config

To edit it and apply the updates to latest EEPROM release:
sudo -E rpi-eeprom-config --edit

Please see the boot EEPROM page for more information about the EEPROM update process.

This section describes all the configuration items available in the bootloader. The syntax is the same as config.txt but the properties are specific to the bootloader. Conditional filters are also supported except for EDID.

The following config.txt properties are used to program the secure-boot OTP settings. These changes are irreversible and can only be programmed via RPIBOOT when flashing the bootloader EEPROM image. This ensures that secure-boot cannot be set remotely or by accidentally inserting a stale SD card image.

For more information about enabling secure-boot please see the secure-boot readme and the secure-boot tutorial in the USBBOOT repo.

The DEFAULT version of the bootloader is only updated for CRITICAL fixes and major releases. The LATEST / STABLE bootloader is updated more often to include the latest fixes and improvements.

Advanced users can switch to the LATEST / STABLE bootloader to get the latest functionality. Open a command prompt and start raspi-config.

Navigate to Advanced Options and then Bootloader Version. Select Latest and choose Yes to confirm. Select Finish and confirm you want to reboot. After the reboot, open a command prompt again and update your system.

If you run rpi-eeprom-update, you should see that a more recent version of the bootloader is available and it’s the stable release.

Now you can update your bootloader.

If you run rpi-eeprom-update again after your Raspberry Pi has rebooted, you should now see that the CURRENT date has updated to indicate that you are using the latest version of the bootloader.

When this boot mode is activated (usually after a failure to boot from the SD card), the Raspberry Pi puts its USB port into device mode and awaits a USB reset from the host. Example code showing how the host needs to talk to the Raspberry Pi can be found on Github.

The host first sends a structure to the device down control endpoint 0. This contains the size and signature for the boot (security is not enabled, so no signature is required). Secondly, code is transmitted down endpoint 1 (bootcode.bin). Finally, the device will reply with a success code of:

The USB host boot mode follows this sequence:

The bootloader in Raspberry Pi 400 and newer Raspberry Pi 4B boards support USB boot by default, although the BOOT_ORDER bootloader configuration may need to be modified. On earlier Raspberry Pi 4B boards, or to select alternate boot modes, the bootloader must be updated.

See:-

Please see the Flashing the Compute Module eMMC for bootloader update instructions.

The Raspberry Pi 3B+ supports USB mass storage boot out of the box.

On the Raspberry Pi 2B v1.2, 3A+, 3B, Zero 2 W, and Compute Module 3, 3+ you must first enable USB host boot mode. This is to allow USB mass storage boot, and network boot. Note that network boot is not supported on the Raspberry Pi 3A+ or Zero 2 W.

To enable USB host boot mode, the Raspberry Pi needs to be booted from an SD card with a special option to set the USB host boot mode bit in the one-time programmable (OTP) memory. Once this bit has been set, the SD card is no longer required.

You can use any SD card running Raspberry Pi OS to program the OTP bit.

Enable USB host boot mode with this code:

This adds program_usb_boot_mode=1 to the end of /boot/config.txt.

Note that although the option is named program_usb_boot_mode, it only enables USB host boot mode. USB device boot mode is only available on certain models of Raspberry Pi - see USB device boot mode.

The next step is to reboot the Raspberry Pi with sudo reboot and check that the OTP has been programmed with:

Check that the output 0x3020000a is shown. If it is not, then the OTP bit has not been successfully programmed. In this case, go through the programming procedure again. If the bit is still not set, this may indicate a fault in the Raspberry Pi hardware itself.

If you wish, you can remove the program_usb_boot_mode line from config.txt, so that if you put the SD card into another Raspberry Pi, it won’t program USB host boot mode. Make sure there is no blank line at the end of config.txt.

You can now boot from a USB mass storage device in the same way as booting from an SD card - see the following section for further information.

The procedure is the same as for SD cards - simply image the USB storage device with the operating system image.

After preparing the storage device, connect the drive to the Raspberry Pi and power up the Raspberry Pi, being aware of the extra USB power requirements of the external drive. After five to ten seconds, the Raspberry Pi should begin booting and show the rainbow splash screen on an attached display. Make sure that you do not have an SD card inserted in the Raspberry Pi, since if you do, it will boot from that first.

See the bootmodes documentation for the boot sequence and alternative boot modes (network, USB device, GPIO or SD boot).

If you are unable to use a particular USB device to boot your Raspberry Pi, an alternative for the Raspberry Pi 2B v1.2, 3A+, 3B and 3B+ is to use the special bootcode.bin-only boot mode. The Raspberry Pi will still boot from the SD card, but bootcode.bin is the only file read from it.

Before attempting to boot from a USB mass storage device it is advisable to verify that the device works correctly under Linux. Boot using an SD card and plug in the USB mass storage device. This should appears as a removable drive. This is especially important with USB SATA adapters which may be supported by the bootloader in mass storage mode but fail if Linux selects USB Attached SCSI - UAS mode. See this forum thread about UAS and how to add usb-storage.quirks to workaround this issue.

Spinning hard disk drives nearly always require a powered USB hub. Even if it appears to work, you are likely to encounter intermittent failures without a powered USB HUB.

When searching for a bootable partition, the bootloader scans all USB mass storage devices in parallel and will select the first to respond. If the boot partition does not contain a suitable start.elf file, the next available device is selected. There is no method for specifying the boot device according to the USB topology because this would slow down boot and adds unnecessary and hard to support configuration complexity.

The first thing to check is that the OTP bit is correctly programmed. To do this, you need to add program_usb_boot_mode=1 to config.txt and reboot (with a standard SD card that boots correctly into Raspberry Pi OS). Once you’ve done this, you should be able to do:

If row 17 contains 3020000a then the OTP is correctly programmed. You should now be able to remove the SD card, plug in Ethernet, and then the Ethernet LEDs should light up around 5 seconds after the Raspberry Pi powers up.

To capture the ethernet packets on the server, use tcpdump on the tftpboot server (or DHCP server if they are different). You will need to capture the packets there otherwise you will not be able to see packets that get sent directly because network switches are not hubs!

This will write everything from eth0 to a file dump.pcap you can then post process it or upload it to cloudshark.com for communication

There are a number of known problems with the Ethernet boot mode. Since the implementation of the boot modes is in the chip itself, there are no workarounds other than to use an SD card with just the bootcode.bin file.

SD0 is the Broadcom SD card / MMC interface. When the boot ROM within the SoC runs, it always connects SD0 to the built-in microSD card slot. On Compute Modules with an eMMC device, SD0 is connected to that; on the Compute Module Lite SD0 is available on the edge connector and connects to the microSD card slot in the CMIO carrier board. SD1 is the Arasan SD card / MMC interface which is also capable of SDIO. All Raspberry Pi models with built-in wireless LAN use SD1 to connect to the wireless chip via SDIO.

The default pull resistance on the GPIO lines is 50K ohm, as documented on page 102 of the BCM2835 ARM peripherals datasheet. A pull resistance of 5K ohm is recommended to pull a GPIO line up: this will allow the GPIO to function but not consume too much power.

You need an NVMe M.2 SSD. You cannot plug an M.2 SSD directly into the PCIe slot on the IO board - an adaptor is needed. Be careful to get the correct type: a suitable adaptor can be found online by searching for 'PCI-E 3.0 x1 Lane to M.2 NGFF M-Key SSD Nvme PCI Express Adapter Card'.

The latest version of Raspberry Pi OS supports booting from NVMe drives. To check that your NVMe drive is connected correctly, boot Raspberry Pi OS from another drive and run ls -l /dev/nvme*; example output is shown below.

If you need to connect the NVMe drive to a PC or Mac you can use a USB adaptor: search for 'NVME PCI-E M-Key Solid State Drive External Enclosure'. The enclosure must support M key SSDs.

To boot from NVMe you need a recent version of the bootloader (after July 2021), and a recent version of the VideoCore firmware and Raspberry Pi OS Linux kernel. The latest Raspberry Pi OS release has everything you need, so you can use the Raspberry Pi Imager to install the software to your SSD.

If the boot process fails, please file an issue on the rpi-eeprom Github repository, including a copy of the console and anything displayed on the screen during boot.

To use HTTP boot you need to use the LATEST / STABLE bootloader configuration and update to a bootloader dated 10th March 2022 or later. HTTP boot only works over ethernet, so you need to connect your Raspberry Pi to your network via an Ethernet cable, e.g. to a socket on the back of your router.

All HTTP downloads must be signed. The bootloader includes a public key for the files on the default host fw-download-alias1.raspberrypi.com. This key will be used to verify the network install image unless you set HTTP_HOST and include a public key in the eeprom. This allows you to host the Raspberry Pi network install images on your own server.

USBBOOT has all the tools needed to program public keys. You would do something like this.

If secure boot is enabled then the Raspberry Pi can only run code signed by the customer’s private key. So if you want to use network install or HTTP boot mode with secure boot you must sign boot.img and generate boot.sig with your own key and host these files somewhere for download. The public key in the eeprom will be used to verify the image.

If secure boot is enabled and HTTP_HOST is not set, then network install and HTTP boot will be disabled.

For more information about secure boot see USBBOOT.

One of the alternate functions selectable on bank 0 of the Raspberry Pi GPIO is DPI (Display Parallel Interface) which is a simple clocked parallel interface (up to 8 bits of R, G and B; clock, enable, hsync, and vsync). This interface is available as alternate function 2 (ALT2) on GPIO bank 0:

Note that all other peripheral overlays that use conflicting GPIO pins must be disabled. In config.txt, take care to comment out or invert any dtparams that enable I2C or SPI:

The output format (clock, colour format, sync polarity, enable) can be controlled with a magic number (unsigned integer or hex value prefixed with 0x) passed to the dpi_output_format parameter in config.txt created from the following fields:

NB the single bit fields all act as an "invert default behaviour".

In firmware dated August 2018 or later, the hdmi_timings config.txt entry that was previously used to set up the DPI timings has be superseded by a new dpi_timings parameter. If the dpi_timings parameter is not present, the system will fall back to using the hdmi_timings parameter to ensure backwards compatibility. If neither are present and a custom mode is requested, then a default set of parameters for VGAp60 is used.

The dpi_group and dpi_mode config.txt parameters are used to set either predetermined modes (DMT or CEA modes as used by HDMI) or a user can generate custom modes.

If you set up a custom DPI mode, then in config.txt use:

This will tell the driver to use the custom dpi_timings (older firmware uses hdmi_timings) timings for the DPI panel.

The dpi_timings parameters are specified as a space-delimited set of parameters:

A Linux Device Tree overlay is used to switch the GPIO pins into the correct mode (alt function 2). As previously mentioned, the GPU is responsible for driving the DPI display. Hence there is no Linux driver; the overlay simply sets the GPIO alt functions correctly.

A 'full fat' DPI overlay (dpi24.dtb) is provided which sets all 28 GPIOs to ALT2 mode, providing the full 24 bits of colour bus as well as the h and v-sync, enable and pixel clock. Note this uses all of the bank 0 GPIO pins.

A second overlay (vga666.dtb) is provided for driving VGA monitor signals in 666 mode which don’t need the clock and DE pins (GPIO 0 and 1) and only require GPIOs 4-21 for colour (using mode 5).

These overlays are fairly trivial and a user can edit them to create a custom overlay to enable just the pins required for their specific use case. For example, if one was using a DPI display using vsync, hsync, pclk, and de but in RGB565 mode (mode 2), then the dpi24.dtb overlay could be edited so that GPIOs 20-27 were not switched to DPI mode and hence could be used for other purposes.

The GPIO connections on the BCM2835 package are sometimes referred to in the peripherals data sheet as "pads" — a semiconductor design term meaning 'chip connection to outside world'.

The pads are configurable CMOS push-pull output drivers/input buffers. Register-based control settings are available for:

Each GPIO pin, when configured as a general-purpose input, can be configured as an interrupt source to the ARM. Several interrupt generation sources are configurable:

Level interrupts maintain the interrupt status until the level has been cleared by system software (e.g. by servicing the attached peripheral generating the interrupt).

The normal rising/falling edge detection has a small amount of synchronisation built into the detection. At the system clock frequency, the pin is sampled with the criteria for generation of an interrupt being a stable transition within a three-cycle window, i.e. a record of '1 0 0' or '0 1 1'. Asynchronous detection bypasses this synchronisation to enable the detection of very narrow events.

Almost all of the GPIO pins have alternative functions. Peripheral blocks internal to the SoC can be selected to appear on one or more of a set of GPIO pins, for example the I2C buses can be configured to at least 3 separate locations. Pad control, such as drive strength or Schmitt filtering, still applies when the pin is configured as an alternate function.

The table below gives the various voltage specifications for the GPIO pins for BCM2835, BCM2836, BCM2837 and RP3A0-based products (e.g. Raspberry Pi Zero or Raspberry Pi 3+). For information about Compute Modules you should see the relevant datasheets.

^a Hysteresis enabled
^b Default drive strength (8mA)
^c Maximum drive strength (16mA)

The table below gives the various voltage specifications for the GPIO pins for BCM2711-based products (e.g. Raspberry Pi 4 and Raspberry Pi 400). For information about Compute Modules you should see the relevant datasheets.

^a Hysteresis enabled
^b Default drive strength (4mA)
^c Maximum drive strength (8mA)

There are a number of OTP values that can be used. To see a list of all the OTP values, you can use:

Some interesting lines from this dump are:

Also, from 36 to 43 (inclusive), there are eight rows of 32 bits available for the customer

To program these bits, you will need to use the vcmailbox. This is a Linux driver interface to the firmware which will handle the programming of the rows. To do this, please refer to the documentation, and the vcmailbox example application.

The vcmailbox application can be used directly from the command line on Raspberry Pi OS. An example usage would be:

which will return something like:

The above uses the mailbox property interface GET_BOARD_SERIAL with a request size of 8 bytes and response size of 8 bytes (sending two integers for the request 0, 0). The response to this will be two integers (0x00000020 and 0x80000000) followed by the tag code, the request length, the response length (with the 31st bit set to indicate that it is a response) then the 64 bit serial number (where the MS 32bits are always 0).

To set the customer OTP values you will need to use the SET_CUSTOMER_OTP (0x38021) tag as follows:

So, to program OTP customer rows 4, 5, and 6 to 0x11111111, 0x22222222, 0x33333333 respectively, you would use:

This will then program rows 40, 41, and 42.

To read the values back, you can use:

which should display:

If you’d like to integrate this functionality into your own code, you should be able to achieve this by using the vcmailbox.c code as an example.

It is possible to lock the OTP changes to avoid them being edited again. This can be done using a special argument with the OTP write mailbox:

Once locked, the customer OTP values can no longer be altered. Note that this locking operation is irreversible.

It is possible to prevent the customer OTP bits from being read at all. This can be done using a special argument with the OTP write mailbox:

This operation is unlikely to be useful for the vast majority of users, and is irreversible.

This list contains the publicly available information on the registers. If a register or bit is not defined here, then it is not public.

17 — bootmode register

18 — copy of bootmode register
28 — serial number
29 — ~(serial number)
30 — xref:raspberry-pi.adoc#raspberry-pi-revision-codes¹
33 - board revision extended - the meaning depends on the board model.
This is available via device-tree in /proc/device-tree/chosen/rpi-boardrev-ext and for testing purposes this OTP value can be temporarily overridden by setting board_rev_ext in config.txt.

36-43 - customer OTP values
45 - MPG2 decode key
46 - WVC1 decode key
47-55 - Reserved for signed-boot on Compute Module 4
64/65 — MAC address; if set, system will use this in preference to the automatically generated address based on the serial number
66 — advanced boot register (not BCM2711)

¹Also contains bits to disable overvoltage, OTP programming, and OTP reading.

The specific power requirements of each model are shown below.

From the Raspberry Pi B+ onwards, 1.2A is supplied to downstream USB peripherals. This allows the vast majority of USB devices to be connected directly to these models, assuming the upstream power supply has sufficient available current.

Very high-current devices, or devices which can draw a surge current such as certain modems and USB hard disks, will still require an external powered USB hub. The power requirements of the Raspberry Pi increase as you make use of the various interfaces on the Raspberry Pi. The GPIO pins can draw 50mA safely (note that that means 50mA distributed across all the pins: an individual GPIO pin can only safely draw 16mA), the HDMI port uses 50mA, the Camera Module requires 250mA, and keyboards and mice can take as little as 100mA or as much as 1000mA! Check the power rating of the devices you plan to connect to the Raspberry Pi and purchase a power supply accordingly. If you’re not sure, we would advise you to buy a powered USB hub.

This is the typical amount of power (in Ampere) drawn by different Raspberry Pi models during standard processes:

On all models of Raspberry Pi since the Raspberry Pi B+ (2014) except the Zero range, there is low-voltage detection circuitry that will detect if the supply voltage drops below 4.63V (+/- 5%). This will result in a warning icon being displayed on all attached displays and an entry being added to the kernel log.

If you are seeing warnings, you should improve the power supply and/or cable, as low power can cause problems with corruption of SD cards, or erratic behaviour of the Raspberry Pi itself; for example, unexplained crashes.

Voltages can drop for a variety of reasons, for example if the power supply itself is inadequate, the power supply cable is made of too thin wires, or you have plugged in high demand USB devices.

The USB specification requires that USB devices must not supply current to upstream devices. If a USB device does supply current to an upstream device then this is called back-powering. Often this happens when a badly-made powered USB hub is connected, and will result in the powered USB hub supplying power to the host Raspberry Pi. This is not recommended since the power being supplied to the Raspberry Pi via the hub will bypass the protection circuitry built into the Raspberry Pi, leaving it vulnerable to damage in the event of a power surge.

Raspberry Pi Zero, 1, 2 and 3 have three SPI controllers:

On the Raspberry Pi 4, 400 and Compute Module 4 there are four additional SPI buses: SPI3 to SPI6, each with 2 hardware chip selects. These extra SPI buses are available via alternate function assignments on certain GPIO pins - see the BCM2711 ARM Peripherals datasheet.

Chapter 10 in the BCM2835 ARM Peripherals datasheet describes the main controller. Chapter 2.3 describes the auxiliary controller.

As with all computers, the USB ports on the Raspberry Pi supply a limited amount of power. Often problems with USB devices are caused by power issues. To rule out insufficient power as the cause of the problem, connect your USB devices to the Raspberry Pi using a powered hub.

The Raspberry Pi 4 contains two USB 3.0 ports and two USB 2.0 ports which are connected to a VL805 USB controller. The USB 2.0 lines on all four ports are connected to a single USB 2.0 hub within the VL805: this limits the total available bandwidth for USB 1.1 and USB 2.0 devices to that of a single USB 2.0 port.

On the Raspberry Pi 4, the USB controller used on previous models is located on the USB type C port and is disabled by default.

The USB controller on models prior to Raspberry Pi 4 has only a basic level of support for certain devices, which presents a higher software processing overhead. It also supports only one root USB port: all traffic from connected devices is funnelled down this single bus, which operates at a maximum speed of 480Mbps.

The USB 2.0 specification defines three device speeds - low, full and high. Most mice and keyboards are low speed, most USB sound devices are full speed and most video devices (webcams or video capture) are high speed.

Generally, there are no issues with connecting multiple high speed USB devices to a Raspberry Pi.

The software overhead incurred when talking to low and full speed devices means that there are limitations on the number of simultaneously active low and full speed devices. Small numbers of these types of devices connected to a Raspberry Pi will cause no issues.

The first set of Raspberry Pi models were given sequential hex revision codes from 0002 to 0015:

With the launch of the Raspberry Pi 2, new-style revision codes were introduced. Rather than being sequential, each bit of the hex code represents a piece of information about the revision:

¹ Information on programming the OTP bits.

² Warranty bit is never set on Raspberry Pi 4.