2017 may be the year of the (ARM based) Linux desktop, sort of. We’ve already seen GIGABYTE ARM development PC powered by a Socionext SC2A11 Synquacer 24-core ARM Cortex A53 processor that will be available in December, and apparently working fairly well already.
But there are even more options, as Bernhard Rosenkränzer (Bero) from the Linaro Mobile Group, and unofficial Linaro superstar, has decided to create his own ARM based desktop and laptop, based on respectively MACCHIATOBin board with a Marvell ARMADA 8040 quad core Cortex A72 processor, and DragonBoard 820c board with a Qualcomm Snapdragon 820 quad core Krait processor.
Since MACCHIATOBin board complies with mini-ITX form factor, he could simply use off the shelf parts with a standard desktop case with power supply, NVIDIA or AMD Radeon graphics card, 16GB memory modules, and a 2 TB SSD drive. The AMD Radeon card fried due to overheating, so the demo was made with an NVIDIA card driven by Nouveau open source driver. The complete system was actually run on fully open source drivers and firmware, and Linux 4.14 mainline with 2 extra patches.
The laptop leverages Pi-Top modular laptop, but replaced Raspberry Pi 3 board with a much faster DragonBoard 820c board that also includes 3GB RAM, and had an SSD connected over PCIe. I ran OpenMandriva with KDE + Linux 4.11 using fully open source drivers.
Bero mentioned that while it’s quite easy to make an ARM desktop as described above, a way would have to be figured to make it more easily reproducible. I got all the information above from Charbax’s video below.
The first 8 minutes are about the DIY ARM desktop and laptop, and after they talk about his work with Android (Project Treble and others), the importance of open source drivers, and his political (non-) future 🙂
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.
22 Replies to “MACCHIATOBin based DIY ARM Desktop, DragonBoard 820c based DIY ARM Laptop (Video)”
Nice! I should give this a try. I have a pcie x4-x16 riser ready.
Are there any written directions by Bero?
um, “NVIDIA or AMD Radeon graphics card,”, so, what is the point of putting high wattage gpu there?
It doesn’t need to be high wattage – passively-cooled pcie gpus are fine.
People prefering reading over watching videos might be interested in: https://lwn.net/Articles/733837/ (especially the comments section as usual)
For <15W max, you can get a nvidia jetson tx2, 8gb ram, pascal gpu, sata, pcie x4 etc.
If price is an issue, you can get tx1, similar specs (just 4gb ram, maxwell GPU) for $200.
And you can choose binary blobs or open source drivers.
@tkaiser: thanks for the link.
anyway, my 15 years old thinkpad x40 (12″ screen, ssd, 1.5gb of ram, single core pentium-m) can go as low as ~6-7W, and usual wattage is 10-15W, which results in 6-10hours of sustained usage. 15 years old! it’s a pity modern software (web mostly) is so bloated one cant easily use it all anymore. but i still use it for a console/burner/web browser/video player/dev machine.
That article mentions the lack of vendor initiative for ARM64 notebooks. I think more Linaro effort could be directed to some of the really good chromebooks out there. But that’s just me.
BTW, it’s curious to see how Bero solved the PCI aperture issue on the macchiato.
So I’m not the only one who uses +10 year old hardware on daily basis. It’s almost unbelievable how a ssd turns this old hardware back to something usable. I’m running mate desktop on it without complaints. I will not talk about power cosumption though…
Why not approach Nvidia about doing a custom Nvidia shield TV, with the need features added?
shield TV actually uses jetson, which is a SOM.
so you really just need a custom baseboard or use one of the smaller ones available.
Well, the obvious reason is ‘no market’, isn’t it? Will change next year when Windows on Snapdragon notebooks will spread… with a similar concept like Chromebooks now of course (‘Let’s collect all data about and from the moron sitting in front of the machine and store it in our datacenters forever’)
The most surprising bits for me when reading through the article were the focus on legacy technologies like SATA for example (who wants SATA or even PCIe/AHCI in a mobile device, technologies originating from scratching bit after bit from spinning rust a few decades ago) and the focus on ‘libre’ only of it’s about GPU drivers (or how could one justify using Snapdragon SoCs or Qualcomm products in general?)
There is a market – it’s just smaller than what the big companies want. They rarely if ever build a device that will be primarily for developers or some other niche group.
Obviously the market is much bigger if the device doesn’t collect all data — which is precisely why those “legacy technologies” are needed.
Where do you store all your data, if not on something connected to SATA/PCIe/AHCI/USB (Don’t say eMMC or UFS — those things don’t even get close to the TB range yet, and the speed doesn’t match a decent SSD either), or on the net (where it will be widely open to those who potentially shouldn’t read it, and inaccessible as soon as you board a plane and aren’t a gazillionaire)?
The only problem with the Snapdragon SoC is the bootloader (which should be replaceable by an open UEFI implementation soon-ish). Everything else can be supported with purely open code already.
GPU drivers are a bigger issue than the bootloader during development because the GPU drivers can prevent you from getting the system up and running (GPU driver provided only for a prehistoric Xorg version while you want to use something much newer, etc.), while the binary bootloader (while bad) will at least work and not mess with OS development efforts.
Getting rid of that is important, but a lower priority than actual OS components.
That was “solved” by using a newer revision of the board that solved the hardware problem, as well as a few patches in the bootloader and kernel.
Bootloader patches have been upstreamed as part of the 17.10 release (you’ll still need a patch to get the USB2 port working though).
Kernel patch is here.
Reproducing the desktop is fairly easy:
– Get the current revision of the MACCHIATObin board (this may take some time…)
– I used this case, but any other MicroATX case should do
– x4 to x16 riser to attach a graphics card (e.g. this) and pretty much any graphics card (try a cheap Radeon — usually best with drivers), or alternatively a graphics card with an x1, x2 or x4 connector (such as this)
– Fan from the case relocated to the top of the CPU heatsink (shouldn’t be necessary with the final revision of the board – this was a nasty workaround for heat issues)
– A 2 TB SATA SSHD
Software-wise, I used OpenMandriva (http://openmandriva.org/ — my favorite Linux distribution primarily because it’s complete but the team is small enough to be really flexible when anything needs changing, and ready to try new things like making clang the default compiler etc.)
For the kernel, I used a post-4.14-rc2 snapshot of Linus’ master tree with a few extra fixes for the board. The kernel lives here
This is the script I used to build the entire OS image (+current u-boot — that too needed a few extra patches):
(It’s not very portable though — uses some OpenMandriva specific tools to set up the target copy).
The laptop is more complicated as it does require some custom wiring. There’s no instructions on that yet.
Nvidia is a horrible company that is openly hostile towards anything even slightly open. They would be my least favorite company to talk to. But even if they weren’t that awful (or there were no other choices available, or you replaced nvidia with any other company making something similar), those companies won’t even talk to you unless you’re prepared to order a large number (typically 10000+) and pre-pay the entire batch.
While I don’t exactly live on food stamps, that is way out of what I can afford (and I’m definitely not starting a crowdfunding or something unless and until I’m 100% sure I can deliver what was promised – that would be dishonest in extreme).
Also note that the SOC that’s inside the Shield is actually far more expensive if you buy it outside of the Shield. A Jetson TX2 goes for $599. They certainly wouldn’t give you the SOC or even a custom version of it at a lower price.
Essentially, it’s what’s available and has open drivers (and not all of them are that high-wattage, go for the lower end ones).
Unfortunately you can’t get a PCIE version of an Intel or Adreno IGP…
And we’re not talking building a custom SOC for cost reasons.
Thanks for the directions. Do you know which version of the board/SoC is targeted by the aperture patch? I’m afraid my macchiato is from the very first run, so chances are that revision they did to the SoC came later : /
Meanwhile, re the laptop: have you tried approaching some of the chromebook SoC vendors? E.g. Rockchip seem to be rather up-front about their 3399, and that powers some of the better chromebooks currently on the market. The GPU userland stack for the 3399 remains the only problem (as it’s entirely up to Arm holdings) but I think that if everything else was addressed the GPU could remain for last (Midgard being an extremely popular arch, will sooner or later get reverse engineered, me thinks).
On my main device on a NMVe SSD (that’s why I called SATA/AHCI ‘legacy’ since especially on a mobile device I want to have efficient SSD access to help with battery life), everywhere around (cold data) on SATA connected storage. I’m used to do all my work stuff on my laptop which involves connecting 1 or 2 large displays on my desktop, virtualizing a couple of hosts at the same time (and also all the time) and testing/using network and storage equipment with at least 10Gbps bandwidth… so even almost all x64 laptops are of no use for me since lacking Thunderbolt.
Thanks for sharing your insights though and I think I’m going to test OpenMandriva soon…
The PCIE fix appears to be only in a yet unreleased version of the board – the working one we had was labeled “rev. 1.2”, but so is the non-working one I have at home. So probably worth a try…
Rockchip 3399 is a rather nice SOC if it wasn’t for Mali — should be possible to build something with the Firefly board if nothing else. But for the time being Mali is pretty much a showstopper – not only is it binary-only, it’s also badly supported (not even a wrapper that would get it to work with any Xorg version other than the one they want to support, much less any way to build for other display systems or so).
Unfortunately there’s no fix in sight, even https://github.com/limadriver-ng/lima/commits/master seems to have stalled again (and never had any support for anything other than 200 and 400).
There is always this for newer Mali’s: https://notabug.org/cafe/chai
some mali 400 drivers development
Anybody did try this?
Pixelbook + Coreboot = Linux developer’s new laptop?