Just as I did in the last post for my Raspberry Pi 3, I installed the legacy version of Raspberry Pi OS, or Raspian, onto the Raspberry Pi 2. I did spend about an hour installing the recommended 32-bit version of Debian 12 based Raspberry Pi OS, but determined that while it would boot, its operation was choppy at best. I then dropped back to the Debian 11 based Raspian and discovered that operation was a lot smoother and faster all around. This was surprising because it has a 900MHz quad-core ARM Cortex-A7 CPU and 1 GiB of DRAM. This is significant because, with Debian 11 Raspian installed, I found little performance difference between it and the Raspberry Pi 3 I was working with earlier. This is a good thing, actually.

Once again I tweaked swap to set it at 2 GiB instead of the default 100 MiB. Other than that, everything else is stock out-of-the-box. What was interesting is how the CPU clock was being managed to drop below 900 MHz. The btop view above shows it idling at 600 MHz. I’d forgotten that early Raspberry Pis used to do this. Just for documentation sake, here’s a raw dump of /proc/cpuinfo.

Some words of warning if you’re going to use the Raspbian legacy image. While you can configure the image in advance for the host name, user, user password, and WiFi SSID and its password, it appears that some settings for the US (where I live) were incomplete. I learned on the RPi 3, and on this RPi 2, to go into the configuration utility and set localization to US, and to pick UTF-8 as the encoding standard. The default is some Latin standard that creates a mess when displaying fancy ASCII text on the terminal screen.

If you think that the Raspberry Pi 2 model B is obsolete, Raspberry Pi Foundation states on its web page that it will remain in production until January 2026. It’s not dead yet, and neither is the RPi 3 B (January 2028) and the RPi 3 B+ (January 2030). Tremendous untapped capabilities in all those “old” boards.

Links

Raspberry Pi 2 Model B — https://www.raspberrypi.com/products/raspberry-pi-2-model-b/

Raspberry Pi 3 Model B — https://www.raspberrypi.com/products/raspberry-pi-3-model-b/

Raspberry Pi 3 Model B+ — https://www.raspberrypi.com/products/raspberry-pi-3-model-b-plus/

Once all that was done and the RPi 3 was booted, I did a bit of housekeeping to tweak things to my personal tastes. I was quite happy with the much snappier performance of the RPi 3 under the 32-bit bullseye-based version. I tried to install fastfetch, but it wasn’t in the legacy repo, so I fired up chromium and downloaded a version compiled for the arm7l architecture which the RPi 3 was running as.

I always create a bin directory in my home folder to hold tools I will only run when I’m logged in. I add that local bin to my path as well. That’s where I unpacked fastfetch to. You’ll note that we are indeed running under Raspbian based on Debian bullseye. This is far more advanced than the version on the board when I put it away years ago; Raspbian based on Debian stretch. You’ll also note I bumped the swap space from the default 100 MiB to 2 GiB. Here’s an image of why that’s so important.

With the system booted and running, with three open terminals of which one was running htop, and Chromium up with only one tab pointed at the Raspberry Pi Sense HAT documentation, swap had already hit 139 MiB. Exhausting swap is a guarantee to crashed applications and a system that is so sluggish as to be for all practical purposes locked up. I’ve already documented how to fix this in the first attempt to resurrect this board, link at the bottom. I decided to only expand swap to 2 GiB instead of 4, just to see if I actually needed to. Turns out I didn’t need 4 GiB, and I probably could have even defined even less, such as 1 GiB.

Once the RPi 3 was up and stable I added a few things to the environment to make it more to my liking. I added the Nerd Hack fonts, and set the shell to use them, then I installed the Rust compiler and tool chain. From there I used cargo to install eza, a more sophisticated ls, and bat, a much better cat alternative. The shell above shows the results of using the Nerd Font and eza via an alias for ls. I show this because one of the first major tasks was to get the Sense HAT operational, and for that I installed the sense-hat package.

I point this out because if you follow the instructions for the Sense HAT documentation, the instructions have you install the sense-hat package, then Octave, then go through the steps of calibrating the sense hat. This left me with the erroneous assumption that the calibration software was a part of Octave, which it is not. You do not have to install Octave to work with the Sense HAT. The instructional also state that the result of the calibration, the file RTIMULib.ini, is in two locations, one of which is under ~/.config/sense_hat. There is no ~/.config/sense_hat folder created.

The RPi 3 is now operational enough I can begin to seriously think about using it for headless and unattended operation somewhere around the house. I’ve yet to determine a specific task, but it’s ready for the next step. I intend to install Cockpit on it, as I have with several other Raspberry Pis in my household. If you want to see Cockpit in action, just a teensy bit, here’s two screen captures of it in operation using Chromium on my Raspberry Pi 5 to look at the remote Raspberry Pi 4.

I have a Raspberry Pi 4, 2 GiB, running unattended and headless running Pi-hole. Rather than have to ssh into the system, I installed Cockpit with its much better web-based interface. Most of the time I live in the console.

Right now I have disabled Pi-hole because an update came down the pipes and caused all sorts of screwy issues. That was sometime last year, and I haven’t felt the need to go in and sort it out, including (possibly) a complete re-installation of Pi-hole itself. Of note is the low memory footprint of bookworm, which is what you can get when you’re not running the graphical desktop. That is basically what I’ll do with the RPi 3, which is disable the graphical desktop and install Cockpit on it to manage it remotely.

The final question that needs to be asked is why? Because I have all this incredibly capable computing resources that are literally sitting in a corner doing nothing. I turned 71 last December, and I need to add as much automation to my household as I possibly can to help me and my wife live independent quality lives. I want a household automation system that I control and doesn’t depend on the “cloud.” I don’t want to wake up one day and read that my home devices will no longer work because the company that sold me those devices is going out of business and bricking all my expensive devices. I just won’t put up with that.

Links

Cockpit Project — https://cockpit-project.org/

Pi-hole — https://pi-hole.net/

Rust — https://www.rust-lang.org/

eza — https://github.com/eza-community/eza/

bat — https://github.com/sharkdp/bat/

attempting to restore an old raspberry pi

