Recompiling Android for use with Parallel RGB TFT LCD and Capacitive Touch Panel

Looks like I need another PWM for brightness control of the LCD backlight. PWMS are in short supply!

I plan on closely following the schematic of the BeagleBone LCD4 Cape for the LCD.

https://github.com/CircuitCo/BeagleBone-LCD4-RevA1/blob/master/BeagleBone-LCD4-RevA1-schematic.pdf

Well it took some doing but I was finally able to compile the RIoT board source code.

I created an Ubuntu 12.04 virtual machine with 1 core, around 8 GB of RAM and 80 GB HD space.

• Any more than 1 core and it would freeze up.
• Without enough RAM compilation would fail. 4 GB didn't seem to work. 8 GB seemed like a safe amount.
• 80 GB of HD just to play it safe.

I tried to follow the instructions from v1.1 of the RIoT Board User Manual but found one typo. I'll just list the commands I used.

Make sure everything is updated and install the necessary dependencies. Through trial and error and searching on forums I put together the following list. There may be extra stuff in here, I'm just sharing what I used.

sudo apt-get update
sudo apt-get install ia32-libs-multiarch libglapi-mesa:i386 git gnupg flex bison gperf build-essential \
  zip curl libc6-dev x11proto-core-dev lib32ncurses5-dev\
  libx11-dev:i386 lib32readline6-dev libgl1-mesa-glx:i386 \
  libgl1-mesa-dev g++-multilib mingw32 tofrodos \
  python-markdown libxml2-utils xsltproc zlib1g-dev:i386 \
  ia32-libs u-boot-tools minicom libncurses5-dev lib32z1-dev\
  uuid-dev    liblzo2-dev

Install Repo just like the manual says.

curl https://raw.github.com/android/tools_repo/stable/repo > ~/bin/repo
chmod a+x ~/bin/repo
export PATH=~/bin:$PATH

Download the source from the repository. Strangely I found that the repo init would fail if I copy/pasted it into the terminal rather than typing it.

mkdir ~/android-imx6-jb4.3-1.0.0
cd ~/android-imx6-jb4.3-1.0.0
repo init --repo-url=git://github.com/android/tools_repo.git -u git://github.com/embest-tech/imx-manifest.git -m embest_android_jb4.3_1.0.0

Before compiling I had to make sure I had the correct Java JDK installed. I downloaded and installed the jdk-6u45-linux-x64.bin file from Oracle. http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase6-419409.html#jdk-6u45-oth-JPR

sudo mkdir /usr/lib/jvm
sudo chmod a+x jdk-6u45-linux-x64.bin
sudo ./jdk-6u45-linux-x64.bin
sudo mv jdk1.6.0_45 /usr/lib/jvm/

Then I had to configure my system to find the JDK.

sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/jdk1.6.0_45/bin/java 1
sudo update-alternatives --install /usr/bin/javac javac /usr/lib/jvm/jdk1.6.0_45/bin/javac 1
sudo update-alternatives --install /usr/bin/javaws javaws /usr/lib/jvm/jdk1.6.0_45/bin/javaws 1

sudo update-alternatives --config java
sudo update-alternatives --config javac
sudo update-alternatives --config javaws
export PATH=$PATH:/usr/lib/jvm/jdk1.6.0_45/bin

Then I could start compiling. This is where the User Manual made an error. The lunch target is actually RIoTboard_6solo-user NOT riot_6solo-user.

source build/envsetup.sh
lunch RIoTboard_6solo-user
make clean
make

Anyway that's what worked for me. I hope this helps someone.

Any particular reason for the parallel LCD ?   The LVDS interface gives you access to a wide range of panels following the Standard Panels Working Group specs.  I'm intending to try re-cycling a 15" display from a dead laptop in this way.

Thought you might be needing another PWM for panel brightness, but there are other ways if you'r short.

e14 also do the  LCD8000-97CLCD8000-97C it's a 1024x768 lvds capactive touchscreen and is compatible with the RIoT

I need a 4.3 inch lcd with decent pixel density. They all seem to have parallel or some variant of MIPI interface.

I've found some posts on the Freescale board that might help me.

https://community.freescale.com/thread/308589

