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
The Android and Embedded Linux Audio DSP Channel 