Raptor says the Blackbird crunch ends in August (and maybe Arctic Terns too)

Good news for everyone with a Blackbird backorder: Raptor is announcing order fulfillment and restocking by August 31, 2022. This may not mean the order you submit now will get fulfilled by then, but if you have your order already in, the wait will be over soon and new orders should be processed much more quickly. (This date does not apply yet to the Talos II Lite, but I'm sure Raptor is working on it.) In the meantime, if you can't wait, may we suggest a regular T2? Those are in stock and ready for purchase.

Raptor is also stating Arctic Tern will launch in the "next few weeks" for purchase, with the Kestrel soft-BMC onboard and compatible with the entire Raptor family including the full T2 and the 'Bird. We're looking forward to it and expect a review as soon as I can get my hands on a couple. Faster BMC booting is always welcome around here!

Rocky Linux 9.0

With new version 9.0 Rocky Linux joins the list of ppc64le-compatible CentOS clones, along with the already extant AlmaLinux 9 and Circle Linux based on Red Hat Enterprise Linux 9 (itself based on Fedora 34). Rocky Linux explicitly requires a POWER9 CPU. Other than that, the big difference is the branding and the governance, but more choice is always good. Download ISOs are available.

CXL is going to eat OMI's lunch

The question is whether that's a bad thing. And as it stands right now, maybe it's not.

High I/O throughput has historically been the shiny IBM dangled to keep people in the Power fold, and was a featured part of the POWER9 roadmap even though those parts never emerged. IBM's solution to the memory throughput problem was the Centaur buffer used in POWER8 and scale-up Cumulus POWER9 systems (as opposed to our scale-out Nimbus POWER9s, which use conventional DDR4 RAM and an on-chip controller), and then for Power10 the Open Memory Interface, or OMI, a subset of OpenCAPI. In these systems, the memory controller-buffer accepts high-level commands from the CPU(s), abstracting away the details of where the underlying physical memory actually is and reordering, fusing or splitting those requests as required. Notoriously, OMI has an on-board controller, and its firmware isn't open-source.

But why should the interconnect be special-purpose? Compute Express Link (CXL) defines three classes of protocol: CXL.io, an enhanced CPU-to-device interconnect based on PCIe 5.0 with enhancements; CXL.cache, allowing peripheral devices to coherently access CPU memory; and CXL.mem, an interface for low-latency access to both volatile and non-volatile memory. Both CXL.cache and CXL.mem are closely related and themselves transmit over a standard PCIe 5.0 PHY. Memory would be an instance of a CXL Type 3 device, implementing both the CXL.io and CXL.mem specifications (Type 1 devices implement CXL.io and CXL.cache, and rely on access to CPU memory; Type 2 devices implement all three protocols, such as GPUs or other types of accelerators). The memory topology is highly flexible. If this sounds familiar, you might be thinking of Gen-Z, which aimed for an open royalty-free "memory semantic" protocol; Gen-Z started the merge into the CXL Consortium, led by Intel, in January.

IBM was part of Gen-Z, but eventually let it dangle for OpenCAPI and OMI, and while it is a contributing member to CXL this seems to have been as a consequence of its earlier involvement with Gen-Z. But really, what's OMI's practical future anyway? So far we've seen exactly one chipset implementation from one vendor and that implementation has directly harmed Power10's wider adoption apart from IBM's own hardware. OMI promises 25Gbps per lane at a 5ns latency, but Samsung's new CXL memory module puts 512GB of DDR5 RAM on the bus at nearly 32Gbps. It's a cinch that Power11, whenever it gets on the roadmap, would support at least PCIe 5.0 or whatever it is by then and CXL would appear to be a better overlay on that baseline. Devices of all sorts could share a huge memory pool, even GPUs. Plus, a lot more companies are on board and that would mean a lot more choices and greater staying power, plus more likelihood of open driver support the more devices emerge.

There are still some aspects of CXL that aren't clear. Although it's advertised as an open industry standard, there's nothing saying it's royalty or patent-free (Gen-Z explicitly was, or at least the former), and the download for the specification has an access agreement. The open aspect may not be much better either: Samsung has an ASIC controller in their memory device but it still may need a blob to drive it, either internally or as part of CPU firmware (earlier prototypes used an FPGA), and nothing says that another manufacturer might not require it either.

Still, OMI has the growing stench of death around it, and it never got the ecosystem support IBM was hoping for; CXL currently looks like everything technologically OMI was to be and more, and at least so far not substantially worse from a policy perspective. Other than as a sop to their legacy customers, one may easily conclude there's no technological nor practical reason to keep OMI in future IBM processors. With nothing likely changing on the horizon for Power10's firmware, that may be cautiously good news for us for a future Power11 option.

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:

#!/bin/csh

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.