EDIT: I’ve been working on this project again and am currently in the process of writing a new article on this!

So I’ve gotta build out a new system for the LED’s on the Sensatron art car. Last year we had to have a full laptop on the car to spit color out to the LED’s via a hacked FTDI driver using bitbanged SPI. It was really a hack…

But this year, I’m not going to be on Playa. So this year, it has to be self contained.

In the past, we tried using an Arduino, but it just isn’t powerful enough for the task. The next step up would be something like the Beaglebone Black. Since it’s got (in theory) a good GPU, as long as we can get OpenGL running on the thing, than we should be able to use that to process the animations.

But first, we need to get some kernel stuff out of the way. I followed Thing-Printer’s kernel upgrade process because they’ve built the SGX kernel modules and the 3.12.9 kernel image that it will work with to support OpenGL. The process is outlined here Note: I changed the kernel version from 3.12.1 to 3.12.9 since 3.12.1 is no longer in their feed.

However, after adding the feed to opkg on the Beaglebone, and installing all the modules, it failed to reboot cleanly.

The very next step I tried after I saw that the boot was failing was hooking up a serial terminal and watching uboot’s logs to see if it gave any hints as to why it was failing. uboot stops outputting logs after the “Uncompressing Linux…” line. This usually means that your kernel upgrade didn’t go as planned.

False SD Card Hopes

After that was mostly unhelpful, the next thing I tried was plugging in the SD card and trying to recover the board. But the SD card images for the Beaglebone Black ARE NOT TO BE BOOTED UNLESS YOU WANT TO FLASH THE WHOLE SYSTEM OVER! They are NOT to be used for non-destructive recovery!

So, as soon as I naively put the SD card back in the slot and boot the board, it started it’s flashing process… which blew away the whole damn install.

The one useful thing I learned while poking around and realizing that these SD card images are destructive to the existing install is what block devices are which:

mmcblk0 -> SSD
mmcblk1 -> Onboard MMC device

Reinstalling Angstrom (again) and Trying SDL

So now I’m waiting for Angstrom to flash again.

Finally, that finished. Now to try another method: Start with SDL and go from there. Maybe we won’t really need OpenGL for this project… but in any case, we need the SDL app at least initializing first.

To use SDL, we’ll need to use the Linux framebuffer directly. Out of the box, even the most basic SDL app won’t run on the Angstrom distro. The first trick is killing gnome so we KNOW we have video access. To do this, we need to run the following and REBOOT:

systemctl disable gdm.service

But that’s still not enough for SDL to grab a video device to write to. We’ll probably need to install some fbdev kernel driver first, then maybe set some of the SDL environment variables. To get a /dev/fb0 device working on the BBB:

opkg install directfb

but that STILL doesn’t work (even after a reboot). And neither is setting the SDL_VIDEODRIVER environment variable as:

export SDL_VIDEODRIVER=directfb

So maybe the version of SDL from the BBB feeds don’t have framebuffer support compiled in? I can’t believe it wouldn’t be…

Moving on: Someone elses work

I reached out to Elias Bakken (@AgentBrum) on Twitter and he pointed me at his replicape Beaglebone Black image. It has SGX working and uses the framebuffer directly at /dev/fb0 to display the Toggle app on the screen.

So I installed that on the 4GB Beaglebone Black that showed up today and started getting things set up. I installed SDL from opkg but for some reason SDL still couldn’t find the framebuffer. So I installed gcc directly on the BBB, downloaded SDL, and started compiling it from scratch just to make sure the framebuffer support was actually compiled in.

Meanwhile, I took a look at the capes defined in /lib/firmware/ because the cape manager’s overlays changed between 3.8 and 3.12 (which is what the Thing Printer image from Elias is running). Because of the change, the 4D 7” LCD Touchscreen cape I need to get working isn’t configured correctly.

The first thing I realized is that this new image doesn’t include any of the dtc commands such as fdtdump or dtc itself. So I had to download the source and compile that on the Beaglebone as well.

Meanwhile, I loaded up the older 2GB board with a simple Ubuntu image with a working cape to figure out what .dts file it was using so I could work from a known, good, DTS overlay descriptor file to start updating the pins to match their new 3.12 definitions. The DTS for the 4D 7” LCD cape is:

BB-BONE-LCD7-01-00A3.dts

So now, with that dts file, the working dtc tools, and the capes schematic, I should be able to port the cape to work with 3.12!

And SDL just finished compiling! So let’s try that out again…

And nope. Still doesn’t work. Even with SDL_VIDEODRIVER set. :sigh:

Well, let’s get that cape working and we’ll come back to SDL in a bit. Maybe we need to use something other than SDL for this project…

Fixing the LCD Cape

After a bunch of banging my head against the wall, I finally got the cape’s dts file updated to work on version 3.12 of the kernel! I’ve made a github repo with the final dtbo file and the dts file. That repo is here:

https://github.com/JamesHagerman/4D-7in-LCD-Cape-Fixes-for-3.12

Also, because the version of dtc I had on the beaglebone didn’t support symbols, I had to apply a patch to it to get it to compile the dtbo from the dts file. That repo is here:

https://github.com/JamesHagerman/dtc

So! Now I have a working LCD cape on 3.12 with SGX loaded up! Because the Toggle app is running on the image Elias Bakken pointed me to, And since that uses OpenGL ES via the SGX library, I can officially see OpenGL running on the 7” LCD! Sure, it’s rotated incorrectly, but that’s minor at this point…

That means this project is DOABLE in regards to getting OpenGL working.

SDL however… is still up in the air…

Building everything myself

