Taking a look at the new Raspberry Pi-5, I am struck by a few things:
In-house silicon, (at least with the design). I don’t think they have their own foundry - but I could be wrong.
This is good because it gets them out from under Broadcom’s thumb regarding access to on-chip resources.
Because the Broadcom on-chip architecture was highly proprietary, it was difficult for the RP design group to get complete and accurate data about the overall archItecture, especially data about the GPU/system controller chip.
Because of this, it was difficult to take advantage of a lot of the advanced capabilities of the GPU without using “blobbed”, (proprietary/obfuscated), code.
It gives them finer-grained control over the overall design.
There are always design compromises and tradeoffs, but with a higher level of control over the silicon, they have better control over where the tradeoffs are.
Increased power consumption.
The Pi-5 appears to want a supply that can source something like 5 amps. (It actually says less, but I want to allow extra for current spikes while running the device.)
That also asks the musical question: How long will the battery last?
Increased power dissipation (as heat).
(A correlary to the increased power draw, or a direct cause if it?)
The Pi-4 recommended active cooling but it wasn’t mandatory.
It appears that the Pi-5 requires active cooling, so much so that an active fan power connection is supplied on the PCB.
Increased vertical size?
It remains to be seen if the Pi-5 can fit the GoPiGo chassis without longer mounting rods.
That also begs the question of the GoPiGo board connector reaching the Pi-5 without an extension connector.
This is finally admitting that the only reason to use a Pi4 or Pi5 is to use more available processing than the Pi3, and tiny passive heatsinks did not even allow the full Pi3 load without throttling.
The only way to use a Pi3 more than 60%, or a Pi4 more than 50%, or a Pi5 more than idle is either a huge, honkin’ heat-sink case (for brief excursions), or active cooling.
In some ways the Raspberry Pi Foundation has fulfilled the maxim I was taught in a “Sociology of Organizations” class I took 50 years ago: “An organization will progress until the major objective is the continuation of the organization”. The RPi Foundation was created to provide an inexpensive computer for education. The RPi2W and the Pi Pico fully met those goals, with the Pi3 extending the education possibilities for artificial intelligence education.
The Pi5 is an organization’s attempt to be relevant in areas better and less expensively served by ChromeBooks and pads. Quite possibly by the time elementary age kids get enough education to be a software developer, the field will no longer be begging for new hires. Lucky if they will find work in software maintenance.
The problem with the Raspberry Pi is that people find uses for it, particularly within the maker space, that were not part of the original idea.
Robotics and ROS(x) seemed to find a marriage made in heaven with the Raspberry Pi, except that ROS was too big for the Pi’s britches, and it kept outgrowing the platform. I even remember the times you lamented the fact that the Pi didn’t have the “oomph” to do the ROS tasks you wanted it to do.
I saw the Pi-1 and Pi-2 as more of a “proof of concept” to verify that the basic idea was valid and to establish if there was enough of a market to warrant continuation of the project.
The various Pi-3 versions and the Pi-4 were attempts to meet a need that was still being defined, and the Pi-Zero was a lower-power version for those projects that didn’t need the heavy-duty hydraulics.
I see the Pi-5 as a logical evolution, and a continuation of their desire to create a “truly Pi-centric” design that they control, without being beholden to 3rd party chipsets.
I don’t see it as a step backwards, or as an attempt to “reinvent the wheel” per se. From a purely software perspective, you might be right - software dev and a basic desktop system is better served by a system designed to meet that need. However, from the perspective of a hardware/software development platform I think the Pi-5 is a logical outgrowth of the progression of Pi based boards.
That it requires a specific OS respin isn’t new. If you remember, the Pi-4 required its own respin, (Buster), and that the Pi-5 requires a specific respin isn’t surprising - especially since there are probably a lot of fundamental architectureal changes under the hood with their custom chipset.
I may not see/agree with the logic, but evolution in computers and software is a distressing fact.
Conical already has a Pi5 certified Ubuntu 23.10 available (which has a promised life of 9 months!), so I could switch my attention to trying to bring the GoPiGo3 software and ROS 2 Humble up on that platform, but I need a break from the bleeding edge.
I have everything I need to work on Dave’s docking hardware, and it would be alot more fun to give ROSbot Dave a 24/7 life like Carl “enjoys”.
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.
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.
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.
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.
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.
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.
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.
How long will the battery last?
