Archive for the ‘Linux’ Category

Building the Android kernel

Velibor Cakarevic

 
 
Downloading Android kernel code

If you download Android 2.1 platform you will not get the source code of the kernel. This is due to that there is quite a huge amount of code needed to be downloaded, it takes time to build the kernel and not many application developers are interested in the kernel code. Below is a description of how to download the Android source code and compile it for ARM, using Linux as your OS. Note that porting to hardware is not in the scope of this description.

First go to your home directory and create a directory where you wish to work in, e.g. myAndroid and step into that directory. Note that ‘$’ is not part of a command but illustrates in this document the commands.
$ cd ~
$ mkdir myAndroid
$ cd myAndroid

To clone the common Android kernel and get the kernel code use the command:

$ git clone git://android.git.kernel.org/kernel/common.git android-kernel

The command creates a new folder called ‘android-kernel’ (you can choose another name if you wish) in your ‘myAndroid’ folder and downloads the kernel code.

Go to that folder:

$ cd android-kernel

Building the Android kernel code

Android relies on Linux version 2.6. When building the kernel you will do these commands:
$ make menuconfig
$ make

The command ‘make menuconfig’ configures the kernel. This process involves specifying what functionality to put into the kernel. Additionally, decisions have to be made (when possible) whether kernel code should be statically or dynamically linked. Statically linking means that all modules are built and linked into the kernel. Optimized static kernels execute much faster, since there are no shared object lookups and their binary size is smaller.

With dynamic loading you can choose to manually load the modulus to the kernel by using insmod or modprobe tool/command. Loadable kernel modules allow changing code during runtime. Loadable modules are pieces of kernel code which are not linked (included) directly in the kernel. One compiles them separately, and can insert and remove them into the running kernel at almost any time. If you want a module to be dynamically loaded give it the option <M> during ‘make config’ procedure.

If you want to make an own module you should enable the module support after doing ‘make menuconfig’

Loadable module support —> [*] Enable loadable module support

When building for another processor architecture than the one that your host processor uses you must use a crosscompiler and set the architecture parameter. This will show you how to compile the code for an ARM processor architecture. Before doing ‘make menuconfig’ set the architecture parameter:

$ export ARCH=arm

Now start the configuration of the kernel:

$ make menuconfig


Picture 1 shows the menu when configuring the kernel.

After having modified the configuration you will at the exit be prompted by a question, whether you wish to save the changes. Choose Yes if you want to do so. You can check the generated .config file by:

$ nano .config

To set the crosscompiler use do the command:

$ export CROSS_COMPILE=arm-unknown-linux-gnueabi-

Note! I am using a compiler that you may not have. If you have downloaded the whole Android 2.1 platform (perhaps you have it in another folder) you could use
~/your_android_platform_folder/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-

In that case the command to set the cross-compiler as the one delivered and precompiled in the Android platform is:

$ export CROSS_COMPILE=~/your_android_platform_folder/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-

Make starts the build process and builds the kernel according to the configuration file. To start the build process do:

$ make

The image is generated in the folder: arch/arm/boot/zImage

If you wish to search for the zImage use the find command:
$ find -name ‘zImage’

Some tips

When configuring the kernel in the menu (see figure 1) there may be some flags that you cannot remove. However you can still modify the ‘.config’-file directly if you wish to. You should on the other hand be sure of what you are doing. When building again, i.e. make you will be prompted by a question if you wish to keep that flag. Press ‘n‘ to exclude the module. If this question does not appear it is most likely that the module has not been removed.

When working with building of the kernel, the best approach is to remove modules that are not necessary in your kernel, and when adding new modules add them step by step. This will give you a fair chance to fix errors such as build failures, but also track down crashes when running on target.

When you have build errors and keep removing flags (i.e. modules) it is good to remove the object files and make a new build. Removing the objectfiles and rebuilding the kernel is done accordingly:
$ make clean
$ make

Edited 5 times. Last edit by KennyLeopold Amanda on Apr 22, 2011 at 8:46:27 PM (about 15 weeks ago).
March 15, 2011 3:35:08 PM PDT (22 weeks ago)
PhotoJayson Burak

 
BAE Systems
Member since Mar 15, 2011
Posts: 1
Hi there,

