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:

http://www.hawkboard.org/hawktawks

Further encouraging development of innovative open source applications, HawkBoard.org and element-14.com 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)

Topic:

“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 test

June 2, 2010

Hawkboard + Angstrom unstable + custom kernel with serialusb support.

Vodpod videos no longer available.

more about "Auzie shows apache on hawkboard – goo…", posted with vodpod

Hawkboard first steps… !

May 24, 2010

http://dbeck.beckground.hu/articles/2010/05/21/hawkboard-part-1/

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 http://dbeck.beckground.hu/articles/2010/05/21/hawkboard-part-1/

ymodem transfer of the uImage file on hawkboard – By Gaston

May 18, 2010

———- Forwarded message ———-
From: Gaston <gaston.dsp@gmail.com>
Date: Tue, May 18, 2010 at 7:39 PM
Subject: [hawkboard.org] ymodem alternative for uImage and ramdisk transfer
To: hawkboard <hawkboard@googlegroups.com>

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)
————–
hawkboard.org > 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!

————–
hawkboard.org > nand info

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

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

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

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

————–
hawkboard.org > 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

————–
hawkboard.org > 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
uboot

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

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”
stuff.
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
————
hawkboard.org > printenv
bootdelay=3
baudrate=115200
bootfile=”uImage”
ethaddr=0a:c1:a8:12:fa:c0
filesize=256DE4
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
stdin=serial
stdout=serial
stderr=serial
ver=U-Boot 2009.01-dirty (Nov 18 2009 – 23:30:48)

Environment size: 435/131068 bytes
hawkboard.org >
————

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,
Caglar

[1] http://www.angstrom-distribution.org/narcissus/

____________________________________________________________________________

— 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 @@
break;
}

–       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;

break the ice …!

October 8, 2009

Thanks for all the interest shown regarding this project.  I am hereby trying to answer some of the questions being asked on different forums, hope this helps and gives some insight.

What is hawkboard.org?

A Open Community Portal for OMAP L 138 – An ARM 9 and Floating Point DSP C674x Application Processor.

Who is driving this initiative?

Mainly Khasim Syed Mohammed with the help of a very energetic and small hardware engineering team called Innovate Solutions with all directions and inputs from a simple and straight beagleboard.org community.

Is this a TI internal project?

No, it is not associated with TI.

Are you copying beagleboard.org ?

Yes, we think beagle board has met community expectations and we are proud to follow beagleboard directions.

Is Gerald Coley or Jason Kridner part of this project ?

Yes, they guide and mentor us

Why not are you associating this beagelboard.org itself.

This initiative does involve the beagle community and is already engaged with them, before we started this effort we discussed about the same on beagleboard mailing lists and IRC and took a opinion poll. So this project is kicked of from beagleboard.org

Then why another name and logo ?

I learnt this from Jason Kridner, giving board a name of website is really good for everyone to get along to know about the product that is the only intention of having a .org associated with the board. But it will also help us in turning this up as a portal for deliverables.

What is the focus or objective of this project?

While I was talking to Gerald Coley he mentioned “the job of DSP is to make ARM better”. I have been in Linux community for a while but when I need to get along with DSP, it really gets tough. The OMAP L 138 is a great and very simple processor, the register set is so simple that any one can start learning about the Linux drivers for any kind of peripherals. I think we as Linux developers need to learn DSP usage and not programming the same and the DSP developers should learn how to program DSP so that ARM can use this. So, its all about ARM utilizing the power of DSP.

When TI has so much software around DSP what’s new in this ?

We are going back to basics, a team of DSP programmers and Linux developers have joined together in learning how to program and use DSP from ARM. While the device will support all of the TI software (DSP Link, Codec Engine, iUniversal, Codecs, DMAI, etc) we are looking forward to start from scratch with hellodsp.c

Are you going open?

Yes we are … give us some time. The team involved in this are doing there regular work at different organizations and still want to work on this project on the side. So we try our best to get some bandwidth around this initiative.

Why did you choose OMAP L 138 a ARM9 processor ?

We need a simple ARM to learn DSP programming. Moreover the DSP in L138 processor is very powerful as it can do all floating point operations and can run at 300 Mhz.  Having  a floating point DSP around will enable us to use tons of DSP algorithms developed across the range of DSPs in the world also gives us an opportunity to port alogrithms running on ARM and x86 in a much easier way.

When is this board available for purchase ?

We have around 5 prototype boards today, we are planning to make a 100 more by end of this month, once we have them we will start an early adopters program on elinux wiki, get boards in hands of real users of this platform. TI has also placed an order for boards to serve the MCU days participants not sure how many of these can go to TI.

Who should buy this board ?

If you are a TI customer who wants to do a serious product in definite time line with lots of TI support from its sales and field then you are on the wrong channel. For such serious businesses we prefer you use the TI EVMs.

This board is meant for learning and programming ARM9 and Floating point DSPs by sharing our knowledge – a open community way … !

Are you not promoting TI DSPs with the help of Open Community ?

Yes and No. We know DSPs for ages and we also know that you think about a algorithm the source is there in Open on some site. But we cannot use this as we don’t know how to use the same from ARM or Linux and the algorithm was developed for single DSP core with CCS. Just as an example, consider I want to use a compression and decompression logic, we know DSP can do better and we also know there is source available for DSP, but being a ARM Linux developer how do I use it – not sure. We need to fix this, DSP is not all about Codecs, it is about processing.

But then why can’t TI fix this ?

TI DSPs are generic and can be used for multiple applications, TI has frameworks like DSP Link, Codec Engine, iUniversal to try the same and address multiple segments, but we need some thing more fundamental to experience the DSP and an easier way.

TI processors are rich in multimedia and processing and it is responsibility of TI to define products for next generation and that is where it is going towards, but the next generation products can’t be simple they are going be and have to be complex example the Davinci and OMAP3.  But for our objective to be met we need a simple processor and tools to use the same.

TI helps us by delivering these in open and free. The cross compilers for DSP are free, the xds 100 emulator schematics are open, CCS is coming free, tons of DSP algorithms  are open.

So is this initiative all about DSP and no room for ARM ?

We know ARM9 is not new –  OMAP L 138 can drive ARM at 400 Mhz max, with the set of peripherals on board like SATA, Ethernet, Composite In and VGA – it is a dream come true for ARM developers who want to do media (audio / video) streaming and storage applications. This platform is more expandable as it offers PWM with a dedicated multi-channel PWM controller in processor, PRU a programmable controller that can be configured to be anything like a CAN controller or UART controller, high speed parallel port for connecting to FPGAs and lots of GPIOs and SPI and Video port interfaces. In my opinion we already meet the expectations of ARM community and looking forward to work closely with Linux ARM community in leveraging the benefits of a Open ARM9 platform. But the ideal objective is get the other guy going the way we “Linux ARM” community want it to be…

What about the cost of the board?

The end price of the product is still not fixed as we don’t have a global distributor signed yet, it all depends on what margin a distributor will expect, it looks odd inspite of all the hardwork we need to pay some one extra money to get the product shipped to all parts of the world, but we cannot help or managing it and they are better in that. As far as I think it should be around 79$ and if we get hit by distys it can go near 85$. Definitely not more than that.  In India this should be available for Rs 3750 /- and In Europe not sure as we have to work out the shipping charges. If some one wants to be our distribution partner we are open to this with all open terms and conditions.

Lets learn …! and feel free to mail me on khasim@beagleboard.org

October 3, 2009
hawkboard.org

hawkboard.org

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.

Regards,

Khasim

Coming Soon …. !

September 9, 2009

hawk_logo1