Nishanth' tech rambles

So we hit the next gen

2012-01-13T06:59:00.001-06:00

Texas Instruments demos first OMAP 5, Android 4.0-based reference design, promises it in laptops next year (video) -- Engadget

firewall on N900

2011-02-03T14:45:00.006-06:00

Grr my first post of this year and I plan to start "I confess: I am a paranoid". what the heck, lets go with it:

I confess, I am a paranoid. I carry around my N900 all the time and thanks to my job, I end up in different continents at times. with my primary SIM connection, international data network tends to around 15$/MB which I don't really feel like paying, so I either choose a local SIM (If I am around for that long that deserves it) OR more likely to use WLAN in the hotel or guest network I am allowed on. I don't like wlan network in general other than the one I personally setup. and hence dont like the thought that my phone's network services are open for all on wlan0 device :(. This triggered my search for something quick and simple firewall. I think of it more or less as a basic password I'd setup on my laptop of a phone unlock code or lock my car when I step out of it - it can be counteracted, but what the heck, some one has to see it worthwhile the effort to do it (and I don't personally think I am worth that effort ;) ). Anyways, back to code..

Maemo wiki(search for the word firewall) unfortunately tells me dubious statement "Maybe not". on a phone data network, I am reasonably sure that the 3G provider really does'nt want to pay for people running nmap on other people's phone - I guess they are pretty serious about it, but unfortunately most wifis contain machines which are already compromised - the users really dont control their PCs anymore.. and my poor phone has to share the world with them as well.. (Disclaimer: I did say I am a paranoid, ok maybe a little bit paranoid).

Since even "ET call home" does'nt really need my phone to run Apache server or an SMTP server, I dont need a complicated firewall setting. I needed something as simple as gufw
yes OR no.

Since I am never the first to look for something, bit of googling later, found this
few customizations for this script I setup the following with the N900 power kernel:
Note: for what ever reasons, N900 default kernel on PR1.3 does'nt come with these modules in /lib/modules/`uname -a` :(

~/bin/fire:


#!/bin/bash

set -x

# Load needed kernel modules

modprobe ipt_MASQUERADE
modprobe ipt_NETMAP
modprobe ipt_REDIRECT
modprobe ip_tables
modprobe ipt_REJECT
modprobe iptable_filter
modprobe iptable_mangle
modprobe iptable_nat


# Clear any existing firewall stuff before we start
# TODO: really not secure thingy- might wanna do REJECT rules before this..
iptables --flush

# As the default policies, drop all incoming traffic but allow all
# outgoing traffic.  This will allow us to make outgoing connections
# from any port, but will only allow incoming connections on the ports
# specified below.

iptables --policy INPUT DROP
iptables --policy OUTPUT ACCEPT

# Allow all incoming traffic if it is coming from the local loopback device
iptables -A INPUT -i lo -j ACCEPT

# Related and established connections: see
#  http://www.sns.ias.edu/~jns/security/iptables/iptables_conntrack.html
#
# Accept all incoming traffic associated with an established
# connection, or a "related" connection
#
# This will automatically handle incoming UDP traffic associated with
# DNS queries, as well as PASSIVE mode FTP (provided the
# ip_conntrack_ftp module is loaded)

iptables -A INPUT -i phonet0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i wlan0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i wmaster0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow connections on selected ports to the firewalled computer:

# Logging: first, eliminate any packets that are going to broadcast
# addresses, since they will overwhelm the log files if there are any
# windows computers on our network. Also, don't log pesky multicast
# packets that we block.

iptables -A INPUT -d 255.255.255.255/0.0.0.255 -j DROP
iptables -A INPUT -d 224.0.0.1 -j DROP

# Log all other blocked packets, and change DROP to REJECT to be
# polite and allow people connecting to a blocked port to receive a
# "connection refused" message instead of timing out after 30 seconds.

#iptables -A INPUT -j LOG
iptables -A INPUT -j REJECT

And the reverse: ~/bin/nofire


#!/bin/bash
set -x

# Clear any existing firewall stuff before we start

iptables --flush

# A dumb set of steps - just being explicit here..
iptables --policy INPUT ACCEPT
iptables --policy OUTPUT ACCEPT

I then added desktop command execution widget to basically use call firewall ON and OFF with a dumb command of /bin/bash -c "/usr/bin/rootsh /home/user/bin/fire" for firewall on and /bin/bash -c "/usr/bin/rootsh /home/user/bin/nofire" for no firewall - activated only if I click on it.

Anyways, as usual, lazy halfbaked though it is, just sharing the goodies - do feel free to improve it and post your own or maybe some real security expert can post a better set of scripts here..

Ofcourse, the only pet peeve I have is this - I, for some reason cannot use my camera with power kernel. mebbe some day will have time to look at all things I want..

[Late realization of searching for N900 ufw on google gave me this]

meego kernel on pandaboard?

2010-10-16T10:30:00.002-05:00

What exactly is a kernel? at the end of the day, just a collection of patches :).. So yeah, I have a "unique" collection of patches for PandaBoard that I requested MeeGo kernel maintainers to pick up yesterday. Now to wait and see if they actually get accepted. Next steps would be tough:

