Application of INITRD in embedded Linux--Analysis of RAMDisk, Ramfs, INITRD and Initramfs__linux

Reference to the original network: http://blog.csdn.net/zhouxinfengone/article/details/7738698

Http://hi.baidu.com/deep_pro/blog/item/220df2dddac6e3d28d1029dd.html

In the essential Linux.device drivers saw such a remark
During the development of embedded systems, INITRD and INITRAMFS can sometimes be used as the actual root file system on embedded devices.

To see such a sentence is very confusing to me, because it seems I understand that to do this can improve a bit of embedded Linux startup speed, I am very interested in this
Since then, I've been on a journey of doubt.

The first thing you need to know is RAMDisk and Ramfs.
http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Introducing-initramfs-a-new-model-for-initial-RAM-disks/
or kernel source/documentation/filesystems/ramfs-rootfs-initramfs.txt
From the above article, we can generally understand that RAMDisk is a ram-based block device, Ramfs is a ram based file system, the purpose of developing RAMFS is because ramdisk waste too much memory cache page, Ramfs is based on an instance of TMPFS

Logically, INITRD is the abbreviation of init RAMDisk, INITRAMFS is the abbreviation of init Ramfs
Names are added with the init prefix, which means they have the ability to boot the kernel
Ramfs is more efficient than RAMDisk, natural Initramfs is also better, is a recommended mechanism for the 2.6 kernel added, although the kernel cmd line parameter used by grub in the PC may be
kernel/vmlinuz-2.6.25-14.fc9.i686 ro root=uuid=11d7ac51-2b45-489e-8a48-8d2a28e2c04e rhgb quiet
INITRD/INITRD-2.6.25-14.FC9.I686.IMG, the actual use of Initramfs, can be separated by file format. INITRD is gziped, Initramfs is cpio.

The rest of it just says Initrd.
The first is the role of INITRD: Kernel mirroring should be as small as possible, so it should not contain too many drive modules statically. But the Linux kernel starts the final step, creates the Init kernel thread, and the INIT program or script that needs to be executed is not in the kernel image, but in the root file system. The root file system may be on a hard disk, disk array, NFS, Flash, and the root file system is also in a variety of formats. At this point, you really do not want to include so many drivers to mirroring, you can use INITRD as a transition.
The content of INITRD itself is a streamlined root file system that contains the necessary directories and programs, and even an init script or program LINUXRC
Everything, because of the high customization of Linux, everything you have. Usually the latter on the PC

Take the PC as an example, first copy a initrd-2.6.25-14.fc9.i686.img, to prevent damage to it can not open the machine
Then rename its backup to GZ, unzip
[Root@localhost boot]# MKDIR/TMP/INITRD
[Root@localhost boot]# CP initrd-2.6.25-14.fc9.i686.img/tmp/initrd/
[Root@localhost boot]# cd/tmp/initrd/
[Root@localhost initrd]# MV Initrd-2.6.25-14.fc9.i686.img initrd-2.6.25-14.fc9.i686.gz
[Root@localhost initrd]# gunzip initrd-2.6.25-14.fc9.i686.gz
[Root@localhost initrd]# ls
initrd-2.6.25-14.fc9.i686
[Root@localhost initrd]# file initrd-2.6.25-14.fc9.i686
Initrd-2.6.25-14.fc9.i686:ascii Cpio Archive (SVR4 with no CRC)

Continue to unzip, view the Init script under its root directory, and its important place is bold.
#!/bin/nash

