Posts

Latest Posts

Fedora 41 mini-review on the Blackbird and Talos II


It's Fedora upgrade time again! And in the same way I preface all these mini-reviews (see our last for Fedora 40), Fedora was one of the first mainstream distributions to support POWER9 out of the box, it's still one of the top distributions OpenPOWER denizens use and its position closest to the bleeding, ragged edge is where we see problems emerge first and get fixed (hopefully) before they move further downstream. That's why it's worth caring about it even if you yourself don't run it. Also, as always, recall both my Talos II and Blackbird are configured to come up in a text boot instead of gdm and I start the GUI manually from there. I always recommend a non-graphical boot as a recovery mechanism in case your graphics card gets whacked by something or other, and on Fedora this is easily done by ensuring the symlink /etc/systemd/system/default.target points to /lib/systemd/system/multi-user.target.

I'll also give a quick shout out here to Dan Horák at Red Hat, who responds to our user issues and maintains some additional Fedora packages in copr. Read his newly updated blog for information.

Irritatingly, dnf continues to fail to update grub2's config (bug 1921479, showing messages like 0ed84c0-p94177c1: integer expression expected during the process), so the process remains largely unchanged from F39 and F40:

dnf upgrade --refresh # upgrade prior system and DNF
grub2-mkconfig -o /boot/grub2/grub.cfg # force grub to update
dnf install dnf-plugin-system-upgrade # install upgrade plugin if not already done
dnf system-upgrade download --refresh --releasever=41 # download F41 packages
dnf system-upgrade reboot # reboot into upgrader

Again there was no installation screen on either the Blackbird or T2 this time around; for both systems I needed to log in as root on an alternate VTY (Ctrl-Alt-F2 or as appropriate) and either dnf system-upgrade log --number=-1 intermittently to watch the updates, or just do journalctl -f if you want a live feed and don't mind the scrollspam. You can probably also still monitor it on the virtual TTY in the BMC web interface. Both systems then rebooted (fast reboot is disabled on both) and came up clean, again with no XFS burp on the T2! I think we can conclude the updated Petitboot firmware has resolved that issue. As usual, one more grub2-mkconfig -o /boot/grub2/grub.cfg was needed to get Petitboot's menu looking right and the install was complete.

I should also note that two people on the Raptor forums reported that their systems were unbootable after this update. However, both the Blackbird and the T2 upgraded with no hitches except for a really old F33 package on the T2 I had to blow away, so I can't replicate that here and neither can Dan.

Let's proceed with testing out the Blackbird, which is my proving ground system before upgrading my regular T2 workstation. The biggest update is that in the most recent kernel versions, especially if you haven't done any updates between the F40 upgrade and now, we finally have 1920x1200 support on the built-in BMC HDMI video!

Yes, much as it pains me to say it, Wayland has finally progressed to the point where it's useable with the ASPEED BMC framebuffer. This is a crucial point to make if you're running a GPU-less configuration, especially if you're trying to achieve a fully libre machine with no firmware blobs: you can now use Wayland with it with little obvious compromise, if you really really want.
All resolutions up to 1920x1200 are supported, including 1920x1080. This works in both GNOME and KDE Plasma 6.2, though I'll have something bad to say about GNOME in a moment.

Now, there's still reasons not to use Wayland with BMC graphics, and the big one is that the fans just ran continuously in Wayland because everything is getting crammed through llvmpipe. This is a little 4-core Blackbird and it could keep up with it, but it certainly earned its money doing so. When I switched back to Xorg using plasma6-x11-unsupported, all was quiet again.

X11 modelines never had any problems supporting BMC video, but here it is for the record.
I also commented on the Chromium build now available for ppc64le in the F40 mini-review, so it's only fair to see how far it's come. And, well, it's come a long way. Many more things work and the previous graphical glitches in Xorg seem gone now. It's still somewhat rickety and crash reports pop up intermittently as its subprocesses fart and die, and really big Wasm apps like (oh the irony) Google Earth will bring it to its knees, but casual browsing largely works fine and it can run MAME from the Internet Archive's online arcade now with reasonable performance. I still find my personal builds of Firefox with Baseline JIT to be faster with browsing and I retain my philosophical objections to Chrome and Chromium, but I can't deny the progress, so this will make others of you happy.

