123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123 |
- .. SPDX-License-Identifier: GPL-2.0
- ===========================================
- Cramfs - cram a filesystem onto a small ROM
- ===========================================
- cramfs is designed to be simple and small, and to compress things well.
- It uses the zlib routines to compress a file one page at a time, and
- allows random page access. The meta-data is not compressed, but is
- expressed in a very terse representation to make it use much less
- diskspace than traditional filesystems.
- You can't write to a cramfs filesystem (making it compressible and
- compact also makes it _very_ hard to update on-the-fly), so you have to
- create the disk image with the "mkcramfs" utility.
- Usage Notes
- -----------
- File sizes are limited to less than 16MB.
- Maximum filesystem size is a little over 256MB. (The last file on the
- filesystem is allowed to extend past 256MB.)
- Only the low 8 bits of gid are stored. The current version of
- mkcramfs simply truncates to 8 bits, which is a potential security
- issue.
- Hard links are supported, but hard linked files
- will still have a link count of 1 in the cramfs image.
- Cramfs directories have no ``.`` or ``..`` entries. Directories (like
- every other file on cramfs) always have a link count of 1. (There's
- no need to use -noleaf in ``find``, btw.)
- No timestamps are stored in a cramfs, so these default to the epoch
- (1970 GMT). Recently-accessed files may have updated timestamps, but
- the update lasts only as long as the inode is cached in memory, after
- which the timestamp reverts to 1970, i.e. moves backwards in time.
- Currently, cramfs must be written and read with architectures of the
- same endianness, and can be read only by kernels with PAGE_SIZE
- == 4096. At least the latter of these is a bug, but it hasn't been
- decided what the best fix is. For the moment if you have larger pages
- you can just change the #define in mkcramfs.c, so long as you don't
- mind the filesystem becoming unreadable to future kernels.
- Memory Mapped cramfs image
- --------------------------
- The CRAMFS_MTD Kconfig option adds support for loading data directly from
- a physical linear memory range (usually non volatile memory like Flash)
- instead of going through the block device layer. This saves some memory
- since no intermediate buffering is necessary to hold the data before
- decompressing.
- And when data blocks are kept uncompressed and properly aligned, they will
- automatically be mapped directly into user space whenever possible providing
- eXecute-In-Place (XIP) from ROM of read-only segments. Data segments mapped
- read-write (hence they have to be copied to RAM) may still be compressed in
- the cramfs image in the same file along with non compressed read-only
- segments. Both MMU and no-MMU systems are supported. This is particularly
- handy for tiny embedded systems with very tight memory constraints.
- The location of the cramfs image in memory is system dependent. You must
- know the proper physical address where the cramfs image is located and
- configure an MTD device for it. Also, that MTD device must be supported
- by a map driver that implements the "point" method. Examples of such
- MTD drivers are cfi_cmdset_0001 (Intel/Sharp CFI flash) or physmap
- (Flash device in physical memory map). MTD partitions based on such devices
- are fine too. Then that device should be specified with the "mtd:" prefix
- as the mount device argument. For example, to mount the MTD device named
- "fs_partition" on the /mnt directory::
- $ mount -t cramfs mtd:fs_partition /mnt
- To boot a kernel with this as root filesystem, suffice to specify
- something like "root=mtd:fs_partition" on the kernel command line.
- Tools
- -----
- A version of mkcramfs that can take advantage of the latest capabilities
- described above can be found here:
- https://github.com/npitre/cramfs-tools
- For /usr/share/magic
- --------------------
- ===== ======================= =======================
- 0 ulelong 0x28cd3d45 Linux cramfs offset 0
- >4 ulelong x size %d
- >8 ulelong x flags 0x%x
- >12 ulelong x future 0x%x
- >16 string >\0 signature "%.16s"
- >32 ulelong x fsid.crc 0x%x
- >36 ulelong x fsid.edition %d
- >40 ulelong x fsid.blocks %d
- >44 ulelong x fsid.files %d
- >48 string >\0 name "%.16s"
- 512 ulelong 0x28cd3d45 Linux cramfs offset 512
- >516 ulelong x size %d
- >520 ulelong x flags 0x%x
- >524 ulelong x future 0x%x
- >528 string >\0 signature "%.16s"
- >544 ulelong x fsid.crc 0x%x
- >548 ulelong x fsid.edition %d
- >552 ulelong x fsid.blocks %d
- >556 ulelong x fsid.files %d
- >560 string >\0 name "%.16s"
- ===== ======================= =======================
- Hacker Notes
- ------------
- See fs/cramfs/README for filesystem layout and implementation notes.
|