DSS - omapfb enablement
EHCI - keyboard and mouse

As usual, the patches to provide the basic functionality does'nt seem to have made it upstream yet.. I sometimes wonder - Is it really so hard to push patches upstream?? Then I realize, I push patches in my spare time :) Which basically means that I am not driven by the chruning winds of business forces within the work environment dictating when and what patches I should be posting upstream :). Glad I still retain that flexibility. and probably the reason I do move seemingly faster - I always have the luxury to maintain focus on upstreaming my patchset.. it is all that hard when one writes in BOLD on one's office white board:

DID YOU CHECK YOUR PATCH STATUS: xyz

When one does'nt have a manager to remind one to follow up on patches upstream, I guess it makes it self driven - the most effective way of upstreaming.. it is long, it is arduous, it is constant monitoring, it is techno-political + there is a bit of learning how to write English involved.. but mostly it is one's personal drive and attitude I guess.. we all like to talk in a common language -> it tends to the "bottom posting", git format patch format etc.. bit of net-etiquette involved.. yeah we'r all mostly C-speaking people and would rather see code-ware than slide-ware and more importantly it should *work* ;)..

Felipe B's post is an excellent real-world read on what it is all about. It is not really that difficult.. it just needs practise.. We all help share what we learn.. but *you* (dear reader) need to step up and post a patch first for us to help tell you how to post a patch ;)

Tired of ttySx and ttyOx

2010-10-14T13:41:00.002-05:00

Recently linux-omap integrated omap-serial patches. Now we dont use ttyS2 anymore but use ttyO2. tired of switching kernel versions and fixing my getty, wrote the following
In my busybox /etc/init.d/rcS file:


proc=`mount|grep "proc"`
if [ -z "proc" ]; then
   mount -t procfs none /proc
fi                                                                                         
if [ -f /proc/cmdline ]; then
   # grab console from cmdline and use it..
   tty=`cat /proc/cmdline|sed -e "s/ /\n/g"|grep console|cut -d '=' -f2|cut -d ',' -f1`
   if [ -z "tty" ]; then
           echo `cat /proc/cmdline` "does'nt have console?"
   else
       # remove my previous one if it exists
       rm -f /dev/tty-bd
           ln -s /dev/$tty /dev/tty-bd
           echo "/dev/$tty linked to /dev/tty-bd - using as console"
   fi
else
   echo "cmdline not found - no console?"
fi

In my inittab:


tty-bd::askfirst:-/bin/sh

PandaBoard un-veiled: get even more power with dual core ARM cortex A9 OMAP4!

2010-09-29T11:36:00.005-05:00

This year seems to be the year of the hacker community :) TI opened PandaBoard for early adopters today :).. Good details on PandaBoard here. The usual goodies schematics and userguide etc are already up as well.. Some of the stuff that impressed me:

HDMI AND DVI options
HSUSB hub and Ethernet yaay..
Serial port is a decent serial port and no weird wiring needed ;)
Connectors pin compatible to beagle and xm.. :)
Did I forget to say you have 1271 onboard wlan??

And lots more.. Just love this Baby.. I run ubuntu at home on my panda (yep, am already part of the PEAP - PandaBoard Early Adopter Program) and working on getting MeeGo up and running as well. Supported in mainline kernel and mainline u-boot as well.. :) fun time ahead with multi core processing ;)

my kernel does'nt boot: the magic of EARLY_PRINTK

2010-09-29T10:24:00.003-05:00

I am subscribed to TI's e2e portal and this post peeked my interest. Since sometime in mainline kernel we've had issues with kernel not booting up due to some weird bugs. As a kernel developer, I have screwed up multiple times preventing kernel boot from happening. Typical build results in:

## Booting kernel from Legacy Image at c0700000 ...
Image Name: Linux-2.6.32-rc6
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1939152 Bytes = 1.8 MB
Load Address: c0008000
Entry Point: c0008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK

Starting kernel ...

And that's it - no useful messages for the kernel geeks to figure out where the boot sequence crashed, no real debug information at all!

So the first question: why the kernel silence?
The boot messages can only be printed once you have the serial port enabled. Now, serial port enablement itself could be pretty much later in the kernel boot sequence, if the system crashes(oops/data abort etc..) prior to that, there is no messages printed as kernel configuration assumes that you have no configured serial port prior to this..

