I’ll admit upfront that there’s more than a bit of irony in the topic I’m about to cover today. As I write these words on Saturday, April 20, Qualcomm is rumored to next week be giving the next public update on the Snapdragon X family, the latest generation of its series of SoCs for computing applications, and following up on last October’s initial unveil.
In-between then and now, the company has collaborated with media partners on a series of performance “sneak peeks”, including more recent ones that, per the applications showcased, are of particular personal interest. And it’s a poorly kept secret at this point that Microsoft plans to roll out its next-generation Qualcomm- and Arm-based mobile computers exactly one month from now, again as I write these words (stay tuned for timely coverage to come on this topic).
My personal experience with Windows-on-Arm is longstanding and extensive, beginning with Microsoft’s Surface RT more than a decade back, which was Arm-based but wasn’t Qualcomm-based (it instead ran on a NVIDIA Tegra 3 SoC) and that I tore down after it eventually died. And in my current computing stable are two “Windows 11 on Arm64 (i.e., AArch64)” systems based on the current-generation Qualcomm Snapdragon architecture, a Microsoft Surface Pro X tablet/laptop hybrid running the SQ1 SoC (a clock-boosted Snapdragon 8cx SC8180X):
and a Windows Dev Kit 2023 (aka “Project Volterra”) desktop based on the SQ3 (Snapdragon 8cx Gen3) SoC, for which I provided a visual “sneak peek” a month back (as I’m writing this):
But what I’m covering today is Microsoft and Qualcomm’s first developer-tailored stab at Windows-on-Arm, the ECS LIVA Mini Box QC710 Desktop, based on a prior-generation Snapdragon 7c SC7180 SoC:
I went into this particular acquisition and hands-on evaluation with eyes wide open. I was already aware, for example, of the sloth-like performance of which other reviewers had already complained. To wit, note that Microsoft’s documentation refers to the QC710 as the “perfect testbed for Windows on Snapdragon (ARM) application developers” (italicized emphasis mine) vs an actual code development platform. Considering the QC710’s testing-focused aspirations, its anemic specs both in an absolute sense and versus the Project Volterra successor such as:
Only 4 GBytes of RAM, and
A 64 GByte eMMC SSD
neither user-upgradeable, to boot (bad pun intended), make at least a bit more sense than they would otherwise…if your code runs smoothly on this, it’ll run on anything, I guess?
So, why’d I take the purchase plunge anyway? For one thing, I’ve always been intrigued by the platform’s diminutive (119 x 116.6 x 35 mm/1.38” x 4.69” x 4.59”, and 230g/0.5 lb.) hockey puck-like form factor:
For another, it comes bundled with a 30W USB-C power supply. Right now, in fact, I’m reliably running mine off the 27W PSU (at top in the following photos) that normally recharges my 11” iPad Pro, believe it or not:
In fact, I recently (and accidentally) learned, when I plugged the wrong end of the USB-C cable into the QC710, that I could even boot it off the iPad Pro’s built-in battery, although the boot process understandably didn’t get very far (the QC710 got confused when it tried to access the iPad Pro’s unknown-format storage).
Price was another notable factor. The QC710 originally cost $219. When I got mine, it was down to $59.27 in open-box condition. And, speaking of “open box”, once I stumbled across initial evidence of the issues, I’ll cover in this writeup, Woot! offered me $30 in compensation to keep it in lieu of sending it back (where it’d likely have just ended up in a landfill).
I figured it’d make an interesting single-function PC acting as a Roon server and tethered to external storage over USB 3.2 Gen1 Type-A, 10/100 RJ45 and/or Wi-Fi 5 (802.11ac 2×2 MIMO, to be precise), for example (although scant system memory, not to mention limited CPU horsepower, might prove problematic). If nothing else, it’d be a decent entry-level donation to someone else. And yes, fundamental engineering curiosity was also an acquisition factor.
Here are some pics of my particular device, as usual starting with box shots:
and now of the QC710 itself, as usual accompanied by a 0.75″ (19.1 mm) diameter U.S. penny for size comparison purposes:
and its accompanying power supply:
So, what was that “initial evidence of issues” that I previously mentioned? In the spirit of “a picture paints a thousand words”, here’s what greeted me the first time I booted the QC710:
The QC710 originally shipped with Windows 10 Home, which doesn’t support BitLocker mass storage encryption. Apparently, though, the previous owner upgraded it to the Pro variant of either Windows 10 or Windows 11, and then either attempted to factory-reset the partition before returning it or Woot! did it prior to resale. Regardless, without the BitLocker key I wasn’t going to be able to get to the existing O/S build. And, by the way, about that “Press the Windows key” statement at the bottom of the screenshot? No go; neither the keyboard nor mouse I had plugged into the system’s two USB-A ports worked. The root issue wasn’t hardware; I stumbled onto the fact that if I hit “ESC” as soon as I saw the initial firmware boot screen:
I’d instead end up in Qualcomm’s BDS (Boot Device Selection) menu, from which the keyboard worked fine until Windows attempted to launch. BDS isn’t a cursor-amenable GUI, you can see, but the mouse was lit up underneath and was presumably also functional outside of Windows.
Alas, I had no BSD documentation, therefore no idea what to do next. Hold that thought.
“No problem,” I figured, “I’ll just reinstall a fresh copy of Windows for Arm” (at additional license key expense, but I digress). Problem, actually: There are currently only two ways to get an ISO of Windows for Arm to put on a USB flash drive. One, which I didn’t try, at least directly (again, hold that thought) involves enrolling as a Windows Insider. The other leverages an unsanctioned-by-Microsoft but slick site called UUP Dump, which I did try. And before any of you ask “what about Microsoft’s Media Creation Tool?”…I tried that too, from both of my Arm-based Windows 11 systems. Both times I ended up with Windows…for x86 CPUs.
So, I went the UUP Dump route instead, trying both Windows 10 and 11, both of which conceptually worked great. In combination with Rufus, I ended up with bootable installer USB flash drives which the QC710 recognized fine. And although I was left with only one free USB-A port, a USB hub attached to it enabled me to connect both my keyboard and mouse. But in both installation-attempt cases, although I ended up at the initial setup screen:
I couldn’t get any further because the keyboard and mouse again weren’t functional. And yes, I even tried separately powering the USB hub versus relying on system power supplied over USB-A. I realized at that point (and my colleague later confirmed) that, for reasons that remain baffling to me, the complete Qualcomm hardware driver stack isn’t natively bundled within the O/S installer. Obviously, USB mass storage support was enabled (therefore the boot-from-flash stick success) and baseline (at minimum) graphics were also functional, enabling me to see the setup screen. But no keyboard or mouse support? Really?
About “my colleague”…the only thing left of that I could think to do was to “throw a Hail Mary pass”…which thankfully ended up getting caught and turned into a touchdown (complete with a spike in the end zone). As I was doing initial research on the QC710 with the thought of perhaps doing a teardown on it (an aspiration with I may yet realize, especially if I can convince myself that it’d be nondestructive and cosmetically preserving) I searched the Internet to see if anyone else had already done one. I didn’t find much on the QC710 at all, and most of the little that I did uncover ended up being underwhelming-results reviews. But I struck gold when I stumbled across a detailed product page (even more detailed now, subsequent to our interaction) from a seasoned and very knowledgeable engineer named Rafael Rivera. The tagline on his LinkedIn profile, “Forward engineer by day, reverse engineer by night”, pretty much sums it up. 😀
I “out of the blue” emailed Rafael a quick summary of who I was and my situation with the QC710, and he rapidly and enthusiastically responded with willingness to help after pulling his system out of storage and refreshing his memory on its details and quirks (his initial writeup was published in mid-November 2021). His suggested first step was a set of instructions (all now documented on his web page) that would:
Use the Qualcomm BSD utility to put the QC710 in UEFI Shell mode, then and mount the QC710 SSD’s main partition as an external USB-cabled drive from another Windows machine (I used my Surface Pro 7+)
Remotely reformat that partition, and then
Remotely use Microsoft’s DISM utility to first put a fresh Windows “build” on that partition and then augment the “build” with the Qualcomm driver suite he’d also published to his web page.
Problem 1: I was able to remote-mount the QC710 partition from my Surface Pro 7+, but when I tried to reformat the new drive letter from within Windows Explorer, it disappeared from view never to return…although something had changed as the QC710 boot screen was now different:
At Rafael’s suggestion, I tried Windows’ Disk Management utility instead, which did the trick (it turned out that my earlier attempt had wiped the partition’s existing contents but the QC710 SSD then unmounted itself prior to reformat completion).
Problem 2: But when I then tried to run DISM using the instructions he sent me, I kept getting the following:
Error: 87The parameter is incorrect.
In comparing notes afterwards, Rafael and I realized that since I was running a “stock” Windows 11 build on the Surface Pro 7+ versus his newer Developer build, my version of DISM was older (and apparently buggier) than his. But at this point, the only thing to do was to pack up the QC710 and ship it to him in for onsite diagnosis. He got it on a Friday afternoon and that same night initially reported back that DISM ran fine for him, and he was able to get the main partition rebuilt problem-free.
Shortly thereafter, however, he sent me another reply, noting that the system still wasn’t booting. He ended up spending a good chunk of his weekend working on the QC710, in the process discovering that two other SSD partitions, the EFI System Partition (ESP) and the Boot Configuration Data (BCD), also required re-creation. The following commentary from him will likely be helpful to anyone else striving to following in his footsteps:
We needed to also rebuild/repair the EFI system boot partition and recovery partition using standard tools, like diskpart and bcdboot. (To mount all partitions on the storage medium, as opposed to just the Windows basic data partitions, I used UsbfnMsdApp.efi -m “eMMC User”.)
When the system was back in my hands a couple of days later, it had an un-activated Insider Dev channel build of Windows 11 on it and was in default Out of Box Experience (OOBE) mode:
And yes, the keyboard was recognized this time (and the mouse, too) 😀
After going through the usual setup steps, I had a fully functional Windows 11 system:
which to date has received a handful of big-and-small updates:
Abundant thanks to Rafael, such a trooper that he even said “thanks for the challenge” after!
As for Microsoft and Qualcomm (and other Arm licensees) …I completely understand the underlying motivation for you to be investing so long and significantly on the Windows-on-Arm effort as an end user alternative to x86 hegenomy. It’s at the root of why I’ve been following the project for as long and in-depth as I have. But I was again reminded of its relative immaturity a couple of days ago when, striving to cut myself free from my kludgy wired keyboard and mouse-plus-USB hub setup for the QC710, I picked up an on-sale Microsoft All-in-One Media Keyboard:
but then had to search for, download and install the Microsoft Mouse and Keyboard Center app in order to get the trackpad to act as anything other than a rudimentary mouse (but hey, at least an ARM64 version of the app was available!).
I’ve had the occasional peripheral not work out of box (OOB) when I did an x86-based PC build in the past, but it was usually something relatively “obscure” like an optimized graphics driver set or a Wi-Fi or Bluetooth driver stack. That said, using the standard initial Windows build I was still able to passably drive the display and otherwise get Windows to a functional initial state where I could then connect to the Internet to download and install the additional software I’d need (over wired Ethernet, for example). And for goodness’ sake, the keyboard and mouse always worked OOB, at least to an elementary degree!
Even though Windows on Arm has far fewer hardware building blocks (and combinations of them) that it currently needs to support versus the legacy x86 alternative, it still seemingly undershoots even a modest modicum of functionality. And that it’s apparently so easy to corrupt a mass storage device’s partition contents to such a degree that the system containing it is rendered braindead in the absence of expert heavy lifting is equally troubling. Try, try again!
Sound off with your thoughts in the comments, please, readers. And thanks again for everything, Rafael!
—Brian Dipert is the Editor-in-Chief of the Edge AI and Vision Alliance, and a Senior Analyst at BDTI and Editor-in-Chief of InsideDSP, the company’s online newsletter.
Related Content
Source link
