Asahi Linux gives hope for weird page sizes yet

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

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

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

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

The first production RISC-V portable?

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

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

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

Firefox 98 on POWER

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

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

Red Hat halts sales and services in Russia and Belarus

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

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

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

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

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

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

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

The only good BOB's a dead BOB.

Faster framebuffer landing in Linux 5.18

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