Cross Compiling – Reblog

Original Blog : http://baruch.siach.name/blog/posts/introduction_to_cross_compilation_part_1/

Introduction to Cross Compilation, Part 1

This post is the first in a series on cross compilation. In this series I’ll introduce the concept of cross compilation, and how to used it. Although there are many different uses for cross compilation, I’ll focus in this series in its use for embedded Linux systems development.

What is Cross Compilation?

When you develop a desktop or server application, almost always the development platform (the machine that runs your compiler) and the target platform (the machine that runs your application) are the same. By “platform” I mean the combination of CPU architecture, and Operating System. The process of building executable binaries on one machine, and run them on another machine when the CPU architecture or the Operating System are different is called “cross compilation”. A special compiler is needed for doing cross compilation that is called “cross compiler“, and sometimes just “toolchain”.

For example, desktop PC application developers for Windows or Linux can build and run their binaries on the very same machine. Even developers of server applications generally have the same basic architecture and Operating System on both their development machine and server machine. The compiler used in these cases is called “native compiler”.

On the other hand, developers of an embedded Linux application that runs on a non PC architecture (like ARM, PowerPC, MIPS, etc.) tend to use a cross compiler to generate executable binaries from source code. The cross compiler must be specifically tailored for doing cross compilation from the development machine’s architecture (sometimes called “host”), to the embedded machine’s architecture (called “target”).

Note: cross compilation is only needed when generating binary executables from source code written in a compiled language, like C or C++. Programs written in interpreted language, like Perl, Python, PHP, or JavaScript, do not need a cross compiler. In most cases interpreted programs should be able run unchanged on any target. You do need, however, a suitable interpreter running on the target machine.

What is Cross Compilation Good for?

I have covered above one reason for doing cross compilation, that is, the target machine has a different CPU architecture that the development host. In this case cross compilation is necessary because the binaries that the native compiler generates won’t run on the target embedded machine.

Sometimes cross compilation is not strictly necessary, but native compilation in not practical, or inconvenient. Consider, for example, a slow ARM9 based target machine running Linux. Having the compiler run on this target will make the build process painfully slow. In many cases target machine is just under-powered, in terms of storage and RAM, for the task of running a modern compiler.

Practically speaking, almost all embedded Linux development is being done with cross compilers. Strong PC workstation machines are used as development hosts to run the development environment (text editor, IDE), and the cross compiler.
Obtaining a Cross Compiler

The easiest way to obtain a cross compiler is to download a ready made pre-built one. Besides being easy to obtain a pre-built binary toolchain is the most useful for the general case of building a kernel and a userspace filesystem. Some special cases require a specially tailored toolchain built from source. I’ll show how to build a toolchain from source in the next post.

A short terminology note: in the following text I use the terms “cross compiler” and “toolchain” interchangeably. The have the same meaning in this context. The term “toolchain” seems to be more popular, however.

Sourcery

The most well known source of pre-built cross compilers is the embedded software division of Mentor Graphics, formerly known as CodeSourcery, an independent company that Mentor has acquired in 2010. They release the “Sourcery CodeBench Lite Edition” free of charge. Sourcery CodeBench is a collection of cross compilers for several CPU architectures, including ARM, PowerPC, MIPS, and Intel x86 among the others. For each architecture there are a number of target options. The one you need for embedded Linux work is the “GNU/Linux release”. Always select the latest version, unless you have a very good reason to avoid it. Then, there are a few packaging formats to choose from. I prefer the “IA32 GNU/Linux TAR” format. Installing it is just a matter of extracting the tar file in the /opt directory. For example, to install the latest MIPS toolchain do as root

tar xjf mips-2011.09-75-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2 -C /opt
One big advantage of Sourcery’s toolchains is that those making them, former CodeSourcery employees, are deeply involved in upstream development of the GCC compiler.

Linaro

The Linaro organization also releases pre-built cross compilers for their target platform, newer ARM processor based on Cortex-A. Download the latest version from here. You need the “Linux binary” one.

Using the Cross Compiler

This is just a quick peek at cross compiling for the impatient new embedded Linux coder. I’ll come back to this issue later in some greater depth.

