Search This Blog

Wednesday, October 9, 2013

Developing Linux OS for ARM - Part IV

Bootstrap is in place ------- > Yes

U-boot is in place      ------->  Yes

Now its time to build kernel image, which will take­over control of the hardware.
We would be discussing the procedure for booting the Linux operating system on board. However,  AT91SAM9260 also supports other popular operating systems like WinCE, FreeRTOS, uC/OS­II, eCOS etc. Refer to  for more information on the same.

The primary site for the Linux kernel source is

we will download the kernel source at the following path:­2.6.27.tar.bz2

Download it to the following path: /Embedded_Linux_Complete/Sources/Linux_kernel/ . A copy of the source is also present in the archives under the following path:


Extract the contents in the current directory.

/Embedded_Linux_Complete/Sources/Linux_kernel$ ls
linux-2.6.27   linux-2.6.27.tar.bz2

Next step would be to download the AT91 maintainers patch, which is the stable patch for AT91. This can be downloaded from:

Download/Copy this to the following path:
After downloading the maintainer's patch apply it on top of the Linux kernel as shown:
 zcat 2.6.27-at91.patch.gz  | patch -p1

Next you can also take the experimental patchset

to the same location and apply it on top of the AT91 one as shown:

/Embedded_Linux_Complete/Sources/Linux_kernel/linux-2.6.27$ zcat 2.6.27-at91-exp.2.patch.gz  |  patch -p1

Now you have to configure the Linux kernel according to your hardware. First identify your kernel revision, your board and then, download the corresponding configuration file. In our case, for AT91SAM9260, the configuration file can be downloaded from

Download the configuration file in


Follow the below mentioned steps to configure the build process:

~/linux-2.6.27$ cp at91sam9260ek_defconfig .config

~/linux-2.6.27$ make CROSS_COMPILE=/home/sanket/Download/Embedded_Linux_Complete/Package/GNU_GCC_toolchain/arm-2007q1/bin/arm-none-linux-gnueabi- ARCH=arm oldconfig

In the above case, the default config that was stored in ~/Linux_kernel/linux­-2.6.27/arch/arm/configs will be used based on the target controller that you have specified.

In case you want to make your own customised kernel, you can configure all options individually using a menu based configuration interface. This can be done using:

~/linux-2.6.27$ make CROSS_COMPILE=/home/sanket/Download/Embedded_Linux_Complete/Package/GNU_GCC_toolchain/arm-2007q1/bin/arm-none-linux-gnueabi- ARCH=arm menuconfig

But before that, for kernel compilation and buildroot, you need to have the some software packages installed on the the host machine. The folliwing is the list of softwares required:

• GNU C/C++
• GNU make
• wget
• sed
• flex
• bison
• m4
• patch
• gettext
• libtool • texinfo
• autoconf
• automake
• ncurses library (development install)
• zlib library (development install)
• libacl library (development install)
• lzo2 library (development install)
• glib library (development install) ­ if some packages selected

On ubuntu, one can install all of these packages simultaneously in the following way:

~/linux-2.6.27$ sudo apt-get install make flex bison m4 ncurses-dev gettext texi2html texinfo zlib1g zlib1g-dev liblzo2-2 liblzo2-dev libacl1 libacl1-dev libglib2.0-dev autoconf automake libtool

Once these packages have been correctly installed , we would be able to have a menu based configuration as shown below:

~/linux-2.6.27$ make CROSS_COMPILE=/home/sanket/Download/Embedded_Linux_Complete/Package/GNU_GCC_toolchain/arm-2007q1/bin/arm-none-linux-gnueabi- ARCH=arm menuconfig

 On typing the above command you would see a menu based configuration utility

Each of the categories shown above will further have kernel modules which can be either retained or removed. Linux supports the concept of loadable kernel modules, which means that many of these kernel modules can also be dynamically loaded/unloaded after the kernel has booted on the target hardware instead of including them at compile time.