This particular Raspberry Pi is unique in that it’s also the one I first installed Arch Linux on, and then Raspian (well before it was renamed Raspberry Pi OS). It still had Raspian installed, and when I powered it up it still booted and ran. But I wanted to install the current Raspberry Pi OS on it and try to get everything working on top of an up-to-date software platform. And so I did, and that was an interesting “learning experience” that got me wrapped around the axle a bit, to the point I still haven’t done anything with the Sense HAT.

Note that this is the current release of Raspberry Pi OS at the time this post was written. Also note that this Raspberry Pi was limited to 907 MiB, a little less than the 1 GiB of memory soldered to the board. The reason for the memory haircut down to 907 MiB is because it’s being used as the graphics buffer for the video display.

I managed to get btop installed and to get it running so I could keep an eye on how the RPi 3 was behaving. You should now note that I have defined 4 GiB of swap space on the board (look in the disks box). When Raspberry Pi OS is installed “out of the box,” it’s configured with only 512 MiB of swap space total. It didn’t take much work with the default swap space to have applications crash out due to memory and swap exhaustion. Once again I had to edit /etc/dphs-swapfile to get my 4 MiB of swap.

# /etc/dphys-swapfile - user settings for dphys-swapfile package# author Neil Franklin, last modification 2010.05.05# copyright ETH Zuerich Physics Departement#   use under either modified/non-advertising BSD or GPL license# this file is sourced with . so full normal sh syntax applies# the default settings are added as commented out CONF_*=* lines# where we want the swapfile to be, this is the default#CONF_SWAPFILE=/var/swap# set size to absolute value, leaving empty (default) then uses computed value#   you most likely don't want this, unless you have an special disk situationCONF_SWAPSIZE=4096# set size to computed value, this times RAM size, dynamically adapts,#   guarantees that there is enough swap without wasting disk space on excessCONF_SWAPFACTOR=2# restrict size (computed and absolute!) to maximally this limit#   can be set to empty for no limit, but beware of filled partitions!#   this is/was a (outdated?) 32bit kernel limit (in MBytes), do not overrun it#   but is also sensible on 64bit to prevent filling /var or even / partitionCONF_MAXSWAP=4096

Lines 16, 20, and 26 are the lines I modified. So with those modifications I managed to keep more applications up and running, although not very many. As you can see in the btop capture, I’d already reached 658 MiB of swap used, and that was with a web browser (Chromium in this instance) and several terminal windows.

Speaking of web browsers, I tried three on that combination of hardware and software; Firefox, Chromium, and Gnome Web, a.k.a. Epiphany. Of the three I discovered that Gnome Web was the worst, consuming the largest amount of swap, and that it crashed far more than Firefox or Chromium. All I wanted was a web browser to be able to search for and read documentation for certain problems I was encountering while working with this setup. Gnome Web was the least helpful in this regard.

I also had to change from using Wayland to using X11 as the desktop engine. The primary reason for the change is that there are no working screen capture tools under Wayland, but more than a few for X11. After switching to X11 I installed gnome-screenshot (bit of irony there considering how bad Gnome Web was), which allowed me to capture specific application windows for documentation purposes.

After spending far more time than I should have tweaking the constrained environment, I tried to install GNU Octave, because that’s what the Raspberry Pi Sense Hat documentation calls for. There’s a tool in the installation for calibrating the various sensors on the Sense HAT. What I discovered is that the version of GNU Octave is still at 7.3.0, while the version you can get off the Octave website is 9.3.0. I managed to install a more up to date version of Octave via flathub, version 9.2.0;

I opened the application and discovered that it’s quite fast in that environment, amazingly so compared to either Chromium or Firefox. Since this is from the flatpak, I need to investigate how to get the calibration tools out of the flatpak. I have the Octave flatpak installed on my Linux Mint system so I’ll investigate there rather than on the Raspberry Pi 3.

And that’s about it for the moment. I am wondering if I should install the light weight 32-bit version of Raspberry Pi OS onto the Raspberry Pi 3. After all, Raspbian was 32-bit on RPi 3. Or maybe I should put the Sense HAT on a 1 GiB Raspberry Pi 4 I found in my collection and install 64-bit Raspberry Pi OS on that. Decisions, decisions…

Links

Raspberry Pi Sense Hat Documentation — https://www.raspberrypi.com/documentation/accessories/sense-hat.html

GNU Octave — https://octave.org/

