I was just noticing that the Pi5 (and newer Pi4) will boot from SSD if there is no sdCard inserted - oh that looks fun to try when my Pi5 arrives.
2 Likes
That has always been true for the Pi-4, as there has been a firmware configuration flag that allows it to boot direct from a SSD. I believe the flag was already there, it’s just that it wasn’t set to allow booting to the SSD by default, (at first). A firmware “update” made SSD booting the default behavior if a SD card wasn’t present.
In fact, (AFAIK), this capability was baked into the Pi-3 after a certain revision, using a similar flag arrangement.
Certain very early Pi-3’s used a SD card “shim” that would allow booting from a USB device. I might be wrong, but I believe that later version Pi-3’s had the same flag that the Pi-4’s have.
2 Likes
The article I was reading showed Three black dots between the power and video connectors if this is possible.
My Pi4 is encased in a heatsink case so I couldn’t tell if it had the three squares. I used the Pi Imager to write PiOS Bookworm to a spare USB3 SSD and voila it booted it.
USB3 SSD: *******
Raspberry Pi Diagnostics->Run sdCard test: Pass
- show log
Seq write: 218MB/sec (target 10MB/sec)
random write: 6775 IOPS (target 500)
random read: 3213 IOPS (target 1500)
It will be interesting to see if the Pi5 has the same i/o performance.
2 Likes
I will have to try to find the article on how to enable TRIM on SSD’s.
2 Likes
This is a very, very old SSD so I don’t expect TRIM feature will be supported.
2 Likes
I don’t know about that. (links please?)
What I read mentioned a command that allowed you to view and change various GPU/System Controller hardware/firmware flags that were buried rather deeper than the normal boot system commands. According to what I read, these flags and registers are buried rather deeply and require special features to modify them as, if mishandled, they can bork the board.
What I’ve read said that there was a firmware update to the GPU/System Controller chip that enabled this capability by default. Supposedly this flag existed in virtually all Pi-4’s but was defaulted “off” in earlier versions.
I will have to go digging sometime and see if I can find my sources.
1 Like
How old is that?
I don’t remember any discreet transistor logic SSD’s around, and they’d have to be built from TTL 74xx chips, (or maybe vacuum tubes?), to not support TRIM.
2 Likes
Ok - my usual note keeping failed me, so I had to pop the screws:
256MB Crucial mSATA SSD 6GB/s
Markings:
Volume UUID: ADB3E94B…
SSD PN: CT256M4SSD3
SSD SN: 1247035A3D8D
FW: 04MH
CBNFP9Y001
WWN: 500A0751035A3D8D
but I don’t know its purveyance. I think it came in a Toshiba laptop I purchased in 2013.
This is a note I found about Trim on RPi, may be different on Bookworm
https://forums.raspberrypi.com/viewtopic.php?t=245348
But do I need this? I’m just playing around to see if it worked.
2 Likes
-
The chances of that SSD supporting TRIM is virtually 100%. In fact, I would be astonished outta my socks if it didn’t.
-
The discussion of TRIM assumes you want to use an external SSD instead of an SD card as the SSD, even on a USB 2.n port, is significantly faster and more responsive than even application rated SD cards. At least on Pi boards <= Pi-4. (I don’t know about the Pi-5’s SSD speeds, but I expect that SSD’s will still be faster.)
-
Another advantage of SSD’s is the size, especially if you’re going to run a larger image with a lot of ROSx add-ons.
-
Likewise, you can experiment with multiple operating system images at the same time without having to grab out tiny, difficult-to-remove SD cards.
1 Like
Actually, I prefer having a book of “Difficult-to-Insert” SD cards:
I bought the $7 remote SD Card thingy @este linked. Arrived yesterday with my MPU9250 IMU, but have not tried it yet.
3 Likes
But do I need it, if my use case is re-write the SSD image before each use?
2 Likes
TRIM is an important maintainance feature for solid-state media as it helps the internal “garbage collection” routines know what’s fair game and what isn’t.
If you remember, solid state media is organized into three logical groups:
-
Read blocks.
Read blocks are the smallest logical grouping of data. Read blocks represent the physical “sector size” of the flash media and is the smallest amount of data that can be accessed at a time. -
Write blocks.
Write blocks are a very large group of read blocks and it represents the smallest block of data that can be written. If you want to change one byte of data, the entire write block must be read into the SSD’s memory, modified, and then all of the data, changed or otherwise, is then written to an empty, (erased), write block somewhere else. the old write block is marked “discardable” and can be erased when enough other write blocks can be discarded or moved. -
Erase blocks.
An erase block is a gigantic collection of write blocks and represents the smallest block of data that can be erased.
Note that flash memory works like EPPROM memory. Bits can only be written in one direction, (typically they start as all ones and individual zeros are programmed in). The only way to set a zero bit back to a one is by erasure.
In order to erase an erase block, any non-discarded write blocks must be moved and then the entire erase block can be reset to the “erased” state.
TRIM is one way that the operating system can tell the device which blocks of data are no longer valid at the OS level, allowing the controller logic to proactively collect blocks that are candidates for being discarded. If the OS marks a block as “discarded”, the SSD knows that the block doesn’t have to be preserved during erasure.
In fact, the system logic that handles TRIM is the system’s “discardable” capability flag for that media device. If the device supports TRIM, and the “discardable” capability flag is set for that device, the OS can now “TRIM”, (provide discard hints), to the SSD’s controller making discard collection more efficient and reducing wear on the device.
2 Likes
Sorry, a lot of very instructive words but
- “Do I need it?” yes or no please
- If yes, why do I have to muck with systemd rules to set it up?
- PiOS/Ubuntu should set this automatically no?
2 Likes
I don’t know if you “need” it per se, but it is sufficiently important that I highly recommend enabling it if it isn’t already enabled.
As far as automagically enabling TRIM, this feature is usually disabled by default for “removable” media - which represents virtually all the available media for the Pi. (Except for the new Pi-5.)
Since “removable” media on the Pi is used as static mass storage, you have to tell the OS that a particular device that’s attached via a removable media port is actually static mass storage and can be TRIMmed.
You really have to decide for yourself, but it’s something I highly recommend.
Another thing you can do to help reduce wear on a solid-state device like a SSD is to use “hdparm” to send a bulk-erase command to the media. This invalidates ALL the blocks on the device allowing for total erasure.
2 Likes
Note that relatively few SD cards support TRIM, (SanDisk Extreme SSDs do as I remember), as they’re expected to be expendable, temporary media.
Cheaper SD cards might report that they support TRIM, but few actually do.
Virtually none that I have seen support “bulk media erase”, not even expensive ones, though it’s a capability within the SD card’s specification.
1 Like
I like this idea a lot @cyclicalobsessive! You can keep notes and the little tag on the micro SD card is handy. Also, it is a good repurpose of a CD holder (CD what now?..) 
3 Likes
Indeed, but I’m wondering if the label tag makes the micro SD card reader/cable flakey. I have only tried the reader a couple times so far, and amidst a three minute boot time I might have mistakenly thought it was not working.
I need to run some i/o speed tests w/wo the extender, and shutdown/cold-boot a bunch more times to understand if this SD Card is going bad or something else is going on.
3 Likes
I do the same thing with my SD cards because inserting/removing the little beggars is a royal pain - often involving forceps and/or tweezers, potentially damaging the card or the device
2 Likes
One of @cyclicalobsessive’s strong points/strange quirks, is that he measures and documents EVERYTHING! - sometimes to the point of (what appears to be), being totally OCD over it.
But, it’s not necessarily a bad thing.
There have been times when I’ve wondered about the relationship between THIS and THAT on the Pi, and darned if he didn’t have the data!
So!
Keep on obsessing over the data, but don’t forget to have fun too.
2 Likes
Does sound like a game changer. I was often negligent in doing backups just because the card was so difficult to access.
/K
3 Likes