Yet another Android build.

It looks like I’m changing up direction, just a bit.  It seems that the documentation that came along with this cheap/no-name Chinese outfit’s board is no good.  Plus, the board is pretty much under lock and key.  My experience has been that any board lacking wide community support and/or access to all the tools used to create the original software images is just not worth the bother.  I do know a well-supported board when I see one.  I’d like to hack the board/software, but I have a lot further plans than simply saying I figured out a closed up board….  

So, what I’ve decided to do is to prepare Android for a couple of other boards.  One of those boards is the Pandaboard (open source) which I had purchased several months back.  The problem with this board is that there is not inherent support for a touchscreen.  I figure that I can (maybe) tackle this as an academic project on the side.  What I’m really after, though, is the Beagleboard Black…….and rumors are stirring that I could receive this for Christmas.  Cool with me.  I’ll be preparing Android and Debian for it in the meantime!

Linux

 

Effortless and Beagleboard Black?

I stumbled upon a cool, very cool development board today at lunch.  I had known about the Beagleboard and BeagleBone boards for quite some time.  They have always been the go-to low cost development kits for TI ARM Cortex processors.  Apparently, Circuit Co, who makes the Beagleboard products has decided to beat the Raspberry Pi makers at their own, low-cost game.  

At $45 now, you can own an ARM Cortex development kit, complete with ethernet, 512MB, 2GB onboard storage, SD card slot, serial, USB, and USB OTG connections.  For another $50-$90, you can add a resistive touch LCD screen.

On top of all of this, the kit is well-documented.  To be quite honest, while I will certainly tinker with the board I already own, I will have look at getting one of these kits!  It’s a great thing.  

Check it out:

http://beagleboard.org/Products/BeagleBone%20Black

First images built

After dealing with some virtual machine issues, and some incompatibility between Ubuntu versions and the Android 4 source tree, I have successfully built u-boot, kernel, and Android images.

The virtual machine issue revolved around having configured the hard drive image in such a way that there was a limitation on the file size.  The file size limit was 2GB, which posed a problem when copying the 2.1GB Android source tar.gz archive into Ubuntu.  The other issue with the virtual machine and Ubuntu revolved around changes made in the gcc versions used in Ubuntu 10.04 and Ubuntu 12.04, versus the Makefiles provided in the Android 4.0 source tree.  The hardware vendor had modified their particular (ie. modified) source tree to work with Ubuntu 10.04 but not Ubuntu 12.04.  Specifically, there is a FORTIFY compiler switch that was added back by the vendor that is not required with Ubuntu 12.04’s default environment.  Instead of downgrading a number of individual packages, including gcc and related, I simply started over with Ubuntu 10.04.  Not a big deal.  I did not snip the errors I encountered here; but, in general, it is well-documented on Google’s Android build environment website that current Android trees,  and going back to Android 3.0, are designed to be built with Ubuntu 12.04 and newer.  If I wanted to, i could patch up this source tree to get it back on par with Ubuntu 12.04’s requirements, but I will leave it alone, for now.  Once I get into downloading a pure Jellybean or KitKat source tree, I will follow Google’s model.

Anyhow, here’s a desktop screenshot of the output image files:

What’s shown are the basic images that comprise  any Android system.  u-boot provides a boot loading sequence while providing the initial interfaces into the system and setting the boot medium.  In the case of this u-boot image, it will enable booting into the Linux kernel as well as providing certain tftp or serial interfaces to use for flashing images directly to flash memory.  As of right now, I have yet to study the u-boot sequence and debug output, but this will come shortly.

Then there’s the kernel image and we have an ARM-targeted Linux kernel.  The kernel presents boot-up scripts, device drivers, and medium location for booting into the Android system.  The zImage is highly configurable, and for my part, I have integrated busy box before and have provided startup scripts to enable audio, starting screen brightness, starting video, etc.  A lot of kernel customization is done with a built-in configuration tool, which we’ll touch on once we get into video configuration and similar.

