Raspberry Pi 5

[kuru]

Introducing: Raspberry Pi 5! - Raspberry Pi

Announcing Raspberry Pi 5, coming in late October: over 2x faster than Raspberry Pi 4, featuring silicon designed in-house at Raspberry Pi.

www.raspberrypi.com

• 2.4GHz quad-core 64-bit Arm Cortex-A76 CPU
• VideoCore VII GPU @ 800 MHz, supporting OpenGL ES 3.1, Vulkan 1.2 - with open source drivers waiting to be released
• 4Kp60 HEVC decoder but it does NOT support H264 hardware decoding. Software decode will bind CPU resources and use quite some power
• Dual-band 802.11ac Wi-Fi®
• Bluetooth 5.0 / Bluetooth Low Energy (BLE)
• High-speed microSD card interface with SDR104 mode support
• 2 × USB 3.0 ports, supporting simultaneous 5Gbps operation
• 2 × USB 2.0 ports
• Gigabit Ethernet, with PoE+ support (requires separate PoE+ HAT, coming soon)
• 2 × 4-lane MIPI camera/display transceivers
• PCIe 2.0 x1 interface for fast peripherals
• Raspberry Pi standard 40-pin GPIO header
• Real-time clock
• Power button
• The RP1-Chip is an in-house development that has been going on since 2015 and cost over 10.000.000 $. It has 16 Gbps bandwidth and handles all the I/O - including a PCIe slot, for which an M.2 HAT will be made available. The RP1 allows both USB 3.0 to run at full 5Gbps, and both USB 2.0 to run at 480 Mbps. SD card speeds have about doubled in comparison to RasPi 4.
• The MIPI connectors allow connecting either two displays, two cameras, or a mix. Out-of-the-box stereo vision!
• The 3,5 mm headphone jack had to go.
• There are two thru-hole solder points for video out.
• There is a dedicated 3-pin fan connector.
• The power button allows for a clean shutdown.
• Typical power consumption ranges between 3.3 and 8.6 watts. A few sources report spikes up to ~12 amps. A power-delivery-enabled supply capable of 5 V, 5 A will be sold for the Pi 5. EDIT: Apparently the old 3 A power supply can still be used. In that case the USB slots' available current will be limited to 0,6 instead of 1,2 amps.

Release date is late October, price for the 8 GB model is about 80 $, and 60 $ for 4 GB. That is before the scalpers get their grubby mitts on them.
1 and 2 GB versions might become available later.

Raspberry Pi 5 Benchmarks: Significantly Better Performance, Improved I/O Review - Phoronix

www.phoronix.com

A few videos in the spoiler.

Spoiler

Chris from explainingcomputers

Spoiler

Jeff Geerling

Spoiler

David Bombal incl. interview with Eben Upton

Spoiler

c't 3003 (deutsch)

Spoiler

NetworkChuck

Spoiler

I was so close to pulling the trigger on an Orange Pi last night. Glad I slept over it, this is fantastic news. Support and documentation will be so much better for the RPi. And it's mostly made in Britain.

If you find more interesting information, written reviews or videos, post below and I'll add it here.

 

[elw3]

"The 3,5 mm headphone jack had to go."
Wait what, how am i getting audio here?
I was about to get a rpi400. Wonder if they bring that out too with upgraded insides.

 

[kuru]

"The 3,5 mm headphone jack had to go."
Wait what, how am i getting audio here?

USB, HDMI, Bluetooth... but yeah, I'm baffled about this decision. I don't have any BT or HDMI audio. Putting a USB dongle on it is pretty annoying.

 

[pyrat]

I was so close to pulling the trigger on an Orange Pi last night. Glad I slept over it, this is fantastic news. Support and documentation will be so much better for the RPi. And it's mostly made in Britain.

Will it? I thought the bootloader tended to be a blob for the GPU ? Is it usable with 100% free software now ?

 

[kuru]

Will it? I thought the bootloader tended to be a blob for the GPU ? Is it usable with 100% free software now ?

That's very specific. I've never thought about that. Is it different for the Orange Pi?

Edit: I guess there are open source drivers for the Orange Pi's Mali G610

Mali Open Source Driver - linux-sunxi.org

linux-sunxi.org

What are the implications of not having open drivers?

 

[pyrat]