Now the solution: EARLY_PRINTK
The reality is usually a bit different in development platforms - usually you have something like u-boot or some bootloader spewing out a few prints to serial port, + ARM kernel boot requirements state that you could optionally (and recommended) have atleast 1 serial port configured prior to giving control to kernel. *if* you have such a bootloader which configures a serial port prior to giving control to kernel, you can enable a configuration called EARLY_PRINTK in the kernel .config. Note: there are many platforms that use this. How do we use this? two steps:
a) Build a kernel with EARLY PRINTK
b) provide earlyprintk as bootargs to actually get a more detailed log:

Step a) building kernel with EARLY_PRINTK
build with your default configuration of your choice, and then enable CONFIG_DEBUG_LL and CONFIG_EARLY_PRINTK in your kernel hacking options:

Kernel low-level debugging functions (DEBUG_LL) [N/y/?] (NEW) y
Early printk (EARLY_PRINTK) [N/y/?] (NEW) y
Kernel low-level debugging via EmbeddedICE DCC channel (DEBUG_ICEDCC) [N/y/?] (NEW) n

and build your uImage, zImage etc..

Step b) add earlyprintk to your bootargs
it is as simple as that - just add the word earlyprintk to the bootargs
example on u-boot.:

setenv bootargs console=ttyS0,115200n8 root=/dev/mmcblk0p2 rootdelay=2 init=/bin/ash

becomes:

setenv bootargs console=ttyS0,115200n8 root=/dev/mmcblk0p2 rootdelay=2 init=/bin/ash earlyprintk

and we are done, bootup and see detailed logs now...

Sidenote: if your serial port itself does'nt work and you have JTAG, you may want to explore the ICE support for earlyprintk as well.. good luck..

linux on C64 DSP!

2010-09-22T12:37:00.001-05:00

Thanks to rkw, heard of this: http://linux-c6x.org/wiki/index.php/Main_Page it is based on 2.6.34 - pretty much closer to .36-rc5 ;) and needs some more work I guess.. mostly, it would be a great thing to get this running on beagleboard! I cant think why not.. ;)

MeeGo diary notes: Packaging the Das U-boot

2010-09-15T15:53:00.004-05:00

My Odyssey into MeeGo packaging continues today with U-boot packaging.

Decision on the source
First of all for U-boot package I needed to decide which source to use. Since I am no big fan of private repositories (even the ones hosted publicly!), the mainline u-boot was an obvious choice. Thankfully sakoman and rest of the u-boot community have done a great job in making omap3 and omap4 support available in Mainline u-boot. And yep, it does have PandaBoard and obviously beagleboard support as well.

RPM saga
Since the rule of a lazy programmer is not to invent something someone already has done, spend some time with google searching for readily available RPM packages for u-boot. One of the first things I hit was that our friends at Freescale had done a nify spec packaging for imx processors for packaging u-boot. But, looking closely I was not too impressed, searching a bit more, hit on the openmamba project and the excellent packaging that Silvan Calarco has done for u-boot. Though it was done for mainstone, it was closest to what I wanted for MeeGo - Ability to build for multiple platforms and multiple architectures with minimal tweaks. A quick email exchange with Silvan, and he was completely ok with me reusing the same MeeGo - Thanks Silvan :).

Cross building rpm on a Ubuntu PC
Almost all folks had me convinced that I needed to switch to opensuse to build RPM packaging. after a couple of hours of playing around with virtualbox and attempting to install opensuse dvd, I decided that it was a waste of my time. Instead found the following:

sudo apt-get install rpm

And viola I have rpmbuild packaging. the first version of the spec file I wrote (very little modified from Silvan's original version) build with the following command:

rpmbuild -ba u-boot.spec --define="CROSS_COMPILE arm-none-linux-gnueabi-" --define="TARGET_BOARD omap4_panda" --define "TARGET_CPU arm" --target="arm"

(note: I was still ignorant of OBS realities at this point ;).. Remember, I am a newbie ;) )..

MeeGo Packaging gimmicry
Since I had my rpm package successfully building, I was all set to hit OBS and be done in a jiffy.. Boy, was I in for a surprise (at least for a spoilt kernel programmer turned newbie rpm packager).

So in I go to the good ol' build.meego.com following the rules as written in the wiki, and reading the guidelines just to get my bearings right,
a) I created my own u-boot project home:nm:bootloader:u-boot (within my namespace ofcourse as I mentioned yesterday).
b) I created my first package inside the project called u-boot
c) Then added a new repository u-boot-omap4panda with a create new repository. -I needed a rule to base it on, so Selected devel:kernel and just added armv7le - cortex a8(omap3) and a9(omap4) were both v7 anyways..
note: I should have created the repository as u-boot.. but I guess we can fix it later on..
d) I added the source.tar.bz2 and the .spec file using the web interface and bingo found that OBS was ready to build out of the box.. and it failed miserably.

