projects / linux.git / blame
| Commit | Line | Data |
|---|---|---|
| 1da177e4 LT |
1 | |
| 2 | Cramfs - cram a filesystem onto a small ROM | |
| 3 | ||
| 4 | cramfs is designed to be simple and small, and to compress things well. | |
| 5 | ||
| 6 | It uses the zlib routines to compress a file one page at a time, and | |
| 7 | allows random page access. The meta-data is not compressed, but is | |
| 8 | expressed in a very terse representation to make it use much less | |
| 9 | diskspace than traditional filesystems. | |
| 10 | ||
| 11 | You can't write to a cramfs filesystem (making it compressible and | |
| 12 | compact also makes it _very_ hard to update on-the-fly), so you have to | |
| 13 | create the disk image with the "mkcramfs" utility. | |
| 14 | ||
| 15 | ||
| 16 | Usage Notes | |
| 17 | ----------- | |
| 18 | ||
| 19 | File sizes are limited to less than 16MB. | |
| 20 | ||
| 21 | Maximum filesystem size is a little over 256MB. (The last file on the | |
| 22 | filesystem is allowed to extend past 256MB.) | |
| 23 | ||
| 24 | Only the low 8 bits of gid are stored. The current version of | |
| 25 | mkcramfs simply truncates to 8 bits, which is a potential security | |
| 26 | issue. | |
| 27 | ||
| 28 | Hard links are supported, but hard linked files | |
| 29 | will still have a link count of 1 in the cramfs image. | |
| 30 | ||
| 31 | Cramfs directories have no `.' or `..' entries. Directories (like | |
| 32 | every other file on cramfs) always have a link count of 1. (There's | |
| 33 | no need to use -noleaf in `find', btw.) | |
| 34 | ||
| 35 | No timestamps are stored in a cramfs, so these default to the epoch | |
| 36 | (1970 GMT). Recently-accessed files may have updated timestamps, but | |
| 37 | the update lasts only as long as the inode is cached in memory, after | |
| 38 | which the timestamp reverts to 1970, i.e. moves backwards in time. | |
| 39 | ||
| 40 | Currently, cramfs must be written and read with architectures of the | |
| ea1754a0 | 41 | same endianness, and can be read only by kernels with PAGE_SIZE |
| 1da177e4 LT |
42 | == 4096. At least the latter of these is a bug, but it hasn't been |
| 43 | decided what the best fix is. For the moment if you have larger pages | |
| 44 | you can just change the #define in mkcramfs.c, so long as you don't | |
| 45 | mind the filesystem becoming unreadable to future kernels. | |
| 46 | ||
| 47 | ||
| 8d59598c NP |
48 | Memory Mapped cramfs image |
| 49 | -------------------------- | |
| 50 | ||
| 51 | The CRAMFS_MTD Kconfig option adds support for loading data directly from | |
| 52 | a physical linear memory range (usually non volatile memory like Flash) | |
| 53 | instead of going through the block device layer. This saves some memory | |
| 54 | since no intermediate buffering is necessary to hold the data before | |
| 55 | decompressing. | |
| 56 | ||
| 57 | And when data blocks are kept uncompressed and properly aligned, they will | |
| 58 | automatically be mapped directly into user space whenever possible providing | |
| 59 | eXecute-In-Place (XIP) from ROM of read-only segments. Data segments mapped | |
| 60 | read-write (hence they have to be copied to RAM) may still be compressed in | |
| 61 | the cramfs image in the same file along with non compressed read-only | |
| 62 | segments. Both MMU and no-MMU systems are supported. This is particularly | |
| 63 | handy for tiny embedded systems with very tight memory constraints. | |
| 64 | ||
| 65 | The location of the cramfs image in memory is system dependent. You must | |
| 66 | know the proper physical address where the cramfs image is located and | |
| 67 | configure an MTD device for it. Also, that MTD device must be supported | |
| 68 | by a map driver that implements the "point" method. Examples of such | |
| 69 | MTD drivers are cfi_cmdset_0001 (Intel/Sharp CFI flash) or physmap | |
| 70 | (Flash device in physical memory map). MTD partitions based on such devices | |
| 71 | are fine too. Then that device should be specified with the "mtd:" prefix | |
| 72 | as the mount device argument. For example, to mount the MTD device named | |
| 73 | "fs_partition" on the /mnt directory: | |
| 74 | ||
| 75 | $ mount -t cramfs mtd:fs_partition /mnt | |
| 76 | ||
| 77 | To boot a kernel with this as root filesystem, suffice to specify | |
| 78 | something like "root=mtd:fs_partition" on the kernel command line. | |
| 79 | ||
| 80 | ||
| 81 | Tools | |
| 82 | ----- | |
| 83 | ||
| 84 | A version of mkcramfs that can take advantage of the latest capabilities | |
| 85 | described above can be found here: | |
| 86 | ||
| 87 | https://github.com/npitre/cramfs-tools | |
| 88 | ||
| 89 | ||
| 1da177e4 LT |
90 | For /usr/share/magic |
| 91 | -------------------- | |
| 92 | ||
| 93 | 0 ulelong 0x28cd3d45 Linux cramfs offset 0 | |
| 94 | >4 ulelong x size %d | |
| 95 | >8 ulelong x flags 0x%x | |
| 96 | >12 ulelong x future 0x%x | |
| 97 | >16 string >\0 signature "%.16s" | |
| 98 | >32 ulelong x fsid.crc 0x%x | |
| 99 | >36 ulelong x fsid.edition %d | |
| 100 | >40 ulelong x fsid.blocks %d | |
| 101 | >44 ulelong x fsid.files %d | |
| 102 | >48 string >\0 name "%.16s" | |
| 103 | 512 ulelong 0x28cd3d45 Linux cramfs offset 512 | |
| 104 | >516 ulelong x size %d | |
| 105 | >520 ulelong x flags 0x%x | |
| 106 | >524 ulelong x future 0x%x | |
| 107 | >528 string >\0 signature "%.16s" | |
| 108 | >544 ulelong x fsid.crc 0x%x | |
| 109 | >548 ulelong x fsid.edition %d | |
| 110 | >552 ulelong x fsid.blocks %d | |
| 111 | >556 ulelong x fsid.files %d | |
| 112 | >560 string >\0 name "%.16s" | |
| 113 | ||
| 114 | ||
| 115 | Hacker Notes | |
| 116 | ------------ | |
| 117 | ||
| 118 | See fs/cramfs/README for filesystem layout and implementation notes. |