Finally, we have the android210.tgz file.  This image is comprised of user, system, and storage partitions that make up the Android system.  There are apps, frameworks, codecs, kernel-level references, etc. as well as the Dalvik VM used to run much of the Android system.  Much of this I will be re-learning as I re-trace these first steps, so stay tuned.  I think we’ll get into the thick of things once we try to develop the audio driver and APIs, and solve a problem I have already noticed with the video output.  Basically, this board cannot be connected to a standard DVI setup via the HDMI / DVI cable I have at my disposable.  The HDMI output timing is not correct for DVI inputs found on many VGA monitors.  We’ll play with these settings as a start at looking into the kernel.

Time to rock some Android and embedded Linux again!

If I had to be honest, I really loved my last job for the challenge, if that’s all I had to judge it by.  If you add in the people, creativity, and market factors, well, this becomes another story.  Maybe if I hadn’t preached the strengths of iOS versus Android……hmmm…….

What I loved about the work, itself, was simply having something so vast like an operating system to work with and to make it work.  I was successful at building a Debian image for an ARM from scratch, porting Android 2.3 to a platform not fully supported by the providers of the the board support package (BSP), creating Android libraries and apps, and building and customizing pieces of Android 4.0 on a Freescale ARM system.  Before this job, I had built Android and Linux for ARM, but had not worked through a lot of troubleshooting or app development.

So, forward-wind a bit and through some discussions with a friend of mine, I decided to delve back into the area of embedded Linux and Android.

What I am doing is creating a platform to use for general purpose audio and wireless applications, which is all accessible and controlled through a touch screen or remote services.  The starting point is actually a single board computer I picked up last year, made by a no-name company in southeastern Asia.  The board is both proprietary and open, with the CPU reference design closed tight, while the peripheral connections are schematically well documented.  This stating point, then, will be only used as a proof of concept.  I will not have the ability, nor the desire, to take this very board and use it as the basis for an actual product.  I can, however, use the board to develop and test lower level general software, as well as application software, to prove out a few concepts.  We’ll then head over to either a Pandaboard, which I also own, or a new board from a company called Olimex to fine-tune the total system, lower cost, and customize further.  We’ll do a good number of tricks with this starting board, though!

The board is a proprietary/closed hardware board from a company in China.  I would provide links to it and all, but you need a legal team to even order it directly,  My platform was purchased off of eBay…. : p

This platform shipped with Android, uBoot, and kernel images already built and ready to go.  (More on building those images, later).  The result is that everything was ready to go out of the box and has been left alone ever since!  The third picture shows the system booted up to the Android 4.0 desktop!

Here we already have an Android desktop, but what about making it all do some useful things?  Well, that’s what’s being documented here.

Over the last two days, I have created a development environment which will be used to recreate the Android, uBoot, and kernel images.  The company shipping this platform provided what amounts to instructions to do all of this, though they did not go so far as to hold your hand!  The manufacturer had compiled Android using rather old Java and gcc compilers, so I had to revisit exactly what versions were appropriate for this build environment.  What it came down to is that you cannot simply download the latest version of Ubuntu, Google “Android build environment setup”, and then be in “off you go mode”.  At this very moment, in the early 1st hour of Monday, the Android system is building on Ubuntu 10.04.   (I am keeping my fingers crossed!)

So, here’s a rundown of what I did to get Android up and building:

1.   I unpacked the reference CD’s software contents (android210-androidfs.tar.gz, android210-kernel.tar.gz, and android210-uboot.tar.gx) into the desktop in Ubuntu 10.04.

2.  The kernel and boot contents were copied into the android210-androidfs directory, which contains a number of other folders.

3.  After building uBoot and the kernel, having installed the arm-non-eabi-gcc toolchain from the CD, as well, I then built Android following a fairly typical set of steps:

From android210-androidfs root, these commands were entered:

. ./build/envsetup.sh

lunch

mm

——-> That ‘s it!

Now, I’m waiting patiently for Android 4.0 to build.  Once this image is built, I will look at preparing the SD card so that the board can be booted off a freshly-built image.  The next hurdle will be studying the kernel and finding out where to hook into the board’s on-board analog to digital converter, audio in/out, and various other data buses, including SPI and I2C.  The intent will be to look at building a lower level kernel driver, providing an API to the driver, and then writing libraries and apps on top of that.  This will all result in a “pipeline” from a user interface / app for controls over an analog (and digital) audio processing system, or even a synthesizer.

12/8/13 – Monday.

I’m sitting here at lunch and I am still working on the Android build.  Time to partay! ; P