Firefox 105 on POWER

Firefox 105 is out. No, it's not your imagination: I ended up skipping a couple versions. I wasn't able to build Firefox 103 because gcc 12 in Fedora 36 caused weird build failures until it was finally fixed; separately, building 104 and working more on the POWER9 JavaScript JIT got delayed because I'd finally had it with the performance issues and breakage in GNOME 42 and took a couple weeks renovating Plasma so I could be happy with my desktop environment again. Now I'm on track again with everything hopefully maintainable and my workflows properly restored, and we're back to the grind with both those concerns largely resolved.

Unfortunately, we have a couple new ones. Debug builds broke in Fx103 using our standard .mozconfig when mfbt/lz4/xxhash.h was upgraded, because we compile with -Og and it wants to compile its functions with static __inline__ __attribute__((always_inline, unused)). When gcc builds a deoptimized debugging build and fails to inline those functions, it throws a compilation error, and the build screeches to a halt. (This doesn't affect Fedora's build because they always build at a sufficient optimization level such that these functions do indeed get inlined.) After a little thinking, this is the new debug .mozconfig:

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

mk_add_options MOZ_MAKE_FLAGS="-j24" # or as you likez
ac_add_options --enable-application=browser
ac_add_options --enable-optimize="-Og -mcpu=power9 -fpermissive -DXXH_NO_INLINE_HINTS=1"
ac_add_options --enable-debug
ac_add_options --enable-linker=bfd
ac_add_options --without-wasm-sandboxed-libraries

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

This builds, or at least compiles, but fails at linkage because of the second problem. This time, it's libwebrtc ... again. To glue the Google build system onto Mozilla's, there is a fragile and system-dependent permuting-processing step that again has broken and Mozilla would like a definitive fix. Until then, we're high and dry because the request is for the generated build file to be generated correctly rather than just patching the generated build file. That's a much bigger knot to unravel and building the gn tool it depends on used to be incredibly difficult (it's now much easier and I was able to upgrade, but all this has done is show me where the problem is and it's not a straightforward fix). If this is not repaired, then various screen capture components used by libwebrtc are not compiled, and linking will fail. Right now it looks like we're the only platform affected even though aarch64 has been busted by the same underlying issue in the past.

The easy choice, especially if you don't use WebRTC, is just add ac_add_options --disable-webrtc to your .mozconfig. I don't use WebRTC much and I'm pretty lazy so ordinarily I would go this route — except you, gentle reader, expect me to be able to tell you when Firefox compiles are breaking, so that brings us to the second option: Dan Horák's patch. This also works and is the version I'm typing into now. Expect you will have to carry this patch in your local tree for a couple versions until this gets dealt with.

Fortunately, the PGO-LTO patch for Firefox 101 still applies to Fx105, so you can still use that. While the optimized .mozconfig is unchanged, here it is for reference:

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

mk_add_options MOZ_MAKE_FLAGS="-j24" # or as you likez
ac_add_options --enable-application=browser
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 MOZ_PGO=1

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

I've got one other issue to settle, and then I hope to get back to porting the JavaScript and Wasm JIT to 102ESR. But my real life and my $DAYJOB interfere with my after-hours hacking, so contributors still solicited so our work can benefit the OpenPOWER community. When it's one person working on it, things are slower.

Void PPC goes Chimera (and bust)

Void PPC maintainer Daniel Kolesa has announced that instead of simply phasing out big-endian support in Void in 2022, he will instead cease maintaining the PowerPC/Power ISA fork of Void Linux entirely in favour of Chimera Linux, a fusion of a Linux kernel, musl libc and FreeBSD userland built with LLVM. There may even be a return of support for big-endian, at least for 64-bit Power (32-bit Power to be considered), as well as Chimera's core support for ppc64le, aarch64 and x86_64 (with 64-bit RISC-V coming).

As with the announcement for big-endian, if you like Void PPC and want to maintain it yourself, you can — provided you bring your own build and distribution infrastructure. Otherwise, Void PPC maintenance will end in January 2023. You can try Chimera Linux in the meantime and see how it works for you.

The RAD750's successor looks like it's RISC-V

It's been PowerPC in space for decades, from the Opportunity rover (a 20MHz BAE RAD6000, based on POWER1) to the James Webb Telescope (a 118MHz RAD750 "G3"). These are battle-tested processors in extremely hostile conditions, such as the Juno space probe in orbit around Jupiter where the RAD750 (a 132MHz part with 128MB of DRAM) operates in radiation levels a million times the human lethal dose. As evidence of its performance, it was supposed to be deorbited for destruction in 2021, but was extended to 2025 to examine the inner moons of Ganymede, Europa and Io.

Still, PowerPC never had a monopoly: the European Space Agency uses LEON, which is actually a free and open SPARC V8 core, and NASA has also used MIPS processors such as the 12MHz Mongoose-V (based on the R3000) used in New Horizons, which visited Pluto. A cluster of ARM-based "Rad-Tol Dependable Multiprocessors" (PDF) with OMAP 3503 cores will fly on the 6U CubeSat Lunar Flashlight nanosatellite scheduled for later this year after SLS Artemis 1 got scratched. For non-mission critical components, even some off-the-shelf ARM cores have made it to space; the Perseverance rover is another RAD750 system at 133MHz, but the Ingenuity helicopter drone it deployed was a regular Qualcomm Snapdragon 801.

BAE does have later generation Power parts available today: the RAD510 SOC, a system-on-a-chip with twice the performance of the RAD750, and the RAD5500 family with the RAD5545, derived from the ISA 2.06 NXP e5500. These are all Power ISA, all radiation-hardened, and all available from BAE's Manassas, Virginia facility, a U.S. Department of Defense Category 1A Microelectronics Trusted Source. (The RAD510 core is actually made by GlobalFoundries Fab 10 — one of IBM's former fabs.) With those on the shelf it's a bit puzzling that SiFive announced their X280 (U74-derived) core with vector extensions and AI/ML support will be the heart of NASA's next-generation High-Performance Spaceflight Computing (HPSC) processor instead, or more accurately eight of them (an additional four unspecified general-purpose RISC-V cores round out the total to 12). The chips are being developed on a radiation- and fault-tolerant process by Microchip Technology over the next three years, at a cost of US$50 million. More than just the added processing capability, probably what gives it a greater edge is lower expected power usage on a smaller process size and the ability to shut down silicon blocks for even greater power savings.