Typically, [*] or <Y> symbolises that the corresponding modules are to be retained in the kernel image at the time of compilation, [ ] or <N> symbolises that the corresponding modules are not to be included in the kernel during the compilation, while <M> symbolises that the corresponding modules will not be loaded during the compile time but the kernel will include modules that would support the dynamic loading of these modules.

There are two options available while doing this:

   1. Load a default configuration: We have a default configuration file called
at91sam9260ek_defconfig, which we can load using the “Load an Alternate
configuration file”

    2. Make your own configuration: If we want to prepare a new configuration altogether, we can select the appropriate options.

Once these steps have been performed we can then save the required configuration using the “Save an Alternate configuration file” option. You will get a .config file generated within your current directory. Also, if there was a previous .config file existing within your current directory, a .config.old would be generated so that you can load it at some time in future if required again.

We will go with the default configuration file supplied to us by the AT91 maintainers. Once this is done, you can ensure that the .config file has been generated in the following way:

/linux-2.6.27$ ls -al| grep "config"

Finally , we arrive to the point where we are ready to build the kernel image:

/linux-2.6.27$ make CROSS_COMPILE=/home/sanket/Download/Embedded_Linux_Complete/Package/GNU_GCC_toolchain/arm-2007q1/bin/arm-none-linux-gnueabi- ARCH=arm

At the end of the compilation process, a zImage and Image file would be generated under the following path: /Linux_kernel/linux­2.6.27/arch/arm/boot.

U­Boot does not support normal linux kernel images like zImage or Image (arch/arm/boot/), so you have to create an uImage file with the mkimage tool which encapsulates kernel image with header information, CRC32 checksum, etc. Download mkimage using:

/linux-2.6.27$ sudo apt-get install uboot-mkimage
Once mkimage is available run the following command to generate an uncompressed uImage file:

/linux-2.6.27$ mkimage -A arm -O linux -C none -T kernel -a 20008000 -e 20008000 -n linux-2.6 -d arch/arm/boot/Image uImage

Once the above steps are performed you will get a uImage file generated in your current directory, which would be used as the kernel image for booting Linux on your ARM platform.

Next step would be to build a rootfs image. That we would be continuing in my next post.


Developing Linux OS for ARM - Part III

Hello. I am back. Its really very long time to pen down where I have stop. I will continue with PART III of developing Linus OS for ARM.

As we already configure primary bootloader AR91Bootstrap in PART II. Its time to configure a secondary bootloader.

In most cases, U­Boot is the secondary bootloader, which is in charge of downloading kernel binaries from FLASH, SD/MMC, USB or ethernet and starting the kernel.

Download the secondary bootloader (U­boot). It can be downloaded
from the following link:

we will download the u­boot­1.3.4.tar.bz2 at the following path:


Extract the same in the current directory.

Download u­boot patch provided by the AT91 community from the below mentioned link:

Creating a patch is a standard way of adding newly generated code to a large existing code base. It is created by comparing the updated code with the code base for which the patch is to be generated.

Save this to the ~/Embedded_Linux_Complete/Sources/u­boot/u­boot­1.3.4.

/u-boot-1.3.4$ ls

Apply it (patch) on top of the original u­boot in the following way:

/u-boot-1.3.4$ cat u-boot-1.3.4-exp.diff | patch -p1

Once the AT91 u­boot sources  are available, cross­compiling u­boot can be done in two steps : configuration and compiling. Note that both arm­elf­ and arm­linux­ ARM GCC cross­compiler types are suitable for u­boot building. We will use arm­none­-linux­-gnueabi­-gcc.

Here are the building steps for the AT91SAM9260EK board:

/u-boot-1.3.4$ make CROSS_COMPILE=/home/sanket/Download/Embedded_Linux_Complete/Package/GNU_GCC_toolchain/arm-2007q1/bin/arm-none-linux-gnueabi- distclean

distclean command removes the binaries and object files files that 'configure' created. Distclean is like make clean with the exception that make clean removes all the files created by make, where as distclean removes all files that are created by make config.