On #meego-dev Stskeeps (one of the nice, friendly and helpful MeeGo maintainers) introduced me to some ground rules in OBS
a) I cannot not define a custom build flag TARGET_BOARD omap4_panda and TARGET_CPU=arm were no no.
b) I dont need to use CROSS_COMPILE in MeeGo as it in the backend uses qemu and native-like build (basically, it executes gcc which is internally linked to a cross-arm-gcc - nifty!)
or in other words,

rpmbuild -ba u-boot.spec

should build me a meego rpm for my platform.. But, wait a minute.. how does OBS know which platforms I intended it to build? Stskeeps pointed me to the kernel package as an example - exactly the same pain - n900, netbook etc need their own separate builds. in some cases individual patches to be applied independent of each other. Lets digress a little and understand how the trick works for kernel.

MeeGo kernel package spec file trick
Put in a simple terms:

obs looks for the spec file with the same name as the obs package name

In the case of kernel, the main package kernel is linked to packages kernel-ivi, kernel-mrst, kernel-n900 kernel-netbook etc. . The core package kernel has the spec files: kernel.spec, kernel-ivi.spec, kernel-mrst.spec, kernel-n900.spec, kernel-netbook.spec along with the same source.

when obs build kernel-n900 package, it does'nt use kernel.spec, instead uses kernel-n900.spec

Nifty - so in each spec file, you put in the stuff what you need for the platform! Problem solved. But, would'nt it be a maintainer nightmare to manage few 100 spec files each forgetting to update common stuff? the MeeGo kernel maintainers had a trick up the sleeve as well.

Use a common kernel.spec.in file to put all data you need, each platform specific data is marked with a tag @@. e.g.:

@@N900 Name: kernel-n900

which basically means introduce Name:kernel-n900 only for n900 spec file. This is provided to a simple perl script called makespec.pl -> it is a very simple tag replacement logic -> It checks if a file called N900 exists, if yes, it enables all lines marked with @N900

all this is wrapped in a Makefile which basically does the following:

touch N900
makespec.pl kernel-n900.spec
rm N900

so when you do a make in the repo, it generates platform specific spec files from kernel.spec.in -> and you now have spec files for each package(aka platform) and a single spec.in file to maintain.

The U-boot package spec
For u-boot I did copied the same logic - with the fact that I did not need an additional patch for panda (atleast at the moment). Yep, I know I can improve the script improve the Makefile, remove the touch+rm nonsense.. mebbe a little later, but for the moment, it is not a tragic blocker as it allowed me my primary goal - in addition to pandaboard, the mechanism should scale to any platform and architecture we need it to scale to. so my contents now changed to:

Makefile -> This is for me to generate the platform specific spec files
makespec.pl -> tiny modifications to allow Panda replacements
series -> this was for future patches that might come in.. I need to work this out..
u-boot-2010.09.rc1.tar.bz2 -> rc1 tarball from denx.com
u-boot-omap4panda.spec -> This is the generated file
u-boot.spec -> "generic" spec file: It does a PandaBoard build at the moment, we can figure things out when we enable something else
u-boot.spec.in -> the main spec file

So, if i do a make clean all my platform specific .spec files disappear. on doing a make a new set of platform specific spec files are generated from my u-boot.spec.in file. Nifty. Tested the build and it built fine with u-boot.spec file

Created a new package u-boot-omap4panda and linked it to home:nm:bootloader:u-boot and viola it built the same with u-boot-omap4panda.spec file instead of u-boot.spec file.

I needed to see if the logic would work with omap3beagle (my fav platform)
- modified the u-boot.spec.in, Makefile and makespec.pl files for adding Beagleboard relevant entries, did a new make and used osc to commit in the changes
- created a new package u-boot-omap3beagle and linked it back to home:nm:bootloader:u-boot

Build just great.. I then noticed that I had a few rpmlint warnings as well..

RPMLINT report:
===============
u-boot-tools.armv7l: W: package-with-huge-docs 77%

More than half the size of your package is documentation. Consider splitting
it into a -doc subpackage.

u-boot.src:143: W: macro-in-%changelog %{TARGET_BOARD}

Macros are expanded in %changelog too, which can in unfortunate cases lead to
the package not building at all, or other subtle unexpected conditions that
affect the build. Even when that doesn't happen, the expansion results in
possibly "rewriting history" on subsequent package revisions and generally odd
entries eg. in source rpms, which is rarely wanted. Avoid use of macros in
%changelog altogether, or use two '%'s to escape them, like '%%foo'.

u-boot.src:22: W: hardcoded-packager-tag Nishanth

The Packager tag is hardcoded in your spec file. It should be removed, so as
to use rebuilder's own defaults.

3 packages and 0 specfiles checked; 0 errors, 3 warnings.

