Command to set date in linux

date -s “23 FEB 2012 18:00:00”

How to install java in ubuntu 10.04

apt-get install openjdk-6-jdk

Arm toolchain installation in Ubuntu 10.04

E: Couldn’t find package gcc-arm-linux-gnueabi
http://lists.debian.org/debian-embedded/2011/04/msg00079.html

Ubuntu has pre-packaged cross-compilers for ARM directly in the archive since Ubuntu 10.10, so you shouldn’t need any special repository with recent Ubuntu releases; just
sudo apt-get install gcc-arm-linux-gnueabi.
If you’re running Ubuntu 10.04, there are backports of this
cross-toolchain in a PPA maintained by Linaro:

sudo add-apt-repository ppa:linaro-maintainers/toolchain
sudo apt-get update
sudo apt-get install gcc-arm-linux-gnueabi

Steps to mount qcow2 image

modprobe nbd max_part=63
qemu-nbd -c /dev/nbd0 image.qcow2
mount /dev/nbd0p1 /mnt/image

How to create a patch file using diff command

$ cat old/file.txt
  This
  is
  a
  simple
  file.

$ cat new/file.txt
  This
  is
  a
  slightly more complex
  file.

$ diff -Nur old new >> new.patch

To install patch

$ cd old/

old $ patch -i new.patch

 

Debugging Segmentation fault using gdb

We are going to use gdb to figure out why the following program causes a segmentation fault. The program is meant to read in a line of text from the user and print it. However, we will see that in it’s current state it doesn’t work as expected…

#include <stdio.h>

#include <stdlib.h>

int main(int argc, char **argv)

{

char *buf;

buf = malloc(1<<31);

fgets(buf, 1024, stdin);

printf(“%s\n”, buf);

return 1;

}

The first step is to compile the program with debugging flags:

prompt> gcc -g segfault.c

Now we run the program:

prompt > a.out

Hello World!

Segmentation fault

prompt >

This is not what we want. Time to fire up gdb:

prompt > gdb a.out

GNU gdb 5.0

Copyright 2000 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

welcome to change it and/or distribute copies of it under certain conditions.

Type “show copying” to see the conditions.

There is absolutely no warranty for GDB. Type “show warranty” for details.

This GDB was configured as “i686-pc-linux-gnu”…

(gdb)

We’ll just run it and see what happens:

(gdb) run

Starting program: /home/dgawd/cpsc/363/a.out

test string

Program received signal SIGSEGV, Segmentation fault.

0x4007fc13 in _IO_getline_info () from /lib/libc.so.6

So we received the SIGSEGV signal from the operating system. This means that we tried to access an invalid memory address. Let’s take a backtrace:

(gdb) backtrace

#0 0x4007fc13 in _IO_getline_info () from /lib/libc.so.6

#1 0x4007fb6c in _IO_getline () from /lib/libc.so.6

#2 0x4007ef51 in fgets () from /lib/libc.so.6

#3 0x80484b2 in main (argc=1, argv=0xbffffaf4) at segfault.c:10

#4 0x40037f5c in __libc_start_main () from /lib/libc.so.6

We are only interested in our own code here, so we want to switch to stack frame 3 and see where the program crashed:

(gdb) frame 3

#3 0x80484b2 in main (argc=1, argv=0xbffffaf4) at segfault.c:10

10 fgets(buf, 1024, stdin)

We crashed inside the call to fgets. In general, we can assume that library functions such as fgets work properly (if this isn’t the case, we are in a lot of trouble). So the problem must be one of our arguments. You may not know that ‘stdin’ is a global variable that is created by the stdio libraries. So we can assume this one is ok. That leaves us with ‘buf’:

(gdb) print buf

$1 = 0x0

The value of buf is 0x0, which is the NULL pointer. This is not what we want – buf should point to the memory we allocated on line 8. So we’re going to have to find out what happened there. First we want to kill the currently-running invocation of our program:

(gdb) kill

Kill the program being debugged? (y or n) y

