Hacker News new | comments | show | ask | jobs | submit login
It's Now Possible to Boot Android on I.MX6 Platforms Without Proprietary Blobs (softpedia.com)
126 points by mmastrac on June 11, 2017 | hide | past | web | favorite | 40 comments



What are the other of the "very few" embedded SOCs that need no proprietary blobs to run? Mediatek?

Also, how great a name is Robert Foss for someone who writes open source code for a living...


Many SOCs are able to run with no blobs, but very few require no blobs while still offering graphics support. Some SOCs with Adreno or Vivante GPUs do however offer open source GPU support.

Re being named Foss while working in Foss: It's a pure coincidence, but has a medieval feel to it. Like Baker, Coppersmith or Eisenhower.


Let's not forget the theory of nominative determinism[0]

[0] https://en.wikipedia.org/wiki/Nominative_determinism


Eisenhower?



Allwinner A10 and A20 pretty much just work, save for MALI.

http://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix


The old TI OMAP chips were good for this too.


Author here, feel free to ask me things.


Hey Robert - this is awesome!

In a previous life, I spent a bunch of time within a large semiconductor company pushing for full source releases in the same spirit - it was successful in a single instance, but an uphill battle in most. Cyanogen was an original inspiration.

During the time I looked after Android porting (started in 2008!) one huge issue purveyed - stability of an Android port was incredibly hard to achieve and was hyper focused around a specific release. It wasn't anything in particular - its just that Android was developed by a incredible team of people on one device and that porting to other platforms tended not to behave like the original.

A few colleagues are now working on the VTS at Android as an effort to solve this exact problem. I'm looking forward to seeing big steps to improve this with all the larger vendors very soon.

The fallout from all this however is that a ported platform will still have a ton of bugs and a long tail of issues that impact app behaviour. Sure - Angry Birds will work (I know... flash back to 2013) but the latest VR app that happens to use an obscure EGL extension to get camera data into the GL context might be either super slow or worse, not working.

Its the development of these new APIs in new Android versions that really causes long term issues, as well as ensuring all APIs work correctly over all versions of Android (and Linux kernels). Many to Many is a tough test case when the majority of the testing is manual.


Do you believe in nominative determinism?


No.

Good question though.


To paraphrase Trotsky, you may not believe in nominative determinism, but nominative determinism believes in you.


There is a fairly well known Dutch pilot whose last name literally translates to "brick".

I'll leave it as an exercise to the reader to decide whether that is an example of nominative determinism or not.


I do some OSS development for UDOO, which sells iMX6 SBC (6Q, 6D, 6SX). We currently offer Android 6, I started to build 7.1 a few days ago. Intro end, question is, did you compare the performance between Vivante and OSS stuff?


I haven't done any comparisons, but the performance of the OSS graphics stack is currently an area of focus.

Work remains to be done with respect to Android. For other applications the OSS driver has been found competitive and even faster for some applications.

Unfortunately I have no numbers to back any of the above statements up.


What things remain to be done for an OSS driver of Vivante GPUs (the fact that the support suffices to run Android proably does not mean that it is feature-complete).


Overall the etnaviv driver is young, both in mesa and in the linux kernel, so there are lots of nice-to-have features missing and fine-tuning.

Christian Gmeiner, Lucas Stach and Wladimir Van Der Laan would all be able to provide you with a more detailed answer.


This is super-basic, but given pretty much the only words I recognize on that page are "android" and "mesa", what does this /mean/?


The original article is better at explaining things:

https://www.collabora.com/news-and-blog/blog/2017/06/05/andr...


Thanks ;)


It means that the iMX6 platform now can run Android using an entirely open source software stack.

It also paves the way for other platforms, and in general is another win for open source.


What do you think is the best hand-solderable application processor these days? I don't see any non-BGA I.MX6 chips, but I didn't look very hard. Is the hobbyist stuck with an ARM926?

Also, in that vein, is there a similar solution for I.MX23's?


You can get a i.MX6 SoM (system-on-module) to take care of nasty things like external memory.

https://www.solid-run.com/freescale-imx6-family/imx6-som/