Never liked warnings and decided to clean them up
a) looking at the Packaging Guidelines, realized that the %changelog section in the .spec had to go to .changes file - so bit of mucking around later, did the same thing like the spec file:
u-boot.changes.in is copied to u-boot-.change to ensure that the changelog is replicated in all package builds.
b) removed my name off the .spec.in regenerated and checked in the changes
c) split the documentation off to u-boot-docs package (so you now get a package for u-boot, one for tools(mkimage) and one for doc) - added a few of useful docs there as well.. mostly the generic ones.

Committed and checked in my changes, noticed that with every checkin, obs would automagically build up the linked up packages. final set of files:

Makefile
makespec.pl
series
u-boot-2010.09.rc1.tar.bz2
u-boot.changes
u-boot.changes.in
u-boot-omap3beagle.changes
u-boot-omap3beagle.spec
u-boot-omap4panda.changes
u-boot-omap4panda.spec
u-boot.spec
u-boot.spec.in

Bingo - for your enjoyment - the final rpm packages are here

TODO: to figure out how to get this to mainline

Osc Commands I used
Overall, I found osc extreamely useful once I had reasonable level of confidence by using rpmbuild on my Ubuntu box, I did not have to deal with webpage based updating etc.. osc was a savior there!

osc co home:nm:bootloader:u-boot

Checks out my u-boot repository

osc status

Tells me what files have been modified or if there are any new files what they were

osc add file1 file2 file3...

Adds the files to the list of changes to be pushed to my repo

osc ci -m "my commit message"

Commits my changes and pushes to my repo with the changes noted with commit message "my commit message"

Well thats it for today.. Overall, I've been amazed how easy it's been once I figured out the basic things to create a buildable package! hmm..

MeeGo diary notes: getting ready for packaging

2010-09-14T16:48:00.004-05:00

Got myself a build.meego.com account and am attempting to start a new package around meego for pandaboard - an OMAP4 based platform. This series of blog posts will hopefully contain my day to day notes for a better lack of word all under the label of MeeGo ;)..

Note: the good folks at DeviceVM had already done a MeeGo port to OMAP4 Blaze platform sometime back, my approach is a bit different in getting MeeGo port available in main MeeGo repository itself. Different challenge - mostly of the packaging kind as I am starting to realize ;)

I've started my first experience with packaging for MeeGo with trying to put together a package for U-Boot. my lack of previous experience with rpm packaging has me stumped so far :(.

On the base level, MeeGo uses rpm packaging - essentially what folks call a spec file. MeeGo folks have added one layering on top with yaml file which is translated by a set of tools called spectacle to translate the yaml to rpm spec file.

Spectacle
Since I like to get my hands on the tools as I learn, the first task of the day was to get spectacle tools loaded and running. Ran into issues immediately trying to get my ubuntu 9.10 box to automagically install the spectacle debian packages. few hours of trying to work around apt sources.list files, I gave up and filed a bug - steps that worked for me:

Downloaded spectacle_0.19_all.deb
sudo apt-get install python-yaml libyaml-0-1
sudo dpkg --install spectacle_0.19_all.deb

Bingo, I now have the specify and other spectacle utilities.

osc - the OBS command line util
MeeGo works with opensuse build system (or OBS) - more or less a centralized build system which effectively reuses packages from all around for various build configuration. OBS has a command line utility called osc - installed this with:

sudo apt-get install osc

So far so good. I now needed to get osc to talk to build.meego.com's servers.. given that I was behind a firewall, I needed a configuration file setup to be done. Bit of help from the good folks on #meego-arm and #meego-dev irc chatrooms on freenode.net later my ~/.oscrc:

[general]
apiurl = http://api.meego.com
packagecachedir = /home/nmenon/src/meego/osbuild-packagecache
[http://api.meego.com]
user = my_obs_login
pass = my_obs_passwd
aliases = meego
email = my_email_id
http_proxy="https://proxy:80/"

Cute.. "osc ls" worked out of the box after this.

osc is a must have tool if you want to effectively work with OBS IMHO.

I am all ready now to create my u-boot repo:
Following the wiki steps (note the build.meego.com looks a bit different from the time the wiki was created ;) but that is expected) Went to the obs site and clicked on projects and added a new project for uboot under my namespace (home:nm:bootloader:u-boot) - This probably will be different when it enters mainline devel:tools:something/something i guess.. not worrying about it for the moment.

on my pc:

osc co home:nm:bootloader:u-boot

and viola I have a clone!

Things to do next - the real thing: figuring out how to add the spec file and related packaging gimmicry to build in obs..

next gen arm core

2010-09-09T14:41:00.004-05:00

Cortex-A15 MPCore - Welcome to the next generation!!
update: 20100910: more of the TI story slashgeared!

Public OMAP4 TRM released

2010-08-27T09:23:00.006-05:00

TI has released public OMAP4430 TRM and clock tool in the official site today. :).. yaay..

