Showing posts from 2022

Firefox 102 on POWER

Firefox 102 is out, not an earth shattering release but with some welcome privacy improvements. It builds out of the box on this Talos II using the PGO-LTO patch from Firefox 101 and the .mozconfigs from Firefox 95.

Firefox 102 is also the basis for the next Extended Support Release, with support for 91ESR (the current version) due to end on September 20 with the release of Firefox 105. Due to a family emergency, I've been out of the country for a bit and haven't been doing much with any projects, let alone the POWER9 JIT (this is why we need more people working on it!). Now that I've been back for a few days and more or less in the swing of things again, it's time to dust it off and forward port the current version to 102 so people doing ESR JIT builds for Fx91 can continue to do so with Fx102. I'll make an announcement and post a patch set when it's ready.

And now a real RISC-V laptop ... maybe

Phoronix is reporting the first production RISC-V laptop, (code?) named ROMA, with "a quad-core RISC-V CPU (although clock frequencies are not noted), a GPU/NPU accelerator [and reportedly other features], up to 16GB of LPDDR4/LPDDR4X RAM [and] up to 256GB of storage." This sounds great, except that I was seriously underwhelmed by the Allwinner D1 in the DevTerm R-01, so the lack of CPU specs is not encouraging. There are also two distinct process nodes for the System-on-Module, 12nm for Pro and 28nm for Normal, so there may be a wide gulf between configurations. On the other hand, it does prominently claim to be upgradable, possibly by swapping out the modules. Strangely, it advertises itself with an ARM SC300 secure enclave, which seems a bit odd as well.

The other thing that's not encouraging, which Phoronix correctly calls bulls**t on, is the proliferation of buzzwords (NFTs! Web3! AR! BINGO!) in the press release. You can register your interest and how many units you want, though I'm understandably not thrilled about signing up for a pre-order from an unknown potentially sketchy company. If actual product emerges, I'll try to get one, but right now this seems more like just another revolution of the RISC-V hype machine.

Fedora 36 mini-mini-review on the Blackbird

I said that Fedora 36 was when I was going to jump ship from GNOME, since I'm not happy with the Adwaita-or-nothing ultimatum GNOME 42 poses squarely at heavy themers like me. The problem is what I'm going to jump ship to.

For the past couple weeks I've been experimenting on the Blackbird to see what window managers and desktop environments seem to work well with Fedora on ppc64le before I try to migrate my main Talos II workstation to whatever I end up picking. But I also know a few of you are itching to upgrade and waiting to see if there were any problems, and of course for those of you running a distro other than Fedora, Fedora's going to find problems earliest. So, this will be a mini-mini-review instead of what we traditionally do: what I've been testing on the Blackbird and how well it appears to work, keeping in mind that my Blackbird is a GPU-less machine using only the ASPEED BMC for graphics and a 4-core CPU with 16GB of RAM. I'd call it "low end," at least within the spectrum of practical OpenPOWER desktops.

The upgrade itself went fairly smoothly. You know the steps to this dance by now, but if you're new to the club, here's the fancy footwork:

dnf upgrade --refresh # upgrade prior system and DNF
dnf install dnf-plugin-system-upgrade # install upgrade plugin if not already done
dnf system-upgrade download --refresh --releasever=36 # download F36 packages
dnf system-upgrade reboot # reboot into upgrader

There were no broken packages and no upgrade glitches, at least on the Blackbird (the Talos II has rather more packages installed). Actually, I was surprised, because this is the release that finally fixes 128-bit long double after literally actual years and watching the PowerPC tracker in Redhat Bugzilla has been very busy of late. But, at least for the vanilla install on this Blackbird, there were no problems. In fact, I know the packages available have increased by at least one, and that one's a biggie. More in a second.

The upgrade was on a black screen again, but if you select the kernel manually from Petitboot you should be able to follow along. Alternatively, you can monitor on the serial port, or from a connected system viewing the serial console over the BMC's web server, or by logging into another VTY with CTRL-ALT-F2 or whatev as root and periodically issuing dnf system-upgrade log --number=-1 to watch log updates. I left it to upgrade while I ate lunch and came back to a clean reboot and a Fedora 36 login prompt.

Recall also that I no longer run a display manager directly on either of my running workstations because of past irregularities with gdm (other display managers may work, haven't tried); I boot directly into a text prompt and do a startx from there. If you are running gdm, lightdm or others, you can probably just select the session type on login and avoid some screwing around with ~/.xinitrc. But first, let's get the Wayland Wasteland out of the, uh, way with a quick XDG_SESSION_TYPE=wayland gnome-session and a heavy dose of antiemetics.

I was unable to appreciate really any difference, good or bad, with Wayland in F36 compared to F35. It still won't support resolutions greater than 1024x768 on BMC graphics, and speed was neither better nor worse; llvmpipe-based applications in particular seem to run roughly about the same as previously, which is to say, not great. My verdict is it's not a regression, which is itself a small victory, and that's as much as I did with Wayland. I then brought GNOME 42 up in X11.
On purpose my Blackbird doesn't have any GNOME themes and only the default extensions that Fedora provides as standard, so this is as vanilla as it gets. Tweaks still allows my Mac pointing memory to deal with closing and window buttons on the left. With the usual modeline 1080p works fine over HDMI in X11.

Fedora has various spins and other window managers available. I'm not going to do everything on the list, but I did a few. The first one I started with is Pantheon, the GNOME derivative from Elementary OS, mostly because it seemed more Mac-like to me. It turns out that the current release is unusually difficult to launch without a desktop manager; even gnome-session --builtin --session=pantheon just puts up a blank background. This is the current launcher I put in ~/.xinitrc:


gala-daemon &
io.elementary.greeter-compositor &
io.elementary.greeter &
(sleep 1 && echo '12' && sleep 1 && echo '25' && \
 sleep 1 && echo '37' && sleep 1 && echo '50' && \
 sleep 1 && echo '62' && sleep 1 && echo '75' && \
 sleep 1 && echo '87' && sleep 1 && echo '100') | \
 zenity --progress --title="Autologin in progress" --text="" --no-cancel --auto-close &
sleep 5 && killall io.elementary.greeter
io.elementary.files-daemon &
io.elementary.wingpanel &
plank &
io.elementary.terminal &
exec gala --replace

It's really ugly, but it does properly load the theming — unless I start up the greeter, the GTK themes seem not to stick. However, I have to kill it so it doesn't hang around. This doesn't fix everything because apps don't seem to update in the dock and a few core components still don't start up right, and you can't log out to the shell without opening a terminal window and doing kill -9 -1, but it's good enough to do this:

And it's also good enough to do this:
Yes, sports fans, the proof that the long double issue is fixed is that MAME is now buildable and now even a standard package on ppc64le. Good job, Dan and folks!

Overall I found the Elementary-on-Fedora experience ... plausible. There are still some pitfalls and I'm not sure how many of them are the fault of my own configuration or something specific to ppc64le or various high-level deficiencies in the packages, but at least one person says it worked great in F35, so maybe I just suck.

Moving along, our next port of call was KDE Plasma. This basically works.

You can enable this either with something like switchdesk, which is a little antiquated, or simply putting exec startplasma-x11 into ~/.xinitrc (or, I suppose, startplasma-wayland, or these alternatives). I was able to get a theme that was good enough working. I know of others using it with Fedora, and it's probably the best secondary and supported option other than GNOME.

I don't have any screenshots of Xfce in F36 yet, but I was experimenting with it on the Talos II for F35, so I have high confidence that continues to work as well. The same is likely true for LXDE.

I also did a couple oddball WMs just for fun and for some new ideas. Other than wmx, which was possibly a little too bare, surprisingly these are more functional than you might think. The first was WindowMaker.

If WindowMaker looks like NeXTSTEP, it's no coincidence since it's a deliberate recreation of the interface. I'm very used to it since my SAIC Galaxy 1100 (a HP PA-RISC 9000/712 "Gecko" workstation in a MIL-SPEC portable case) runs NeXTSTEP 3.3. It's also stonking fast and has little baloney compared to most other window managers, but the interface is not designed to be particularly configurable other than individual menu options and cosmetic themes, and it's not very Mac OS X-like (because Rhapsody, Mac OS X and macOS aren't very NeXT-like). There is a Fedora package for it. Put exec wmaker into ~/.xinitrc.

