Who got Talos II order #1?

It wasn't me at Floodgap, though ours is an early machine (my unit on the right is serial #12, from order #8). Turns out it was Trevor Dickinson.

If the name sounds familiar to some folks in the audience, that's because Trevor is perhaps best known for his work in the Amiga scene. I'd been watching his PowerPC-based AmigaOne series for awhile to see if they were decent successors to the Quad G5 I used prior to getting the Talos II, though neither the X1000 nor the current iteration of the X5000 are a match for the G5 in raw CPU terms. (I'm also underwhelmed that the NXP P5020 the X5000 is currently using lacks AltiVec, which I think is a terrible omission. More on that in a bit.) On the other hand, if you have a substantial investment in Amiga software (I don't), then these are the gruntiest machines that natively boot AmigaOS, and they can also boot Linux.

I'm not sure if Trevor was a backer of the original POWER8 Talos (I was), but he definitely got in at the ground floor with his T2. Not only did he order a rather beefy configuration (dual 18-core POWER9 CPUs and 96GB of RAM, etc., compared to my relatively middling dual 4-core with "just" 32GB), but Raptor even sent him a cool "order #1" certificate to commemorate his getting in first.

What's Trevor doing with this machine? Well, apparently, nothing. He mentions that the "beta Linux" he was instructed to download didn't work, though I don't recall my unit coming with any such thing. Indeed, I selected Fedora precisely because it booted on the T2 out of the box, and I can't imagine my machine arrived much later than his did. But the really baffling part is that his blog post was written just a few days ago and by now almost all the distros that support ppc64/ppc64le support POWER9, so I don't know what's still got him marooned.

He makes another interesting comment: "With the price I paid including shipping and [New Zealand] import duties I could have purchased 8 or 9 complete AmigaOne X5000 systems which can actually run AmigaOS 4, MorphOS and Linux." Well, that's probably true, and despite some wishful pipe dreams I've seen on MorphOS forums, there's very little likelihood AmigaOS or MorphOS will be ported to the T2 anytime soon. But the P5020 in the X5000 isn't even remotely in the same class as the POWER9: it has just two cores with a single thread per core, it has much less cache, it doesn't have AltiVec, let alone VSX, and it doesn't have the memory bandwidth. Part of this is because it's a design dating back to 2010, but the other part of it (and one of my perpetual complaints about recent PowerPC-based Amiga systems) is that it's an embedded-class CPU being put into a desktop environment. I should point out that I actually rather like Amigas; I own several A500s, an A3000 which one of these days I'll get Amix up on, and a '060 A4000T. But eight or nine X5000s lashed together wouldn't equal even a reasonable fraction of the power of the dual 18-core SMT-4 POWER9 he's got there (that's 144 threads, kids, plus everything else the POWER9 supports that the P5020 doesn't).

Still, no one wants a big expensive doorstop, and I hope he's able to get order #1 up and running (though I dispute that "the Talos II Secure Workstation is really aimed at a Linux administrator in a data centre" -- the Talos is now unambiguously my daily driver and I'm no longer a professional system administrator nor do I work in a data centre). I suppose I could drop by if he needs a hand in Aotearoa since I'm currently in the Southern Hemisphere with my wife's family in New South Wales. We fly back to sunny Southern California via Auckland, so we'll see.

Either way, Merry Christmas (or your holiday of choice), whatever your timezone.

IBM chooses Samsung for POWER10

It's official: Samsung will manufacture the upcoming POWER10 on their 7nm EUV process thanks to an expansion of IBM and Samsung's 15-year R&D partnership. The next z microprocessors, which have some low-level microarchitectural similarities to the Power line, will also be produced on 7nm EUV. There are still relatively few details available about either CPU; POWER10 is still scheduled for around 2020-1.

This doesn't change plans for the upcoming final revision of POWER9 in 2019. More details should be forthcoming as that release date approaches.

The saga of the Power ISA 128-bit long double

Our last post on MAME's failure to build on Power yielded some interesting information in the comments which, in my copious spare time, seemed worth researching further. But first a technical digression.