TRM gives you indepth insight into what OMAP4 is all about
and the clock tool is my favourite tool especially to understand the complex clock framework dependencies on OMAP chips - the released version is custom to TI OMAP4 platform though.. but effective tool if you like to learn/debug/understand the clock framework dependencies -> all the way from the oscillator you use on the board to the clocks you use in the functional block of interest..

originally note from Mythri on Linux OMAP
[update: ctt wiki]

omap4 headsup from slashgear

2010-02-01T22:06:00.001-06:00

found this article pretty interesting

how do you start a new year? in style!

2010-01-16T12:34:00.005-06:00

it is exciting news and there is no reason for me to do the good old style of a post.. so here it goes:

Jason's state of the beagle address (somehow sounds similar to this - no offense intended ofcourse) had the following highlights (or my view how as an engineer I'd have paraphrased):

Beagleboard rocks. (and we have awards to prove it too ;) )..
We kinda got screwed by beagle's success initially, but now I think things are better now..
beagleboard is getting an engine change soon - blistering speeds ahead dudes.. 720meg beagles.. get those apps rockin..
Annnndddd..... Yeeeehaaaawww.. beagleboard XM!!!!!! DM3730(dudes in l-o know the diff with OMAP3630).. wow.. more juice under the hood man... mama mia!!! camera, 4 port ehci, usb2ethernet the good ol' lcd and expansion connectors, everything we all cribbed and wanted our fav beagle to have, is there now! Go Go Gerald ;)
for those newbies.. go do the training and get rockin faster..(android/angstrom.. whatever you need is out there!)
TI is doing better supporting all of us hacker - so more choices for us to do the best hacks! want to create that automated dishwashing robot which also doubles as your lawn mover and your network router ;) go ahead DO it!
yah, as usual, let keep our flames to the usual MLs and ircs..

what heights do we take beagle to? YOU decide ;)

OMAPZoom tutorial hour!!

2009-12-04T20:12:00.003-06:00

So omapzoom folks have a tutorial hour now, some really cool topics get caught up here.. this week:

· Android on OMAP Overview and Resources

· DSP Bridge Overview

· OpenEmbedded Overview

it is a webex (works on most OSes including a linux PC) + teleconf -> large number of access numbers from around the world
more information here. the OMAP tutorial hour (including the previous presentations - which by the way explains kernel process from TI) are available here.

Smart Reflex what is it?

2009-11-19T19:07:00.004-06:00

Googling around, I found this beautiful article that gives excellent explanation of how Adaptive Voltage behaves in the system.

by the way, this is going to be part of my rewrite of smart reflex driver to make the voltage infrastructure a lot more cleaner and easy to use.
General flow I am thinking is as follows(will change ofcourse):
voltage driver
|------------> No SR PMICs implementation thru regulator framework perhaps.
\-------> Smart reflex driver
|----> PMIC interface (for class 0 devices)
|-----------------------------------\
\-----> Voltage processor driver -> Voltage controller driver
Ofcourse things might change as I move on with the implementation (I need to think a little more on this), but once I am done, you should be able to see it here

few new things I see on linux-omap kernel community

2009-10-14T21:19:00.003-05:00

After a long while of staying off linux-omap, been watching it rather closely recently.. here are some interesting stuff I saw this month:

Power Management: Operating points and general PM strategy for handling for various silicons here
Silicon Feature support for OMAP3 here
New silicon support: OMAP35xx and 36xx support being introduced.
Discussion on memory and cache issue here
ETM, ETM support here
few new PMIC - 6030 and 5031
hints of wl1251 support getting upstream
IO_ADDRESS is dead use io_remap like the rest of the world
spring cleaning of omap850/730 series

and of course a bunch of stuff I have missed posting here such as move to 2.6.32-rc4 by Tony and Kevin, both pushing out patches to mainline etc.....

some interesting posts

2009-10-14T21:09:00.003-05:00

High time I "ported" my posts from facebook back here..so here it goes
Some really bad code stories:

shared by rob clark - how bad can some code go??

http://thedailywtf.com/Articles/The-Shenanigans-Handler.aspx

Aint this cool:

http://arstechnica.com/web/news/2009/09/horrifically-bad-software-demos-become-performance-art.ars

Techno Curios:

Tired of fullspeed, highspeed, lowspeed?? how about superspeed?? tired of acronymns already??

http://www.pcworld.com/article/172757/wheres_usb_30.html

Search for my cheap oscilloscope goes on:

http://www.micahcarrick.com/06-06-2006/pc-sound-card-oscilloscope-linux.html
http://www.fpga4fun.com/digitalscope.html

Hacks 'nd bytes:

PS3 back with Hulu..

http://www.ypass.net/blog/2009/06/got-a-ps3-want-hulu-back-easy-enough/

timing diagrams

2009-10-14T21:02:00.003-05:00

drawtime

This is kinda a cool app that runs on ubuntu to draw timing diagrams as follows:
Example(from the drawtime website):

