Tegra3 – Tuomas Kulve

Ubuntu on Ouya

March 24, 2014September 20, 2014tuomas

[Update 2014-09-20]: The latest patches from Markus for the Jetson TK1 work also for Tegra3!

I was testing Markus Tavenrath’s EGL branch of the XBMC on my Ouya and noticed that OMX_UseEGLImage segfaults on Debian but doesn’t on Ubuntu. The segfault happens inside the NVIDIA’s OMX binary, so there is not much to debug. And with Ubuntu 13.10 I had rendering issues. Then I tried Debian Jessie just to discover it is already using X.Org Video ABI 15.

So here is the summary of my discoveries:

Debian Wheezy: Segfault in OMX_UseEGLImage with XBMC.
Debian Jessie: X.Org Video ABI 15, no driver.
Ubuntu 12.04: Old.
Ubuntu 12.10: Old.
Ubuntu 13.04: No obvious issues.
Ubuntu 13.10: X.Org Video ABI 14, rendering problems.
Ubuntu 14.04: X.Org Video ABI 15, no driver.

I noticed that Totem has moved to GStreamer 1.0 so it does not use NVIDIA’s GStreamer plugins. I changed Parole to use nvxvimagesink instead of the de-facto xvimagesink and it works well. I’ve uploaded the binary to my tmp.

Pulseaudio seemed to cause slow playback and extra CPU consumption so I just removed it.

My instructions for creating Ubuntu Raring rootfs for Ouya can be found from github. Do leave a comment if there is anything broken with the instructions!

Debian on Ouya: All Systems Go

September 12, 2013tuomas

I finally got all the major subsystems working and Debian is now usable on Ouya. I prefer Debian but Ubuntu should work similarly.

In the above screenshot I’m playing 1080p H264 while running glmark2-es, an OpenGL ES benchmark. And the CPUFreq ondemand governor doesn’t even raise the CPU frequency from the minimum as everything is properly accelerated. I do have to admit that the 1080p video isn’t running smoothly with the benchmark running at the same time.

A disclaimer before telling more: Trying this out might void the warranty and flashing anything to Ouya may easily brick it forever. So don’t try it, unless you are willing to buy a new one.

That said, the idea is not to touch Ouya’s Android at all. Kernel is booted from RAM and Debian from an SD card or USB stick.

The instructions for debootstrapping your own Debian Wheezy rootfs are described in the github repository and the needed binaries are in a temporary location that will probably change at some point.

WiFi is working as well but I’m not sure if the firmware binaries are redistributable, so you need to copy them from the Android rootfs after booting to Debian.

One of my main goals for this whole exercise is video encoding and I’m happy to say that H264 encoding from an USB webcam works nicely with hardware acceleration as well.

I’ve also noticed some issues:

Hciconfig doesn’t show BT devices, I didn’t debug much further.
Mpg123 seems to play but nothing is heard. Maybe it tries to pass MP3 onwards instead of PCM? GStreamer provides acceleration for MP3 and AAC though.
Video acceleration works only with GStreamer and nvxvimagesink. Mplayer can’t even use XV video output correctly.
Tegra3 supports only OpenGL ES 2.0 with EGL, so no full OpenGL with GLX.
Xrandr seems to be able to switch the resolution but after the switch there was window decoration corruption.

Despite the deficiencies I think Tegra3 is quite well supported in the X.Org world and many things work well with this 99$ device.

If you test my instructions, let me know how it goes and what you think about it! :)

Pleco Phase02 completed

September 1, 2013tuomas

It’s been two years already since I posted about Phase01 being completed. It was a simple track based vehicle using cheap DC motors and the hull was built from Meccano parts:

For Phase02 I decided to go with a ready made car and bought an RC Rock Crawler. It’s about four times the size of the Phase01:

The software is roughly the same as it was for Phase01. I’ve fixed a lot of bugs, simplified some things and added a bunch of new features. The slave has a sonar next to webcam and it measures the distance to what ever the camera is pointing at. The slave also measures the current consumption and battery voltage level. All details are shown on the GUI.

The hardware on the other hand has changed a lot. Instead of handling the servos directly from Linux there’s now a separate self-designed Cortex-M4 based microcontroller board for driving the PWM signals. In the future the microcontroller can update the PWM signals real-time based on other sensors without having to worry about latency issues in Linux.