The U­boot can be made to reside on any of the following storage media: Data flash/NAND flash/NOR flash. In our case we are using the dataflash, but NAND flash can also be used since AT91Bootstap supports both. The AT91Bootstrap will pass the environment variables to U­boot while it tries to bring U­boot up.

So while we compile U­boot we will configure it for Dataflash.

/u-boot-1.3.4$ make CROSS_COMPILE=/home/sanket/Download/Embedded_Linux_Complete/Package/GNU_GCC_toolchain/arm-2007q1/bin/arm-none-linux-gnueabi- at91sam9260ek_dataflash_cs1_config

These environment variables includes the IP address setting of the host, the server from which U­boot would tftp to retrieve some packages and more. When U­boot is up and running on our board we will try and view all these environment variables.

NOTE: In our case, the software packages have been made to reside in the dataflash. In some cases, they might reside in NAND Flash or NOR flash. While compiling u­boot the environment variable location needs to be choosen accordingly. 

To compile u­boot after configuration,

/u-boot-1.3.4$ make CROSS_COMPILE=/home/sanket/Download/Embedded_Linux_Complete/Package/GNU_GCC_toolchain/arm-2007q1/bin/arm-none-linux-gnueabi- 

If the compilation goes well, a uboot.bin file would be generated in your current directory which would be ultimately flashed to the dataflash using a software utility called SAM­BA (Burning Application for SAM controllers).

Once the bootloader is in place, next step would be to build a kernel image. That we would be discussing in my next post.


Saturday, March 26, 2011

Developing Linux OS for ARM - Part II

With the previous understanding of Part I, the first thing that you need to get is the toolchain. The toolchain might be available in source form as well as in the form of a binary. To avoid the effort of compiling the toolchain, we will start off with a binary. CodeSourcery provides regular, validated releases of the GNU Toolchain for arm processor. The version of the toolchain that we are using can be downloaded from the following link:

After downloading this package, extract it to some location (In my case, I have pasted at the following path: /home/sanket/Downloads/Embedded_Linux_Complete/Packages/GNU_GCC_toolchain).

Download the AT91Bootstrap source from the following link:

The AT91Bootstrap sources will differ based on the media where the secondary level bootloader is located. In our case, we want our secondary bootloader to be loaded in the dataflash and hence we will download the corresponding package. Alternate option for the secondary level bootloader would have been NAND flash.
Extract the AT91Bootstrap source, change to the board directory as shown below:

$cd AT91Bootstrap/Bootstrap-v1.10/board/

at91cap9adk     at91sam9261ek     at91sam9g20ek     at91sam9xeek
at91sam9260ek     at91sam9263ek     at91sam9rlek

Select your board by going into the corresponding board directory.

/board$ cd at91sam9260ek/
/board/at91sam9260ek$ ls

at91sam9260ek.c    dataflash    nandflash

Select your media by going into the corresponding directory. In our case the media for the secondary bootloader would be dataflash.

/at91sam9260ek$ cd dataflash/
at91sam9260ek/dataflash$ ls

at91sam9260ek.h       dataflash_at91sam9260ek.elf       Makefile

dataflash$ make clean

rm -f *.o *.bin *.elf *.map

Before building the sources, check out the location of your compiler toolchain. In
my case, it is


While running make we would be specifying the entire path. This is required if you have not installed the toolchain. In our case, instead of installing we have just extracted the tar ball image of the toolchain and hence we need to specify the path as shown below:

/dataflash$ make CROSS_COMPILE=/home/sanket/Downloads/Embedded_Linux_Complete/Package/GNU_GCC_toolchain/arm-2007q1/bin/arm-none-linux-gnueabi-

If everything is fine (compiler path and bootstrap source) a binary file (dataflash_at91sam9260ek.bin) will be generated in the current directory at the end of the compilation process.

/dataflash$ ls

