Raspberry Pi RP1 Southbridge Chip Explained: What Changed on the Pi 5 I/O and Why It Matters for Makers

If you've read our Pi 5 vs Pi 4 migration guide, you already know the headline specs: a faster CPU, PCIe support, NVMe boot. What that comparison doesn't dig into is the single biggest architectural change under the hood, and the one that actually explains most of the Pi 5's real-world I/O behavior changes: Raspberry Pi designed their own silicon, called RP1, to take over almost all of the peripheral I/O that used to be handled directly by the main SoC. Understanding what RP1 actually does clears up a lot of "why does this work differently on a Pi 5" questions that come up constantly in GPIO, camera, and display projects.

What RP1 actually is

On every previous Raspberry Pi model, the main Broadcom SoC handled GPIO, USB, Ethernet, camera (CSI), and display (DSI) interfaces more or less directly, as part of the same chip running your Linux kernel. On the Pi 5, Raspberry Pi split that off entirely: RP1 is a separate chip, designed in-house by Raspberry Pi (the same team behind the RP2040 in the Pico), that sits on the board and handles GPIO, USB 2.0 and 3.0, the two camera/display MIPI connectors, and Ethernet, communicating back to the main Broadcom SoC over a PCIe link rather than being wired directly into it. It's a genuine southbridge in the classic PC sense — a dedicated I/O controller chip offloading peripheral handling from the main processor, the same architectural pattern desktop motherboards have used for decades, just newly applied to a single-board computer.

Why Raspberry Pi did this

A few converging reasons, all of which show up in practical behavior differences:

• Freeing up the main SoC's limited I/O pins — modern SoC packages have a finite number of pins, and dedicating many of them to legacy peripheral interfaces (GPIO, camera, display) limits what else the chip can do. Moving that to a separate chip over a PCIe link sidesteps the constraint.
• Design reuse and faster iteration — RP1 is Raspberry Pi's own design, meaning they're not dependent on Broadcom's SoC roadmap for peripheral feature changes, and can iterate on I/O capability somewhat independently of the core compute chip.
• Genuinely improved GPIO performance in some respects — RP1's GPIO block is a from-scratch Raspberry Pi design rather than inherited legacy silicon, and includes features like improved pull-up/pull-down drive strength options and faster toggle rates achievable from well-written low-level code, compared to earlier Pi GPIO blocks.

What this means in practice for maker projects

AreaWhat changedWhy it matters to you GPIO librariesLow-level GPIO access methods that directly poked SoC memory-mapped registers on earlier Pis (some older RPi.GPIO-adjacent code, certain real-time bit-banging tricks) don't work unmodified, since the registers now live on RP1 across a PCIe link rather than directly in the main SoC's address spaceModern libraries (gpiozero, the updated RPi.GPIO successor stack, libgpiod) already handle this correctly — the practical advice is to use current, actively maintained GPIO libraries rather than very old example code written before the Pi 5 existed GPIO timing characteristicsGoing through RP1 and a PCIe link introduces different latency characteristics than the previous direct-SoC pathOur real-time Linux and PREEMPT_RT coverage on the Pi is the right reference if your project genuinely depends on tight GPIO timing — don't assume Pi 4 timing numbers carry over unchanged Camera and displayBoth CSI camera ports and the DSI display connector are now served through RP1 rather than directly from the Broadcom SoCThis is largely transparent if you're using libcamera and current display drivers, but it's why some older third-party camera driver hacks that poked SoC-specific registers directly needed updates for Pi 5 support USBRP1 handles USB 2.0 and 3.0 host controller dutiesExplains why USB behavior and available bandwidth on the Pi 5 is described separately from the main SoC's PCIe lane, which is instead available for the M.2/NVMe HAT ecosystem

Where this actually bit people

The most common practical fallout, seen across early Pi 5 adopters, fell into two camps: GPIO code written against very low-level register access patterns (rather than a proper library) that assumed a direct-SoC memory map and needed porting, and a handful of camera or display accessory boards from before RP1 existed that needed a firmware or driver update from their manufacturer to work correctly. Neither is really an "RP1 problem" so much as the normal cost of any architecture change — if you've been using maintained, current libraries for your GPIO, camera, and display work rather than low-level SoC-specific tricks, RP1's existence is mostly invisible day to day.

Should this change how you design a new project?

Not dramatically, for most maker-level work. Write GPIO code against gpiozero, libgpiod, or another current, actively maintained library rather than directly manipulating memory-mapped registers, and you're insulated from needing to care whether you're talking to RP1 or a previous generation's direct SoC GPIO block. The one place it's genuinely worth knowing about is if you're debugging a Pi 5-specific GPIO timing or camera driver issue and the usual fixes for a Pi 4 don't apply — at that point, knowing there's a separate RP1 chip and a PCIe link in the data path, rather than a single monolithic SoC, is the detail that makes the rest of the debugging make sense.

RP1 is a genuinely interesting piece of in-house silicon design from a company that started as a single-SoC hobby board maker, and it's a sign of where Raspberry Pi's engineering ambitions have moved — but for the overwhelming majority of GPIO, camera, and sensor projects covered on this site, the right takeaway is simply: use current libraries, and the architecture change underneath them will stay out of your way.