The Linux is now running on a Tegra3 based Ouya gaming device. Ouya is not as convenient for robotics as Gumstix was but personally I think Tegra has better Linux support than OMAPs. And since there is now a separate control board for motors and sensors, it’s enough for the Ouya to only have a USB connection to the control board.

Ouya needs 12 volts while the motors need 5 volts and I’m expecting to need 3.3 volts as well. So I now have three switching regulators connected to the battery for the needed voltage levels. And a USB hub because of the USB based control board and webcam. There are also lots of cables. So I’m not actually able to get everything nicely inside the car, but almost.

Controlling an RC car with a keyboard is inconvenient, so I’ve added support for gamepads. I’m currently using a Bluetooth based gamepad from Logitech:

When driving in a local WiFi network, there’s no noticeable latency at all. It’s still not possible to really drive based on the camera only, the viewing angle is too narrow, turning the camera is cumbersome and the video quality needs some tweaking.

Now that I’ve made some nice progress with the project, I have clear goals for the Phase03:

Disassemble the webcam to get the size and the weight down and to be able to attach fish eye lenses to it.
3D print a frame for the electronics and the webcam.
Tweak the video quality and camera controls so that it would finally be possible to drive based on the video stream.
Control the webcam based on driver’s head orientation?

So there are plenty of interesting things to learn :)

Oh, and I’ve moved the code to github.

Debian on Ouya

August 11, 2013September 12, 2013tuomas

Ouya is a 99$ Tegra3 based gaming console without a display.

My goal is to use Ouya in my robotics project for video encoding but first I want to have Debian running there with hardware accelerated X.Org, OpenGL ES and video.

I now have the Debian running but with a few bigger issues that I’ll describe shortly. If you want to try it out, you can find my instructions for creating the rootfs in github. That might void the warranty even though the kernel is booted from RAM and the rootfs mounted from USB stick so the Ouya software should remain intact.

Ouya is easily brickable permanently, so you need to be careful not to flash anything there and you’ll be doing it at your own risk.

About the Issues.

HDMI

2013-09-05: HDMI works now with multiple resolutions and is not so picky about having the cable connected already on boot.

Ouya display kernel driver is hardcoded to use HDMI as the primary display with 1920×1080 resolution. That works relatively well as long as you keep your monitor/TV always on. I couldn’t get anything but black if I e.g. switched my monitor to another input and back.

I tried to enable the normal behaviour in the display driver and by disabling the LVDS in xorg.conf but the TV remains black and doesn’t seem to change the resolution. Maybe there is still something hardcoded in the display driver or maybe the driver is trying to enable the non-existent internal panel and gets confused.

Audio

2013-09-11: Got audio working with a simple asound.conf. I also run /etc/init.d/alsa-utils stop but unsure if that affected anything.

aplay -l lists HDMI as the first device and tegrawm8903 as the second. If I make the tegrawm8903 the default the audio plays but only from the left speaker and half the speed.

I don’t know if this is related to the HDMI problems above or if I should just have the correct ALSA mixer configuration.

Video

2013-09-05: Totem has configurable video sink: gconftool-2 -s /system/gstreamer/0.10/default/videosink nvxvimagesink –type=string

Hardware accelerated video decoding and rendering is supported through GStreamer. Currently videos play well with playbin2 as long as the audio is disabled with audio-sink=fakesink and the correct video sink is selected with video-sink=nvximagesink.

Maybe the GStreamer’s autovideosink should be patched to use nvxvimagesink instead of xvimagesink to make nvxvimagesink the default in applications using playbin2

Power

2013-09-05: CPUfreq with ondemand governor is working and enabled in the kernel nby default now.

CPU core hot-plugging works but switching to the low power core seems to lead to a kernel bug (arch/arm/mach-tegra/pm.c:509). Same bug seems to happen with ondemand CPUFreq governor. I haven’t really tried to get those working yet but both of them are working with Nexus7 so maybe it’s possible to get them working on Ouya as well.

If you want to test Debian on Ouya, you can find the needed blobs from my /tmp but I might set up something more appropriate later.