Archive for the ‘Uncategorized’ Category

New Tools For Using the DSP on Hawkboard

October 6, 2010

Last week, TI released two new software development tools that they hope will encourage more developers (especially ARM developers) to make use of the DSP on their ARM+DSP platforms (which includes the OMAP-L138 at the heart of the Hawkboard).

The first tool, called C6Run, aims to provide an automated way to compile and run code on the DSP core, without having to learn any new tools or APIs.  When programs built using these tools are run, from the target Linux system, the DSP is enabled, loaded and communicated with by the ARM.  Individual portions of applications, or entire applications can be executed on the DSP. Documentation for the tool is available on TI’s embedded processor wiki. This tool is also open source and is being developed on TI’s external subversion server.

The second tool, called C6Accel, provides pre-defined APIs to access the collection of TI’s optimized DSP libraries for their C6000 architecture.  As the DSP core in the OMAP-L138 is both a fixed-point and floating-point DSP, the exposed libraries include optimized fixed- and floating- point code.  The exposed libraries include simple math libraries, image processing routines, and optimized signal processing routinesDocumentation for this tool is also available on TI’s embedded processor wiki.

It will be interesting to see if ARM developers actually start making use of these to utilize the DSP.


HawkTawks Online Trainings on Hawkboard

July 2, 2010

Hawk Tawks:

Further encouraging development of innovative open source applications, and announced a series of “Hawk Tawks” webinars aimed at familiarizing both industry innovators and hobbyists with the HawkBoard’s wide range of end applications.

Three Topics and associated schedule are below

July 20th 2010 – 11 a.m. EDT/4 p.m. BST and 8 p.m. EDT/1 a.m. BST (8:30 PM India time)


“Introducing Texas Instruments’ OMAP-L138/AM1808 processor architecture and HawkBoard peripherals;
Embedded Linux porting on HawkBoard with booting and validating procedures”

Presenter : Jeff Cobb and Khasim Syed Mohammed, Texas Instruments

The OMAP-L138 SoC on the HawkBoard features a fixed-/floating-point C674x DSP core, an ARM926 core, and a rich set of peripherals. This talk will give an overview of the two processors and go over many of the on-chip peripherals. It will focus on the Programmable Real-Time Unit (PRU) and the Universal Parallel Port (uPP), two new peripherals found on this device.

The talks will also cover board bring up and demonstrate porting of Linux Kernel and drivers on ARM9 and working with all the peripherals on board with sample applications.
July 22nd 2010, 11 a.m. EDT/4 p.m. BST and 8 p.m. EDT/1 a.m. BST (8:30 PM India time)

Topic: : Developing and porting Qt applications on the HawkBoard

Presenter : Prabindh Sundareson, Texas Instruments

User Interfaces have become fundamental components, at the same time with more complex functionalities, to suit the needs of new emerging applications. To drive down the cost of development and to bring products to market faster, it is imperative to use standard frameworks like Qt, Android, X, and customize it to the needs of specific applications. To make the system more efficient and performance oriented, developers have to understand fundamental graphics layers of each framework. In this talk, we will cover the fundamentals of Qt framework, its programming model and tools, and performance benchmarking with Xgxperf toolkit from TI on target development boards like Hawkboard.

August 3rd 2010 – 11 a.m. EDT/4 p.m. BST and 8 p.m. EDT/1 a.m. BST (8:30 PM India time)

Topic: GStreamer porting on HawkBoard

Presenter:Todd Fischer, RidgeRun

Learn how to stream data through the DSP, using the ARM for control and data routing. On the ARM side, data exchange can be done using USB, TCP/IP networking, SD / hard disk storage, and audio / video connections. DSP algorithms that are XDM and XDAIS compliant can be built into a DSP based codec server. The iUniverse framework is used expose the codec server based algorithms to the ARM using the GStreamer streaming media library. GStreamer has many features (over 200 pipeline elements) so you can focus on your DSP algorithm and let GStreamer take care of the rest.

Hawkboard first steps… !

May 24, 2010

With all my experiences with IGEP and SheevaPlug I was ready for a new experience with an ARM board having a SATA connector. My desktop environment at home is totally ARM based. First I tried SheevaPlug being my desktop but I was not completely satisfied because of the instability of the USB based display. Then I tried IGEP which has proper display handling but when it does I/O on USB or SDHC it largely blocks the system. Finally I set up SheevaPlug to be my NFS server and I use IGEP from NFS root. I compiled a Gentoo system on the IGEP and this became a pretty usable system with acceptable performance. The story was almost done, but there was one point I couldn’t digest: the NFS perfromance. I connected a USB disk to SheevaPlug and it sees around 16MB/s. When it is exported to IGEP through NFS it goes down to 4MB/s. There are also issues with the USB disks power saving. These are the factors that made me curious about the Hawkboard .

More detailed Article here

ymodem transfer of the uImage file on hawkboard – By Gaston

May 18, 2010

———- Forwarded message ———-
From: Gaston <>
Date: Tue, May 18, 2010 at 7:39 PM
Subject: [] ymodem alternative for uImage and ramdisk transfer
To: hawkboard <>

Hi all,
My cross development base is a virtual Ubuntu 9.1. To be honest I dont
even know if it is possible to get to that machine from the host
network. Since I had to get a serial link up to be able to fiddle
around with uboot I searched for other options to get the kernel in.
There are several serial transfer protocols included in uboot. I
picked ymodem for its simplicity.
I will include my particular kernel in this example to highlight the
importance of size.

When the Ready signal is given I start the ymodem transfer of the
uImage file (I think it HAS to be named uImage)
————– > loady 0xc0700000 115200
## Ready for binary (ymodem) download to 0xC0700000 at 115200 bps…
CCCCCCCxyzModem – CRC mode, 2(SOH)/2396(STX)/0(CAN) packets, 9 retries
## Total Size      = 0x00256de4 = 2452964 Bytes