at91sam9260ek.h        crt0_gnu.o        dataflash_at91sam9260ek.elf
dataflash.o     div0.o    main.o    pmc.o    string.o _udivsi3.o
at91sam9260ek.o    dataflash_at91sam9260ek.bin    debug.o     gpio.o    Makefile    
sdramc.o     udiv.o      _umodsi3.o

continue ......................................

Saturday, February 12, 2011

Developing Linux OS for ARM - Part I

The first thing that you possibly need to do after getting your hardware ready is to install the necessary software packages and toolchain on the host system (PC).These packages would be required to compile and download/burn packages on to your target platform (ARM9/any embedded controller). We would be talking specifically about the AT91SAM9260 from ATMEL, which is an ARM9 based architecture giving 200MIPS at 180MHz. Although AT91SAM9260 would be our target controller, most of the software components that we discuss would apply to all target platforms. The lower level softwares like the primary level bootloader would be architecture specific. The AT91SAM9260, also known as Smart ARM based controllers (aka SAM) is based on the integration of an ARM926EJS processor with fast ROM and RAM memories and a wide range of peripherals. The AT91SAM9260 embeds an Ethernet MAC, one USB Device Port, and a USB Host controller. It also integrates several standard peripherals, such as the USART, SPI, TWI, Timer, Counters, Synchronous Serial Controller, ADC and MultiMedia Card Interface. Primarily for porting the conventional Linux, we would need MMU support in hardware. ARM9 based MCUs feature an MMU (unlike most ARM7 MCU) and hence we do not need to use some other stripped down Linux variants like uCLinux which can be ported to MMU less architectures.

The following would be the software components required to get Linux running on the target system : 

Root filesystem

Linux Kernel
Hardware (MCU)

Bootloader :

The bootloader can be further classified into:

1. Primary bootloader: This might typically reside onchip (internal flash). In case of AT91SAM9260, a component called ROMboot enables us to dump the primary bootloader to the on chip flash. The primary bootloader is called AT91Bootstrap. A primary bootloader is needed for configuration of CPU parameters like clock frequency, incharge of hardware configuration, download UBoot (secondary bootloader) from FLASH to SDRAM and start the bootloader.

2. Secondary bootloader: In most cases, UBoot is the secondary bootloader, which is in charge of downloading kernel binaries from FLASH, SD/MMC, USB or ethernet and starting the kernel.

Once the bootloader has loaded the kernel in the memory, the operating system kernel will then takeover control of the hardware. The kernel comprises of the scheduler and the device drivers. The other utilities provided by any standard OS distribution are not a part of the kernel space. The Root filesystem contains applications which are executed on the target, using the OS kernel services. It forms the user space. Its primarily an archive of utilities like cat, ftp, vi, gedit, ls etc

continue ......................................

Saturday, January 15, 2011

Difference between ARM and Intel Processor

The world of CPUs is a dark, deadly, and dangerous place. After all, the CPU is said to be the literal “heart” of the PC – and as such, it’s the single most-heavily engineered component. Billions of dollars and manhours have gone into the design of these various chipsets and they’ve all been researched, optimized, fabricated, and sold in order to make your computer… better.

The biggest difference between these platforms is the design dogma they follow. The x86 is a CISC architecture: Complex Instruction Set Computer. The ARM is a RISC-based designs: Reduced Instruction Set Computer.

CISC architectures can have up to thousands of individual commands supported by the processor that can be used in machine code. Each of these assembly commands can range from a single operation to several hundred or more in length. On the other hand, RISC-based CPUs understand only a handful of different instructions, the minimum necessary to get the job done.

However, this in no way means that CISC is more powerful or that RISC is limited. The difference between the ARM and Intel can be explained with booting process of an OS.

In the Intel x86 architecture the bootloader is called from BIOS (Basic Input / output system). It then loads the kernel into RAM from the filesystem, & execute the kernel. At this point the kernel has control & accesses the filesystem. On an Intel architecture you need only to place the bootloader on the boot sector of the hard drive and have an accessible filesystem.