128-bit long double is currently implemented in gcc for Power ISA and PowerPC using "IBM extended doubles." This datatype is actually two 64-bit doubles paired together rather than a single 128-bit value, and specially handled in software. Because this is really a pair of 64-bit floats with altered handling, although it does improve precision (two 52-bit fractions, plus signs), it does not extend the range (as this NumPy bug demonstrates). In this scheme the effective exponent is still 11 bits, and the value thus yielded is not the same as the IEEE 754R 128-bit floating point datatype, which has a 15-bit exponent and a 112-bit mantissa plus sign.

The work to implement the true 128-bit type in gcc supersedes the extended double approach and offers better mathematical performance, and thus eliminates the need on supported systems to implement constant folding for IBM extended doubles, the crux of the g++ constexpr issue that screws up building MAME. What suitable 128-bit registers exist on Power? Why, AltiVec, of course. You can then use POWER9's native quad-precision support to support the new __float128 datatype (or emulate it in software on POWER7 and POWER8). gcc currently implements this feature behind the -mfloat128 option, which requires VSX and has hardware acceleration on POWER9.

However, if you try to use true 128-bit floats as long doubles now, it won't work properly. Why? Because the OS (and in particular libc) also needs to be adjusted for the ABI change. For Fedora, the transition to true 128-bit long double is scheduled for F30, which will include backwards compatibility symbols as the original implementation of 128-bit long double did, and the problem should finally be put to rest. It is likely that other distributions supporting ppc64le are undertaking the same process (we run Fedora here at Floodgap-Talospace).

For big-endian ppc64, there doesn't seem to be an endian restriction on 128-bit float support, so it should work the same way on Talos II systems being run BE (as well as BE POWER7 and POWER8). However, for pre-VSX platforms (such as 32-bit PowerPC, G5, and POWER4 through POWER6), the best solution for compatibility may simply be to find a system that still uses 64-bit long double. By doing so you avoid the problem completely if you don't need the extra precision. Adélie Linux, as reported by its maintainer A. Wilcox, is apparently such a platform.

No love for PowerPC from MAME

MAME, the famous multi-system emulator, has been broken on Power ISA since around 0.194 due to a long-standing gcc bug with 128-bit long double. This bug hasn't been paid attention to in 12 years, and is rather beyond my personal ken to take a whack at as well. Near as I can determine, the issue affects every Power ISA platform with such a datatype including 32-bit, 64-bit and 64-bit little-endian.

Besides a minor fix for one of their upstream libraries on little-endian PowerPC, the most straightforward workaround to get MAME up on the Talos II is to simply use 64-bit long doubles by setting the compiler flag -mlong-double-64. This is admittedly a non-standard ABI option but appears to work just fine as the screenshot demonstrates. However, rather than allow this (hopefully temporary) workaround to fix the platform given that the gcc issue is longstanding and apparently difficult to resolve, the MAME team decided not to allow any such workaround even given that it clearly wouldn't affect anything else. It's their project, but I really think that sucks, because it means MAME won't build on any PowerPC system out of the box for the foreseeable near future.

You have two options. The first is to change the makefile and/or set the appropriate compile-time options to use clang instead of gcc. I haven't tested this and clang isn't my preferred compiler on Power ISA as it's less mature on this architecture, but it is a supported compiler at least for MAME on macOS, so it should work. You'll still need the bx patch below right now (read on) if you're building on ppc64le.

Otherwise, you can apply the patch that was rejected to get gcc builds working. You'll still need the bx portion of this diff right now for either compiler on little-endian systems, though hopefully at some future point the bx patch will be accepted upstream and merged back to MAME. Again, as a non-standard ABI there is the potential for conflict with code that may not expect the altered datatype, but this is the build I currently use myself and at least as of this writing seems to work.

The POWER continues in Firefox 64

If you are able to build Firefox 63, you should be able to build Firefox 64 without anything additional. Meanwhile, a whole mess of fixes for long-standing issues have landed for Firefox 65 and later, but more about that in a future post.

FreeBSD 12.0 released

FreeBSD 12.0 is released, the latest version of the venerable BSD-derived operating system, with updates to crypto, TRIM support and Clang among other features and improvements. ISO images and downloadable archives are available for ppc64, but this support does not seem to include POWER9 (yet). One of our occasional readers is on this team and perhaps could give an update?

Note that Power support in FreeBSD is big-endian; no word on whether ppc64le will be supported as well.

