This article is targeted at embedded engineers who are familiar with microcontrollers but not with microprocessors or Linux, so I wanted to put together something with a quick primer on why you’d want to run embedded Linux, a broad overview of what’s involved in designing around application processors, and then a dive into some specific parts you should check out — and others you should avoid — for entry-level embedded Linux systems. This is some seriously detailed writing, and an amazing starting point for people interested in developing for embedded Linux.
Linux 5.9 is out as the 2020 autumn kernel update. Linux 5.9 has a number of exciting improvements including initial support for upcoming Radeon RX 6000 “RDNA 2” graphics cards, initial Intel Rocket Lake graphics, NVMe zoned namespaces (ZNS) support, various storage improvements, IBM’s initial work on POWER10 CPU bring-up, the FSGSBASE instruction is now used, 32-bit x86 Clang build support, and more. It will make its way to your distribution eventually, to your separate kernel repository, or, for the brave ones, to your compile command.
This version of the book has undergone a major reorganization. It uses enhanced cross-compilation techniques and an environment isolated from the host system to build tools for the final system. This reduces both the chance for changing the the host system and the potential of the host system influencing the LFS build process. Major package updates include toolchain versions glibc-2.32, gccc-10.2.0, and binutils-2.35. In total, 37 packages were updated since the last release. The Linux kernel has also been updated to version 5.8.3. There’s a separate version for systemd – for those so inclined.
Automotive Grade Linux is a collaborative open source project that is bringing together automakers, suppliers and technology companies to accelerate the development and adoption of a fully open software stack for the connected car. With Linux at its core, AGL is developing an open platform from the ground up that can serve as the de facto industry standard to enable rapid development of new features and technologies. It’s got some big names backing it.
As Phoronix notes: See our Linux 5.8 feature overview for all the exciting changes from an AMD Energy Driver for Zen/Zen2 CPUs to new F2FS compression capabilities, POWER10 CPUs starting to boot with the mainline kernel code, power management improvements, and much more. This is also the first major kernel release featuring the new inclusive terminology guidelines. You can build it yourself, or just wait until it trickles down into your distribution of choice.
Since I wanted to see how Linux would detect the drive that meant I needed to find a way to boot Linux. After a bit of googling I discovered the make tinyconfig option which makes a very small (but useless) kernel, small enough to fit on a floppy. I enabled a couple of other options, found a small enough initramfs, and was able to get it to boot on the 486. And as expected Linux has no problem with seeing that the drive is connected and the drive’s full capacity. Next step is to actually get Linux installed to the hard drive. I’d rather not roll my own distro but maybe I’ll have to. Another possibility is to boot Linux from floppy and then download a kernel and initrd from a current distro and kexec over to it. But that feels to me like reinventing iPXE. That’s version 5.8 of the Linux kernel running on a 486. I shouldn’t be surprised that this is possible, yet I’m still surprised this is possible.
To meet our customers where they are and relieve customer challenges in managing multiple security solutions to protect their unique range of platforms and products, we have been working to extend the richness of Microsoft Defender ATP to non-Windows platforms. Today we are excited to announce general availability of Microsoft Defender Advanced Threat Protection (ATP) for Linux! Adding Linux into the existing selection of natively supported platforms by Microsoft Defender ATP marks an important moment for all our customers. It makes Microsoft Defender Security Center a truly unified surface for monitoring and managing security of the full spectrum of desktop and server platforms that are common across enterprise environments (Windows, Windows Server, macOS, and Linux). Defender ATP is an enterprise product, so this news doesn’t mean the end-user program that ships with Windows is coming to Linux. Still, seeing Microsoft embracing Linux left, right, and centre is still a weird sight for someone who still hasn’t forgiven Microsoft for their role in killing any chances of BeOS catching on. I’m still bitter over that one.
A few weeks ago, we talked about how Ubuntu is forcing snap packages on users, even when using apt. Since various distributions are based on Ubuntu, a lot of users of those distributions are wondering if snaps will infect their systems, too. One of the most popular Ubuntu-based distributions, Linux Mint, has a clear answer. First, I’m happy to confirm that Linux Mint 20, like previous Mint releases will not ship with any snaps or snapd installed. Second, to address this situation we’ll do exactly what we said we would: • In Linux Mint 20, Chromium won’t be an empty package which installs snapd behind your back. It will be an empty package which tells you why it’s empty and tells you where to look to get Chromium yourself.• In Linux Mint 20, APT will forbid snapd from getting installed. You’ll still be able to install it yourself and we’ll document this in the release notes, but by default APT won’t allow repository packages from doing this on your behalf. This is good news, and the right route to take.
As far as Linux 5.7 goes there are many new features and improvements like an Apple USB “Fast Charge” driver, Intel Tiger Lake “Gen12” graphics are now deemed stable and promoted out of the experimental flag, AMD Renoir graphics are in good shape, F2FS Zstd support, Qualcomm Snapdragon 865 support on this mainline kernel, and a lot more. You can of course build the new kernel yourself, but it’ll make its way to your distribution of choice soon enough.
10 years ago, systemd was announced and swiftly rose to become one of the most persistently controversial and polarizing pieces of software in recent history, and especially in the GNU/Linux world. The quality and nature of debate has not improved in the least from the major flame wars around 2012-2014, and systemd still remains poorly understood and understudied from both a technical and social level despite paradoxically having disproportionate levels of attention focused on it. I am writing this essay both for my own solace, so I can finally lay it to rest, but also with the hopes that my analysis can provide some context to what has been a decade-long farce, and not, as in Benno Rice’s now famous characterization, tragedy. The end of this massive article posits a very interesting question. What init system does Chrome OS use? And Android? Do you know, without looking it up? Probably not. What does that tell you?
When the parts were almost in, I had decided to really start digging into NixOS. Friends on IRC and Discord had been trying to get me to use it for years, and I was really impressed with a simple setup that I had in a virtual machine. So I decided to jump head-first down that rabbit hole, and I’m honestly really glad I did. NixOS is built on a more functional approach to package management called Nix. Parts of the configuration can be easily broken off into modules that can be reused across machines in a deployment. If Ansible or other tools like it let you customize an existing Linux distribution to meet your needs, NixOS allows you to craft your own Linux distribution around your needs. Unfortunately, the Nix and NixOS documentation is a bit more dense than most other Linux programs/distributions are, and it’s a bit easy to get lost in it. I’m going to attempt to explain a lot of the guiding principles behind Nix and NixOS and how they fit into how I use NixOS on my desktop. I’m hearing more and more people talk about NixOS lately, and I’ve been wondering why. This article is an excellent overview into this unusual Linux distribution.
The Linux kernel lockdown patches were merged into the 5.4 kernel last year, which means they’re now part of multiple distributions. For me this was a 7-year journey, which means it’s easy to forget that others aren’t as invested in the code as I am. Here’s what these patches are intended to achieve, why they’re implemented in the current form and what people should take into account when deploying the feature. Root is a user – a privileged user, but nevertheless a user. Root is not identical to the kernel. Processes running as root still can’t dereference addresses that belong to the kernel, are still subject to the whims of the scheduler and so on. But historically that boundary has been very porous. Various interfaces make it straightforward for root to modify kernel code (such as loading modules or using /dev/mem), while others make it less straightforward (being able to load new ACPI tables that can cause the ACPI interpreter to overwrite the kernel, for instance). In the past that wasn’t seen as a significant issue, since there were no widely deployed mechanisms for verifying the integrity of the kernel in the first place. But once UEFI secure boot became widely deployed, this was a problem. If you verify your boot chain but allow root to modify that kernel, the benefits of the verified boot chain are significantly reduced. Even if root can’t modify the on-disk kernel, root can just hot-patch the kernel and then make this persistent by dropping a binary that repeats the process on system boot. These patches are intended to prevent that, and this blog post goes into detail about how it all works.
Intel’s Dynamic Platform and Thermal Framework (DPTF) is a feature that’s becoming increasingly common on highly portable Intel-based devices. The adaptive policy it implements is based around the idea that thermal management of a system is becoming increasingly complicated – the appropriate set of cooling constraints to place on a system may differ based on a whole bunch of criteria (eg, if a tablet is being held vertically rather than lying on a table, it’s probably going to be able to dissipate heat more effectively, so you should impose different constraints). One way of providing these criteria to the OS is to embed them in the system firmware, allowing an OS-level agent to read that and then incorporate OS-level knowledge into a final policy decision. Unfortunately, while Intel have released some amount of support for DPTF on Linux, they haven’t included support for the adaptive policy. And even more annoyingly, many modern laptops run in a heavily conservative thermal state if the OS doesn’t support the adaptive policy, meaning that the CPU throttles down extremely quickly and the laptop runs excessively slowly. It’s been a while since I really got stuck into a laptop reverse engineering project, and I don’t have much else to do right now, so I’ve been working on this. It’s been a combination of examining what source Intel have released, reverse engineering the Windows code and staring hard at hex dumps until they made some sort of sense. Here’s where I am. Someone has to do the dirty work.
I guess current world events are starting to affect the flow of news in our sector, too, since there’s a decided lack of interesting stuff to talk about. So, let’s talk about this: One of the immediate differences Ubuntu 20.04 desktop/laptop users will notice when booting in UEFI mode is the boot splash screen improvements thanks to leveraging Red Hat’s work on providing a flicker-free boot experience and pulling in the UEFI BGRT system/motherboard logo during the boot process to provide a more transitive experience. Canonical in turn is working on pushing some of their improvements back into upstream Plymouth. The Ubuntu 20.04 LTS boot experience is on-par to what has been found in Fedora and other Linux distributions like Arch Linux for over one year. I love it when different distributions and other projects work together to improve something that isn’t particularly sexy or high on anybody’s agenda, yet still is a welcome improvement. This is a great example of that.
Earlier this evening, Linus released Linux 5.6, which contains our first release of WireGuard. This is quite exciting. It means that kernels from here on out will have WireGuard built-in by default. And for those of you who were scared away prior by the “dOnT uSe tHiS k0de!!1!” warnings everywhere, you now have something more stable to work with. The last several weeks of 5.6 development and stabilization have been exciting, with our codebase undergoing a quick security audit, and some real headway in terms of getting into distributions. WireGuard is probably the biggest new feature in 5.6, announced earlier today.
Ars Technica reports on a story from the early 2000s 2020: When software and operating system giant Microsoft announced its support for inclusion of the exFAT filesystem directly into the Linux kernel back in August, it didn’t get a ton of press coverage. But filesystem vendor Paragon Software clearly noticed this month’s merge of the Microsoft-approved, largely Samsung-authored version of exFAT into the VFS for-next repository, which will in turn merge into Linux 5.7—and Paragon doesn’t seem happy about it. Yesterday, Paragon issued a press release about European gateway-modem vendor Sagemcom adopting its version of exFAT into an upcoming series of Linux-based routers. Unfortunately, it chose to preface the announcement with a stream of FUD (Fear, Uncertainty, and Doubt) that wouldn’t have looked out of place on Steve Ballmer’s letterhead in the 1990s. This is some “get the facts” level of tripe. You’d think that in 2020, we’d be spared this sort of nonsense, and I’m sad I’m even spending precious bits on this one – but at least we get the name of Paragon out so you can avoid them like the plague.
For those managing to get their hands on a recently released Loongson 3A4000/3B4000 or even older Loongson 3 MIPS64 processors, improving the support is on the way with the upcoming Linux 5.7 kernel. Queued as part of the MIPS architecture work for Linux 5.7 are a number of Loongson improvements, in particular for the Loongson 3 series. The Loongson processors are pretty much impossible to come by outside of China, and gained some fame as the platform of choice for Richard Stallman.
In the previous installment of this three-part series, we took a look at the reasons why having truly open source-friendly Linux-based phones are not only a good thing to have but are also necessary to shake up things in the mobile space. The idea, of course, isn’t new and goes as far back as the OpenMoko community-driven project and even the mostly-but-not-totally open source Nokia N900 and N9. Those days are long gone, however, and the smartphone industry has changed drastically over the last decade and so have the attempts at making Linux phones. In this part, we take stock of the options that are currently available not just to Linux enthusiasts but to privacy and freedom-loving people as well. I’d love to have a mobile operating system based on Linux that isn’t Android, but it seems like all the options still have a long, long way to go.
We’ve known that Intel’s P-State Linux CPU frequency scaling driver in general can be a bit quirky and especially so when dealing with Intel integrated graphics where the iGPU and CPU share the same power envelope. This has been shown with examples like using the “powersave” governor to boost iGPU performance while discrete graphics owners are generally best off switching over to the “performance” governor. As the latest though on helping the iGPU front with P-State, there is a new patch series talking up big gains in performance and power efficiency. Francisco Jerez of Intel’s open-source driver team sent out a set of ten patches today working on GPU-bound efficiency improvements for the Intel P-State driver. This is a very welcome patchset, since the interplay between Intel processor and Intel integrated GPU isn’t exactly optimal, as we’ve talked about before.
Admittedly it’s been while since I last wrote about this (formerly MATE-based) desktop environment, but it’s still out there, shipping as default experience in Ubuntu Kylin, doing its thing. But not for much longer, it seems. Based on an updated shared on Chinese social media, the UKUI team appear to be rebuilding UKUI using Qt. The plan, they say, is to stick to to the same “easy, excellent, expert, elaborate” mantra that the original UKUI desktop was (supposedly) built to. I’m highlighting this here because there’s a ton of interesting Linux desktop work going on in China that we in the west rarely talk about, such as Deepin and its Qt-based Deepin Desktop Environment that’s also available on some other distributions. UKUI fits in that same bucket. There’s, of course, legitimate concerns over code from China, but since these projects are open source, it would seem there’s little to worry about on that front. The fact of the matter is that, totalitarian dictatorship or not, Chinese people are just regular folks, and many of them are probably excellent programmers and designers that can contribute a lot to the health, variety, and competition within the desktop Linux and wider open source community.