FreeBSD considering end of ppc64 support

FreeBSD is considering retiring powerpc64 prior to branching 16, which would make FreeBSD 15 the last stable version to support the architecture. (32-bit PowerPC is already dropped as of FreeBSD 14, though both OpenBSD and NetBSD generally serve this use case, and myself I have a Mac mini G4 running a custom NetBSD kernel with code from FreeBSD for automatic restart.) Although the message says "powerpc64 and powerpc64le" it later on only makes specific reference to the big-endian port, whereas both endiannesses appear on the FreeBSD platform page and on the download server.

I asked Warner Losh for clarification but he hasn't gotten back to me yet, so it's unclear if this is meant to apply to just the BE port or both. Unlike the overall industry mood generally, especially from you underannuated whippersnappers who deal with the doublethink of big-endian math in your head but little-endian code in your repos, the BSDs have historically been friendly to big-endian hardware as a means of ensuring code correctness. Indeed, his note acknowledges this. One sticking point seems to be Power ISA's own unique architectural features but I suspect it is due at least as much to the higher cost and poorer availability of the hardware, which has admittedly been thin on the ground lately.

My preference in server operating systems is a BSD-variant and FreeBSD was going to be my own migration plan when I retire my POWER6 running AIX (big-endian, natch), but this news has made me consider OpenBSD/powerpc64 instead. This port is a little suboptimal in that it states it does not presently run under a hypervisor, but it is currently well-supported and specifically tested on Raptor hardware, which is going to be the majority of the ecosystem. Of course, OpenBSD is also a famously opinionated operating system, so there may be a little bit more of a learning curve for me personally, whereas I already have experience with FreeBSD on shared x86_64 hosting and my other BSD systems all run NetBSD (on /mac68k, /cobalt, /macppc, /alpha, /hpcmips and /hpcsh). Another possibility is to try to maintain security patches and fixes on the remnant of FreeBSD 15, though I have such limited time these days I'd prefer not to pour it into another endeavour with an obvious future dead end. I'd dearly love a NetBSD option, but there isn't a NetBSD port that runs on POWER9.

I do think it's a little unfair to cite the user base as being less than "x86 or armv7" when these were extremely common architectures in their day, and a lot of people are probably still running FreeBSD on older examples to get the most money they can out of their hardware. I can't imagine their RISC-V numbers are very high either but no one is saying that should go away, and Power ISA is still very relevant in today's big-iron shops. If and until "low-end" Power11 desktop hardware is available, we'll want all the operating system support we can get too.

Debian 13 Trixie

Debian 13 is out, which like most other architectures is one of the big three distros on ppc64le (which Debian calls ppc64el in accordance with its normal naming scheme). The current release is based on the LTS kernel 6.12, glibc 2.41 and systemd 257, and includes GNOME 48, KDE Plasma 6.3, LXDE 13, LXQt 2.1.0, Xfce 4.20, gcc 14.2, LLVM-Clang 19, bind 9.20, Perl 5.40, and Python 3.13. ppc64el is one of the supported seven architectures and boots directly on all current Raptor hardware. As with all kernels with a 4K page size, if you try to use KVM acceleration in QEMU with a 64K page size guest (the default), it will fail. This doesn't occur on Fedora because Fedora ships a kernel with a 64K page size. Fortunately, see this note for workarounds by either setting a 4K property on the guest or using a 64K page size on the OS side. Live and installer images are available.

Power11 hits the market this month

IBM made the date official: Power11 launches July 25, with the 32 AI-core Spyre Accelerator expected to follow in the fourth quarter. IBM's launch products will be the full-rack Power E1180 with up to up to 256 SMT-8 Power11 cores with 2MB L2 each and up to 128GBMB of shared L3 (8GBMB per core with the correct figures in the Red Book) with 64TB of DDR5 memory, the midrange 4U Power E1150 with up to 120 Power11 cores and 16TB of DDR5, the junior 4U Power S1124 with up to 60 Power11 cores with 8MB of L3 per core and 8TB of DDR5, and the "low-end" 2U Power S1122 with up to 60 Power11 cores and 4TB of DDR5. The processors come in 16, 24 or 30-core versions; the E systems have four sockets (with up to four nodes in the E1180) and the S systems have two. All four systems can run AIX and Linux, and all systems except for the E1150 can run IBM i. As is usual for IBM's initial offerings, internally they look like straight-up implementations of the Blueridge reference platform and should be expected to scale accordingly. And if you have to ask how much they are, well ...

It's notable that the "meet the family" document IBM links from the press release — so we can assume it's officially blessed — says nothing about OMI, only DDR5 RAM. However, IBM has made it clear that Power11 will continue to have OMI, since enterprise Power10 customers would certainly have had an investment in it, and the upper tier datasheets reference OMI channel capacity. We don't know if the OMI firmware for Power11 is open and libre (it was not in Power10), nor if the Synopsys IP blocks reportedly used in Power10's I/O are still present, because IBM didn't say, or if the "low-end" binned CPUs are different in this regard.

