Remember when we talked about the Snapdragon X Elite SoC back in August? A few months have passed, so it's fair to ask how it's going with Snapdragon X Elite Linux support.

After months of little to no news, we finally have some more data, released by Tuxedo. Linux laptop OEM Tuxedo announced that they were working on a Snapdragon-based Linux laptop around the release date of the X Elite, but there has not been a lot of news about it, up until now. This silence has made several people wonder what was going on, making many wonder whether the project was still in development.

Just a few days ago, Tuxedo posted a status update, detailing how far along they are in shipping their ARM laptop. We have both good and bad news.

Let's start with the good news. In short, yes, the laptop is still in active development and, no, it has not been abandoned. The bad news is, that development has been slower than expected, since Qualcomm has not made much progress on the Linux support for the X Elite platform, focusing, instead, on the Windows experience more.

There are several possible reasons for this. The most likely one is that Qualcomm has a contract with Microsoft revolving around helping port Windows on ARM to the X Elite platform, and reception has not been perfect. Users and tech reviewers alike have been praising its efficiency, but are being left disappointed about things like x86 emulation woes, unstable game support, and bad GPU driver performance. Understandably, Qualcomm might have been forced to get all hands on deck to fix their platform to make the large volume of X Elite Windows laptops on the market viable for the average consumer first.

Despite that, it is not all doom and gloom. Just a few weeks ago, Tuxedo employee and kernel maintainer Georg Gottleuber, overseeing the Linux support for Tuxedo's ARM notebook, submitted the initial version of the device's Device Tree to the Linux kernel.

Let's see why this is a big deal.

What is the device tree

According to Linux kernel documentation, the Linux kernel uses a data structure called the “Open Firmware Device Tree”, or “Device Tree” (DT) in short, as a language and data structure for describing hardware configurations. The kernel reads this data structure to get a description of the machine it is running on, without needing to hard-code details about it in a specific kernel build.

Describing the data structure

The Device Tree is a graph-based data structure.

For those who don't yet know, a graph is described by a finite set of nodes (also called vertices), and a set of edges or arcs, which match unordered pairs of nodes together. Graphically, nodes can be thought of as circles, while arcs can be represented as arrows that connect two nodes. Arcs can have a direction, which can be used by graph traversal algorithms; sequences of actions to completely walk over every node in the graph in order, deciding the path to walk according to different criteria. A graph that consists of directed edges is called a directed graph. Additionally, edges can be augmented with a numeric value called a weight, which encodes information about the cost of traversing from one node to another.

Among other attributes, a directed graph may be either cyclic or acyclic. A graph is cyclic when it contains a cycle — basically, a graph is cyclic when it contains at least one path that includes a node as both its starting and ending point. If you can start from a node, walk through at least two edges from there, and end up on the same node where you started, you are looking at a cyclic graph. Naturally, if you cannot do that, you are looking at an acyclic graph.

With this in mind, the Device Tree is an acyclic graph, also known as a DAG. The nodes represent various hardware components, while the edges represent relationships and dependencies between components. For example, a USB hub will have several dependent nodes — the USB devices that are connected to it.

The Device Tree source code is compiled by the Device Tree Compiler (DTC) into a binary format called the Device Tree Blob (DTB). The kernel reads this binary representation at boot, and it uses it to know what devices and chips are present in the system, and where they are. Of course, we are not only talking about detachable physical devices you can see, like a keyboard or a mouse, but also embedded sub-devices that are part of the same component. Take, for example, a WLAN (Wireless Local Area Network) card. The WLAN card is the component that allows your laptop to connect to 802.11 (Wi-Fi) networks, as well as to other devices over the BLE (Bluetooth Low Energy) protocol. While, physically, this card is just a little module inserted into a small slot on your motherboard, it exposes two separate devices that reside in two separate parts of the device tree: a Wi-Fi network interface, exposed over the PCIe (PCI-Express) bus, and a Bluetooth interface, exposed over a USB (Universal Serial Bus) bus.

Difference between x86 and ARM

On regular x86 laptops, this mapping is already present in the UEFI firmware, described as ACPI tables. ACPI, which stands for Advanced Configuration and Power Interface, is an open standard that some firmware implementations use to advertise the devices that are part of the system to the operating system through a key-value data structure called “ACPI tables”. At boot, when the operating system detects ACPI tables, it reads them to enumerate the hardware devices and allow the various drivers and kernel modules to interact with all compatible discovered devices.