The other oddball window manager I've played with so far is amiwm. Yes, this is an Amiga Workbench clone. There is no Fedora package for it; I built it from the source code on the Lysator FTP site (Lysator brings back memories since NannyMUD was single-handedly responsible for lowering my undergraduate grade point average freshman and sophomore years), though there seem to be a few patched-up versions on Github. In operation it's pretty much exactly what it says on the tin, screens, gadgets, requesters, Workbench menus and all:

And the damn thing not only works, it's even swifter than WindowMaker and does have the close button on the left. Maybe I've found a modern Amiga I do want. Anyway, the upgrade seems to be good. Go to it.

Firefox 101 on POWER

Firefox 101 is out, mostly of interest to developers but with a few liveability improvements. I suspect breakage of our LTO-PGO patch will be a regular occurrence and Fx101 indeed broke the diff again, but after updating rust, cargo and cbindgen the optimized build works fine with this revised PGO-LTO patch and the same .mozconfigs from Firefox 95.

I can't figure out where the bugs are in our POWER9 Ion JavaScript JIT implementation, though I still strongly suspect it's because we use sign-extended 32-bit ints. This is enough to pass the test suite but still breaks with the web. MIPS does too and we are strongly based on the MIPS port, but one wonders if MIPS suffers from the same issues, and I'm quite sure it's not tested anywhere near as well. As 32-bit arithmetic instructions aren't orthogonal in Power ISA this change would require some significant rearchitecting and I've just come off a really bad week at work, so I'll just try to pull up the current JIT to 102 so that those of you building the new ESR can continue to use Baseline Interpreter and Baseline Compiler, and then it will be time for more major surgery on the source code. You can help (please!).

Mini-review: The Clockwork Pi DevTerm R-01, or RISC-V on the go

This blog is unambiguously pro-Power ISA, not least because I'm a long-time PowerPC bigot to start with, but also I think OpenPOWER — POWER9 specifically — is currently the best option for a practical yet truly open computing platform: competitive performance, auditable stack, solid hardware, and good and steadily improving software support, so there. And that remains my official editorial position as I type this on my trusty Talos II.

But that doesn't mean I'm not other-RISC-curious, and RISC-V gets a lot of ink these days. I'll say for the record I believe much of that ink is hype: RISC-V is only a performance threat on the low end, there's a lot of sizzle and little steak in present hardware choices, and while the ISA may be open the actual implementations vary greatly on that point. I've observed that there are two main markets for OpenPOWER workstations, namely people who want to support alternatives to the x86-ARM duopoly, and those who want a truly libre auditable platform (with some natural overlap between these groups). RISC-V can scratch the itch of the first group, but it's arguable whether the ecosystem does so collectively for the second. That said, all hype machines, to borrow a cow-orker's trenchant expression, easily transform into self-licking ice cream cones and that sort of salivary momentum is why RISC-V is here to stay.

One other thing that RISC-V and OpenPOWER have in common, besides a royalty-free ISA, is that workstations are neither architecture's core market. POWER9 (and Power10 even more so) is still primarily a server and big-iron chip, and extant RISC-V cores mostly lurk in embedded applications (especially the "too cheap for MIPS" segment). But Raptor workstations at least have nerd awareness, while only the even-less-frequently-encountered HiFive Unmatched meets the definition of a RISC-V PC, and the others are just glorified evaluation boards. And even some people complain about the price of that.

For me, though, it wasn't the price that was the problem (I mean, I've got two T2 systems and a Raptor Blackbird and I'm saving my pennies for an Arctic Tern, so I'm all in on POWER); it was the form factor. I'm out of KVM slots and I have too many boxes around the office. If I was going to play with RISC-V as a use-it-like-a-computer user, it needed to be something that I could set up to mess with and tear it down to recover the desk space. Why, it could even be portable. That would be nice. There's no portable OpenPOWER option (yet?), so if there's a totable libre system out there other than those old bizarro Loongsons I'd love to rock one.

So when ClockworkPi announced they were making a RISC-V spin of their DevTerm "portable terminal," and for just US$240 to boot, I said, "Take my money. No, seriously, take it." So they took it, and yesterday about two months later it arrived, fresh from off the DHL boat from COVID-infested Hong Kong Hangzhou Manifest Tech Co Ltd (wait, did I buy a car or a computer?). Today I'll tell you about it.

Here's what this review isn't: in general it's not a review of the CPi DevTerm itself, though necessarily I'll mention some things of relevance. There are many of these reviews based on its previous iteration using aarch64 CPUs (mostly Cortex-A53 and A72) and the R-01 is literally just a DevTerm with a core module swap. Everything you'd like or hate about the form factor largely applies to both flavours, so refer to any of those existing reviews to determine whether you'd want a DevTerm at all regardless of what CPU's actually in it. Instead, I'm going to talk about this device specifically as a RISC-V general purpose computer, either if you'd just like a RISC-V machine to play with or to truly use as an alternative system on the road.

So, about that form factor. Although most people liken the DevTerm to the Tandy Radio Shack TRS-80 Model 100 (the most famous member of the Kyotronic 85 family), actually its design cues come more from the Model 100's close relative, the NEC PC-8201A. (Dig the control diamond: don't tell me that's a coincidence. For some reason CPi chose to make its codes separate from the cursor keys.) But I've used my PC-8201A on the road, for an entire month on Penang Island in Malaysia in 2000 where it was my only computer, and its full-size keyboard made it quite liveable. The DevTerm's a bit ... smaller — 65 percent regular size, to be exact. I have thin fingers (even when I was 45 pounds heavier) and wide hands, and I can sort of touch-type on it, or lift it in two hands and two-thumb-type with my hand width allowing my thumbs to just meet in the center of the keyboard. However, if you lack either of these attributes you may not enjoy the experience, though it has enough ports you could still potentially use it as a desktop system with external input devices instead. (The DevTerm keyboard is also not backlit, but I'm not going to ding it for that at this price point.)

