The problem, as always, lies in the fact this is powered by an AllWinner SoC. They are not famous for respecting the licenses of the software they use, namely the Linux kernel, and things like graphic acceleration are usually hard to get working (and I'm not talking about working without blobs, I mean they are hard to get to work at all).
IMO this is the major downside to Raspberry Pi alternatives like the Orange Pi and this. The Raspberry Pi is more expensive, but at least there's more documentation available, an effort to merge kernel stuff upstream, and there are even people working in getting proper, blob-free Mesa drivers working: https://wiki.freedesktop.org/dri/VC4/
With that said, it's nice to see cheap ARM64 development platforms becoming available, even if they aren't as open/supported as they should be.
I agree. These companies keep trying to compete on price, but thats not the #1 differentiator. Rapsberry Pi is so successful because of the community support and therefore ease of use. I would be more convinced by a new board if they supplied extensive documentation and had a bunch of project guides ready to go.
It's hard to get graphics working, but on the other hand you can actually boot upstream Linux in headless mode on the older Allwinner boards right now. Debian Jessie even officially supports the older ones whereas they're unlikely to ever add support for the Raspberry Pi because it requires a binary blob to even boot.
Unfortunately, this is using Allwinner's new A64 chip and I don't think the unofficial sunxi community that provides open source support for their hardware has even looked at supporting that chip yet. Also, whether support materializes depends heavily on how much the companies that are selling boards based on it care about open source, and well...
"With that said, it's nice to see cheap ARM64 development platforms becoming available, even if they aren't as open/supported as they should be."
^^This is the ultimate take-away, yes.
Over the past year, 64-bit ARM development platforms have dropped in price from the $2999 Opteron A1100 to the $79 Dragonboard, and now to the $15 PINE64.
Argh. Thanks for that - you've saved me quite a bit of cash. If only I'd read a post like that before backing the Almond and the UDOO.
A reasonable amount of my network at home is run by an aging and ailing Dreamplug - ARMv5 and remarkably sturdy. I'm still looking for a viable replacement. I was hoping to jump to a Pogoplug (same SoC, but USB3) but I (soft-)bricked it upgrading uBoot.
The now-worthless Australian dollar makes most of these things much more expensive, but it really looks like my choices are expensive industrial boards with nebulous support arrangements or giving up on ARM entirely.
Works fine, company doesn't care about FOSS, relationship with the ODM, Cortina Systems is unknown. It was running kernel 2.6 when I got rid of it last year.
Well, ok, but unless I'm going to do some ridiculous amount of paging, I can't really take advantage of the 64-bit much. And in the meantime my 64-bit executables will suffer from larger pointers.
The stuff that arm does well (IMO) is stuff that uses Python and other high-level languages. Those tend to port with little to no effort. Yet they use a ton of indirection so the size of those pointers really matters for memory consumption.
$15 for an ARM board still seems like decent value, though.
Does ARM Linux offer a 64 bit mode with 32 bit pointers?
On x86-64, Linux supports a 'x32' mode which gives all of the advantages of the 64 bit ISA, but with a 32 bit memory model, meaning that programs using lots of pointers will take up far less memory (but still get to use the extra registers & instructions), leading to faster code. You can run x32 binaries inside a 64 bit kernel (ubuntu offers several packages, for example)
OTOH I don't know if the ARM64 ISA offers many other improvements to make a similar 32-in-64 kind of mode worthwhile.
These 64 bit Allwinner SOCs only have a 32 bit* memory bus anyway (presumably to reduce board cost), so an x32 mode could double performance for pointer-heavy code.
Theoretically it's possible. Just keep all memory in the first 4GB. Load all pointers from 32bit locations and do 32bit arithmetic on them, they should get 0-extended for loads and stores. With the correct linker scripts this could be done in user space (modulo calling dynamically linked libraries).
There's already a $15 Allwinner-based ARM board shipping now with similar specs, the Orange Pi PC. Quad-core (but only 32-bit) processor, 1GB of RAM, pretty much identical hardware video decode and GPU, 10/100 Ethernet, 3 USB ports, various expansion ports, thermal issues if you run at the advertised clock. (Why do I suspect the Pine has thermal issues? Take a look at the Kickstarter FAQ and how they carefully dodge questions on cooling.)
The Orange Pi PC has a 2-core MALI400 GPU and hardware H264 and H265 decoding of 4K content, same as the Pine. Not sure whether it supports 4K HDMI out but I believe it does at 30Hz. The main differentiating factors seem to be that the Pine is 64-bit, has less RAM on the base $15 model, has battery support and isn't actually shipping yet. Oh, and the Pine is charging a lot more in shipping fees.
While I like affordable things and development boards in particular, hardware price isn't that much of an issue anymore. Most people, especially programmers, are going to spend more in terms of labour cost even just getting this up and running. Actually doing something exciting takes from a fair to a huge amount of time, which you most likely won't be able to recuperate. At least not directly. Until someone has a next level value proposition that enables more things, I would suggest sticking to the boards you're already not using.
Yet another product I would buy from a store in a heartbeat, but instantly dismiss because of kickstarter. Granted, this one looks professional and it appears they've already set up manufacturing, but that really doesn't sway my opinion.
It's still vaporware now, unlike alternatives. What's the fascination about 64-bit architecture anyway, apart from it being a bigger (=> better) number?
It's an easy benchmark for the common consumer to look at and feel they have selected the right product. They don't have to know about the differences between A35, A53, A57, and A72 much less why those models are better than the A7, A9, A15, A17 processors. They don't need to know that Android isn't 64-bit. They don't need to know that the 1-3GB of memory in their phone isn't going to benefit from 64 bits.
They do feel that no one is going to sell junk labeled as 64-bits, and I mean come on, why would the manufacturer display it's got 64-bits unless it was really important?
Is it actually? You loose almost all the conditional execution, lots of the interesting shifted addressing (I think Aarch64 allows shifts up to 3 only). You get more registers. Oh and no 16-bit instruction mode anymore.
Another cheap rPi alternative that doesn't solve any new problems. What I'd like to see is one of these with a few SATA ports and ECC memory. Then you'd have a viable low-cost, low-power server, in a market that is sorely lacking those things considering the closest alternative is one of the newer Intel Atom boards that costs upwards of $250.
2G of RAM and 1Gbit ethernet, decent display, reasonable CPU's. The missing piece is the lack of SATA.
I get it that most of these boards are just phone processors, but having wired ethernet and a decent storage mechanism allow them to be used as speedy little NAS's, video servers, desktop machines, whatever.
USB2 storage is pretty much stuck at ~30MB/sec, around the same max that is possible with SD. Its probably faster to run the storage over the gbit ethernet port.
IMO this is the major downside to Raspberry Pi alternatives like the Orange Pi and this. The Raspberry Pi is more expensive, but at least there's more documentation available, an effort to merge kernel stuff upstream, and there are even people working in getting proper, blob-free Mesa drivers working: https://wiki.freedesktop.org/dri/VC4/
With that said, it's nice to see cheap ARM64 development platforms becoming available, even if they aren't as open/supported as they should be.