It would have to be indeed a significant technical leap to justify a complete break from a well-understood architecture and we'll see soon enough if it's worth it. That said, assuming it accumulates the same stellar track record as the BAE Power parts, the RISC-V HPSC will likely have its own decades-long run in space (assuming Jack Kang, SiFive's idiot senior vice president of business development, can stop smoking crack: there are still more PowerPC programmers than RISC-V programmers even now, chumpcakes). For that matter, the ESA is interested in RISC-V too and we approve of any free computing solution as long as it does the job. But don't cry for Power ISA in space yet; with three years of HPSC development to go, and several critical missions in progress, there's plenty of universe to explore no matter what CPU is doing the exploring. As HPSC will just be one choice of many even at NASA, Power ISA parts are likely to remain part of this very conservative industry for awhile, especially in commercial and military applications.

What's Arctic Tern good for, anyway?

Arctic Tern (and its associated soft-BMC Kestrel) is a product that's hard to describe just looking at it. Is it a boot accelerator? Is it a BMC replacement? Is it a development board? Is it OpenPOWER's answer to the Pi Nano? (Answers to pop quiz: yes (in the sense you get the BMC up quicker), yes, yes, and sort of but not really, since the clock speed is too low and it lacks some accoutrements.)

Raptor's new manual should address some of these concerns, and particularly covers the worry I and others had about bricking our system trying to get it installed (disclosure: yours truly reviewed a pre-release copy and submitted comments). Yes, it does need a PCIe slot if you want it to act as a VGA controller or USB host device; yes, it comes with all the necessary cables, including a JTAG programmer; yes, it's compatible with the Blackbird; no, soldering isn't required. But the instructions that are there are step by step and copiously decorated with illustrative photographs such that anyone reasonably handy with their machine should be able to do it.

Instead, the biggest roadblock to the casual interest will likely be the programming: you have to build the FPGA bitstream and firmware image yourself, and then flash your unit manually. The modules don't come preconfigured. (What, did you think that JTAG box was included just for giggles?) Raptor provides Kestrel source and instructions for Debian Linux on an OpenPOWER host in the manual, but the instructions are lengthy, and there is no public build or any other binaries presently available. This is primarily due to the rapid background development but also consider it a minimum "hacker" threshold required to join the club. Other operating systems on Raptor or OpenPOWER hosts should work, but x86_64 users will have to bring up their own toolchains. Raptor did say that at some point there will be "known good" images, though when that will be is an open question since the Kestrel source isn't even close to stable right now. Compared to that, the requirement that you also patch the on-board BMC to disable it in software seems comparatively minor (and it's reversible).

So who's this good for? Raptor may have their own ideas about that, but from over here typing this on my (now switched over to KDE) Talos II, right now I see this product really for someone who wants all the pieces in one place to play with Microwatt to develop their own embedded applications for it. If you're one of those people, you may not even care about the state of Kestrel anyway; to you it would be merely an example. On the other hand, for those of us looking forward to a fully auditable BMC, Kestrel seems to be working but it may not be sufficient (or sufficiently solid) to replace your BMC today and you'd have to jump through a lot of hoops to do it. If that's all you're interested in, you may want to wait. But it comes with everything you need to get started and for those in its apparent target audience, the barriers to entry don't seem unreasonable.

Linux 5.19

Linux 5.19 is released, largely with more hardware support and new architectures (including an unusual super-modern virtual Motorola 68000 platform to emulate Google Goldfish devices — my real Q800, clockchipped running A/UX, is flabbergasted). Here's a full list of changes.

This release doesn't have a great deal of Power ISA-specific improvements, but one generally positive note can be implied from Linus Torvalds' announcement message: he's now on an Apple silicon laptop, running Asahi Linux. Recall that Asahi Linux uses 16K pages as opposed to 4K pages, and this is still the case; many Power ISA workstation users are on systems that use 64K pages, including this Raptor Talos II running Fedora 36. If software bustage is happening for Linus himself, then it's a good sign that more software will start becoming more flexible about allowing larger memory pages and that's good news for us niche configurations too.

Arctic Tern available for purchase

Raptor now has Arctic Terns available for purchase, along with the user's guide. The US$1600 bundle comes with the PCIe carrier card, one ECP5 FPGA module (using Microwatt, the FPGA OpenPOWER core), FSI and JTAG adaptors and all the necessary cabling to connect to a Talos II system (we presume this means the entire T2 family including the T2 Lite and Blackbird, but it doesn't say — more about that in a moment UPDATE: it does now). As it is designed to completely replace the onboard ASPEED BMC, there are fan, Ethernet and two (!) HDMI connectors on board. There is a second module slot as we surmised, but it appears most board functions will be available with just one FPGA module installed, as provided in this bundle (fortunate since an extra module is US$900).

Unfortunately it looks like it does need its own PCIe slot and people like me with a nearly full loadout will be a bit disappointed if that's truly the case. We don't yet know, because the user's guide doesn't look like it has installation instructions for any T2 family system either even though it does have Raptor's usual studious pinouts and schematics. Being primarily a peripheral, I look forward to seeing additional documentation posted since no one wants to buy a $1600 card, get it home and accidentally brick it and their expensive OpenPOWER computer. Once I get my hands on one, we'll talk more about it.