PORTING LINUX & ANDROID ON

Beagle Board

A PROJECT REPORT SUBMITTEDIN PARTIAL FULFILLMENT OF THE REQUIREMENTS

FOR THE AWARD OF THE

“DIPLOMA IN EMBEDDED SYSTEM PROGRAMMING”

UNDER THE GUIDANCE OFMr. Kaushal Kishore Sharma

Submitted by:SAJID NAEM E.R

CENTER FOR DEVELOPMENT AND ADVANCE COMPUTING’S

ADVANCED COMPUTING TRANING CENTER

PUNE

CERTIFICATE

THIS IS TO CERTIFY THAT THE PROJECT WORK ENTIITLED

PORTING LINUX & ANDROID ON

Beagle Board

IS SUBMITTED BY SAJID NAEEM E.R

For award of Diploma in Emedded Programming

CDAC ACTS, PUNE embodies the bonafide work done by

them under my supervision.

Mr. Kaushal Kishore Sharma

[Project Guide]

ACKNOWLEDGEMENTWe here by take this opportunity to express our deep sense of Gratitude to our

guide Mr. Kaushal Kishore Sharma for their valuable Guidance and esteemed

suggestions along with constant Encouragement during our project work, which

enabled this project to Be successful.

We also express our sincere thanks to all the faculties for our Continuous

enlightenment with their technical expertise. We would also like to thank for

providing us with all the activities all round the clock.

We would also like to devote our special thanks to for providing us with his

expertise in the device drivers and motivating us to take every opportunity with great

zeal and also for developing a never say die attitude in life.

TABLE OF CONTENTS

Chapter Description Page No.

1. Introduction………………………………………………………………..

2. Equipment………………………………………………………………….

3. Setup ………………………………………………………………………

4. SD Card Configuration ……………………………………………………

5.PORTING –AN INTRODUCTION………………………………………..

6.Modules in Porting………………………………………………………….

7. Prerequisites of Porting …………………………………………………….

8.Filesystem Layout…………………………………………………………….

9.TOOL-CHAIN………………………………………………………………..

10. Various Types of Tool-chains………………………………………………

11.BOOTLOADER……………………………………………………………..

12.U-Boot:……………………………………………………………………….

13.BOOTING SEQUENCE…………………………………………………….

14. FLASH UTILITY…………………………………………………………..

15.Linux Kernel for OMAP3530OSK…………………………………………..

16.Upload Linux Kernel to the OSK…………………………………………….

17.ANDROID PORTING………………………………………………………..

18.HARDWARE DETAILS……………………………………………………

19.Detailed Description of……………………………………………………….

20.CONCLUSION………………………………………………………………

21.REFRENCES…………………………………………………………………

1. INTRODUCTION

This document is the System Reference Manual for the BeagleBoard, a low cost OMAP3530 based board supported through BeagleBoard.org. This document provides detailed information on the overall design and usage of the BeagleBoard from the system level perspective. It is not intended to provide detailed documentation of the OMAP3530 processor or any other component used on the board. It is expected that the user will refer to the appropriate documents for these devices to access detailed information.

The Beagle Board is an open-hardware single-board computer that is both inexpensive and capable of running Linux® at a reasonable speed. Get to know the Beagle Board, and learn how to get a Linux development environment together on the cheap.

The Beagle Board is a pocket-sized reference board (see Figure 1) containing a Texas Instruments OMAP3530 system-on-a-chip (SoC) processor (ARM Cortex A-8 core) running at up to 600MHz.I picked the eagle Board because it is an inexpensive platform for learning how Linux and small systems work. It is a reasonable alternative for hobbyists designing projects for themselves, academics creating projects for classes, and professionals designing low-cost appliances or thin clients.

This is a basic illustrated guide about how to connect successfully Beagle- Board to a PC. This guide is aimed to people with no experience in this gadgets and those who need making the board function quickly, at the first attempt and with no headaches.

For this, a pack of components available at the board’s website will be used. At this way, the same kind of components will be connected, as there are serveral versions and reviews of the board that include subtle hardware changes -specially, changes related with connectivity.

Equipment

To run these tests you will need the following components:o BeagleBoardo 5V DC supply with a 2.1mm I.D. and 5.5mm O.D. connectoro SD Cardo PCo USB miniA to A cableo USB HUBo DVI-D Monitoro DVI-D to HDMI cableo Speakerso 3.5mm stereo cable with connectors on both endso DB9 Null-Modem Cableo DB9 to IDC-10 cable ATI/Everex configuration

Setup

This step sets up the board for the tests to follow.1. Make sure Beagle power is in OFF state by removing the 5V supply and the USB host connection.