If there are going to be third-party Power11 systems, and IBM didn't say anything in the press release about them either, they generally follow six to twelve months after. We have heard little from Raptor since about the SolidSilicon S1 and X1, and because all indications suggest the S1 is a Power10 implementation without the crap, this already puts them behind the curve. That said, adapting Power11 should be possible to any next-generation Power ISA workstation: the Talos II and T2 Lite are fairly straightforward reworks of the reference POWER9 Romulus design, and Blackbird is still Romulus, just in a much smaller form factor. These first-generation P11 boxes, as presumably performant as they are, wouldn't be nice to have in an office and IBM just doesn't do end user sales. Creating a T3 based on Blueridge would seem to be the best way forward for Raptor to regain the top slot in OpenPOWER workstations — assuming the architecture is still open.

[UPDATE: I have been advised by an anonymous individual with knowledge of the situation that a new Raptor announcement on products under development is scheduled for Q1 2026 ... which would be "six to twelve months after" as predicted. "Open firmware" is specifically mentioned and absolutely planned. It's worth pointing out that both Raptor and SolidSilicon are now listed as top-tier Platinum members for OpenPOWER parallel with IBM itself. That implies SolidSilicon is still in the mix and IBM is still backing OpenPOWER. They stressed this is not an official announcement, so you take it for what it's worth.]

Enter the IBM z17 mainframe with Telum II (more clues for Power11?)

IBM is announcing their new z17 mainframe, based on the Telum II (see our notes on the original Telum CPU). IBM first announced the Telum II last year and the z17, its intended first deployment, has now emerged just about bang on time.

Still, we're obviously more interested in Power ISA around here, and IBM has yet to say much substantive about Power11 other than the usual assertions of additional power efficiency, more cores and higher clock. It is also expected to offer DDR5 support for enhanced memory bandwidth, though this is all but certain to require OMI DDR5, not direct-attached RAM as in our Raptor boxes. But it's often instructive to look at what's going on with IBM mainframes for microarchitectural clues now that Z-machines and IBM "big" Power chips often have the same underlying design.

The first Telum strongly emphasized cache. Interestingly, it did so by dropping categorial L3 and L4 altogether: instead, IBM developed a strategy where cores could reach into the L2 of other cores and treat that as L3, and reach into other chips' cache and treat that as L4. Each chip had eight cores and 32MB of L2 per core, giving lots of opportunity for more efficient utilization. The picture of the Telum II die above shows that IBM has not substantially deviated from this plan, using the same 128K/128K L1 but increasing L2 to 36MB per core. IBM's documentation says that there are eight cores per chip, but at a cursory glance there appear to be ten on the die, likely for yield reasons (two cores would be fused off). Assuming these dud cores still have useable cache, however, that matches IBM's specs of up to 360MB of effective L3 and a whopping 2.88GB of L4 per system.