I apologize for asking a stupid question, but I’m curious as to what the next steps are from here, once the new zImage has been created…or in other words, how do I get the zImage loaded on the device? I have found a few different options, but none of them seem to work for me. What I mean by that is that whenever I try to flash new kernel or new boot image (kernel + ramdisk) to my device, it does not load. I don’t get any errors during the build or make process. So, I am either flashing the device wrong or something else that I have no knowledge of. Any help would be appreciated. Thanks.

~ Jay

March 16, 2011 1:25:26 AM PDT (22 weeks ago)
PhotoVelibor Cakarevic

 
 
Member since Apr 22, 2010
Location: Malmo
Posts: 2
Hello Jayson,

It is hard to tell what might be causing the device not to display the home screen. If you flash procedure would fail then you should get an error message during that procedure.

The zImage is an compressed code that is unzipped at the boot procedure. You can see the procedure in the command prompt when the device boots up (some boot-loaders print a dotted line to animate the procedure). If it is uncompressed then that should be a good sign, that you have flashed it ‘corrrectly’ (but I am comparing to my own projects). You tell the bootloader (set the environment variables) which memory address the image is stored at. I do not know which bootloader you are using but Uboot is the one I have been using [1].

Further you might not have the correct driver code for the display. Such driver code (Linux driver code) should be delivered to you by the vendor. You could ask them about this issue as well.

Have you enabled/added the display driver module (in the “make menuconfig”)? If it is statically linked (‘*’) it is built in the kernel. If it is dynamically linked (‘M’) then the kernel will load/insert the module in the runtime. You can also insert the modules manually by the ‘insmod’ [2] or ‘modprobe’ [3] command.

One tip is to mount the device’s filesystem on to a laptop (done in the bootloader by setting parameters) i.e. you boot up the device but the device gets the filesystem from a folder on your laptop. From there you can insert modules. This approach (mounting the filesystem) makes is ‘easier’ to work since you (most probably) have more space on your laptop then on your device and do not have to flash the filesystem on your device (saves you time).

Further if you are using Beagleboard, then there are ported versions of Android for their device.[4]

Google has also added some information since I posted this article. Please have a look at the “Android Platform Developer´s Guide” [5]

In order to help you I would have to be sitting next to you.

[1] http://www.denx.de/wiki/U-Boot/WebHome
[2] http://linux.about.com/od/commands/l/blcmdl8_insmod.htm
[3] http://linux.about.com/od/commands/l/blcmdl8_modprob.htm
[4] http://labs.embinux.org/index.php/Android_Porting_Guide_to_Beagle_Board
[5] http://source.android.com/porting/display_drivers.html

http://seg.sharethis.com/getSegment.php?purl=http%3A%2F%2Ffypandroid.wordpress.com%2Fwp-admin%2Fpost-new.php&jsref=&rnd=1313654342140

Reference

http://marakana.com/forums/android/examples/111.html

 
As we know, Java 1.5 has not been maintained anymore and Java 6, has been hanging around for a while and Java 7 is coming soon. But it doesn’t mean everybody has to move on to Java 1.6. The problem in Ubuntu is they force you to use OpenJDK. Worse yet, they don’t let you downgrade to 1.5.There are lots of legacy systems running on Java 5 and we can’t forget that. It is also about freedom of choice. If you want to install Sun JDK 5 or 6 Ubuntu should not make your life difficult.

Ubuntu 10 and 11 don’t allow us to natively (or easily) install Sun JDK’s via apt-get.

It is so frustrate when we try to install it on Ubuntu 10.10 and have no luck:

sudo apt-get install sun-java5-jdk (or sudo apt-get install sun-java6-jdk)

After installed, the JDK will go to this directory: /usr/lib/jvm/java-6-sun

You can see all JDK’s installed running the following command:

sudo update-java-alternatives -l

After a while, finally got the solution for this:

sudo add-apt-repository “deb http://us.archive.ubuntu.com/ubuntu/ jaunty multiverse”

sudo add-apt-repository “deb http://us.archive.ubuntu.com/ubuntu/ jaunty-updates multiverse”

sudo apt-get update

sudo apt-get install sun-java5-jdk

Check it out just to confirm:

sudo update-java-alternatives -l

The commands above worked for me in Ubuntu 10 and 11, installing Sun JDK 1.5 and 1.6.
If it doesn’t work, try to add the following repositories and repeat the process: (anonymous suggestion – thanks a lot):

