Today we’re happy to announce a couple of new accessories that we think will make a big difference to your experience with Raspberry Pi. With the latest release of Raspberry Pi OS, Raspberry Pi 5 can make use of the extra performance available from Class A2 SD cards; to help you take advantage of this, we are introducing our own range of high-quality, low-cost Raspberry Pi SD Cards. And we’re releasing the Raspberry Pi Bumper, a cute little silicone cover to protect the base and edges of your Raspberry Pi 5.

Raspberry Pi SD Cards

As many of you will know first-hand, your choice of SD card makes a huge difference to your Raspberry Pi experience. Historically, we’ve worked with our Approved Reseller partners to test and endorse third-party SD cards. But as cards have become more sophisticated, and particularly with the advent of Class A2 cards, this process has become increasingly cumbersome.

To ensure you have the best possible experience at the lowest possible cost, we’ve worked with our partner Longsys to develop a range of branded Raspberry Pi SD Cards. These Class A2 cards offer exceptional random read and write throughput across the entire range of Raspberry Pi computers, and when used on Raspberry Pi 5 support command queueing for even higher performance.

From today, our Approved Resellers will only promote Raspberry Pi SD Cards alongside Raspberry Pi computers, and you can be assured of their quality.

Class A2 SD Cards: harder, better, faster, stronger

SD cards which support Application Performance Class A2, such as our new Raspberry Pi SD Cards, enable faster read and write operations, and Raspberry Pi 5 incorporates hardware features which allow it to make the most of this extra performance. To enable these features, you will need to use the latest release of Raspberry Pi OS, or update your Raspberry Pi OS install with the latest packages. Run the following command to update:

sudo apt update && sudo apt full-upgrade

How exactly do Class A2 cards achieve better performance? Read on!

What is CQHCI?

The SD Host Controller Interface (SDHCI) specification standardises the piece of hardware (the host controller) which controls communication with the SD card. On Raspberry Pi computers, the host controller lives inside the Broadcom application processor. The Command Queueing Host Controller Interface (CQHCI) extends SDHCI with an extra set of control registers, and a CQ engine which takes over from the legacy host controller when a suitable card is detected.

Cards must be explicitly put into command queueing (CQ) mode, after which a new set of SD commands becomes available and many of the existing SD commands become invalid. The new commands decouple the request to read or write a card sector from the response of the card. Each read or write operation is tagged, with up to 32 tags in use across both reads and writes. The card can choose the order in which it returns responses to the commands, and may optionally buffer write data rather than committing it immediately to flash.

By allowing it to effectively “see into the future”, command queueing lets the flash controller hide more of the latency associated with accessing disparate NAND flash pages. This results — at least in theory — in better throughput for random I/O workloads of the sort generated by Raspberry Pi OS.

CQ support first landed in eMMC devices with JEDEC specification JESD84-B51, in 2015. The SD specification equivalent landed some time later with SD v6.00, in 2017. However, at the time of the Raspberry Pi 5 launch in 2023, Linux only supported CQHCI on eMMC devices — so we were leaving performance on the table.

In early 2024 I set about implementing the missing CQ support for SD cards.

How do you use CQHCI?

Carefully parsing the SD specification led me to develop a dependency chain of optional card features that all needed to be supported if CQ mode is to be used. These are, in order:

• The card must support Extension Register access, which is a generic method of accessing optional features over 512-byte pages, each with a type identifying to what feature extension the page refers
• The card must support the Performance Enhancement extension registers
• In the Performance Enhancement extension, the card must support Write Caching
• As a consequence of Write Caching support, the card must also support the Power extension registers and at a minimum support Power-Off notifications
• The card must declare the queue depth required to meet Class A2 performance — from 2 to 32 tags

As Linux already supported CQ with eMMC cards, all I had to do was to find out where the SD implementation differed — and there were a few of these cases.

During normal operation the host operating system sometimes needs to issue “meta-ops” that don’t directly transfer data but do related things, such as recalibrating the host-to-card data path delays, requesting card status as a proxy for card removal, and doing flash maintenance operations such as signalling block discard.

