RidgeRun Blog

In case you miss the news, the Leopard DM365 board is now available.

We will be rolling an SDK for it pretty soon (less than two weeks).

Davinci, Gstreamer, LeopardBoard Davinci, DM365, Gstreamer, LeopardBoard

We are glad to release a free SDK for the OMAPL138 EVM/experimenter board.

This free SDK allows people to evaluate the capabilities of RidgeRun’ SDK software integration on the EVM hardware. Our highlights are:

• Support for the touchscreen on EVM
• Automatic integration and build of the DSP software components.
• DMAI integration.
• Examples for development of DSP algorithms using IUniversal and xDAIS integrated.

The professional SDK for L138 is available as well that could be used for create your own custom hardware based on L138, and includes gstreamer integration and support for L138 of the DSP components. Professional SDK includes engineering support for your product development from our engineers as well. Contact us for more information.

Hawkboard support coming soon.

You can download the free SDK for OMAPL138 EVM from our download center.

L13x, OMAPL138, hawkboard hawkboard, L138

RidgeRun is working along Costa Rica TEC into a project for developing xDAIS DSP algorithms for TI processors.

Here is the press release for the resources donations.

Here is the project’s blog.

Education, OMAPL138 Costa Rica, Education, Gstreamer, L138

Thanks to the collaboration between RidgeRun, Costa Rica Institute of Technology, and Texas Instruments, we are announcing our first conference on the subject of embedded technology. We will be doing presentations for students on several subjects and introducing them to the research project on DSP algorithm development.

For more information visit the conference page.

Education Costa Rica, Education

I was testing the new DM6446 SPI support I had added to u-boot when I got a data abort.

U-Boot > sspi 0 32 abcd
data abort
pc : [<810a3674>] lr : [<810a3638>]
sp : 8104fe3c ip : 00000d39 fp : 00000001
r10: 00000002 r9 : 00000000 r8 : 8104ffdc
r7 : 000f4240 r6 : 00000000 r5 : 00000000 r4 : 810602b8
r3 : 00000001 r2 : 01c66800 r1 : 00000019 r0 : 810602b8
Flags: NzCv IRQs off FIQs off Mode SVC_32
Resetting CPU …

Egads, what should I do with that information? Actually, it is really rather easy to figure out what line of source code caused the problem. Here are the steps I used.

First, look in u-boot.map where you found the u-boot.bin that you loaded into your target hardware. Search for the library with the address closest (but lower) to the address shown in the dump for the pc (program counter) register – 0×810a3674 in my case. Note that the PC was incremented by 4, so the address of interest is at 0×810a3670

from u-boot.map:

.text 0×810a3428 0×25c drivers/spi/libspi.a

This is the collection of object files in an archive (the .a file) from the drivers/spi directory.

Since the PC address when the data abort occurred is 0×810a3670, and libspi.a starts 0×810a3428, the problem occurred 0×248 offset inside libspi.a.

Second, use objdump to see what is 0×248 bytes from the start of the libspi.a.

arm-linux-gnueabi-objdump -dS drivers/spi/libspi.a

which produces, in part

static inline void spi_out32(u32 addr, u32 data)
{
__raw_writel(data,addr);
244: e5832000 str r2, [r3]

/* Take SPI module out of reset */
spi_set_bits(SPI_GCR0, 1);

/* Take SPI module out of reset */
spi_set_bits(SPI_GCR0, 1);

return &spi_bus->slave;
}
248: e8bd84f0 pop {r4, r5, r6, r7, sl, pc}

the source code objdump added to the assembly listing isn’t exactly right (because I have compiler optimization enabled), but you can see the problem is near the return from the spi_setup_slave() function that caused the data abort.

Hmm, turns out it was one instruction before – at offset 0×244 – there is more instruction pipelining that I realized, the causing the value of PC to be incremented for two instructions before the data abort occurred.

In look at the inline function

static inline void spi_set_bits(u32 addr, u32 bits)
{
u32 v = spi_in32(addr);
v |= bits;
spi_out32(v, addr);
}

I see I have the arguments backwards in the spi_out32 call. Changing the line to:

spi_out32(addr,v );

fixed the problem.

I hope this simple example shows how with the aid of a symbol (map) file and using objdump, you can use the PC address where the problem occurred to quickly locate the line of offending code.

Uncategorized