The cores top out at 5.5GHz with various microarchitectural improvements such as better branch prediction and faster store writeback and address translation, all the typical kinds of tweaks that would also likely show up in Power11. Power11 is also expected to remain on 7nm with a "refined" process instead of moving to 5nm. (It's possible that Power12, whenever that arrives, may skip 5nm entirely.)

Of course, the marketing material on z17 is all AI all the time. IBM's claimed AI improvements seem to descend from an enhanced "DPU" ("data processing unit") with its own 64K (32K instruction/32K data) L1 cache capable of 24 trillion INT8 operations per second, the kind of bolt-on hardware that could also be incorporated or scaled-down into other products. In fact, such a product exists already, shown above: IBM's Spyre Accelerator, which is basically 32 more DPUs. These attach over PCIe and would be a good alternative to our having to scrabble around with iffy GPU support, assuming that IBM supports this in Linux (but they already do for LinuxONE systems, so it shouldn't be much of a stretch).

If you have the money and a convenient IBM salesdroid who actually answers the phone, you too can horrify your electrical utility starting in June. As for those of us on the small systems side, Power11 in whatever form it ends up taking is not anticipated to emerge until Q3 2025, presumably as what will be the E1100 series starting with the E1180 and going down. This further shrinks the production and sales window for the long-anticipated Raptor S1 systems, however, and there hasn't been a lot of news about those — to say nothing of what the Trump tariffs could mean for rolling out a new system.

Plan 9 finally comes to the POWER9

A great announcement today from the 9front team: ongoing support for ppc64. Today's release finally brings the groundbreaking Plan 9 operating system to our platform as a preferred architecture, with big endian a first-class citizen. It's idiosyncratic, sometimes baffling and at times deliberately outright user-hostile, but now you have a choice of operating systems and can truly use our refreshingly different computers with a refreshingly different user interface paradigm. I'm downloading and installing it on the Blackbird right now and I'll report back with a full review in detail.

Also, I'm well aware of the calendar, thanks.

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

UPDATE: The patch has been retracted, see comments.

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.

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.

Chromium Power ISA patches ... from Solid Silicon

It appears that some of the issues observed by me and others with Chromium on Fedora ppc64le may in fact be due to an incomplete patch set, which is now available on Solid Silicon's Gitlab. If your distro doesn't support this, now you have an upstream to point them at or build your own. They include the Ungoogled changes as well, even though I retain my philosophical objections to Chromium, and still use Firefox personally (I've got to get back on the horse and resume maintaining my personal builds now that I've got Plasma 6 back running on Xorg again).

Oh, yeah, it really is that Solid Silicon. You can make your own speculations from the commit log, though regardless of whether Solid Silicon is truly a separate concern or a Raptor subsidiary, it wouldn't be surprising that Raptor resources are assisting since they've kind of bet the store on the S1.

Timothy Pearson's comments in the Electron Github suggest that Google has been pretty resistant to incorporating support for architectures outside of their core platforms. This is not a wholly unreasonable position on Google's part but it's not a particularly charitable one, and unlike Mozilla, the Chrome team doesn't really have the concept of a tier-3 build nor any motivation to. That kind of behaviour is all the more reason not to encourage browser monocultures because it's not just the layout engine that causes vendor lock-in. Fortunately V8, the JavaScript engine, is maintained separately, and reportedly has been more accommodating presumably because of things like Node.js on IBM hardware (even IBM i via PASE!).

Mozilla is much more accepting of this as long as regressions aren't introduced. This is why TenFourFox patches were largely not upstreamed since they would potentially cause problems with Cocoa widgets in later versions of macOS, though what patches were generally applicable I would do so. The main reason I'm still maintaining the Firefox ppc64le JIT patches outside is because I still can't solve these recent startup crashes deep within Wasm code, which largely limits me to Baseline Compiler and thus is not suitable for loading into the tree yet (we'd have to also upstream pref changes that would adversely affect tier-1 until this is fixed). I still intend to pull these patches up to the next ESR, especially since Github is glacially slow now without a JIT and it's affecting my personal ability to do other tasks. Maybe I should be working on something like rr for ppc64le at the same time because stepping through deeply layered code in gdb is a great way to go stark raving mad.

A RISC-V option for your Framework laptop (how about POWER next?)

Many of you have heard of the Framework laptop, a modular system that you can DIY from a mainboard and parts or purchase fully assembled. The designs are open-sourced on Github and Framework has actively been trying to develop an ecosystem around the product.

The part that's potentially most interesting is the mainboard. Framework actively advertises the notion that you can just replace components piecemeal to upgrade, including the logic board, yet keep the same display, port loadout, keyboard, battery and so on if they still work. You can even stick the old one in a case and use it for something else, which is not only environmentally conscious but very customer-friendly.

Now the first third-party Framework mainboard is coming, and it's not x86: it's RISC-V, and it fits in their 13" chassis. A RISC-V option is of course not new in portable computers; I reviewed the ClockworkPi RISC-V DevTerm a couple years ago, which can take either an RPi ARM compute module or an Allwinner D1 based on the 1GHz RV64IMAFDCVU XuanTie C906. However, the CPU is more powerful than that, a quad-core StarFive JH7110 with four SiFive U74 cores. The new Framework mainboard is based on an existing DeepComputing laptop product called "Roma;" DeepComputing now sells a more advanced version in a laptop of their own based on the octocore SpacemiT K1. Combined with the generally well-regarded Framework loadout and creature comforts, this could definitely be a product to watch.

That said, much as I was disappointed with the performance of the RISC-V DevTerm, most people are going to be similarly unimpressed with the performance of this one. Phoronix's benchmarks placed it well below the Raspberry Pi 4 (and the Orange Pi 5 crushed it), and Framework is trying to set expectations low by saying, "The peripheral set and performance aren’t yet competitive with our Intel and AMD-powered Framework Laptop Mainboards." That would certainly be an understatement, and is yet another example of the self-licking RISC-V ice cream cone getting ahead of its skis on real-world throughput. Framework also apologetically notes that the board "has soldered memory and uses MicroSD cards and eMMC for storage, both of which are limitations of the processor." Still, it's (soon to be) available and functional, and it could be mounted in one of those small desktop cases, so if you want a sidecar RISC-V machine to play with you've got another option better than yet another SBC.

But more important than that: it proves that you can put really any architecture on such a board and take advantage of the Framework, uh, framework instead of reinventing the wheel completely. So, instead of these various attempts at building a PowerPC laptop, why isn't there a Power ISA Framework mainboard? Wouldn't that approach just make more sense?

A baby Power10, if you're desperate

Are you really desperate to have your own Power10 (libre issues notwithstanding) while we wait for S1? IBM historically releases "little" versions of their servers after the launch systems have exhausted their novelty and now it's time for this generation's. If you've got 2Us in your rack, a wad of money in your wallet and an IBM salesdroid in your Rolodex, in about a month the Power S1012 could be yours.

Based on the size of the board, no one would mistake this for a Blackbird, yet it's pretty much the IBM equivalent: a single socket supporting up to eight cores. It comes as either a rackmount or in IBM's mega-tower case with four RAM slots for up to 256GB of memory. Tape and RAID are options, and it boots Linux, AIX or IBM i. If you need more sockets, there's the S1022 with a second one in the same form factor, and if you need more capacity, the 4U S1014 has you covered — and is still tower-ready in the same way that Orson Welles was suit-ready.

IBM hasn't shown as much love for their baby towers recently, though. In fact, there wasn't an IBM 2U option at all in POWER9's generation (no doubt much to Raptor's relief); if you wanted Big Blue in a Littler Box, you had to buy the 4U S914 instead (or a leftover POWER8 S812). Also, it seems like the S1012 tower's power output is gimped somewhat: the spec sheet says the rackmount can put 240W through the single CPU socket but the tower manages "only" 195W, which limits your core count. In the glory days, though, we had things like this.