CS1 = 1, OE = 1, ADDR = X, DATA = Z.

CS1 = 0, OE = 0, ADDR = "".
OE -tOE> DATA = "";
CS1 -tCS1> DATA;
ADDR -tACC> DATA.

OE = 1, CS1 = 1, ADDR = X.
CS1 -tH> DATA = Z;
OE -tH> DATA;
ADDR -tH> DATA.

and you can now generate all those cool waveforms without having to worry about did you get the lines right etc..

more such cool stuff here

Flashlite and Valgrind for OMAP3!!

2009-09-19T08:47:00.002-05:00

Looking through the beagleboard facebook group,
Saw two interesting points:

Flash Lite 3.1 evaluation version for Beagleboard

For all the Beagleboard fans out there, we’ve created an evaluation version of Flash Lite 3. This is a fully functional version of Flash Lite that times out in 3 minutes. It is built on Angstrom Linux distribution and requires X. Please email me if you are looking for more information or are interested in having one. I should mention that OMAP 3530 (ARM Cortex A8) is a powerful CPU and seems to handle graphics as well as video very well."

How to build Valgrind for Beagleboard

1) Get Valgrind source code from SVN using revision 9648 and 1888 for VEX
svn co -r 9648 svn://svn.valgrind.org/val
grind/trunk
cd VEX
svn update -r 1888

2) Download the patch here http://bugsfiles.kde.org/attachment.cgi?id=32348

3) Apply the patch into the source code
cd valgrind
patch -p1 < [path to the patch]

4) Run autogen.sh to run autotools

5) Configure the source code
./configure --host=arm-angstrom-linux-gnueabi

The patch still has some bugs such as CPU instruction alignment you can 'cat /proc/cpu/alignment' to find out if the kernel is configured to fix unaligned accesses, and you can enable it by executing 'echo 2 > /proc/cpu/alignment' but it's enough to use for simple application.
Have fun with Valgrind :-)

The above quotes are straight from Facebook posts itself..

CELF 2009 - France (ELC-Embedded Linux Conference)

2009-09-12T11:56:00.003-05:00

here are the sessions in the conference: http://www.embeddedlinuxconference.com/elc_europe09/sessions.html

Includes Sascha and my personal fav - u-boot v2.

And then Finally TI U-Boot tree!!

2009-09-10T14:51:00.002-05:00

Finally.... here it is!!! patches for u-boot to be send straight to u-boot mailing list.

Free DSP codecs!!!

2009-08-31T18:12:00.002-05:00

Wow.. a blast of new sites for omapzoom..

And then I see this on the new omapzoom google groups!!!
* MPEG4 Video Dec
* H263 Video Dec
* JPEG Dec
* JPEG Enc
* AAC Dec
https://gforge.ti.com/gf/project/openmax/frs/?action=index
And you also now have a wiki for omap

Plato! trace-visualize-debug-filter code path!

2009-08-16T13:44:00.002-05:00

Got this link from a colleague - kinda useful if you would like to use it for your own purposes.. quote from the site:

PLATO is a tool for displaying and analyzing software traces from an application being debugged. It connects to TTIF (libttif.so, included) which provides a lower overhead replacement for printf(), so as to minimize the chance that timing related bugs disappear when you enable debug traces, and also some binary trace APIs. PLATO can be running on a separate PC from the application being debugged, making it suited for embedded development. PLATO will decode/filter/display/visualize the traces

towards a integrated infrastructure for feature + errata handling in kernel

2009-08-14T17:13:00.005-05:00

I have a confession to make: I am fanatic about clean code. I like it simple and I like it elegant.

Few days back, I had a chat on linux omap mailing list on what I'd dream to see instead of a half a dozen cpu_has_feature_XYZ() APIs in the system.. The thought is more of this form:

Some sort of infrastructure which is common to all silicons,platforms exist which provides method to register the tuple (silicon_rev_id | ip_module_rev_id, feature_errata_id)
Specific drivers such as DMA, I2C, McBSP, PRCM etc.. on registration provides to the system the an array of tuples for that device.
Platform on bootup provides the platform_data to the driver, which allows the driver to start, but now, it can also detect cpu_rev and can grap it's own IP Module rev from it's own register.. -> that is provided to the infrastructure
Every time there is a need to check to enable/disable feature/errata, all the code needs to do is:

if (is_enabled(dev, OMAP3_ISP) ) {
do my stuff;
}

is'nt that cleaner than
if (cpu_is_3430() && (cpu_rev >= OMAP3430_ES3P1) ) {
do my stuff;
}
or
if (cpu_is_3430() && (omap_features & OMAP_HAS_ISP) {
      do my stuff;
}

Now what ever we do here can easily be displayed by the subsystem by exposing a cat /sys/devices/... /features or even club it with cat /proc/cpuinfo if that is what people want -> you can do it anytime anywhere if you retain just the data you need... ;)
No need to store the entire database of features in the infrastructure for ever, we can save memory by making the original array init_data and copying it into a list which is easier to search for the infrastructure..

