meego kernel on pandaboard?

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

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!

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

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!

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

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

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

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

Public OMAP4 TRM released

TI has released public OMAP4430 TRM and clock tool in the official site today. :).. yaay..
[WARNING 17 Oct 2012]: ALWAYS GO HERE for the very latest documentation - Thanks to a few people ignoring the "official site" link above

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

found this article pretty interesting

how do you start a new year? in style!

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