This is my long-trucking POWER6 p520, the 2U baby of the old POWER6 generation. You could get it with two sockets and the same CPUs as its larger siblings, and since the POWER6 was SMT-2, I've got four threads running on its single LPAR. It has RAID and an optical drive and 16GB of RAM, with more available if you were willing to do battle with IBM Capacity on Demand codes. All in all, not bad for 2009.

Of course, I'm being very facetious in this article, because naturally none of these towers are really workstation substitutes. The S1012 (and certainly the S1022) is undoubtedly as loud as the POWER6, and while the POWER6's back baffle reduces some of the noise, it correspondingly reduces ventilation. There's a reason, after all, that I gave the thing its own room with the other geriatric servers. Plus, IBM doesn't talk to us end users: you'll have to buy it through a VAR or authorized rep. That was why I said screw it to buying a brand-spanking new POWER7 back in the day and got the POWER6, because it was used, cheaper and actually available. Which reminds me — if you have to ask how much it is, you almost certainly can't afford it. Hope you've been saving your pennies for the S1.

Rocky Linux 9.4

Rocky Linux 9.4 is out, based on RHEL 9.4, but, you know, free. (Note that Rocky Linux 8.9 doesn't come in a ppc64le version, so Rocky 9.x is your only choice.) If you want the stability of RHEL but don't like the pricetag and don't need the support, here's one of your options. As is typical for such point releases, this one primarily refreshes included software along with security updates. Boot, minimal and DVD ISOs are available for download.

End of the road for PowerPC 40x in Linux

The original PowerPC 400-series embedded chips are no longer supported in the Linux kernel as of today. Despite its prior design wins in many set top boxes, service processors and network equipment, there are no known current consumers of the code and no maintainers. The change affects the 401, 403 and 405, but in case you were worried the change is irrelevant to the embedded PowerPC 405 variant used as an on-chip controller for OpenPOWER, since it runs the Self-Boot Engine and not mainline Linux. It also does not extend to the 44x and above, like the Amiga clone Sam440ep and Sam460ex (AmigaOne 500) boards, which use the AMCC 440EP and 440-derived AMCC 460EX respectively and thus remain supported.

Fedora 40 mini-review on the Blackbird and Talos II (and a taste of Chromium)

This is Chromium running on GNOME in Xorg in Fedora 40 on the Talos II. I think it says it all, really.

Now, I won't mince words here: I don't like Chromium on philosophical grounds and you shouldn't expect me to be complimentary. But I salute the work that went into making it run. I'll have more to say about that later.

Meanwhile, it's that time again: in the same way I preface all these mini-reviews, 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 T2 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.

F40 is the first release since the 2.10 Petitboot PNOR firmware update and I had high hopes that it would fix the problem with stuck XFS logs sometimes making it puke, since it leapfrogs to a much more recent kernel. Both my GPU-less 4-core Blackbird and WX7100 dual-8 Talos II were already upgraded to the current PNOR before beginning and I recommend you do the same. Don't forget to save a copy of your BOOTKERNFW flash partition if your GPU requires it since this operation will erase it (you can flash it back when it's done).

dnf still!!!!! doesn't update grub's config (bug 1921479, showing messages like 0ed84c0-p94177c1: integer expression expected during the process), so the process remains largely unchanged from F38 and F39:

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=40 # download F40 packages
dnf system-upgrade reboot # reboot into upgrader

I always do the Blackbird first as a checkpoint, and got this:

I'm not sure what the issue was, since the Blackbird mostly runs Workstation with only a few extra packages. This didn't happen on the T2. However, I crossed my fingers with --allowerasing and I was able to get it to download on the Blackbird and install.

I also should note that 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 dnf system-upgrade log --number=-1 intermittently to watch the updates. 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, so no XFS burp on the T2! One more grub2-mkconfig -o /boot/grub2/grub.cfg was needed to get Petitboot's menu looking right and the install was complete. I do note with approval that Fedora's boot from Petitboot to prompt was very quick this time around. Good work there.

Now, that desktop environment. I migrated to KDE from GNOME a few releases back after GNOME started messing with my themes, but KDE Plasma 6 in F40 is now Wayland-only; startplasma-x11 doesn't even exist. There is apparently an unofficial package to restore the X11 session but I haven't tried this yet due to a bigger problem I'll get to momentarily. On the GPU-less Blackbird this is a problem because Wayland remains limited to 1024x768 over the built-in HDMI output (Xorg can be coerced up to 1920x1200 with a modeline), so if you've decided to give up and embrace the KDE Wayland Wasteland, you either get to compute like it's 1999 or you get a GPU.

GNOME, on the other hand, does still work in Xorg and performs well on both the Blackbird and T2. Set your .xinitrc to

export XDG_SESSION_TYPE=x11
/usr/bin/gnome-session

and then the usual startx will bring it up from a text boot. Which brings us to this screenshot again:

Chromium is now officially available for the first time on ppc64le as a Fedora package. However, in Xorg it has many visual glitches, and this is true whether or not you have a GPU (this was taken on the Talos II, which has the Raptor BTO WX7100 workstation card).