Now set a breakpoint on line 8:

(gdb) break segfault.c:8

Breakpoint 1 at 0x8048486: file segfault.c, line 8.

Now run the program again:

(gdb) run

Starting program: /home/dgawd/cpsc/363/a.out

Breakpoint 1, main (argc=1, argv=0xbffffaf4) at segfault.c:8

8 buf = malloc(1<<31);

We’re going to check the value of buf before the malloc call. Since buf wasn’t initialized, the value should be garbage, and it is:

(gdb) print buf

$2 = 0xbffffaa8 “Èúÿ¿#\17703@t`01@01”

Now step over the malloc call and examine buf again:

(gdb) next

10 fgets(buf, 1024, stdin);

(gdb) print buf

$3 = 0x0

After the call to malloc, buf is NULL. If you were to go check the man page for malloc, you would discover that malloc returns NULL when it cannot allocate the amount of memory requested. So our malloc must have failed. Let’s go back and look at it again:

7 : buf = malloc(1<<31);

Well, the value of the expression 1 << 31 (the integer 1 right-shifted 31 times) is 429497295, or 4GB (gigabytes). Very few machines have this kind of memory – mine only has 256MB. So of cousre malloc would fail. Furthermore, we are only reading in 1024 bytes in the fgets call. All that extra space would be wasted, even if we could allocate it. Change the 1<<31 to 1024 (or 1<<9), and the program will work as expected:

prompt >

Hello World!

Hello World!

prompt >

So now you know how to debug segmentation faults with gdb.

Source : http://www.unknownroad.com/rtfm/gdbtut/gdbsegfault.html

Openembedded

OpenEmbedded, the build framework for embedded Linux. OpenEmbedded offers a best-in-class cross-compile environment. It allows developers to create a complete Linux Distribution for embedded systems. Some of the OpenEmbedded advantages include:

• support for many hardware architectures
• multiple releases for those architectures
• tools for speeding up the process of recreating the base after changes have been made
• easy to customize
• runs on any Linux distribution
• cross-compiles 1000’s of packages including GTK+, Qt, the X Windows system, Mono, Java, and about anything else you might ever need

OpenEmbedded in ubuntu

$ sudo apt-get install sed wget cvs subversion git-core coreutils unzip texi2html texinfo docbook-utils gawk python-pysqlite2 diffstat help2man make gcc build-essential g++ desktop-file-utils chrpath python-ply python-progressbar libxml2-utils xmlto python-psyco policykit-gnome-doc gnome-doc-utils

Setting up the toolchain and doing a build

Before starting to configure your OE installation by following the instructions on this page make sure you have read how OE fits in with your host distribution and the required software for compilation.

Directory Structure

The base directory of your Openembedded environment (/stuff/) is the location where sources will be checked out (or unpacked).

• You must choose a location with no symlinks above it

• If you work in a chrooted environment and have ccache installed it is highly recommended to ‘su – <username>’ after you have chrooted. Compilation may fail because ccache needs a valid $HOME, which is usually set when using a user account. It is recommended that ccache is not installed on systems used to build OpenEmbedded as it has been known to introduce other subtle build failures.

To create the directory structure:

$ mkdir -p /stuff/build/conf
$ cd /stuff/

Obtaining BitBake

To start using OE, you must first obtain the build tool it needs: bitbake

It is recommended to run bitbake without installing it, as a sibling directory of openembedded/ and build/ directories. Indeed, as bitbake is written in python it does not need to be compiled. You’ll just have to set the PATH variable so that the BitBake tools are accessible (see Setup the environment section).

Getting a working bitbake

Bitbake switched from a svn repository to a git one, and the former is stuck at version 1.8.13, so when you try to build you may face an error: “Bitbake version 1.10.2 is required and version 1.8.13 was found”. In that case please fetch released version or use git repository.

Which version is safe to use? Last release one is always working. When OE changes require newer version of BitBake metadata is changed and you will get message like above.