I was about to suggest SoMs as well.

The biggest challenge with BGAs from a hobbyist perspective isn't the soldering. There are lots of hobbyists successfully reflowing BGAs with toaster ovens. The bigger problem is manufacturing the PCBs to break out the BGA balls. TI has some BGAs with a proprietary ball pattern that are designed to be broken out with just 4 layers, but that's the exception, and you generally need very narrow traces and trace clearance to route between balls and vias. I just looked at OSH Park's current capabilities and they only do up to 4 layers and their DRC specifies 6 mm minimum trace width and 6 mm minimum spacing. I've heard of people using OSH Park and similar lower-end prototyping services to manufacture one-off PCBs for fine-pitch BGAs, but you'll be failing DRC by a massive margin, so expect terrible yield on the PCBs, assuming any of them work at all.

Unfortunately I think DRC will be similarly challenging for most SoM connectors since their pin spacing has a similar pitch to BGAs, so you'll probably need an off-the-shelf break-out board to work around that. Honestly, at some point you should consider whether a vanilla dev board with low-speed GPIO headers could meet your requirements.


Those OSHPark rules are 6mil, not mm - that's a little over 0.15mm. But it's still not really suitable for BGP modules. You can probably do 60-ball RAM modules, but a medium-sized processor seems like it would be off the table.

I think that dirtyPCBs does 6-layer boards, but they're comparatively pricey for small runs or prototypes.


Thanks for the correction; I thought 6 mm sounded way too high. Gotta love American measurement units!

There are Internet accessible Chinese PCB manufacturers that will do short runs for designs of almost any complexity, but they aren't really targeting hobbyists, though that seems to be changing.


Yeah, mils are a really strange measurement unit. I'm not sure who thought that 1/1000" would be a good standard.


I think it harks back to older manufacturing processes, via plastics (where mils are used) back to metalworking. Machinists will usually talk about small distances in "thou", as in thousandths of an inch.

Always cracks me up when AvE mentally converts 2.5/64" or some crazy shit into thou while thinking out loud, and then goes "metric fanboys be like whaaat?"


Huh, I hadn't heard of that sort of thing, besides the various dev boards offered by the microprocessor developers. Thanks!


The AllWinner A13 (Cortex A8) is available in a LQFP176 package. That includes a MALI400 GPU. That is still fairly old, but more up to date than ARM926.


I'm hardly an electronics designer (although I do it for fun), so I don't have much of an opinion.

However, I don't think there are any SOCs with Adreno or Vivante GPUs that are also hand solderable. A quick Octopart search[1] turned up nothing.

About iMX23, a quick look seems to suggest that it has no 2D/3D capable IP on the SOC. So it likely just has a display controller of some sort. Unfortunately I don't know what that display controller is. It may be encompassed by the imx driver depending on that the hardware actually is.

[1] https://octopart.com/search?q=&start=0&category_ids=4267&spe...


In Android O Google plans to separate HAL, OS and customizations.

This is a move from the "move fast and break things", which has allowed Google to make huge changes to Android but at the same time caused all kinds of problems for vendors, to a more "have a stable base" mentality.

Do you think we will see more fully open platforms due to this change?


Do you think google failing to provide a single nexus phone that doesn't require binary blobs is Incompetence or Malice?


What about indifference?


How big a job is customizing all this to work on a different board? At work we use iMX6-based SoM's on custom baseboards, and so far have stuck to Linux. But we'd like to experiment with Android, just to see if that is a viable/interesting option for embedded systems.


Is there official documentation available that you used for writing the Vivante driver or did you do it by reverse engineering? Or was it some of both?


care to point to the moneyshot diff?

i trusted commit message and got here https://customer-git.collabora.com/cgit/android-etnaviv/gbm_...


I'd love to see Ubuntu or Yocto support for this, with accelerated Wayland. Is that a possibility?


The same work that goes into this Android support also paves the way for Wayland on this hardware platform.

But, I haven't run it myself yet.


An interesting target for postmarketOS: https://ollieparanoid.github.io/post/postmarketOS/




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

Search: