Raspberry Pi Catch-All

Raspberry Pi 4 is out!

Broadcom BCM2711, Quad core Cortex-A72 (ARM v8) 64-bit SoC @ 1.5GHz
1GB, 2GB or 4GB LPDDR4-2400 SDRAM (depending on model)
2.4 GHz and 5.0 GHz IEEE 802.11ac wireless, Bluetooth 5.0, BLE
Gigabit Ethernet
2 USB 3.0 ports; 2 USB 2.0 ports.
Raspberry Pi standard 40 pin GPIO header (fully backwards compatible with previous boards)
2 × micro-HDMI ports (up to 4kp60 supported)
2-lane MIPI DSI display port
2-lane MIPI CSI camera port
4-pole stereo audio and composite video port
H.265 (4kp60 decode), H264 (1080p60 decode, 1080p30 encode)
OpenGL ES 3.0 graphics
Micro-SD card slot for loading operating system and data storage
5V DC via USB-C connector (minimum 3A*)
5V DC via GPIO header (minimum 3A*)
Power over Ethernet (PoE) enabled (requires separate PoE HAT)

That's quite the specs for $35/$45/$55 (1GB/2GB/4GB RAM).

Apparently the Pi people put 60% of their pre-production into the 2GB model. I betcha the 4GB model is hard to get for a good long while. I bet that outsells the 2GB model by at least 2 to 1.

I wish they hadn't dropped the HDMI port. Dongles suck. Admittedly, it's only like $3, but it's something that's easy to lose. I have no issue with them adding a second monitor port, that's fine, but I wish they'd kept the primary one as the standard form factor.

It sounds like a pretty capable little system, at this point. You might actually be able to use one as a slightly sluggish desktop. It probably wouldn't even be that painful.

The articles I've read suggest that cooling is a major issue with these. You will probably want to add heatsinks, and you might even consider a case with a small fan. The Pi folks claim that it's only using 1W more than before, but at least one tech reporter is saying that heat is a problem and that they're likely to self-throttle without extra help.

How much of a jump is this in emulation performance over the 3?

So from what others have dug up in the documentation it looks like the Ethernet is no longer sharing bandwidth with the USB bus, but the USB 2 and USB 3 ports share the same bus.

For a dongle-less solution you can get HDMI to HDMI Micro cables.

Ethernet no longer sharing the USB 2.0 bus is some of the best news about the Pi 4.

Malor wrote:

Apparently the Pi people put 60% of their pre-production into the 2GB model. I betcha the 4GB model is hard to get for a good long while. I bet that outsells the 2GB model by at least 2 to 1.

Bet it's the same with the 1GB. The 2GB part is in an odd place between people who will want to play around with the cheap model and people who don't mind paying for more RAM ($20 more is reasonable). Perhaps the thought was to get a big run of those out of the way from the beginning. That would allow them to focus ongoing production on the better selling ones.

Middcore wrote:

How much of a jump is this in emulation performance over the 3?

I don't know any end-users with one yet, but the initial claims are a 2x to 3x overall performance increase. Since the number of physical cores is the same, presumably that's all per-core execution speed, which implies that a Pi 4 will be a much stronger emulation host.

LouZiffer wrote:

Bet it's the same with the 1GB. The 2GB part is in an odd place between people who will want to play around with the cheap model and people who don't mind paying for more RAM ($20 more is reasonable). Perhaps the thought was to get a big run of those out of the way from the beginning. That would allow them to focus ongoing production on the better selling ones.

I think you're probably correct about the 1GB one selling more units, but the way they characterized focusing on the 2GB version was that they expected that one to sell the most.

I think they're going to be quite, quite surprised.

The Retro Pi scene will probably be most interested in the 4 GB model, but 2 should be great for a lot of other uses.

So their web server is running on 18 unit cluster of Pi 4s. Well just the part serving the launch site and the database is running elsewhere as well.

