124 lines
4.6 KiB
ReStructuredText
124 lines
4.6 KiB
ReStructuredText
|
.. 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.
|