2. Connect the IDC UART cable the Beagle Board and using a Null-Modem serial cable connect it to a SERIAL port on a Window/Linux/Mac machine

3. Have terminal program, such as TeraTerm, HyperTerminal, or Minicom, running on the host machine.

4. Configure the terminal program for (BAUD RATE - 115200, DATA - 8 bit, PARITY- none, STOP - 1bit, FLOW CONTROL - none)5. Insert the MMC/SD card (that is prepared as described above) into MMC/SD slot on Beagle Board.

6. Connect a LCD Monitor to DVI/HDMI port on the Beagle Board.

7. Connect an externally powered speaker to audio out jack on Beagle Board.

8. Connect a Line-in cable from PC or any player to Audio In jack on Beagle Board.

9. Connect a TV (NTSC-M) to S-video port.

10. Power ON LCD, TV and audio speakers.

SD Card Configuration

In order to boot from the SD card, it must be formatted and the files loaded. The following steps explain that process.

1. Format the MMC/SD Card for FAT32 File System using the HP USB Disk Storage Format Tool 2.0.6: http://selfdestruct.net/misc/usbboot/SP27213.exe

2. Insert the Card writer/reader into the Windows machine.

3. Insert MMC/SD card into the card reader/writer

4. Open the HP USB Disk Storage Format Tool.

5. Select “FAT as File System”. Click on “Start”.

6. After formatting is done Click “OK”

7. Copy the following files on to MMC in the exact order listed. COPY THE MLO FIRST! Make sure you name the file as indicated in the BOLD type.

MLO as MLOu-boot as u-boot.binu-boot for flash as u-boot-f.binramdisk image as ramdisk.gzKernel (uImage) as uImage.binreset.scr as boot.scrx-loader image as x-load.bin.iftRegular script file as normal.scr

PORTING LINUX ON OMAP Porting is a process wherein we try to customize an already

available kernel so as to make it compatible to run on a particular architecture of a particular hardware environment.

Different hardware have got different internal structure i.e. the internal implementation of the basic blocks that make that hardware board. Two different development boards can have a totally different type of memory layout, memory access methods, peripherals and other features. So the kernel that may run on one of them will not work on other because of the basic difference in the board architecture. This is the reason we need to customize the kernel.

Customization of the kernel would include changing some parameters in the kernel source, including or excluding some kernel modules , libraries etc. Once the customization is completed the kernel is compiled to generate an image that will be ready to be downloaded to the board.

This process will also invariably include the BOOTLOADER also. The bootloader may or may not be required to customize, but yes , it can also be customized.

It should be noted that porting is not an atomic process. The process of porting will in-turn contain many other crucial modular steps. So when we are working on ‘porting’ we should work in a modular method. Completing the process module by module.

Modules in Porting The process of porting can be basically divided into following

moduleso Study of Bootloadero Study of ‘kernel customization’o Detailed study of the relevant h/w boardo Study of Support system required o Compiling and / installation of support system required Bootloadero Customizing bootloader (U-BOOT)o Compiling and downloading U-BOOT(U-BOOT)oKernelo Customizing Kernelo Compiling and downloading kernel

The study modules sound very trivial but these modules only will decide over the success of failure of the complete process. Very good study materials on the porting and other relevanttopics are available on the internet.The second main module is compiling and installing the prerequisites. The porting processwill require a lot of other utilities, so before we start with the actual porting we should be ready with all the prerequisites on our systems.

The third main part of the process of porting is the U-BOOT customization and compilation. Normally the U-BOOT source is not needed to be customized barring one or two very trivial changes. Once the U-BOOT image is ready we can download it into theintended SOC. The detailed steps are explained in the further chapters.

The last part of the process of porting is customization and compilation of the kernel. This is the most crucial part of the complete process. We need to be very sure of which

Prerequisites of Porting Cross Development tool chain. Minicom (or any other serial ort communication utility) Get it from the Linux OS installation CD. U-BOOT loader source / image.

Get a U-Boot Loader from ttp://sourceforge.net/projects/uboot/Linux Kernel Source + OMAP patch This is all we need as the procedure for porting. In the coming section all the details of thesteps are provided... inetd, but are started up at boot time and register themselves with the portmapper, therefore, you have to make sure to start them only after rpc.portmap is running.

File system Layout The complete list of root file system top-level directories and their

