| Thomas Gleixner | ec8f24b | 2019-05-19 13:07:45 +0100 | [diff] [blame] | 1 | # SPDX-License-Identifier: GPL-2.0-only |
| Alexey Dobriyan | 2a22783 | 2009-01-22 10:56:54 +0300 | [diff] [blame] | 2 | config CRAMFS |
| Nicolas Pitre | 8d59598 | 2017-10-12 02:16:13 -0400 | [diff] [blame] | 3 | tristate "Compressed ROM file system support (cramfs)" |
| Alexey Dobriyan | 2a22783 | 2009-01-22 10:56:54 +0300 | [diff] [blame] | 4 | select ZLIB_INFLATE |
| 5 | help |
| 6 | Saying Y here includes support for CramFs (Compressed ROM File |
| 7 | System). CramFs is designed to be a simple, small, and compressed |
| 8 | file system for ROM based embedded systems. CramFs is read-only, |
| 9 | limited to 256MB file systems (with 16MB files), and doesn't support |
| 10 | 16/32 bits uid/gid, hard links and timestamps. |
| 11 | |
| Mauro Carvalho Chehab | 0c1bc6b | 2020-04-14 18:48:37 +0200 | [diff] [blame] | 12 | See <file:Documentation/filesystems/cramfs.rst> and |
| Alexey Dobriyan | 2a22783 | 2009-01-22 10:56:54 +0300 | [diff] [blame] | 13 | <file:fs/cramfs/README> for further information. |
| 14 | |
| 15 | To compile this as a module, choose M here: the module will be called |
| 16 | cramfs. Note that the root file system (the one containing the |
| 17 | directory /) cannot be compiled as a module. |
| 18 | |
| Nicolas Pitre | 8d59598 | 2017-10-12 02:16:13 -0400 | [diff] [blame] | 19 | This filesystem is limited in capabilities and performance on |
| 20 | purpose to remain small and low on RAM usage. It is most suitable |
| 21 | for small embedded systems. If you have ample RAM to spare, you may |
| 22 | consider a more capable compressed filesystem such as SquashFS |
| 23 | which is much better in terms of performance and features. |
| Michael Opdenacker | 54886a7 | 2013-11-12 15:08:35 -0800 | [diff] [blame] | 24 | |
| Alexey Dobriyan | 2a22783 | 2009-01-22 10:56:54 +0300 | [diff] [blame] | 25 | If unsure, say N. |
| Nicolas Pitre | 99c18ce | 2017-10-13 16:09:23 -0400 | [diff] [blame] | 26 | |
| 27 | config CRAMFS_BLOCKDEV |
| 28 | bool "Support CramFs image over a regular block device" if EXPERT |
| 29 | depends on CRAMFS && BLOCK |
| 30 | default y |
| 31 | help |
| 32 | This option allows the CramFs driver to load data from a regular |
| 33 | block device such a disk partition or a ramdisk. |
| 34 | |
| 35 | config CRAMFS_MTD |
| 36 | bool "Support CramFs image directly mapped in physical memory" |
| Nicolas Pitre | a8c6db0 | 2018-02-07 22:08:08 -0500 | [diff] [blame] | 37 | depends on CRAMFS && CRAMFS <= MTD |
| Nicolas Pitre | 99c18ce | 2017-10-13 16:09:23 -0400 | [diff] [blame] | 38 | default y if !CRAMFS_BLOCKDEV |
| 39 | help |
| 40 | This option allows the CramFs driver to load data directly from |
| 41 | a linear adressed memory range (usually non volatile memory |
| 42 | like flash) instead of going through the block device layer. |
| 43 | This saves some memory since no intermediate buffering is |
| 44 | necessary. |
| 45 | |
| 46 | The location of the CramFs image is determined by a |
| 47 | MTD device capable of direct memory mapping e.g. from |
| 48 | the 'physmap' map driver or a resulting MTD partition. |
| 49 | For example, this would mount the cramfs image stored in |
| 50 | the MTD partition named "xip_fs" on the /mnt mountpoint: |
| 51 | |
| 52 | mount -t cramfs mtd:xip_fs /mnt |
| 53 | |
| 54 | If unsure, say N. |