Obligatory unboxing:

The box clearly advertises what's in it and, interestingly, the amount of RAM on the board (at 1GB this seems an odd thing to brag about).

Famously, it comes unassembled. Everything is in nice neat trays and it's actually rather fun to unpack. The plastic standoffs and holdfasts on sprues give it a delightful model-kit feel.

What's not included are a USB-C charger and two 18650 Li-Ion batteries. Neither of those is expensive or tough to find, but you'll need one or the other to actually power it up. There is also no paper for the thermal printer (!) it carries onboard, though any office supply store will have that too.

Case design, schematics and connectors are all GPL and on Github. The RISC-V "core," as CPi calls their CPU modules, sits on anti-static foam in one of the compartments:

CPi modules contain basically everything but storage and peripherals. In particular, the CPU/SoC, GPU (if present) and RAM are provisioned on a 200-pin SO-DIMM and can be swapped out (naturally you'd need to change the operating system at the same time, but that can be as simple as another microSD card). This is a strength of the design because if you don't like the experience with one CPU card (too slow? not compatible?), try another. CPi sells them inexpensively; if you already own an ARM DevTerm you can just buy the RISC-V module for US$29 and download the software. CPi kindly included a RISC-V build of their Ubuntu-based OS with this unit.

In this case, the CPU is an Allwinner D1, a single-core 1GHz RV64IMAFDCVU CPU based on the XuanTie C906 with on-board 2D graphics, DSP, audio/video, USB and SDIO. The DevTerm exposes HDMI, audio and USB external ports directly serviced by the D1. This is the same part in the Sipeed Nezha evaluation board and in a forthcoming SBC from Pine64. Impressively the RTL for the C906 core is open source and Apache-licensed, but unfortunately the rest of the design isn't: in particular the onboard graphics, DSP and peripheral controllers are only available as blobs, and only then if you register as a developer with Allwinner. For CPi's purposes this isn't a killer because their other CPU options are also blobularly blobtastic, but it's a minus in our book. The Hynix chip next to it is the RAM, a single gigabyte as stated. I cannot find any L2 cache at all, just the 32K L1 caches each for I+D.

Another minus is that the C906 and related cores, while they advertise vector instructions, predate the current RISC-V vector instruction standard. The instructions are similar but they are neither binary nor source compatible. On the other hand there's hardly anything supporting the current standard anyway, so this may not be a problem in the long run if the install base becomes large enough.

Getting out the clear orange scaffold and installing the screen, here's a size comparison against a DVD case to give you another idea about how big it is:

As you can see they're roughly the same size. If you'd find typing on a keyboard about half the size of a lengthwise DVD case difficult, the DevTerm is probably not for you. Anyway, let's finish putting it together.
Ta-daa! It took me about half an hour and it was pretty easy with no tools required. The manual goes step by step though they use a lot of part code shorthand that needed some flipping back and forth to check exactly what standoff, etc., I was supposed to be using where. While most of it can be taken apart as easily as it came together, some are glued stick-on components like the little on-board speakers and most notoriously the wireless antenna. I also didn't like the fact the flex cables are a little nervewracking to install and it took a little fiddling to convince myself they were properly seated (plus the video cable in particular has "SCREEN" silkscreened on it, but that end does not connect to the actual screen; it connects to the port marked "SCREEN" on the mainboard). Although it directs you to insert tiny screws to affix the core module to the board, there didn't seem to be any holes drilled on my board and the SO-DIMM socket seemed to hold the core just fine anyway. This might be something specific about the RISC-V module because the assembly manual is generic in scope. Finally, a pro-tip: it's easiest to put in the microSD card during assembly; it felt like I was inserting the card into an empty hole when I did it after, even though it did go in securely.

All that aside I give overall high marks to the fit and finish of the case, though it took me a little time to get the top to mate with the front lip of the bottom. And then there's those Frankensteiny Princess Leia earmuff closures on either side of the screen: they're cute and give it some personality, and they do hold the unit together, and I guess they're better than thumbscrews, but you almost expect them to have some sort of input device functionality and they don't. Missed opportunity, in my opinion. Plus, if you reopen the case the two halves of the closures come apart and have to be snapped back together, which is a little irritating. Once it is together, though, the case feels very sturdy. I liked how it felt in my hands; it didn't feel flimsy or fragile, and it was not excessively heavy even with the batteries in. Total weight according to my kitchen scale is 588g, or about a pound and a quarter.

Booting up! The manual warns it may take up to a minute, which wasn't too far off. The screen is very bright and legible, even considering the 1280x480 resolution is a little odd by modern standards (basically two VGA screens side by side), but it's very glossy and picks up hairs and fingerprints like a magnet. You probably want to have a microfibre cloth around in your bag for this thing.

And booted into CPi's bespoke Ubuntu variant, ClockworkOS. Despite the wiki (it's correct in the on-screen readme), the default username and password are both cpi.
Proof of uname:
ClockworkOS is very lightweight, and thank goodness it is for reasons we'll get into. There's no Wayland crap here; this is Xorg, as G-d Himself intended (especially because — as our frustrations with Wayland on our BMC-only 2D framebuffer Blackbird have proven — Wayland generally does not do well without a GPU even though it's doing better these days than it has). If the window manager looks throwback, it's because it's good old school twm. Fortunately the thumb trackball isn't too bad but there are key combinations for several marquee apps, which I found to be a thoughtful touch.

The status monitor on the right is also very handy, but you'll notice the clock is wrong, and the reason the clock is wrong is because it couldn't contact any time servers. Despite manually creating a network configuration for the house Wi-Fi, the DevTerm wouldn't connect from the front of the house (the Wi-Fi access point is in the server room in the middle) even though every other Wi-Fi capable device I own is able to do so. I was so perplexed by the range I ended up disassembling it again to check if I'd damaged the antenna or if it had come loose when I turned it over to put on the bottom, but the antenna was physically intact and the connector was snapped securely onto the mainboard. The only way it would connect was if it were closer to it. Various Wi-Fi issues have been reported with the DevTerm's relative GameShell, which appears to use the same sort of antenna, though I'm not sure if this is the same specific problem.

There are lots of fun pieces of software pre-installed like DOSBox and Chocolate Doom (and things like GIMP, Inkscape and Xfig if you want to do real work), so I fired up Doom because of course it plays Doom to get an idea of performance. The CPU immediately showed as pegged in the status monitor, which was not encouraging. Neither was gameplay:

I mean, the poor thing's even using a smaller viewport (by default: it started up that way) and the CPU is still straining at 99%. The framerate wasn't slide-show-slow and music and sound effects didn't seem to suffer (use Fn+the volume key to turn up the audio), but you could clearly see it painting each frame.

Web browsing was equally disappointing, but also for different reasons. Firefox on RISC-V is still a work in progress, although there was an Fx94 build at one point; there are patches for Chromium 104, though I wouldn't be caught dead using Chrome or anything derived from it, and neither Firefox nor Chromium are installed in any case. But it does have Qutebrowser, so let's try ... uh ...

Um, okay, how about ELinks?
This worked and might even be more appropriate for the display and CPU anyhow. It was very sprightly. Text for the win. I did go back to Qutebrowser and try QtWebKit despite the warning, and that does start, but ...
Besides the bad rendering, it was also just as slow as playing Doom was. At this point it would seem most appropriate to get an idea of how much oomph this thing actually has. For this we'll use CoreMark, since it's simple, easy to port and verifiable, and it's what many RISC-V vendors cite so this gives you comparison points. ClockworkPi kindly included development tools making it as simple as cloning it from Github and running make.
A couple benchmark results first, using default settings and reporting the highest score obtained: my NetBSD Macintosh IIci (25MHz Motorola 68030, no cache card) gets 8.3 iterations/second, my NetBSD Mac mini (1.5GHz PowerPC G4 7447A) gets 6073.9 iterations/second, my M1 MacBook Air gets 31713.3 iterations/second (single thread) and 171848.9 iterations/second (8 threads), and this dual-8 SMT-4 DD2.3 Raptor Talos II gets 14367.8 iterations/second (single thread) and 430078.6 iterations/second (64 threads). The D1 clocks in at ... 2232.5 iterations/second, just over a third of the performance of the G4 Mac mini, and I can run TenFourFox on that.

Another thing that performs badly on this device: shutting down. It takes literal, honest-to-goodness multiple minutes to power off cleanly. A surprise was the loud "click" it makes when it finally finishes. There doesn't appear to be an obvious way to make it sleep or suspend, though there is a screen saver which turns off the display after a period of inactivity.

I imagine some of these software problems will improve in later iterations, but as it stands this was my out-of-the-box user experience right now (in fairness CPi does say it is a "highly experimental" model, and actively steers new users away from it). I suppose you could try other distros but they may not support (fully) the DevTerm's onboard devices.

Now, something positive: battery life and power consumption seemed really good. The CPU may be weaksauce but it doesn't put a lot of power demand on the hardware either, nor is there a GPU to draw more juice, and the backlight can be easily changed with key combinations or terminal commands. And although there's a tiny little fan on the board I never heard it unless I put my ear right up against it and the device never seemed to get hot even when it was being held at its limits (which was a lot of the time). While the status monitor will show battery percentage (second from the bottom, above the uptime), cat /sys/class/power_supply/axp20x-battery/uevent will display a fuller, different set of statistics that don't always agree. Either way it's thrifty enough I'd estimate you can probably get eight, maybe 10 hours of runtime or more out of a full charge depending on load and battery quality. On the Kill-A-Watt the USB-C charger pulled between 11 and 14 watts depending on CPU load, though even with the CPU pegged in Chocolate Doom it only occasionally drew at the upper end of that range. Incidentally, since the batteries are removeable it's probably more efficient just to shut it down, take them out and stick them in a wall charger at the end of the day.

You might think after all the complaints I've made that I don't like this device. That is absolutely not the case; in fact, I've already become rather fond of it. I'll even go so far as to say that if you want an easy way to try RISC-V and want one you can use like a general purpose computer, and you're not already drunk on the Kool-Aid, then the DevTerm R-01 is your ticket. Clockwork Pi should be commended for offering it and charging less for it on top of that. Offered the choice between a HiFive Unmatched system and the DevTerm R-01, even considering the Unmatched will be somewhat more powerful, I'd still pick the DevTerm. Besides its obvious space and price advantages it's at least got enough grunt to serve as a terminal and do some very basic tasks and do it for hours on easily replaceable batteries, and it comes with sufficient developer tools out of the box that you can test your software on actually available RISC-V silicon today. Plus, with HDMI, USB and Bluetooth, you can just dock it as a desktop system if you don't need it to be mobile. While I certainly had my share of software problems, I suspect they are not at all unique to this particular implementation.

No, my objections here are primarily to the Allwinner D1. For as many claims as RISC-V's proponents make about openness, this chip isn't meaningfully so, and its underwhelming performance doesn't make it worth putting up with. I realize it's aggressively low-end but for crying out loud, it's getting its clock cleaned by a value-spec 2005 Power Mac (the U740 in the Unmatched gets by the G5, but by less than you'd think), and some software still doesn't work on the architecture yet — certainly more so than OpenPOWER. About all it's got going for it is that it can clearly do very well in a portable, power-constrained environment, and it's cheaper than ARM would be in that setting, yet despite such obvious shortcomings it and its progeny are the very chips here and in other upcoming products simply because they exist and survive. Is RISC-V going to be perennially bringing up the performance rear? (Hey, Raptor, want to make a souped-up Arctic Tern in this form factor?) Not for nothing but I don't see anyone selling those ballyhooed Micro Magic parts, and they may well be snake oil. Maybe some future RISC-V system will have sufficient performance, low power usage and full auditability to become a new and self-sustaining libre mobile option, but I'm having a hard time seeing any such CPU on the horizon.

