Pi4 to Pi5 migration

On 05/06/2024 17:07, snipped-for-privacy@www.zefox.net wrote: > What's the easiest way to migrate from Pi4 to Pi5? >

The recommended way is a clean install of Bullseye on the Pi 5, but then you get Wayland, Network manager and no rsyslog, and you'll have to sort that lot out.

If the Pi 4 is using a 64 bit version of Buster, you can upgrade in place despite the warnings.

If it is only running 32 bit Buster, then it's a bit more involved.

BTW; a USB SSD, as it will be vastly faster than a mechanical disc for running software. Keep the spinning rust for data.

---druck

Why not use an SD card as the system disk, booting OS + apps and reserve the hdd for data?

The trick is to separate app installation, executables etc, from data. I get that from using Docker containers. It's worth looking at Docker because life is just so much easier, in the long run. Not only does Docker separate exes and data it also tends to script setup/config making changes easier.

Pi5 needs bookwork, which is the one that adds Wayland. The previous was bullseye, not buster

Yes sorry its bullseye to BOOKWORM

---druck

Bookworm can provide also X11. It is the desktop that requires Wayland not Pi5 per se.

I used to do that, before it was possible to boot from USB. There's nothing wrong with it, excecpt that it requires a custom /etc/fstab. Since the appearance of direct USB booting on the Pi3 eliminating the microSD gets rid of one thing that can go wrong.

All the stuff I'll need to carry over from one install to the next is in my home directory, Docker is overkill, I think....

Thanks for writing!

bob prohaska

In light of private comments on bookworm's new "features" it appears that I should set up a bookworm install and play with it some. The existing Pi4 works very well under Bullseye, but it'll get superceded at some point and I'll have to face Bookworm eventually. In principle I like the idea of upgrading from X11, though the actual experience may not be fun.....

One thing I hadn't considered until now is migrating away from RasPiOS to something else. Are there any alternatives that offer comparable support that will run on the Pi5? The biggest issue for me is probably browser support, most other things I do are in terminal windows running shells on FreeBSD hosts (also RPi, but headless). I'm a less-bad admin with FreeBSD, but it does not yet make use of the GPU on any Pi that I know of. AFAIK FreeBSD can't yet boot on a Pi5.

Thanks for writing!

bob prohaska

In this case it's the desktop that I want.

Thanks for writing!

bob prohaska

SD card cards on the Pi3 and before were very slow, but on the Pi4 and especially Pi5 are much faster. I'm now using 64GB high endurance cards from Samsung and SanDisk with 16GB images on them, so considerably over provisioned which will increased their life further.

You shouldn't need to customise /etc/fstab with USB data discs as they will be automatically mounted in /media unless you want them mounted elsewhere.

---druck

There is nothing wrong with Bookworm, you can set it up to work in an identical way to Bullseye and it's predecessors. The problem is the default set up of clean install of Raspberry PI OS's Bookworm is very different to what has has before, and takes quiet a bit of know how to change it back. I found it easier to go against advice and upgrade from a working Bullseye, rather than workout that out.

Other OS's aimed at the Pi are getting better, but Raspberry Pi OS still has the most optimisation on the Pi4 and earlier. It would be very interesting to see where things stand on the much faster Pi 5, where such optimisations may not be so important.

---druck

Mozilla are publishing ARM64 Firefox binaries for Linux now, so that removes the main roadblock to running up-to-date Firefox on other Linux distros that didn't compile it regularly themselves.

I use the PiCore version of Tiny Core Linux, which supports the RPi 5. It certainly avoids all the excessive layers of complexity in RPiOS (and I'm talking from when I gave up on that about four years ago), though there is quite a lot that you need to set up from scratch, and very limited packages available. Probably not what you mean by "comparable support". Other alternative Linux distros are likely better in those regards, maybe Arch Linux?

Yes, I tried Ubuntu on the rPi5 back in December, it wasn't tailored to the Pi. Either the browser support or GPU support was broken, so I switched to Pi OS. That might be fixed now, but there isn't much to be gained by not using Pi OS.

I successfully configured the Pi OS desktop to use Gnome and look like Ubuntu. It took a bit of messing around, but nothing too difficult.

It depends on what you want to do. I have Alpine running on a CM4 that serves as a headless OctoPrint host for my 3D printer. I've not tried running any of the desktop bits because I don't need them in that application. I've run Gentoo on various RPis, but updates can be painfully slow if you don't cross-compile them on more powerful hardware. I might've had Armbian running at one point (or maybe I'm confusing the RPi with other SBCs on which I've run Armbian).

None are going to be as easy to get up and running, but if you don't mind getting your hands dirty, they all have their uses and you'll learn something from the experience. :)

Probably browser performance is the main bottleneck. Far as I know the RasPiOS version of chromium is the only browser that exploits the VideoCore portion of the Pi. Is this still true?

It's been a genuine dissapointment that Broadcom failed to open VideoCore in a useful way. It's most of the Pi's horsepower. Or, am I being unfair?

Thanks to everyone for reading and replying!

bob prohaska

I have Alpine running on a CM4 that

Via Mesa drivers, hardware 3D graphics rendering should be supported in Firefox just like on PC, this has been the case for years. Check the details on the about:support page to see whether Firefox on your RPi has detected that it's available.

Of course it's really a matter of what you mean by "exploits". Even pure framebuffer mode uses "the VideoCore portion of the Pi", so what specific exploitation are you looking for?