Mount-t Proc/proc/proc
Setquiet
Echo Mounting proc FileSystem
echo Mounting SYSFS filesystem
Mount-t Sysfs/sys/sys
Echo Creating/dev
Mount-o mode=0755-t Tmpfs/dev/dev
Mkdir/dev/pts
Mount-t Devpts-o gid=5,mode=620/dev/pts/dev/pts
Mkdir/dev/shm
Mkdir/dev/mapper
echo Creating initial device nodes
Mknod/dev/null C 1 3
Mknod/dev/zero C 1 5
Mknod/dev/systty C 4 0
Mknod/dev/tty C 5 0
Mknod/dev/console C 5 1
MKNOD/DEV/PTMX C 5 2
Mknod/dev/tty0 C 4 0
Mknod/dev/tty1 C 4 1
Mknod/dev/tty2 C 4 2
Mknod/dev/tty3 C 4 3
Mknod/dev/tty4 C 4 4
Mknod/dev/tty5 C 4 5
Mknod/dev/tty6 C 4 6
Mknod/dev/tty7 C 4 7
Mknod/dev/tty8 C 4 8
Mknod/dev/tty9 C 4 9
Mknod/dev/tty10 C 4 10
Mknod/dev/tty11 C 4 11
MKNOD/DEV/TTY12 C 4 12
MKNOD/DEV/TTYS0 C 4 64
MKNOD/DEV/TTYS1 C 4 65
Mknod/dev/ttys2 C 4 66
MKNOD/DEV/TTYS3 C 4 67
echo Setting up HotPlug.
HotPlug
echo Creating block device nodes.
Mkblkdevs
echo "Loading EHCI-HCD module"
Modprobe-q EHCI-HCD
echo "Loading OHCI-HCD module"
Modprobe-q OHCI-HCD
echo "Loading UHCI-HCD module"
Modprobe-q UHCI-HCD
Mount-t Usbfs/proc/bus/usb/proc/bus/usb
echo "Loading ext3 module"
Modprobe-q ext3
echo "Loading scsi_mod module"
Modprobe-q Scsi_mod
echo "Loading sd_mod module"
Modprobe-q Sd_mod
echo "Loading libata module"
Modprobe-q Libata
echo "Loading ata_generic module"
Modprobe-q Ata_generic
echo "Loading pata_acpi module"
Modprobe-q PATA_ACPI
echo waiting for driver initialization.
Stabilized--hash--interval 250/PROC/SCSI/SCSI
echo "Loading Ata_piix module"
Modprobe-q Ata_piix
echo waiting for driver initialization.
Stabilized--hash--interval 250/PROC/SCSI/SCSI
echo "Loading dm-mod module"
Modprobe-q Dm-mod
echo "Loading dm-mirror module"
Modprobe-q Dm-mirror
echo "Loading Dm-zero module"
Modprobe-q Dm-zero
echo "Loading dm-snapshot module"
Modprobe-q Dm-snapshot
echo Making Device-mapper control node
Mkdmnod
Modprobe Scsi_wait_scan
Rmmod Scsi_wait_scan
Mkblkdevs
Echo Scanning logical volumes
LVM Vgscan--ignorelockingfailure
echo Activating logical Volumes
LVM Vgchange-ay--ignorelockingfailure VolGroup00
Resume/dev/volgroup00/logvol01
echo Creating root device.
Mkrootdev-t Ext3-o defaults,ro/dev/volgroup00/logvol00
echo Mounting root filesystem.
Mount/sysroot
Echo Setting up the other filesystems.
Setuproot
Loadpolicy
echo Switching to new root and running init.
Switchroot
Echo booting has failed.
Sleep-1

First, it uses Nash, not a common shell like bash or csh. Nash was designed specifically for Init because of its small size.
PC INITRD but only a transition, so after loading the hard drive, ext3 and so on, you can't wait to reset the root file system
First Mkrootdev Specifies the final root directory, which is the same as the kernel boot parameters of grub. Then mount/sysroot the final root directory to/sysroot, Setuproot begins to transfer the/proc/dev/sys in INITRD to/sysroot,
Switchroot will begin converting/sysroot to the final root file system, and after completing the INITRD in RAM everything before emptying.
(If there is a/INITRD directory, the INITRD will be mounted to the directory)

Well, after half a day, I can finally explain the initial doubts.
INITRD, or INITRAMFS, whether in PC or embedded, are optional, divided into 3 kinds of situations
1 Don't initrd at all
2 Initrd as the ultimate root file system
3 INITRD as a transition, by INITRD init to load the final root file system
(The author of this article Deep_pro http://hi.baidu.com/deep_pro/reproduced please indicate the source)

Situation 1, such as embedded Linux static contains NAND flash drive and JFFS2 driver, specify kernel boot parameters
Root=/dev/mtdblock2 rootfs=jffs2 RW console=ttysac0,115200 INIT=/LINUXRC
(using BusyBox as the root file system)

Situation 2, the root file system into a RAMDisk mirror, using Ubbot download to 0x30800000, kernel boot parameters
Root=/dev/ram rw INIT=/LINUXRC initrd=0x30800000,8m console=ttysac0,115200
Note that once the RAMDisk is used as the parameter root of the kernel command line argument, Root=/dev/ram
Then just take initrd as the ultimate root file system.

Situation 3,pc Common, embedded Linux can also be seen such a startup parameter
console=ttysac0,115200 Root=nfs Nfsroot=192.168.1.9:/source/rootfs initrd=0x10800000,0x14af47
Belonged also to the condition 3

For ARM platforms, if Bootloader does not support mounting INITRD, you can use Bootpimage, which connects the kernel and INITRD directly together.

It now appears that initrd as the ultimate root file system will take time to read initrd from Flash into RAM while reading and writing to the file system is not written to Falsh
Do not initrd, the root file system has been in Flash, if the root file system writable, will also be written to the Flash

As for performance comparisons, there's still less experience.