In the past I have always hauled around a simple i2c Linux app I wrote so I could read and write I2C registers when I tried to make sense of some confusing datasheet. This was in the dark ages before there was a standard I2C sub-system in Linux.

Recently while working on a touch screen driver for the TI TPS65070 chip (the combo analog chip for the way cool OMAP-L138 SoC), I came across i2c-tools from the folks over at lm-sensors. After a quick port to the SDK framework, I ran the i2cdetect tool and got the output:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
20: -- 21 -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- UU -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

UU means a chip was detects and since the datasheet said my chip had address 0×48, I was seeing a response I expected.

Next, I read the TPS65070 datasheet to see how to configure the chip to post an interrupt when the screen was touched. I needed to set a couple of I2C registers and for this simple test, I poll once a second.

# step 1 - enable the ADC, select TSC input to ADC
i2cset -y 1 0x48 0x07 0x8F

# step 2 - set tsc mode to detect touch
i2cset -y 1 0x48 0x08 0x05

# step 3 - poll tsc interrupt (bit 3) until it is set
while sleep 1 ; do i2cget -y 1 0x48 0x02 ; done

Example output:

0x00
0x00
0x08
0x00
0x00

As soon as I read the I2C interrupt register, the interrupt is cleared.

There is a series of steps request to read the X and Y locations, so I wrote a simple shell script

tsc_read ()
{
    # first parameter is ASCII charcter between 0 .. 7
    tsc_mode=$1
    # set the tsc mode
    i2cset -y 1 0x48 0x08 0x8$tsc_mode
    # start the conversion on ADC input TSC
    i2cset -y 1 0x48 0x07 0xCF
    # verify we are done (shell script should be slow enough)
    # check that bit 5 is set
    i2cget -y 1 0x48 0x07
    # read the A/D converted value
    i2cget -y 1 0x48 0x0A
    i2cget -y 1 0x48 0x09
}

And now to read the X and Y locations is easy

# step 4 - read X position
tsc_read 0

# step 5 -read Y position
tsc_read 1

Example output:

# tsc_read 0
0xaf
0x01
0xf6
# tsc_read 1
0xaf
0x01
0x83

meaning on a 10 bit A/D scale 0×000 … 0×3FF (x,y) = (0×1F6, 0×183)

Overall, I found the i2c-tools very helpful in validating I understand how to interact with the chip registers properly.

Uncategorized

We are rolling an updated OMAP35x free SDK! The highlights are:

• Based on latest PSP from TI (based on kernel 2.6.29)
• Support for OneNand and NAND Mistral EVMs
• Support for integration against latest DVSDK from TI.

As usual the free SDK is a great platform to evaluate how the RidgeRun SDK give you a better time to market by speeding up your development. The professional SDK from RidgeRun includes integration for GStreamer plugins, graphical environments for the target board, professional support from our engineers, development services, training, and much more.

You download the free SDK for OMAP35x from here.

Enjoy

Gstreamer, OMAP35x Gstreamer, OMAP35x

We have (finally!) released and updated free SDK for Leopard Board. The highlights are:

• Kernel 2.6.29 based:
  • We have added the camera patches (VGA) so the camera works with v4l2 APIS (in particular it works with gstreamer, thanks Maria!).
  • Audio patches so input and output are working with alsa (thanks Cristina!).
• DVSDK integration with the git kernel (thanks Maria!)
• GStreamer integration: support for encoding/decoding mpeg4 and if you download the DM355s codec combo you can enable AAC/MP3 encoding decoding (thanks Cristina!).
• We have tested the gstreamer elements are capable of RTSP streaming.

Known issues (we will be fixing them soon):

• No support for NAND flashing from uboot. Recommended boot modes are NFS and SD card.
• Network interface doesn’t set a default MAC address, so an uboot network operation is required before booting.
• Network interface issues may cause the board to lost connection over NFS.
• Garbage on the screen during CPU overload (flickering).
• No support for FB interface from the TIDmaiVideoSink

Even the known issues list is long we think we should have them fix soon, and want to share the new features ASAP.

Special thanks for this efforts to María Rodriguez and Cristina Murillo, our two interns from ITCR and now full time engineers, and to Miguel Aguilar, our engineer supervising their work.

Download from here.

Enjoy.

Gstreamer, LeopardBoard DM355, Gstreamer, LeopardBoard