content are shown bellow.1. bin : Binary executables i.e Essential user command binaries2. boot : Static files used by the bootloader3. dev : Device nodes i.e Devices and other special files4. etc : Local System configuration files, including startup files5. home : User home directories6. lib : Essential libraries, such as the C library, and kernel modules7. media : Mount points for removable media8. mnt : Mount points for temporarily mounted filesystems9. opt : Add-on software packages10. proc : Virtual filesystem for kernel and process information11. root : Root user’s home directory12. sbin : Essential system administration binaries13. sys : Virtual filesystem for system information and control (buses, devices, and drivers)14. tmp : Temporary files15. usr : Secondary hierarchy containing most applications and documents useful to most users, including the X server16. var : Variable data stored by daemons and utilities

TOOL-CHAIN

ARM Specific Development Tools Development tools are required to develop a software or program. Suppose we want to write programs on x86 based systems we need GCC compiler for compiling our codes, debugger tool for debugging and creating binary executable files which can run on X86 processor. Similarly we need tools specific to our processor that is ARM9 one such tool is toolchain. It includes Linker, assembler, c-compiler, c-library & header. Additional components in some toolchain include extra library and more supplementary tools such as Debugger, Profiler.

Toolchain can be defined as a complete collection of tools required for writing, compiling, creating executable files and finally libraries used at run-time for running those executables on the system.

Various Types of Toolchains 1. Native Toolchain:- Set of software tools running on one platform and generating binaries for same platform are called as native toolchain. The usual development tools available on GNU/LINUX workstation is NATIVE tool chain.2. Cross development Toolchain:-In Embedded System development it is not practical to use native toolchain because offollowing limitations.3. The target is too restricted in terms of memory/storage.4. The target is very slow as compared to workstation.5. Not necessary to install all development tools on target.Hence, embedded developer’s needs tools which are different than normal toolchain in respect that they typically run on one platform while building application for another. This is why these tools are called as “Cross development tools”.

These cross development tools are not installed in the target system but they remain on the host and we can compile and create binaries for ARM on host machine itself. Above shown is how the native and cross compiling toolchain works.

Components of Cross-Development Tool-chain

1. Binutils is a set of tools to generate and manipulate binaries for a given CPU architecture.Various utilities in Biutils package are Loader, Linker, and Assembler.

2. GCC compiler GNU C compiler free software compilerCan compile C, C++, Ada , Java Objective C++, and generate code for a large number of CPU architectures, including ARM, AVR, CRIS, FRV, M32, MIPS, v850, i386, x86_64, IA64,etc.

3. GLIBC or alternate C- library o C library acts as an interface between the applications and the Kernel. It provides the well known standard C API to ease application development. Glibc is C library from the GNU project. Almost all userland applications willlink to this library. Only things like the kernel, bootloaders and other things that avoid using any C library functions can be compiled without it .There are alternatives to glibc for small and embedded systems but this is the standard for compiling the rest of gcc

4. Kernel headers-This is the first component required to build a toolchain. The C library and compiled programs needs to interact with the kernel. Therefore compiling C library and many applications require the kernel header.

BOOTLOADER ARM Linux cannot be started on a machine without a small amount

of machine specific code to initialize the system. ARM Linux requires the boot-loader code to do very little.

The minimal requirements from the bootloader are Configure the system’s memory. Load the kernel image at the correct memory address. Optionally load an initial RAM disk at the correct memory address. Initialize the boot parameters to pass to the kernel. Obtain the ARM Linux machine type Enter the kernel with the appropriate register values.

U-Boot:-

We use Das U-boot as the bootloader for our board. Das U-Boot is the first thing we will see when we start up our OSK. If we press a key when prompted, we will be able to use U-Boot, rather than booting into Linux. From here, we can upgrade U-Boot or our kernel, or flash on a new root filesystem; we can also change environment variables, such as the kernel’s boot arguments.

Compiling U-Boot:-

Step 1: First move to the desired directory, where we want the bootloader to reside.$ cd /usr/src/

Step 2: Unpack the tar with xjvf parameters. These parameters are used to untar the tar-file. And change the current directory to the u-boot directory.$ tar –xjvf /root/home/u-boot-1.3.3.tar.bz2$ cd u-boot-1.3.3/

Step 3: Now set the path of toolchain. Toolchain is a set of tools to build computer software. It includes – linker, assembler, archives, C compiler, C library and C header files. We need this to compile our bootloader (C/C++ programs) intend to use on the OSK.$ export PATH=/opt/arm-2007q3/bin:$PATH Step 4: Now clean the previous configurations. To clean the previous configuration files we use ‘distclean’. This command simply run the ‘distclean’ rule defined in the Makefile.This rule clears all previously saved configuration settings.$ make distclean

Step 5: Apply default configuration for our OSK. OMAP3530osk_defconfig is the configuration file which comes with the bootloader for the OMAP3530 board. This file contains all the necessary configuration settings of the bootloader to work properly on the board. This command apply these configuration settings to .config file.$ make OMAP3530osk_config