sudo add-apt-repository “deb http://us.archive.ubuntu.com/ubuntu/ hardy multiverse”
sudo add-apt-repository “deb http://us.archive.ubuntu.com/ubuntu/ hardy-updates multiverse”

Cheers
http://leonardo-pinho.blogspot.com/2010/11/java-15-no-ubuntu-1010.html

ntroducing the BeagleBoard-xM

The BeagleBoard is a pocket-sized reference board containing a Texas Instruments Open Multimedia Application Platform (OMAP) 3 system-on-a-chip (SoC) processor, which includes an ARM Cortex-A8 core, Texas Instruments C64x+ digital signal processor (DSP), and onboard graphics engine, as well as integrated dual data rate (DDR) random-access memory (RAM). The BeagleBoard is an inexpensive platform for hobbyists, academics, and professionals who are learning Linux and small systems. Figure 1 shows the BeagleBoard-xM.
Figure 1. BeagleBoard-xM
Picture of the BeagleBoard-xM

In a previous developerWorks article, I explored booting Linux on BeagleBoard revision C, which hosts a 600MHz OMAP3530 processor, 256MB RAM, and 256MB NAND flash memory. Revision xM is more robust with a 1GHz OMAP3730 processor and 512MB RAM. It boots from the microSD card with no flash memory and hosts new interfaces, including a DB-9 serial connector, integrated 4-port Universal Serial Bus (USB) hub, and integrated Ethernet port. The BeagleBoard-xM retains many revision C features, including Digital Visual Interface (DVI)-D output, S-video, audio, Joint Test Action Group (JTAG), and a large expansion header.

Back to top

Building your working environment

The following sections show you how to source required components, set up, and test the console.

Sourcing components

The BeagleBoard-xM is packaged with a preformatted 4GB microSD card along with an adapter so you can plug the card into a standard Secure Digital (SD)/MultiMediaCard (MMC) slot, but no cables. You need the following:

Powering the BeagleBoard-xM

Traditionally, the BeagleBoard is powered from either an external 5V power source or a USB On-The-Go (OTG) cable. These cables, however, provide only up to 500mA, barely enough to power the xM. It is highly recommended that you use an external power supply—either a 5V power brick with a 2.1mm barrel (positive center) or a Y cable that plugs into two USB ports on your host.

  • Power supply
    Use a 5V external power supply.
  • Serial cable
    The BeagleBoard-xM provides a female DB9 port and requires a serial cable to connect the console to your host system. Use a straight-through (not null-modem) cable. If your host system has no serial port, use a DB9-to-USB cable.
  • USB keyboard and USB mouse
  • DVI-D capable monitor and a DVI-D to High-Definition Multimedia Interface (HDMI) cable
    Note that the board does not emit Video Graphics Array (VGA) signals through this connector, so a standard DVI-to-VGA converter cable won’t work.
  • 4GB+ microSD cards and a card reader
    You can overwrite the data on the provided card, but it is better to purchase a few cards to use with different distributions. Use a USB card reader if your host has no integrated reader.

Setting up the console

Linux users can use minicom, shown in the examples that follow. Microsoft® Windows® users can use Hyperterminal or PuTTy, and Mac users can use screen, ZTerm, or MacWise.

Connect the serial cable to the BeagleBoard-xM’s DB9 port and your host, and launch minicom in setup mode as root:

sudo minicom -s

 

Listing 1 shows the minicom configuration menu.
Listing 1. minicom configuration menu

            +-----[configuration]------+
            | Filenames and paths      |
            | File transfer protocols  |
            | Serial port setup        |
            | Modem and dialing        |
            | Screen and keyboard      |
            | Save setup as dfl        |
            | Save setup as..          |
            | Exit                     |
            | Exit from Minicom        |
            +--------------------------+

 

Select Serial port setup. The resulting sub-menu is shown in Listing 2.
Listing 2. minicom serial port setup menu

    +-----------------------------------------------------------------------+
    | A -    Serial Device      : /dev/ttyS0                                |
    | B - Lockfile Location     : /var/lock                                 |
    | C -   Callin Program      :                                           |
    | D -  Callout Program      :                                           |
    | E -    Bps/Par/Bits       : 115200 8N1                                |
    | F - Hardware Flow Control : No                                        |
    | G - Software Flow Control : No                                        |
    |                                                                       |
    |    Change which setting?                                              |
    +-----------------------------------------------------------------------+
            | Screen and keyboard      |
            | Save setup as dfl        |
            | Save setup as..          |
            | Exit                     |
            | Exit from Minicom        |
            +--------------------------+

 