The bottom line: the DevTerm R-01 is fun to play with and makes a stellar introductory RISC-V general purpose computer at a decent price that you can, for some values of "use," use. If you're already a DevTerm owner a measly US$29 for an R-01 module is a slam dunk, and even as a first-time buyer I feel my US$240 wasn't ill-spent. But after this first personal taste of RISC-V, I don't think OpenPOWER has much to worry about right now.

First production Kestrel and Arctic Terns? (OpenPOWER compute modules exist!)

Thanks, D, who's quicker on the draw than I am: this image popped up on the Raptor Wiki. Looks like Kestrel and Arctic Tern made it to full prototyping, and maybe on the way to production!

This image shows a Blackbird being brought up solely with the Kestrel soft BMC (the metadata says the ASPEED BMC was completely disabled), powered by a much more advanced design than the ECP5 card we saw in the last iteration, especially because this is now a set of custom boards. The PCIe carrier card has Ethernet and two HDMI ports to the left, and what looks like JTAG and serial (grey ribbon) on the right near the LEDs. The "hat" board has been incorporated into the carrier with the LPC, FSI (the black cables curling around out and back into frame go to the connector next to DIMM A1) and I2C signals, and a separate ribbon cable carries the TPM lines.

So far, this is mostly just moving components around. But new on this carrier card are two SO-DIMM style module slots, both populated with what looks like the same sort of card, though only the top one seems to be active. These modules are labeled "ARCTIC TERN ECP5 MODBMC (?) CARD AT1MB1 REV 1.01 (C)2022 RAPTOR COMPUTING SYSTEMS, LLC" (there was a rev 1.0? what did we miss?). This is clearly the CPU card on which the Kestrel soft BMC software runs. The BMC flash likely lives on these boards, but not the PNOR, which appears to be on flash chips on the carrier to the left of the LEDs. UPDATE: this thread says the modules have 1GB of DDR3 RAM each (!), and the CPU fan is directly connected to the carrier. They can be accessed remotely.

