Autosport Labs

This thread is to document my exploration of the BeagleBoneBlack (BBB), and it's potential as a host for the RCP App, or some subset of it, or else definitively prove that it is unsuitable.

In my specific case, I intend to use it to drive an external 1024x600 outdoor display, which worked perfectly.

The board arrived today, along with the display, and I have not been so excited in a long time. This is going to be a challenge.

Broadly speaking, there are three prongs to this attack, which I'm pursuing in parallel:

• RCP with official debian image.
• RCP via custom image generated from Buildroot
• RCP via android port.

The first thing I had to do was download the lastest debian image (stretch), and flash onto an sd card. The jessie image board shipped with was broken from jump, with a simple update failing to peform correctly.

In parallel, I am generating an image via buildroot on my laptop. I will post the final buildroot config and kconfig, if this works out.

I have been traveling for a few days, so not as much progress as I would like. But some progress:

• Got some accelerated demos working in the stock debian distribution
• Got first working buildroot config which boots, and allows ssh login
• Got the QT5 Opengl Demos to run with acceleration
• Got Kivy building under buildroot, against the platform GLESv2 libs.

Debian
I was able to follow a guide to install TI drivers on debian, and got some of the KVM examples to run. It was an encouraging first step. I then tried to get an opengl benchmarking tool, glmark2, to build against EGL and the TI drivers. It builds, but when I try to run it, complains about a missing .so file. I think it's just an issue with the build scripts picking up the wrong library from somwhere.

But, meanwhile, I made more progress with buildroot.

Buildroot
The demos ran great, so I'm somewhat optimistic this will all work out in the end.

I am working towards getting a minimal Kivy hello-world app to run. The library loads, but it wasn't able to open a window because it the EGL backend is Raspberry pi specific, using the broadcom driver directly.

So, I am adding SLD2 to the buildroot config, configure SDL2 to use EGL, and then try building kivy against SDL2.

When this is all done, I am considering submitting a patch to add the RaceCapture App as a buildroot package, with a default config for both raspberry pi and beaglebon.e

One thing that's really nice about buildroot his how fast these images boot, even off an SD card.

Attaching images of the demo apps. The apparent dithering is actually an artifact of my cell phone camera and / or compression, not apparent in real life.

https://github.com/emdash/buildroot/pull/1

I have tried two different android images:

• http://icculus.org/~hendersa/BBB_JB_And ... 13.img.bz2
• https://newcontinuum.dl.sourceforge.net ... 514.img.xz

Neither of these seem to enable hardware acceleration. The former seemed to run reasonably well. The later was painfully slow.

I't's not clear if there are newer images available, or if more recent versions of the android system would work better.

I spent a couple solid days horsing around with buildroot, trying different combinations of libraries, and was never able to get anything but the pre-compiled demos to use the GPU.

What it comes down to is this: the beaglebone black's PowerVR GPU is perfectly capable, but linux software support is lacking. There are no open-source drivers, and the supplied libraries are missing various features (like GBM), so it's impossible to get something like SDL2 or even benchmarking tools like glmark and kmscube to actually build and run on the PowerVR GPU. I was able to get GLmark2 to build, using libgbm supplied from mesa3d, but it did not actually work with the GPU at runtime. I could not get kmscube to build at all using the supplied libraries, because they were missing certain symbols.

The situation is actually identical on the Raspberry Pi, except that someone already did the hard work of creating a user-space library to support the RPI GPU, and ported Kivy to run on that interface, whereas no one has done it for the bbb.

In the end, there are only three ways this board will work with Kivy:

• Make a separate EGL port, similar to the rpi port, but using the PowerVR sdk.
• Reverse-engineer the PowerVR GPU to create a proper kernel driver.
• Use mesa with software rendering.

I have been experimenting with the software rendering idea, but this currently produces random segfaults (I think related to the fact I didn't have a keyboard or mouse plugged in, have not tried it with a mouse). My suspicion is that it will run with software rendering, but be ungodly slow and horrible, though there is an llvm-based renderer in mesa3d that has a chance of performing well enough.

I think that, given all this, it's less work to write a custom dashboard application that uses something like fbdev + cairo, or wayland + cairo, using the fbdev backend, than to actually port kivy. Either way, it's a lot of work, but I still might give it a try at some point. For the moment, I am moving on.

I started an alternative dashboard project specifically to support this board (though it should be portable to other linux boards).

See the following post: viewtopic.php?t=6137

Found this website which has a nice range of products, including some that are easy to open and close.

https://www.polycase.com/hinged-enclosures

I'm sure a metal enclosure is better form an RF / EMI perspective, but the hinged / latching cover would be more convenient for working with it. It's probably going to live under my seat, which I admit is not a great place for it. But I don't have a ton of options.

Been hacking away. My desk is a bit too messy to take clear pictures right now, you'll just have to bear with me.

The cabling situation is a little bit awkward: I've got power, HDMI, and USB that all need to be run as separate cables, between three different devices. Allowing for maintenance, so I don't want to do anything that would make any of the individual components RCP, BeagleBone, or the screen, too difficult to remove. And each component has it's own mounting considerations.

The Display, obviously, has to be up where I can see it. The weird thing about the display is that, I guess for the sake of weather proffing, it has a long-ish cable permanently attached to it, which has to be used with this very specific 25-pin adapter, that then breaks the cables out to standardized connections. It is rather bulky, and more than once I've been worried the weight of the cable would yank the tiny display off my counter. The display itself vastly outweighs the tiny beaglebone black. Back in my day, your computer generally weighed more than the cables attached to it For all that, I think mounting the display is going to be the easiest part of this whole process. It's the only thing that has to be in one specific place. I would just re-use the original mount, but the existing display is a tabled that's been epoxied into place, so ... it ain't coming off in one piece.