Tonight's game on OpenPOWER: Blake Stone Aliens of Gold

Everything is awful, so now that we've rescued a Blackbird let's go shoot more aliens. One of the more entertaining games based on id's Wolfenstein 3D engine was Apogee's Blake Stone: Aliens of Gold from 1993, developed by yet another set of apparent refugees from Softdisk, but that's another story for another day. It kept the basic formula but added subtle lighting effects and ceiling and floor textures, along with more varied environments, lots of (cartoony but fun to shoot) monsters, and a very helpful automap.

Ordinarily this wouldn't be worth a mention; that's what we have DOSBox for (see our article on adding an OpenPOWER JIT to DOSBox). Despite the fact that DOSBox does support this game, however, I do actually own a retail copy of Blake Stone from back in the day and it runs like dried snot even with a JIT.

Fortunately, the source code to Blake Stone was released back in the day as well after it was long believed to be lost, and an excellent SDL/OpenGL port called BStone is available which adds many graphical improvements, mouse look (well, side to side, anyway), and 16:9 modes as demonstrated in the screenshot. It also supports the IMHO inferior sequel, Planet Strike.

To start saving mankind, you can play the shareware version, but it's more fun to play with a retail copy (mine is the 1994 FormGen release, but the one you can still buy from Apogee will work), or extract the game assets from the DOSBox-based GOG installer. The CD or 3D Realms downloads are easiest to work with, as you can just copy the contents into a folder.

Clone the BStone Github project. You will need CMake and SDL 2.0.4 (or better) development headers and libraries. The CMake build recipe assumes that your SDL has a static libSDL2main.a library, which apparently the ones from Fedora, Slackware and possibly others don't, which may require modifying the SDL CMake component that comes with it (I had to). Then mkdir build, cd build and cmake .. to kick it off.

Once built you can start the game either from the directory where your Blake Stone files are (I have cd ~/stuff/dosbox/BSTONE && ~/src/bstone/build/src/bstone), or pass bstone the --data_dir option with a path (if it fails to detect the correct game, try passing --aog, --aog_sw or --ps). If you don't have OpenAL-capable hardware, disable OpenAL sound from the in-game configuration menu, or you may get random crashes during play. Don't shoot the informants.

Fedora 34 mini-review on the Blackbird and Talos II (it sucks)

Once again it's time to upgrade Floodgap's stable of Raptor systems to the latest release of Fedora, which is up to version 34 (see our prior review of Fedora 33). You may not necessarily run Fedora yourself, but the fact that it does run is important, because it tends to be very ahead of most distros and many problems are identified in it and fixed before moving to other less advanced ones. And boy howdy, are there problems this time. I'm going to get it over with and tl;dr myself right now: if you use GNOME as your desktop environment and you haven't upgraded yet, DON'T. F34 and in particular GNOME 40 are half-baked, and the problems don't seem specific to OpenPOWER and the hard work of folks like Dan Horák; these issues are more generalized. There is always that sense of dread over what's going to break during the update, and while I'm finally typing in Firefox on this updated Talos II, it took me hours to get everything glued back together and the desktop performance problems in particular are cramping my ability to use the system well. Fedora 33 will still be supported until a month after F35 comes out; it may be worth sticking with F33 for a couple months for the GNOME team to work on the remaining performance issues.

The problems started from the very beginning, even before actually updating. I do my updates initially on the Blackbird to shake out any major problems before doing it to my daily driver T2. As I explained previously, neither the Blackbird nor the T2 use gdm; they both boot to a text prompt, and we jump to GNOME with startx (or XDG_SESSION_TYPE=wayland dbus-run-session gnome-session if we want to explore the Wayland Wasteland). I do the upgrade at the text prompt so that there is minimal chance of interference. Our usual MO to update Fedora is, as root,

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

If you do this with F34, however, you get a number of downgrades (unavoidable, apparently), missing groups and an instant conflict with iptables when you try to download the packages:

dnf suggests we add --best --allowerasing to deal with that. It doesn't work:

Neither does adding --skip-broken. The non-obvious solution is dnf system-upgrade download --refresh --releasever=34 --allowerasing, and just ignoring the duff package.