https://community.freescale.com/message/348805#348805

https://community.freescale.com/thread/310492

I believe there's a MIPI_DSI block in the SoC, see section 42 of the ref manual, but I confess that I've no idea about MIPI stuff or whether there are even enough pads brought out to connectors to be able to use it. If you're stuck with 4.3" then I suppose you have to take what you can get.

Please do let us know how you get on with it..

Well I've had some problems.  I got a USB TTL serial cable so I could see what was going on during boot and I managed to blow up my board. My best guess is that I connected a 5 volt VCC line to one of the pins by mistake. I'm not sure. I was getting nonsense in my terminal window, then nothing, then the chip got really hot. : (

So I ordered a new one and am carrying on. This time I was very careful to scope all the pins before connecting anything and I cut the 5V line so I can't touch anything by accident.

Presently I am having trouble getting either the supplied Android image or one I've generated to boot from the eMMC. There are no problems during the MFGtool flashing process. The boot process begins but hangs on the line:

Freeing init memory: 252k

I've pasted the entire boot log here. RIotBoard Android Boot Log (Hanging) - Pastebin.com

Going through the manual I noticed section 5.2.2 1) which says to change the BUILD_TARGET_LOCATION in /device/fsl/riot_6solo/BoardConfig.mk. (The directory is actually /device/fsl/RIotBoard_6solo/) I double checked and saw that I still had:

BUILD_TARGET_LOCATION ?= sdmmc

So I went back to MFGtool and tried to write a card in the SD slot. It didn't work.

I tried writing a card in the uSD slot. It did work.

I tried booting from the uSD slot with the correct boot jumpers set. It didn't work.

I put the uSD in an adapter and tried booting from the SD slot with the correct boot jumpers set. It DID work!

So I have successfully built my own image and got it to boot. I don't really need it to boot from the eMMC because my final product will boot from SD anyways. Next is to rebuild the image with user permissions for one of the uarts so I can access the uart from an Android app. Then comes the hard part... getting the LCD pins working.

Oh and another thing in case anyone has any thoughts on the subject...

I recently attended the Android workshop at EELive in San Jose. http://www.eeliveshow.com/sanjose/conference/android-engineering-certificate-program.php

The gist of the thing was that Android is great for a UI and not good for realtime processing. What they suggested was to use a Linux/Android hybrid system. The instructors had created an image for the Nexus 7 that had Android Kit Kat running on top of a Debian distribution. To demonstrate their point we used a fake oscilloscope app which displayed a lot of latency when sampling data in the Android user space. Then in the Debian user space, we made a Linux kernel module which sampled data with very little latency then read the data back into our fake oscilloscope app. It worked great and really made their point but they didn't show us HOW to make the hybrid system.

So now I need to figure out how to make my own hybrid distribution. The RIoTboard, with it's Android focus, seems like a good candidate for this. So this is something I'd like to pursue in the long term.

I found a website with some instructions that seem promising. http://whiteboard.ping.se/Android/Debian

I'll be sure to share if I have any success.

SPI Port Problems

Hey guys,

I've got a cape/shield now but I'm having trouble with the SPI port.

Getting access to the SPI port

Just as a reminder, I'm using the Android distribution provided for the Riotboard which has the older kernel and uses board.c files instead of device trees. I'm trying to use ECSPI1 to send the initialization commands to the LCD. I realize I should be using some sort of kernel module to do this but I've had a little experience using spidev in userspace so I thought I'd try sending the commands that way first. Althoug I did find a good tutorial on writing SPI kernel modules. (Writing a Linux SPI driver - Part 1)

I found this thread on the Freescale message board which discusses how to get spidev working.

https://community.freescale.com/thread/302612

The pin multiplexing is set in board-mx6dl_RIoTboard.h

/* CSPI */
  MX6DL_PAD_KEY_COL0__ECSPI1_SCLK,
  MX6DL_PAD_KEY_ROW0__ECSPI1_MOSI,
  MX6DL_PAD_KEY_COL1__ECSPI1_MISO,
  MX6DL_PAD_KEY_ROW1__GPIO_4_9,

Then the port is initialized in board-mx6dl_RIoTboard.c, where it is set up to use the ads7846 touch panel driver. I changed the init structure to match my needs.

