Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 8d59598c authored by Nicolas Pitre's avatar Nicolas Pitre Committed by Al Viro
Browse files

cramfs: rehabilitate it



Update documentation, pointer to latest tools, appoint myself as
maintainer. Given it's been unloved for so long, I don't expect anyone
will protest.

Signed-off-by: default avatarNicolas Pitre <nico@linaro.org>
Tested-by: default avatarChris Brandt <chris.brandt@renesas.com>
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
parent eddcd976
Loading
Loading
Loading
Loading
+42 −0
Original line number Diff line number Diff line
@@ -45,6 +45,48 @@ 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
--------------------

+2 −2
Original line number Diff line number Diff line
@@ -3676,8 +3676,8 @@ F: drivers/cpuidle/*
F:	include/linux/cpuidle.h

CRAMFS FILESYSTEM
W:	http://sourceforge.net/projects/cramfs/
S:	Orphan / Obsolete
M:	Nicolas Pitre <nico@linaro.org>
S:	Maintained
F:	Documentation/filesystems/cramfs.txt
F:	fs/cramfs/

+6 −3
Original line number Diff line number Diff line
config CRAMFS
	tristate "Compressed ROM file system support (cramfs) (OBSOLETE)"
	tristate "Compressed ROM file system support (cramfs)"
	select ZLIB_INFLATE
	help
	  Saying Y here includes support for CramFs (Compressed ROM File
@@ -15,8 +15,11 @@ config CRAMFS
	  cramfs.  Note that the root file system (the one containing the
	  directory /) cannot be compiled as a module.

	  This filesystem is obsoleted by SquashFS, which is much better
	  in terms of performance and features.
	  This filesystem is limited in capabilities and performance on
	  purpose to remain small and low on RAM usage. It is most suitable
	  for small embedded systems. If you have ample RAM to spare, you may
	  consider a more capable compressed filesystem such as SquashFS
	  which is much better in terms of performance and features.

	  If unsure, say N.