One note for those who want to play with development versions of BitBake – Python 2.6 may be required by newer versions. This can be a problem for some Linux distributions.

Basically the easier and faster solution (at the moment I’m writing) is to get release one.

 wget http://download.berlios.de/bitbake/bitbake-1.10.2.tar.gz

Using releases

Visit BitBake homepage and download tarball with latest release. For normal usage we suggest using 1.8.x (stable branch) versions. Unpack it to /stuff/bitbake/.

Obtaining OpenEmbedded using Git

Note: Once upon a time OpenEmbedded was using Monotone for version control. If you have an OE Monotone repository on your computer, you should replace it with the Git repository.

Note: These are only brief instructions. For a longer description about using Git with OpenEmbedded refer to Git and GitPhraseBook.

The OpenEmbedded project resides in a Git repository. You can find it at git://git.openembedded.org/openembedded.

Web interface is: http://cgit.openembedded.org/

To obtain Openembedded:

1. Install git
2. Go to the base directory of your OpenEmbedded environment

$ cd /stuff/

1. Checkout the repository (use one of our mirrors)

$ git clone git://github.com/openembedded/openembedded.git

or for the firewall challenged try https proto

$ git clone https://github.com/openembedded/openembedded.git

or http proto

$ git clone http://github.com/openembedded/openembedded.git

This is the data you’ll be using for all the work.

Updating OpenEmbedded

The .dev branch of OE is updated very frequently (as much as several times an hour). The distro branches are not updated as much but still fairly often. It seems good practice to update your OE tree at least daily. To do this, run

$ git pull --rebase

(note: this must be done in the directory created by the checkout of openembedded. On this page, this directory is /stuff/openembedded, but my checkout generated a directory /stuff/openembedded. Check the name of your subdir, and use the name on your machine in the following examples)

Create local configuration

It’s now time to create your local configuration. While you could copy the default local.conf.sample like this:

$ cd /stuff/
$ cp openembedded/conf/local.conf.sample build/conf/local.conf
$ vi build/conf/local.conf

It is actually recommended to start smaller and keep local.conf.sample in the background and add entries from there step-by-step as you understand and need them. Please, do not just edit build/conf/local.conf.sample but actually READ it (read it and then edit).

For building a .dev branch, in your local.conf file, you should have at least the following three entries. Example for the Angstrom distribution and the Openmoko gta01 machine:

BBFILES = "/stuff/openembedded/recipes/*/*.bb"
DISTRO = "angstrom-2010.x"
MACHINE = "beagleboard"

If you choose to install OE in your home directory, modify local.conf to refer to the OE paths as /home/<username>/ rather than ~/. It does not find the *.bb packages otherwise.

Setup the environment

One of the four command sets below will need to be run every time you open a terminal for development. (You can automate this in ~/.profile, /etc/profile, or perhaps use a script to set the necessary variables for using BitBake.)

If you followed the recommendation above to use BitBake from Git:

$ export BBPATH=/stuff/build:/stuff/openembedded
$ export PATH=/stuff/bitbake/bin:$PATH

If you installed BitBake:

$ export BBPATH=/stuff/build:/stuff/openembedded

Alternative syntax for those using the tcsh shell (e.g FreeBSD):

$ setenv PATH "/stuff/bitbake/bin:"$PATH
$ setenv BBPATH "/stuff/build:/stuff/openembedded:"$BBPATH

Start building

The primary interface to the build system is the bitbake command (see the bitbake users manual). bitbake will download and patch stuff from the network, so it helps if you are on a well connected machine.

Note that you should issue all bitbake commands from inside of the build/ directory, or you should override TMPDIR to point elsewhere (by default it goes to tmp/ relative to the directory you run the tools in).

Here are some example invocations:

Building a single package (e.g. nano):

$ bitbake nano

Building package sets (e.g. task-base):

$ bitbake task-base

Special note for task-base: you may need additional setup for building this very one task. More details in ZaurusKernels

Building a group of packages and deploying them into a rootfs image:

GPE:

$ bitbake x11-gpe-image

X11:

$ bitbake x11-image

OPIE:

$ bitbake opie-image

(NOTE: kergoth says it will take around 10GB of disk space to build an opie or gpe image for one architecture.
sledge says: You can reduce it to ~4GB by INHERIT += “rm_work”)

(NOTE: if you are using your custom kernel – set “Use the ARM EABI to compile the kernel (AEABI)” option in “Kernel Features”)

See the /stuff/openembedded/recipes/meta/ directory if you’re curious about what meta/task and image targets exist.

Building a single package, bypassing the long parse step (and therefore its dependencies–use with care):

$ bitbake -b /stuff/openembedded/recipes/blah/blah.bb

See Useful targets for a description of some of the more useful meta-packages. You will typically need at least one of the base images (bootstrap-image, opie-image or gpe-image), and if and only if you’re building for an OpenZaurus target requiring an installer image (such as C3000), an additional pivotboot-image.

Output of the build process (temporary files, log files and the binaries) all ends up in the tmp directory. Most interesting is probably the tmp/work/ directory. Just have a look around the DirectoryStructure.

Images generated by building package groups like opie-image or pivotboot-image are placed in the tmp/deploy/images/ directory. Individual ipkg packages are put in tmp/deploy/ipk.

Adding Packages

1. Create bbfile.
2. Try building it locally.
3. Fix eventual problems.
4. Send .bbfile or an OePatch to the openembedded-devel mailing list. Please note that changes should comply with the commit policy.

Problems

Try to solve problems first by checking that you have done everything right, that nothing has changed from this description and that you have the latest code (see GitPhraseBook). Look also in the log file (referenced in any error message you will receive). If you still have problems, try checking PossibleFailures and common build errors. Above links are dead, you can try the Category:FAQ. If problems persist, ask on IRC or in the openembedded mailing list.

The Openembedded metadata is changing constantly. This implies several things:

1. Once you have a “known good” version that works well on your system, keep it! To update, clone a new copy; don’t overwrite that working version until it’s known to be safe.
2. To resolve build problems, “git pull” is your good friend. Many times, the issues will already be fixed in the current tree.
3. Not all metadata updates cause the local caches to update correctly. Sometimes you’ll need to remove the “…/tmp” work directory and rebuild from scratch.
4. Similar issues apply to the package sources you download.

Portability issues

Make sure to set TARGET_OS to something other than linux in local.conf if your host isn’t linux.

GNU extensions to tools are often required. Symlink GNU patch, make, and cp (from fileutils), chmod, sed, find, tar, awk into your OE development path.

FreeBSD 4 users: Perl 5.0 is too old. A more recent perl must be available as /usr/bin/perl. Unfortunately just having more recent perl in the path isn’t good enough. Some scripts are hard-coded for /usr/bin/perl. You can test for which perl you’re using by typing perl -v. see /usr/ports/UPDATING for instructions on updating perl. Don’t forget to do a use.perl port as instructed in /usr/ports/UPDATING

FreeBSD users: Set BUILD_OS in local.conf to freebsdN where N is your major version number. At least the cross gcc wants this.

FreeBSD users: The build process of glibc uses a very long command line at some places. Increase ARG_MAX to at least 131072, by editing /usr/sys/sys/syslimits.h and recompile your kernel (and reboot).

Productivity notes

Use the interactive bitbake mode (“bitbake -i”) to speed up work when debugging or developing .bb files. Remember to run “parse” at the prompt first. Go!

If you want to save some compile time or are interested in additional tweaks to local.conf take a look at the Advanced configuration page.

 Source : http://www.openembedded.org/wiki/Getting_started

What is Ctag?

Ctags generates an index (or tag) file of language objects found in source files that allows these items to be quickly and easily located by a text editor or other utility. A tag signifies a language object for which an index entry is available (or, alternatively, the index entry created for that object).

Tag generation is supported for these programming languages.

A list of editors and tools utilizing tag files may be found here.

