Skip to main content

Porting Linux

Booting Linux

Introduction 3

About boot loader 3

Known components of Hardware block 4

[ARM926ejs core] 4

[Cache] 4


Linux kernel 5

Basic understanding of kernel internal 5

Specific patches added in kernel 6

Specific adaptions and patches for MCS8140 6

Compiling and using Linux kernel 6

Debugging kernel 8


Porting Linux step by step 8

Step 1 Machine registration 8

Step 2 Firmware to kernel transition 8

Step 3 Early kernel init 9

Step 4 Mapping I/O devices 10

Step 5 IRQ setup 10

Step 6 system timer tick 10

Step 7 board level initialization 11

MCS8140 specific peripherals 12

Root file system 15

Creating a JFFS2 file system 15

/bin and /sbin 16

About busybox 16

/etc 16

About /init.d/rcS 17

/dev 17

/proc 17

/tmp 17

/var 17

/lib 17

/mnt 17

/modules 17

/usr 17

/sys 17


This document contains basic information about what are steps involved in building Linux for MCS8140, this board uses internal boot loader called I-boot and external boot loader called U-boot.

Building embedded Linux system consists of three parts, the bootloader, the Linux kernel, and the graphical user interface (or GUI). Attempt is made here to present understanding of linux kernel.

About boot loader

The typical bootloader performs the following types of functions:

  • Initialize CPU speed

  • Initialize memory, which includes enabling memory banks, initializing memory configuration registers, and so on

  • Initialize serial port (if present on the target).

  • Enable instruction/data caches.

  • Set up stack pointer.

  • Set up parameter area and construct parameter structures and tags (this is an important step, as boot parameters are used by the kernel in identifying root device, page size, memory size and more).

  • Perform POST (Power On Self Test) to identify the devices present and to report any problems.

  • Provide support for suspend/resume for power management.

  • Jump to start of kernel.

Known components of Hardware block

[Brief about hardware components involved in; need to have understanding of processor core, cache, MMU/TLB, memory map ]

[ARM926ejs core]



Linux kernel

The Linux kernel we are using for MCS8140 is linux-2.6.15. This kernel has so many features in built; we are using the following kernel features for MCS8140.

1) Kernel module support added.

2) Enabled ARM926 processor support and thumb instruction set support.

3) MMU support enabled.

4) PCI host support and hot plug enabled.

5) IPV4 TCP/IP stack enabled

6) IEEE80211 wireless support enabled.

7) Incorporated the flash device driver for supporting flash memory.

8) Enabled char, block devices support.

9) Ramdisk support enabled.

10) Enabled SCSI support.

11) PROC file system support.

12) SATA support enabled.

13) Enabled network device support.

14) Generic serial console (8250) support enabled.

15) Enabled sound support in kernel.

16) USB EHCI, OHCI support.

17) USB dev,sys file system.

18) Enabled ext2,ext3, minix, VFAT, FAT,MSDOS,NTFS,RAMFS file systems.

19) Enabled JFFS2, NFS, SMB file system support.

The features added to kernel which are specific to MCS8140 are: (we can enable the options in kernel in menuconfig by adding the options in Kconfig files in their respective modules.)

1) Added on board Ethernet driver to the kernel.

2) Added List processor and TCP segmentation offloading support to Ethernet driver.

3) Added board specific serial driver.

4) Added board specific sound driver. (I2S codec)

5) Added USBIP application module.

Basic understanding of kernel internal

The kernel layout is divided into architecture-specific and architecture-independent parts. The architecture-specific part of the kernel executes first and sets up hardware registers, configures the memory map, performs architecture-specific initialization, and then transfers control to the architecture-independent part of the kernel. It is during this second phase that the rest of the system is initialized. The directory arch/ under the kernel tree consists of different subdirectories, each for a different architecture (MIPS, ARM, i386, SPARC, PPC, and so on). Each of these subdirectories includes kernel/ and mm/ subdirectories, which contain architecture-specific code to do things like initialize memory, set up IRQs, enable cache, set up kernel page tables, and so on. These functions are called first once the kernel is loaded and given control, then the rest of the system is initialized.

The kernel can be compiled either as vmlinux, Image, or zImage depending on the available system resources and the functionality of the bootloader. The main difference between vmlinux and zImage is that vmlinux is the real (uncompressed) executable, while zImage is a self-extracting compressed file containing more or less the same information.

Specific patches added in kernel

The wireless drivers which are not available directly in 2.6.15 kernel are downloaded and added to our CVS tree.

These include Broadcom driver, Ralink drivers. (Available in drivers/net/wireless folder)