It really looks like it may be shipping in the very near future and I'm jazzed about how fast Kestrel reportedly can bring the system to power-ready. But there are two more exciting things about this: first, if this is laid out the way it appears to me to be, this means you can have two BMCs for a libre dual-monitor setup right out of the box, no extra PCI cards or firmware blobs required. (Suck it, Nvidia.) Second, and even more notable, this means that OpenPOWER compute modules may soon be a thing! Given Raptor Engineering, I'm sure hoping these will be sold for standalone projects, especially if the onboard Microwatt-core performance is competitive with RPi and other ARM boards. Maybe then the people whining about how much it costs to play with OpenPOWER will finally get something at a lower price point to play with (and then they can complain about that).

That said, we still don't know price or availability yet, and we don't know if there will be a way to add a Kestrel setup without using a precious PCIe slot (after all, the T2 Lite has only three, and the Blackbird just two; hopefully it can be configured to pull power from something else). But there's a lot of good things in this picture and we're looking forward to hearing more in what are no doubt soon-to-come official announcements.

Red Hat Enterprise Linux 9 and AlmaLinux 8.6

And more updates for Linux on OpenPOWER: RHEL 9 and AlmaLinux 8.6. AlmaLinux 8.6 continues on kernel 4.18 from version 8.5 with the usual bug fixes and security updates, plus updated streams for Perl, PHP and log4j and updated toolchains for gcc, LLVM, Rust and Go. ISOs are available. Currently your best bet on OpenPOWER for RHEL-style stability without the RHEL-style price, support for AlmaLinux 8.x is expected through at least 2029.

But hey, let's say in these inflationary times you think support contracts are a good investment. IBM-Red Hat's got you covered with RHEL 9, the first release based on CentOS Stream (version 9) instead of directly off Fedora, meaning this is actually F34 instead of the recently-released F36. This is particularly notable for ppc64le because you won't get the new long double support in F36 (it's "only" glibc 2.34), but then you won't have to deal with the GNOME 42 stupidity either. Fortunately application streams will cover keeping your toolchains current. If you're still on RHEL 8, though, you're still supported until at least 2030, and big-endian systems and others putting along on RHEL 7 will be supported through mid-2024 (with extended support planned for two years after that).

FreeBSD 13.1