The reason I entertained running it under Xorg at all was Plasma 6 pretty much broke my custom theme completely and a lot of my applets, even though its Wayland compositor runs fine on the Talos II. (Start it from the text prompt simply with startplasma-wayland.) But the application appears normally.

There are many problems with Chromium on ppc64le (big endian need not apply) and I suspect the major reason is because its JIT appears unfinished. In particular, it seems like most Wasm and certain other operations will make it trap, and as such it's not yet ready for prime time. I'm sure it will continue to improve and the porters are to be congratulated for their hard work on it, but I'll still be trying to get all the pieces in Firefox to go in the same direction, and once the next ESR (128) starts hitting the beta channel we'll at least have Baseline JIT acceleration available for it while I continue to struggle with Ion and Wasm.

Before that, though, I'm deciding what to do, whether to go back to GNOME or try to piece together my custom theme again in KDE. It'll need a fair bit of work. I guess this means it wasn't a good upgrade, though not because it doesn't work on OpenPOWER; it just wasn't a good upgrade, period. I certainly hope the churn will be less in F41.

Fedora 40

Fedora 40 is now out, the most current release that I personally use on my own Talos II and Blackbird systems. (This means that Fedora 38 will go EOL in about a month.) This release is presently based on kernel 6.8.7 and GNOME 46, but not the anticipated new Anaconda installer and DNF5 package manager updates. Also included are gcc 14.0, GNU binutils 2.41, glibc 2.39, gdb 14.1, Golang 1.22, LLVM 18, Ruby 3.3 and PHP 8.3.

Perhaps the biggest news for this release is that an official Chromium build is available once again for ppc64le while I still spin my wheels with the Firefox JIT (Wasm is now broken again and I have not been able to figure out why). I don't like Chromium for philosophical reasons but I'm sure it will make many of you happy.

