Вы находитесь на странице: 1из 5

Last update: 2011/06/09 15:36

uclinux-dist:images http://docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:images

uClinux-dist Compiled Images


After spending time adding some applications, removing others, and generally staring at configuration screens, you typically run make and sit back for a while. If everything goes smoothly, you end up with a directory called images full of files. But what exactly are all those different files for ? The files generally fall into two classes: kernels and root filesystems. Keep in mind that the conventions used here apply to all Analog Devices board configurations. Your board build system certainly is not required to behave in the exact same way and you are free to do whatever you like. The exact image generation step occurs in the image make target in the vendors///Makefile. For example, the vendors/AnalogDevices/BF537-STAMP/Makefile will behave as described here. To avoid duplication though, that image target may refer to targets defined in vendors/AnalogDevices/vendor.mak. If you want your board to output files the same way, you can certainly re-use that file without copying it. See vendors/Bluetechnix/CM-BF537U/Makefile as an example of re-using Analog Devices settings.

Kernel Images
There are a few variation of kernel images. They can be in the ELF format, or they can be in the bootable U-Boot image format. They may have a root filesystem bundled into it, or they may be just the kernel.

Formats
Kernels that are in the bootable U-Boot format will typically contain Image in their name (such as uImage or vmImage), while kernels that are in the ELF format will typically contain linux in their name (such as linux or vmlinux). Most of the time you should use a kernel that is in the bootable U-Boot format. These tend to be much smaller as the U-Boot format includes compression, and U-Boot can easily boot these. If you really need speed over space savings though, you may wish to boot the ELF format instead. The ELFs are not compressed (and thus are much larger), but the loading process tends to be quicker as things are just a bunch of memory copies. The ELF format tends to need a lot more meta information to describe itself whereas the U-Boot format strips out everything not strictly necessary. With recent releases of U-Boot, booting Linux ELF's will not work properly, so only use the bootable U-Boot format.

Attached
Kernels that have an attached root filesystem will have the filesystem type as a suffix (such as .ext2 or .initramfs). Kernels that do not have an attached root filesystem will not.
http://docs.blackfin.uclinux.org/ Printed on 2013/03/22 00:07

http://docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:images uclinux-dist:images

Last update: 2011/06/09 15:36

Kernels that have a root filesystem attached are generally used when you want to run with a root filesystem completely in RAM. If you wish to run with a root filesystem out of external storage (such as parallel flash or serial flash or ), then you usually use the standalone kernel image. As such, any changes you make to your root filesystem when it is running out of RAM will obviously be lost as soon as the system reboots. A persistent root filesystem is only possible when it is stored externally.

Examples
Some of the common image files that are produced are: Filename vmlinux linux linux.cramfs linux.ext2 linux.initramfs Description The Linux kernel in the ELF format -- no root filesystem A symlink to the default linux.rootfs file The Linux kernel in the ELF format with a CRAMFS filesystem attached The Linux kernel in the ELF format with a EXT2 filesystem attached The Linux kernel in the ELF format with a cpio archive filesystem attached The Linux kernel in the ELF format with a compressed cpio archive filesystem linux.initramfs.gz attached linux.romfs The Linux kernel in the ELF format with a ROMFS filesystem attached vmImage The Linux kernel in the bootable U-Boot format -- no root filesystem uImage A symlink to the default uImage.rootfs file The Linux kernel in the bootable U-Boot format with a CRAMFS filesystem uImage.cramfs attached The Linux kernel in the bootable U-Boot format with a EXT2 filesystem uImage.ext2 attached The Linux kernel in the bootable U-Boot format with a cpio archive filesystem uImage.initramfs attached The Linux kernel in the bootable U-Boot format with a compressed cpio archive uImage.initramfs.gz filesystem attached The Linux kernel in the bootable U-Boot format with a ROMFS filesystem uImage.romfs attached The reason for the .initramfs and the .initramfs.gz variations is that since the bootable U-Boot format already includes compression, the uImage.initramfs.gz means the root filesystem is doubly compressed. So for the bootable U-Boot images, using the uImage.initramfs.gz image is a bad idea and using the uImage.initramfs is a good idea. But for ELFs (which contain no compression themselves), it tends to be the other way as linux.initramfs.gz is a good idea and linux.initramfs is a bad idea.

