Midnight musings of a system gone wild

Interesting view presented here. How can we create software to handle situation where DRM (an unfortunate necessity in an imperfect world) is here to stay? Embedded systems such as mobile phones are essentially a close co-operation b/w h/w and software in a scale rarely seen before. It is one hell of a complex system. A thought that says let do virtualization layering, where the critical components (read IP) are kept layered out from the rest of the system. In the day when mobile phones are reaching and will some day cross the traditional desktop computing power, the overhead paid by these virtualizing layers are low. We could have something like an hypervisor running OS of our choice while being blissfully abstracting all the legal and technical woes away. We do today maintain an heterogenous multiprocessing system. And this does allow virtualization to take place to an extent. Probably the way to go might be massively parallel systems, where each system is independent of the other and may be termed as an "expert system".

Traditional OSes fail in respect of working in a heterogenous parallel processing systems as in an embedded system like mobile phones. There are many reasons for it:
a) IP blackholes: some parts of the system give the vendor a competitive advantage in the market that they would rather not loose. The net result is that even if an OS desires, it will not be able to control such a system.
b) inter processor communication: in a cluster or a generic "PC/Server world" the communication is limited only by the link media-optical networks etc. Think within a mobile phone - custom buses talk between peripherals, processor components have a lot more to handle other than link being the bottle neck.
c) Multi expert systems: traditional OSes think in Master-Slave in terms of App processor -> peripheral relationship. when you have multiple processors specializing on various tasks, we probably need a OS which has a wider abstraction.
d) Traditional applications are designed for limited use of multi-processing capability.
Thinking as we do now, we probably will end up in a bottleneck in years to come. What might be needed would a "OS" which is system wide - not just on an ARM in one corner of the chip. Applications are a usecase for the entire chip - it needs a co-ordinated system functioning in perfect harmony. probably virulization might be the answer, or perhaps a new breed of programming language, compilers, OS and applications and probably even a new breed of design methodology to exploit this interesting new phenomenon is the need of the hour..

Just musing...

pwm dimming and others

PWM dimming is done on certain LCD displays. here is an article which gives some fundamentals on this.

and here is an article on modulation.

Now here is some data on JESD204 std for serial comm.

on cellphone front, this article speaks about energy scavenging phones. I guess it'd be interesting to convert body heat, body movement back into energy, thinking of it, there are multiple opportunities:
a) body movement (peizo)
b) body or component heat/ temperature differences(thermocouple)
c) light (e.g. sunlight) (photovoltaic)
d) pressure (peizo)
e)(ok this is a bit fetchy..) crossing magnetic field of earth..
f) electromagnetic noise (I mean there are tons of devices throwing out wireless energy around rt? what if other devices can convert that back to useful energy if the signal is not meant for them?)
g) barometric pressure differences?
Ok I seem to have run of ideas for the moment, but hell yeah! why just cellphones, probably is energy scavenging or energy "recycle" going to be the next wave? There seems to be lots of "philosopher stone science" involved at the moment, but is it really far fetched as it looks like? every device has an unique environment it can adapt to. Just like the naturists say - live in harmony with the forces.. if we could apply that concept to the devices... would it not be fun? How about using the natural degeneration to power ourselves back up.. why do we still look at nuclear power with fear(different thing that every year i am proven wrong by some power plant issues somewhere).. but then, would we have even thought about power management if nuclear power was available in a cellphone? hell! we'd be running penta-core intel processors on cellphones (if it was not for the heat ofcourse ;) ). but, we get the picture..

Probably we need to think wider.. what new human interface technology has come into the market the past few years? multi-touch touch screen? we need a break through in that front, so do we need in many other fronts..

freescale and multicore processors

This article was pretty interesting PowerQuicc Dual-core, 4 Watt consumption and they also speak of a 8 core consuming <30W. Interesting indeed.. some route our processing needs are taking..

Linux "Embedded" maintainers

David Woodhouse(MTD) and Paul Gortmaker (Windriver, Network dev)
More here and here

The usual flow for OMAP patches has been: dev ->Tony->Russel->Linus. How does this new flow change it? there is a new mailing list. interesting musings..
As the quote goes:

The maintainer's job would involve an architecture independent appraisal of the embedded code and generally keeping the code in good working order.

Just like a big bunch of guys in this thread, I wonder how does is it all going to work...

some nand-nor basics

Thanks to my boss, here is an article which gives some basics.. it speaks of convergence technologies and fundamentals. There is lots of emerging techologies such as MCL NAND based devices which expose MMC interface to host, etc..

Reversing the U-Boot's kermit protocol