On the ARM, there is no BIOS, & no delay for the POST. There is also no hard drive. So the first thing to run is the bootloader, which then loads the kernel directly from flash (and not of a filesystem). The bootloader passes execution to the kernel. The kernel then accesses the filesystem & things are pretty similar to an x86 boot sequence from there.

The other important difference between the Intel world & the ARM world is that the bootloader is also used to transfer the OS image onto the flash device

Friday, December 31, 2010

Basic Operating System Overview

One killer application of Linux is to be used as the operating system of an embedded system. ARM-based CPUs are killer partners of embedded Linux. Operating system consist of three main parts:
  • Bootloader
  • Kernel and
  • Filesystem

Bootloader :

Unlike regular computer, most embedded systems don't have a firmware out-of-box like CMOS, Openfirmware or EFI, etc. Instead, you need to install the bootloader yourself or it is burned onto the board already. Generally, to a naked system, people use JTAG protocol to burn a bootloader. A bootloader can provide a interface for users to control the system as well as basic system tools, such as writing data into flash or transferring files from the host machine.


Kernel :

In computing, the kernel is the central component of most computer operating system; it is a bridge between applications and the actual data processing done at the hardware level. The kernel's responsibilities include managing the system's resources (the communication between hardware and software components). Usually as a basic component of an operating system, a kernel can provide the lowest-level abstraction layer for the resources (especially processors and I/O devices) that application software must control to perform its function. It typically makes these facilities available to application processes through inter-process communication mechanisms and system calls.
The Linux kernel is an operating system kernel used by the Linux family of Unix-Like Operating system. It is one of the most prominent examples of free and open source software. 

The Root Filesystem :

Other than the Linux kernel, most embedded Linux system contain things such as a graphic environment as on most PDAs. The collection of all those files is called the Root Filesystem. It generally is stored in the flash partition called root. Attention, here "Root" is not equal to the /root directory and here "filesystem" is not a software to manager files on storage devices. The Root Filesystem is in the form of an image to be written into the flash memory.

Sunday, December 26, 2010

Deploying u-boot, Linux kernel and GPE onto Mini2440


Before you start, you will need
  1. A mini2440 development board, with or without a 3.5"/7" LCD.
  2. A software called minicom on your PC
  3. The u-boot image, Linux kernel image, and GPE image, as well as the USB-downloader program to transfer files from your Linux PC to the NAND flash on mini2440 via a USB cable.
  4. A non-cross RS232 cable (both female heads) and a USB type-A-to-type-B cable (one head is the regular USB head as on your USB flash/thumb drive, and the other one is the little square one, like the one to connect your printer.)