Fedora 29 mini-review on Talos II

Although I don't think anyone has good data on this so far, I suspect that Fedora usage among Talos II users is pretty high because it was among the first to offer POWER9 support out of the box. I believe Debian has the greatest install base overall because of its general reputation and it seems to be the one Raptor recommends, but I still wager that Fedora is in the top couple. Indeed, coming from the Power Mac world without loyalties to any particular distribution, the fact I could just throw a bootable Fedora CD into my brand-spanking-new T2 and install an OS without any fuss was pretty much the whole reason I'm using Fedora now. Fortunately, after an initially bumpy start with some weird glitches here and there, F28 Workstation has generally been a very pleasant experience and I think most distros that support Talos systems are now to that point. This review, then, is not a general review of Fedora 29, but rather a review of F29 from the perspective of a Talos II user and anything relevant to this platform that I encountered.

If you are unfamiliar with Fedora, the most important thing to remember is that there is no such thing as a Fedora LTS (if you want that kind of extended support, then you really should be using CentOS or Red Hat Enterprise Linux). Releases are maintained on an N+2 system: now that Fedora 29 is out, F28 will be supported until one month after F30 is released and F27 will be shortly unsupported since we are roughly a month after F29 emerged. In practice this means any one release is supported for roughly a year, give or take, so it really is important to stay current with official releases. On the other hand, since the cadence is somewhat quick, the chance of major breaking changes between any two consecutive releases is relatively low.