Good to see that the whole "I could make a Beowulf cluster out of THAT." meme is still going strong.

Heh, the Pi 4 kicks the crap out of the machines that were originally being used for Beowulf. Just wrecks them.

USB performance benchmarks:
IMAGE(https://www.raspberrypi.org/magpi/wp-content/uploads/2019/06/2019-06-21-15_42_55-Window.png)

Ethernet:
IMAGE(https://www.raspberrypi.org/magpi/wp-content/uploads/2019/06/2019-06-21-15_43_22-Window.png)

More here.

I/O speed was the most significant bottleneck with the earlier Pis, so that being fixed is major. I haven't actually used one, of course, but I think a Pi 4 4GB might do okay as a desktop. It's not going to knock your socks off, but I think you could actually use one and not mind that much.

Oh, but one possible issue: does the USB data transfer speed include the internal SD card slot? If that's still bottlenecked, then you'll need outboard storage to really take advantage.

Malor wrote:

I/O speed was the most significant bottleneck with the earlier Pis, so that being fixed is major. I haven't actually used one, of course, but I think a Pi 4 4GB might do okay as a desktop. It's not going to knock your socks off, but I think you could actually use one and not mind that much.

Oh, but one possible issue: does the USB data transfer speed include the internal SD card slot? If that's still bottlenecked, then you'll need outboard storage to really take advantage.

SD is controlled over USB, but that's normal for most devices. It still operates over PCI-e which means you should get the full capability out of SD cards. USB will be faster than even U3 rated cards.

EDIT: NOPE... it's 40-45MB/s. See benchmark links below.

I phrased that very(!) poorly.

What I was really wondering is if the internal SD slot is connected to USB3, USB2, or to some dedicated link of some kind. Bringing up USB3 might be more complex, and they might not want to do that for the boot device, so I can easily imagine them sticking the internal slot on USB2 for simplicity. If they did that, then you'd have to use a USB key or an external hard drive to get access to USB3 storage speeds.

Yea the SD card seems like it could be one of the biggest performance hindrances now. Be nice to see them add an m.2 slot to the next revision maybe.

Malor wrote:

I phrased that very(!) poorly.

What I was really wondering is if the internal SD slot is connected to USB3, USB2, or to some dedicated link of some kind. Bringing up USB3 might be more complex, and they might not want to do that for the boot device, so I can easily imagine them sticking the internal slot on USB2 for simplicity. If they did that, then you'd have to use a USB key or an external hard drive to get access to USB3 storage speeds.

Based on the storage benchmarks I've seen, you're right to mention this:

https://medium.com/@ghalfacree/bench...
https://www.cnx-software.com/2019/06...

So it's 40-45MB/s from faster MicroSD cards. Though around double the speed of previous Pi platforms, that's in the realm of USB2, not USB3.

Yeah, and it may split that bandwidth with the USB2 ports, as it's quite possible that all three are driven off a single link.

Hah, don't I feel clever for spotting that. Booting from USB 3 is hard.

So, upshot: if you want really fast I/O, you're going to want a USB hard drive or SSD on one of the blue ports. You may want just enough Linux on the SD card to get the system booted. If you're using it as a desktop, this will probably improve its feel fairly substantially.

The way I'd probably set that up would be by turning the SD card into the /boot partition. On the PC, the obvious solution is to use Grub to boot Linux off USB 3 directly, but if the Pi's bootloader isn't starting that, you'd have to have the Linux kernel available on USB 2 storage. (I think Raspbian sets it up by default this way, with the bootloader and kernel image in a single FAT32 partition at the start of the drive, which is then mounted under /boot. So instead of transitioning to a second partition on USB2, you'd jump to a partition out on USB3 instead, once Linux had launched the USB 3 drivers.)

For a fallback/safety position, you could probably just leave the OS in place on the SD card, with a 'rescue' entry in the bootloader pointing at it. But there's a real danger there. The boot system on the Pi is intricate and fragile, and you'd end up with two OS installs that both thought they were managing the files on the /boot partition. Things could get very, very confused for either or both OSes, to the point that you might have to wipe the SD card and start over, and then do brain surgery on the SSD OS. You'd probably want to set the rescue OS to "hold" all the packages related to booting, but I don't even know what those are.

The command 'rpi-update' might fix most boot problems, however. It seems very sophisticated, and also seems to play nicely with Raspbian's own package manager. You *might* be safe using that command from either OS install, but man, that just feels like a bad idea. Don't mess with /boot from the rescue Linux unless you really have to.

On one of those linked sites it did mention that there was a firmware update in the works to allow booting via USB in the future.

One of the things I really liked about the Pi was its built-in hardware random number generator. It puts out a nice steady stream of entropy, and it's one of the easier ways I know to get access to a HWRNG that's probably trustworthy. (there remain definite questions about the ones on Intel chips.) So I really hope they preserve that feature, I haven't seen anything about it in any of the writeups so far.

I think I'm pretty likely to buy one of these. My Pi 2 died awhile back, and I just have my original Pi 1 sitting there as a DNS/DHCP server. It takes a long time just to run OS updates, so I really wouldn't mind upgrading it, finally. Sadly, the Pi 4 won't be a drop-in replacement, it'll take a new power supply and a new video cable, but at least they're cheap.

Raspberry Pi admits to faulty USB-C design on the Pi 4

tl;dr: they cheaped out building the port. Smart chargers (E-marked ones) will detect that a resistor is missing, and will refuse to supply power to the Pi. The only workaround is to use a stupid charger.

They say that there will eventually be a board revision that fixes this, but it could be awhile.

I didn't know that the Nintendo Switch basically has the same problem. I like USB-C, but between it being used as the connector for multiple communications standards (is it USB 3.1 or Thunderbolt 3?) and companies not following the standard with their ports and other companies making crappy chargers and cables that can fry you devices it is becoming a big headache. My Razer laptop has USB-C (Thunderbolt 3 variety) and I have had issues with a number of adapters that are supposedly compatible not working with it. These days I buy stuff verified to work with Apple products just because they seem to be the most dependable for use with my laptop.

So I finally managed to source one of the new 4s... I got a 4gb model. Initial impression is pretty weak, but I don't think it's the Pi's fault. The drive I/O is extremely slow, but I'd repurposed an old microSD from a music player. Turns out that it's just a Class 4 card, meaning it's glacially slow, and sure enough, the system is incredibly sluggish about loading software. So I'm waiting on a replacement card, which should show on Wednesday.

I think the CPU in this thing is pretty beefy. Scrolling around webpages, once I waited ages for Chromium to load, was smooth and snappy. And the hardware RNG is still there... and even better, the current kernel already preloads a driver, and they're running rng-tools by default. (which keeps the kernel entropy pool stocked up from /dev/hwrng when it runs low.) I used to have to do all that manually, but it's just being handled in current Raspbian.

I think running Debian native on it will end up being a substantially faster solution, because Raspbian has to be compiled to support the really wimpy CPU in the Pi Zero and Pi 1. Debian doesn't yet offer OS images for the 4, because it doesn't have a device tree in the kernel source. Once it does, presumably they'll be able to generate images, which will probably be snappier. I was running Debian natively on my old RPi 2, and it was much faster than Raspbian. The problem was trying to keep the kernel up to date... the guy who'd ported the kernel and generated the image seemed to lose interest in the project. I was able to keep the user-level software stack patched, but wasn't able to update the kernel, so ended up stuck on a really ancient version. Hopefully, a true Debian image will solve that problem.

I'll report back once I've got a decent disk in the new 4. I think it's likely to be a very useful little gizmo, fast enough to actually be an okay desktop.

Huge thanks for the write-up Malor. I'm looking forward to updates! The Pi 4 is on my list as something to mess around with near the end of the year when I get some down time (oh please let there be down time).

Waiting for an official RetroPie update to support the model 4 before I take the plunge.

edit: couple minor typo fixes, nothing new here if this is tagged new to you.

The new card is much better, even on the internal slot. It's not quite snappy, but it's reasonably quick at loading, and would probably be snappy with an external card reader or SSD. I'll try playing with that soon, but it's acceptable, speedwise, on the internal reader.

Normal web browsing is fine, fast and perfectly usable. Youtube is... iffy. In Chromium, it mostly works, but it drops frames and gets a touch choppy. It also fails to buffer the video properly, meaning that you get pauses once in awhile. Further, on one of these pauses, the playback process wedged so hard I ended up having to power the machine off to recover. Trying to shoot processes with kill -9 didn't work, reboot didn't work, shutdown didn't work. The only solution was a hard power off.

So I tried Firefox, and that didn't crash. But it didn't crash because it didn't work; the video playback there was pretty much a disaster. It would usually fail out with an error, but on the rare occasions where it got very far, it would inevitably break apart into color-smeared blocks, become unwatchable, and *then* fail out with an error. Not real impressed. The Firefox in Raspbian is also substantially slower than Chromium on that hardware; they're using the extended service release, so it's fairly old. It postdates the Quantum engine, I believe, but isn't terribly current. If that was being updated, it might work better.

Movie playback is excellent at 1080p. However, Raspbian does not come with an H265 handler in VLC, so H265-encoded movies are just a black screen with sound. The only decoder I see mentioned is in the libreelec distro; they've apparently patched Kodi there explicitly to support the new video chipset in the 4, and reports are that it works well. If your major intended use is as a video client, you probably want libreelec as your OS, rather than Raspbian, or you'll need to transcode H265 files.

It plays back beautifully over a network, too; driving the Ethernet is easy for the 4, it has tons of bandwidth, so just browsing and playing back files on a network share is totally feasible. As long as it's a supported codec, VLC is buttery-smooth at 1080p on the Pi. The patched Kodi is likely to be even better, and reportedly will handle 4k just fine.

The hardware RNG was the only other thing I really tinkered with at all. Oddly, it's slower than it was in the Pi 1. I get transfer speeds of 104Kps on the Pi 1, and I think I got the same on the Pi 2... that's dead and I can't test it now, but I remember it as being identical. On the Pi 4, I get an absolutely rock-steady 67.5KBps. It never changes or wiggles, it just steadily dumps out that many bytes. I presume that they've made internal changes, but the problem is that you never know if they're actually good changes or not. It's slower in the new edition, but is it better?

Slower it may be, but 67.5Kbytes/sec of random data is pretty much a hurricane by kernel entropy standards, so you'd never run out. You'd be able to keep random and urandom thoroughly re-seeded. (btw: use /dev/urandom, don't bother with /dev/random. The numbers aren't actually any more secure and the interface can block. urandom is functionally just as good, and never runs out of new data.)

Overall, this machine is *vastly* stronger than a Pi 1. It's a perfectly competent little server, and seems to be a reasonable desktop as well. It's not flawless, and you're not gonna have as good a time as you would on, say, an x86 Ubuntu machine, but it's not too far from there. And it looks like a dynamite video client. Just... no x265 yet in Raspbian Buster edition, you need libreelec to get that right now.

I just went and read the most recent LibreElec patch notes, and they say they're beta-quality only on the 4B right now. If you use it, they say, be prepared to have issues and to need to submit logs and help troubleshoot.

Part of the reason is because the Pi Foundation is only supporting kernel 4.19 at the moment, where their other distros are up on Linux 5.1. It sounds like proper support for the new video chipset isn't going to arrive until Linux 5.2, and getting everything really up to par sounds like a lot of work; they have to port software to use the new Video 4 Linux 2 pipeline. They also mention "GBM", as in GBM/V4L2, and I haven't even *heard* of that. No idea what that even is.

It would not shock me, at this point, if it takes another year or so before they've really hammered out the Pi 4 as a true desktop environment. It sounds like (and feels like) it's got the horsepower to do it, but the software support just isn't there yet.

At the moment, it's an excellent small server, and you could use it as a Linux desktop if you really needed to, but you'd have a much better time ATM with something Intel-based. That will probably change, but today the Pi 4 isn't all the way there.

Still, it's a neat little box, and particularly if you want a server for your network, you could seriously consider it. Even with all the accessories, buying the whole thing from scratch, it would make a highly capable little Linux server for less than a hundred bucks, only taking about 3 or 4 watts at idle, and no more than 15 under load. And, in a year or so, it'll probably be a very good desktop, too. (If that usage is interesting for you, then picking up a 4GB model would be smart.)

It sounds like it will also be an excellent video client. Right this very second, it does 1080p with most video formats very nicely. (direct video only, though, not Youtube.) Given some time to develop, it should do H265 and 4kp60 with equal aplomb. It can play back from a network share with little effort, because the Ethernet is no longer bottlenecked.

I also expect that Youtube will eventually be fixed, although that could take longer, as the Debian base for Raspbian doesn't change quickly.

It sounds really cool. Although I haven't really touched my PI3 in over a year.

If you're not using the 3 for anything, the 4's not likely to be any better. I use Linux constantly, so having a small box available can be pretty handy, even though I've got a bigger Intel-based one. If nothing else, it's a nice fallback server if the main one is offline.

So I was messing around a little bit with Python benchmarking between my Pentium G3220 (Ivy Bridge, 3GHz), the Pi 4, and the Pi 1. It seems like the Pi 4 is usually around 35-40% of the speed of the Intel chip, which really isn't bad, considering it's clocked half as fast and burns like a fifth as much power. I used some of the brute-force Python scripts I wrote for Project Euler, and one of the bigger ones came back like this:

Pentium G3220: 9.98 seconds elapsed
Pi 4: 32.68 seconds elapsed
Pi 1: 644.26 seconds elapsed (10 minutes, 44.26 seconds)

The Pi 1 was struggling partly because the RAM isn't really adequate for that algorithm: it uses about 350 megs on the Pis, and about 700 megs on the Intel box. I think it was doing a little swapping on the Pi 1, so it's probably not as bad as it looks here. It's slower than a 4, but it's not 21 times slower. (10 times slower, though... maybe.)

The Pi 1 really isn't very usable; I updated it to the current Raspbian version, and it's really slowed down a lot. I consider it painful to work with. The Pi 4 is perfectly fine as a remote server, just about as crisp and fast from the command line as the Intel machine. It's fast enough to do most routine stuff without a quiver... it's only when the big guns are called out that it starts to lag some, but even then it's perfectly usable. It's quite a competent little machine.

Just thought I'd follow up that the Pi 4 is a really excellent little server. In routine remote administration, it feels almost exactly the same as an Intel server. The drive is a little slower, because I'm just using the internal SD card slot instead of an external USB3 reader, but it's absolutely acceptable. It's just barely noticeable as being a hair slower, and only if you're thinking about it.

I did an apt update yesterday, and I was a bit shocked at how fast it went. I'm used to the updates on the Pi 1 as being goddamn glacial, a five- to ten-minute process if anything substantial needs to be done. This time around, there was a bunch of stuff to install, so I alt-tabbed away, and when I tabbed back a minute later to check on it, it was already done. The installs just flew by. With a USB3 SSD, I think it might not even be detectable as a non-x86 box for routine tasks.

The desktop is still not really there yet, and may not be for quite awhile. But if you're looking for a cheap and surprisingly powerful little Linux server, this offers a lot of what you'd get in an Intel NUC, enough that you might not care about the missing features. (like no SATA.)

A Pi4 won't be a good NAS box, but for other server duties, it's excellent. This is the first Pi I've had that's genuinely a pleasant experience to remotely administer.

So, of course, as soon as I said something nice, it bit me. I'd rebooted it right around the time I posted that, and didn't realize that the machine didn't come back up. It took me awhile to diagnose the problem and wend my way to a solution: the power light was flashing four times, and that was it. I was worried it was bricked, and I hadn't mistreated it at all.

So it took me about 30 minutes to dig through websites until I finally figured out the actual problem: it wasn't able to load start.elf anymore. So I took the SD card over to my Intel server, mounted it there, and looked in the /boot dir, and sure enough, there was no start.elf in there. Somehow, it got deleted.

I thought I was going to have to reimage it, but then I remembered that I had a backup of the system on the slow SD card. Popped that in, and it booted right up. So then I tried to mount the fast card so I could copy files over and... nada. Nothing. The system gave me no message *at all* when I plugged in the USB reader. Normally you get some dmesg lines telling you what disk a new device is, but I got absolutely nothing, even though the reader was lighting up and flashing normally. Everything looked fine, both electrically and in terms of visible behavior, but the disk wasn't visible in Linux. There was no hint that a plugin event had even taken place.

So this was annoying. I ended up taking the card back to the Linux box again, and copying over the 'start4.elf' file. Took it back to the Pi... kernel panic. Took it back to the Linux box, added in all the 'start4' files I could see. Back to the Pi... kernel panic. Back to the Linux box, copied in a bunch of 'fixup4' files. Brought it back to the Pi, and it finally booted normally. Phew.

But now it wouldn't recognize the old card when it was plugged in either, and I got to thinking about this. The Pi is using 'partuuids' for all its mounting, and I wondered if that was related. So I did a bunch of searching on what disk UUIDs were, and was constantly pulled into long discussions of filesystem UUIDs, which wasn't what I needed.

Turns out disk UUIDs are a thing, but only on GPT disks. I tried using gdisk on the Pi's card, and it wasn't GPT, it was regular old MBR. So now I'm off to figure out what the heck UUID means on an MBR disk.

So that turns out to be the "disk signature" thing you might remember from Windows. Each disk gets a unique 32-bit value, apparently at random, and Windows will not use two disks with the same ID. Neither, as it turns out, will Linux, at least in this context. A PARTUUID for an MBR disk is constructed by concatenating that 32-bit value with an -01 for the first partition, an -02 for the second partition, and so on. This is how the Pi specifies all its boot files... not by filesystem UUID, but by PARTUUID, which really doesn't work that well with MBR. I'm not sure why they went this way, and it's awkward.

So I figured out how to change a disk signature in Linux; you use fdisk, type x for expert mode, and type i for ID. The number you type in can't be a hex value, as it turns out... unless you prepend it with 0x. So I finally got that sorted, and updated the cmdline.txt file with the PARTUUID, and then edited the fstab in etc as well, so that all three lines were pointed to the new value.

And voila, that disk is now recognized when plugged in a USB3 port, and the Pi will boot from the edited SD card as well.

That totally invisible failure when a PARTUUID is duplicated is really, really odd. This might not even be a Pi problem, this might just be a Linux misfeature.

Anyway, my final upshot on this is that you may want to keep a backup boot source. At least briefly, they were apparently giving out a bad system update that wiped ten or twelve critical files out of /boot. If you don't have another Linux box available, you will need a backup SD card or you're dead in the water. And make sure you don't just DD the backup, either, because if the PARTUUIDs are the same, you can't load your main system card. You can't even see it's attached to the system, and can't edit its signature. You'll need another machine to do that, and then you'll have to fix cmdline.txt and fstab.

I did a full update on the old card, once I had the new one working, and I was not able to duplicate the bug, so if it was a bad system update, as I'm assuming, it's been fixed.

Still recommend a backup card if you don't have another Linux machine. And fix the UUIDs before that bites you.