Sunday, May 27, 2007

Friday, April 20, 2007

SlingBox client on N800/OpenMoko - A wish

Hi SlingMedia,

I am taking an opportunity to put my message to SlingMedia (Blake?) through my blog to have the client for their Sling* products on GNU/Linux.

As of today (AFAIK), Sling do provide/announced in beta stage the clients for Symbian (S60 based devices), MaC OS, WinCE?? and ofcourse Windows Vista premium and other Windows desktop versions.

I am sure that they are aware of the usage/users of GNU/Linux basically Ubuntu/Debian/RedHat/whatever on Desktops/Laptops/Internet Tablet(N770 and N800 etc) and now coming MID UMPCs specifically as announced by Intel recently. Due to this recent movements, specifically in Embedded Linux + GMAE it makes sense to have or put thought across the Sling management to start developing (again google like beta :)) the client which can run on GNU/Linux desktops as well some of the embedded devices.

It is almost easy to understood that one will find more smart mobiles loaded with S60 and WinCE as of today compared to Linux with sufficiently big screen and so does Sling addressed those OSes based clients, but is there any effort/roadmap Sling is willing to try on Linux based desktops/handhelds?. If we believe that some of the recent research reports for OSes which will penetrate more in smartphones in coming years, then Linux clearly looks likes a winner, with WinCE still leading the race.

It will be not be that easy to move those clients development on GNU/Linux, looking at choices/offerings we have in GNU/Linux world.

* Let's start from the MMI (Man Machine Interface):
- Our world is divided into KDE/GNOME, so the first task Sling has to decided on the graphical framework which can build and satisfy their MMI requirements. Looking at the some of the demos of SlingBox, I don't see that they have very much high requirements in terms of rendering engine - You don't won't iPhone like GUI isn't it.

- Client from the GUI/MMI viewpoint is divided into the controller (remote?) and typical media player, which doesn't demand any fancy stuff, and can be adjustable to N800/N700 kind of screen very well.

* Multimedia Framework
- I am sure that Sling can pick up their internally developed frameworks wherever required as first choice for re-usability and to reduce effort in porting.

- Using GStreamer and adding their plugins on top of it is a good choice, but considering the size of company I don't see that Sling will try to venture into this world at this stage.

* Licensing
- Not to worry much as they are just dealing with client only. But using GTK+ will be better compared to Qt/E. I am sure they don't won't spend time understanding dual licensing. As most of the component there will be covered under LGPL.

* Other middleware components:
- I am sure these all will be sourced from WinCE/Symbian/Mac based client, which should be easily portable on Linux and will remain closed.

Ideal platform:

- MMI Development and early porting can start with x86 PC running Ubuntu/RH/Fedora and later can be ported to ARM based devices like N800/N700/OpenMoko. Here they will benefit if they use GTK+ as framework to develop their MMI as all three platforms use GTK+ for their applications development. Again it is easy to test MMI and early development for Nxxx and OpenMoko using qemu, so there is no cost involved in procuring the test devices.

- In future this success can be carried easily to Access Linux Platform based mobiles, which should become reality at the end of next year.

- Yes, but sling might have to manage releasing .deb and .rpms to satisfy most of Ubuntu/Debian and RH/Fedora users.

OLPC Laptop: I have received this laptop couple of weeks back, but I have not started any development on that. I have some plans and things to make working on OLPC. I will post photos of this laptop and new perfact N800 leather case I found in Gangaram's book house at MG Road.

Thursday, February 22, 2007

N800 Received Today !!!

I have received my Nokia 800 today. Thanx Nokia. Right now downloading Canola Player and few e-books to it. I already have 2GB miniSD card from my Nokia N73 ME, so I don't need to buy new one at least for some time.

Friday, January 26, 2007

Hurray !!! Received N800 Discount Code

Thanx. Nokia and Nokia Maemo Team...Oops, it should "Maemo Coupon Team". As there is no webstore facility available for India, I need to order it using my friends in Finland and US. I just need to talk with them and initiate the process to bring N800 to Bangalore, India.

Dirk, Did you received that discount code?

But, it is very pity that, even though Nokia having its Development Office and very good customer base in India, still they don't have webstore facility for N800 for India. Please make some arrangements for it. As it is "true" that whatever new IT technology related device comes out after 2005-2006 from US/Europe, there must some Indian tag attached with it, at least one quality assurance guy from Wipro/Infosys/TCS/Sasken will be in your team.

OMAP3430 - I will be receiving it soon. BTW, I have seen the EVM circulating in few multimedia companies in Bangalore. So expect someone posting patches for it on omap mailing list soon. Also you will see custom boards based on OMAP3430, as people started getting chips for it :)

