We are glad to make available our evaluation SDK for the AM35x EVM board.
RidgeRun SDK offers an integrated build system for this platform, with a proved solution for reliable product development and deployment, integrating the greatest of open source software and our know-how for TI SoCs.
Our Professional SDK includes support for advanced 3D User interfaces with QT and Clutter.
Check our download center.
TI is putting out codecs for the DM365 faster than we can supported in GStreamer 
.
Now you find mpeg2, VC1, AEC, mp3, aac, wma codecs for DM365. Thanks to the work we did in the past for the Leopard DM355, we were able to adapt gstreamer-ti DDOMPE branch to support the AAC codecs for DM365, and unlike the DM355 this codec doesn’t froze when you try to encode along with alsa. So encoding aac audio is as simple as:
gst-launch -e alsasrc ! dmaienc_aac ! qtmux ! filesrc location = test.m4a
This generates files that can be playback with quicktime or any standard media player. The properties of the plugin also allow to configure the encoder to generate the proper streams if you intend to do network streaming.
Audio decoding isn’t working out of the box as we need to implement some code handling for extended arguments on the decoding side (replicating the logic we have for encoders).
We have improved RidgeRun SDK for DM365 platforms to support automatic download and compilation of the AAC codecs if the user selects it (without requiring manual intervention). If you are looking into using the mp3, wma, aec, mpeg2, or VC1 codec in gstreamer, talk to us, we can make that happen.
We are happy to introduce our own YouTube Channel.
This channel will be used to post videos on trainings, or demos we have. You can see, we already have some videos showing GStreamer daemon technology.
Enjoy.
We have made available our SDK for the LeopardBoard DM365.
This is a beta release since the quality of the drivers and functionality is still subject to much improvement. However we wanted community users to have something to get started as soon as possible.
In our developer site, you will find the documentation with the current know issues, and the work plan for fixing them.
Enjoy.
We are happy to introduce our new RidgeRun Developer Connection site.
This wiki will provide updated documentation, whitepapers, release notes, regarding using RidgeRun technologies. We also use it as the basis for documenting some of our research and development projects, allowing people to try out the latest we are working on (if you are brave enough!).
The wiki is open only to RidgeRun developers for editing at this point, but we hope that will change on the future as the sites matures. If you feel you can contribute, let us know and we can provide you editing access.
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).
We are glad to release an Evaluation SDK for the OMAPL138 EVM/experimenter board.
This Evaluation SDK allows people to evaluate the capabilities of RidgeRun’ SDK software integration on the EVM hardware. Our highlights are:
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 Evaluation SDK for OMAPL138 EVM from our download center.
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.
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.
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.