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

uClinux Dist+Compiled+Images

Embed Size (px)

DESCRIPTION

How to compile Uclinux

Citation preview

Last update: 2011/06/09 15:36 uclinux-dist:imageshttp://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 atconfiguration 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 filesfor ?

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. Yourboard build system certainly is not required to behave in the exact same way and you are free to dowhatever you like. The exact image generation step occurs in the image make target in thevendors///Makefile. For example, the vendors/AnalogDevices/BF537-STAMP/Makefilewill behave as described here.

To avoid duplication though, that image target may refer to targets defined invendors/AnalogDevices/vendor.mak. If you want your board to output files the same way, youcan certainly re-use that file without copying it. Seevendors/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 thebootable U-Boot image format. They may have a root filesystem bundled into it, or they may be justthe kernel.

Formats

Kernels that are in the bootable U-Boot format will typically contain Image in their name (such asuImage or vmImage), while kernels that are in the ELF format will typically contain linux in theirname (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 bemuch smaller as the U-Boot format includes compression, and U-Boot can easily boot these. If youreally need speed over space savings though, you may wish to boot the ELF format instead. TheELFs are not compressed (and thus are much larger), but the loading process tends to be quicker asthings 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 bootableU-Boot format.

Attached

Kernels that have an attached root filesystem will have the filesystem type as a suffix (such as .ext2or .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:imagesuclinux-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 rootfilesystem completely in RAM. If you wish to run with a root filesystem out of external storage (suchas parallel flash or serial flash or …), then you usually use the standalone kernel image. As such, anychanges you make to your root filesystem when it is running out of RAM will obviously be lost assoon 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 Descriptionvmlinux The Linux kernel in the ELF format -- no root filesystemlinux A symlink to the “default” linux.rootfs filelinux.cramfs The Linux kernel in the ELF format with a CRAMFS filesystem attachedlinux.ext2 The Linux kernel in the ELF format with a EXT2 filesystem attachedlinux.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 filesystemattached

linux.romfs The Linux kernel in the ELF format with a ROMFS filesystem attachedvmImage The Linux kernel in the bootable U-Boot format -- no root filesystemuImage A symlink to the “default” uImage.rootfs file

uImage.cramfs The Linux kernel in the bootable U-Boot format with a CRAMFS filesystemattached

uImage.ext2 The Linux kernel in the bootable U-Boot format with a EXT2 filesystemattached

uImage.initramfs The Linux kernel in the bootable U-Boot format with a cpio archive filesystemattached

uImage.initramfs.gz The Linux kernel in the bootable U-Boot format with a compressed cpio archivefilesystem attached

uImage.romfs The Linux kernel in the bootable U-Boot format with a ROMFS filesystemattached

The reason for the .initramfs and the .initramfs.gz variations is that since the bootableU-Boot format already includes compression, the uImage.initramfs.gz means the root filesystemis doubly compressed. So for the bootable U-Boot images, using the uImage.initramfs.gz imageis a bad idea and using the uImage.initramfs is a good idea. But for ELFs (which contain nocompression themselves), it tends to be the other way as linux.initramfs.gz is a good idea andlinux.initramfs is a bad idea.

Filesystem Images

Root filesystems all begin with rootfs and are suffixed with the common filesystem short name. Ifyou wanted, you could mount these on your development systems on loop back devices (will mostlikely 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 orsome 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:imageshttp://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 comedirectly from the top level romfs directory. Since it contains no device nodes, a file (typically calleddevice_table.txt) will be given to the creation utility so that the /dev directory and associateddevice nodes are created with proper major/minor numbers as well as permissions inside of theresulting image.

The different filesystem types will be generated based on the kernel configuration options you'veenabled. So if you enable EXT2 support in your kernel, an ext2 rootfs will be automaticallygenerated. Conversely, if you're wondering why a certain type isn't being generated, it's most likelybecause you haven't enable support for that in your kernel configuration.

For more details of the root filesystem, visit the rootfs page.

Filename Descriptionrootfs.cramfs A root filesystem formatted in the CRAMFS formatrootfs.ext2 A root filesystem formatted in the EXT2 formatrootfs.initramfs A root filesystem formatted in the cpio archive formatrootfs.initramfs.gz A root filesystem formatted in the cpio archive format and compressed with gziprootfs.jffs2 A root filesystem formatted in the JFFS2 formatrootfs.romfs A root filesystem formatted in the ROMFS formatrootfs.yaffs A root filesystem formatted in the YAFFS formatrootfs.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 justlike 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 rootfilesystem. 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 willavoid generating images that make no sense or will not work. For example, if you disable ROMFSsupport in your kernel, then it makes little sense to create a root filesystem in the ROMFS format asthe 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…)●

http://docs.blackfin.uclinux.org/ Printed on 2013/03/22 00:07

http://docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:imagesuclinux-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 requiresthe memory to be formatted as a specific filesystem. This is useful for testing different storagecapabilities.

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 withattached 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 thecompression type too):

General setup ---> Kernel compression mode ---> (X) Gzip ( ) Bzip2 ( ) LZMA

You can control compression of the initramfs (assuming you're using theCONFIG_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

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:imageshttp://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