I did a long weekend project a few months ago bringing up GNU/Linux on a low cost tablet. Here's a picture of it running XFCE: http://i.imgur.com/jmh8N0W.jpeg
If you at least have a kernel source for the SoC, it's doable. However, especially if you don't have the source for your specific device (because manufacturers play fast and loose with the GPL), you'll probably spend the first few days getting it working and then many, many weekends getting it to be usable. I did stop before I got to that point.
Here's some of the issues I ran into:
* The parallel RGB to MIPI bridge doesn't have complete publicly available documentation and it requires LCD-specific configuration. I've sniffed it from the Android kernel with a logic analyzer.
* The touchscreen controller doesn't have complete publicly available documentation and it requires device-specific configuration.
* The BMS doesn't have complete publicly available documentation and it requires device-specific configuration
I guess you can see a trend. :) If you have the time, you can RE this stuff with some basic soldering skills and a logic analyzer or scope.
But actually the issues which made me lose enthusiasm were the following:
* Rotating the framebuffer to landscape orientation in software is freaking slow. Android seems to be doing it using OpenGL ES, but I'm not aware of any GNU/Linux window manager capable of this. The display controller didn't support rotation and the only remaining alternative would have been too hacky for my taste, to use the image processing engine to maintain a rotated shadow copy.
* Limited capabilities: processing speed is mostly OK, but only 2 GB of RAM and the slow framebuffer are not great. There's almost no I/O, essentially you only have a USB OTG port. Tablets are not thermally designed to sustain high loads. Battery life will probably not be that great and it seems difficult to upgrade the battery.
Now, some of this stuff doesn't fully apply to Nexus 9. I expect Google to be better at providing a kernel source closer to that's running on the device and the hardware itself it much more capable, it even has OpenGL (non-ES) support. This still leaves quite a few issues. Chromebooks (used for running GNU/Linux, of course) might be worth looking into.
Did you use libhybris for this?
What bootloader did your device have?
How did you do the initial bringup without being able to see the console? (or did you have UART?)
Basically, do you feel like doing a longer writeup?
I'm sick to death of "Linux on XYZ Android device" meaning a chroot - I would have hoped there'd be more interest in running Debian or whatever everywhere.
No, I did not use libhybris. It boots the kernel I've patched and it uses a full Linaro filesystem on a micro SD. The Android FS is not even mounted when running GNU/Linux.
The SoC is RK3188 and it uses a proprietary bootloader to do some hardware initialization IIRC.
The device does have an UART port, which I've used.
Honestly, not really. It's cumbersome, slow and really takes too much effort. There are Atom transformer tablets that come with Win 8 and have Linux installable that are way better for that job.
Using linux on the asus TF101, the battery life is A-OK, I could get ~12h with the secondary battery, my main issues has been RAM (1G is barely enough).
Without resorting to install linux I would recommend KBOX2 [http://kevinboone.net/kbox2.html] which offer a lot of useful tools for a developper (vim, gcc, shh ...), and rely on the excellent Android Terminal Emulator.
Of course linux provide a more complete ecosystem for developers, but even without replacing android there is still enough to be useful.
Similar to "bergie", I have used Terminal IDE on my 2nd gen Nexus 7 to do some exploratory work programming Android.
It's doable, and battery life is quite good, but having an IDE on a PC to work on the screen layout XML file helps. Also, the Android API documentation layout sucks, which makes it harder to look things up. Auto-complete in a real IDE also helps compensate for how bad the online documentation for the API is.
If it was up to me, the Android documentation would be better, and an API to programmatically set up the screen layout would be readily accessible.
For all of Java's faults, I like how compact the online javadoc is for the runtime library, compared to the crap layout with mandatory frames that Android API uses (or MS .NET, for that matter).
Is battery life worth it?