Step 6: Edit the Makefile for the following changes-- In Makefile find the following text ifeq($(ARCH),arm)CROSS_COMPILE = …change the CROSS_COMPILE line toCROSS_COMPILE = arm-none-linux-gnueabi- This line tells the compiler that which cross-compiler we wants to use to compile thebootloader.

Step 7: Now compile the u-boot. U-boot is compiled with the make command. Make command compile the u-boot source files according to the configuration which we have already applied and create a binary image of the bootloader – u-boot.bin. This file will be available in the current directory it can be used to boot our OSK.

$ makeThis will be the final command for the compilation of the

bootloader. After these steps we have a compiled image of the U-Boot which we can send to our board to boot the OMAP3530 board.

Upload U-Boot to the OSK:

To upload the binary image of the bootloader we need to follow the following steps.

Step1: Connect the Ethernet cable and serial cable between computer and OMAP3530 kit. Our computer and board communicate via these two interfaces.

Step2: Open the terminal on computer and start ‘minicom’. Minicom is the utility like hyperterminal in windows, which is used to communicate with serial device.

Step3: Power up the OMAP3530 kit. When we power up the kit it start the previously loaded bootloader which apply the initial setting to bootup the board and start the linux kernel.

Step4: Press any key to stop booting the kernel when prompted (stop booting the kernel).

Step5: Now setup environment variable. Environment variables are necessary parameters to setup communication between our computer and board. To setup the environment variables follow the following steps:

- First of all setup the Ethernet address of the board. This sets the MAC address of the OSK

- (printed near the port).$ setenv ethaddr <00:0E:99:XX:XX:XX>- Now give an IP address to the board.$ setenv ipaddr 192.168.72.33- Also give the IP address of the computer.$ setenv serverip 192.168.72.34- Provide the NET MASK address of the LAN.$ setenv netmask 255.255.255.0- Set the GATE WAY IP of the LAN$ setenv gatewayip 192.168.72.254

Step6: Save all the settings which we have just applied by the command$ saveenv

Step7: Now our board is ready to receive the compiled image of the bootloader (u-boot.bin).To upload the bootloader image, copy the image file to the ‘/tftpboot/’ directory.$ cp –f /root/home/u-boot-1.3.3/u-boot.bin /tftpboot/

Step8: Send the bootloader image, u-bbot.bin, to the RAM in OSK$ tftpboot 0x10000000 u-boot.bin

Step9: This command will upload the u-boot image to the board and also will show the size of our file, note down this size. The size value will be used to move the binary image to the flash.

Step10: Now un-protect the memory area of the previously loaded bootloader, so that we can remove that.$ protect off 1:0Here 1 is for the memory bank and 0 for the sector in that bank.

Step11: Erase the previous bootloader by the following command.$ erase 1:0Here 1 indicates the bank no 1 and 0 indicates sector no 0, i.e. the residing location of bootloader.

Step12: Move the new bootloader image to flash.$ cp.b 0x10000000 0x100000 <size of u-boot copied in RAM (in hex)>e.g. $ cp.b 0X10000000 0X100000 34f2eNow if we restart the OMAP3530 kit, it will boot the kit with our ploadedbootloader image.

Step13: Once the new bootloader starts we need to change the “boot arguments” of the new boot loader in case they are not already properly set. Though we have already set the new environment variables still we haven’t set the “boot arguments”. Do it as follows$ setenv bootargs=console=ttyS0,115200n8 noinitrd root=/dev/nfs rwnfsroot=192.168.72.34:/data/rootfs2.6,nolock devfs=mountip=192.168.72.33:192.168.72.34:192.168.72.254:255.255.255.128:omap:eth0:offmem=30M(this is a single line command !!!)TRAP: copy and paste above string on the u-boot screen to avoid any errors, the onlychanges that one need to do in this string arenfsroot=<your IP>:<path of rootfs on your PC> andip=<your board IP>:<your PC IP>:<your gateway IP>:<your netmask>

BOOTING SEQUENCE

Flash is of 32MB (16MB X 2) divided into 258 sectors of 125K each. When JP3 is in position 1-2 position. Flash is positiond at address 0x0. When powered on CPU fetches the first instruction from address 0x0.

Therefore U-Boot bootloader is burned at address 0x00000000 (sector 0). U-Boot is configured to fetch the LINUX kernel from address 0x00100000. Therefore LINUX kernel is burned at address 0x00100000.U-Boot bootloader remaps itself at address 0x11080000 in RAM and operates from there.