Manual and Tutorial can be found in http://ctags.sourceforge.net/

Cscope- interactively examine a C program

cscope is an interactive, screen-oriented tool that allows the user to browse through C source files for specified elements of code.

By default, cscope examines the C (.c and .h), lex (.l), and yacc (.y) source files in the current directory. cscope may also be invoked for source files named on the command line. In either case, cscope searches the standard directories for #include files that it does not find in the current directory. cscope uses a symbol cross-reference, cscope.out by default, to locate functions, function calls, macros, variables, and preprocessor symbols in the files.

cscope builds the symbol cross-reference the first time it is used on the source files for the program being browsed. On a subsequent invocation, cscope rebuilds the cross-reference only if a source file has changed or the list of source files is different. When the cross-reference is rebuilt, the data for the unchanged files are copied from the old cross-reference, which makes rebuilding faster than the initial build. 

 Tutorials and man pages are found in this link

http://cscope.sourceforge.net/

Installing cscopr in ubuntu

$ sudo apt-get install cscope

or

You can download the tarball here. Extract the contents into a convenient directory, and let’s get ready to roll.

To install Cscope, open a terminal and navigated to the extracted directory.
Now run the commands

./configure
make
sudo make install 

This should install cscope on your computer. I use cscope with emacs, so the next set of steps explain how to integrate it with emacs. If you wish to use csope with other browsers, please visit their website (http://cscope.sourceforge.net) for instructions.

1) Make the ‘cscope-indexer’ script (in cscope/contrib/xcscope) executable.

sudo chmod a+x ./contrib/xcscope/cscope-indexer 

2)Copy it into /usr/bin or /usr/sbin (it needs to be in $PATH)

sudo cp ./contrib/xcscope/cscope-indexer /usr/bin 

3)Copy the file xcscope.el (in cscope/contrib/xcscope) to /etc/emacs (basically it has to be in the emacs load-path)

sudo cp ./contrib/xcscope/xcsope.el /etc/emacs 

4)Edit your ~/.emacs file and add the line

(require ‘xcscope) 

Now you can use the cscope key bindings in emacs. Here is a list of the most common key-bindings:

1) to create a cscope database for your code files, navigate to the topmost direcory (under which all your code directories of current project are) in emacs (using C-x,C-f) and type C-c s I. This should create the files cscope.out and cscope.files. These together represent your database

2)While browsing through any source code file, use the following bindings:
C-c s s Find symbol.
C-c s d Find global definition.
C-c s g Find global definition (alternate binding).
C-c s G Find global definition without prompting.
C-c s c Find functions calling a function.
C-c s C Find called functions (list functions called
from a function).
C-c s t Find text string.
C-c s e Find egrep pattern.
C-c s f Find a file.
C-c s i Find files #including a file.

3)To navigate the cscope search results use:
C-c s n Next symbol.
C-c s N Next file.
C-c s p Previous symbol.
C-c s P Previous file.

4)Once you have satisfied your curiosity, you can return to the point from where you jumped using
C-c s u Pop Mark

And thus, you have complete control over code navigation! I have used the file xcscope.el as a reference, and it goes on to detail far more complex tasks using cscope. Look into it once you get the hang of cscope!

How to setup lxr (Linux cross-Referencd) in ubuntu

The Linux Cross-Reference project is the testbed application of a general hypertext cross-referencing tool. (Or the other way around.)

The main goal of the project is to create a versatile cross-referencing tool for relatively large code repositories. The project is based on stock web technology, so the codeview client may be chosen from the full range of available web browsers. On the server side, any Unix-based web server with cgi-script capability should do nicely.

The main feature of the indexer is of course the ability to jump easily to the declaration of any global identifier. Indeed, even all references to global identifiers are indexed. Quick access to function declarations, data (type) definitions and preprocessor macros makes code browsing just that tad more convenient. At-a-glance overview of e.g. which code areas that will be affected by changing a function or type definition should also come in useful during development and debugging.