First, put your newly installed toolchain in your path. For example, the Sourcery MIPS toolchain mentioned above needs the following command:

export PATH=$PATH:/opt/mips-2011.09/bin

Create a simple “Hello World” program, and save it in hello.c:

#include 
int main (void) {
    printf ("Hello World!\n");
    return 0;
}

Compile your program using the MIPS toolchain as follows:

mips-linux-gnu-gcc -Wall -o hello hello.c

Copy the resulting hello binary file to you target machine and run it there. If all goes well you should see the expected output.

There are many details to get wrong here, ranging from ABI issues, to C library and kernel version compatibility. I’ll cover some of these issues in future posts.

Advertisements

[ Raspberry Pi ] Remote Connection | PC | Ubuntu | SSH

This tutorial is to connect RPI remotely through SSH in Ubuntu.

  1. Connect the LAN Cable to Router and RPI
  2. Find the IP of Raspberry Pi Board.
  3. Screenshot from 2013-05-12 08:08:24Default credentials
    User name : pi
    Password : raspberry
  4. SSH into the RPI
     ssh pi@192.168.1.4
  5. Voila!! Got it.. You are inside RIPScreenshot from 2013-05-12 08:51:22

Writing a Well Documented Code With Doxygen

Goal : To give a push start on how to start with good well self 
       documenting code and generate a easy document using doxygen.
Pre-requiset : Doxygen installed on your ubuntu machine..
sudo apt-get install doxygen

Doxygen is a wonderful document generation application available for any programmer.
What I feel is, when you start coding with the intention of creating a document using Doxygen, you will end up with a awesome, well self explaining code ever.
Here is a simple example to start with using Doxygen for C program.

While creating a file, start always with the License header, which implies you code is reusable to a good scale.

/**
* DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
* Version 2, December 2004
*
* Copyright (C) 2004 Sam Hocevar <sam@hocevar.net>
*
* Everyone is permitted to copy and distribute verbatim or modified
* copies of this license document, and changing it is allowed as long
* as the name is changed.
*
* DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
* TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
*
* 0. You just DO WHAT THE FUCK YOU WANT TO.
*/

* The above License is actually a valid License, if anyone this that I am playing..
** This is the License created by the Ex-Debian Project Leader and a big contributor to VLC code Sam_Hocevar
Always give a description of what a file is going to contain and used for, with revision history. It will give you a better clarity on what has to be done and what is the purpose of having that file.

/**
* @file \file_name.c
* @author \you
* @date \today
* @brief This file is for blah blah drup doom code to invoke a thermo-nuclear
* war for fun.
* @param[in] argument1 - Used to simply say i have argument 1
* @param[in] argument2 - Used to simply say i have argument 2
* @param[in] argumentn - Used to simply say i have upto argument n
* @param[out] out argument1 - Used to simply say I am doing something upto
* provide a output
* @return - I do return a status of what happened inside this black hoel!!
*/

start with sections of what its going to do inside.. like..

/* Declaration of required variables */
..
.
.
..

/* I am going to sleep for n seconds */
sleep(n);

Name every variable as that is going to explain the need, like,

/* This variable is used to keep a count of
number of iterations happened and I feel
Its better to have a meaningful variable
name than to have like int i.. */

uint8_t iteration_count = 0;

So, Now you have your example code done..
Hope you will have a well self documented code by now..
Next, go and generate the Doxygen config file to produce the documentation.

cd /location/of/my/code/
doxygen -g
ls

This would have generated a file as Doxyfile

Now open and edit few things on this..

gvim Doxyfile

# PROJECT_NAME = "My Project"
# PROJECT_NUMBER =
# PROJECT_BRIEF =
# INPUT =
# RECURSIVE = NO

to

PROJECT_NAME = "Your Project Tilte"
PROJECT_NUMBER = "0.0.1"
PROJECT_BRIEF = "This is to learn Doxygen"
INPUT = /your/source/location/
RECURSIVE = YES

This is just a piece of cake… all the configuration variables are self explanatory.. explore more..

now, run,

doxygen Doxyfile
ls

Yes… Its done.. Go and open html/index.html.