In RAM,0x10000000 contains Zero page exception vectors.0x10000100 contains Parameter block. (kernel parameters from Uboot)0x10004000 contains page tables.0x10008000 contains uimage. (kernel image)0x10800000 contains initrd. (initial file system)0X11080000 contains U-BOOT image (remapped)0x11096144 contains BSS area(used by kernel decompression)1109 6144 B S S a r e a ( u s e d b y k e r n e l d e c o m p r e s sion)1108 0000 U-BOOT image (remapped)1080 0000 initrd. (initial file system)1000 8000 uimage. (kernel image)1000 4000 page tables.1000 0100 Parameter block. (kernel parameters from Uboot)1000 0000 Zero page exception vectors.0010 0000 LINUX kernel0000 0000 U-Boot bootloader

FLASH UTILITY

When you have a virgin board .i.e. a board without any bootloader or in worst cases it can so happen that the bootloader that you loaded gets corrupted. In such cases the board will not boot-up at all, i.e. there will be no U-boot prompt and hence in such cases we cannot use the U-Boot commands to load or unload new bootloader.

In such a case the only solution is a “Flash Recovery Utility”.

How to Use the Flash Utility?

Step 1: Firstly install a usb library like libusb-1.0.6. (because flash utility uses USB)# tar -jxvf libusb-1.0.6.tar.bz2# cd libusb-1.0.6# ./configure# make# make install

Step 2: Untar the tarball for the flash utility and compile the utility using simple commands# tar zxvf omapfl-1.0.tar.gz# make clean# make allAfter these commands a runnable file by name “omaplf” will be created in the un-tared folder.

Step 3: To use it, connect the board with your computer using USB ( board has a type A connector, as your computer, and you need to do a A-A direct cable) Power the board, set JP3 to pins 1-2, connect USB cable and executes the program passing it two arguments.First argument is the second stage loader (the included 2nd.bin file) and second one is the program you want to load at flash (example: u-boot-1.1.1). If it doesn't work, press the reset button of the board.

The flash loading (recovery) is done by following simple commands# ./omaplf 2nd.bin <your uboot file.bin> e.g# ./omaplf 2nd.bin u-boot.binAfter this step the Flash has been rescued and the new U-Boot is ready to run . Reset theboard !!

The file "2nd.bin" is the second stage boot loader. The main program (omaplf) sends it to the OMAP processor, where it is executed by the internal bootloader. Then it send the second binary to be flashed."2nd.bin" is already provided in the utility folder , if you need to recompile the second

boot loader, you will need a cross compiler, "2nd/Makefile". If your local gcc compiler is not called "gcc", change "Makefile", also if your include files for libusb isn't located at /usr/include (add -L/.... to INCLUDES= line at Makefile).

LINUX KERNEL FOR OMAP3530_OSK

Linux Kernel for OMAP3530OSK Building the Linux kernel for OMAP3530 processor is little different than building it for general purpose computers. We need to configure the Kernel according to our need. This depends on what features we require and which modules we need to include in our Linux Kernel. Following are the steps to build the bootable Kernel which can be used by theOMAP3530 processor.

The latest kernel can be obtained from http://www.kernel.org/ and the necessary patch to use this kernel on an OMAP system can be found at http://www.-muru.com/linux/omap/

Compilation of Linux Kernel

Once these files are obtained, we can compile the linux kernel following the steps below:

Step1: Change the current directory to the directory where we want the source of the kernel.# cd /usr/src/

Step2: Un-pack the source of the kernel here.# tar -xjvf /root/home/linux-2.6.25.tar.bz2

Step3: Copy the patch for the OMAP3530 in current directory.# cp /root/home/patch-2.6.25-omap1.bz2 .

Step4: Un-zip the patch file by following command# bunzip2 patch-2.6.25-omap1.bz2

Step5: Now change directory to the kernel source directory# cd linux-2.6.25/Step6: Apply the OMAP3530 patch to the kernel.# cat ../patch-2.6.25-omap1 | patch -p1

Step7: Here we have the kernel source tree which is patched for the OMAP3530 OSK. Nowwe need to compile the kernel for our OMAP3530 processor. To have the cross compiler generate an ARM Linux image, the path to the cross compiler tools is added to the host machine's PATH variable by:#export PATH=/opt/arm-2007q3/bin:$PATH

Step8: Edit the Makefile for the following changes, to tell the compiler that which compilation library to be used to cross compile the Kernel.In Makefile change the find the line – “CROSS_COMPILE ?= arm-linux-change this line to -“CROSS_COMPILE ?= arm-none-linux-gnueabi-

Step9: Now clean the previously save configuration if any by passing ‘clean’ parameter to the make command. This is the rule defined in the Makefile of the kernel which deletes all the previous configuration files available in current Kernel.# make clean (or # make mrproper)