As you can see above the size is given both in hex and dec, very nice!

————– > nand info

Device 0: NAND 128MiB 1,8V 8-bit, sector size 128 KiB > nand erase 0x200000 0x256de4

NAND erase: device 0 offset 0x200000, size 0x256de4
Erasing at 0x440000 — 101% complete.
OK > nand erase 0x200000 0x260000

NAND erase: device 0 offset 0x200000, size 0x260000
Erasing at 0x440000 — 100% complete.

Some of these messages above confuse me, but no errors so lets

————– > nand write.e 0xc0700000 0x200000 0x256de4

NAND write: device 0 offset 0x200000, size 0x256de4
Attempt to write non page aligned data
2452964 bytes written: ERROR

ERROR, that doesn’t sound good, lets try a bit longer section

————– > nand write.e 0xc0700000 0x200000 0x260000

NAND write: device 0 offset 0x200000, size 0x260000
2490368 bytes written: OK

Now that seems quite ok, so now we have the uImage flashed to NAND at
0x200000 and the length is 0x256de4
I dont use ramdisk so I’ll leave that for you to figure out.
I use a sdram with two partitions, first for uImage (not used, but
soon(tm) we hope for a new uboot).
Second is my rootfs, so I continue to set some bootargs and bootcmd in

————- > setenv bootargs “mem=80M console=ttyS2,115200n8 root=/
dev/mmcblk0p2 rootwait rw init=/sbin/init ip=dhcp” > setenv bootcmd “setenv $bootargs;nand read.e
0xc0900000 0x200000 0x256DE4;bootm 0xC0900000” > saveenv
Saving Environment to NAND…
Erasing Nand…
Erasing at 0x0 — 100% complete.
Writing to Nand… done >

This part above have more or less copied from another post here and it
has a typo in it, just ignore the error message on the “mem=80M”
mem=80M (or something smaller than 128M at least) needs to be passed
to the kernel in order to get DSPLink to work.

For completeness this is the endresult of my uboot-environment
———— > printenv
bootargs=mem=80M console=ttyS2,115200n8 root=/dev/mmcblk0p2 rootwait
rw init=/sbin/init ip=dhcp
bootcmd=setenv mem=80M console=ttyS2,115200n8 root=/dev/mmcblk0p2
rootwait rw init=/sbin/init ip=dhcp;nand read.e 0xc090
0000 0x200000 0x256DE4;bootm 0xC0900000
ver=U-Boot 2009.01-dirty (Nov 18 2009 – 23:30:48)

Environment size: 435/131068 bytes >

I hope this inspired someone out there!

Using VPIF input on hawkboard from Caglar…

May 10, 2010
I found this discuss and the method useful for all hawkboard users. Just logging here. I am waiting for DSP side code, will update this blog when I upload other sources as well.
> Caglar,

> Can u share the information regarding how to make composite video work in
> hawkboard.

Sure, but it’s a little bit picky though. Here is what I did to make it work:

I downloaded sources for kernel coming with Angstrom [1]. Kernel version
is 2.6.33-rc4, I guess it is the PSP kernel.

This kernel was supporting VPIF input and output out of the box, moreover
associated filesystem was creating /dev/video0 node automatically. However, in
my experience TVP5147 driver was a little bit buggy(due to noise I guess)
so it wasn’t detecting camera standard. Then I patched my kernel with the
attached patch to solve this issue.

Next trouble was color space conversion. VPIF was giving data in NV16
(two plane YUV) format but LCDC was expecting an RGB data. This was a little
bit problematic for generic players; for instance gstreamer v4l2 plugin was not
supporting NV16 and mplayer was unable to detect the format. So I wrote my own
program to do the following:

*  Grab a frame from V4l2 driver
*  Convert color space from NV16 to RGB565
*  Copy buffer to framebuffer memory.

But this was not enough as framerate was not so good. So I modified Codec
Engine video_copy example to utilize DSP and that way I offloaded color space
conversion to the DSP. This gave me a beautiful 25 fps from my camera.

Currently I don’t have any appropriate place to upload my example codes but I
can share them with anyone interested. Actually binaries can serve a good
purpose for anybody want to give it a quick try on their board.

Best Regards,



— kernel_source_original/drivers/media/video/tvp514x.c        2010-03-18 14:33:44.000000000 +0200
+++ kernel_source/drivers/media/video/tvp514x.c 2010-05-07 00:46:05.284494625 +0300
@@ -741,8 +741,9 @@

–       if ((current_std == STD_INVALID) || (try_count < 0))
–               return -EINVAL;
+       if ((current_std == STD_INVALID) || (try_count < 0)) {
+               current_std = STD_PAL_BDGHIN;
+       }

decoder->current_std = current_std;
decoder->input = input;

October 3, 2009

Here I give the most awaited details of board. Probably in next two weeks I plan to host a page on elinux to track early adopters of this platform.

The cost is still getting reviewed, so please don’t rush on the same.

Sorry for frustration

October 2, 2009

Hello all,

I am really sorry frustrating every one by not giving the details about the platform.  The board has come along good, I don’t find any issues in bring up Linux kernel and have tested all peripherals on board.

We have finalized the cost and distribution channel. The biggest problem for the hawkboard team is in arranging all the required chipsets or components, due to lead times in getting these components we are seeing the availability of board only by end of February 10.

We will get few boards by early November which will be delivered to early adopters and MCU day registered users interested in this platform.

For world wide distribution we still need more time.

sorry for all the delays, will keep you all updated with the proceedings.



Coming Soon …. !

September 9, 2009