Now, this infrastructure can also be readily used for external peripherals outside the chip - like camera sensors, RFBI displays etc.. come to think of this, it kinda looks the way how I2C board_info is handled in some ways.. hmmm...

Now, only thing I need is get some time to do this, as Kevin seems interested in the original patch.. couple of fortnights to go before i get some personal time to hack some *real* code.. ;) but what the heck.. if there is anyone out there who has the time and interest to do this.. go ahead and do it..

Replace CAmELcASiNg with lower_casing

2009-08-13T22:20:00.004-05:00

Finally irritated with a bunch of CaMELcASinG, decided to write a small script albeit not too clean or optimized for the job of a search and destroy
Since it is weird to write my own c interpreter to find the right targets to replace, I use output of ctags to generate tags file. if you are using kernel, you could just do a make tags to get the same output file.

#!/bin/bash
# Silly little script to replace CaMELCaSInG to lower_casing
# Half a zillion thoughts later,
# why not use ctags which has c interpreter already to do
# function identification for us?
if [ ! -r 'tags'  ]; then
echo "Sorry.. no tags file!"
exit 1
fi
if [ ! -r "$1" ]; then
echo "I need a directory or a file for replacing.."
exit 2
fi
DIR_FILE=`echo "$1"|sed -e "s/\//\\\//g"`
# tags have the following notation in field 4 (tab seperated)
# e - enum value
# d - define
# f - function
# F - File itself
# g - enum type
# m - structure parameter
# p - prototype
# r - kconfig define(refered)
# s - structure type
# t - typedefined variable
# v - variable
# x - extern defined variable
# we can choose to have different rules:
# rename rule i am going to follow:
# Any define -> convert camelcase to lower_case_define->convert to caps
# Any function, enum,struct param,prototype,struct type, typedef var,extern def ->
# camel_case to lower_case_define
# All files will be made unix file only (no point in dos + unix mixtures..)

#**
#* @brief - changes camel casing to ones with smaller case
#*
camel_to_norm(){
echo $1|tr '\_' '+' |sed 's/\([A-Z]\)/_\l\1/g' | sed 's/^_\([a-z]\)/\1/g' |\
 tr 'A-Z' 'a-z' | sed "s/\([a-z][a-z]\+\)/-\1-/g"|tr -d '_'|\
 tr '-' '_'|sed -e "s/_$//g"|sed -e "s/^_//g" | tr '+' '_' |\
 sed -e "s/__*/_/g"|sed -e "s/_\([0-9][0-9]*\)/\1/g"|\
 sed -e "s/^[a-z]\_\([a-z][a-z]\+\)/\1/g"


}

#**
#* @brief - all_to_upper - Moves all to upper case
#*
all_to_upper(){
camel_to_norm $1 | tr 'a-z' 'A-Z'
}

#**
#* @brief generate_list - will generate list of symbols from tags matching
#*
generate_list() {
cut -d' ' -f1,4 $TMPFILE|grep "$1\$"|cut -d' ' -f1|sort|uniq
}

#**
#* @brief find_files - finds list of files from tag file matching usage
#*
find_files(){
cut -d' ' -f1,2 $TMPFILE|grep "^$1"|cut -d' ' -f2|sort|uniq
}
TMPFILE=/tmp/cleaner.$$.tmp
TMPFILE1=/tmp/cleaner.$$.1.tmp
# grab the output for only the ones we want..
grep  "$DIR_FILE" tags |grep -v "^\!"|sed -e "s/\/\^.*\"/REPLACE_1/g">$TMPFILE

replace_pattern(){
echo "=====>Search and replace for pattern $1 with $2"
# Convert the functions back to smaller case and replace them in the files
for token in `generate_list "[$1]"`
do
 if [ $2 -eq "1" ]; then
  new=`camel_to_norm $token`
 else
  new=`all_to_upper $token`
 fi
 if [ "$new" != "$token" ]; then
  echo "==>Replacing $token with $low"
  for file in `find_files $low`
  do
   echo "->replacing $token to $new in file $file"
   cp $file $TMPFILE1
   dos2unix $TMPFILE1
   sed -e "s/\(W*\)$token\(\W*\)/\1$new\2/g" $TMPFILE1>$file
  done
 else
  echo "==>not replacing $token"
 fi
done
}
echo "================= Replacing Defines ==============="
replace_pattern d 2
echo "================= Replacing Functions ==============="
replace_pattern efgmpstvx 1
rm -f $TMPFILE $TMPFILE1

usage:
Replace file_or_directory.

Note, we could definitely customize this by adding prefix or in cases where code originates from windoze environment, removing dw_ dl_ etc.. that is pretty easy to do once you pick on tags and know what to do for output ;)