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?