static struct spi_board_info imx6_RIoTboard_spi_devices[] __initdata = {
        {
                /*.modalias = "ads7846",*/
                 .modalias = "spidev",
                .bus_num = 0,
                .chip_select = 0,
                .max_speed_hz = 1500000,
                /*.irq = gpio_to_irq(RIoTboard_RES_TCH_INT),
                .platform_data = &ads7846_config,*/
                .mode= SPI_MODE_3
        },
};

Then in the board initialization function I made sure that the correct SPI bus was being initialized.

/*!
* Board specific initialization.
*/
static void __init mx6_RIoTboard_board_init(void)
{
     ...
/* SPI */
  imx6q_add_ecspi(0, &mx6solo_RIoTboard_spi_data);
  spi_device_init();

I had to make sure that the spidev module added was into the kernel. In the file /kernel_imx/arch/arm/configs/imx6_android_defconfig I changed the line:

# CONFIG_SPI_SPIDEV is not set

to:

CONFIG_SPI_SPIDEV=y

Once I had all that done I recompiled the Android image and put it on an SD card. When I looked in /dev I was rewarded with a file called spidev0.0.

Compiling a binary to run on the Android shell

To test the SPI port I decided to use the spidev_test.c from:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/spi/spidev_test.c?id=95b1ed2ac7ffe32…

First I changed the spidev.h location to be:

#include </home/riot/android-imx6-jb4.3-1.0.0/kernel_imx/include/linux/spi/spidev.h>

and the device to be:

static const char *device = "/dev/spidev0.0";

I cross compiled the binary using the android gcc in the prebuilts, with the --sysroot referring to the headers in the ndk 8 folder.

riot@ubuntu:~/android-imx6-jb4.3-1.0.0$ '/home/riot/android-imx6-jb4.3-1.0.0/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-gcc-4.6.x-google' --sysroot='/home/riot/android-imx6-jb4.3-1.0.0/prebuilts/ndk/8/platforms/android-14/arch-arm'  -o ../spidev_test ../spidev_test.c

Next I booted my Riotboard, remounted the filesystem so that I could write to it and made a directory to put the binary in.

root@RIoTboard_6solo:/ # mount -w -o remount /dev/block/mmcblk0p5 /system
root@RIoTboard_6solo:/ # mkdir /system/lcdtest

From my Windows pc I connected the mini-usb and pushed the binary into the directory.

C:\>adb push spidev_test /system/lcdtest
853 KB/s (7868 bytes in 0.009s)

Back in the serial shell I made the binary executable and tried it out.

root@RIoTboard_6solo:/ # chmod 777 /system/lcdtest/spidev_test
root@RIoTboard_6solo:/ # /system/lcdtest/spidev_test -H -O
spi mode: 3
bits per word: 8
max speed: 500000 Hz (500 KHz)


FF FF FF FF FF FF
FF FF FF FF FF FF
FF FF FF FF FF FF
FF FF FF FF FF FF
FF FF FF FF FF FF
FF FF FF FF FF FF
FF FF

Everything nearly worked correct. I was scoping the output on my logic analyser and noticed that my Clock isn't operating at the correct polarity.

The clock polarity appears to be mode 0 no matter what mode I set the spidev to be. Changing the frequency affects the output correctly. It's just the mode that won't change.

Does anyone know what I may be doing wrong?

The problem was that SPI modes with CPOL high aren't implemented in the spi_imx.c driver.

This guy on the Freescale forum found a solution.

https://community.freescale.com/thread/313815

I made the changes he suggested, however I still can't get my LCD to initialize correctly. The clock is at the right polarity now however there seems to be an extra pulse at the end of every message.

In the following instance I sent 0x11. That clocks out correctly, then there's one extra pulse of nothing at the end.

I'm in touch with my LCD manufacturer. Hopefully they can help.

Out of curiosity, did you try using the 3.16-rc* kernels to see if the driver has been sorted out somewhere between 3.0.35 and 3.16 ?

If it has then you may be able to compare the two versions and work out what to change. There's also a 3.10.x provided by freescale that may just need some devicetree work for the RIoTboard.