Step10: Apply default configuration on the kernel for OMAP3530 which has been obtainedwith the kernel source in file ‘omap_osk_3530_config’.# make ARCH=arm omap_osk_3530_config

In this command ‘ARCH=arm’ defines the architecture of the hardware for which wewant to compile the Kernel and ‘omap_osk_3530_config’ is a file that contains the default configurations for the OMAP3530. This command will create a ‘.config’ file which will contain all the default configurations necessary for the OMAP3530 board.

Step11: Now we can change the default configuration according to our needs by# make menuconfig

This command will open a configuration window, through which we can change the Kernel configuration according to our needs.In this window we need to change following settings

Kernel Features -> Use the arm EABI… (Enable)Device Driver -> I2C support (Disable)Device Driver -> OMAP DSP driver -> (DSP GATEWAY) (Enable)System Type -> TI OMAP implementation -> MMU Framework Support (Enable)

Step12: Now we have configured the Kernel according to our need and we can now compile it. To compile the Kernel use the make command with ‘ARCH=arm’ parameter. Here we again explicitly tells the compiler that we want the compiled Kernel for ARM architecture by specifying it as ‘ARCH=arm’. This is optional we can also compile without using this argument.# make ARCH=arm

After make operation we will have vmlinux in our Kernel source tree. File vmlinux is stand alone, monolithic Kernel image but it is not in a suitable format for U-Boot to upload. To convert the file, the mkimage utility must be used which comes with UBoot.

Step13: To make the kernel image suitable for U-Boot, first of all create a new binary from vmlinux which we will use to change into the suitable format for u-boot. For all this we need to apply the following operations

#arm-linux-objcopy –O binary –R .note –R .comment –Sarch/arm/boot/compressed/vmlinux linux.bin

Step14: This linux.bin is needs to be compressed before sending to the board. To compress this image use gzip utility# gzip -9 linux.bin

Step15: Now we have compressed image of linux kernel which is ready to be changed into required format which u-boot can use to boot the kernel. The format of kernel image can be changed by the following operation

# <U-Boot Directory>/tools/mkimage –A arm –O linux –T kernel –C

gzip –a 0x10c08000 –e 0x10c08000 –n ‘Linux Kernel Image’ –dlinux.bin.gz uImage-2.6.25.ccNote that above command is a single line command.After this we will have a file ‘uImage-2.6.25.cc’ which can be upload to the OMAP3530 board.

Upload Linux Kernel to the OSK To upload the binary image of the linux kernel we need to follow

the following steps.

Step1: Power up the OMAP3530 kit. When we power up the kit it start the bootloader which apply the initial setting to boot-up the board.

Step2: Press any key to stop booting the kernel when prompted.

Step 3: Now copy the kernel image in ‘tftpboot’ directory to upload it$cp –f /root/home/u-boot-1.3.3/u-boot.bin /tftpboot/

Step 4: Send the linux kernel image, uImage-2.6.25.cc, to the RAM in OSK$tftpboot 0x10000000 uImage-2.6.25.cc

Step 5: This command will upload the kernel image to the board and also will show the size of our kernel image file, note down this size. The size value will be used to move the binary image to the flash.

Step 6: Now un-protect the memory area of the previously loaded kernel, so that we can remove that.$protect off 1:8-22Here 1 is for the memory bank and 8-22 for the sectors from 8 to 22 in that bank.

Step 7: Erase the kernel by the following command.$erase 1:8-22

Step 8: Move our new linux kernel image to flash.$cp.b 0x10000000 0x100000 <size of kernel image(in hex)>

Now if we restart the OMAP3530 kit, it will boot the kit with our linux kernel!!!

1. As long as no key is pressed on the terminal, the following will be displayed:reading boot.scr679 bytes readRunning bootscript from mmc ...## Executing script at 80200000reading x-load.bin.ift20392 bytes read

2. The x-load.bin.ift contains the XLoader file that will be flashed into the NAND inthe following steps. The following will be displayed:***** Replacing x-load *****Usage:nand - NAND sub-systemHW ECC selectedNAND erase: device 0 offset 0x0, size 0x80000Erasing at 0x0 -- 25% complete.Erasing at 0x20000 -- 50% complete.Erasing at 0x40000 -- 75% complete.Erasing at 0x60000 -- 100% complete.OKNAND write: device 0 offset 0x0, size 0x20000131072 bytes written: OKNAND write: device 0 offset 0x20000, size 0x20000131072 bytes written: OKNAND write: device 0 offset 0x40000, size 0x20000131072 bytes written: OKNAND write: device 0 offset 0x60000, size 0x20000131072 bytes written: OK