Something that won't make you happy was GNOME. Whether it was Wayland or Xorg, there were tons of graphical artifacts on the blob-free Blackbird (these are photographs of the screen since the framebuffer didn't always reflect the issue):

The Plasma 6.2 update doesn't seem to break anything major, so if you're blob-free, I'd just use KDE with the unsupported X11 support. It's easier on the cores and it generally works. Xfce would probably be okay too.

On the T2, other than that weir-dass F33 remainder package, the upgrade was similarly smooth. Nothing so far has seemed to regress. However, the Talos II has a Raptor-BTO AMD WX7100 card, unlike the Blackbird.

Regular readers know very well I'll complain when it's time to complain, but this time around the F41 upgrade worked well and the system seems solid. I'm sorry to hear about the problems some others have had, but I couldn't replicate them here. So far this has been one of the smoother updates, which was a profound relief.

CHRP support gone from Linux kernel


There weren't that many Common Hardware Reference Platform PowerPC systems anyway, but if you have one of them (notably systems like IBM's RS/6000 7046 Model B50, the Total Impact briQ, Motorola PowerStacks or the PegasosPPC or Pegasos II from Genesi), your days are numbered as CHRP support will be removed from the next Linux kernel release. CHRP never got much market traction; Apple, then the largest seller of PowerPC machines, only partially supported it (Old World Macs are sui generis and New World Macs are a combination of CHRP and PReP), and as a result Linux support for Power Macs — at least what remains — never completely depended on it.

At least for the Genesi machines, however, you have better and more supported options in MorphOS and AmigaOS 4, and while Power Macs should still work, they're (IMHO) more usefully served by one of the BSDs. For the real oddball machines, though, if you were running a bleeding-edge kernel this is the end of the line — unless you'd like to step in and maintain it.

Updated Baseline JIT OpenPOWER patches for Firefox 128ESR


I updated the Baseline JIT patches to apply against Firefox 128ESR, though if you use the Mercurial rebase extension (and you should), it will rebase automatically and only one file had to be merged — which it did for me also. Nevertheless, everything is up to date against tip again, and this patchset works fine for both Firefox and Thunderbird. I kept the fix for bug 1912623 because I think Mozilla's fix in bug 1909204 is wrong (or at least suboptimal) and this is faster on systems without working Wasm. Speaking of, I need to get back into porting rr to ppc64le so I can solve those startup crashes.

Fedora 41


Just a quick note that Fedora 41 is out, the standard Linux distro we use here on our two Raptor systems. Based on kernel 6.11, he big updates are updated packaging with DNF 5 and RPM 4.20 plus Perl 5.40, Python 3.13, LLVM 19 and gcc 14.1/glibc 2.40. Fortunately there are apparently still optional Xorg support packages for GNOME and KDE Plasma. Once the package repos have stabilized a bit, I'll have the usual minireview. For now, refresh your memory with how things went with Fedora 40, and of course Fedora 38 will be EOL in about a month based on their standard schedule.

Running Thunderbird with the OpenPower Baseline JIT


The issues with Ion and Wasm in OpenPower Firefox notwithstanding, the Baseline JIT works well in Firefox ESR128, and many of you use it (including yours truly). Of course, that makes Thunderbird look sluggish without it.

I wasn't able to get a full LTO-PGO build for Thunderbird to build properly so far with gcc (workin' on it), but with the JIT patches for ESR128 an LTO optimized build will complete and run, and that's good enough for now. The diff for the .mozconfig is more or less the following:

export CC=/usr/bin/gcc
export CXX=/usr/bin/g++

mk_add_options MOZ_MAKE_FLAGS="-j24"

#ac_add_options --enable-application=browser
#ac_add_options MOZ_PGO=1
#
ac_add_options --enable-project=comm/mail
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/tbobj

ac_add_options --enable-optimize="-O3 -mcpu=power9 -fpermissive"
ac_add_options --enable-release
ac_add_options --enable-linker=bfd
ac_add_options --enable-lto=full
ac_add_options --without-wasm-sandboxed-libraries
ac_add_options --with-libclang-path=/usr/lib64

export GN=/home/censored/bin/gn # if you haz
export RUSTC_OPT_LEVEL=2

You can use a unified .mozconfig like this to handle both the browser and the E-mail client; if you do, to build the browser the commented lines should be uncommented and the two lines below the previously commented section should be commented.