Today’s Ubuntu 23.10 updates included kernel updates. Once the update completed and the Raspberry Pi 5 was rebooted, the SPI devices were fully operational. I ran a test example from luma.led_matrix ( https://github.com/rm-hull/luma.led_matrix ):

$ ./matrix_demo.py -n 4 --block-orientation -90Created deviceMAX7219 LED Matrix DemoFast scrolling: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.Slow scrolling: The quick brown fox jumps over the lazy dogVertical scrollingBrightnessAlternative font!Proportional font - characters are squeezed together!Tiny is, I believe, the smallest possible font (in pixel size). It stands at a lofty four pixels tall (five if you count descenders), yet it still contains all the printable ASCII characters.CP437 Characters

Believe me, everything worked with the HiLetgo four-character 8×8 matrix display (see below for details). I’m so happy to finally see this fix land.

I’m including the Raspberry Pi 5 wiring diagram and a picture of the HiLetgo MAX7210 Dot Matrix Module I used for the test. With the latest update to Ubuntu 23.10, everything works as expected.

Unless you have a very specific use case that absolutely requires you use Raspberry Pi OS on the Raspberry Pi 5, then install and use Ubuntu 23.10 exclusively for the Raspberry Pi 5.

I’m still trying to love Raspberry Pi OS and its LXDE-based window manager, and it’s just not happening. I’ve tweaked some things, even going so far as to pull a screen wallpaper from Linux Mint Uma (mikeu_red_waves.jpg); that seems to make the overall desktop experience a bit better for me.

I tried lxappearance to change the desktop. That application opened but I couldn’t change anything.

I then switched from Firefox as my default browser to Chromium because in spite of what was claimed, Firefox is still a hot mess and slower on Raspberry Pi OS than Chromium. I found Chromium a better browser experience than Firefox; Chromium is now my default browser.

That desktop screen capture you see above was taken with grim, a command line tool that is absolutely primitive to use and the only screen capture tool I found that worked. No other screen capture application will work because of the shift from X to Wayland. Basically it’s an all or nothing type of tool. If you want a specific section of the desktop, then you edit the full screen capture with another primitive graphics editing tool to whittle away the extraneous parts. For this post the full desktop was sufficient and required no further post processing.

After flipping back to Raspberry Pi OS and regretting the decision almost immediately, my intent is now to flop back to Ubuntu 23.10. For anything needing SPI support I’m going to move it over to one of my numerous microcontroller boards, such as one of the ESP32-S3 development boards. I can either code something in C++, or drop MicroPython on it. There’s a certain irony in doing a write/port to MicroPython as it won’t work with regular Python 3 under Ubuntu 23.10. But everything else works, and I might even cobble something together to use Bluetooth to communicate from the Raspberry Pi 5 to the ESP32-S3 hosting the MAX7219/1088AS displays. That sounds a lot more productive and a lot less frustrating than trying to beat Raspberry Pi OS into shape.

Yep. That’s my plan.

It bothered me quite a bit that my last few schematic diagrams were missing the 8×8 LED matrix display. As it turns out, the part number for the 8×8 LED display is printed on the side: 1088AC. When I went looking for any part sheets for it, all I found was a single page with this printed on it

It was a PDF with a copy of a copy of the circuit diagram. I could barely make out the column, row, and physical pin numbers. I then went looking for an open source KiCad part for the 1088AC and found one on GitHub, which I forked and then cloned from my fork. I was able to quickly ascertain that the part was designed for KiCad 6. From there I used KiCad’s part library manager to import the part and then convert to KiCad 7 format. I had to do a bit more work with it before I could use it. For example, all the LED symbols were reversed, pointing up (as common anode) instead of down (common cathode). A little work to select and flip each diode symbol took care of that. I also change all the row pins from input to output, as they were all defined as input.

I am aiming to order a dozen or so MAX7221 parts from e-bay. The MAX7221 has a few additions internally over the MAX7219, one of which is that it support QSPI format data communications. Same price as the MAX2719, same pinout.

What’s interesting about the MAX7219/MAX7221 part sheet, it mentioned on the front page that it was suitable for LED matrix displays, but all the circuit diagram examples only show seven-segment by eight character displays, such as the one on the right above.

More learned with KiCad 7; better control with the schematic diagram, the ability to import parts, and the ability to convert from KiCad 6 to KiCad 7. When I’m finished with the 1088AC KiCad drawing part I’ll update my GitHub version and post a link to it in another post.

Links

My copy with updates and migration to KiCad 7. Note that only the 1088AS part has been updated. — https://github.com/wbeebe/kicad-LED_DotMatrix

You’re looking at a very simple circuit diagram, where I’ve wired a HiLetgo MAX7219 Dot Matrix Module to the Raspberry Pi 5 via its 40 pin connector. In spite of the add for the module on Amazon (see below) it works just fine with the Raspberry Pi and a Python library, Luma.LED_Matrix, I found on the web (see links below).

All I wanted to do was hook up one of these inexpensive four-character modules to a Raspberry Pi 5 and scroll text across it using Luma.LED_Matrix. It does not work with Ubuntu 23.10. It works just fine with the latest release of Debian GNU/Linux 12, a.k.a. Raspberry Pi OS. The problem is that Ubuntu 23.10 does not enable the SPI kernel drivers. Raspberry Pi OS does.

The screen capture above shows what the SPI devices will appear as in the dev file system if the kernel drivers are properly configured for the SPI peripherals. When you try this on Ubuntu all that is shown is /dev/spidev10.0. The other two devices are missing.

There’s not much more to say at this point except I am extremely aggravated to have to back down to Raspberry Pi OS. Ubuntu 23.10 is a gorgeous UI and a highly performant distribution on the Raspberry Pi 5. Getting it set up was no different than on an x86-64 system, and once set up was indistinguishable from normal Ubuntu. All the tools worked, especially Visual Studio Code, and I was developing command line tools written in Rust. It was a breeze doing anything non-trivial. Until I tried physical computing, at which point Ubuntu’s limitations in those areas became evident.

It’s not a problem to physically switch between operating systems. I just don’t want to, and based on my experience so far with Ubuntu 23.10, I will be dragged back kicking and screaming to Raspberry Pi OS on the Raspberry Pi 5. As soon as I can come up with a good solution to this mess, I’ll post it.

Links

Luma.LED_Matrix — https://github.com/rm-hull/luma.led_matrix

moving back to raspbian 64 bit, dropping work on wiringpi

Update 4 March 2024 — Ubuntu 23.10 is finally fixed

As noted in a link at the bottom, Ubuntu 23.10 finally supports the SPI devices on a Raspberry Pi 5, meaning that all hardware I need supported (I2C, SPI, GPIO) appears to be fully functional when running Ubuntu 23.10 with all the latest OS and kernel updates. There is absolutely no need to install Raspberry Pi OS, formerly known as Raspbian, on the Raspberry Pi 5.

Update 9 January 2024 — That Didn’t Last Very Long, Did It?

I am flopping back to Ubuntu after having flipped back to Raspberry Pi OS. I just could not stand the loss of power and convenience I experienced with Ubuntu, but not with Raspberry Pi OS. They should rename Raspberry Pi OS to Raspberry Pi Mess.

Update 7 January 2024

I have decided, for the second time (the first being back in 2018 with Ubuntu 20.10, see link below) to move back to Raspberry Pi OS (formerly Raspian) because the SPI subsystem isn’t installed/doesn’t work. I’ve tried everything I know, including slumming through the various fora and as well as searching on the web to find a solution to make it all work. It won’t. So as of right now I’m back on Raspberry Pi OS so I can get back to the reason I purchased my Raspberry Pi 5 board, interfacing with external hardware.

I put this in because of the insane number of hits on this post over the last few days. So be warned. Ubuntu 23.10 is very pretty and very nice as an OS, especially compared to the current Raspberry Pi OS, but it’s still missing critical support for some key Raspberry Pi 5 hardware subsystems. It’s a shame, really. I would have loved to stay on Ubuntu.

Original Post

After receiving two copies of the latest Raspberry Pi 5, I finally installed two different operating systems on 128GB SanDisk micro SDXC cards and booted up one of the SBCs.

The first OS i tried was the recommended Raspberry Pi OS built from Debian 12 for 64-bit ARM. I used the basic desktop. Once it booted up on the RPi 5, it ran quite well. Compared to how it runs on the RPi 4, execution of the operating system was highly performant, and all actions such as starting an application or moving or resizing windows was absolutely smooth with no discernible lag whatsoever.

The problem was trying to do any work with that operating system. As has been noted and warned about in other stories, not everything has been fully updated on Raspberry Pi OS for the RPi 5. I ran into one such problem when I tried to perform a screen shot with the utility scrot. I’ve used it before on older versions of the operating system without any issues. This time scrot simply created a black image when it was run. There were some other issues, but that wasn’t the real reason I left it. No, Raspberry Pi OS is still the limited environment it’s always been going back to the Raspberry Pi 3. I’m spoiled for choice these days, and all the other Linux distributions are polished and provide a solid user experience. Raspberry Pi OS is falling behind in that department.

The second operating system I tried, and the one I’m writing this review on, is Ubuntu Desktop 23.10 for Raspberry Pi 5. It is as easy to download and copy to another SDXC card. It booted up almost instantly, even the first time. Once up and running it looked and felt like an Ubuntu installation on every other personal computer I have it installed on, and that’s a significant advance for this distribution. Every other time I’ve tried to install and run Ubuntu, it’s been so slow that I had it off my Raspberry Pi 4s within 15 minutes. This time, it’s on to stay.

There is one odd feature of Ubuntu on the Raspberry Pi 5. I have the official active cooler in place, and it has a tiny fan in it. Under Raspberry Pi OS it would occasionally turn on while I was using the desktop. Under Ubuntu 23.10 it’s on all the time and running at full RPMs. While it’s loud enough that I can hear it from where I sit, it’s not too loud, more like background white noise, but noticeable. I would note that the CPU temperatures have been in the upper thirty degree centigrade range with Ubuntu. Under Raspberry Pi OS the CPU temperatures where 20° C higher. The choice in this case is I can compute in near-silence with Raspberry Pi OS or run a lot cooler, but a bit louder, with Ubuntu.

I might give Fedora 39 a quick test to see how it works, but if I don’t, running Ubuntu 23.10 is an excellent user experience on the Raspberry Pi 5.

Links

moving back to raspberry pi os on the raspberry pi 5

ubuntu 23.10 finally supports spi on the raspberry pi 5

I’ve placed several Raspberry Pies around my house, and they’re all headless. That means no attached screen, keyboard, or mouse. In the past when I set up a headless system that meant logging into them via SSH. That was OK, but there were times when I wished for some bit of a graphical desktop. Then along came Cockpit.

Cockpit ( https://cockpit-project.org/ ) is a web-based graphical interface for remote system management, whether it’s sitting somewhere else with a screen, keyboard, and mouse, or else it’s a headless system away from you. Cockpit is an installable package for just about every Linux distribution under the sun, including Raspian. You can follow the setup and operational directions at the Cockpit home page.

Cockpit’s very complete and is capable of giving you, the remote user, complete insight into a remote system all within your browser of choice. I can’t speak to all browsers, but I’ve tested it with Firefox (this example is running on macOS Catalina and a 2012 Mac Mini Server), Chrome, Safari, and Vivaldi. When I do use Cockpit I always leave it open on the terminal.

The terminal page in Cockpit is a full-blown terminal. I haven’t found an ASCII application or tool yet that I couldn’t run within that terminal. That includes complex tools such as htop and btop. Since I’ve been using Cockpit, I’ve had no need to ssh into the system.

First thing to note is that the last time I logged into the Pi was back in June 2020. As soon as the Pi powered up and I logged in I tried the usual sudo apt update && sudo apt upgrade dance. And it failed. To make a long story short, I did manage to do a full upgrade to the latest 64-bit version of Raspberry Pi OS, the version built with Debian 11/bullseye. But it was seriously squirrelly in operation.

I backed up the pi account and development areas from the older card to a thumb drive, downloaded the latest image from  https://downloads.raspberrypi.org/raspios_arm64/images/ , performed a clean install of Raspberry Pi OS 64-bit using balenaEtcher ( https://www.balena.io/etcher/ ) onto a Sandisk Extreme 128GB micro SDXC card, rebooted with the new card, then copied everything back over, and carried on from there.

In the middle of doing all of that I took some additional time to try a few new distributions aimed squarely at the Raspberry Pi 4. They were Ubuntu 21.10 for IoT, Fedora 35 for IoT, and Pop!_Pi for Raspberry Pi 4. Here’s what happened with each to keep me still on Raspbian.

1. Ubuntu 21.10 for IoT was perhaps the cleanest install of the three. It was no problem to flash and boot into Ubuntu. The critical feature on boot is for the OS to automatically resize the boot partition. Raspbian does it, and so does Ubuntu for IoT. My problem with Ubuntu on the RPi 4 8GiB is sloppy performance. At one point I attempted to drag-and-drop an application icon onto the Ubuntu dock. It’s a habit I developed using macOS and Windows (10 and earlier). Under Ubuntu you have to right-click on the app icon and select on the resultant menu to add the icon to the dock. My drag-and-drop attempt locked the Ubuntu desktop up solidly. After waiting a few minutes to see if it would ever come back, I pulled power and then the card and wiped it clean for the next experiment.
2. Fedora 35 for IoT wouldn’t boot into a graphical desktop. I have a feeling that Fedora 35 for IoT hasn’t a decent driver to use my LG 34UM61-P, a 34″ diagonal 21:9 UltraWide® monitor. All the other distributions can find and use this monitor, but apparently Fedora 35 for IoT can’t. Once again, wipe and reload.
3. Pop!_Pi for Raspberry Pi 4 was an interesting alternative I hoped would work out. It booted just fine, had reasonable performance, but it lacked one vital feature. It currently won’t resize the boot partition and it has no tool like raspi_config to allow you to manually do it yourself. I liked the way it looked and worked. I would have loved to have kept it, but it was not to be.

I’m back to doing some personal work on the current Raspberry Pi OS. The tools are up-to-date, especially Python3, and Python2 is not completely gone. I’ve got the last Go and Rust, and between those three I’m keeping busy. In fact, right now I’m moving all my little Go work over to modules. So far I’ve not hit any roadblocks. Once done I’ll check that in, and then move on to more physical computing.

On several occasions I’ve written about moving from Raspbian Buster 64 bit to Ubuntu 20.10. I was never completely comfortable with using Ubuntu 20.10 on a Raspberry Pi 4B, not even the version with 8GiB of RAM. But I stuck with it because I thought it would reward my usage over time, with fixes and updates. That all disappeared when I tried to run my physical computing tools under Ubuntu.

I wrote all my tools with Google’s Go and GoBot ( https://github.com/hybridgroup/gobot/ ). I don’t remember what version of Go I started with, but my tools build and work with the latest version of Go, 1.15.3. Or they do under Raspbian. When I set up my build environment under Ubuntu and attempted to run my tools, nothing worked.  When I set up the same under Raspbian Buster 64 bit, they all worked just fine. The key to understanding how my tools work is that they drive everything on the Raspberry Pi’s I2C bus. For an example look at /2018/06/24/golang-on-the-raspberry-pi-part-4/ . The GPIO pin functionality may still work, but for me I’ve got shift registers and intelligent peripherals on I2C, and I need it to work. It doesn’t under Ubuntu 20.10, but it does under Raspbian Buster 64 bit.

At this point I’m back on Raspbian, and will stay there for the foreseeable future.

Leaving WiringPi

I’m going to stop working with WiringPi. Gordon Henderson stopped working on it in August 2019. I managed to fork a copy here ( https://github.com/wbeebe/WiringPi ) from a group that made a copy of the code and then started their own work on it. I fixed a minor coding problem that kept the shared library from linking under Ubuntu. It seemed to work (gpio readall), what with the very little testing I did. After spending about a week of evenings just looking at how the code is written and organized, I’ve decided to leave well enough alone. For physical computing I have my Golang work, and there are other tools, especially in Rust, that I can turn to if I need them.

I’m back to a general state of calm and comfort with Raspbian 64 bit and Golang. I’ll just take that and move along.

The deb file was built on the Jetson Xavier NX board, then copied to a thumb drive, then moved over via the thumb drive over to the Rasbperry Pi and installed from there. So far it’s behaved reasonably well. I’ve learned quite a bit about the build tools that come with the source. I suppose it’s good that I found some of the directions I did on the web, but now that I’ve gone through this whole process a number of times, what I used to start with short circuits what is available in the source tree cloned from GitHub.

I appreciate that I can use the Jetson NX as a build system. I also appreciate that there is a method in the source tree for building the deb file. That to me is super. Now I can keep up with releases, knowing I can target 64-bit ARM binaries for Debian/Ubuntu.

And speaking of Debian, the 64-bit OS running on the Raspberry Pi now identifies itself simply as Debian.

Once I feel comfortable running the full build suite in Visual Studio Code I’ll post a streamlined how-to for ARMv8/aarch64/arm64. Too many labels, frankly.

Identity

Here’s what my tool rpinfo.sh returns for this board:

 Raspberry Pi 4 Model B Rev 1.4 CPU Type : Cortex-A72   Core Count : 4 Hardware : BCM2835 Revision : d03114 MemTotal : 7.58233 GB   Kernel Release : 5.4.42-v8+   OS Description : Debian GNU/Linux 10 (buster)

Memory and Memory Usage

In order to get this one going I also installed the pre-announced 64-bit Raspberry Pi OS. Note that it’s not officially Raspbian any longer, although that’s what it still announces itself as. But the 64-bit build is real enough for the kernel and all the tools I’ve checked so far. What is more significant is the ability to see all 8 GiB of memory on the board. Here’s a copy of a terminal with htop running.

Open up the image and check the Mem line at the top, and you’ll see the footprint currently at 944 MiB with a total of 7.58 GiB of memory (remember that part of this is reserved for the graphics processor and display). And that’s with Chromium on the desktop with a number of open tabs, including a tab to write this post on my blog.

In order to get that 2 GiB of swap I had to modify /etc/dphys-swapfile per my post here: /2019/08/03/increasing-swapfile-space-on-the-raspberry-pi-4/. Rather than pick anything larger than 2 GiB I followed my original instructions. I’ll figure out later if I want more than that.

And the reason swap was bumped up is that it still comes pre-configured with only 100 MiB of swap out-of-the-box. I know this is a pre-release, but 100 MiB on any of the 64-bit Raspberry Pi boards is like driving a Porsche Taycan on four midget spare tires. I could see it come configured with 1GB at a minimum, but not 100 MiB. That’s as bad as still offering a paltry 16 GiB micro SDHC card to boot from. A standard for these boards and all other 64-bit Raspberry Pi boards is 64 GiB. Even a good (SanDisk, for example) 64 GiB micro SDXC card is inexpensive enough to give to a new user.

Thermals

The original Raspberry Pi 4B was, for all practical purposes, a credit card-sized space heater. Merely booting up the 4 was enough to send its temperatures to 70°C, and doing any work pushed it up to throttle. To the credit of the developers, they managed to claw back operating overhead over a series of firmware releases aimed primarily at the USB controller, but it was never enough in my opinion. To this day I run my 2GiB and 4GiB boards in Flirc cases. The 1GiB sits in its anti-static bag to this day.

But this version of the 4 runs in open air without those issues. Depending on the load it runs 10°C to 20°C cooler with this version of 64-bit Raspbian. I’m attributing this to the overall re-design of the board for the 8 GiB memory chip. And it may even have some additional tweaks in both firmware and the Linux kernel.

It will still need a cooling solution if it’s going to be packaged and deployed as an embedded system, so there’s still that. Since learning to use and appreciate small fans on the Jetson Nano and NX I’m now looking for something similar that will still allow me to use the various HATs I’ve picked up over time.

Power

THEY FIXED THE USB C CONNECTOR POWER ISSUE!

I have been powering this board with an Anker PowerPort Atom III 60W supply, and it works just fine. None of my earlier 4s (1, 2, or 4 GiB) work with anything other than the official 20W power supply, and that’s a big problem.

Third Party Software

I’ve install 64 bit versions of Go (go1.14.4), Rust (1.43.1) and Julia (1.4.2). All of them work just fine. Once 64 bit Raspbian is official, then it will be far easier to find and install the latest languages and tools. I was struck time and again how easy it was to work on aarch64 Ubuntu on the Jetson Nano and NX, compared to the 32 bit version of Raspbian. That impediment on the Raspberry Pi 4 is about to go away.

Final Conclusion

Buy this one. Don’t get the 2 or 4 GiB (they stopped selling the 1 in May 2020). Get the 8 GiB and move on.

It would appear this post is pulling a lot of traffic. As is typical in this type of documentation, the efficacy of this post has been overcome by events, specifically the full release of Debian Buster 64 bit for the Raspberry Pi 3 and 4. With the 64 bit version installed, Chromium doesn’t have the update dialog bug. Therefore, ignore my original post and instead update to 64 bit Buster. You can go here to find it: https://downloads.raspberrypi.org/raspios_arm64/images/

The parent folder has two folders, one dated 5-24 and a newer one dated 8-24. I started with the 5-24 release, which was and still is considered a pre-release. So far I’ve encountered no issues, and over time I’ve watched numerous updates come rolling in. I can only assume by now that I’m up to the 8-24 release. In any event, install the 8-24 release. Consider the 5-24 release only if all else fails.

Original Post

I don’t know how it crept in, but there’s a bug in the current Chromium that keeps popping up a dialog complaining it can’t update Chromium. The only problem is that Chromium isn’t updated like regular Chrome, it can only be updated when there’s a package update via apt. And there are no updates. There’s a bug for this (see https://github.com/RPi-Distro/repo/issues/165), but if you’d like to shut up the annoyance now, then there is a work-around (I think).

In the file system under /etc/chromium-browser/customizations, open a new file named 01-disable-update-check:

cd /etc/chromium-browser/customizationssudo vi 01-disable-update-check

Then type in the following single line of text:

CHROMIUM_FLAGS="${CHROMIUM_FLAGS} --check-for-update-interval=31536000"

Save the file and restart Chromium. The interval value 31536000 is the number of seconds in 365 days, or one year. Why that number was chosen I can’t say. Nor can I say if the value really works, because restarting the browser always makes the nag dialog as well as the icon go away for a time on next startup. But we shall see…

In addition to running cooler, Raspbian Buster appears to be using a lot less memory resources than before, such as when having many open tabs in Chromium. More often than not I could see on htop where swap was being hit with a regular load of Chromium, multiple open tabs on the Terminal with multiple editing sessions, and regular builds with any of Go, C++, Rust, Python 3 or Julia running. I’ve now had the Pi 4 up for five days with continuous use and I haven’t hit swap yet.

And speaking of Julia, I installed version 1.4.0 and then installed all the supporting packages I normally need. One of those packages is Winston, and it has problems. Winston under Julia 1.4.0 is dependent on more packages than ever these days, so much so that any Julia script I’ve written won’t run because not all the current Winston dependencies are met. As a consequence I’ve dropped back to running the prior release, Julia 1.3.1. My scripts still run, and for the time being I’m not updating any of its packages.

That wasn’t a problem with Raspbian Buster up until just recently. Before that time, I had an entry for my SSD in fstab that started out like this:

/dev/sda1 ...

It worked just fine, until one day after a recent update that included the kernel, it didn’t. No warning that this was going to happen, none at all. After the update and subsequent reboot, the Raspberry Pi refused to boot, and instead dropped me into a prompt waiting for me to log in as root to fix the problem. Oh, wait, root is disabled by default in Raspian, so that just put me in an endless boot loop.

It took two attempts rebuilding a minimal boot micro SDXC before I finally figured out what was happening. Fortunately, that second micro SDXC card was a new one with a minimal Raspbian system, so it didn’t take too much effort to see that adding the entry to /dev/sda1 was causing it to fail to boot. Fortunately for me I have other Linux systems (my ten-year-old Samsung R580 running Ubuntu 18.04.04 came to the rescue) that allowed me to mount both micro SDXC cards, edit fstab and remove the entries. Once removed, both micro SDXC cards booted just fine in the Raspberry Pi 4.

Once I got back in I enabled root with ‘sudo passwd root’ and gave it a password. Now, if I have a problem where a Raspbian boot failure wants to dump me into the root account in single user mode, I can actually log in at that point.

The other problem was getting the USB SSD to mount. Here’s what I did to fix that. But first, a tiny bit of background.

The kernel in Raspbian buster uses what’s now known as a PARTUUID to identify a storage device instead of the old school device name in /dev. To find out what that PARTUUID is, you have to run this command at the command line in a terminal window:

pi@rpi4-4-01:~ $ sudo blkid/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="69D5-9B27" TYPE="vfat" PARTUUID="d9b3f436-01"/dev/mmcblk0p2: LABEL="rootfs" UUID="24eaa08b-10f2-49e0-8283-359f7eb1a0b6" TYPE="ext4" PARTUUID="d9b3f436-02"/dev/sda1: LABEL="SSD" UUID="ad89d540-a007-4d0a-887b-0b0dbefe3e8e" TYPE="ext4" PARTUUID="937a0120-01"/dev/mmcblk0: PTUUID="d9b3f436" PTTYPE="dos"

Since I already know the label on my SSD is “SSD” it’s quickly identifiable in blkid’s output. Copy the PARTUUID at the end of the entry, and use that in the fstab entry for the drive, like so:

PARTUUID=937a0120-01 /ssd ext4 defaults,auto,users,rw,nofail,x-systemd.device-timeout=30 0 0

Note that the quotes are not added to the entry. Also note all the flags I use, especially the shortened timeout (systemd.device-timeout=30) to shorten the wait during boot in case the SSD isn’t plugged in. The default is 90 seconds.

The primary reason I want the SSD mounted is because that’s where I put swap. In /etc/dphys-swapfile I add the following line:

# where we want the swapfile to be, this is the default#CONF_SWAPFILE=/var/swapCONF_SWAPFILE=/ssd/swap

I want my swap on the SSD because testing has shown the SSD is an order of magnitude faster than the boot micro SDXC. I use the Raspberry Pi 4’s as development and native build machines, rather than set up an emulation and cross-compile tool chain on my Mac. Believe it or not, it’s a lot simpler the way I have it set up. This is a decent compromise that doesn’t require me to put the entire OS on the SSD and then configure the Raspberry Pi to boot off the SSD. There are some significant problems with that, such as the Rasberry Pi 4 wasn’t set up to do that for quite some time after its release, and the fact that once configured that way, you can’t go back. So I put swap on the SSD, then cd onto a work area on the SSD and develop and build away.

This all gets back to the bigger question: why did this change, and when did it change? I use the same type of setup, and the same SSD, on the Jetson Nano, and it’s running a tweaked version of Ubuntu 18.04.04, complete with the Ubuntu graphical desktop. The fstab entry for that is the regular device entry, /dev/sda1.

Oh well. I just keep reminding myself that this is just a hobby, and I’m retired.

I spent some time this Thanksgiving holiday taking Ubuntu for IoT for a quick spin on a Raspberry Pi 4 with 2GB of memory. I have three Raspberry Pi 4s, one each of 1GB, 2GB and 4GB memory capacity. The 4GB is the primary “development” system with the latest version of Raspbian Buster installed. I had the 2GB version mounted inside a Flirc case sitting on the shelf, unpowered and without an OS. I decided to experiment with that one, as I hadn’t used it since the very early days of the Raspberry Pi 4 hardware release and initial release of Raspbian Buster. Once the 4GB Raspberry Pi 4 arrived, I transferred all my work to it and ignored the other two. The 1GB board is back in its anti-static bag and in its original box. I need to pull it out and put it back to work as well. But I digress…

Setup

• Raspberry Pi 4 with 2GB of memory
• Firmware version – 000137ab
• SanDisk Ultra Plus 64GB µSD card, V10, XC I, C10, A1
• Monitor – Samsung S22C300H 1920 x 1080, 21.5 inch monitor
• Keyboard – Logitech MK710 wireless
• Mouse – Logitech MX Ergo trackball

Normally I use an LG 34UM61-p 2560 x 1080 monitor with my RPi 4 because Raspbian Buster is capable of driving it. But Ubuntu IoT won’t, neither in text nor graphics (desktop) mode. While the Logitech MK710 comes with its own mouse, I use the Ergo because it’s easier for me. I’ve begun to develop arthritis in my right wrist, and it’s easier for me to keep my hand still and at a 30% tilt from horizontal, and just move the track ball with my thumb.

Installing 64-bit Ubuntu Server IoT

The reason for installing 64-bit Ubuntu Server IoT on the 2GB memory RPi 4 board is that it currently will not work on the 4GB memory board.

I followed the directions on the Ubuntu site (https://ubuntu.com/download/raspberry-pi), flashing the 64-bit Ubuntu Server image to the µSD card using balenaEtcher (https://www.balena.io/etcher) on my Mac. If you don’t use balenaEtcher (on Linux, macOS, or Windows) then you’re only making it harder on yourself. balenaEtcher is incredibly simple to use and nearly foolproof.

Bootup was bit peculiar compared to Raspbian command line. It took awhile for the Ubuntu image to completely boot. When it finally presented a login prompt and I logged in, it had converted all the empty space on the µSD card into a Linux volume. The total amount of disk space that Server took for itself on that volume was less than 2GB, which isn’t bad at all.

Logging in the first time was annoying. The login prompt would appear, then get wiped as late starting services would announce themselves as via text to the console. I learned to wait until startup was truly finished before attempting to log in.

I had the Pi connected to my network via a wired cable. The server image doesn’t have everything necessary to turn on WiFi on the board. I had to install network tools in order to make wireless work, and I had to create by hand an initial wpa_supplicant.conf configuration file with my wireless networks SSID and password. At the next reboot the WiFi network came up and Ubuntu IoT was running in 64 bit mode with WiFi. After that it was ‘apt update’ and more waiting. Bringing up WiFi is very simple, and very easy, with Raspbian. It can be done either with a text tool or on the desktop. Ubuntu Server IoT could take a page from the Raspbian setup manual on how it should be done.

Now I know that security is a Big Deal with the Ubuntu IoT crew. I really get that. But forcing me to change my password into something long and complex is a royal pain in my behind. I hate that crap. Trust me: if and when I decide to deploy based on this (which at this time I won’t, but keep reading) then I’ll harden login. I didn’t fall off the turnip truck to get here. And I certainly don’t need such a sledgehammer reminder as the one in Ubuntu Server IoT right off the bat.

Installing a Desktop

After installing Server I followed the direction’s advice and installed Lubuntu Desktop. That took some time as a large number of packages had to be installed, and many others updated. When it finished and the RPi 4 rebooted, it showed a graphical login screen. I logged in and beheld a typical Linux graphical desktop.

It was, for the most part, rather uneventful, which is a Good Thing. I noticed that the applications installed were rather sparse, which is another Good Thing. There were no ancient games, for example. What I did find unusual is that LibreOffice was installed. I don’t need an office suite installed on a RPi development board. That’s why I never install the full Raspbian desktop plus applications, only the basic Raspbian desktop.

I also discovered that gcc isn’t installed either. I understand not having it with the Server image, but the desktop image should have the development tools as part of the overall package. Python 3 was there as was Vim, so I could have taken off with that if I’d wanted to. And yes, I can certainly apt install all the development tools. But still…

I did like the look of Lubuntu, but not necessarily it’s operation. The desktop software operated in a halting, janky sort of fashion. I’d move the mouse across the desktop and watch it stutter a bit. It wasn’t all the time, and it didn’t get in the way of getting work done. But compared to Raspbian, it didn’t feel quite as polished while using it.

I spent a half hour poking about, looking at things, and appreciating it was actually running in 64-bit mode. That’s my biggest complaint about Raspbian, that it’s still 32-bit. Once set up I shut it down and attempted to bring it back up with the LG monitor. While Ubuntu Server came up, the monitor stayed dark. I could ping it and ssh into it, but the graphical desktop was non-functional. In the end I pulled out the µSD card, put it away, and brought the 2GB RPi 4 in up-to-date Raspbian.

Thoughts

I’m not sure what to say. It feels rough, especially the desktop. My advice there is to pick just one desktop, and then to tailor it more towards development, including such applications as gcc and supporting development tools.  Or if you don’t want to bloat the desktop meta package then create a Languages Development meta-package that has everything needed, while trimming back the desktop package.

Ubuntu Server IoT has a lot of promise and I will tinker with it some more in the near future, but for now, based on my very limited experience, if you’re starting out with the Raspberry Pi, then chose Raspbian. There are three Raspbian images; one minimal command line, one basic desktop, and a desktop with all sorts of additional goodies. I personally use the first two. But I can’t ignore the fact that Ubuntu Server has a 64-bit foundation. They’re all good and solid and will get you up and running with a minimum of fuss.

One other positive aspect about Ubuntu Server plus desktop. It’s disk footprint is noticeably smaller than Raspbian, even with the desktop meta package installed. I certainly appreciated that. It’s memory footprint also is rather small as well. Again, another aspect to appreciate.

I’m not giving up on Ubuntu Server IoT. I just need to think of the best way to use it in the future.

Because of a chance comment on an earlier post (an absolute failure – unable to build qt5 on a raspberry pi 4, /2019/09/02/an-absolute-failure-unable-to-build-qt5-on-a-raspberry-pi-4/) by developer outsourcedguru (https://outsourcedguru.wordpress.com/) I have “fallen” for yet something else to get involved with: Kivy (https://kivy.org/). To be honest I’d never heard about it before now. It uses Python like PyQt5 does, to provide the programmatic bones on which to build very interesting applications using other tooling for desktop application rendering, which is 3D in this case.

I went looking and found directions for getting everything installed for Kivy. I then found a GitHub repo with this example in it (https://github.com/kivy/kivy/tree/master/examples/3Drendering). I downloaded everything and got it going as-is. It is now my new favorite thing to just run on my desktop. I’ve been monitoring both CPU usage as well as memory usage, and with this simple example it has basically no impact at all. Startup is near instantaneous. CPU temperature crept up a few degrees C, if that. With Chromium open with fourteen or so tabs and my other tools open as well, it should be doing some kind of work.

Something else for me to explore. I’m going to pull this onto my Macs as well.

Here’s another one for the Raspbian Buster notebook. I spent a bit of time trying to install Microsoft’s Visual Studio Code by following these directions at https://pimylifeup.com/raspberry-pi-visual-studio-code/. After setting up all the dependencies, downloading the tarfile and pulling it apart, then attempting to run the script that would install and build everything else, the VS Code installation failed because the JavaScript engine ran out of heap space. Fine. I’ve used VS Code everywhere else, including Linux systems with only 4GB of memory, but I’ve never had a heap-space issue before now. To be truthful I like working with VS Code and all its various plugins. I would have tried to debug the blocker, but I decided to cut my losses then and there.

I got to the point of trying to install VS Code because I found myself thrashing about looking for a comfortable code editor and almost IDE. I say almost IDE because, after nearly two decades immersed in IDE development environments, I’d grown tired of it. VS Code was a nice step back. But it wasn’t going to happen on the Raspberry Pi 4 with Raspbian Buster. That’s when I turned back to VIM (VI Improved) and rather quickly got it into pretty good shape for my needs. But something still nagged at the back of my mind, and as good as Vim has become, it just wasn’t quite right. I then figure, what the hell. I’ll install and try Emacs again.

I was introduced to Emacs back in the early 1990s by an Emacs goddess. That is no exaggeration. She could code rings around all the other guys, and part of her prowess can be attributed to her mastery of Emacs. She showed me how much better Emacs was over vi and then set me up with some directions and  a beginning .emacs file. I learned how to edit with emacs and how to configure it to fit my tastes. It soon became my default editor, and I carried around my .emacs file from project to project. But a funny thing happened on the way into the 21st century. I got swept up into the bigger-is-better development tool environment and eventually forgot about Emacs.

Until today. It’s been so long since I’ve used it that I’ve had to open up a basic web-based user manual and started to build an .emacs from scratch. Fortunately for me Emacs has evolved considerably. The version I’m using now is a desktop client, and it’s menu support has allowed me to quickly get back up to speed again with regards to setting up a decent visual environment. All the very old muscle memory is coming back, and I think I understand part of my uncomfortable feeling with Vim; a lot of the key sequences are too close together. Being back in Emacs, everything just falls naturally back into place.

Emacs is not better than Vim, and Vim isn’t better than Emacs. But Emacs is best for me.

If you’re going to do something like this, then make sure that after an install you remove all soft links bin directory. The bin directory should look something like this:

All those links will end in a ‘3’, such as ‘python3’, and if you have the path to where you installed the Python 3.8 beta binaries in your overall $PATH, then you’ll pick it up instead of the default. So remove those links for the time being and instead use python3.8 when you want to test.

One more minor detail, which I started doing when building Qt5, and that’s create a build folder away from the source folder. Configure and build out of the build folder, so that if you need to rebuild with different configuration or different features, it’s simple to just create a second separate build folder and run everything again. For example:

Everything is in the build folder instead of commingled in with all the source. I wrote in last year’s post to build inside the source code folder after you unpacked it, and that was poor advice on my part.

A Tipping Point

The Raspberry Pi 4, in spite of its few rough edges (excess heat generation, non-standard USB C power connector) is still an excellent development platform, especially at US $55 for the 4GB version. With the drop in price of solid state storage prices you can build a very good Raspbian development system and do all your work natively instead of cross-compiling on another system (Linux or macOS or Windows 10). It keeps costs down considerably, especially if you’re on a budget. Even if you’re not, it’s still an excellent bargain all around. If you want to purchase a Raspberry Pi, then the 4B with 4GB is the one to get. With the extensive ecosystem and user community that’s built up around the Raspberry Pi, there’s no longer any excuse to hold back.