After corresponding with Elias directly via Twitter asking him if FB support was compiled in to his kernel, he said it had been a long time but he didn’t think that it WAS compiled in. Which might explain why SDL couldn’t use the FB… and it also explains why my relatively sane LCD Cape dts file was throwing a pretty gnarly kernel dump when it was loaded up.

So now, after a bunch of digging, I’ve started to use the Yocto Project’s build system to get things up and running. Luckily, the Yocto project was the place that Elias directed me to just a bit later in the conversation; He said the SGX support along with FB support was just added to the meta-ti “module” in the Yocto build process!

That means if I can get it to compile, I should have both a working build system for myself along with a working kernel and filesystem image with all of the features I need working correctly. Too bad I don’t know shit about Yocto. But here it goes anyways:

I’m doing this on a quad core Intel Q6600 desktop machine running Ubuntu 14.04. To get everything ready for Yocto’s build process I had to run this apt-get command:

sudo apt-get install gawk wget git-core diffstat unzip texinfo build-essential chrpath libsdl1.2-dev xterm libunwind8-dev

Once I did that, I had to get the latest Yocto source tree and a few other meta~~* packages to get it working with the BBB: bc. git clone~~b dora git://git.yoctoproject.org/poky.git cd ./poky git clone https://github.com/openembedded/meta-oe.git git clone git://git.yoctoproject.org/meta-ti.git

Once those were pulled down, I had to configure Yocto’s build system itself:

source oe-init-build-env bbb
vim conf/local.conf
vim conf/bblayers.conf

In the conf/local.conf file, I had to set the MACHINE and BBMASK values correctly and make sure the system would be using the right number of cores to compile with the BB_NUMBER_THREADS and PARALLEL_MAKE values. The BBMASK value was not in the file so I added it. I set these lines:

BB_NUMBER_THREADS ?= "8"
PARALLEL_MAKE ?= "-j 8"
MACHINE ?= "beaglebone"
BBMASK ?= ".*/meta-ti/recipes-misc/(images|payload)/"

In the conf/bblayers.conf file, I had to add these lines correctly under the BBLAYERS block. Keep in mind your paths will be different:

  /home/jamis/dev/beagleboneblack/yocto/poky/meta-oe/meta-oe \
  /home/jamis/dev/beagleboneblack/yocto/poky/meta-ti \

Once that was done, I had to cd back INTO the bbb/ directory so that I could clear out the stuff that was set in the “source” command above. Once there, I was able to run bitbake to compile the smallest and simplest kernel and filesystem images:

cd /home/jamis/dev/beagleboneblack/yocto/poky/bbb/
bitbake core-image-minimal

But once that ran, the meta-oe metadata/“module” was throwing some error about libunwind. But meta-oe is needed for the beaglebone black to work correctly, so after some digging, I found that I needed to set the ${SAVANNAH_NONGNU_MIRROR} and the ${SAVANNAH_GNU_MIRROR} value in this file:

yocto/poky/meta/conf/bitbake.conf

To the following. There is a section in that file named “# Download locations and utilities.” and it should probably go under that somewhere:

SAVANNAH_NONGNU_MIRROR = "http://download.savannah.gnu.org/releases"
SAVANNAH_GNU_MIRROR = "http://download.savannah.gnu.org/releases"

Now would be a good time to mention how to “make clean” this bitbake stuff. This should do the trick (but it should only clean out what it needs):

bitbake -c clean core-image-minimal

So once this is compiled, you have to go through some work to partition the SD card and get all of the files onto it in the correct way. The output of the build will be placed in:

yocto/poky/bbb/tmp/deploy/images/beaglebone/

… And in that directory, you’ll find all of the files you need except the uEnv.txt file to tell uboot how to load the image. You’ll have to figure that out for yourself.

That said, the uEnv.txt is actually the most important part. If you get it wrong, uboot will freak out and just boot whatever is on the current MMC device built in to the board. So, you need a uEnv.txt file that works.

But for right now, since I don’t wanna sit down and figure out how to build the uEnv.txt file itself, I’m just using this command at a serial terminal until I get a working build:

bootcmd=i2c mw 0x24 1 0x3e; run findfdt; run loadbootenv; run importbootenv; setenv bootfile uImage; fatload mmc 0:1 ${loadaddr} ${bootfile}; setenv mmcroot /dev/mmcblk1p2 ro; setenv mmcrootfstype ext2; setenv bootargs console=${console} ${optargs} root=${mmcroot} rootfstype=${mmcrootfstype}; load mmc 0:2 ${fdtaddr} ${bootdir}/dtb/${fdtfile}; bootm ${loadaddr} - ${fdtaddr};

That form is kind of messy, so here’s a commented version:

bc.. i2c mw 0x24 1 0x3e run findfdt run loadbootenv run importbootenv

1. Actually load uImage: setenv bootfile uImage fatload mmc 0:1 ${loadaddr} ${bootfile}

2. Setup the root filesystem device info: setenv mmcroot /dev/mmcblk1p2 ro setenv mmcrootfstype ext3

3. Setup the boot arguments: setenv bootargs console=${console} ${optargs} root=${mmcroot} rootfstype=${mmcrootfstype}

4. Load the FDT file (found in the findfdt command): load mmc 0:2 ${fdtaddr} ${bootdir}/dtb/${fdtfile}

5. Actually load the os: bootm ${loadaddr} - ${fdtaddr}

But even after all of that, the system still fails to load with the dreaded “Starting kernel …” line. So something’s still wrong.

The next thing I need to try is ditching meta-ti and using meta-beagleboard instead. Too bad meta-beagleboard doesn’t have all of the drivers I need from ti…

Till next time…