For eMMC devices, most meta-ops are performed by issuing command CMD6 with a 32-bit argument. CQHCI supports injecting these while in CQ mode by designating the “top” tag in the controller for performing DCMDs (direct commands). However, with SD cards, the set of commands performing meta-ops generally require us to halt the CQ engine, and issue a non-CQ command using the regular SD host controller registers.

Once these differences were ironed out, I had a workable Linux driver, which was pushed to rpi-update. I created a testing thread in the forums for the adventurous, and set about evaluating my extensive collection of retail cards.

How well do SD cards implement CQ mode?

In a very hit-and-miss fashion.

SanDisk cards, in particular the Extreme and Extreme Pro product lines, were my first choice — and they performed well. However, other manufacturers’ offerings suffered from one or more of a number of common deficiencies that precluded CQ mode operation, or caused them to flake out in use:

• Not declaring Power-Off notification support despite implementing the extension
• Hanging on receipt of a cache flush request after CQ mode had been activated then deactivated
• Cards not correctly implementing the “CQ enable” expansion register bit — if I wrote a 1, I would still read back 0 forever

There was even one type of card that claimed Class A2 support but ignored any request to read the expansion registers to probe for any of these features!

The Raspberry Pi kernel filters out cards that fail these tests, either during feature probing or with an explicit quirk that matches the card identifier. If you find an A2-branded card that misbehaves on a Raspberry Pi 5, then please report it in the above-mentioned forum thread.

Write caching + surprise removal = badness

One potential pitfall of enabling CQ mode was that it provides cards with new opportunities to corrupt your filesystem if power is removed unexpectedly. In CQ mode, hosts should honour the requirement to maintain the card’s power supply, and only remove it after a Power-Off notification is sent; this provides an opportunity for the flash controller to commit all outstanding writes to flash. For battery-powered hosts with concealed SD slots such as a phone, that is an easy contract to fulfil — requesting device shutdown or uncovering the slot can trigger a Power-Off notification. Raspberry Pi, with its exposed SD slot and pluggable PSU, has a harder time providing this guarantee.

With multiple writes in flight, or multiple posted notifications of pending writes, we can no longer guarantee the order in which writes get committed to flash. If power is removed unexpectedly, an arbitrary collection of recent writes may not have been committed, rather than strictly the n most recent writes; this greatly complicates the task of making the filesystem resilient to corruption. The Raspberry Pi kernel sidesteps this problem by limiting the maximum number of posted writes in CQ mode to one. While in theory this may result in lower sequential write throughput, the cards I’ve tested see at most a 2–3% percent reduction in performance.

Introducing Longsys

Once it became clear that Class A2 SD cards offer a significant performance uplift when operating in CQ mode on Raspberry Pi 5, we started discussions with several card OEMs, with the goal of qualifying a cost-effective offering that would work well across every generation of Raspberry Pi computer.

We settled on Longsys as our vendor after working with their engineering team to align their cards’ declared feature sets with our requirements; to prove that the cards were robust by automatically performing over 100,000 surprise power cycles under I/O heavy load; and to tune the cards to get the best out of Raspberry Pi 5.

While best performance on Raspberry Pi 5 was our primary goal, the non-CQ performance of these cards is still stonkingly fast, and you will generally see a significant uplift in performance on older Raspberry Pi computers.

Raspberry Pi Bumper for Raspberry Pi 5

Today’s other accessory launch brings you the Raspberry Pi Bumper: the simple casing solution you never knew you needed, and already a firm favourite here at Pi Towers. It’s a snap-on silicone base that unfussily protects the base and edges of your Raspberry Pi 5, and the surface you’re putting it down on, and also makes it easier to use the power button. It’s compatible with the Raspberry Pi Active Cooler, and will set you back a meagre $3.

And there you are. Two unglamorous, yet excellent, accessories that we wonder how we managed without. We hope you like them.

The post Raspberry Pi SD Cards and the Raspberry Pi Bumper: your new favourite accessories appeared first on Raspberry Pi.