Other bits of hypertextual sugar, such as e-mail and include file links, are provided as well, but is on the whole, well, sugar. Some minimal visual markup is also done. (Style sheets are considered as a way to do this in the future.

Technicalities

The index generator is written in Perl and relies heavily on Perl’s regular expression facilities. The algorithm used is very brute force and extremely sloppy. The rationale behind the sloppiness is that too little information renders the database useless, while too much information simply means the users have to think and navigate at the same time.

The Linux source code, with which the project has initially been linked, presents the indexer with some very tough obstacles. Specifically, the heavy use of preprocessor macros makes the parsing a virtual nightmare. We want to index the information in the preprocessor directives as well as the actual C code, so we have to parse both at once, which leads to no end of trouble. (Strict parsing is right out.) Still, we’re pretty satisfied with what the indexer manages to get out of it.

There’s also the question of actually broken code. We want to reasonably index all code portions, even if some of it is not entirely syntactically valid. This is another reason for the sloppiness.

There are obviously disadvantages to this approach. No scope checking is done, and the most annoying effect of this is mistaking local identifers for references to global ones with the same name. This particular problem (and others) can only be solved by doing (almost) full parsing. The feasibility of combining this with the fuzzy way indexing is currently done is being looked into.

An identifier is a macro, typedef, struct, enum, union, function, function prototype or variable. For the Linux source code between 50000 and 60000 identifiers are collected. The individual files of the sourcecode are formatted on the fly and presented with clickable identifiers.

It is possible to search among the identifiers and the entire kernel source text. The freetext search is implemented using Glimpse, so all the capabilities of Glimpse are available. Especially the regular expression search capabilities are useful.

---

Availability

The code for the indexer is released under the GNU Copyleft license. Go to LXR main site to get the latest version.

Steps to setup lxr in ubuntu

Required Packages :

Apache – Web server

lxr -Linux Cross Reference –

Perl – Reference generator

Install the packages

$ sudo apt-get install lxr perl apache2


$ sudo vi /etc/apache2/sites-enabled/000-default

Add these lines to “/etc/apache2/sites-enabled/000-default”

$ sudo vi etc/apache2/sites-enabled/000-default/

            # Linux Cross Reference Stuff          

             Alias /lxr /usr/share/lxr

            <Directory usr/share/lxr>

            Options All

           AllowOverride All

           </Directory>

Create a file /usr/share/lxr/http/.htaccess which contains:

$ sudo vi /usr/share/lxr/http/.htaccess

<Files ~ (search|source|ident|diff|find)$>

SetHandler cgi-script

</Files>

Restart your apache web-server

$ sudo /etc/init.d/apache2 restart

Now we will setup the cross reference.

i). Create /usr/share/lxr/source if it doesn’t exist.

ii). Create a directory 2.6.39 inside it – this is the linux version I am cross referencing.

$ sudo mkdir /usr/share/lxr/source/2.6.39 -p

 Untar the kernel source inside this directory in a subdirectory ‘linux’ .. i.e., you now have /usr/share/lxr/source/2.6.39/linux with the source in the linux directory.

$ cd /usr/share/lxr/source/2.6.39 ; sudo tar zxvf linux-2.6.39.tar.gz

Create andAdd a line with contents ’2.6.39′ (without the single quotes) in /usr/share/lxr/source/versions

Create a link from /usr/share/lxr/source/2.6.39 to /usr/share/lxr/source/defversion

$ sudo ln -s /usr/share/lxr/source/2.6.39 /usr/share/lxr/source/defversion

Change the director to /usr/share/lxr/source/2.6.39 and execute ‘genxref linux’

$ cd/usr/share/lxr/source/2.6.39 ; sudo genxref linux

Make sure that all the files inside /usr/share/lxr/source/2.6.39 has “read” permission

$ sudo chmod -R o+r /usr/share/lxr/source/2.6.39/*

10 minutes later click here: http://localhost/lxr/http/blurb.html

Then click “Browse The Code”