3.The u-boot-f.bin contains the UBoot file that will be flashed into the NAND in the following steps. The following will be displayed:reading u-boot-f.bin

275928 bytes read***** Replacing u-boot *****Usage:nand - NAND sub-systemSW ECC selectedNAND erase: device 0 offset 0x80000, size 0x160000Erasing at 0x80000 -- 9% complete.Erasing at 0xa0000 -- 18% complete.Erasing at 0xc0000 -- 27% complete.Erasing at 0xe0000 -- 36% complete.Erasing at 0x100000 -- 45% complete.Erasing at 0x120000 -- 54% complete.Erasing at 0x140000 -- 63% complete.Erasing at 0x160000 -- 72% complete.Erasing at 0x180000 -- 81% complete.Erasing at 0x1a0000 -- 90% complete.Erasing at 0x1c0000 -- 100% complete.OKNAND write: device 0 offset 0x80000, size 0x1600001441792 bytes written: OK

4. After the XLoader and UBot are flashed, the environment variables are erased to insure proper booting of the Kernel image that I son the SD card. . The following will be displayed:***** Erasing environment settings *****Usage:nand - NAND sub-systemNAND erase: device 0 offset 0x160000, size 0x20000Erasing at 0x160000 -- 100% complete.OK

1. After the NAND has been flashed, the normal.scr script is read form the SD card and the first step after that is to load in the uImage.bin file into the SDRAM.Beagle will print the following to the terminal:***** Executing normal.scr *****## Executing script at 80200000reading uImage.bin

2578044 bytes read***** Kernel: /dev/mmcblk0p1/uImage.bin *****

2. Then the root filesystem is read into SDRAM. The BeagleBoard will output the following:reading ramdisk.gz7999649 bytes read***** RootFS: /dev/mmcblk0p1/ramdisk.gz *****1856680 bytes read

3. At this point, the booting process will start. The following will be printed to the terminal:## Booting kernel from Legacy Image at 80200000 ...Image Name: Linux-2.6.28-omap1Image Type: ARM Linux Kernel Image (uncompressed)Data Size: 2577980 Bytes = 2.5 MBLoad Address: 80008000Entry Point: 80008000Verifying Checksum ... OKLoading Kernel Image ... OKOKStarting kernel ...UncompressingLinux.................................................................................................................................................................... done

Android™ delivers a complete set of software for mobile devices: Operating system, middleware and key mobile applications.

URLs: http://www.android.com/http://source.android.com/http://developer.android.com/http://androidguys.com/http://source.android.com/roadmap/cupcake

The Android Software Development Kit (SDK) is also available:http://developer.android.com/sdk/1.1_r1/index.html

Building Android on Beagle

Posted by Michael Opdenacker on June 4th, 2009 (rss, trackback) Tags: beagle

Updated instructions to use Android on the Beagle board

These instructions are derived from Embinux.org’s Android Porting Guide to Beagle Board, based on their work to port Android on the Beagle board. They correct multiple inaccuracies in this guide, and also add many useful details.

These instructions were tested on xubuntu 9.04. There shouldn’t be many differences if you use other recent Ubuntu or Debian versions.

Install needed software packages

At the time of this writing, note that Android requires Sun’s Java5 JDK, and doesn’t support the Java6 one.

apt-get updateapt-get dist-upgradeapt-get install git-core bison sun-java5-jdk flex g++ zlib1g-devapt-get install libx11-dev libncurses5-dev gperf uboot-mkimage

Android also uses its own repo script as a git front-end:

mkdir -p ~/bincd ~/binwget http://android.git.kernel.org/repochmod +x repo

We are also going to need a 2007q3 toolchain from Code Sourcery

cdwget http://www.codesourcery.com/sgpp/lite/arm/portal/package1787/public/arm-none-linux-gnueabi/arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

cd /optsudo tar jxf arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

You could also get this toolchain from our website:

cdwget http://free-electrons.com/pub/demos/beagleboard/android/arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.lzmacd /optsudo tar --lzma -xf ~/arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.lzma

Download sources

Our instructions create a directory in your home directory, but of course, it can be placed anywhere!

mkdir ~/beagledroid cd ~/beagledroid repo init -u git://labs.embinux.org/repo/android/platform/beaglemanifest.git/ repo sync

Caution: this can take a lot of time, as this downloads and extracts 2.4 GB of data. On a fast workstation with a 500KB/s Internet connection, it took about 90 minutes.

If your corporate network doesn’t let you use the git protocol, you can use our snapshot available on

http://free-electrons.com/pub/demos/beagleboard/android/:

cdtar --lzma -xvf beagledroid-git-20090603.tar.lzma

Building Android

make

If your workstation has multiple CPUs, you could save a lot of time by running multiple jobs in parallel:

make -j 4

On our machine, this took about 4 hours!

Building the kernel

export CC_PATH=/opt/arm-2007q3/bin/arm-none-linux-gnueabi-cd ~/beagledroid/kernel/vendor/embinux/support-tools/beagle_build_kernel.sh

Copying the Android root filesystem

Android’s root file system is generated in ~/beagledroid/out/target/product/generic

cd ~/beagledroid/out/target/product/genericmkdir ~/beagledroid/rootfscp -a root/* ~/beagledroid/rootfs/cp -a system/* ~/beagledroid/rootfs/system/cd ~/beagledroid/rootfssudo chown -R root.root .sudo chmod -R a+rwX data system

Formatting an MMC/SD card

First connect your card reader to your workstation, with the MMC/SD card inside. Type the dmesg command to see which device is used by your workstation. Let’s assume that this device is /dev/sdb

Type the mount command to check your currently mounted partitions. If MMC/SD partitions are mounted, unmount them.

In a terminal edit partitions with fdisk:

sudo fdisk /dev/sdb

Delete any existing partition with the d command.

Now, create the boot partition:

Command (m for help): nCommand action e extended p primary partition (1-4)pPartition number (1-4): 1First cylinder (1-239, default 1): 1Last cylinder, +cylinders or +size{K,M,G} (1-239, default 239): +64M

Change its type to FAT32:

Command (m for help): tSelected partition 1Hex code (type L to list codes): cChanged system type of partition 1 to c (W95 FAT32 (LBA))

Using the n command again, create a second partition filling up the rest of your card (just accept default values).

Now, format the partitions in your card:

sudo mkfs.vfat -n beagleboot -F 32 /dev/sdb1sudo mkfs.ext3 /dev/sdb2

Remove and insert your card again. Your new partitions should be mounted automatically.

Copying data to the MMC/SD card

Start by copying the X-loader and U-boot on the first partition.

cd /media/beaglebootwget http://free-electrons.com/pub/demos/beagleboard/android/MLOhttp://free-electrons.com/pub/demos/beagleboard/android/u-boot.bin

cp ~/beagledroid/kernel/arch/arm/boot/uImage .

Now copy the Android root filesystem to the second partition (assuming it is mounted on /media/disk:

sudo rsync -a ~/beagledroid/rootfs/ /media/disk/

HARDWARE DETAIL

Flash Bus Memory MAP of OMAP3530_OSK The flash memory is physically connected to CS3. When JP3 is in

the 2-3 position (default),the OMAP3530 boots in fast boot mode where CS3 is swapped with CS0 so the Flash starts at address 0. When the processor starts running, it will execute the code in flash (U-Boot is stored in flash at factory).

If JP3 is in the 1-2 position, the OMAP3530 comes up in full boot mode with the internal ROM at address 0. The interal bootloader supports additional boot modes such as booting from the serial port. At any time, the state of the CS0-CS3 mapping can be changed by modifying the BM(bit 1) of the EMIFS_CONFIG register(address0xFFFECC00).

Board

Functional Block Diagram of OMAP 5912

CONCLUSION

The project was intended to design a device driver that could run the SPI interface in all the modes possible for the transmission and reception of data of any length. Though due to hardware constrains the external communication via the SPI module was not possible, so the current status as such is that the driver hence written can drive the SPI interface in the loopback mode.

The reasons why the external communication with the SPI module of OMAP3530_OSK was not possible is that the SPIF.SCK pin of the SPI module is permanently connected to the power management chip interrupt pin.This makes it impossible to use the pin as SPIF.SCK Because the power management chip cannot be disabled. Hence the project status at the time of submission is that the linux kernel version linux- 2.6.25 was successfully ported on the OMAP3530_OSK, before which the U-BOOT-1.3.3 was successfuly downloaded into the board.

The device driver for the SPI interface of theOMAP3530_OSK is written successfuly and it demonstrated the SPI communication in the OMAP3530_OSK in loopback mode.

REFRENCES

Linux Device Drivers : Jonathan Corbet, Alessandro Rubini, & Greg Kroah-Hartman

Linux Kernel Development : Robert Love

Building Embedded Linux System 2nd edition - Karim Yaghmour

http://www.en.wikipedia.com

http://www.denx.de for U-BOOT

http://www.-muru.com/linux/omap/

http://sourceforge.net/projects/uboot/

http://freeelectrons.com/docs/

http://linux.omap.com for OMAP related Documentation