We have been watching Vala for a while now. It’s a really cool idea (and if you have programmed GObject before you know what I’m talking about).

Well, we have finally spare the time to integrate support for Vala on the RidgeRun SDK, thanks to the support by the latest automake version. This allow us to easily write vala code for the target platform and the SDK will take care of the cross compilation (and proper vala bindings for the cross compiled libraries).

There are two main points where using vala will greatly speed our customers development capabilities:

• GStreamer: developing GStreamer applications is a lot easier if you use object oriented languages, but our experience so far using C++ bindings doesn’t provide the more elegant code possible, and when it comes to integrate it with other technologies like dbus, things start to turn complex. Vala could also be used to develop gstreamer plugins.
• DBus: doing glib marshals is a bit of a pain. Vala does dbus interactions as beauty as they should be.

Of course there are tons of other APIs where vala will help us that we haven’t play around yet (sqlite, clutter, WebKit, etc). We are really excited about the possibilities!

If you have never see vala code, here is a simple snippet of a gst pipeline for playing audio.

using Gst;

public void main (string[] args) {
    Element src;
    Element sink;
    Pipeline pipeline;

    // Initializing GStreamer
    Gst.init (ref args);

    // Creating pipeline and elements
    // NOTE: The return type of the pipeline construction method is Element,
    // not Pipeline, so we have to cast
    pipeline = (Pipeline) new Pipeline ("test");
    src = ElementFactory.make ("audiotestsrc", "my_src");
    sink = ElementFactory.make ("autoaudiosink", "my_sink");

    // Adding elements to pipeline
    pipeline.add_many (src, sink);

    // Linking source to sink
    src.link (sink);

    // Setting waveform to square
    src.set ("wave", 1);

    // Set pipeline state to PLAYING
    pipeline.set_state (State.PLAYING);

    // Creating a GLib main loop with a default context
    var loop = new MainLoop (null, false);

    // Start GLib mainloop
    loop.run ();
}

Gstreamer Gstreamer

Cristina has finished her graduation project with the Leopard board, and now we have (almost) completely AAC-LC and MP3 encode/decode support with the gstreamer plugin.

We have tested the encoders to properly generated standalone AAC or MP3 files, as well as muxplex them into a mp4/quicktime container format. The only remaining issue is related to the the encoders being unable to be used at the same time as the alsa capture driver (Cristina already ask Ittiam about the problem, but we haven’t got any feedback yet). In any case the issue is reproducible with Ittiam’s command line demo apps, so we don’t think is a gst issue.

As usual the beauty of a gstreamer solution is on the simplicity of the examples:

Encoding AAC audio into a quicktime container (two steps due the encoder bug):

gst-launch alsasrc ! audio/x-raw-int, width=16, depth=16,  endianness=1234,
channels=2, rate=44100, signed=true ! filesink location=/audio.pcm

 gst-launch -e filesrc location=/audio.pcm ! audio/x-raw-int, width=16,
depth=16,  endianness=1234, channels=2, rate=44100, signed=true !
dmaienc_aac ! qtmux ! filesink location=/audio.m4a 

Decoding the AAC audio from quicktime container:

gst-launch filesrc location=/audio.mp4 ! qtdemux ! dmaidec_aac ! alsasink 

Encoding AAC audio elementary stream:

gst-launch filesrc location=/audio.pcm ! audio/x-raw-int, width=16,
depth=16,  endianness=1234, channels=2, rate=44100, signed=true !
dmaienc_aac outputformat=2  ! filesink location=/audio.aac 

Decoding AAC elementary stream:

gst-launch filesrc location=/audio.aac ! aacparse ! dmaidec_aac ! alsasink 

Encoding MP3 elementary stream:

gst-launch -e filesrc location=/audio.pcm ! audio/x-raw-int, width=16,
depth=16,  endianness=1234, channels=2, rate=44100, signed=true !
dmaienc_mp3 ! filesrc location=/audio.mp3

Decoding MP3 audio:

gst-launch filesrc location=/audio.mp3 ! mp3parse ! dmaidec_mp3 ! alsasink 

The support for these features is available on DDOMPE’s branch, and will likely be available on the 2.0 release of the gst-ti-dmai plugin.

Enjoy.

Davinci, Gstreamer, LeopardBoard Education, Gstreamer, LeopardBoard