FreeBSD 13.1 is now available, notable as it comes in both big-endian and little-endian flavours depending on how you swing (as well as 32-bit ports for Power Macs and the AmigaOne A1222). The biggest change in this version is that 13's shift to the PowerPC ELF ABIv2 makes it binary-incompatible with 12.x (so you may need to rebuild or relink; the release notes also suggest doing kldxref /boot/kernel after successful installation or upgrade). However, there are also fixes for the bootloader on the LE port, OpenSSL performance improvements, a serial console fix for the BE port, a fix for running FreeBSD with HPT superpages enabled on QEMU with TCG (if you're trying before you're buying), and — particularly of relevance to those of us on OpenPOWER hardware — a fix for the AST2500 console on bootup with recent OpenBMC firmware. It's a big update but one that makes OpenPOWER an even better citizen on FreeBSD (now if only NetBSD would get with the program, because at this point it's just embarrassing). Read the release notes, or download.

AOSC for old and new Power

Another choice in OpenPOWER distros, but with another choice for old-school 32-bit PowerPC, too. AOSC/OS (short for "Anthon Open Source Community") is an Debian (formerly OpenSUSE) derivative claiming to have a wide variety of packages and good port parity at the cost of larger space and a generally manual installation process. The desktop experience is KDE, though a server version is also available. Support for POWER8 and up is listed as "experimental" but is available for download, and most packages appear available to ppc64le.

However, another notable feature of AOSC/OS is its planned "retro" spin, including specific support for Power Macintosh, from the G3 through the G5 (the G5 using a 64-bit build). Unfortunately there isn't support yet for other PowerPC or bigendian systems, and the process is even clunkier since it requires another Linux installation as a trampoline, though the trampoline can be an old version. The retro spin also supports Loongson MIPS, Intel i486 and ARM going back to ARMv4; on desktop you have your choice of Trinity, a "spiritual successor" of KDE, or a "retro" X11 experience with IceWM. Currently these downloads are in the Alternative Downloads area.

Fedora 36 released

Fedora 36 is out. This distro is important to me personally as I run it on both my Raptors (my Talos II and my HTPC Blackbird), and even if you don't run it yourself it's a good early warning indicator of future platform issues because new support and features often hit Fedora first. However, I have mixed feelings about this milestone: we get LLVM 14 and gcc 12 and we're finally getting proper long doubles on ppc64le (as part of glibc 2.35), but it's also got GNOME 42, which means my customized, carefully curated to match my muscle memory Mac theme is screwed on GTK 4 apps (but in a worst of all worlds approach GTK 2/3 apps still use any custom theming while new hotness libadwaita apps don't). It might still be better than the alternatives, but it sucks, so in our upcoming usual mini-review (see my F35 one for an example) we might dive a bit into some of the alternative desktop environments offered on Fedora and see how they work on OpenPOWER — I'm thinking about Pantheon, myself. As usual, the review will come out in a week or so once any immediate breakers are identified and mirror sites have caught up. Meanwhile, here's the complete list of changes.

Firefox 100 on POWER

You know, it's not been a great weekend. Between striking out on some classic hardware projects, leaving printed circuit board corpses in my living room like some alternative universe fusion of William Gibson and Jeffrey Dahmer, one of the yard sprinkler valves has decided it will constantly water the hedge (a couple hundred bucks to fix) and I managed to re-injure my calf muscle sprinting to try to get a phone call (it went pop, I yelped and they hung up anyway). But Firefox is now at version 100, so there's that. Besides the pretty version window when you start it up, it has captions on picture-in-picture and various performance improvements.

Fx100 also broke our PGO-LTO gcc patches again; mach now needs to be patched to ignore how gcc captures profiling information or it will refuse to start a PGO build. This is rolled into the ensemble PGO-LTO patch, which works with the same .mozconfigs from FIrefox 95.

Between everything that's been going on and other projects I've wanted to pay attention to I don't think we're going to make the Fx102 ESR window for the POWER9 JIT. I'll still offer patches for 102ESR; you'll just have to apply them like you do for Firefox 91ESR. Meanwhile, I'll keep trying to get the last major bugs out as I have time, inclination and energy, but although I know people want this really badly, we need more eyes on the code than just me.

Tonight's game on OpenPOWER: Death Rally

Let's go for another shooter, but this time a top-down one. Essentially a murderous Super Sprint, Finnish developer Remedy's first game was the exuberantly zippy Death Rally, a decidedly socially hostile top-down racer with machine guns, bombs, spikes, sabotage, splattable spectators and cold hard cash. You can pick up missions for extra money (assassinations, drug running, the usual) or just exterminate your competition for a big bonus and plow the proceeds into a better chassis, a faster engine and better tires and armour. Apogee picked it up and added Duke Nukem for extra competition along with Remedy's cadre of obviously named parody racers (just try to guess who Bogus Bill is).

While Death Rally plays well in DOSBox, and even got an official freeware Windows port, there was never a Mac version (I had to play it on my beat-up old 486) and it was never open-sourced. A few attempts have been made to decompile it but the best of these is dRally, which is 64-bit compatible and compiles out of the box (just make -j24 or as you like for your number of cores) with SDL2 on Fedora 35. The old IPX multiplayer mode isn't supported but everything else mostly works.

Once it's compiled, you'll need a copy of the game assets, of course. I have the GT Interactive retail CD; I have not tried to extract it from the Steam version, 3D Realms no longer sells it directly, and I can't find it on GoG, so let's assume you've got a disc too. For that, just copy over all the *.BPA files (make sure they remain uppercase!) and the CINEM subdirectory from the CD. Create a file called CDROM.INI that simply has one line, ./CINEM (to tell it where the movies are). Start the game in that directory (I made a directory called assets that has everything in it and just symlinked ../drally_linux for convenience).

There are two bugs I ran across, neither serious. The DOS game alternates between 640x480 and a letterboxed (in SDL) 320x200 mode; the former is used for menus and the latter for videos and actual gameplay. On my Talos II in Fedora 35 with a WX7100 there's a lot of garbage in the letterboxed area which can be improved, though not completely eliminated, with this patch. Also, at least with my GT retail copy, if you let the game sit at the menu too long it will eventually go through its brag screens and crash when it hits one that doesn't seem to be in the archive. This patch wallpapers the problem.

Otherwise, I've been gunning down other cars all afternoon, and I haven't had to fire up DOSBox to do it. Get ready to go!

Attack of the zombie PowerVR GPUs

Like rotted silicon corpses, several new recent GPU cards based on Imagination Technologies' old school PowerVR IP have emerged in the Chinese market, including the Innosilicon Fantasy One series and most recently the Moore Threads MUSA family. Don't kid yourself either about these being particularly more open than AMD and Nvidia offerings, though support for the Rogue GPUs is landing in kernel and in Mesa3D; while there is fairly good documentation on the GPU's ISA the firmware is still likely to be binary blobs (though this is no worse than the alternatives). Moreover, their performance even from the OEM specs just isn't competitive with current cards. That said, any GPU at all beats the flat framebuffer of the ASTs in our systems, and these chips may move more slowly enough to be more stable in the kernel compared to the occasional churn with amdgpu and friends. Assuming it can be flexible on page size, another alternative GPU architecture, even a basic one, would be welcome (at least until the Microwatt-based Libre-SoC is a viable option). We'll be watching that space.

Firefox 99 on POWER

Firefox 99 is out. The major change here is that the Linux sandbox has been strengthened to eliminate direct access to X11 (which is important because many of us do not live in the Wayland Wasteland). Note that the sandbox apparently doesn't work currently on ppc64le; this is something I intend to look at later when I'm done with the JIT unless someone™ gets to it first.

Unfortunately, Fx99 does not build from source on ppc64 or ppc64le and I was too busy on the JIT to do my usual smoke tests early. The offender is bug 1758610 but the patches do not apply cleanly to 99, so I have provided a consolidated diff for your convenience. You will also need a tweaked PGO-LTO patch; with those applied the .mozconfigs from Firefox 95 will work.

All three stages of the JIT (Baseline Interpreter, Baseline Compiler and Ion, as well as Wasm) now function and pass tests on POWER9 except for a couple depending on memory layout oddities; that last unexpected test failure took me almost a week and a half to find. (TenFourFox users will be happy because a couple of these bugs exist in TenFourFox and I'll generate patches to fix them there for source builders.) However, it isn't shippable because when I built a browser with it there were regressions compared to Baseline Compiler alone (Google Maps fonts look fuzzier in Ion, the asm.js DOSBOX dies with a weird out of range error, etc.). The shippable state is that Ion should be a strict superset of Baseline Compiler: it may not make everything work, but anything that worked in Baseline Compiler should also work with Ion enabled, just faster. These problems don't seem to have coverage in the test suite. You can build the browser and try it for yourself from the new branch, but make sure that you set the Ion options in about:config back to true. Keep in mind that this is 97.0a1, so it has some unrelated bugs, and you shouldn't use it with your current Firefox profile.

Smoking out these failures is going to be a much harder lift because debugging a JIT in a heavily multi-threaded browser is a nightmare, especially on a non-tier-1 platform with more limited tooling; a lot of the old options to disable Electrolysis and Fission seem to be ignored in current releases. With that in mind and with the clock counting down to Firefox 102 (the next ESR) I've decided to press on and pull down Firefox 101 as a new branch, drag the JIT current with mozilla-central and see if any of the added tests can shed light on the regressions. A potential explanation is that we could have some edges where 32-bit integer quantities still have the upper word set (64-bit PowerPC doesn't really have comprehensive 32-bit math and clearing the upper bits all the time is wasteful, so there are kludges in a few places to intercept those high-word-set registers where they matter), but changing these assumptions would be major surgery, and aside from the delays may not actually be what's wrong: after all, it doesn't seem to break Baseline. One other option is to deliberately gimp the JIT so that Ion is never activated and submit it as such to Mozilla to make the ESR, and we'd have to do this soon, but indefinitely emasculating our Ion implementation would really suck to me personally and may not pass code review. I'm sure I've made stupid and/or subtle errors somewhere and a lot of code just isn't covered by the test suite (we have tons of controlled crashes, asserts and traps in untested paths, and none of it is triggered in the test suite), so I really need more eyes on the code to see what I can't.

Asahi Linux gives hope for weird page sizes yet

Asahi Linux, a new distribution for Apple silicon-based machines (which sounds like some Star Trek silicon-based lifeform), has made an official alpha release. Although we've got a couple M1 systems here at Floodgap Orbiting Headquarters, that's not really the reason we care about it here. The reason is that Asahi Linux is currently a 16K-page system.

Recall from our previous article that many Power ISA distros, most notably Fedora, default to a 64K memory page for performance reasons rather than the more typical 4K page seen in most operating systems and on most x86_64 machines. (Void and others, on the other hand, are 4K.) This was also true of aarch64, which Fedora and RHEL also used 64K pages for, but Fedora moved to 4K pages on that architecture to cater to small devices like the Raspberry Pi and issues with the Continguous Memory Allocator.

However, Asahi Linux's choice of a 16K page size is even more unusual and not all aarch64 implementations support it, though that's irrelevant on the specific machines they cater to. From the docs, it was chosen because it "both performs better, and is required with our kernel branch right now in order to work properly with the M1’s IOMMUs." Like 64K pages this breaks software that assumes a 4K page size. Most notably for Asahi this breaks Chromium (trying to find sympathy, still trying, still trying, sympathy failed) but also jemalloc and a number of other things.

The fact that a more high-profile architecture also relies on an atypical page size is good news for us, because while there are plenty of projects that couldn't care less about ppc64le, those same projects are much more likely to pay attention to the same problem on an M1 Mac. If the fixes they upstream aren't lazy and support all of the page sizes aarch64 does (4K, 16K and 64K), then this in turn will help 64K-page OpenPOWER systems like the one I'm typing this on. To the extent that happens, we should thank the hackers on Asahi Linux, because they will have made it possible.

The first production RISC-V portable?

Yes, there have been various one-off RISC-V kinda-portables, just like there have been various one-off RISC-V kinda-workstations. But it was inevitable a production "RISC-V PC" would become available, and now there's a new first, a RISC-V version of the Clockwork DevTerm portable.

The DevTerm series is clearly inspired by the Kyotronic 85 family, which many people will remember in the form of the TRS-80 Model 100. This warms my heart because an NEC PC-8201A (the other white meat) was my one and only portable computer for a month when I was overseas in Malaysia and Singapore in 2000. (It acquitted itself fabulously, for the record.) The keyboard is unfortunately smaller (one review of the ARM version compared it to an HP 200LX, which is a small keyboard indeed) and it's not touch-enabled, but the machine is very modular and apparently all that was necessary to go R5 was a redo of the OS and a new CPU-memory card (which you can buy separately for anything that will accept a Raspberry Pi compute module form factor). The CPU appears to be an Allwinner D1 containing a OpenXuantie C906, a 1GHz RV64IMAFDC(V)U single core with 1GB of memory onboard. There is no GPU, just a framebuffer.

Bluntly, these are underwhelming specs (the specs for the HiFive Unmatched didn't get my sizzle zizzled much either), and even the lowliest 4-core POWER9 Blackbird or T2 Lite would smash a HiFive into itty bitty little RISC bits. Against this, well, I think my iBook G4 wouldn't have much to worry about. But there's no portable option for OpenPOWER yet, and while a Microwatt or Libre-SoC system might get there one day — perhaps as a compatible compute module, even — this is here today, and could be a worthy mobile complement to an OpenPOWER desktop workstation. I haven't reviewed their Github exhaustively, but the C906 seems to be open-source. Plus, even though the specs are lower than their other ARM-based offerings, it's also the cheapest (the set is $239, but the CPU-memory card is just $29). This is convenient and inexpensive enough that I've squeezed a bit out of our budget to order one and I'll do a review here when it arrives. I'm unquestionably a Power ISA bigot at heart, but that doesn't mean I'm not Five-curious.

Firefox 98 on POWER

Firefox 98 is released, with a new faster downloads flow (very welcome), better event debugging, and several pre-release HTML features that are now official. One thing that hasn't gotten a lot of airplay is navigator.registerProtocolHandler() now allows registration for the FTP family of protocols. I already use this for OverbiteWX and OverbiteNX to restore Gopher support in Firefox; I look forward to someone bolting back on FTP support in the future. It builds out of the box on OpenPOWER using the .mozconfigs and LTO-PGO patch from Firefox 95.

On the JIT front the Ion-enabled (third stage compiler) OpenPOWER JIT gets about 2/3rds of the way through the JIT conformance test suite. Right now I'm investigating a Ion crash in the FASTA portion of SunSpider which I can't yet determine is either an i-cache problem or a bad jump (the OpenPOWER Baseline Compiler naturally runs it fine). We need to make Firefox 102 before it merges to beta on May 26 to ride the trains and get the JIT into the next Extended Support Release; this is also important for Thunderbird, which, speaking as a heavy user of it, probably needs JIT acceleration even more than Firefox. This timeframe is not impossible and it'll get finished "sometime" but making 102 is going to be a little tight with what needs doing. The biggest need is for people to help smoke out those last failures and find fixes. You can help.

Red Hat halts sales and services in Russia and Belarus

The blog post buries the lede a bit, but "[e]ffective immediately, Red Hat is discontinuing sales and services in Russia and Belarus (for both organizations located in or headquartered in Russia or Belarus). This includes discontinuing partner relationships with organizations based in or headquartered in Russia or Belarus." Undoubtedly a reaction to sanctions against Russia, this probably doesn't affect CentOS or (especially) Fedora, which remains a common distribution for OpenPOWER systems. If you're an OpenPOWER user in the war zone (and please keep your observations to that topic), do post in the comments and stay safe. 🇺🇦

Tonight's game on OpenPOWER: Aleph One and the Marathon series

I had mentioned in the article on SheepSforza, our OpenPOWER port of classic MacOS emulator SheepShaver, that the famous Mac shooter Marathon and its sequels run fine under emulation. Marathon, the first big product from Bungie who went on to create Halo, was a 2.5D game with texture mapping, lighting, sprites and sectors like Doom, but did Doom better by having room-over-room levels (using a portal renderer and polygon tags), free look, a complex plot told through in-game terminals, and a more sophisticated physics model including low-gravity and vacuum environments. Marathon 2: Durandal introduced a more advanced engine with fluid environments you could swim in (often not to your benefit) and larger, more expansive outdoor levels; this version of the engine was licensed for a couple other titles like the bizarre messianic shooter ZPC, and used with minor changes in the third installment, Marathon Infinity. For my money M2 was the best of the series: the original Marathon was understandably a little underdeveloped, and Infinity's convoluted time-shifting plot was very hard to wrap your head around, but M2 had just enough story complexity to be interesting and a bit more varied gameplay to keep you engaged through the tougher parts.

Also like Doom, Bungie eventually released the source code, in this case to Marathon 2 which was the only version of the engine to run anywhere other than the Mac. Marathon Infinity was also later released in source form, and both games became the nucleus of a modern reimplementation, Aleph One. But again, Bungie did Doom better: they also released all three games' assets for free too, so you don't need to hunt down a CD to play it legally. I happen to own a copy (bought new back in the day) of the Mac Action Sack, but this is even better — especially because I don't remember where the canvas bag went.

Aleph One runs all three official installments, plus a number of total conversions, hobby scenarios and even a port of the Wolfenstein-esque Pathways into Darkness, Bungie's banner 3D game prior to Marathon and arguably in the same universe. (It was also one of the first games to run native on the then-new Power Macintosh, so it's special to us here in OpenPOWER land.) Strangely, one game it doesn't run is ZPC, which is a bummer because it's truly one of a kind. However, I think Marathon 2 is (again) the best Aleph One game as it has the fullest selection of high-resolution textures from the Xbox Live Arcade remaster; the other two games don't look nearly as good.

For this brief tutorial we'll assume you're playing M2 (the process with the others is similar). Download game assets and unzip them to ~/.alephone/Scenarios/Marathon2 (such that you see all the .???A files, Music.ogg, etc. in that directory). Put any plugins (the high-resolution assets are plugins) into ~/.alephone/Scenarios/Marathon2/Plugins (I unzipped them also, but strictly speaking this isn't necessary if you have all the requisite libraries when you build the actual game binary).

Now build the game engine. The Github build instructions work out of the box for Fedora 35 on my Talos II (and presumably should work for Ubuntu), and other distros should be similar. However, I built Aleph One with CFLAGS="-O3 -mcpu=power9 -flto" CXXFLAGS="-O3 -mcpu=power9 -flto" ./configure to give it a little extra juice, and then make -j24 (or as your number of cores permit). To start the game, assuming you have the Github in ~/src/alephone, ~/src/alephone/Source_Files/alephone ~/.alephone/Scenarios/Marathon2 will transport you to Lh'owon. I recommend turning on all the graphics options under Preferences (the screenshot here has hi-res textures for everything along with lighting bloom); with the Raptor BTO WX7100, the game runs like butter, so take advantage of it. In particular, make sure the frame rate is unlimited and filter and antialias all the things if you have a GPU. On the other hand, with an AST2500-only OpenPOWER system, set the rendering mode to Software instead of OpenGL and you'll get a decent (classic) experience, though you may wish to not use the hi-res version for speed purposes.

The only good BOB's a dead BOB.

Faster framebuffer landing in Linux 5.18

Code to speed up software framebuffer operations — which is all you get if you're running a Raptor family system without a GPU through the on-board BMC graphics — is due to land in the upcoming 5.18 kernel's merge window later this month. In component commits, the developer cites as much as a 25% improvement in some operations. Much of this gain seems due to just second-guessing the compiler: using the existing high performance memset/memcpy operations (and on OpenPOWER, these take full advantage of the SIMD capabilities in our CPUs) instead of relying on the compiler to auto-vectorize, and manually unrolling loops. This will still be slower than a GPU, and the Libre-SoC project aims to fill that gap with a libre alternative, but for those of us (like me) running a Raptor system "naked" with onboard hardware, this is very welcome news. We'll look at some of the other Power-specific and Power-adjacent changes in 5.18 later this month when the merge window closes.

Intel gets worse, but Power11 might get better

Just in case we needed any more reassurance we made the right move with OpenPOWER: Phoronix is reporting that Intel is about to get even more restrictive with firmware. For as much flak as Intel (deservedly) takes over the Intel Management Engine and other closed highly-privileged blobs, the actual Firmware Support Package has so far been open source and royalty-free (it's what's layered on top that's the problem). There isn't a smoking gun or significant direct context in this Twitter thread, but the issue seems to be around the upcoming "Scalable FSP" architecture. Previously, open source firmware had control on initialization and could call into the closed blobs (or not) as necessary, but FSP 3.0 seems to invert this, giving a new closed blob control to call into the open source firmware (or not). This lets Intel cut projects like Coreboot on x86_64 out of the picture, and can only be seen as a way to directly subvert their operation. A lot of this stuff is under NDA currently but as systems incorporating FSP 3.0 start appearing we should begin to get a clearer understanding.

By the way, don't expect AMD to act any better. Remember that they're the company bringing you Pluton: quoted from the article, "Pluton will also prevent people from running software that has been modified without the permission of developers." It wouldn't be surprising to see AMD's Platform Security Processor pick up additional lock-in capabilities to reinforce this and other vendor controls.

Meanwhile here in the computing underground, we have our own problems with Power10, but there may be some light on the horizon for Power11. It was always a mystery after POWER8 and POWER9's completely open firmware why IBM would take a sudden wrong turn with Power10, but this unsubstantiated post from the same thread (if it's not wishful thinking) suggests COVID staffing issues rather than philosophical concerns were to blame for IBM using off-the-shelf vendored IP blocks requiring the existing blobs in its firmware.

I don't know who that is, or what internal events at IBM they're privy to, so it should be taken with a grain of salt. (If they read this blog, feel free to follow up in the comments or with me in E-mail.) Still, it makes more sense than IBM suddenly slamming the door on OpenPOWER after the tremendous goodwill built up with POWER8 and especially POWER9. It does also suggest, however, that the situation with Power10 is more or less baked in. The roadmap for POWER9, currently the OpenPOWER architecture with the widest install base, basically blew up and the long-promised POWER9 AIO "Axon" or "Axone" never arrived. I'm predicting that Power10 will have a smaller install base than POWER9 because it's still IBM-exclusive, no other vendors so far have announced machines, and Raptor (the only "low-end" vendor of OpenPOWER workstations) has said they won't ship a Power10 system with blobs. If there wasn't enough money on the table to release Axon for IBM's biggest OpenPOWER ecosystem, there won't be for a newly-freed "Power10+."

But there's plenty of time for Power11, possibly landing in the 2024-5 timeframe, just in time for POWER9's technological ebb. And if simple humanpower really was the reason IBM took shortcuts, hopefully their staffing and design teams will be in a much better place by then (wars, pestilence, locusts and inflation notwithstanding). It would come just in time because what makes OpenPOWER a compelling alternative to x86_64 and Apple ARM (and what so far has eluded RISC-V) is performance. I'd like to see Power11 continue to keep us in the game — but without compromises this time.

AlmaLinux 8.5 now stable on ppc64le

AlmaLinux, one of the "new" classic CentOSes after CentOS was reworked into the a-bit-more-fizzy CentOS Stream, has now updated their 8.5 beta release for ppc64le officially to stable status. This is probably your best bet if you want a no-cost RHEL-like experience on your OpenPOWER hardware with the stability reputation you used old-school CentOS for. Release notes and Live ISO images are available. Currently AlmaLinux 8 has a support commitment until at least 2029.

Vikings' OpenPOWER store is open

Rejoice, folks on the other side of the Atlantic: now you can buy the hardware you want from a source closer to home. Vikings' OpenPOWER store is now showing items in stock, including Raptor Talos II and T2 Lite full systems, T2 Lite boards, DD2.2 and DD2.3 POWER9 CPUs up to 22 and 18 cores respectively, and heatsinks and HSFs (and the hex driver needed to install them). The T2 and T2 Lite full systems in particular are different from what Raptor sells on this side of the pond: Raptor T2 systems currently come in Supermicro SC747 chasses with redundant 1620W PSUs but the Vikings flavour comes in Phanteks Enthoo Pro 2 towers with a 650W PSU. Vikings T2 Lites start at €4158/US$4713 with VAT and full T2s at €5707/US$6467 with VAT, and both include 16GB of RAM and a single 4-core DD2.2 POWER9 with 3U HSF. You can of course add a GPU, 2nd CPU, RAM, SSD, bigger PSU, etc. to order, and if you're in Aachen, Germany, you can even drop by and pick it up. No word on Blackbird sales yet but we're sure that's on the way as the supply chain improves and Raptor is able to manufacture more, and in the meantime the T2 Lite remains a solid alternative. Note that while their OpenPOWER store is separate from their RYF products, the T2 and T2 Lite are still absolutely FSF RYF. Systems are available for order now. Let's support the companies that support us.

Chimera Linux test ISOs available for ppc64le

Chimera Linux, an upcoming Linux distro with a FreeBSD userland so you don't have to choose, now has downloadable test images for ppc64le and x86_64. The little-endian Power images, which we care about here obviously, are available both as straight-up console (which can be redirected to the onboard serial port) and GNOME-or-console flavours, and require a POWER8 or higher. The GNOME spins (screenshot at right) use Wayland by default but also allow X11 with a bootloader configuration. There's still a lot in flux, but it's impressive the OS is this far along, and certainly offers something more substantial to the Power community than the usual distro dance. For more info, see the FAQ, or download ISO images from the download page.