you have your documentation for your code here in html..

You want in PDF? That too in latex??
Just install latex on your machine and follow this..

sudo apt-get install latex;

cd /your/source/code/location/latex;
make;

voila.. you are done…

HowTo Restart a Daemon/Program in Linux if it Crashes/Killed

Most of security critical applications/services are pron to attacks and the first try is to kill/remove the process/application. Here in this post, im writing about the method to prevent the first try, to kill the service.

One method, is to restart the application when it is killed. For making an service/process to run as a daemon, In Linux, we can add a launching script at /etc/init.d/ directory, so that it will be started at the bootup init.

Here is a simple hello world program to demonstrate it.


#include
int main() {
     while(1) { /* Continue forever as a daemon */
     printf("Hello world\n");
     sleep(1); /* Sleep for one minute */
    }
}

Now compile it into hello.out and create a startup script to add it to init.d as below.

raj@08:39:10:$ gcc hello.c -o hello.out

while ! /home/raj/hello.out   #This will wait for the program to exit successfully .
do
echo “restarting”                  # Else it will restart.
done

Add this script hello.sh /etc/init.d/ to start it at boot time. But now, we can test it without rebooting.

Provide execution permission to the script and run the script on one termnial.

raj@08:39:22:$ sudo chmod +x /home/raj/hello.sh
raj@08:39:32:$ ./hello.sh

Now you can see the program running and printing Hello world string once in one minute. Now open one more terminal and kill this process by finding its pid as below.

raj@08:40:07:$ pidof hello.out
26685
raj@08:40:20:$ sudo kill 26685.

Now, you can see the process being started again.
Here is screenshot to give an overview.

Screenshot from 2012-12-02 08:40:54

 

Surely there will be may better ways, would like to know and if i come to know, i will update this. 🙂

Howto setup su root in ubuntu

By default, ubuntu distribution doesnt provide password for su/root user. Here is how to setup a password for su.

Run this on terminal. [ Ctlr + Alt + T ]

sudo passwd

Enter your password and it will ask for new password.
Enter it, and you are done.

More information : http://www.howtogeek.com/111479/htg-explains-whats-the-difference-between-sudo-su/

bc, Shell or cli Calculator

You can do calculations on your CLI/Shell/Terminal itself.
There is a utility called bc.

From man page,:

NAME bc – An arbitrary precision calculator language

SYNTAX bc [ -hlwsqv ] [long-options] [ file … ]

DESCRIPTION bc is a language that supports arbitrary precision numbers with interactive execution of statements. There are some similarities in the syntax to the C programming language. A standard math library is available by command line option. If requested, the math library is defined before processing any files. bc starts by processing code from all the files listed on the command line in the order listed. After all files have been processed, bc reads from the standard input. All code is executed as it is read. (If a file contains a command to halt the processor, bc will never read from the standard input.) This version of bc contains several extensions beyond traditional bc implementations and the POSIX draft standard. Command lineoptions can cause these extensions to print a warning or to be rejected. This document describes the language accepted by this processor. Extensions will be identified as such.

Some simple example :

# 10+20
echo “10+20” | bc

# Convert decimal number 10 to hexadecimal number
echo “obase=16; 10” | bc

# Convert Hexadecimal number 10 to decimal number
echo “ibase=16; 10” | bc

# Convert Binary number 10 to decimal number
echo “ibase=2; 10” | bc

# Convert Decimal number 10 to Binary number
echo “obase=2; 10” | bc

You can also use printf, ofcourse, yes its like C.. 😛 as below

printf ‘%x’ 16

Optical Character Recognition in Ubuntu

Today, I was trying to capture some logs from QEMU. But unfortunately, i couldnt start logging qemu easily.
So Thought to capture the image and take up OCR to get text. Ubuntu has gocr, which i could use.

Installing gocr:

sudo apt-get install gocr

Using GOCR :

gocr -h for list of usage

Simply to extract text from a screenshot, i followed this.

raj@14:19:31:$ gocr -i ~/Pictures/Screenshot\ from\ 2012-11-25\ 14\:18\:40.png -o out.txt

Output is pretty acceptable, even though its not accurate.