Step 1: Setting up the minicom

  • Install minicom(for example, via command "sudo apt-get install minicom") 

  • On a shell prompt, type "minicom -s" 

  • Use up and down arrow to select "Serial port setup". 

  • If you wanna setup something, press the button corresponding to that item. After you finished, press Enter to exit. Besure to configure "Bps/Par/Bits" and "Hardware Flow Control" as same as the snapshot. You can save this configuration as default so that you don't need to set it again next time.

  • Then select "Exit" and press Enter. Don't select "Exit from Minicom", otherwise you are out of minicom.

  • Please note that your serial port does NOT have to be /dev/ttyUSB0, since I used a USB-to-RS2323 converter. It is only my case. In your case, it could be /dev/ttyS1 or /dev/ttyS0. But make sure set all the reset parameters as I did. 

    Step 2: Replacing vivi by u-boot 


    The mini2440 comes with two flashes, the NOR flash and the NAND flash. The NOR flash stores vivi by default. So I am NOT gonna overwrite it, in case I need it. I am gonna overwrite the NAND flash by u-boot, Linux kernel 2.6.31 and GPE.
    I will boot the board from NOR flash, using vivi in it to write u-boot into NAND flash. And then, I will reboot the board from NAND flash, and use u-boot to finish all the rest.
    Turn the boot selection switch to NOR flash on the board. Connect mini2440 with PC using minicom via RS232. Power on the board and you shall see this boot-up menu:

    ##### FriendlyARM BIOS for 2440 #####
    [x] bon part 0 320k 2368k
    [v] Download vivi 
    [k] Download linux kernel 
    [y] Download root_yaffs image 
    [c] Download root_cramfs image 
    [a] Absolute User Application
    [n] Download Nboot 
    [e] Download Eboot 
    [i] Download WinCE NK.nb0 
    [w] Download WinCE NK.bin 
    [d] Download & Run 
    [f] Format the nand flash 
    [p] Partition for Linux 
    [b] Boot the system 
    [s] Set the boot parameters 
    [t] Print the TOC struct of wince 
    [u] Backup NAND Flash to HOST through USB(upload) 
    [r] Restore NAND Flash from HOST through USB 
    [q] Goto shell of vivi 
    Enter your selection: q
    Press q and Enter at the prompt and switch to vivi promp.
    Now connect PC with mini2440's USB device port, via a USB cable. Make the compiled u-boot image handy. Tell vivi that you need 239016 Bytes space in the RAM to load something from the USB, starting at 0x31000000

    Supervivi> load ram 0x31000000 239016 u
    USB host is connected. Waiting a download. 
    On another shell window, use following command to download  u-boot into the RAM of mini2440

    $ sudo ./s3c2410_boot_usb u-boot.bin 
    Enter root password when prompted, and you shall see this output on the shell

    csum = 0xd542
    send_file: addr = 0x33f80000, len = 0x0003a5a8
    Error downloading program
    Please ignore the error.

    Now go back to vivi. You shall see follows

    Now, Downloading [ADDRESS:31000000h,TOTAL:239026]
    RECEIVED FILE SIZE:  239026 (233KB/S, 1S)
    Downloaded file at 0x31000000, size = 239016 bytes
    Now we are ready to write u-boot from the RAM to NAND flash. Execute the code starting at RAM location 0x31000000:

    Supervivi> go 0x31000000
    go to 0x31000000
      argument 0 = 0x00000000
      argument 1 = 0x00000000
      argument 2 = 0x00000000
      argument 3 = 0x00000000
    U-Boot 1.3.2-dirty-moko12 (Apr 16 2009 - 18:14:52)
    I2C:   ready
    DRAM:  64 MB
    Flash:  2 MB
    NAND:  Bad block table not found for chip 0
    Bad block table not found for chip 0
    64 MiB
    Found Environment offset in OOB..
    USB:   S3C2410 USB Deviced
    In:    serial
    Out:   serial
    Err:   serial
    MAC: 08:08:11:18:12:27
    Hit any key to stop autoboot:  0
    When seeing "Hit any key to stop autoboot," press any key on the keyboard. The prompt shall change from Supervivi> to MINI2440 #. Get the information about the NAND flash:

    MINI2440 # nand info
    Device 0: NAND 64MiB 3,3V 8-bit, page size 512, sector size 16 KiB 
    Erase everything on the NAND flash:

    MINI2440 # nand scrub
    NAND scrub: device 0 whole chip
    Warning: scrub option will erase all factory set bad blocks!
             There is no reliable way to recover them.
             Use this command only for testing purposes if you
             are sure of what you are doing!
    Really scrub this NAND flash? <y/N>
    Erasing at 0x3ffc000 -- 100% complete.
    Bad block table not found for chip 0
    Bad block table not found for chip 0
    Please enter a lower case y and press Enter when prompted. 
    Now create a new partition table

    MINI2440 # nand createbbt
    Create BBT and erase everything ? 
    Skipping bad block at  0x03ff0000                                            
    Skipping bad block at  0x03ff4000                                            
    Skipping bad block at  0x03ff8000                                            
    Skipping bad block at  0x03ffc000                                            
    Creating BBT. Please wait ...Bad block table not found for chip 0
    Bad block table not found for chip 0
    Bad block table written to 0x03ffc000, version 0x01
    Bad block table written to 0x03ff8000, version 0x01
    and partition the NAND flash using u-boot default configuration. Each partition shall be given a name.

    MINI2440 # mtdparts                    
    device nand0 <mini2440-nand>, # parts = 4
     #: name                        size            offset          mask_flags
     0: u-boot              0x00040000      0x00000000      0
     1: env                 0x00020000      0x00040000      0
     2: kernel              0x00500000      0x00060000      0
     3: root                0x03aa0000      0x00560000      0
    active partition: nand0,0 - (u-boot) 0x00040000 @ 0x00000000
    mtdids  : nand0=mini2440-nand
    mtdparts: <NULL>
    Now write u-boot to NAND flash

    MINI2440 # nand write 0x31000000 u-boot
    NAND write: device 0 offset 0x0, size 0x40000
     262144 bytes written: OK 
    Reset the on-board switch to NAND flash and reboot mini2440

    Step 3: Downloading Linux Kernel

    Now you shall see all u-boot informations on the minicom window. Hit any key when you see the promption "Hit any key to stop autoboot."
    Now set a NAND flash offset since later you won't want to write stuffs on the area that contains u-boot.

    MINI2440 # dynenv set 40000
    device 0 offset 0x40000, size 0x3fc0000
    45 4e 56 30 - 00 00 04 00
    MINI2440 # nand erase kernel
    NAND erase: device 0 offset 0x60000, size 0x500000
    Erasing at 0x55c000 -- 100% complete.
    Copy the Linux kernel image onto an SD card and insert the SD card to  the card reader of mini2440. Now initialize the SD card.

    MINI2440 # mmcinit
    trying to detect SD Card...
    Manufacturer:       0x02, OEM "TM"
    Product name:       "SD01G", revision 2.3
    Serial number:      2486075243
    Manufacturing date: 1/2002
    CRC:                0x72, b0 = 1
    size = 1642070016
    Suppose the Linux kernel image has the filename "uImage." Now load it  to the RAM first.

    MINI2440 # fatload mmc 0:1 0x31000000 uImage
    reading uImage
    1945804 bytes read
    Write the Linux kernel from RAM to the NAND flash partition called "kernel."

    MINI2440 # nand write 0x31000000 kernel
    NAND write: device 0 offset 0x60000, size 0x500000
     5242880 bytes written: OK

    Step 4: Downloading GPE Embedded Graphic Environment

    Well, at this step, you have plenty of choices. You can try Qtopia, etc. But I prefer GPE, which is GPL'ed and small. Things like GPE are called Root Filesystems. You can follow the same steps that you did for downloading Linux kernel. Just write to NAND partition "root" instead of "kernel."
    Initialize SD card

    MINI2440 # nand erase root
    MINI2440 # mmcinit
    trying to detect SD Card...
    Manufacturer:       0x02, OEM "TM"
    Product name:       "SD01G", revision 2.3
    Serial number:      2486075243
    Manufacturing date: 1/2002
    CRC:                0x72, b0 = 1
    size = 1642070016 
    Load GPE image to RAM, supposing the filename is gpe-image-micro2440.jffs2.
    MINI2440 # fatload mmc 0:1 0x31000000 gpe-image-micro2440.jffs2
    reading gpe-image-micro2440.jffs2
    39239680 bytes read
    Since the GPE image is compiled in JFFS2 filesystem, you need to write it as a JFFS2 image.

    MINI2440 # nand write.jffs2 0x31000000 root ${filesize}
    NAND write: device 0 offset 0x560000, size 0x256c000
    Writing data at 0x2acbe00 -- 100% complete.
     39239680 bytes written: OK


    Now you are pretty much done. Just do the two last things as follows

    MINI2440 # setenv bootcmd nboot.e kernel \; bootm
    MINI2440 # saveenv
    Saving Environment to NAND...
    Erasing Nand...Writing to Nand... done
    Now reset your mini2440 and enjoy!