The first “proper” Windows 10 Arm laptops were unveiled at the end of 2017 and beginning of 2018, all based on Qualcomm Snapdragon 835 processor with always-on LTE connectivity, 20+ hour battery life, a fairly expensive price tag, and somewhat underwhelming performance.
Qualcomm was not interested in supporting Linux, but there was interest from the community, and now it seems Ubuntu 18.04 images are available for Lenovo Miix 630, HP Envy x2, and ASUS Novago TP370 thanks to Aarch64-laptop project currently hosted on Github.
Now the prebuilt images are not really ready for end users since UFS storage and WiFi are not working on any laptop yet, the touchpad is not working on the ASUS laptop, and accelerated graphics needs to be implemented.
Interestingly WiFi is related to UFS on those laptops, and Marc Gonzalez is said to be being actively worked on UFS upstream support, which should enable for internal storage and WiFi. That means now you’d need to flash the image and boot from an SD card.
All laptops support the following:
- Boots into Grub Normal Mode
- Boots Linux kernel from rootfs’ /boot partition using Device Tree
- Boots to text Ubuntu login prompt/shell
- SD Card Storage
- USB
- GUI Desktop (using Framebuffer)
- Keyboard
So at this stage, If you need network access, you may have to plug a USB to Ethernet adapter until UFS/WiFi gets worked out.
You can follow the status for each laptop, and instructions to build your own image in the “build” repository.
Via Phoronix
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Nice! I’ve seen the prices on this generation of ARM windows laptops dropping sharply, possibly due to underwhelming sales, so it’d be good to pick one up on the cheap and have something beefier than the usual ARM chromebook for development work.
> and have something beefier than the usual ARM chromebook
Why not taking some random x86 laptop thingy then? If it’s about ‘trust’ and not wanting anything with Intel’s Management Engine inside I would believe situation with a Qualcomm laptop will be more or less the same (if not even worse if the cellular modem lives inside the SoC).
BTW: Some information wrt the proprietary bootloader: https://github.com/aarch64-laptops/prebuilt/issues/22#issuecomment-462653795
> “Why not taking some random x86 laptop thingy then?”
Maybe because of the good performance vs battery life characteristics ? (especially since Linux will be native code, unlike Win10 apps that have to go through the emulator)
> the good performance vs battery life characteristics ? (especially since Linux will be native code, unlike Win10 apps that have to go through the emulator)
Well, first to the ‘Win10 and emulator’ stuff (I wouldn’t call it emulation anyway but binary translation). I still think that’s a big misunderstanding mostly based on silly kitchen-sink benchmarks testing irrelevant stuff like running Photoshop filters on images as large as a football field. And while I really don’t want to use Windows what Microsoft did here is just brilliant (the way they assured that most of the performance critical code when executing x86 apps runs native instead or on GPU/VPU anyway). If I would be a Windows user and if I would love to be backdoored by design (LTE modem as part of the SoC from a company known for their funny ‘QuadRooter’ vulnerabilities) maybe I would’ve bought one of these ARM laptops already.
Wrt Linux and battery life this is nothing you get for free. You need an optimized software stack and every detail matters. Power savings happen especially when avoiding the CPU (offloading as much as possible to GPU/VPU), you need to optimize every driver to make use of power saving techniques (ASPM and so on) and often it’s needed to even tweak the userland to get sufficient results. Looking only at CPU cores, ISA and ‘MIPS per watt’ is possible but useless at the same time.
I just remembered that I received my PineBook dev sample almost two years ago. Back at that time the community already worked over a year turning Allwinner’s smelly BSP/Android kernel for the A64 platform into something usable. Still there was a lot of work needed to get both somewhat decent performance and improved battery life. And literally none of the developers likes the smelly AW kernel so the only hope was mainline. It’s 2019 now and we’re almost there.
Things can take time… and I’ve no idea how ‘open’ Qualcomm is when it comes to video engine and this stuff.
And then my main machine (I switched to laptops almost 20 years ago) simply needs to run. I’ve no time to deal with unnecessary upgrade hassles or stuff like that when an important job has to be done…
To be honest I wouldn’t worry about one specific vendor trying to backdoor you. Most machines have WiFi, Ethernet or something that takes a firmware blob for a cortex m microcontroller that’s actually doing the work, all vendors are totally useless at writing firmware and kernel drivers aren’t usually written in a way to expect that someone has hijacked the firmware.
> To be honest I wouldn’t worry about one specific vendor trying to backdoor you
Fully aware of this. I was just referencing the ‘always-connected’ concept of these Snapdragon Windows thingies.
Snowden was 6 years ago and still people (in the west) only realize that cellular networks are a weapon of mass surveillance as long as Huawei is mentioned in the same sentence. We have publicly available standards that describe that we’re the last ones owning our own mobile devices: https://eena.org/aml/ — but people don’t give a sh*t. At least I don’t want to use devices that are always connected to whoever else with an implementation having higher privileges than every open source stack I could run on ‘my’ device.
I think we’re boned and this point. Even if you built all of your hardware out of discreet transistors I’m sure Google and pals would still be able to profile and locate you.
I used to use a ‘random x86 notebook thingie’ (AMD bobcat) for about 5 yeas before I switching to ARM chromebooks. By the end of the second year the battery life of the random x86 thingie was already 3h. I was running from power outlet to power outlet if I wanted to get something done.
>By the end of the second year the battery life of the random x86 thingie was already 3h.
Is that directly related to the x86 isa? does it cause lithium cells to degrade faster than if they are discharged via an ARM isa?
Erm, no, that has to do mainly with the market realities of the x86 — $300-$400 got you only this much battery back then. The ISA is just a hindrance when downscaling the tech. And it’s easier to upscle something, than to downsale it, as has been demonstrated by arm and apple on the upscale side, and by intel on the downscale side.
> By the end of the second year the battery life of the random x86 thingie was already 3h
And this is due to x86 or an inexpensive laptop featuring a ‘you get what you pay for’ battery?
My current i7 laptop I got last year had a really underwhelming battery life of just 6 hours. Turned out one little part of a so called MDM (mobile device management ‘solution’) was crap. Disabled it, another hour, tweaked a single Firefox setting another 1.5 hours more. Details matter (both with software and hardware — I always need to laugh when people call me stupid for using MacBooks 🙂 )
I’m typing this on ‘an inexpensive’ notebook that lasts 8h+ of proper work. It costs $280. The secret? It’s an ARM ; )
>have something beefier than the usual ARM chromebook for development work.
If you’re doing development work why cheap out? Every extension to the change/build/test cycle is making you less productive. I’ve given up trying to do anything on my core i3 laptop for this reason. I can imagine using anything but the latest greatest ARM64 machine would drive you insane.
Maybe he is employing a remote build machine?
If you can do everything via ssh or something sure. But in that case you wouldn’t need a *beefy* laptop at all.
Why not some random x86 laptop? you can also carry a backpack full of batteries with you to make-up for the poor battery life and also get some nice workout from carrying it.
x86 is bad because it doesn’t have ARM-magic(tm). ARM magic is a combination of RISC and “but it’s more power efficient” that makes everything you do with ARM instantly at least 20 times betterer.
And then you’ll complain people downvote you. Instead of stupidly trolling, explain why x86 is better.
not sure if @dgp or @me. Anyway what I meant is, x86 is not better if you want battery life.
That was for dgp, I got the irony of your message 🙂
And the best part — the achilles heel of ARM notebooks — the GPU drivers, will be addressed by Rob Clark’s excellent freedreno. One of the reasons I’ve been sticking to dev-mode chromebooks is their rather predictable GLES 3.2, with small exceptions (e.g. RK3399 DRM stack hard-rebooting the machine after an out-of-browser app terminates the wayland connection).
>And then you’ll complain people downvote you.
>Instead of stupidly trolling, explain why x86 is better.
Why are x86 machines better? Because I can install a prebuilt mainline kernel on them and have them actually boot first time 99.9999% of the time instead of getting stuck somewhere between the decompressor and kernel entry. If I’m really unlucky maybe I’ll need to install a firmware package to have the majority or all of my hardware working.
When that x86 machine dies I can rip the drive out and stuff it in almost any other x86 machine and it’ll boot.
Oh and I can get GPU drivers for GPUs that aren’t hilariously out of date and I’m not stuck on some year or more out of date kernel that has multiple CVEs against it.
These are perfectly valid arguments, though they have nothing to do with your previous rant 😉
That’s not a rant. That’s poking at the people that seem to think that something being ARM instantly excuses it for the many issues that ARM (or any *alternative* platform) has.
While apparently something being x86 instantly puts it in the ‘sw writes and debugs itself’ category.. It’s really funny when dgp makes blanket statements.
Yes, x86 has the overall sw superiority side of things, and yet, on my $280 arm chromebook I have the latest and greatest gcc and clang toolchains, and a state-of-the art browser and media stacks. That sw experience beats the hell out my late AMD bobcat with debian/ubuntu, taking me a weekend of ‘fixing things’ after every catalyst update, while not being able to do elementary vsync. Of, the joys of x86..
>While apparently something being x86 instantly puts it in the
>‘sw writes and debugs itself’ category..
It doesn’t but x86 is a good 10 or 15 years ahead of any ARM machine on generic linux desktop use. The ARM SoC landscape was incredibly fragmented before Cortex-A.
And even after Cortex-A you still cannot just build a kernel and boot it on any Cortex-A machine in a lot of cases. Device tree that fixes a lot of the issues only really happened a few years ago.
>It’s really funny when dgp makes blanket statements.
I’m glad you’re getting some chuckles. It’s probably good for you.
>Yes, x86 has the overall sw superiority side of things,
>and yet, on my $280 arm chromebook I have the latest and greatest gcc and clang >toolchains, and a state-of-the art browser and media stacks.
And I can almost have that on SH4 too (native GDB is still missing AFAIK). Linux, GCC etc are have levelled the playing field and made what the underlying machine actually is a non-issue in a lot of cases. AFAIK the latest binutils still generates broken thumb kernels because of some advice from ARM ltd that broke it. :/
There’s nothing magical about X86 either except that IBM making a class of X86 machine and everyone cloning it means that we don’t have the complete shit show that almost everyone else has with closed source primary bootloader, broken out of date secondary u-boot or some proprietary bootloader that half works and then hardware that is connected to the processor like someone thought ISA was a really great idea that should live on forever. Even the Amiga had discoverable buses.
>taking me a weekend of ‘fixing things’ after every catalyst update,
>while not being able to do elementary vsync. Of, the joys of x86..
Surely that’s the joys of AMD drivers? I know you really hate then and it gives you hives just thinking about using their stuff but Intel is pretty good about getting their stuff mainlined. Either way fiddling with stuff to get it working on Linux is unlucky on X86. On ARM rebuilding the kernel with random patches from someones private tree to get something working right is the norm. I’m not sure why you can’t understand that that’s massive negative.
I don’t see a point in perpetuatuing the rest of the discussion as we mostly agree there, but that part I will address:
>Surely that’s the joys of AMD drivers? I know you really hate then and it gives you hives just thinking about using their stuff but Intel is pretty good about getting their stuff mainlined. Either way fiddling with stuff to get it working on Linux is unlucky on X86. On ARM rebuilding the kernel with random patches from someones private tree to get something working right is the norm. I’m not sure why you can’t understand that that’s massive negative.
Erm, AMD being one of the *two* available vendors of x86 notebook parts, and trouncing intel’s offerings at the time in anything but GPU driver conformance — we’re talking of that AMD. I went with an AMD APU part in 2011 as the competition’s Bay Trail was worse or on-par at best in every possible way but GPU drivers (no, their vsync did not work either). Speaking of GPUs, I had the misfortune of dealing with the infamous intel Poulsbo chipset — now *that* was a horror story of GPU driver development.. But as you say, that, along with pre-armhf/arm64, was years ago. The current situation, from my POV:
ChromeOS has been a really enjoyable dev environment for my non-professional projects. I enjoy the fact google keeps the *numerous* vendors in check — zero kernel builds given by me there. In order to get a comparable x86 chromebook to any of $280-$300 arm units I use daily, I’d have to pony up $100 more at the very least — we’re talking similar battery life at best (an extremely important factor for me), similar or a tad better CPU peformance (an important factor for me), similar GPU performance (yet another important factor for me). Why would I do that? So that crouton recognizes my 3D GPU? But I can already access that in CrOS dev-mode. And If I really wanted something from the GPU CrOS does not provide (like OCL), I can dual-boot to archlinux with a full set of GLES, OCL and vulkan drivers on one of my chromebooks, but I seldom do that these days.
>ChromeOS has been a really enjoyable dev environment
I wouldn’t trust google as far as I could throw them. Most ChromeOS devices will be stuck on Linux 4.4 + blobs until the end of time. Which is great if the vendor keeps updating the images but they manage that for a few years after release at most.
>I enjoy the fact google keeps the *numerous* vendors in check
Google has only recently really bothered to do anything to make sure vendors aren’t shipping kernels with known exploits. Good for them for doing that but it’s too late. If vendors weren’t shipping hackjob GPL infringing kernels in the first place it wouldn’t be an issue because you would be able to pull their repo and rebase it on a stable release yourself instead of hoping/praying that whatever vendor made your machine cares enough to put out an update.
>In order to get a comparable x86 chromebook to any of $280-$300 arm units I use daily,
>I’d have to pony up $100 more at the very least
$100 is like one or two hours at the office right? I think’d rather put in a few hours overtime than have to mess around with custom images etc when it turns out there is a bug in the kernel, horrible qualcomm wifi driver, horrible qualcomm wifi firmware, closed source GPU driver or something more trivial like OpenSSL.