Hacker News new | past | comments | ask | show | jobs | submit login

The sorry state of open source on ARM is not due to the vendors but ARM itself and to an extent Google. The effort to open GPU drivers on ARM is over 5 years old now I think and you can see all the promises made on the ARM community forums.

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.




Can you explain further how Google is possibly at fault here? Legitimately ignorant of the situation.


Google is currently developing an alternate kernel which will be MIT licensed. They've been removing GPL from userspace as fast as they can, and now it seems they want to remove it from the whole system.

http://www.theverge.com/2016/8/15/12480566/google-fuchsia-ne...

https://github.com/fuchsia-mirror/magenta/blob/master/LICENS...


I doubt that the primary motivation for Magenta is to eliminate the GPL'd Linux kernel from Android. A much more practical way to do that would be to use one of the BSDs.


They also deprecated GCC from the NDK, going forward only clang will be supported.

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.


I don't think you can legitimately say that Google are hampering open source by releasing more open source software. You might argue that they're stepping back from the GPL, but that's different.


I bet in around 10 years time, the GPL will be surely missed, but then it will be too late.


+1 Even today Android is falsely advertised as open source while in fact you can't install the OSS version on any phone and expect it to work without proprietary blobs. Thank closed device drivers for that, and more restrictions will come in the future.

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.


Well, RISC-V is coming and some of that will be fully open source, freely licensed hardware. For example: http://www.lowrisc.org/

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.


Out of curiosity, will this end custom ROMs?


Not necessarily, but it will be harder work reverse-engineering what OEMs do without the modified kernel source releases


The entire ARM ecosystem is basically Google and ARM. Google is using open source Linux to power Android but all the hardware drivers are closed. The only reason you cannot simply install and use Linux on any Android device is the closed source drivers.

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-...


What does Google have anything to do with this? If there are companies to blame for the sorry state of open source on ARM, that would be Qualcomm, Broadcom, and other SoC makers.


That might be the entire mobile ecosystem (although that sounds too simplistic, still, you are forgetting Linaro), but the ARM ecosystem also includes M-profile (deep embedded), R-profile (RTOS) and server-class (SBSA and "almost" designs like Octeon-TX and Tegra X1). The ARM server ecosystem is most definitely a bunch of software and hardware players, and Google is not a significant presence there FWIW.


It's annoying there's no Free driver stack for the Mali GPUs, but pretty much all other ARM IP is supported just fine in mainline Linux. Calling it a 'sorry state of open source on ARM' seems disingenuous.


This is inaccurate. ARM SOCs are all different and tightly closed. Which ARM SOC can you run on Linux without support from third party open source developers?

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.


Egads... They aren't "tightly closed". Just there's no way to enumerate what devices are on what IO on the chip. - Don't get me wrong, many dealers just don't broadcast what's on a fabless-fab. Doesn't mean they're closed. Go hire someone who speaks and types Mandarin and get the info about "Gongkai".

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.


Enumeration is solved by device tree. The problem really is drivers for important parts of SOCs that make running Linux on them practical.


> Is there any ARM SOC yet that ARM has said can run Linux out of the box?

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?




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: