Tag: computers

Clearing confusion regarding modern PowerPC endianness

I am having to correct, with alarming regularity, confusion regarding the endianness of modern PowerPC and POWER chips.  This article is going to answer a lot of those questions, with facts and citations.

What endianness are modern PowerPC / POWER CPUs, including POWER9?
Fact: All POWER Architecture processors since POWER3 support both big and little endian modes. This is because the PowerPC ISA defines an endian-switch bit in a processor control register (MSR), and all POWER processors since POWER3 implement the PowerPC ISA. The PowerPC ISA dates back to the 1990s, where AIX and Linux were exclusively big endian and Windows NT (yes, Windows NT) ran on PowerPC in little endian mode. Most POWER hardware, and most PowerPC computers, historically had firmware that only supported big endian mode. Reports are that POWER4 and POWER5 chips do not support setting the MSR because no firmware supports this mode, but I have no citation to confirm nor deny this. (My IBM POWER hardware starts at POWER6.) This has changed with POWER8, and now modern computers support both. POWER8 and POWER9 can run in either endian, though they still default to big endian during initial bootup (and the firmware services are still in big endian, requiring a byteswap for little endian OSes).
Isn’t Linux only being developed for PowerPC on little endian now?
Fact: The Linux kernel supports both endians equally.
Didn’t Debian drop support for big endian PowerPC with Jessie?
Fact: Debian still “actively supports” big endian 64-bit PowerPC; it is not a release architecture because it does not have enough dedicated maintainers. The port is still fully functional and is kept up to date.
When you buy a new POWER computer, aren’t your only choices of operating system little endian?
Fact: In addition to Debian’s big endian port, there are plenty of other operating systems that support big endian. Gentoo’s PPC64 profile is bi-endian in nature. FreeBSD and Adélie Linux are exclusively big endian, and support all the modern features of POWER9 including DARN, Radix MMU, and more. Devuan is currently adding PPC64 support for both endians.
Isn’t IBM (or OpenPOWER, or [another member organisation of OpenPOWER]) investing solely in little endian for the future?
Fact: OpenPOWER is dedicated to supporting development of both BE and LE.

Aren’t you stuck with one endian or the other?
Fact: Linux’s KVM hypervisor lets you run an environment with the opposite endianness of your host. You can freely run either endian on your host and still have the software of the other endianness available to you with no issues.

Status update for Firefox on PowerPC / big endian

(This post is probably not interesting to non-technical observers.  Rest assured, I’m still working quite hard on porting Firefox to PowerPC when I have the chance.)

I’ve just pulled the latest Firefox code (from mozilla-central) and have fully rebuilt Firefox with the latest code.

First, the good news: JS-API tests are still 100% passing.  XPC Shell tests are up!  10 more tests pass now, and it took a full 17 minutes less time to run the test suite.  This is huge; it shows that if we (the POWER, SPARC, System/390, etc communities) work together with Mozilla to truly fix Firefox on big endian, there should be no issues keeping it working.

And now, some of the worse news.  Skia m71 has landed on the tree, which is meant to bring feature-parity with Chrome 71.  This was a major loss for us.  Skia does not compile at all on any architecture other than x86 and ARM.  Once that bug was patched around, it also does not compile correctly on big endian systems; thankfully, Marcus from the Raptor Talos community already had some patches written for this during their Chromium port sprint.  And now, unfortunately, comes the truly bad news: even after fixing all the build errors, it is not possible to start Firefox with Skia m71.  This seems to be related to the text layer code, which was not always working correctly anyway.  Before, this would just cause some graphical glitches; now it is a completely fatal error.

This will require more digging than I presently have the time to consider, unfortunately.  I probably won’t get back to Mozilla porting until early next week.  This will give me the time I need to focus on writing Parcel, Adélie’s next-generation package database tool and Web site.

If you like what you see and want to ensure that Firefox is ported to POWER, in addition to all of the other important work that we do improving the Linux ecosystem, please consider supporting the Adélie Linux project on Patreon, or chipping in with cryptocurrency.  Your support is what keeps efforts like this going.  Thank you!

Big Endian Firefox: Now with more compositing

I’m currently in the process of trying to bring up the PowerPC platform as a fully supported architecture in Firefox.  I’ve already implemented better support for XPCOM / JS interfacing, and fixed a crash in the JavaScript interpreter. My next challenge is fixing graphical issues, which is proving to be more of a challenge than I initially anticipated.

However, I have broken some new ground.  Before, the compositing engine had wildly inaccurate colouring caused by errant “swizzle methods” (which are functions that take images of one colour type and change them to another – or, “swizzle” them).  This resulted in Firefox 64 (Nightly) looking like this on my workstation:

Firefox, with blue blocks and weird colours everywhere
Firefox, with a broken compositor

I’ve just managed to fix these methods and lo and behold, Firefox 64 (Nightly) looks like this now:

Screenshot_20181019_205618
Firefox, with working compositor

Obviously, there are still some minor nits to work out.  (Namely that my avatar in the top right corner has a blue tint to it!)  I believe the last issues are going to be in the Cairo code, which seems to get very confused by Skia’s byte ordering.  I already have a lead on how to potentially fix this issue.  The good news is that there are no longer any (non-debug) crashers, unless you attempt to view H.264 video.  This is because video playback via FFmpeg crashes due to another byte ordering issue.

All in all, I’m very satisfied with what I was able to knock out in just a few hours on a Friday night.  Thanks go to the #gfx chat room on Mozilla IRC for their guidance in what to look at.

Ridiculous unusable download URLs for open source projects

I told myself (and everyone I know) that I wouldn’t write another blog post until I moved the blog off Google Blogger, but I can’t stay silent on this issue.

UPower, the open source power management software used on Linux (and I believe the *BSD family), has recently changed their download URLs. As the lead of Adélie Linux, I personally maintain a significant chunk of “core” desktop experience packages. We consider UPower to be one of those, because it is important to conserve energy whenever possible.

Today I was notified by Repology that UPower was out of date in Adélie. No big deal, I’ll just bump it:

>>> upower: Fetching https://upower.freedesktop.org/releases/upower-0.99.8.tar.xz 
curl: (22) The requested URL returned error: 404 Not Found

“Hmm”, I wondered to myself, “maybe this is a git snapshot package someone uploaded”. It turns out it wasn’t; Debian, Arch, and Fedora are all shipping 0.99.8 now. What gives?

I looked at Debian’s packaging first, since they typically have a good hold on stability. I didn’t even understand the change, though, so I looked up Exherbo’s packaging and was horrified.

Instead of a simple URL, they are now using a GitLab Upload URL which contains an SHA-1 hash in the URL. That means all of our bump scripts can’t work any more. Instead of simply typing a single abump command, for every release of UPower I will now have to:

  1. Open their GitLab instance in a Web browser, which isn’t even installed on any of the staging computers to minimise security hazards:
  2. Wait for all the JavaScript and miscellaneous crap to load;
  3. Context-click the link for the UPower tarball;
  4. Copy the link;
  5. Connect to our staging system remotely from a computer with a Web browser installed;
  6. Open vim on the APKBUILD file for UPower;
  7. Paste the link into the source= line, replacing what is already there;
  8. And then run abuild checksum manually to update the sha512sum in the file.

WHY!? fd.o people, please, out of respect for us packagers that want to give your software to the people who need it, please use your /releases/ directory again!