Filesystem Images
Root filesystems all begin with rootfs and are suffixed with the common filesystem short name. If you wanted, you could mount these on your development systems on loop back devices (will most likely require root access) and poke around the contents that way. These will rarely get used directly on the board. Most of the time you will burn them into flash or some other storage medium, and then attach them when booting Linux.
Printed on 2013/03/22 00:07 http://docs.blackfin.uclinux.org/

Last update: 2011/06/09 15:36

uclinux-dist:images http://docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:images

The contents of the root filesystem are generally taken from two places. Most contents will come directly from the top level romfs directory. Since it contains no device nodes, a file (typically called device_table.txt) will be given to the creation utility so that the /dev directory and associated device nodes are created with proper major/minor numbers as well as permissions inside of the resulting image. The different filesystem types will be generated based on the kernel configuration options you've enabled. So if you enable EXT2 support in your kernel, an ext2 rootfs will be automatically generated. Conversely, if you're wondering why a certain type isn't being generated, it's most likely because you haven't enable support for that in your kernel configuration. For more details of the root filesystem, visit the rootfs page. Filename Description rootfs.cramfs A root filesystem formatted in the CRAMFS format rootfs.ext2 A root filesystem formatted in the EXT2 format rootfs.initramfs A root filesystem formatted in the cpio archive format rootfs.initramfs.gz A root filesystem formatted in the cpio archive format and compressed with gzip rootfs.jffs2 A root filesystem formatted in the JFFS2 format rootfs.romfs A root filesystem formatted in the ROMFS format rootfs.yaffs A root filesystem formatted in the YAFFS format rootfs.yaffs2 A root filesystem formatted in the YAFFS2 format

Misc Files
A System.map is provided for each associated Linux kernel image. It will have a rootfs suffix just like the linux images so that you can easily match the two. Sometimes contents files are provided as an easy way to see what is contained in a particular root filesystem. If that is the case, it will be named the same way as the rootfs except that it will have a .contents suffix.

Creation
The uClinux dist build system by default will generate images based on your kernel settings. It will avoid generating images that make no sense or will not work. For example, if you disable ROMFS support in your kernel, then it makes little sense to create a root filesystem in the ROMFS format as the resulting kernel will not be able to read it.

rootfs storage
There are three methods for storing the root filesystem:
q q q

CONFIG_BLK_DEV_INITRD - initramfs (default in newer releases) CONFIG_MTD_UCLINUX - uClinux MTD (default in older releases) non-volatile storage (i.e. flash, hard drive, etc)
Printed on 2013/03/22 00:07

http://docs.blackfin.uclinux.org/

http://docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:images uclinux-dist:images

Last update: 2011/06/09 15:36

The first option will always be unpacked to a dynamic ramfs mount while the second option requires the memory to be formatted as a specific filesystem. This is useful for testing different storage capabilities. The CONFIG_BLK_DEV_INITRD option can be found here: General setup ---> [*] Initial RAM filesystem and RAM disk (initramfs/initrd) support The CONFIG_MTD_UCLINUX option can be found here: Device Drivers ---> <*> Memory Technology Device (MTD) support ---> RAM/ROM/Flash chip drivers ---> <*> Support for RAM chips in bus mapping Mapping drivers for chip access ---> [*] Generic uClinux RAM/ROM filesystem support

rootfs type
A standalone rootfs image will be generated for each filesystem type you have enabled in the kernel. So if you want a JFFS2 image created automatically for you, enable support for it. Assuming you've picked CONFIG_MTD_UCLINUX for your rootfs storage, then kernels with attached rootfs images will also be generated for each filesystem type you've enabled.

compression
You can control the compression of the kernel itself here (make sure your U-Boot supports the compression type too): General setup ---> Kernel compression mode (X) Gzip ( ) Bzip2 ( ) LZMA

--->

You can control compression of the initramfs (assuming you're using the CONFIG_BLK_DEV_INITRD option): General setup ---> [*] Initial RAM filesystem and [*] Support initial ramdisks [ ] Support initial ramdisks [ ] Support initial ramdisks

RAM disk (initramfs/initrd) support compressed using gzip compressed using bzip2 compressed using LZMA

From: http://docs.blackfin.uclinux.org/ - Analog Devices | Mixed-signal and Digital Signal Processing ICs
Printed on 2013/03/22 00:07 http://docs.blackfin.uclinux.org/

Last update: 2011/06/09 15:36

uclinux-dist:images http://docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:images

Permanent link: http://docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:images Last update: 2011/06/09 15:36

http://docs.blackfin.uclinux.org/

Printed on 2013/03/22 00:07

Вам также может понравиться