Which Orange Pi ?
Orange pi 5 with a RK3588S ? Last time I checked that needs blobs for RAM init, no source for TF-A and maybe some other blob that I don't remember.
RK3566 (Orangi Pi 3B, Orange Pi CM4) is similar, I think.
Mali should work fine either now or in the future, but the boot chain is compromised anyway.

 

[kuru]

Which Orange Pi ?
Orange pi 5 with a RK3588S ? Last time I checked that needs blobs for RAM init, no source for TF-A and maybe some other blob that I don't remember.
RK3566 (Orangi Pi 3B, Orange Pi CM4) is similar, I think.
Mali should work fine either now or in the future, but the boot chain is compromised anyway.

Sorry, yes I meant the 5.

I think I get what angle you're coming from. I don't care about the "ethics" that much. Are closed source drivers a problem for OS or emulator developers, for optimization?

 

[pyrat]

I think I get what angle you're coming from. I don't care about the "ethics" that much. Are closed source drivers a problem for OS or emulator developers, for optimization?

I don't know. My intuition is that Mali will be easier to work with than whatever there's for Video Core, but I'm not really sure. Maybe there's somethign for VideoCore that I'm not aware off.
From what I know the problem with RK3588/RK3566 is "only" when you want to build you're own u-boot image. That needs blobs from Rockchip that get pulled by the mainline U-Boot. If you care for ethics or (not so vendor trusting) security that's a problem.
Apart from these blobs, Wifi and Bluetooth, you might even get away with linux-libre for RK3588/RK3566, but I haven't tried, and since few people care for these things, there may be gotchas I haven't heard of.
If VideoCore requires proprietary drivers (I think so, but I'm not up to date) that's usually a problem when you wnat to update the linux kernel, or potentitally when you want to patch it.
Maybe have a look at what LibreElec has for each board. They gather patches that work but are not clean enough for mainstream (yet).
Edit. Might be wrong. Phoronix on free drivers for VideoCore VII

 

[TeDaDeS]

USB, HDMI, Bluetooth... but yeah, I'm baffled about this decision. I don't have any BT or HDMI audio. Putting a USB dongle on it is pretty annoying.

I like having a physical audio port. Wasn't there an audio-hat for the Pi to add one if you like, that could work instead of dongle. But still, it doesn't really sound like it was impossible to add the port (but they probably also have a good reason to not add it).

Good upgrade for the NextCloud instance I run, which was working but could use more power. If there is a compute-version of this I can upgrade the Home Assistant unit I got.

 

[Askarus]

"The 3,5 mm headphone jack had to go."
Wait what, how am i getting audio here?
I was about to get a rpi400. Wonder if they bring that out too with upgraded insides.

That is pretty stupid.
Hopefully there will be a version with a bigger pcb.

Tha A76 sounds great however. No more LITTLE only design.

Maybe there should be a MIPI and a headphone jack variant, as most usecases need probable either or.

 

[Risca]

I like having a physical audio port. Wasn't there an audio-hat for the Pi to add one if you like, that could work instead of dongle. But still, it doesn't really sound like it was impossible to add the port (but they probably also have a good reason to not add it).

I always had issues with buzzing and noise on the pi's builtin audio port. The HiFi hats available for the pi have been very affordable and great when I've used them,

 

[kuru]

Added info:
power spikes up to 12 W
old 3 A power supply can still be used, but USB current will be limited to 0,6 vs 1,2 A.

 

[pyrat]

OK, apparently I was wrong. There seems to be some free software drivers for Rapsberry Pi 5 GPU

 

[kuru]

Speaking of LibreElec, I set up Kodi on an RPi 3b+ tonight and I'm delighted at how well YT works at 720p. That is after 2 hrs of fiddling with google's API key site and going through outdated documentation for the YT plugin. Moonlight also works like a charm at least over LAN. Sadly not usable at all over Wifi. I also tried an older build of Lineage OS (Android) but the experience was quite bad.

 

[netcat]

Ever try streaming over NFS? WOW ...

 

[kuru]

^never tried, not my use case

More info: BCM2712 supports HEVC 4K60 hardware decoding, but it does NOT support H264 hardware decoding. That will run on brute force and thus consume a lot of power.

 

[Confuzzled]

For those that want a boot of the Raspberry Pi 5 without binary blobs, there's a slightly confusing post from Gordon Hollingworth (Director of Software Engineering at Raspberry Pi) at Raspberry Pi: News: Introducing: Raspberry Pi 5! : comment 1594066

There still is a bootloader (to do things like network boot, network install, NVMe boot, USB boot, setting up the SDRAM and possible future easter eggs) it is not encrypted or open source (again due to bits of code which are not ours to release). But once we have loaded the kernel and started the ARMs, it’s only job is to monitor and handle clocks and power, and maybe some encryption key handling for encrypted boot or something…


What is different to all previous devices is that it is all contained inside the EEPROM, there is no longer a start.elf or bootcode.bin required to boot.

I guess that in principle, if it is not encrypted, as he says, then the booting code in the EEPROM could be reverse engineered and replaced with FLOSS code. In the past, it was (IIRC) the GPU that initialised the hardware and did 'secret sauce' stuff from a binary blob before starting the ARM processors....ah, these STackExchange answers have a clear explanatory diagram:

https://raspberrypi.stackexchange.com/questions/10442/what-is-the-boot-sequence#10595
https://raspberrypi.stackexchange.com/questions/10442/what-is-the-boot-sequence

So Gordon's comment could be construed as slightly misleading if the Pi 5 does the same: GPU executes non-FLOSS ROM code before executing what is in the EEPROM.

There is a project to replace the capability of the non-FLOSS boot-ROM code:

https://github.com/librerpi/rpi-open-firmware

which is a revival of a previous on-permanent-hold project: https://github.com/christinaa/rpi-open-firmware/

But there are interesting questions raised by the following analysis/work: https://starkeblog.com/raspberrypi/.../2021/12/12/raspberrypi4-eeprom-analysis.html

While I'm very sympathetic towards the idea of removing non-FLOSS software from systems that I'm expected to trust, to a certain extent, it is almost 'turtles all the way down'. Even if all your code is FLOSS, and formally proven to work as intended, you still have the possibility of hardware trojans/backdoors. Few people have their own assured fab. So unless you are a nation-state, or a very rich billionaire, you can't be certain that the chips you buy are not compromised. You end up having to make a risk/reward calculation. You have to set your own border for acceptable risk, and for many, the idea of requiring FLOSS code everywhere is too much trouble for the expected rewards. Personally, I'm glad that projects like libre-soc exist, but past experience shows that they don't seem to get a lot of traction. Most people don't care, and those that do care don't seem to have critical mass. Personally, I think that it will take a nation-state to see the advantages of open-hardware - somewhere like India, Taiwan, or Brazil - and resource building it.

 

[pyrat]

Thanks for the useful info you provide.

For those that want a boot of the Raspberry Pi 5 without binary blobs, there's a slightly confusing post from Gordon Hollingworth (Director of Software Engineering at Raspberry Pi) at Raspberry Pi: News: Introducing: Raspberry Pi 5! : comment 1594066

Well, it doesn't explain much. The code being in EEPROM or SD is not very important.
It's nice that it is not encrypted, but it can still be signed, and I don't know if the bootrom will check some signature. If it does, you won't be able to run your own version even if you manage to reverse engineer.
When he suggests the bootloader can be used for secure boot, that almost implies it's signed, because otherwise an attacker could replace it, just as a tinkerer could.
But secure boot could also be implemented by some read only setting somewhere, ideally with some jumper or switch that could be locally accessible if not physically blocked. So it's not definitive.
That bootloader is likely to also set up memory regions, privileged exception handlers, etc., acting like a supervisor that keeps control even after starting linux, and can turn it off or modify anything if some access somewhere is attempted.
In the PC world it would also typically include transparent network access and OTA updates.

I guess that in principle, if it is not encrypted, as he says, then the booting code in the EEPROM could be reverse engineered and replaced with FLOSS code.

It might be signed. For proper secure boot it often is, and for DRM it practically needs to be (or be physically read only, or only updated after itself checks the signature of the update)

So Gordon's comment could be construed as slightly misleading if the Pi 5 does the same: GPU executes non-FLOSS ROM code before executing what is in the EEPROM.

Yes, it doesn't clarify much to me.

There is a project to replace the capability of the non-FLOSS boot-ROM code:

https://github.com/librerpi/rpi-open-firmware

which is a revival of a previous on-permanent-hold project: https://github.com/christinaa/rpi-open-firmware/

But those are for Raspberry 3 or earlier, right ? At least it's some precedent.

But there are interesting questions raised by the following analysis/work: https://starkeblog.com/raspberrypi/.../2021/12/12/raspberrypi4-eeprom-analysis.html

Not very definitive. They may just have compressed part of the firmware as it got bigger and that's why some strings and functions no longer show up. Or it might be partly encrypted (unlikely?)). OR maybe the reasearcher already took this into account, I don't know.

While I'm very sympathetic towards the idea of removing non-FLOSS software from systems that I'm expected to trust, to a certain extent, it is almost 'turtles all the way down'. Even if all your code is FLOSS, and formally proven to work as intended, you still have the possibility of hardware trojans/backdoors. Few people have their own assured fab.

Sure. Buying any hardware is trusting the vendor. That's clear, hardware can't be easily verified. I think even RMS made it clear that even with open hardware, it was difficult to ensure the design you have is the circuit that was really etched in the chip you got.

So unless you are a nation-state, or a very rich billionaire, you can't be certain that the chips you buy are not compromised. You end up having to make a risk/reward calculation. You have to set your own border for acceptable risk, and for many, the idea of requiring FLOSS code everywhere is too much trouble for the expected rewards.

Yes, but for me the criterium of all replaceable code should be free is good enough. They could give me the source to the bootrom and I still wouldn't know if that source is what's really in the ROM. And backdoors could be in wiring if needed, so you can't avoid trust in the hardware. But then having to trust any firmware updates is unjustified, if you have to trust that you can as well trust windows and forget about free software.
Of course there's very little hardware that fullfills this, but I find it very strange to require the OS to be free but the code that has control over the OS not needing to be.
I find more tolerable to run the nonfree javascript in some web page than a nonfree bootloader. It's a risk, but in theory, if you pinky assume no software bugs, that javascript can't compromise much.
The bootloader can compromise anything and run your OS on a remotely managed virtual machine without you knowing, also assuming no software bug, just bad vendor intent.
But yes, to each its own, and we won't get the freedom we need and deserve whatever policy we choose.

Personally, I'm glad that projects like libre-soc exist, but past experience shows that they don't seem to get a lot of traction. Most people don't care, and those that do care don't seem to have critical mass. Personally, I think that it will take a nation-state to see the advantages of open-hardware - somewhere like India, Taiwan, or Brazil - and resource building it.

Yes.
I lately heard of a talk at EuroBSDCon. It's quite wishful thinking and lacking manpower, but it hits at some forthcoming Power10 board design by Raptor (ballpark 5000€ for a complete computer). And then libresoc and other (expensive) more SBC like designs. Power10 Talos was not possible because the memory bus required blobs, but it looks like some needed info on that blob was released, so that people can now build their own. I think there were other blobs involved, so I have doubts, but I kind of trust Raptor, at least much more than any other vendor, despite prices being high for high specs and high freedom. So, don't hold your breath, but it's nice that there's still someone trying.

 

[Confuzzled]

Thanks for the thoughtful and detailed reply. I had simply forgotten about signing non-encrypted firmware. My apologies.

I get rather irritated about people talking about Secure Boot, as it is usually used as a way of securing the computer against the person who bought the hardware. And, there really ought to be physical jumpers on motherboards that need to be moved to allow firmware updates, with an optional means of leaving it permanently enabled and relying on software control mechanisms to allow remote management.

 

[pyrat]

I get rather irritated about people talking about Secure Boot, as it is usually used as a way of securing the computer against the person who bought the hardware.

100% agreed, but I don't know any other name.

And, there really ought to be physical jumpers on motherboards that need to be moved to allow firmware updates, with an optional means of leaving it permanently enabled and relying on software control mechanisms to allow remote management.

Yes, It is so clear that it makes me more upset when they try to sell me their schemes. Nobody on earth would devise such a complex system where a CPU will hash code and validate cryptographic signatures before even activating RAM when they could just added a DIP switch. To me that make it much more obvious they're evil.

Chromebooks btw, used to have something similar (called "verified boot"?). Maybe not convenient enough and still they usually had too small harddisks, because their idea was users don't deserve to own data or think by themselves, but it was less evil than PCs.
I guess Google can be less evil when they want to enter new markets.
I no longer know what do they have in chromebooks nowadays. Maybe it's still good?