I believe Chromium has HW video decoding on the Pi (not sure about encoding), so that's probably what you mean. A quick search for "Raspberry pi firefox hardware video decoding" brings up many results announcing that support was added in Firefox 116. Note that this means it's not available in the current Firefox ESR releases, if you're using them.

If you're talking about video en/decoding, then yes that's a bit unfair because Broadcom have made the APIs for common functionality like that available. Also the Raspberry Pi developers have access to all the secret documentation and development kits from Broadcom, and it's the code that they've written for their fork of the Linux kernel which has become some of the unofficial open-source reference material for talking to the RPi's GPU. As the ones selling the product, traditionally it's their job to submit code to projects like Firefox to help get it supported if they so desire, or fork them like they've done with the Linux kernel. Actually Firefox is apparantly using a Linux kernel interface for this video decoding support, so the RPi developers have up an API as conveniently as possible and left the Firefox developers to take the last step of using it at their end (quite a few years after Chromium, VLC, FFmpeg, etc. did). So you could blame Mozilla too for being so slow. Take your pick.

What Broadcom would enable by fully open-sourcing their GPU code and documentation is that the firmware that these APIs talk to could be expanded as well. Then extra GPU-accellerated functions could be written such as for newer video codecs, or other things entirely. By publishing the documentation for the QPU units in the VideoCore IV GPUs Broadcom did open some doors towards that, but it's not really enough information for a full open-source GPU firmware to be independently developed (there's a project for that with VideoCore IV, but it stalled years ago).

Firefox is Extended Support Release 115.11.0esr(64-bit), installed using apt. There's a checkbox to "use hardware acceleration when available" but no hint whether it _is_ available or in use.

My browser of choice is chromium Version 124.0.6367.73 (Official Build) Built on Debian , running on Debian 11 (64-bit). It seems a bit faster. It also offers a checkbox "Use graphics acceleration when available" without giving a hint of what it's actually using. I do remember that highligting the button caused trouble around a year ago.

Both are up-to-date according to apt.

AIUI a GPU is a coprocessor with its own registers and cache that can do single-instruction-multiple-data operations in parallel with the CPU such as vector math. That's what I _think_ I'm looking for. Compiler enhancements seem necessary, is that the bottleneck?

Aye, there's the rub 8-)

Do other GPU companies (Nvidia comes to mind) handle things any better?

Thanks for writing!

bob prohaska

On the Pi the GPU is a black box, or rather a collection of black boxes inside a black box. There is some ability to launch code on small parts of the GPU (the QPUs) and some limited compiler support for them. But the parts that are used for most of the graphics pipeline aren't accessible - the GPU firmware presents an API and the Linux driver talks to that API, but we don't get to look at or change the software behind the API.

Everyone does it. Nvidia is much worse because, unlike RPi and AMD, they don't even open source any of the software running on the CPU side of things

- both the kernel driver and the userspace components are closed source binary-only. Intel is probably the best in that there's good Linux drivers and some documentation for how their GPU hardware works, which you don't get with anyone else.

(Intel make discrete GPUs. You can plug them in but they don't work on a Pi:

Theo

The hints are all on the about:support page that I pointed you to. To be specific, type "about:support#graphics" in the URL bar and press Enter. There you'll find the specifics of what hardware accelleration is used, or maybe a clue why it's not. You might need to look up the terms used to see how they relate to the specific GPU accelleration you want, but if my guess about your intentions is correct then look at "HARDWARE_VIDEO_DECODING".

Debian package the ESR versions, but you could manually install the Mozilla ARM64 Firefox binaries, though I think currently they're only nightly builds, so the other extreme of stability. Firefox ESR

No the code running on the GPU is all written by Broadcom and Linux software just talks to that, so nothing needs to be compiled for the GPU in order to use functionality that's in the stock GPU firmware. The bottleneck at this point seems to be mainly application developers adding support for the APIs, but this isn't an issue with compilers, just the usual limits of time, money, and willpower.

If you want to do more with the GPU than using the routines Broadcom's firmware includes, such as support en/decoding other video codecs, or using it as a co-processor for non-graphics-related tasks, then free compiler options become limited. That gets complicated, but it's not much to do with PC-like GPU acceleration in web browsers, that is already facilitated by Broadcom's pre-compiled GPU firmware binary which runs on the GPU from start-up (in fact it's what starts the CPU and Linux up).

No, it's unlikely to be in their interest to release documents to help others write open-source firmware for GPUs, because then people could add features and performance improvements to cheaper GPU chips that might reduce the market for their more expensive models. Still the degree of openness varies, overall Broadcom isn't great, but better than Nvidia and no worse than others.

Much the same applies to other parts on the RPi boards like the WiFi/Bluetooth chips which also run closed-source firmware binaries. There are other SBCs that try to use more "open hardware", but the RPis prioritise low-cost ahead of that.

For what it's worth, I moved from Buster to Bookwrm on a Pi4 recently. I really only use it for streaming movies. The streaming services would no longer accept Firefox on Buster. It maxed out at v. 92 if I remember correctly.

I was pleasantly surprised. I couldn't tell you what's different. It just runs quicker and feels more solid on the same hardware. It's a pleasure to see an update require *less* resources. All I care about is getting Netflix, Kanopy, PBS, etc in Firefox. Now that's working better than ever.