Pineberry Pi HatDrive: Using NVMe SSDs With The Raspberry Pi 5

When the Raspberry Pi 5 launched, many were left chomping at the bit after seeing the PCIe FPC connector alongside the promise that an ‘NVMe SSD HAT would be forthcoming’. Although the official Raspberry Pi NVMe HAT is still a long while off, the Polish company Pineberry Pi is ramping up to release its Top & Bottom versions of its very wittily called HatDrive.

They sent a prototype to [Jeff Geerling], who has been putting his grubby mitts all over them before putting together a video showing off the HatDrive Top, which can accept 2230 and 2242 size NVMe drives.

The primary goal of adding an NVMe drive to the RPi is of course to get rid of those slow and fragile SD cards. Although the SD card standard supports near-NVMe-like speeds with UHS-III, the Raspberry Pi 5 bottoms out at UHS-I, around 100 MB/s. Despite this, using an NVMe drive for booting still takes some work, as [Jeff] lays out in a clear article. Most of this involves tweaking the /boot/config.txt file to enable external PCIe support, editing the onboard EEPROM to change the boot order (in lieu of having a PC-like BIOS screen) and getting the OS image flashed onto the NVMe drive you intend to boot from.

Although things seem to work fine during [Jeff]’s testing, some caveats remain, such as the RPi 5 officially supporting only PCIe Gen 2 x1, with Gen 3 possible, but with potential data integrity issues. There’s also the fundamental limit of having only a single lane of PCIe available. If that’s no problem, then Pineberry Pi offers the aforementioned HatDrive Top for traditional HAT-style mounting, and a Bottom version that can accept up to 2280 format NVMe SSDs. Including the provided ribbon cables, you can order the Top and Bottom for €20 and €25.99 respectively, with the first batch to ship in early December.

Thanks to [Stephen Walters] for the tip.