The Blackbird does not have a GPU; all video output is on the ASPEED BMC (using the Blackbird's HDMI port). Ordinarily I would select the new kernel from Petitboot when it restarts after the final command above to see a text log of the installation but this time we get an actual graphical install screen.

After the installation completed, the machine rebooted uneventfully and came up to the text prompt. I entered startx as usual and ...

At this point GNOME just plain hung up. There was no mouse pointer, though pressing ENTER on the keyboard triggered the button and put it back to the text prompt. Nothing unusual was in the Xorg logs, and journalctl -e showed only what seemed like a non-fatal glitch (Window manager warning: Unsupported session type). Well, maybe the time for the Wayland Wasteland was now. I did an exec bash (gnome-session doesn't properly handle using another shell, or you get weird errors like Unknown option: -l because it tries to be cute with the options to exec) and XDG_SESSION_TYPE=wayland dbus-run-session gnome-session, and Wayland does start:

However, it still doesn't support 1920x1080 on the Blackbird on-board HDMI, just 1024x768. It also seemed a little sluggish with the mouse. I exited it and tried to start gnome-session --debug --failsafe but it wouldn't initialize.

It then dawned on me that I was setting XDG_SESSION_TYPE manually for Wayland; I previously left it unset for X11. Setting XDG_SESSION_TYPE to x11 finally brought up GNOME 40 in X with a full 1080p display:

I put that into my .cshrc and that was one problem solved. The Applications drawer seemed a little slower to come up, though I have a very vanilla installation on this Blackbird on purpose and few apps are loaded, so I didn't try scrolling through the list or running lots of applications at once. (More on that in a moment.)

Just to see if anything shook out subsequently, I ran dnf upgrade again. This time the missing iptables compatibility packages came up:

That solves that mystery, so just ignore iptables during the initial download and the next time you run dnf after Fedora has been upgraded, it will clean up and install the right components. This whole sordid affair now shows up in the Release Notes.

Upgrading the Talos II is usually a much more complex undertaking anyway because I have custom GNOME themes and extensions installed on it and I always expect there will be some bustage. I don't like it, mind you, but I expect it. Armed with what I had learned from the Blackbird, I installed the packages on the T2 (some other groups also had "no match," though all of my optionally installed packages could and did upgrade) and rebooted.

Unlike the Blackbird, however, the installer still came up in a text screen as in prior upgrades when I selected that kernel from the Petitboot menu.

This machine has the BTO AMD WX7100 workstation card and does not use the ASPEED BMC framebuffer. If you don't select the kernel from the menu and just let the default go, you will get the usual black screen again, and as in prior versions you'll have to pick another VTY with CTRL-ALT-F2 or something, log in as root and periodically issue dnf system-upgrade log --number=-1 to watch.

I rebooted and started X (with XDG_SESSION_TYPE=x11), and GNOME came up, but it looked a little ... off.

If you noticed the weird pink-purple tint, you win the prize. However, my second monitor seemed to have a normal display (so did the Blackbird), and the difference is that my main display is colour-managed. When I selected the default profile, the tint went away but my colours weren't, you know, just right. I spent a few hours regenerating the profile with my Pantone huey manually with dispcal, but the same thing happened with the new profile.

The problem is the new colour transform matrix (CTM) support; the prior profile obviously worked fine in 3.38 but isn't compatible with 40. The proper way to solve this would be by letting GNOME make a new colour profile for you from the Settings app and it even allegedly supports the Pantone huey and other colourimeters. However, it has never (to my knowledge) worked properly on OpenPOWER (it crashes), so I've never been able to do this myself. Instead, my current solution is to just temporarily disable CTM with

xrandr --output DisplayPort-0 --set CTM 0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1

(that's 0, 1, seven zeroes, 1, seven more zeroes, and 1). Adjust DisplayPort-0 to where your colour-managed display is connected. Note that every time you (re)start GNOME or its shell, it will forget this setting and you'll have to enter it again. It would be nice if the colour manager could work with OpenPOWER, but CTM should have never broken working profiles in the first place.

However, that all got solved later, because an even more pressing concern popped up first: the UI was slow as molasses. GNOME 40 defaults to the Activities overview on startup with nothing running. It takes literally several seconds to move from one page of activities/apps to the next. Several seconds. This problem is not unique to OpenPOWER, and occurs on both Wayland and Xorg, but a general fix is apparently months away.

The performance problems are not X11-specific. In fact, Wayland is even worse, because the mouse stutters even just moving it around. This is the first time Wayland is actually worse on the system with the GPU (the T2) rather than the system without one (the Blackbird), though I hardly consider this regression a positive development.

What am I doing about it? Well, what can I do about it, short of trying to fix it myself? GNOME is the default environment for Fedora Desktop, and while I could switch to KDE or Xfce (and I might!), these are serious regressions that are hitting a decent proportion of users and were even evident during the beta phase. Did QA just fall asleep or something? To top it off, even if it were working well, whose freaking bright idea was it to make you go to the upper left corner to click Activities, then back to the bar to click the Show Applications button, just to pull up what you have installed? I've started using the Applications menu that Fedora includes by default; at least that doesn't take a Presidential administration or two or wild sweeping mouse gestures just to show you a list of apps, even though it's still noticeably slower than 3.38.

The slowdowns are entirely specific to GNOME. Once you actually get an app started, like Firefox or a game, display speed is fine, so the problem clearly isn't pushing pixels; it's something higher level in GNOME. Switching all the core scheduling to performance made at most minimal difference. Similarly, (as root) echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level instead of auto made things a little better, but there is still no excuse for how bad it is generally. About the only thing that made more difference than that was simply turning animations off altogether in GNOME Tweaks. Nothing was smooth anymore, but it was about twice as fast at doing anything, so that's how I'm limping along for the time being.

With those significant problems on deck, the usual turmoil with custom themes and extensions is actually anticlimactic. I had to make some tweaks to my custom Tiger-like GNOME shell extension to fix the panel height and a weird glitch with slightly thicker border lines on the edges of the panel, which you can see in the screenshot below. Quite a few extensions could not automatically update to GNOME 40, either:

I've become irritated enough by this that I actually did set disable-extension-version-validation to true in dconf-editor, which made a couple start working immediately, including my beloved Argos custom script driver. For the others I downloaded the most current version of the shell system monitor and this fork of Dash-to-Dock, and manually installed them in ~/.local/share/gnome-shell/extensions/ (you may need to reset the GNOME shell with Alt+F2 and r to get gnome-extensions enable to actually see their UUIDs). A few I should have dispensed with earlier: No Topleft Hot Corner can now be simply replaced by gsettings set org.gnome.desktop.interface enable-hot-corners false, and AlternateTab's switcher behaviour now can be rigged manually from GNOME Settings.

I'm now more or less back where I started from, but working with apps is much less fluid and the desktop experience is undeniably inferior to prior releases, and I can't believe no one thought to blow the whistle during the test phase.

If you use Fedora purely as a command-line server, other than the initial hiccups with downloading packages, it seems to work. If you use KDE or Xfce or anything other than GNOME as your desktop, you're probably okay with F34 too, though I didn't test those (I may later). But if you use the default GNOME on Fedora, especially if you use Wayland, think twice about this update before installing it while you've still got some time with F33. Part of riding the bleeding edge is drawing blood now and then, but F34's wounds seem much more self-inflicted than usual. This is the worst Fedora update since I started using it in F28 and I'm not exaggerating in the slightest.

LibreBMC and Kestrel: two separate BMC tastes that taste separate separately

After our article earlier this week on LibreBMC and my concern as to what it meant for Raptor's own Kestrel "soft BMC" project, Raptor's Tim Pearson contacted me and advised that Kestrel is a standalone Raptor product on its own timetable that's still very much in development. In fact, the attached screenshot shows evolution from just last month with On-Chip Controller support now in the firmware, where it is able to read the temperature sensors and has scaffolding for monitoring fan RPM. Although Raptor makes it clear that Kestrel is and always will be open, and is developed on OpenPOWER systems using open tooling, it is mostly Raptor in-house code with the only non-Raptor bits being Zephyr (the OS), LiteX (the FPGA designer), Microwatt (the CPU core) and some minor components like I2C.

The other noteworthy thing is that Kestrel will indeed be offered as an aftermarket plug-and-play upgrade for existing Blackbird and Talos II systems, no soldering required. This is excellent news, because while LibreBMC is a very encouraging development and has wide-ranging implications beyond OpenPOWER systems, its basis on OpenBMC means a heavier installation that continues to be less well suited to a workstation environment (in terms of interface and sheer startup time amongst other things). While Antmicro's planned LibreBMC card may also work in Raptor systems, it's really meant for OpenPOWER servers as well as other server-class machines with onboard BMCs that aren't necessarily Power-based. Whether we like it or not, while there's a lot of nerd cred around OpenPOWER workstations, such systems presently represent a minority of the POWER9 installed base (let alone of all BMC-managed hardware). It thus makes sense that Raptor, currently the only manufacturer of OpenPOWER workstation machines, would be in the best position to create an open BMC that also is better tailored to improving the desktop user experience. As I've written here before, the envisioned improvements to fan control and user interface are very welcome, but Kestrel's promised 10-second power-to-IPL is a huge win for the desktop when ASPEED BMCs running LibreBMC right now take over a minute or more. LibreBMC's OpenPOWER core will certainly improve performance but I doubt it will be to that extent.

But I also suspect more good news than just an aftermarket upgrade is afoot. I pointed out in the LibreBMC article how much one of the physical form factors in particular looks an awful lot like an single-board computer, because really when you have a system-on-a-chip and on-board peripherals, you kind of have a "PowerPi" already. Raptor isn't saying, but Kestrel, like LibreBMC, will necessarily have its own SoC at its heart and thus could easily be the basis of another OpenPOWER SBC project, possibly one that might be even better suited for that environment. Plus, being Raptor, you know all the components will be open and blob-free (especially now that they've eliminated the blobs for the onboard Broadcom Ethernet, leaving just the Microsemi PM8068 as the last blob firmware component and only if you buy it as a BTO option). It will be worth watching to see when and how all this comes to market. Either way, getting your choice of BMC alternatives is a really great thing especially when the BMC is so critical to the system as a whole.

GNU Guix 1.3

As previously promised, support for POWER9 is now officially a part of the newly released Guix 1.3. Besides many performance and functionality improvements allowing you to Scheme your way to a full installation (or roll back one), the OpenPOWER port should run on any POWER9 PowerNV system (no word on POWER8 support currently, although the support is for generic powerpc64le). Note that as many binary substitutes aren't yet built for POWER9, support is still considered a "technology preview" and you will need to build many of the packages from source for the time being. It is expected this support will catch up as more build capacity comes online.

The only disappointing thing about this announcement is that there doesn't appear to be a way to install standalone Guix (i.e., Guix System) on OpenPOWER yet, nor are there any ISO images you can just pop in your workstation; you'll need to install some other bootable foreign distro and install Guix-the-package-manager on top of it. Presumably Debian, Fedora, Void and others will be suitable, but a full from-scratch install option will be needed to bring this port fully up to parity.

LibreBMC announced, end of Kestrel?

Oh, how timely. On the heels of our article yesterday on "little Power" comes an official announcement from the OpenPOWER Foundation for LibreBMC, a fully open and Power ISA-based BMC replacement.

All PowerNV systems currently use some form of ASPEED BMC to provide the baseboard management features necessary to run the system (what we old fogies used to call "service processors"), which on these machines includes IPMI, offering the PNOR flash ROM to the processors to start the machine, a 2D frame buffer, environmental monitoring, network, front panel and other on-board interconnects. They run their own operating system, almost always OpenBMC, and function as a computer-within-a-computer. The goal here is to replace the ASPEED devices with a multi-vendor supported option compliant to the Open Compute Project's Data Center Secure Module Specification, but would (from our perspective as users and operators) appear much the same. It would also be compatible with Power, x86 and ARM systems like current BMC offerings. However, unlike ASPEED chips which are ARM-based, LibreBMC would run on a Power ISA core, possibly even a descendant of Microwatt.

Some of the names announced in connection with LibreBMC are familiar: Yadro appeared in yesterday's piece, a Russian developer of high performance systems and storage solutions, and Google was one of the developers of the OCP DC-SCM spec and is undoubtedly advising on the high-level design. Raptor is also involved, which is very good news, because their involvement suggests there are unlikely to be hidden blobs and the LibreBMC will be truly an open device (the announcement says it's all open tooling using LiteX, and synthesizeable on Lattice and Xilinx FPGAs). If you want a "little Power" system-on-a-chip, you could do a whole lot worse than simply ripping this off into a little stand-alone developer board. Maybe this is where the PowerPi will come from.

But, oddly, despite their involvement Raptor isn't making LibreBMC: that's being done by Antmicro, who currently has RISC-V and ARM-based products and will be "developing the LibreBMC card," implying that LibreBMC will also be offered as a physical component instead of just IP and VHDL code. Specifications for the physical form factor are even in the DC-SCM specification: it has a special slot similarly sized to an OCP NIC, but differently keyed, and the vertical form factor option 1 in particular looks very much like Beagle Boards and RPis. The fact that LibreBMC will run OpenBMC also suggests this is not a direct port of Kestrel, Raptor's own prototype BMC replacement; Kestrel currently runs its own OS based on Zephyr.

If this is a quiet way of announcing Kestrel is throwing in with LibreBMC, this would disappoint me somewhat. Kestrel, though granted in a very early form, seemed a better fit for those of us on the small but visible Power workstation side if its promises on faster start times were to be believed. In particular its trimmer OS choice was an important difference: OpenBMC's problem (from my outsider view) is that it wants to be all things to all workloads, which means a bigger loadout with more features but slower start times and a much larger firmware footprint. LibreBMC's move to a higher-performance Power core should help but software always expands to meet the available CPU power. BangBMC is still out there and aimed to address performance by cutting out fat like dbus and systemd, and apparently is now facilitated by Raptor, but it hasn't gotten a great deal of traction and nobody ships it as default, for example. A bespoke fast-start workstation-oriented BMC would be a great fit for our desktop systems but LibreBMC doesn't sound like that. And if this is going to be the simultaneous basis of a little Power board as well, bootup time really has to be better.

There are also the practical aspects for current owners: OpenBMC isn't going to drop ASPEED support anytime soon since there's a large install base running it (on lots of machines, not just OpenPOWER), but future updates would understandably prioritize the new hotness. Kestrel, although you needed a soldering iron, could be retrofitted to existing boards. Especially since open POWER10 systems will be slower to arrive, what about a LibreBMC retrofit option (that doesn't involve board work) for existing machines? Will the Antmicro "card" offer this, or will there be an aftermarket product from Raptor or another vendor? We'd also like whatever hardware and software improvements the LibreBMC initiative will foster especially if we won't be replacing our systems for awhile.

Nevertheless, I wait to see what happens with cautious enthusiasm, because I think that the importance of the BMC to the system (it runs and sees everything, after all) really demands an open solution. Plus, the presence of a BMC means there's (going to be) an OpenPOWER SoC, meaning smaller Power solutions may be just around the corner. Whoever ends up making it, this is good news.

The strange bedfellows who want a little POWER

Thanks to reader Karl S for the initial report that got me down the rabbit hole, who discovered a quiet entry for a PowerPi workgroup at the OpenPOWER Foundation, clearly modeled on the ARM-based Raspberry Pi.

The obvious basis for a "little Power" device would be something like Microwatt, which Raptor is already using for Kestrel, and to which IBM staff regularly adds new features. While IBM also opened up other cores, notably the A2 family, Microwatt is (or at least will be) more like what's under our desk in terms of supported instructions and features, and is probably the easiest of the open synthesizeable cores to work with right now.

Still, Microwatt is "merely" a core, albeit a rapidly developing one, and not actually a product for sale or even a chip (though it may be in the near future). This makes the PowerPi concept particularly interesting in that it's trying to use real hardware to appeal to the same market segment that would rather experiment with something smaller, but end up unrealistically repelled by even Raptor's "low end" (relatively) pricing and reach instead for ARM or RISC-V boards because of their sensitivity to cost.

The PowerPi workgroup has four members. The first three are IBM (naturally); YADRO, a Russian manufacturer of high performance servers and storage solutions; and Van Tosh, a Belgian cloud solutions provider with their own RHEL offshoot. With the exception of IBM, none of them seem to have the expertise to work on a mini-POWER system, nor do their current sites indicate any particular proclivity.

But the fourth is noteworthy, a company called ChipEleven, a new, privately held VC-backed fabless design firm based in New Orleans that started just last year. Its CEO is a Master's student at Georgia Institute of Technology. They advertise a system on a chip with lots of peripheral interconnects, a quadcore ISA 3.0B-compliant CPU, an ARM Mali G77 GPU, onboard VGA up to 1920x1080, Ethernet, SPI flash and DDR4 RAM controller, with an ETA of 2023.

Does this sound a little familiar? It might, because an earlier project exists called Libre-SOC. Libre-SOC started with a RISC-V design to serve as a libre GPU, interestingly based on the CDC 6600, but shifted to OpenPOWER for higher performance and now plans to release an entire SoC instead. Raptor has provided material assistance (though Kestrel is proceeding on its own separate path) and development by volunteers is funded by NLNet donations. Allegedly, ChipEleven started with the Libre-SOC project and cleaved off, though to what extent (if any) ChipEleven's design derives from Libre-SOC is disputed.

It's not generally my habit to report on new speculative projects because a lot of them, even those with well-meaning and motivated people, will eventually flame out or their organizers lose interest. And ChipEleven may do just that: 2023 is a long way off (POWER10 will have certainly arrived by that point) and that doesn't mean there will be an actual physical product you can buy, let alone what it would cost. For its part, Libre-SOC wisely makes no promises. Still, the fact such a workgroup exists and has the backing of the OpenPOWER Foundation is notable, even if the current members are a motley bunch. Whether they can actually ship something is another story.