If your cable is a straight-through serial cable, the serial device is /dev/ttyS0. If you use a USB converter, use /dev/ttyUSB0. If no text appears in the next step, it is possible your host assigned a different device, so increment 0 to 1 and try again. For all devices, the settings are 115200, 8 bits, no parity, 1 stop bit, and no hardware or software flow control.

When your settings are correct, save this setup as the default by choosing Save setup as dfl and then Exit. The minicom welcome message appears, as shown in Listing 3.
Listing 3. minicom welcome message

Welcome to minicom 2.3

OPTIONS: I18n
Compiled on Oct 24 2008, 06:37:44.
Port /dev/ttyS0

       Press CTRL-A Z for help on special keys

 

To verify, apply power to your BeagleBoard-xM, and type a key to stop the boot countdown. Boot-loader messages appear showing the X-loader and U-boot version, date of build, and output, with U-boot showing specifics about system memory, input and output channels, expansion board information, and the board’s revision and die ID, as shown in Listing 4.
Listing 4. X-Loader and U-Boot

Texas Instruments X-Loader 1.4.4ss (Aug 19 2010 - 02:49:27)
Beagle xM Rev A
Reading boot sector
Loading u-boot.bin from mmc

U-Boot 2010.03-dirty (Aug 20 2010 - 20:50:46)

OMAP3630/3730-GP ES1.0, CPU-OPP2, L3-165MHz,
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  512 MB
NAND:  256 MiB
In:    serial
Out:   serial
Err:   serial

Probing for expansion boards, if none are connected you'll see a harmless I2C error.

No EEPROM on expansion board
Beagle xM Rev A
Die ID #77f600001bf00000015739ea0701c021
Hit any key to stop autoboot:  0
OMAP3 beagleboard.org #

 

Unplug power from your BeagleBoard-xM.

Preparing to boot Linux

Monitor cable

Make sure to never plug the monitor cable in while the board is powered, because that could damage the board. Always unplug the power first.

Plug your keyboard and mouse into the USB sockets on the BeagleBoard-xM. Plug a network cable, if available, into the Ethernet jack. Connect the HDMI-to-DVI cable between the board and a DVI-D monitor.

The following instructions are intended only to get your board up and running with these three Linux distributions. The links in Resources contain development kits, toolchains, and instructions for setting up full development environments.

Back to top

Booting Angstrom Linux

Angstrom Linux is an operating system developed specifically for small computers such as the BeagleBoard-xM. The fastest way to boot Angstrom on the BeagleBoard-xM is with the microSD card that comes with the board, which contains an Angstrom image. However, the image on that card is a verification image, which means that it is provided only to verify the board’s operation. It does not contain a graphical user interface (GUI) and boots by default as a RAM disk; thus any changes you make are lost when you unplug.

The included microSD card contains a single File Allocation Table (FAT) partition of approximately 117MB, containing the following:

  • Boot loaders X-loader (MLO) and U-boot (u-boot.bin)
  • Linux kernel (uImage)
  • Boot script (user.scr)
  • RAM disk root file system (ramdisk.gz)
  • md5sum file to check file sizes

The rest of the card is unformatted.

To boot, insert the microSD card and apply power. After the boot countdown, the system automatically invokes the boot script. The boot-loader text is shown again on the console, followed by boot messages showing the boot processes, including execution of the script itself, loading the kernel and RAM disk, and finally starting the kernel, as shown in Listing 5.
Listing 5. Booting Angstrom

mmc1 is available
The user button is currently NOT pressed.
reading boot.scr

** Unable to read "boot.scr" from mmc 1:1 **
reading user.scr

755 bytes read
Running bootscript from mmc ...
## Executing script at 80200000
mmc1 is available
reading ramdisk.gz

19960110 bytes read
reading uImage