You'll need comm-central embedded in your ESR128 tree as per the build instructions, and you may want to create an .hg/hgignore file inside your ESR128 source directory as well to keep changes to the core and Tbird from clashing, something like

^tbobj/
^comm/

which will ignore those directories but isn't a change to .hgignore that you have to manually edit out. Once constructed, your built client will be in tbobj/. If you were using a prebuilt Thunderbird before, you may need to start it with tbobj/dist/bin/thunderbird -p default-release (substitute your profile name if it differs) to make sure you get your old mailbox back, though as always backup your profile first.

Music production on Power: an adventure in porting


[Here's a guest post from taylor.fish on their porting work on music and audio software. I thought it made a good tutorial on porting and also is a great way to show off the diverse things people are doing on OpenPower. Like all guest and first-party posts on Talospace, this article remains the property of the original author and may be distributed under CC-BY-SA 4.0. -- Ed.]

For the past five years, I’ve used a Blackbird as my primary computing device. Prior to that I used x86 systems flashed with Libreboot, but aging hardware running unsupported firmware only gets you so far.

The switch to a truly owner-controlled Power ISA system was a welcome one, but it wasn’t without its growing pains. I could no longer assume any given piece of Linux-compatible software would successfully compile and run on my machine, due to the small but significant portion with architecture-specific issues. That didn’t deter me from continuing to use my Blackbird as my main device, but when I wanted to get back into music production, I knew I would have to confront this problem: my previous endeavors, although sticking entirely to free software, were all on x86.

Of particular importance in digital music production are plugins, which include instruments like synthesizers and samplers, effects like equalizers and reverb, and analysis tools like spectrograms and oscilloscopes. While there are some excellent plugins released as free software, they are vastly outnumbered by proprietary ones, and it takes dedication to commit to producing music only with free software. Not wanting that uphill battle to feel more like a cliff, when I discovered that some of those plugins wouldn’t run on Power, I was determined to change that fact rather than lose what few tools I had.

And so my porting adventure began. Over the past year or so I developed patches for every piece of free/libre audio software that I wanted to use but that didn’t work on Power. Some of those changes have been merged upstream, but for all the others I maintain a GitHub organization called PowerAudio that contains forked versions of each repository with ppc64le patches applied (along with some other improvements for use on GNU/Linux). If you just want working audio plugins on Power, visit that page, which has more information about each piece of ported software. If you want to know more about what the porting process entailed, however, read on…

The porting process

Each piece of software to be ported has its own unique set of problems, but there are some common themes. Here are some of the most frequent issues that prevent audio plugins from working on Power ISA systems:

1. Architecture-specific compiler options

This is the easiest issue to fix. Some projects pass architecture-specific options to the compiler (like -msse on x86) but don’t restrict those options only to the relevant architectures. In that case the fix is simply to perform an architecture check before applying those options, as in this change to tap-lv2:

@@ -10 +10,3 @@
+ifneq ($(findstring $(shell uname -m),x86_64 amd64 i386 i686),)
 CFLAGS += -mtune=generic -msse -msse2 -mfpmath=sse
+endif

Some projects handle specific architectures but then assume x86 as a fallback. In that case, it’s easiest to continue the pattern and add ppc as one of the cases, as in this change to Helm:

@@ -25,4 +25,8 @@ ifneq (,$(findstring aarch,$(MACHINE)))
 ifneq (,$(findstring arm,$(MACHINE)))
	SIMDFLAGS := -march=armv8-a -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard
+else
+ifneq (,$(findstring ppc,$(MACHINE)))
+	SIMDFLAGS :=
 else
	SIMDFLAGS := -msse2
+endif

2. Assumptions broken by Power

Some code appears to be cross-platform but contains assumptions that don’t apply to Power ISA systems. For example, the plugin framework DPF used the first part of gcc -dumpmachine to obtain the correct directory name for VST plugins. On 64-bit little-endian PowerPC, that yields powerpc64le. But the VST 3 specification says the directory name should match uname -m, which is ppc64le. These two identifiers happen to be identical for many architectures, but generally differ on PowerPC and Power ISA systems.

Simply using uname -m here would break cross-compilation, so the fix performs a text substitution to correct the discrepancy on Power:

@@ -691 +691,3 @@ ifeq ($(LINUX),true)
-VST3_BINARY_DIR = Contents/$(TARGET_PROCESSOR)-linux
+# This must match `uname -m`, which differs from `gcc -dumpmachine` on PowerPC.
+VST3_ARCHITECTURE := $(patsubst powerpc%,ppc%,$(TARGET_PROCESSOR))
+VST3_BINARY_DIR = Contents/$(VST3_ARCHITECTURE)-linux

A similar issue existed in JUCE, a popular framework for audio plugins. JUCE performs architecture detection with a chain of preprocessor conditionals that (somewhat hackily) use #error to emit the correct architecture identifier, which JUCE uses in places that expect the output of uname -m. While those conditionals do attempt to detect PowerPC, they don’t account for the fact that the different endiannesses of 64-bit PowerPC have different identifiers, and incorrectly classify ppc64le as ppc64. This can cause compilation to fail entirely when JUCE uses the incorrect architecture name but then runs a validator that expects the correct one.

A simple endianness check fixes this one:

@@ -64,3 +64,7 @@ #elif defined(__ppc__) || defined(__ppc) || ...
   #if defined(__ppc64__) || defined(__powerpc64__) || defined(__64BIT__)
-    #error JUCE_ARCH ppc64
+    #ifdef __LITTLE_ENDIAN__
+      #error JUCE_ARCH ppc64le
+    #else
+      #error JUCE_ARCH ppc64
+    #endif
   #else

3. Lack of inclusion in platform-specific code

Some projects contain truly platform-specific code that needs to be written separately for each architecture, but don’t include PowerPC one of the handled cases. In these situations, the most straightforward (and sometimes only) fix is to add the necessary Power-specific code. For example, sfizz contained a copy of a low-level dependency that only supported x86 and ARM, but because that dependency had already added support for Power and other architectures upstream, all that was necessary for sfizz was to update the dependency.

Another example comes from DISTRHO Ports, a large collection of plugins ported to GNU/Linux, in which an architecture detection script required adding code to detect the various types of PowerPC:

@@ -42,4 +42,19 @@
     elif echo "${fileout}" | grep -q "x86-64"; then
         if [ "$(uname -m)" != "x86_64" ]; then
             MESON_EXE_WRAPPER="qemu-x86_64-static"
         fi
+
+    elif echo "${fileout}" | grep -q "64-bit LSB.*PowerPC"; then
+        if [ "$(uname -m)" != "ppc64le" ]; then
+            MESON_EXE_WRAPPER="qemu-ppc64le-static"
+        fi
+
+    elif echo "${fileout}" | grep -q "64-bit MSB.*PowerPC"; then
+        if [ "$(uname -m)" != "ppc64" ]; then
+            MESON_EXE_WRAPPER="qemu-ppc64-static"
+        fi
...

Although the purpose of this script is to aid cross-compilation, the lack of Power support prevented even native compilation.

4. Missing optional vector intrinsics

Hardware-specific vector intrinsic functions (SIMD) are often used to improve performance, but software that uses them must provide a separate implementation for each supported architecture, which rarely includes Power. However, some software is designed to use vector intrinsics only when such an implementation exists, falling back to a non-optimized, cross-platform approach otherwise. In practice, though, if non-optimized platforms don’t get much testing, bugs that unintentionally prevent compilation on these systems can go unnoticed.

This issue occurred in a dependency used by Wavetable that contained, but did not require, optimized SIMD code for x86–64 and ARM, but caused errors on other architectures by mistakenly trying to use their nonexistent SIMD implementations. Because SIMD was designed to be optional in this dependency, the fix simply adds an architecture check:

@@ -80,5 +80,7 @@
  #ifdef JUCE_32BIT
   #define GIN_HAS_SIMD 0
- #else
+ #elif defined(JUCE_INTEL) || defined(JUCE_ARM)
   #define GIN_HAS_SIMD 1
+ #else
+  #define GIN_HAS_SIMD 0
  #endif

Another example comes, again, from JUCE. JUCE contains a copy of libpng, a PNG library that actually contains optimized VSX code for Power! But in a cruel twist of irony, JUCE excluded that optimized code from their copy, yet kept the code that tries to use it. The result? Linker failures that, because they occur in a helper tool almost always compiled early in the build process, prevent almost all software that uses JUCE from compiling on Power.

The fix for this one comes from libpng itself, which demonstrates the proper way of disabling optimizations, by defining certain macros instead of just deleting the implementations. So these macros simply need to be added to JUCE, which… already defines one of them?

#define PNG_ARM_NEON_OPT 0

Indeed, because JUCE’s copy of libpng excludes the optimized routines for all architectures, this issue presumably appeared on ARM at some point and was fixed (x86 happens not to exhibit the problem because libpng optimizations are opt-in on that architecture). That would have been a great time to include the other macros to disable optimizations, but instead, that task is accomplished by this fix:

@@ -268 +268,4 @@
   #define PNG_ARM_NEON_OPT 0
+  #define PNG_POWERPC_VSX_OPT 0
+  #define PNG_INTEL_SSE_OPT 0
+  #define PNG_MIPS_MSA_OPT 0

5. Missing required vector intrinsics

Finally, one of the most common sources of incompatibility with Power in audio software is the non-optional use of SIMD, necessitating separate implementations for each architecture. Unsurprisingly, support for Power is not typically included.

My preferred approach in this case is to use SIMDe, a cross-platform implementation of x86 (and ARM) vector intrinsics, optimized with the platform’s native vector operations when available. In the case of Vaporizer2, that looks something like this:

@@ -6,5 +6,8 @@
 #ifdef __aarch64__ //arm64
	#include "../../sse2neon.h"
-#else
+#elif defined JUCE_INTEL
	#include "immintrin.h"
+#else
+	#define SIMDE_ENABLE_NATIVE_ALIASES
+	#include <simde/x86/sse3.h>
 #endif

Something similar is done for Vitalium, the fork of Vital in DISTRHO Ports. However, when attempting to use SIMDe to implement the x86 intrinsics it uses, I encountered odd runtime errors with backtraces that involved SIMDe. More investigation is needed to determine the cause, but because Vitalium also provides implementations of its vector-optimized routines for ARM, an easier workaround was to configure SIMDe to implement ARM’s vector intrinsics (NEON) instead, which appears to avoid that issue.

@@ -33,8 +33,13 @@
 #else
-  static_assert(false, "No SIMD Intrinsics found which are necessary for compilation");
+  #warning "No native SIMD support; using SIMDe"
+  #define SIMDE_ENABLE_NATIVE_ALIASES
+  #include <simde/arm/neon.h>
+  #define VITAL_NEON 1
+  #define VITAL_SIMDE 1
 #endif

-#if VITAL_SSE2
+#if VITAL_SIMDE
+#elif VITAL_SSE2
   #include <immintrin.h>
 #elif VITAL_NEON
   #include <arm_neon.h>

[See also x86intrin.h -- Ed.]

Lastly, another example of this comes—yet again—from JUCE, in a form that prompts a different solution. JUCE contains its own set of SIMD functions, designed with an architecture-independent API but requiring architecture-specific implementations. Although Power is predictably unsupported, JUCE does contain cross-platform fallback implementations for almost all of its SIMD API; however, these are used only as part of the architecture-specific implementations, to implement operations that don’t have a precise native equivalent on a given platform.

Why not, then, provide a universal fallback implementation for all unsupported architectures? That’s exactly what this change does (with a diff too large to include here), fixing another source of compilation errors in projects that use JUCE.

Conclusion

When ARM devices running desktop operating systems started to become more common, in particular due to Apple’s decision to move away from Intel, I had hoped that this would encourage x86-only software to become architecture-independent, benefiting Power in the process. Unfortunately, many projects have simply special-cased support for ARM, even when cross-platform alternatives exist (which don’t preclude optimized architecture-specific routines if desired). Maybe another architecture will eventually become the catalyst for this change, but until then, we’ll need patches.

I will, however, take a moment to complain again about JUCE. Despite making me sign their Contribution License Agreement, JUCE has ignored all of my pull requests (juce-pr1, juce-pr2, and juce-pr3), even the simplest two that would not require much review (yet are the most important fixes for Power). Because of this, every project that uses JUCE must, at a minimum, use a patched version in order to compile on Power.

Still, I think the biggest takeaway is that music production is absolutely possible on Power. The experience is undoubtedly rough around the edges, but I hope that PowerAudio’s ports can reduce the discrepancy in available tools compared to other architectures, and generally make this activity more accessible to Power ISA users.