See http://code.google.com/p/omap-u-boot-utils/ for Code and binary details.
Background:
Few days back, I had written a app which came from a need to be able to script download operations to U-Boot V2. Now, that I have a bit of time on hand.. here is the detail for supporting an app for kermit for U-Boot. Of course, you are free to read ckermit code, or pay up some well deserved money for kermit95.. but there is something called as gkermit(also from columbia univ) which is GPLed. There is also something called as ekermit which is kinda neat.. You can find Loadb here. For me personally, drawing the sequence of code as implemented by loadb was enough and did not require looking at the massive code base of gkermit.

Details:
Kermit protocol in it's simplest form is described as a transmission followed by a end of transmission character. Each transmission consists of multiple packets. Each packet can be a session initiation, data packet or many other packet types. The app I wrote supports only sending data packets. So, it is not complete on it's own, but this is fine, since U-Boot cares only for data packets.

Every packet is an individual entity of it's own. Every packet has a start and end packet marker. Data packets come in two flavors - large packets and small packets. Small packets are simple, but large packets is better for performance reasons, but, it depends on the kind of link you got.. if it is a pretty reliable link, you'd like to send large chunks of data and then retry them all over again... Data packets have their own header. Following the header, there is a bunch of data bytes which end with a CRC and an end character.

The control characters in the middle of data bytes could create confusing state for kermit protocol, hence the control characters are specially encoded by the protocol. encoding is simple: An escape character(#) is prefixed to characters which are specially encoded. The encoding is an XOR with 0x40.

If the reciever gets the packet properly, it acknowledges the receipt of packet. If a NAK (negative acknowledgment) or the recieved ack packet itself is corrupted, the transmitter retries the old packet.

The packet sequence number allows for the sender and receiver to keep track of the packet flow sequence.
Examples of packets:
Large packet:

unsigned char start;
unsigned char length_normal; /* =0 if the large packet is used */
unsigned char sequence_number;
unsigned char packet_type;
unsigned char length_hi;
unsigned char length_lo;
unsigned char header_checksum;
unsigned char data_bytes[length];
unsigned char CRC;
unsigned char end;

Small packet:

unsigned char start;
unsigned char length_normal;
unsigned char sequence_number;
unsigned char packet_type;
unsigned char data_bytes[length];
unsigned char CRC;
unsigned char end;

Ack/Nak type packet:

unsigned char start;
unsigned char length_norm;
unsigned char sequence_number;
unsigned char packet_type;
unsigned char checksum;
unsigned char end;

Conclusion:
Of course kermit adds up extra bunch of bytes to the data stream.. but it is application independent, allows retries and in general pretty darn reliable protocol. Now, if you are using something like a serial cable, you better have something like kermit protecting your data, but in the case of USB and the like, where the protocol layer itself does the error correction, you probably dont need this.

Free TI DSP C64x compiler for Linux

Thanks to Dirk Behme, this news is very interesting.
Here is the link to the discussion and here is the link to download.

PREDICT II online

Finally.. after years of being on my backup CD, my MCA final year code is online.. http://code.google.com/p/predict2/ is where i have hosted it. GPLV3 :)..
The project is a silly thing when I think back now.. it is 6+ years old now, java based anonymous electronic cash protocol which (yeah, you guessed it), I designed..... implementation doc report is here and the project overview here
A Warning though: the code did not compile in the 5 mins i tried.. probably JDK1.3 is so pretty darn old.. more probably with CLASS PATH issues..

if any one wants to maintain it, folks are most welcome :) mebbe move it to 2008 era!! am no longer an app guy :(

CV -> Ubuntu style!

After 6+ years, on a whim, I have finally decided to research how to write my CV :).. it is one of those things I never like doing.. so to prep up things.. I setup some requirements:
a) It should be easy to type in and maintain.
b) I will not use Windows, abiword, openoffice etc.
c) It should be portable output-pdf is good..
Entrez Latex

Step 1: Getting the packages.: sudo apt-get install texlive-base-bin texlive-latex-extra texlive-latex-recommended latex2rtf groff latex2html
This gives you the CTAN resume.cls which is kinda neat and looks like it makes life lot simple.

Step 2: looking for ready templates:
a) Jason Blevins has posted a nice CV template gives an output like this. From this page, linked to this - resume style.
b) Mathew Miller's CV Template gives this output, but looks more academia.
c) just google for latex cv
Just choose the stuff you'd like.

Step 3: write the stuff..
Well.. the main thing is lots of folks have done this :)... and other than writing the material, fonts and other funny stuff is not anymore of a bother(just telling myself.. it is not as tough as I think it is..) ;)

Horrah!!! First OMAP Uboot V2 support merged to mainline

Thanks to Sascha.. http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-v2.git;a=summary has U-Boot V2 support for SDP3430 merged.

This weekend, will provide support for Beagle, zoom MDK and send out patches..

I am meanwhile plodding thru i2c arch from kernel to pull into u-boot v2. + point.. Existing i2c drivers should work with small effort on U-boot v2. There is a bunch of other stuff to do:
after i2c, USB, NAND, MMC, NOR, etc...