Raspberry Pi M.2 HAT+ here at last with a $12 price tag The Raspberry Pi M.2 HAT+ has finally put in an appearance, allowing Pi 5 owners to connect M.2 M-key peripherals to their computers and take advantage of NVMe drives. It has been a while coming. When the Pi 5 was launched, a prototype HAT+ was shown off. The device provided a bridge from the Pi's PCI Express connector and the …
"We asked the Pi team for a list of NVMe drives tested and will update the piece if we receive a response."
Jeff Geerling has just released a video about the M.2 HAT+. He mentions the drives that he successfully tested with it...
YouTube: It's time to ditch microSD [8 mins, 54 secs]
They used to have images in articles, back when most stories either had a relevant original image or no image at all.
Then they switched to shitterstock / AI and had a policy that every article MUST have an image whether relevant or not, and the pointless AI images were cluttering up the articles, so they removed the image from the article template.
Now, in the once-in-a-blue-moon event where an article actually has a real photo, there is nowhere to display it except in the homepage thumbnail next to all the AI-generated nonsense pics.
Nevertheless, it is easy to get the full version of most pics by removing the resize options from the URL
This post has been deleted by its author
> A 16 GiB SKU would make the Pi 5 a candidate for low-cost desktops for schools, businesses and labs
So - anyone who has been using any of the older R'Pis as a low-cost desktop have just been fooling themselves?
What "low-cost desktop"-class task *requires* 16GiB on an R'Pi? They aren't running full-fat Windows 11! Some light wordprocessing was out of the question for, ooh, the R'Pi 3? Or web browsing to look up Wikipedia[1] to help write that school essay? Or a spreadsheet to record your experimental results as you receive them?
Presumably the inclusion of Mathematica was just there to be a great big tease all those years.
You are probably going to come back and say that the 2GiB R'Pi 3 was in some way " too slow" even though it can actually manage these tasks. Or that you *have* to be able to load up absolutely every desktop program all at the same time, with 30 web tabs open at once, or it "can't really be useful" - in which case, just what is your minimum operational behaviour (not hardware spec, behaviour or ability, if you will) for a "low-cost desktop"?
Ye Gods - my main Windows desktop PC only had 4GiB until a couple of years ago, and I could run VMs (at a satisfactory level to get my job done, thank you very much), do all the text processing, compiling etc etc that I needed to![2]
[1] I know, I know.
[2] ok, I've *now* got quite a bit more RAM and CPU to use it, but then I am not even going to claim that this is in any way, shape or form a "low-cost desktop" - nor do I pretend that it is fully utilised all the time!
People have run full-fat Windows on a Pi.
It didn't work well, and one of the reasons for that is that Windows does not like being booted off an SD card.
Now that this has been fixed, and ARM Windows is a bit more mature, maybe it will work at bit better now?
Gigabytes??
"You lucky, lucky bastard. Proper little jailer's Moore's law pet, aren't we? You must have slipped him a few shekels, eh? Ohh! What wouldn't I give to be spat at in the face have "only" 8Gb! I sometimes hang awake at night dreaming of being spat at in the face having gigabytes."
My 4GB Pi5 and KINGSTON SNV2S2000G 2.00 TB SBM02103 in an Argon NEO 5 M.2 works well:-
Bookworm Light: Linux 6.6.28+rpt-rpi-2712 - Bootloader: Sat 20 Apr 2024 10:53:30 UTC (1713610410)
With pciex1_gen=3: dd if=/dev/zero of=./speedTestFile bs=20M count=5 oflag=direct - 104857600 bytes copied, 0.154623 s, 678 MB/s
I've had a few Pis in the past (and if you ever saw me, a few pies too). Infact, I found the original Pi last night.
However, every project has been abandoned due to the damn SD cards corrupting after 'surprise' power loss, so the final release of the official M.2 addon means I might get back into the Pi game.
Standard SD cards will fail eventually if they do not have global or static wear leveling. If you are putting standard SD card into product you can not easily get to and replace you will be in a world of pain. There are techniques you can use like read into ram then never write which will make a standard SD card last a long time ( based on number of reboots). You could maybe use SPI flash for write storage instead with read and write disturb aware file-system or just use NOR flash with it’s slow erase time.
If you are gong to use a standard SD card then chose one that has android run support A1 or A2 as the flash endurance will make it last longer (like Sandisk).
So the way SD cards fail is that with read disturb multiple reads cause adjacent flash cells levels become harder to differentiate between a one or zero then you get bit flips on reads. These bit flips cause invalid files and file-systems, this makes your PI a bit flaky. If you reformat the SD card the it will be fine but the fact the pi can’t boot makes this difficult to solve remotely. If you are going to put PI in the field running from SD card make sure it has global wear leveling SD card as this is the only thing that can stop read disturb issues, they are expensive for a reason!
> weak sauce USB ports that don't provide enough power other than to drive a mouse and keyboard
Assuming that your PSU can provide the amps, so it really is just your USB ports that are lacing, you can go a long way by rigging a hydra cable that runs the 5V line for your USB drive direct from the PSU's USB 5V line. Or from a 5V pin on the GPIO header. You don't even need to solder, a sharp knife and a piece of chocolate block screw connector will do the job, so long as you aren't going for looks over function.
Depending on the nature of your project you might also consider making the main part of the card read-only. I've got a (very niche) range of industrial controllers built on regular form-factor RPis - I'm setting the ext2fs partition to an overlay filesystem after installation, and using a FAT32 partition to store the config files, which we're not expecting to be written to more than 100 times.
In theory this should avoid the write-wear issues completely, although it's a new design so I can't give a definitive answer on whether this works until about ten years time.
Firmware upgrades of the base OS don't happen. Firmware upgrades of my software stack are done by a startup script that looks for a new version of the firmware on the FAT32 partition and unzipping it before the application starts running. So long as I don't need to upgrade the upgrade script, this is working very nicely.
I also run a bunch of RPis at home and can highly recommend network booting them - this was a a bit problematic with RPi3s (if the tftp server wasn't found when booting - as it would from, say, a power cut - the network boot process would just stop completely and you'd need to power cycle them). RPi4 and later don't have this issue and are stable as rocks. Number of SD cards involved: zero.
I've been running a Pi5 with an NVMe card for a while now.
Pimorini have an expansion card that sits under the board, attached by a ribbon cable.
If you get the longer ribbon cable and some longer stand-offs you can fit a heat-sink on the NVMe stick. Mine is currently running at 30C.
It's only one lane, but will read at 850MB/s.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
