world leader in high performance signal processing
Trace: » 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/<company>/<board>/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.

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 Description
vmlinux The Linux kernel in the ELF format -- no root filesystem
linux A symlink to the “default” linux.rootfs file
linux.cramfs The Linux kernel in the ELF format with a CRAMFS filesystem attached
linux.ext2 The Linux kernel in the ELF format with a EXT2 filesystem attached
linux.initramfs The Linux kernel in the ELF format with a cpio archive filesystem attached
linux.initramfs.gz The Linux kernel in the ELF format with a compressed cpio archive filesystem 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
uImage.cramfs The Linux kernel in the bootable U-Boot format with a CRAMFS filesystem attached
uImage.ext2 The Linux kernel in the bootable U-Boot format with a EXT2 filesystem attached
uImage.initramfs The Linux kernel in the bootable U-Boot format with a cpio archive filesystem attached
uImage.initramfs.gz The Linux kernel in the bootable U-Boot format with a compressed cpio archive filesystem attached
uImage.romfs The Linux kernel in the bootable U-Boot format with a ROMFS filesystem 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.

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:

  • 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…)

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 RAM disk (initramfs/initrd) support
  [*]   Support initial ramdisks compressed using gzip
  [ ]   Support initial ramdisks compressed using bzip2
  [ ]   Support initial ramdisks compressed using LZMA