If you have been wondering why Linux seems to run to some degree on pretty much every Intel or AMD laptop you throw at it, this is the reason. Your Intel laptop probably does not have its Device Tree mainlined in the kernel. The kernel does not really "know" that you are using a ThinkPad T14 or a Framework 16 (other than being able to show you the name your OEM exposes), the kernel reads the ACPI tables that were exposed by your UEFI firmware after the kernel was bootstrapped, and it knows all the individual devices you have. It knows you have a motherboard based on the Insyde firmware, a PS/2 or USB keyboard on the relevant bus, a Pixart touchpad, a Realtek sound card, Mediatek Wi-Fi and Bluetooth devices, an AMD CPU and GPU, and so on. This is why Linux boots roughly on any x86 laptop, but it does not necessarily support every component. Often, trying to load Linux on a very recent gaming laptop, before the community has had the opportunity to upstream drivers for all its components, will result in a system with missing functionality. For example, it is possible that you can boot the device and get the CPU, GPU, and keyboard to work; but there is no way to get the speakers, keyboard backlight, or Bluetooth device to work. In x86 land, you do not get "supported laptops" under the hood, you mostly get supported peripherals. A Linux-supported Intel laptop is a sum of supported peripherals certified to pass a test suite and work well together in that exact configuration, slapped into a package the OEM is willing to provide ticketed Linux support over. In the real world, there is such a thing as a Linux-supported laptop; but the kernel does not have that concept.

If you are looking at something like that, you can look at some selected devices from big manufacturers, or pick something from a smaller company instead, like Framework or Tuxedo, the vendor behind this promising ARM laptop. Their laptops are great, and they are also fairly priced for the build quality and specifications. To be clear, this is not a sponsored suggestion; I have had positive personal experiences with current-generation Tuxedo laptops, and I feel comfortable recommending them. Otherwise, I wouldn't bother writing this article.

In ARM land, sadly, things do not quite work this way, though. Most ARM notebooks and embedded devices completely lack an ACPI interface, so, they depend on the kernel to know their Device Tree. In that case, the Device Tree is the only way the kernel can enumerate all the devices that make up a system — basically, Linux needs to know you are using a Tuxedo ARM laptop Gen 1; so that it can load the relevant Device Tree for that specific laptop to work. This is one of the reasons why ARM laptops are so complicated to boot on Linux. While any obscure Intel laptop will probably get at least basic functionality on a Linux boot, an obscure, unsupported ARM laptop may not be able to work at all.

What's next?

While this is a very good step, work is far from over. Now that Linux knows the basic structure Tuxedo's ARM laptop has, support for several components listed in the device tree needs to be implemented.

Again, all the Device Tree does is tell the kernel what's inside a device, but it does not know how to operate that device. That is the task of the associated kernel module, which contains the driver code to work with the device. For every device in the tree, the kernel will pass the device and its address to the competent kernel module, which will take it from there.

Right now, the missing functionality is… quite a lot. Tuxedo claims that all USB functionality, including USB-4, the ability to push a video signal to an external monitor through HDMI, and all audio functionality are still yet to be implemented. All in all, the laptop is still not quite usable yet, not even for basic use. Unfortunately, again, Qualcomm has been dragging its feet on Linux support, and Tuxedo's planned collaboration with them did not materialize.

It's not over, though. It is Linux we are talking about: all drivers are developed in the open, and entities other than the original manufacturer are more than welcome to contribute to the development. That is the case for Linaro, a company that has heavily contributed to the ARM ecosystem since 2010. The company is also involved in the open-source ecosystem, with several open-source contributions under its belt. Tuxedo has started a collaboration with Linaro to complete the development of their ARM laptop and, frankly, knowing Linaro's track record, the project is in good hands.

When will it ship?

Unfortunately, Tuxedo cannot yet estimate when the laptop will be ready, but they have told us that we can look forward to long battery life and excellent performance in a lightweight and quiet device.

Honestly, I'm here for it. Although they have their faults, Snapdragon X Elite Windows laptops are known for being quite efficient, generally having better battery life than their Intel and AMD counterparts.

With that said, I am still really looking forward to further evolution on the RISC-V side of things. RISC-V is another architecture that is quite similar to ARM and that promises similar benefits, while not being controlled by a single company, and having an open source ISA. Don't get me wrong: The Snapdragon X Elite is a great System-on-Chip, but, like most ARM computers, it is still mostly proprietary and locked down. On the other hand, RISC-V might be our best bet for finally having good, modern, well-performing open hardware. It also seems to be in a better state for Linux already: if you are interested, we have already covered DeepComputing's RISC-V mainboard for the Framework 13 not long ago.