That said, this release is probably more notorious for eliminating X11 support in the KDE Plasma 6 spin, which yours truly also uses. It will be interesting to see how well that works on the GPU-less Blackbird here since I haven't seen anything to suggest the issue with 1920x1080 through the onboard HDMI has been fixed, but the trusty old BTO WX7100 in the T2 should be fine in the Wayland Wasteland. Attempts to remove the X11 session from GNOME reportedly didn't land for this release either, so we'll see how that turns out too. I usually give the repos a few days to catch up before updating and then I'll post my usual mini-review (here's the one for F39).

OpenBSD 7.5

OpenBSD 7.5 is out with multiple kernel and SMP improvements (we love SMP improvements on our multicore beasts), more hardware support, and LibreSSL 3.9.0, OpenSSH 9.6/9.7, and LLVM-clang 16.0.6. The only headliner Power ISA specific improvement to the big-endian powerpc64 port is a smoother upgrade process, but all the other advancements are welcome too. Download from any of the many mirror sites.

Early Power11 signals in the kernel

A number of people have alerted me to some new activity around Power11 in the Linux kernel, such as this commit and a PVR (processor version register) value of 0x0F000007. It should be pointed out that all this is very preliminary work and is likely related to simulation testing; we don't even know for certain what node size it's going to be. It almost certainly does not mean such a CPU is imminent, nor does this tell us when it is. Previous estimates had said 2024-5, but the smart money says no earlier than next calendar year and probably at the later end of that timeframe.

That said, the reputed pressures around Power10 that caused closed IP to be incorporated are hopefully no longer as acute for Power11, and off-the-books discussions I've had suggest IBM internally acknowledges its strategic mistake. That would be good news for Power11, but it's not exactly clear what this means for Solid Silicon and the S1 because S1's entire value proposition is being Power10 without the crap. While S1 will certainly come out before Power11, we still don't know when, and if there's a short window between S1 and a fully open Power11 then S1 could go like Osborne.

"Short" here will be defined in terms of how much work it takes to adapt the Power11 reference system. IBM understandably always likes to sell its launch systems first and exclusively before the chips and designs trickle down. The Talos II and to a lesser extent the Blackbird are a relatively straightforward rework of Romulus (POWER9's reference), so one would think adapting Power11 would similarly require little adjustment, though Romulus used the ASPEED BMC and any Raptor Power11 would undoubtedly use (Ant)arctic Tern/Solid Silicon's X1. In contrast, there'd be a bit more work to port Rainier (Power10) to S1 since the RAM would be direct-attach instead of OMI and there may be differences to account for with PCIe, plus the BMC change. The last estimate we had for the S1 machines was late 2024; putting this all together and assuming that date is at all accurate, such a system may have a year or two on the market before Power11 exits its IBM-exclusive phase.

That could still be worth it, but all of this could be better answered if we had a little more insight into S1 and its progress, and I've still got my feelers out to talk to the Solid Silicon folks. You'll see it here first when I get a bite.

Fedora 39 mini-review on the Blackbird and Talos II (and other woes)

Merry Christmas and Happy Holidays: what a long strange trip it's been trying to get to this point, between trying to get a place to live at the new $DAYJOB and fix the Blackbird, which seemed to have gotten its BMC setting scrambled, then get it and the Talos II upgraded to Fedora 39 so that I can get back to work on the Firefox JIT. Here we are finally, just in time to write up our usual mini-review (see what I wrote for Fedora 38). As I always say in these mini-reviews, 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 usual, recall both my T2 and Blackbird are configured to come up in a text boot instead of gdm and I start KDE manually from there. I still test GNOME on both systems, but my primary desktop environment has been KDE Plasma for several versions now, and I always recommend a non-graphical boot as a recovery mechanism in case your graphics card gets whacked by something or other. On Fedora this is easily done by ensuring the symlink /etc/systemd/system/default.target points to /lib/systemd/system/multi-user.target.

Unfortunately, dnf kernel updates still! don't seem to properly update grub's config (basically bug 1921479, showing messages like 0ed84c0-p94177c1: integer expression expected during the process), so the process remains largely unchanged from F38:

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=39 # download F39 packages
dnf system-upgrade reboot # reboot into upgrader

I do the Blackbird first as a check, since it can afford to be down waiting for updates, but I can't have that happening with the Talos II since it's my primary workstation. Unfortunately, while the packages downloaded okay, the actual upgrade process didn't do anything. After a couple failed attempts where it rebooted back into 38 seemingly unchanged, I watched it like a hawk and observed the following:

The installer was saying that the Fedora 39 GPG signatures weren't valid "yet" and so nothing that was downloaded could be verified. This turns out to be the same basic issue that bedevils Raspberry Pi 4 and earlier models that lack a realtime clock (bug 2242759), but the Blackbird has an RTC, so what gives?

I checked the CMOS battery coin cell and got a full 3.0 volts, and couldn't find anything otherwise wrong with the installer itself. The answer was labouriously going through the logs and finding that the system time was about two years in the past, confirmed in the Petitboot shell. This gets fixed in a normal boot by chrony synching up with NTP, but that apparently doesn't happen with the installer. Worse, it looked like everything had somehow gotten scrambled in the Blackbird's BMC because I couldn't log on with the admin password and fix the time (either from the SSH server or the web interface). Time to crack the case and connect to the BMC's serial port.

Connect your terminal at 115200bps, 8-N-1 to the inside 9-pin serial port headers. We're basically following these instructions to reset the BMC's internal persistent storage, which will zap everything including the BMC password (if you're an old Mac user like me, think of this as the ASPEED equivalent of "zapping PRAM"). However, a wrinkle here is that the system can reboot multiple times, so it's important to change the bootargs as many times as it resets back to U-Boot until the kernel actually comes up.

Here's what you might see in your terminal program. Make sure the terminal program is running and the serial port is connected before you apply power to the system to start up the BMC, or you won't be early enough to talk to U-Boot.

DRAM Init-V12-DDR4
0abc1-4Gb-Done
Read margin-DL:0.3725/DH:0.3803 CK (min:0.30)


U-Boot 2016.07 (Feb 19 2020 - 11:51:39 +0000)

       Watchdog enabled
DRAM:  496 MiB
Flash: 32 MiB
In:    serial
Out:   serial
Err:   serial
Net:   aspeednic#0
Hit any key to stop autoboot:  0 
ast# setenv bootargs console=ttyS4,115200n8 root=/dev/ram overlay-filesystem-in-ram rw
ast# boot
## Loading kernel from FIT Image at 20080000 ...
   Using '[email protected]' configuration
   Trying 'kernel@1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x20080128
     Data Size:    2656176 Bytes = 2.5 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x80001000
     Entry Point:  0x80001000
     Hash algo:    sha1
     Hash value:   1815ece74a2e27241c471b9ed87885071dd9e143
   Verifying Hash Integrity ... sha1+ OK
## Loading ramdisk from FIT Image at 20080000 ...
   Using '[email protected]' configuration
   Trying 'ramdisk@1' ramdisk subimage
     Description:  obmc-phosphor-initramfs
     Type:         RAMDisk Image
     Compression:  lzma compressed
     Data Start:   0x20310f88
     Data Size:    1583941 Bytes = 1.5 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: unavailable
     Entry Point:  unavailable
     Hash algo:    sha1
     Hash value:   55e0853d6ad703d5ea225837d85223a73f7cf3a4
   Verifying Hash Integrity ... sha1
DRAM Init-V12-DDR4
0abc1-4Gb-Done
Read margin-DL:0.3745/DH:0.3784 CK (min:0.30)


U-Boot 2016.07 (Feb 19 2020 - 11:51:39 +0000)

       Watchdog enabled
DRAM:  496 MiB
Flash: 32 MiB
In:    serial
Out:   serial
Err:   serial
Net:   aspeednic#0
Hit any key to stop autoboot:  0 
ast# setenv bootargs console=ttyS4,115200n8 root=/dev/ram overlay-filesystem-in-ram rw
ast# boot
## Loading kernel from FIT Image at 20080000 ...
   Using '[email protected]' configuration
   Trying 'kernel@1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x20080128
     Data Size:    2656176 Bytes = 2.5 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x80001000
     Entry Point:  0x80001000
     Hash algo:    sha1
     Hash value:   1815ece74a2e27241c471b9ed87885071dd9e143
   Verifying Hash Integrity ... sha1+ OK
## Loading ramdisk from FIT Image at 20080000 ...
   Using '[email protected]' configuration
   Trying 'ramdisk@1' ramdisk subimage
     Description:  obmc-phosphor-initramfs
     Type:         RAMDisk Image
     Compression:  lzma compressed
     Data Start:   0x20310f88
     Data Size:    1583941 Bytes = 1.5 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: unavailable
     Entry Point:  unavailable
     Hash algo:    sha1
     Hash value:   55e0853d6ad703d5ea225837d85223a73f7cf3a4
   Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 20080000 ...
   Using '[email protected]' configuration
   Trying '[email protected]' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x203089e8
     Data Size:    34013 Bytes = 33.2 KiB
     Architecture: ARM
     Hash algo:    sha1
     Hash value:   f53d8ad3a7c573a4903f910fd124507c73f0bbfb
   Verifying Hash Integrity ... sha1+ OK
   Booting using the fdt blob at 0x203089e8
   Loading Kernel Image ... OK
   Loading Ramdisk to 9ea16000, end 9eb98b45 ... OK
   Loading Device Tree to 9ea0a000, end 9ea154dc ... OK

Starting kernel ...

[...]

Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro) 0.1.0 blackbird ttyS4

blackbird login: root
Password: 0penBmc
root@blackbird:~# flash_eraseall /dev/mtd/rwfs
Erasing 64 Kibyte @ 400000 - 100% complete.
root@blackbird:~# reboot

Notice that it fell back to U-Boot once before actually going into the OpenBMC kernel. You need to set the bootargs both times (because the watchdog is aggressive and will reboot after even a brief period of inactivity, I recommand cutting and pasting that setenv command instead of typing it). Once that's done, the default 0penBmc password will work, and we can reset the persistent storage. You may need to powercycle the BMC after this too as the manual reboot may not be enough.

With that corrected, I was able to log into the web interface and set the time manually, though I also ensured the time owner was Host (i.e., not the BMC) so that hopefully the system can deal with this itself on startup again. Petitboot confirmed the time was correct and the install succeeded. On my Blackbird I got the usual graphical progress bar on the ASPEED BMC framebuffer; on my T2 with a BTO AMD WX7100, as long as you ensure the kernel is manually selected through Petitboot on startup, you'll still get to see the install log live as text. If you forget to manually select the kernel and the system comes up to an apparently black screen, you can either 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 as appropriate as root and periodically issuing dnf system-upgrade log --number=-1 to watch log updates.

The update did not cause a stuck XFS log entry on the Blackbird, but after the reboot I still had to do one more grub2-mkconfig -o /boot/grub2/grub.cfg and a restart to ensure the right kernel and version were being used. Currently the kernel version as of this writing is 6.6.7.

Fedora 39 is apparently the last hurrah for the X11 session of KDE Plasma, largely because the Fedora KDE SIG doesn't want to deal with it. While Plasma 6 still has a legacy X11 session, KDE as provided in the Fedora spin won't have it — Wayland Wasteland or bust. (In particular, this will obsolete both kwin-x11, presumably including /usr/bin/kwin_x11 and /usr/bin/startplasma-x11, and plasma-workspace-wayland.) Naturally this directly affects me personally, so let's start with the system with the worst Wayland support, our stripped-down Blackbird. All it has is the ASPEED BMC framebuffer connected over HDMI.

(GNOME Wayland started manually with XDG_SESSION_TYPE=wayland /usr/libexec/gnome-session-binary --builtin)

(KDE Plasma 5 Wayland started manually with /usr/bin/startplasma-wayland)

Both GNOME 45 (GNOME's own X11 session support removal is further behind, and doesn't appear imminent) and Plasma 5 in F39 are still limited to 1024x768 with the on-board HDMI. This is a terrible limitation that yet again remains unaddressed, especially for those people trying to run their systems completely blobless, and also affects Arctic Tern which uses the same IT66121FN HDMI transceiver PHY. While performance remains stably improved over the horrid morass it used to be, further fixes appear to be stuck on a plateau.

The good news is, a lot of the graphical glitches that plagued F38 and earlier in GNOME on the AST framebuffer (both Wayland and X11) appear to be corrected in GNOME 45. Window decorations and window movement seem to work properly again and performance is good enough. This places me in the unusual situation of recommending GNOME to blobless or no-GPU OpenPOWER users, even though it's not a particularly lightweight desktop environment, simply because you'll still be able to run it under X11 at least for a little while and you can add an X11 modeline for higher resolution — as I've done. Otherwise, start budgeting for a video card.

Plasma 5, of course, continues to work fine without a GPU in X11. Enjoy that while it lasts.

Next was the Talos II, which has a custom KDE theme and a lot more packages. Its clock is fine, so that wasn't the problem, but the install left a stuck log entry on the XFS root again and Petitboot duly puked. I haven't (quite, anyway) gotten to the point of replacing the XFS root with ext4, but I now have a script to automatically do the volume group gyrations and XFS repair on the Blackbird instead of typing in commands, and for future upgrades I'll be doing ipmitool chassis bootdev safe (at the suggestion of a commenter) before running the installer so that if I can't scan for devices, I can at least restart, immediately jump into the Petitboot shell and do repairs if necessary. Note that turning off the automatic device scan can impair autobooting, such as me remotely bringing up the system from the BMC after a power failure, so I've set it back to normal with ipmitool chassis bootdev none after the upgrade and repair were successful.

So far F39 is running fine on the T2 as well, with only a couple old compat packages that didn't make the jump (meanwhile, for those of you hanging on to F37, that support is already over). It's F40 where the problems are expected to start for me with KDE, which as of this writing is scheduled for mid-April 2024. As usual no one cares, least of all the Wayland community, which has simply fallen back on strong-arm tactics to drive adoption and functionality be damned. I'll have to evaluate my choices then based on my app mix and how well Wayland-only KDE can handle them, and it won't be just OpenPOWER users like me in that boat.

Fedora 39

Fedora 39 is out, the Linux distro I use personally on my Talos II and Blackbird systems. Since I'm doing a lot of remote work with the new $DAYJOB it might be a bit before I can sit down with it but there will be the usual mini-review (here's what I had to say about Fedora 38). This release is based on kernel 6.5 and GNOME 45, with LLVM 17, Perl 5.38, glibc 2.38 and gcc 13.2. As usual, Fedora 37 will EOL one month after this release.

However, F39 isn't really the big news, and probably won't be a very exciting (or bumpy) release. Instead, the bigger and possibly more obnoxious change will occur with Fedora 40 when the Plasma spin (which I use instead of GNOME) is expected to completely drop X11 support, and the same is likely coming for GNOME 46 which will occur in the same version. It will be interesting, to say the least, to see how this affects people running OpenPOWER systems without GPUs to be completely blob-less. I've not been terribly happy with Wayland on the Blackbird's ASpeed BMC framebuffer and I haven't seen anything to indicate that its deficiencies have improved. Wonder how well it would work on the X1 ...

The next Raptor OpenPOWER systems are coming, but they won't be Power10

I'd like to first start out by saying I've been aware of new developments but made certain promises to keep my mouth shut until all the parties were ready to announce. (Phoronix is not so constrained.) Many of you noted an offhand comment in this YouTube video about Raptor announcing a new Power10 system. That got a lot of people excited, because while our POWER9 systems are doing well, in 2023 this dual-8 64-thread POWER9 is no longer cutting edge and we need new silicon in the pipeline to keep the ecosystem viable.

Raptor yesterday officially announced that we're not getting Power10 systems. The idea is we're going to be getting something better: the Solid Silicon S1. It's Power ISA 3.1 and fully compatible, but it's also a fully blob-free OpenPOWER successor to the POWER9, avoiding Power10's notorious binary firmware requirement for OMI RAM and I/O.

I asked Timothy Pearson at Raptor about the S1's specs, and he said it's a PCIe 5.0 DDR5 part running from the high 3GHz to low 4GHz clock range, with the exact frequency range to be determined. (OMI-based RAM not required!) The S1 is bi-endian, SMT-4 and will support at least two sockets with an 18-core option confirmed for certain and others to be evaluated. This compares very well with the Power10, which is also PCIe 5.0, also available as SMT-4 (though it has an SMT-8 option), and also clocks somewhere between 3.5GHz and 4GHz.

S1 embeds its own BMC, the X1 (or variant), which is (like Arctic Tern) a Microwatt-based ISA 3.1 core in Lattice ECP5 and iCE40 FPGAs with 512MB of DDR3 RAM, similar to the existing ASpeed BMC on current systems. X1 will in turn replace the existing Lattice-based FPGA in Arctic Tern as "Antarctic Tern," being a functional descendant of the same hardware, and should fill the same roles as a BMC upgrade for existing Raptor systems as well as the future BMC for the next generation systems and a platform in its own right. The X1 has "integrated 100% open root of trust" as you would expect for such a system-critical part.

Raptor's newest systems are planned for late 2024. There will be tiering, so most likely (though not confirmed) Blackbird, T2 and T2 server classes of systems will be available under new names. Price? Well, you'll just have to wait and see.

Solid Silicon is definitely a new name in the Power ecosystem and we don't know a lot about them. There's a web page, but the TwXitter and LinkedIn links are unpopulated as of this writing, and it's maddeningly minimal on actual content. Tim confirmed they are a new licensee and have been working on the design for at least a couple years. The press release gives a 737 area code, which is Austin, Texas, and the only Solid Silicon business entry I could find for Texas is this one for Solid Silicon Technology LLC in Plano. I'm told this isn't them, so if anyone from Solid Silicon would like to lift the corporate veil a little, drop me a line at ckaiser at floodgap dawt com. [UPDATE: The LinkedIn was updated after this posted, listing Todd Rooke as CEO. Rooke's listing indicates past experience with FPGAs, as well as his time at HPE and Microsoft. His location is given as Colorado Springs but Colorado lists no company by that name. Hopefully more to come.]

But besides new systems in the offing, it's also good news that we're getting — we hope — performant OpenPOWER chips that aren't from IBM. I don't have anything against IBM; I've worked with IBM hardware for literally decades, and my home server is a classic POWER6 that just keeps on truckin'. But IBM designs chips to benefit IBM's world, which is server rooms (ask anyone who's got one what it's like to share an office with a POWER8), and IBM doesn't do end-user sales. If Raptor has a good partner here who can design solid OpenPOWER chips for workstations and small servers, not traditionally IBM's present domain but one important for them to maintain if they want OpenPOWER to stay relevant, then in around a year we should be in for a treat — and a very rosy near future.