3190568 bytes read
Booting from ramdisk ...
## Booting kernel from Legacy Image at 80200000 ...
   Image Name:   Angstrom/2.6.32/beagleboard
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3190504 Bytes =  3 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux.....................................................................
[    0.000000] Linux version 2.6.32 (ubuntu@ip-10-204-115-71) (gcc version 4.3.3 .......

 

Linux boot messages follow, and then finally the Angstrom logo and a login prompt, as shown in Listing 6.
Listing 6. Angstrom login console

.-------.                                          
|       |                  .-.                     
|   |   |-----.-----.-----.| |   .----..-----.-----.
|       |     | __  |  ---'| '--.|  .-'|     |     |
|   |   |  |  |     |---  ||  --'|  |  |  '  | | | |
'---'---'--'--'--.  |-----''----''--'  '-----'-'-'-'
                -'  |
                '---'

The Angstrom Distribution beagleboard ttyS2

Angstrom 2010.7-test-20100820 beagleboard ttyS2

beagleboard login:

 

Log in as root, no password necessary. You can run basic Linux commands to test the system. Try running testled, and watch the light-emitting diodes (LEDs) on the BeagleBoard-xM.

To see Angstrom in action, you need a full root file system and a matching kernel. The following instructions show how to download and boot the demo image:

  1. Navigate to the Angstrom BeagleBoard demo page and read the instructions.
  2. Download the binary images for the boot loader and root file system from the Angstrom BeagleBoard demo page. There files you need are:
    • mkcard.txt
    • MLO
    • u-boot.bin
    • Angstrom-Beagleboard-demo-image-glibc-ipk-2010.3-beagleboard.rootfs.tar.bz2
  3. Insert a microSD card with at least 4GB capacity, and determine its device name. For example, if you are using a USB card reader, use fdisk and look for a disk matching the card’s characteristics. The following example shows /dev/sdg:
    # fdisk -l
    ...
    Disk /dev/sdg: 3.9 GB, xxx bytes
    255 heads, 63 sectors/track, xxx cylinders
  4. Unmount any partitions on the card. Use your card’s device name in place of /dev/sdgin the following example:
    sudo umount /dev/sdg?
  5. Format your SD card using the mkcard.txtscript.Note: Be certain that you are targeting your SD card and not a system disk.

    Use your card’s device name in place of /dev/sdg in the following example:

    chmod +x mkcard.txt ; sudo ./mkcard.txt /dev/sdg

    When the operation is done, your microSD card contains two primary partitions:

    • One 70MB FAT partition labeled boot.
    • One ext3 partition labeled Angstrom that takes up the rest of the card’s capacity.

    If your system does not automatically mount these partitions after the script creates them, mount them by hand, replacing your card’s device name for /dev/sdg in the following example:

    sudo mkdir -p /media/boot ; sudo mount /dev/sdg1 /media/boot
    sudo mkdir /media/Angstrom ; sudo mount /dev/sdg2 /media/Angstrom

    The rest of this example assumes these partitions are mounted as /media/boot and /media/Angstrom.

  6. Unpack files to the root file system partition (this command may take some time):
    sudo tar -C /media/Angstrom -xjvf \
     Angstrom-Beagleboard-demo-image-glibc-ipk-2010.3-beagleboard.rootfs.tar.bz2
  7. Copy files to the boot partition, noting that the kernel image comes directly from the root file system:
    cp MLO /media/boot
    cp u-boot.bin /media/boot
    cp /media/Angstrom/boot/uImage /media/boot
  8. When all operations are done, synchronize file systems and unmount partitions:
    sync ; sudo umount /dev/sdg?
  9. Insert the card into the BeagleBoard-xM and apply power.Note: If the first boot fails with an error like this:
     Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block...

    Restart the system, stop the boot countdown, and type the following command:

    setenv mmcroot /dev/mmcblk0p2 rw

    Then boot the system by typing boot.

The first boot takes a while as the system configures itself. The Angstrom logo appears on the monitor, while on the console each component is configured. After about 10 minutes, an Angstrom login screen appears on the monitor and a boot prompt on the console. Use the login screen to set up a new user and log in. You can also log in on the console as root, no password required.

Back to top

Booting Android

Android has proven to be a popular operating system for the BeagleBoard, as the board is an inexpensive platform for Android application development and testing. There are several ports of Android to the BeagleBoard. This article uses the rowboat project. Be sure to connect a USB keyboard and mouse as well as a DVI monitor before starting.

  1. Download the precompiled binary tarball from the Texas Instruments Android DevKit page, making sure to identify the pre-built image for the BeagleBoard-xM (beagleboard-xm.tar.gz).
  2. Unpack the tarball:
    tar zxvf beagleboard-xm.tar.gz
  3. Read the instructions in README.txt.
  4. Insert a microSD card with at least 4GB capacity, and determine its device name. For example, if you are using a USB card reader, use fdisk and look for a disk matching the card’s characteristics. The following example shows /dev/sdg:
    # fdisk -l
    ...
    Disk /dev/sdg: 3.9 GB, xxx bytes
    255 heads, 63 sectors/track, xxx cylinders
  5. Format your SD card using the provided script.Note: Be certain that you are targeting your SD card and not a system disk.

    Use your card’s device in place of /dev/sdg in the following example:

    mkmmc-android.sh /dev/sdg

    When all operation is done, synchronize file systems and unmount partitions:

    sync ; sudo umount /dev/sdg?
  6. Insert the microSD card into the BeagleBoard-xM and apply power.The first boot takes a while as the system configures itself. After about four minutes, you should see the Android logo and then a home screen. If the network does not activate automatically, wait another five minutes and reboot. Note that the console remains active and automatically logs in as root.

Back to top

Booting Ubuntu

Ubuntu is fast becoming a popular distribution for netbooks, mobile Internet devices (MIDs), and other small systems. Canonical, Ubuntu’s parent company, has dedicated resources to porting Ubuntu to ARM processors such as the BeagleBoard. As with Android, make sure to plug in a monitor and USB keyboard and mouse before starting.

  1. Read the instructions on the Ubuntu OMAP Maverick Install page.
  2. Download the precompiled binary image. Make sure to identify the image for the BeagleBoard-xM: Preinstalled netbook image for TI OMAP3 computers (ubuntu-netbook-10.10-preinstalled-netbook-armel+omap.img.gz). Do not uncompress the image at this time.
  3. Insert a microSD card with at least 4GB capacity, and determine its device name. For example, if you are using a USB card reader, use fdisk and look for a disk matching the card’s characteristics. The following example shows /dev/sdg:
    # fdisk -l
    ...
    Disk /dev/sdg: 3.9 GB, xxx bytes
    255 heads, 63 sectors/track, xxx cylinders
  4. Write the image directly to the card.Note: Be certain that you are targeting your SD card and not a system disk.

    Use your card’s device in place of /dev/sdg in the following example:

    sudo sh -c 'zcat \
     ./ubuntu-netbook-10.10-preinstalled-netbook-armel+omap.img.gz > /dev/sdg'

    Note: If your BeagleBoard-xM is revision A3, you may need to download a different kernel. See the Ubuntu Maverick install page for details.

    When all operations are done, synchronize file systems and unmount partitions:

    sync ; sudo umount /dev/sdg?
  5. Insert the card into the BeagleBoard-xM and apply power.The first boot takes a while as the system configures itself, during which the monitor and console may stay dark. After about 5 minutes, the Ubuntu logo appears on the monitor, followed by a series of system configuration screens. Answer the configuration questions using the keyboard and mouse plugged into the BeagleBoard. If the network does not activate automatically, wait until the system is completely operational, shut it down (go to System and choose Shut Down), and then reboot.

The console does not remain active for Ubuntu. You must interact with the system through the monitor and keyboard or mouse. However, you can install a Virtual Network Computing (VNC) server from the Ubuntu Software Center and interact with the system through VNC.

Back to top

Where to go from here

Each of these operating systems has its own community ecosystem, including web sites, wikis, mailing lists, and Internet Relay Chat (IRC) channels, as does the BeagleBoard itself. Take advantage of these excellent resources while you learn about the BeagleBoard-xM and your chosen operating system.

 

Resources

Learn

Get products and technologies

  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.

Discuss

Reference

http://www.ibm.com/developerworks/linux/library/l-beagleboard-xm/?ca=drs

Introduction to Kernel

Posted: February 7, 2011 in Linux

The kernel makes its services available to the application programs that run on it through a large collection of entry points, known technically as system calls.

 The kernel uses system calls such as ‘read’ and ‘write’ to provide an abstraction of your hardware

From a programmer’s viewpoint, these look just like ordinary function calls, although in reality a system call involves a distinct switch in the operating mode of the processor from user space to kernel space. Together, the repertoire of system calls provides a ‘Linux virtual machine’, which can be thought of as an abstraction of the underlying hardware.

One of the more obvious abstractions provided by the kernel is the filesystem. By way of example, here’s a short program (written in C) that opens a file and copies its contents to standard output:

#include <fcntl.h>

int main()

{

    int fd, count; char buf[1000];

    fd=open(“mydata”, O_RDONLY);

    count = read(fd, buf, 1000);

    write(1, buf, count);

    close(fd);

}

Here, you see examples of four system calls – open, read, write and close. Don’t fret over the details of the syntax; that’s not important right now. The point is this: through these system calls (and a few others) the Linux kernel provides the illusion of a ‘file’ – a sequence of bytes of data that has a name – and protects you from the underlying details of tracks and sectors and heads and free block lists that you’d have to get into if you wanted to talk to the hardware directly. That’s what we mean by an abstraction.

the kernel is responsible for process scheduling. At any one time, there are likely to be several processes (programs) waiting to run.

The kernel’s scheduler allocates CPU time to each one, so that if you look over a longer timescale (a few seconds) you have the illusion that the computer is running several programs at the same time. Here’s another little C program:

#include <stdlib.h>
main()
{
  if (fork()) {
    write(1, "Parent\n", 7);
    wait(0);
    exit(0);
  }
  else {
    write(1, "Child\n", 6);
    exit(0);
  }
}

This program creates a new process; the original process (the parent) and the new process (the child) each write a message to standard output, then terminate. Again, don’t stress about the syntax. Just notice that the system calls fork(), exit() and wait() perform process creation, termination and synchronisation respectively. These are elegantly simple calls that hide the underlying compexities of process management and scheduling.

An even less visible function of the kernel, even to programmers, is memory management. Each process runs under the illusion that it has an address space (a valid range of memory addresses) to call its own. In reality, it’s sharing the physical memory of the computer with many other processes, and if the system is running low on memory, some of its address space may even be parked out on the disk in the swap area.

Another aspect of memory management is that it prevents one process from accessing the address space of another – a necessary precaution to preserve the integrity of a multi-processing operating system.

The kernel also implements networking protocols such as IP, TCP and UDP that provide machine-to-machine and process-to-process communication over a network. Again, this is all about illusions. TCP provides the illusion of a permanent connection between two processes – like a piece of copper wire connecting two telephones – but in reality no permanent connection exists. Note that specific application protocols such as FTP, DNS or HTTP are implemented by user-level programs and aren’t part of the kernel.

The modular kernel

Now we have some idea of what the kernel does, let’s look briefly at its physical organisation. Early versions of the Linux kernel were monolithic – that is, all the bits and pieces were statically linked into one (rather large) executable file.

In contrast, modern Linux kernels are modular: a lot of the functionality is contained in modules that are loaded into the kernel dynamically. This keeps the core of the kernel small and makes it possible to load or replace modules in a running kernel without rebooting.

The core of the kernel is loaded into memory at boot time from a file in the /boot directory called something like vmlinuz-KERNELVERSION, where KERNELVERSION is, of course, the kernel version. (To find out what kernel version you have, run the command uname -r.) The kernel’s modules are under the directory /lib/modules/KERNELVERSION. All of these pieces were copied into place when the kernel was installed.

It’s also possible to configure and build your own kernel. For this, you might try Greg Kroah-Hartman’s Linux Kernel in a Nutshell, an O’Reilly title that makes a delightful but presumably unintended play on words. But, of course, you have to be nuts to make a kernel.

Visual Editor

Posted: January 22, 2011 in Linux

What is VI?

The default editor that comes with the UNIX operating system is called VI (VIsual editor).

The UNIX VI editor is a full screen editor and has two modes of operation:

  1. Command mode commands which cause action to be taken on the file, and
  2. Insert mode in which entered text is inserted into the file.

In the command mode, every character typed is a command that does something to the text file being edited.

In the insert mode, every character typed is added to the text in the file; pressing the <Esc> (Escape) key turns off the Insert mode.

 

NOTE: Both UNIX and VI are case-sensitive. Be sure not to use a capital letter in place of a lowercase letter; the results will not be what you expect.

“*” is used to mention the most commonly used vi commands.


To Get Into and Out Of VI

To Start VI

Use the command below to create a file in VI. If the file named filename exists, then the first page (or screen) of the file will be displayed; if the file does not exist, then an empty file and screen are created into which you may enter text.

* VI filename edit filename starting at line 1

To Exit VI

Usually the new or modified file is saved when you leave VI. However, it is also possible to quit VI without saving the file.

Note: The cursor moves to bottom of screen whenever a colon (:) is typed. This type of command is completed by hitting the <Return> (or <Enter>) key.

*  : x<Return> quit VI, writing out modified file to file named in original invocation
  :wq<Return> quit VI, writing out modified file to file named in original invocation
  :q<Return> quit (or exit) VI
* :q!<Return> quit VI even though latest changes have not been saved for this VI call

Moving the Cursor

The mouse does not move the cursor within the VI editor screen (or window). You must use the key commands listed below.

In the table below, the symbol ^ before a letter means that the <Ctrl> key should be held down while the letter key is pressed

* j or <Return>
  [or down-arrow]
move cursor down one line
* k [or up-arrow] move cursor up one line
* h or <Backspace>
  [or left-arrow]
move cursor left one character
* l or <Space>
  [or right-arrow]
move cursor right one character
* 0 (zero) move cursor to start of current line (the one with the cursor)
* $ move cursor to end of current line
  w move cursor to beginning of next word
  b move cursor back to beginning of preceding word
  :0<Return> or 1G move cursor to first line in file
  :n<Return> or nG move cursor to line n
  :$<Return> or G move cursor to last line in file

Screen Manipulation

The following commands allow the VI editor screen (or window) to move up or down several lines and to be refreshed.

  ^f move forward one screen
  ^b move backward one screen
  ^d move down (forward) one half screen
  ^u move up (back) one half screen
  ^l redraws the screen
  ^r redraws the screen, removing deleted lines

Adding, Changing, and Deleting Text

Perhaps the most important command is the one that allows you to back up and undo your last action. Unfortunately, this command acts like a toggle, undoing and redoing your most recent action. You cannot go back more than one step.

* u UNDO WHATEVER YOU JUST DID; a simple toggle

Inserting or Adding Text

The following commands allow you to insert and add text. Each of these commands puts the VI editor into insert mode; thus, the <Esc> key must be pressed to terminate the entry of text and to put the VI editor back into command mode.

* i insert text before cursor, until <Esc> hit
  I insert text at beginning of current line, until <Esc> hit
* a append text after cursor, until <Esc> hit
  A append text to end of current line, until <Esc> hit
* o open and put text in a new line below current line, until <Esc> hit
* O open and put text in a new line above current line, until <Esc> hit

Changing Text

* r replace single character under cursor (no <Esc> needed)
  R replace characters, starting with current cursor position, until <Esc> hit
  cw change the current word with new text,
starting with the character under cursor, until
<Esc> hit
  cNw change N words beginning with character under cursor, until <Esc> hit;
  e.g.,
c5w changes 5 words
  C change (replace) the characters in the current line, until <Esc> hit
  cc change (replace) the entire current line, stopping when <Esc> is hit
  Ncc or cNc change (replace) the next N lines, starting with the current line,
stopping when
<Esc> is hit

Deleting Text

* x delete single character under cursor
  Nx delete N characters, starting with character under cursor
  dw delete the single word beginning with character under cursor
  dNw delete N words beginning with character under cursor;
  e.g.,
d5w deletes 5 words
  D delete the remainder of the line, starting with current cursor position
* dd delete entire current line
  Ndd or dNd delete N lines, beginning with the current line;
  e.g.,
5dd deletes 5 lines

Cutting and Pasting Text

The following commands allow you to copy and paste text.

  yy copy (yank, cut) the current line into the buffer
  Nyy or yNy copy (yank, cut) the next N lines, including the current line, into the buffer
  p put (paste) the line(s) in the buffer into the text after the current line

Other Commands

Searching Text

A common occurrence in text editing is to replace one word or phase by another. To locate instances of particular sets of characters (or strings), use the following commands

  /string search forward for occurrence of string in text
  ?string search backward for occurrence of string in text
  n move to next occurrence of search string
  N move to next occurrence of search string in opposite direction

Determining Line Numbers

Being able to determine the line number of the current line or the total number of lines in the file being edited is sometimes useful.

  :.= returns line number of current line at bottom of screen
  := returns the total number of lines at bottom of screen
  ^g provides the current line number, along with the total number of lines,
in the file at the bottom of the screen

Saving and Reading Files

These commands permit you to input and output files other than the named file with which you are currently working.

  :r filename<Return> read file named filename and insert after current line
(the line with cursor)
  :w<Return> write current contents to file named in original VI call
  :w newfile<Return> write current contents to a new file named newfile
  :12,35w smallfile<Return> write the contents of the lines numbered 12 through 35 to a new file named smallfile
  :w! prevfile<Return> write current contents over a pre-existing file named prevfile