Pinebook ARM Linux Laptop Powered by Allwinner A64 CPU
cnx-software.com
cnx-software.com
Cortex-A53 is a low cost, energy efficient, slow, in-order implementation. I don't think it was ever used as the main core in a flagship smartphone. Something like a 2012 ODROID-X2 SBC with its Cortex-A9 cores should have no trouble outperforming it, but it doesn't support AArch64.
> Given Allwinner's history of GPL skirmishes and backdooring
On the other hand, the linux-sunxi community does a pretty good job of bringing mainline support for Allwinner SocS and they're working on the A64. That's probably the longer term plan for the creators of this laptop.
The pictures of the laptop are exactly the same device I have sitting in my lap right now. The NexDock of course has no computer inside it: it's a keyboard, touchpad, SD reader, USB hub, and display.
"How Does It Work? NexDock is a laptop that runs on your smartphone, tablet or mini PC. Use NexDock with the latest Windows 10 mobile devices (such as the Lumia 950) and take advantage of the new Continuum feature, which allows smartphones and tablets to switch between touch and desktop modes. iPhone and Android users can utilize of the mini HDMI port or wireless adapter for a substantial screen size and productivity upgrad
Still, it looks like a very cool gadget. What's the battery life like on it?
Whatever condition you buy it in now will be the condition it will be in 10 years. Expect absolutely no upgrades of the kernel subsystem.
The blame is shifted from the vendor to ARM and then back like a football and open source developers give up and look for something productive to do.
It appears Arm is not interested in open source or moving beyond the mobile market where things are tightly controlled.
http://www.theverge.com/2016/8/15/12480566/google-fuchsia-ne...
https://github.com/fuchsia-mirror/magenta/blob/master/LICENS...
GCC is still around, because just like it happened with Apple, there are a few features that clang still lacks in order to fully replace it in the context of Android.
Brillo has even less GPL components than Android.
Right now the OSS community should focus their efforts on the most important goal: having fully open source hardware CPUs and peripherals. We already have huge loads of open source software but we still lack a comparatively open iron to run them on.
Peripherals are a lot more tricky. RISC-V is concentrating on the CPU cores, cache hierarchy and interrupt controller. Peripherals will be proprietary for a while, but could be open source one day.
Yet these drivers exists and work perfectly for Android which is the Linux kernel, so why are they not being made available after all these years?
If there was any interest in open source by Arm or Google they would make some minimum intiatives to makes the drivers available but not a single initiative exists.
There have been multiple discussion on Ars and HN itself about Google's relations with Android and open source..
[1]http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-...
You need more than just CPU support for it to be usable, and most mainline support is the minimum to make the Android part of it work. Drivers for all the hardware bits are tied tightly to Android. Is there any ARM SOC yet that ARM has said can run Linux out of the box?
Only the rasberry pi works on the latest mainline and that is due to the work done by the foundation and there too the GPU driver is a blob.
We were at this place once before, with 16 bit soundcards and ISA, for those of you that remember. In those days, we had to set IRQ and I/O so the device could communicate with the computer. And those devices had to correspond with each other. It was a hot mess, but what we had. MCA tried to fix it, with proprietary crappiness, but PCI actually won out.
In reality, ARM is too open, and has too manhy ways in which hardware can be added. That causes problems, because there's no detection routines - "detection" can crash certain chips.
That is not how this works. ARM doesn't design any SoCs sold to the general public. They design some specifications, such as the ARM architecture specs, a number of implementations (i.e. the Cortex cores) and a number of other IP blocks such as cache controllers, memory controllers, SD/MMC controllers, UART controllers, interconnects, DMA engines, MMUs and, yes, GPUs. AFAIK all of these apart from GPUs are supported in mainline Linux due to drivers written by ARM, which is why I've said that all their IP except GPUs is supported properly.
Now, to actually create SoCs, other companies such as Allwinner, NVIDIA, Samsung, etc, buy a license either for the architecture and use their own implementation (e.g. NVIDIA Denver) or they buy a license for the ARM implementations (e.g. the Allwinner A64 which uses Cortex-A53). These companies can then license a subset of the other ARM IP blocks, they can create their own, or they can license them from other companies. So you end up with SoCs which are either partly or completely not ARM IP, hence not ARM's responsibility to support as a complete unit. If you're looking to blame someone, blame whoever designed the SoC.
> Drivers for all the hardware bits are tied tightly to Android.
The GPU and video accelerators have userspace bits which are typically proprietary and Android specific. This is what I was saying is indeed annoying but not that much of a problem. The GPU on ARM SoCs only provides OpenGL(ES) acceleration, while graphics output, framebuffers, and even the hardware support for XV (video scaling, colorspace conversion) is usually implemented in different IP blocks with available drivers. Software decoding for 1080p and smaller video is fast enough on most SoCs.
> ARM SOCs are all different and tightly closed.
They're all different indeed, but not necessarily tightly closed. You can get the reference manual for a whole bunch of SoCs, including NVIDIA Tegra K1 and X1, the Freescale i.MX series, the TI Sitara series and most Allwinner SoCs (ha). These normally exclude the graphics/video accelerators, but everything else needed to have a usable system is typically included.
> Which ARM SOC can you run on Linux without support from third party open source developers?
Things get really blurry between drivers officially supported by the vendor, drivers mainlined by the employees of these companies in their free time, and drivers written by the vendor but mainlined by the community. AFAIK, at least the Tegra series and the X-Gene based APM SoCs are in the first category.
> Only the rasberry pi works on the latest mainline and that is due to the work done by the foundation
Well, that's simply not true. I personally use a Cubieboard 2 (Allwinner A20), Jetson TK1 (Tegra K1), Acer Chromebook 13 (Tegra K1) and APM X-C1 (APM883208) on mainline. On TK1, even the GPU is supported via nouveau and APM883208 doesn't have one.
Wasn't the mainlining work for RPi mostly done by Eric Anholt, who (surprise!) works for Broadcom, the makers of the SoCs they use?
Are there any other machines like this, or are cheap machines like the post as far as it gets? I would have considered the ARM Samsung Chromebook, but it has pretty awful battery life.
Minor features: capacitative touchscreen, screen that folds all the way round for use in tablet mode, MicroSD card slot, nice big clicky touchpad, completely silent, and a metal case.
http://www.trustedreviews.com/asus-chromebook-c201-review
I run ChromeOS on mine, with Debian in a chroot using Crouton; but I gather you can run Debian on it natively, although with some blobs:
Given the price and performance of current generation Chromebooks, I don't see much advantage in going for ARM systems right now.
One nice thing about x86-64 is that you can also run closed-source apps like games. For example, after having installed Crouton, I was able to install Steam and play some of the Linux games in my library.
I'm waiting for the previously announced, but now delayed Samsung Chromebook Pro. It's thinner, has a higher-rez screen, and has the pen-technology of the 'note' tablets. (rumored 500$)
What I would really like to see is a Tegra X1 based laptop with a nice IPS screen, preferably something matte.
GPU I suppose is nice, but how does this Denver thing actually stack up against other ARMs?
More for people who never leave terminal or for teaching kids linux.
edit - I too once basked in the warm rays of a 320x200 CRT, it's OK at the time if that's all you've ever experienced, but it's hard to go back to that from 4k.
Or on programmable calculators (TI, HP, etc.), with just 128x64 or so screen.
Or on Amiga (704|640)x(200|256|400|512).
Or VGA PC 640x480. VGA was for the first time truly enough for an IDE. SVGA 800x600 soon followed. And 1152x864, etc.
So one should definitely be able to manage with 1280x720.
I think we can adapt to whatever is available. I guess one could even manage software development with just a single line (320x8, 40x1 characters) display. It'd certainly be far from optimal, but you could do it.
Of course now I enjoy 4K resolution and multiple monitors...
Or even a dumb terminal (TTY) that prints to physical paper.
Works fine for me. Even smaller makes me work on production stuff for weeks at a time. It's a matter of taste.
It is perfectly practical.
Hell, right now I have three terminals open. One that I'm using to make changes to a file, another that I'm using to just hit the up arrow and enter to scp the file to a remote server after every change, and another to tail the log file in case there's any errors popping up. Could I do it with one window? Sure. Can I use screen to make it seem like I have three? Of course. But why would I bother when I've got tons of real estate?
A53 is a bit on the slow side, but the worst part is that it's not a great (as in, representative of the architectural requirements on software) chip for porting software to AArch64, because of its simplistic design - you will be able to get away with forgetting a barrier, or TLB or cache maintenance instruction here or there, and your code will work (but blow up on other, more advanced uarches, like A57 or other non-ARM designs). It's basically a minor step above using Foundation Model.
I would like it even more if it were just a Raspberry Pi (possibly with a very fast ssd if it were possible) inside, simply because of the support and trust I have in them.
Current black friday sale is $178 to $185
"This processor is a Texas Instruments MSP430 microcontroller, roughly as powerful as the processor inside the original Macintosh."
"MSP430 is a 16 bit processor running at 16MHz. The Dhrystone benchmark measures 1.4 MIPS."[1]
No doom or rooting your MagSafe adapters.
[1]: http://www.righto.com/2015/11/macbook-charger-teardown-surpr...
I mean the MSP430 was great, 10 years ago, but the industry hasn't stood still.
https://www.google.com.au/search?q=doom+on+commodore+64&safe...