A few notes about my configuration before we begin. My high security systems are on a standalone wired network that cannot route directly to the Internet, only through proxies, and this system has the BTO AMD WX7100 workstation card as its primary console with the VGA port jumpered off. It comes up with a textual boot (not graphical) so I can do updates with high confidence of not interfering with anything running; I manually do a startx when I want to start GNOME from there. (Incidentally, I didn't like the default icky PC VGA font, so I changed it to the Sun workstation font shown in the photograph which I think befits this machine better. Just set FONT="sun12x22" in /etc/vconsole.conf.)

If you don't have your GPU's firmware loaded in to Petitboot, you may wish to consider doing so before upgrading to or installing F29. If this is not possible or feasible, you may find life a bit easier if you use the VGA port (make sure it is not jumpered off), particularly if you are installing from scratch. In my case, I don't have the firmware on the Petitboot side yet since I rarely work with Petitboot directly, but I did need to have the VGA jumpered back on to actually install Fedora for the first time. For the upgrade this is optional but requires a few more steps. I'll talk about this in a moment for the benefit of those with unusual video cards or issues with them during early IPL.

Rather than upgrade immediately when F29 was available, I waited a few weeks to ensure that updated packages were available from both Fedora and the RPMFusion repositories. When I was ready to upgrade from F28 to F29, I quit GNOME and returned to the text console, and started the upgrade process with the standard steps:

sudo dnf upgrade --refresh # upgrade DNF
sudo dnf install dnf-plugin-system-upgrade # install upgrade plugin
sudo dnf system-upgrade download --refresh --releasever=29 # download F29 packages
sudo dnf system-upgrade reboot # reboot into upgrader

(GNOME Software can apparently do this for you automatically, but I prefer to kick off such updates manually. If you are installing F29 from scratch, however, install from the ISO for the Server or Everything versions as usual for ppc64le and then convert to Workstation afterwards if desired.)

If you have the firmware loaded in Petitboot or you are using the VGA, you can see the upgrade progress automatically begin after the system reboots. If you don't, however, you can still monitor the system by pressing CTRL-ALT-F2 for an alternate console, logging in as root (other UIDs are locked out) and periodically issuing

dnf system-upgrade log --number=-1

which displays the log so far. You'll see the normal dnf strings you would ordinarily do as it goes through the packages.

On my system the upgrade process (after the reboot) took about an hour and I went to bed in the middle of it. I woke up a few hours later to find the Talos at a black screen with its fans roaring at top volume, which looked like it had gone berserk during IPL when the upgrade ended with an automatic reboot. This caused a few nervous moments when I had to hard-power it off from the front power button and bring it back up. Fortunately, the machine then booted immediately into F29 and the system upgrade log showed that dnf had completed the upgrade without any errors. All of the packages I currently use seem to have made it over, so pretty much anything else you need to have on ppc64le should "just work" at this stage.

There are many small improvements in F29 but the two big ones are Fedora Modularity, allowing shipping multiple package versions on the same platform base, and GNOME 3.30. Although this problem is not specific to the Talos, the GNOME upgrade introduces issues of its own:

One minor annoyance was that the system monitor extension I use had gone a little nuts and needed to be reconfigured. However, the big annoyance is that as you can see from the screenshot Epiphany (GNOME Web) no longer supports plugins, including the one to manage GNOME extensions. The Tweaks window demonstrates I use quite a few of them, so losing that feature really hurts their management -- especially because trying to install and use the Firefox extension instead still gives up with an error about a missing "native host connector" even after I installed and manually confirmed the native host component was present. The big one was that Dash to Dock needed an upgrade and installing GNOME extensions by hand isn't exactly an entertaining pastime.

The trick is that the Fedora package for the native host connector only includes the JSON native messaging descriptor for Chrome. Since we don't/won't use Chrome and there isn't an official release for POWER9 anyway, we have to create our own: once you have downloaded and installed the Fedora native host connector package and the GNOME shell extension for Firefox, place the contents of this gist into ~/.mozilla/native-messaging-hosts/org.gnome.chrome_gnome_shell.json and restart Firefox. Now, when you visit the GNOME Extensions site, it should simply "just work" and the browser should now be able to automatically enumerate, install, disable, enable and upgrade your GNOME extensions.

On the whole, a week into the installation, I don't notice a great deal else, which means the upgrade was relatively uneventful overall (the most desired attribute of any system update). One thing I do notice is that running updates is now quite a bit faster (downloading a lot less metadata) and this is very welcome. Bumps are unfortunately to be expected and we should be striving for better in Linux if we want to be a viable alternative to macOS and Windows, but I'm relieved to say that at least with this update, the update wasn't much bumpier on our unusual black beast.

CentOS 7.6.1810 available

CentOS 7.6.1810 is now available based on Red Hat Enterprise Linux 7.6 (fresh off the IBM merger). Separate ISO images are available for ppc64 and ppc64le, along with a standalone build for POWER9 which should support Talos family machines. You can read the release notes for CentOS-specific information and get more information on RHEL 7.6, from which it descends.

Why we need Firefox on Talos, not just Chromium

Today's news is that apparently EdgeHTML, the layout engine for the Edge browser, is being replaced not just on mobile, not just for ARM on Windows, but even on Windows 10 itself -- with Chromium. There's more about that on our sister blog, TenFourFox Development.

This potentially allows Chromium to arrogate even more browsershare to itself, enabling Google to continue with eroding support for anything that isn't Chrome. If you're using a Talos II as I am, you of all people should recognize the vulnerabilities of an architectural monoculture. We've seen that with Intel's stagnation on x86, we saw that with Internet Explorer 6, and we're about to see it again if Chromium is successful in driving Gecko's marketshare to irrelevancy.

Chromium on POWER9 exists, and apparently works; I won't use it personally for the reasons I cited above, but I salute the work that went into it. (Too bad Google doesn't seem to.) Mozilla, on the other hand, has been willing to accept PowerPC patches even after PPC OS X was no longer a tier-1 platform (which is where TenFourFox came from), and is taking patches to repair Firefox builds on ppc64le today. They've taken some of mine, and they've even taken patches to fix big-endian PowerPC and PPC64. The irony with the current big-endian issues is that they're actually with Skia, which was written by ... Google.

Mozilla has proven willing to support platforms outside their core as long as those platforms take responsibility and the support for those platforms doesn't interfere with tier-1 builds. This is an eminently reasonable policy. Moreover, with the exception of the JIT, which I'm trying to work on between TenFourFox, Christmas holidays and visiting family, Firefox exists and works and can be built. We need to remember that after Microsoft imminently outsources their browser to Chromium, Gecko (Firefox) will be the last major rendering engine that isn't Chromium or WebKit. Nothing else has enough marketshare for any other developer to think about, least of all Google themselves. If we don't act to support and preserve its marketshare on a platform where choice and freedom are part of its DNA, we may confront a future where Chromium is the only choice. And Google's already showing us what that future's going to look like.