27 thoughts on “Pineberry Pi HatDrive: Using NVMe SSDs With The Raspberry Pi 5

  1. Just why… If you don’t want to use RPi like a normal embedded device i.e. with RO memory and have wear leveled RW memory just for logs and you are hell bent on using it as a desktop then why not use just industrial SD card or for the massive simplicity of it just and ordinary SSD with SATA-USB adapter. All those 3, 4, and 5 Pis can boot from them.

    1. Why a “normal embedded device” should not have a fast NVMe storage? For example, logging can require a very significant storage throughput, and SD cards are not suitable for it. I had to resort to an external drive connected over USB3 for logging purposes alone (around 100Mb/s telemetry only, not counting the camera feeds), which is far from ideal.

    2. Why not? This is Hackaday, not “use only for what one person believes its intended purpose is”-aday.

      “Stop liking what I don’t like” is a rude and pointless position for you to take, dude.

      1. Might I interest you in some prime hacking action?

        *plugs SSD into port*

        I think its an expectation issue. “Hacks” on hackaday are supposed to be clever/interesting/unusual/whacky projects. Simple design projects are just….too vanilla.

    3. This should have been a stock feature of the RPi imho.

      These boards stopped being “embedded” for quite some time, they’re more like a small desktop PC with some GPIOs now, but a lot of people still fail to acknowledge that.
      What’s keeping them from being used as general purpose small desktop PCs is mainly the fragility and lack of speed of booting an OS from an SD card, and the linux distro support that is not yet on par with their x86 counterpart. Examples: want to encrypt the root filesystem on a raspberry? good luck with that. Secure boot? Never heard of it in an RPi. Accelerator support, still in its infancy, most standard linux apps can’t use hardware video decoding. Want to run virtual machines on an RPi? see point one.

      Let’s hope this is a step in the right direction, and that eventually we’d all be able to use a cheap and energy efficient ARM sbc as our main desktop OS. At least those of us who aren’t into gaming, that is.

      1. Virtual machines run just fine on a Pi, I’ve had quite a few of them running simultaneously as an experiment before, though obviously if you are going to lock out large chunks of system memory you want one of the models with lots of RAM, and at least on the Pi4 getting useful performace out of that many VM is overclock and cooling time.

        Secure boot technically exists on Pi4 (and 5 I assume) – but the concept of secure boot is of so little value to most Pi uses I can’t see why you would actually do it.

        And for what it is – a small low power embedded GPU the Vidcore GPU’s are now pretty well supported – doesn’t have all the features of the Intel/AMD/Nvidia graphics options, but the hardware does have support, and it does work on the formats the GPU has accelerators for, and should with any of the more ubiquitous video handling programs and distro’s just work by default.

        I really don’t see the requirement for these drives on a normal Pi either – really cool to have it, but USB 3 drives are fast enough and can be NVME for the read/write and data endurance – functionally rather equivalent. But if your usecase was one that really wants a native NVME drive you have always had the option of the compute module 4 – all the pi4 goodness that can be attached to any carrier board you like (or design) brining out only the stuff you care about, including that PCIe lane right into a M.2 slot.

        The Linux experience on Arm vs x86-64/AMD64 is virtually identical now. Assuming you can find slow enough Intel/AMD or fast enough Arm options to provide a valid performance comparison. Most distro’s have an Arm variant, and the good Arm CPU/SOC computer suppliers have mainlined everything needed for it to work or at the very least kept up their own fork (so just don’t buy one of the terribly supported and only good on paper SBC that only has one ancient kernel) and almost all of the software you may want is packaged for both, and if it isn’t pre-packaged it is probably just one compile away.

        I’ve used a Pi4 as my daily desktop for a long time, as it worked really well, able to do most tasks and keep a VM running all the time – though its use has fallen away of late as the steamdeck has so much more performance and still has an excellent power consumption rate.

      2. I agree with your first statement, mainly because of the unreliability of SD cards (which I hadn’t even realized until the Pi started killing them).

        And I don’t want to scorn other people’s use cases, but your gripes about security and encryption seem like they’d be way down the list of most people’s priorities with such a device. Accelerators and hardware decoding? Yeah, now we’re talking about stuff with wide appeal.

        Oh, and Pi Co.: STOP USING MICRO-HDMI. It’s insulting trash at ANY price point.

        1. What is the big deal about knocking micro-hdmi??? It seems to work great with either a full size monitor or the small portable monitor that I am currently using. Even sound comes through ok on the small portable display. So just wondering…..

        2. Also agree with you on the security and encryption…. My use cases on a home network, security and encryption of the disk or secure boot is not even thought about for embedded network devices :) . But then I have an internal network of devices that don’t have access to the internet either. Giving access to the internet for a device, to me, is a ‘huge’ no-no for home automation projects.

  2. My first 8GB RPI5 (plus heatseat, and 5V-5A wall wart) arrived yesterday. Wahoo! Had a USB 2TB T7 ready with Bookworm installed. Booted really ‘fast’ from a USB 3 port. Works great so far. Normally I run my RPIs headless, but for testing the first one, I am using a portable HDMI device/keyboard/mouse.

    Sometime, I’ll have to hook up a PCI SSD adapter. Get the ‘bottom’ version so it is out of sight. Doing that should allow up to three SSD devices directly connected if desired.

    1. And the articles on either side of this one are… Maybe the baby hydraulic jack isn’t a hack, being too well made, but its certainly not an advert.

      HAD certainly could be called an advertisement platform if you really want to view it that way, but in cases like this or that multitool CNC machine its stuff that should interest the HAD audience and that we may not have known existed – and usually complete with benchmarking/review type content that helps validate if the thing is actually good in a way the marketing rich website of so many things probably doesn’t.

  3. Why do you keep writing names in square brackets? It’s usually used for cases like this: ”… so I told her [The President]…” for when a quote is not explicit in who is being referred to. You don’t just go around bracketing every name you see.

    1. This is a local style choice for Hackaday. We went to it becuase so many people have handles that would be very confusing if you didn’t do something to set them off. So, sure, if you say “Jojo built a NAS…” that is easy to understand. But if you say “Random leet hacker built a NAS…” it is somewhat confusing (and there are other handles even more confusing). Compare that to [Random leet hacker] built a NAS. Why we use brackets instead of something like italics, I’m not sure — before my time — but I’m guessing it is so it will render nicely in text browsers, etc.

  4. So is booting from the SSD alone possible or do you need a boot manager on the SD? Also at most we’re only getting gen 2 x1 PCIe, but I suppose if it beats even the top SD speeds and the hat is cheap enough it’s better than nothing.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.