Specific adaptions and patches for MCS8140

UART, Timer, Interrupt Controller are must for Linux (these will come into basic Linux kernel porting section).
PCI Host driver
USB Host driver
EHCI,OHCI drivers.
MAC Driver (Includes LP & TSO & Cipher)
Audio Drivers.

Compiling and using Linux kernel

Kernel linking and loading

The kernel executable consists of many object files linked together. The object files have many sections such as text, data, init data, bass, and so forth. These object files are linked and loaded by a file known as a linker script. The function of the linker script is to map the sections of the input object files into an output file; in other words, it links all the input object files into a single executable whose sections are loaded at specified addresses. is the kernel linker script present in the arch/<target>/ directory, and it is responsible for linking the various sections of the kernel and loading them at a particular offset in memory.

Parameter passing and kernel boot up

stext(from lds file) is the kernel entry point, which means that the code under this section is the first to execute when the kernel boots up. It is usually written in assembly, and is normally present under the arch/<target>/ kernel directory. The code sets up the kernel page directory, creates identity kernel mapping, identifies architecture and processor, and branches to start_kernel (the main routine whereby the system is initialized).

start_kernel calls setup_arch as the first step where the architecture-specific setup is done. This includes initializing hardware registers, identifying the root device and the amount of DRAM and flash available in the system, specifying the number of pages available in the system, the filesystem size, and so on. All this information is passed in parameter form from the bootloader to the kernel.

There are two ways to pass parameters from bootloader to kernel: parameter_structure and a tag list. Of these, param structure is deprecated as it imposes restrictions by specifying that each and every parameter has to be at a particular offset within param_struct in memory. Recent kernels expect parameters to be passed as a tag list and will convert parameters to a tagged format. param_struct is defined in include/asm/setup.h. Some of its important fields are:

struct param_struct {

unsigned long page_size; /* 0: Size of the page */

unsigned long nr_pages; /* 4: Number of pages in the system */

unsigned long ramdisk /* 8: ramdisk size */

unsigned long rootdev; /* 16: Number representing the root device */

unsigned long initrd_start; /* 64: starting address of initial ramdisk */

/* This can be either in flash/dram */

unsigned long initrd_size; /* 68: size of initial ramdisk */


Note that the numbers represent the offset within the param structure where the fields are to be defined. This means that if the bootloader places the parameter structure at address 0xc0000100, then the rootdev parameter is placed at 0xc0000100 + 16, initrd_start is placed at 0xc0000100 + 64, and so on -- otherwise, the kernel will encounter difficulties in interpreting the correct parameters.

In a tagged list, each tag consists of a tag_header that identifies the parameter passed, followed by values for the parameter. The general format for a tag in the tag list could be as follows:

The kernel identifies each tag by the <ATAG_TAGNAME> header.

#define <aTAG_TAGNAME> <Some Magic number>

struct <tag_tagname> {

u32 <tag_param>;

u32 <tag_param>;


/* Example tag for passing memory information */

#define ATAG_MEM 0x54410002 /* Magic number */

struct tag_mem32 {

u32 size; /* size of memory */

u32 start; /* physical start address of memory*/


The setup_arch also needs to perform any memory mappings for flash banks, system registers, and other specific devices. Once the architecture-specific setup is done, control returns to the start_kernel function where the rest of the system is initialized. These additional initialization tasks include:

  • Setting up traps

  • Initializing interrupts

  • Initializing timers

  • Initializing console

  • Calling mem_init, which calculates the number of pages in various zones, high memory, and so on

  • Initializing the slab allocator and creating slab caches for VFS, buffer cache, etc.

  • Setting up various filesystems like proc, ext2, JFFS2

  • Creating kernel_thread, which execs the init command in the filesystem and displays the lign prompt. If no init program is present in /bin, /sbin, or /etc, the kernel will execute the shell present in /bin of the filesystem.

Debugging kernel


Porting Linux step by step

Below steps provides brief explanation about porting linux to ARM; these steps are very general.

Step 1 Machine registration

Register the machine type. In arch/arm/tools/mach-types

# machine_is_xxx CONFIG_xxxx MACH_TYPE_xxx number

scp ARCH_SCP SCP 900

This provides a unique numerical identifier for your machine, also provides configuration variable for your machine as CONFIG_MACH_$MACHINE.

Provides runtime machine-check (machine_is_xxx).

Step 2 Firmware to kernel transition

Requires boot loader to

● Initialize all memory controller and system RAM

● Initialize a single serial port for early boot messages

● Disable MMU

● Disable all caches

● Provide kernel parameter ATAG list

● Required registers:

– r0 = 0

– r1 = machine number

  • r2 = &(ATAG list)

We are using U-boot.

ATAG list is a data structure for providing machine details to kernel.

Usually located in first 16KB of RAM, most common is @RAM base + 0x0100.

ATAG list is defined in include/asm-arm/setup.h.

ATAG list consists of

ATAG_CORE- start of parameter list.

ATAG_MEM- memory size and location one per memory blocks.

ATAG_NONE- end of parameter list.

Directory file structure which need to be taken care while modifying,



● Cache/TLB/page fault/DMA handling


● core kernel setup, APIs, and syscall handling


● low-level helper functions (mostly ASM)


● code shared across various machine types


● Machine-type specific code (arch-ixp425, -pxa, -omap, etc)


● Default configuration for $PLATFORM (lubbock, ipaq, etc)

include/asm-arm/arch-$MACHINE (include/asm/arch)

– Machine-specific headers

Step 3 Early kernel init

At this stage kernel starts decompression, calling arch_decomp_setup(), during this stage it initializes serial port(if any), to see the messages.

Need to detect the CPU before starts initialization,

Kernel contains table of CPUs it supports in



First thing kernel does is check CPUID with table of CPUs

– Table contains a mask and expected value

If (cpuid & cpu_mask) == cpu_val we are OK

Otherwise we can't run on this CPU

– If OK, call CPU's _setup function.

If CPU is detected OK

Check for the machine type

Each platform has a machine descriptor structure: like

MACHINE_START(IXDP425, "Intel IXDP425 Development Platform")

MAINTAINER("MontaVista Software, Inc.")






.timer = &ixp4xx_timer,




Machine name/number from can be obtained from arch/arm/tool/mach-types.

Step 4 Mapping I/O devices

Certain devices need to be mapped before VM is fully up and running.

Like interrupt controller

Timer tick

Also certain devices need large virtual memory area

Static mapping allows usage of 1MB sections.

ioremap() uses only 4K pages

Call mdesc->map_io()

Call create_mapping() with static I/O mappings.

ARM-Linux Memory Map

Step 5 IRQ setup

IRQ are defined in defined in include/asm-arm/arch/irqs.h; with macro NR_IRQS

IRQ numbering is upto developer.

First level IRQ decoding is done in


get_irqnr_and_base irqnr, irqstat, base, tmp

Step 6 system timer tick

This is initialized after IRQ.

Load timer with LATCH,


● CLOCK_TICK_RATE is HW clock freq.

Request timer interrupt.


Timer ticks every (1/HZ)s

For getting timer interrupt, call first timer_tick() function.

gettimeoffset() function returns no of microseconds since last timer tick.

Step 7 board level initialization

Board_init() function is called; which adds platform devices such as flash, I2C etc. This is very board specific.

MCS8140 specific peripherals

[List out peripherals and write brief about what are file changes done in kernel source tree to support these peripherals]


Files changed


Target related changes


Added new dir


Interrupt management on MCS8140 (clear_irq, mask_irq, unmask_irq) ,do_level_irq, pci , usb routines.


Arch type and name mentioning, ,Configuring size and start of SDRAM


PCI bus registration, memory, irq mappings, configuration space reading routines.



- mov r7, #MACH_TYPE_SCP



Taking the param_struct out of "tag list" , "param_struct".


Added new dir


DMA hardware details e.g DMA channels, Max. DMA addr.( No changes)


Hardware mapping and base addr for all blocks e.g. BASE addr, offsets for PCI, USB, MAC etc..


Macros to perform various read/write operations


IRQ's numbers. memory mapping , some definitions for IRQs.


Minor change - File not required


defines phys_to_virt and vice-versa


packet cache manipulation functions ( not required)


reserved for future use


Definitions for serial port usage


Routines for cpu soft reset and cpu idle.


System timer initialization, routines for timer offset and it's interrupt.


serial console putc and puts funtions


clock tick rate


virtual memory allocation , start, offset, end definitions.



deals preempt changes


__asm_volatile changes for fiq.



Defines memory map symbols related to MCS8140 board and exports them Defines "arch/arm/boot/bootp/rdisk.bin.gz" as INITRD



Starting file to load and relocate the kernel. Enabled the D-Cache to have fast Uncompression of linux image on bootup.

Driver file changes



Initialization of serial console.



serial console code.



Ethernet probe added.



Chiefly added SKB debug messages apart from some minor target specifics.



Target specific enhacements related to packet cache



Console initilization delayed - Seems like not necessary.

Config and Makefile changes



Simple makefile for new C files in this directory.



"tristate ' SCP FIQ network support' CONFIG_SCP_FIQ_ETHER"


FIQ modules added.





serial_scp.o modules added.



Config file for adding SCP Architecture.



Config file for adding head_scp.o module.


- Added info regarding the ARCH type, CC and path to MODLIB for asm-arm -> asm.



Preempt_schedule exported ifdef CONFIG_PREEMPT



- Add fiq.o module support if CONFIG_SCP_FIQ_ETHER defined



ARCH_SCP 900 added.



changed to hard float and ifeq ($(CONFIG_ARCH_SCP),y) MACHINE = scp. for arch-scp -> arch & proc-armv -> proc .

copied below line,

machine-$(CONFIG_ARCH_SCP) := scp



- compressed bin file which is defined as INITRD



Default kernel config file



Selects what components to be built as modules.


Selects what components to be made part of the kernel



Selects the Driver SKB pool , PCH, Net profiling ,if CONFIG_ARCH_SCP is there.



Partitioning of flash for bootloader, environment variables, kernel and file system.

MAC, LP ,TSO driver



New directory for ethernet driver.

Root file system

We are using Journaling Flash File System, version 2 (JFFS2) in MCS8140.

Creating a JFFS2 file system

Basic steps for creating JFFS2 file

A JFFS2 file system (basically a Ram disk using JFFS2) is created under Linux with the mkfs.jffs2 command as follows

mkdir jffsfile

cd jffsfile

/* copy all the /bin, /etc, /usr/bin, /sbin/ binaries and /dev entries that are needed for the filesystem here */

/*Type the following command under jffsfile directory to create the JFFS2 Image */

./mkfs.jffs2 -e 0x40000 -p -o ../jffs.image

The -e option specifies the erase sector size of the flash (typically 64 kilobytes). The -p option is used to pad the remaining space in the image with zeroes. The -o option is used for the output file, which is usually the JFFS2 filesystem image -- in this case, jffs.image.

Before creating root file system we need to compile the kernel and make kernel image.

Steps in compiling kernel

  1. make menuconfig

  2. make zImage

  3. make modules

  4. Copy .ko files to respective directory; these directory will be copy of directory file structure on target board.

  5. run command create_flash_image kernel [./kernel source tree]; this will generate kernel image as scp_zimage.

  6. run command create_flash_image jffs2 [./target directory structure]; this will generate jffs2 file system with name flashdisk_jffs2.

  7. create_flash_image is a script file;

A JFFS2 file system (basically a Ram disk using JFFS2) is created under Linux with the mkfs.jffs2 command as follows

mkdir jffsfile

cd jffsfile

/* copy all the /bin, /etc, /usr/bin, /sbin/ binaries and /dev entries that are needed for the filesystem here */

/*Type the following command under jffsfile directory to create the JFFS2 Image */

./mkfs.jffs2 -e 0x40000 -p -o ../jffs.image

The -e option specifies the erase sector size of the flash (typically 64 kilobytes). The -p option is used to pad the remaining space in the image with zeroes. The -o option is used for the output file, which is usually the JFFS2 filesystem image -- in this case, jffs.image.

/bin and /sbin

The /bin directory contains essential user command binaries and /sbin directory contains essential system administration binaries.

About busybox

BusyBox is a single executable implementation of many standard Linux utilities. BusyBox contains simple utilities, such as cat and echo, as well as larger, more complex tools, such as grep, find, mount, and telnet (albeit, with fewer options than the traditional version); some refer to BusyBox as the Swiss Army knife of utilities. Busybox is a key component of MCS8140, as it gives extremely small footprint (A multi-call binary can perform the functions of many different applications.) for MCS8140 it is 971KB, compaired to standard linux utilites size as 3.4MB.

The easiest way for BusyBox to perform the function of one of the applications that it can emulate is by creating and naming a symbolic link and connecting it to the BusyBox binary. You then type the name of the symbolic link, which executes BusyBox. BusyBox uses symbolic links to make one executable look like many. For each of the utilities contained within BusyBox, a symbolic link is created so that BusyBox is invoked. BusyBox then invokes the internal utility as defined by argv[0].

Currently defined functions in busybox v1.1.3 are

[, [[, addgroup, adduser, ash, awk, basename, bunzip2, busybox,

bzcat, cat, chgrp, chmod, chown, chroot, clear, cp, cut, date,

dd, delgroup, deluser, df, dirname, dmesg, du, echo, egrep, env,

expr, false, fdisk, fgrep, find, free, freeramdisk, ftpget, ftpput,

getty, grep, gunzip, gzip, halt, head, hostname, id, ifconfig,

init, insmod, kill, killall, klogd, linuxrc, ln, logger, login,

ls, lsmod, mesg, mkdir, mkfs.minix, mknod, modprobe, more, mount,

mv, netstat, nslookup, passwd, ping, poweroff, printf, ps, pwd,

reboot, reset, rm, rmdir, rmmod, route, sed, sh, sleep, sort,

start-stop-daemon, su, sulogin, sync, syslogd, tail, tar, tee,

telnet, telnetd, test, tftp, time, top, touch, tr, umount, uname,

uniq, unzip, uptime, usleep, vi, vlock, wc, which, who, whoami,


These all functions which are present in /bin and /sbin are symbolic link to busybox bin.


This directory contains system configuration files, including startup files.

About /init.d/rcS

This startup script present in /etc directory creates ramdisk of 42MB, this is being used for storing temporary messages. Actually /tmp -> rdisk0/tmp means /tmp directory is a link to rdisk0/tmp and /var is link to rdisk0/var. After creating ramdisk and /tmp and /var folders this script file starts syslogd and klogd daemons.


This directory contains devices and other special files.


This directory contains virtual file system for kernel and process information. This is useful for mounting virtual file system.


It contains temporary files.


It contains variable data stored by daemons and utilities.


It contains essential libraries, such as C library and kernel modules.


It contains mount point for temporarily mounted file system.


It contains specific modules related to hardware block developed.


This is secondary hierarchy containing most applications and documents useful to most users.



Popular posts from this blog

dasara marathi message dasara greetings in marathi

Dasara Marathi Greetings-SMS-marathi-Messages-vijaya dasami
marathi greeting cards for vijaya dasami
Happy Vijaya Dashami ! Celebrate the victory of the forces of good over Evil
Dasara is celebrated in Nepal by the name of Dashain. Vijayadashami (Hindi and Marathi: विजयादशमी, Kannada:ವಿಜಯದಶಮಿ)

Marathi Wishes for Dasara..
Apanas ani aplya kutumbiyans Vijayadashami nimmitt hardik shubhechha!

dassera greetings, marathi world, greetings, dassera, marathi greeting MARATHIGREETING.COMSpecial Marathi Greetings from ...Dasera, nljk. New Born, ckGkph pkgwy. Marathi Birthday, okMarathi Diwali ...

मराठी शुभेच्छापत्रे greeting marathi greetings...New Marathi Greeting Cards. Send this Marathi Dipawali Greeting Dasara Greeting Card to your friends · Click to Send this Greeting card to your friends for ...

मराठी शुभेच्छापत्रे - Greetings Cards, Marathi ...
Send free Marathi Greetings, electronic Greetings, m…

Xilinx's Interview Questions

Xilinx is the world's one of largest supplier of programmable logic devices. It has started R & D department in Hyderabad, India. It has broad scope for embedded system programming in device driver in linux.

Before the interview you have to feel the Xilinx form with information containing all academic details, current/previous employer, contacts of employer( to check out info about you), current ctc, expected ctc and expected date of joining, etc.

I appeared two back to back technical interviews.

The first interview was taken by a young man look like just crossed 30's.

He asked me to tell me about myself.

Then he asked my experience.

He checked my expertise in resume.

He asked questions about RTOS, and Linux Device Drivers.
What is RTOS ? Define it.
How a linux device driver works?
How a character driver works?

He looked at my project summaries and started to ask in depth questions about each project.

After that he asked me to write to delete nth node from starting in Singly Linked Li…

Rajasthan Board 10th Results | | RBSE

Raj Board of Secondary Education, Rajasthan Results at rajeduboard.nic.inBoard of Secondary Education, Rajasthan Ajmer declared result of secondary examination today at 4PM official site is

check Secondary Examination- 2008 Result
(To be announced on July 1st, 2008 at 4:00 PM)

Declared result
Praveshika Examination-2008 Result
(Announced on June 25, 2008 at 4:00 PM)

The history of the Board of Secondary Education Rajasthan (BSER) is a remarkable panorama of progressive record of the futurological vision for developing a dynamic system of various sub-systems of examinations and highlights of the academic excellence of the last four decades. The BSER took rapid strides for promotion and development of Secondary Education in Rajasthan, spread over 3,42,239 sq. km. and in more than 6000 schools located in 32 districts involving 8.5 lakhs students for Secondary and Senior Secondary Examination in the year 2000.

At present the Board is conducting …