IVA - Just one BIG note: - N800 doesn't use IVA1.0 for MPEG4-SP/H.263/H.264, so don't expect very good multimedia capabilities from it. Audio/Video Codecs either run on DSP C55x or ARM11. And there is _NO_ chance that you will see MBX gaming engine support, as Imagination Technology will never open the specs and driver for it. No problem, we don't need another Ngage from Nokia :)

Friday, November 17, 2006

Are we open enough?

Well, the question above was probably asked in different way by Ari Jaaksi to Linus Torvald, and Linux replied with "Next time may be Samsung/Siemens or someone else will be more open...and it will continue", and I think might answer it better once it becomes reality in January'07. Well, watchout OMAP guys, they have Samsung single-core chip and may not have to worry about the DSP/IVA1/2 gateway.

Siemens SX1(OMAP310) port code(
is now available at site, posted by Pavel Machek, and looks like it will make to -omap tree soon. I believe that we have now highest no. of supported board variants for OMAP1/2 series of chips. Total of 15 (12 for OMAP1 and 3 for OMAP2), and soon will become 16. I hope this may be good reason to fight for less #ifdefers and push our drivers to upstream, starting with fb.

And don't forget to visit and try to search in google to know probably the founders and where N-OMAP guys are nowadays.

--- - Hmm..Finally moved from Yahoo to Google Mail account, as Yahoo search was really slowing down on my Inbox, with Inbox count no. fixed to 65535, evenif my inbox was having more e-mails than that :). I had also exceeded 1GB quota. I will continue to check my yahoo account, but I will unsubscribe most of the mailing list from that account, and transfer it to gmail one. So, please use my new account id for any queries. Thanx.

Thursday, October 05, 2006


Linus had released 2.6.19-rc1.

All the drivers mentioned in the earlier entry of "Arr !!! Linux 2.6.18" are pushed except "IrDA driver". I have sent an e-mail to lkml and Samuel about it.
[update: IrDA driver will be pushed to "netdev" tree. Thanx Samuel]

Not much updates on dspfs and IVA DOFF stuff. Hey but some good signs of working doff loader.

- Need to verify that which COFF versions are supported by current Nokia-DSPGW. Does it support COFF files created by CCS 3.1 or higher, as it seems that sections header is changed in new COFF version. Looks like variable section name length ?

No DaVinci work again, as will not be able access the board for few months from now :(.

But let's plan to move new re-organized mailbox fwk code into the dspfs, and something like task-bridge (it looks like big effort...not much clarify as of now...will write later on that).

Wednesday, September 20, 2006

Arr !!! Linux 2.6.18

Finally Linus had released Linux 2.6.18.

Following patches of drivers will be available in linux-2.6.19-rc1:

1. smc91x support for H4.
2. OMAP Keypad driver
3. OMAP watchdog driver
4. OMAP I2C driver
5. OMAP IrDA driver
6. OMAP RNG driver, which actually builds :-).

I have _not_ tried to submit menelaus driver to upstream, as I had shifted my focus to DSPGW re-organization, dspfs and IVA DOFF format.

DSPFS is now available for public, please see the recent announcement e-mail to OMAP mailing list.

IVA DOFF format (Dynamic Object File Format):

- It is a properietary file format developed by Texas Instruments. Most of the multimedia companies _now_ releases there algorithms running on DSP/IVA in this format.

For unknowns, CCS (Code Composer Studio) produces the output file in COFF (Common Object File Format) , and _some_ magic TI tool converts that COFF to DOFF file.

You can easily compare the size of the both files, and DOFF is stripped down version of COFF with internal re-organization of COFF such that, you can improve the loading time of images.

It seems to be very easy to write down DOFF parser and loader if you hae doff.h from TI :-). But you may not be able to release that code until TI agrees to publish that file to public under _some_ license.

Writing the IVA/DSP DOFF Loader:

It is very easy under dspfs, as you can simply expose the internal memory as mmaped files to application. In case of IVA it might look like this:

|-- c55x
| |-- codecs
`-- iva1
|-- codecs

intmem - 128k IVA internal memory
copmem - linear 39k co-processor memories including image buffers A and B.
shmem - Shared memory in SDRAM

Now, once you have image data available and know what is the target load location, you can then "memcpy" into above memories, after mmaping it :-).

Sounds trivial, isn't it.

Please e-mail me to if you want to hear/contribute some more ideas on bridge driver.


But why can't we load CCS generated COFF file then? As this format is widely know to people, and it will be easy shared the code/loader/parser written for it. Like current Nokia-DSPGW distributes DSP dynamic loader along with coff.h files, and I am sure we don't need to ping TI for DOFF then.

I am going to have look at this coff.h files, and try to write parser/dump tool for it first, as it will be easy to just load the data to target memory afterwards, I will keep posted.

DaVinci updates:

1. I2C cleanup driver submitted and pushed to davinci-git tree.
2. Started MMC cleanup, but didn't go far, as I need to understand EDMA architecture. As of now, it looks like that I may not able to give more time to DaVinci for few weeks.