sysfs-class-mtd 6.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177
  1. What: /sys/class/mtd/
  2. Date: April 2009
  3. KernelVersion: 2.6.29
  4. Contact: linux-mtd@lists.infradead.org
  5. Description:
  6. The mtd/ class subdirectory belongs to the MTD subsystem
  7. (MTD core).
  8. What: /sys/class/mtd/mtdX/
  9. Date: April 2009
  10. KernelVersion: 2.6.29
  11. Contact: linux-mtd@lists.infradead.org
  12. Description:
  13. The /sys/class/mtd/mtd{0,1,2,3,...} directories correspond
  14. to each /dev/mtdX character device. These may represent
  15. physical/simulated flash devices, partitions on a flash
  16. device, or concatenated flash devices. They exist regardless
  17. of whether CONFIG_MTD_CHAR is actually enabled.
  18. What: /sys/class/mtd/mtdXro/
  19. Date: April 2009
  20. KernelVersion: 2.6.29
  21. Contact: linux-mtd@lists.infradead.org
  22. Description:
  23. These directories provide the corresponding read-only device
  24. nodes for /sys/class/mtd/mtdX/ . They are only created
  25. (for the benefit of udev) if CONFIG_MTD_CHAR is enabled.
  26. What: /sys/class/mtd/mtdX/dev
  27. Date: April 2009
  28. KernelVersion: 2.6.29
  29. Contact: linux-mtd@lists.infradead.org
  30. Description:
  31. Major and minor numbers of the character device corresponding
  32. to this MTD device (in <major>:<minor> format). This is the
  33. read-write device so <minor> will be even.
  34. What: /sys/class/mtd/mtdXro/dev
  35. Date: April 2009
  36. KernelVersion: 2.6.29
  37. Contact: linux-mtd@lists.infradead.org
  38. Description:
  39. Major and minor numbers of the character device corresponding
  40. to the read-only variant of thie MTD device (in
  41. <major>:<minor> format). In this case <minor> will be odd.
  42. What: /sys/class/mtd/mtdX/erasesize
  43. Date: April 2009
  44. KernelVersion: 2.6.29
  45. Contact: linux-mtd@lists.infradead.org
  46. Description:
  47. "Major" erase size for the device. If numeraseregions is
  48. zero, this is the eraseblock size for the entire device.
  49. Otherwise, the MEMGETREGIONCOUNT/MEMGETREGIONINFO ioctls
  50. can be used to determine the actual eraseblock layout.
  51. What: /sys/class/mtd/mtdX/flags
  52. Date: April 2009
  53. KernelVersion: 2.6.29
  54. Contact: linux-mtd@lists.infradead.org
  55. Description:
  56. A hexadecimal value representing the device flags, ORed
  57. together:
  58. 0x0400: MTD_WRITEABLE - device is writable
  59. 0x0800: MTD_BIT_WRITEABLE - single bits can be flipped
  60. 0x1000: MTD_NO_ERASE - no erase necessary
  61. 0x2000: MTD_POWERUP_LOCK - always locked after reset
  62. What: /sys/class/mtd/mtdX/name
  63. Date: April 2009
  64. KernelVersion: 2.6.29
  65. Contact: linux-mtd@lists.infradead.org
  66. Description:
  67. A human-readable ASCII name for the device or partition.
  68. This will match the name in /proc/mtd .
  69. What: /sys/class/mtd/mtdX/numeraseregions
  70. Date: April 2009
  71. KernelVersion: 2.6.29
  72. Contact: linux-mtd@lists.infradead.org
  73. Description:
  74. For devices that have variable eraseblock sizes, this
  75. provides the total number of erase regions. Otherwise,
  76. it will read back as zero.
  77. What: /sys/class/mtd/mtdX/oobsize
  78. Date: April 2009
  79. KernelVersion: 2.6.29
  80. Contact: linux-mtd@lists.infradead.org
  81. Description:
  82. Number of OOB bytes per page.
  83. What: /sys/class/mtd/mtdX/size
  84. Date: April 2009
  85. KernelVersion: 2.6.29
  86. Contact: linux-mtd@lists.infradead.org
  87. Description:
  88. Total size of the device/partition, in bytes.
  89. What: /sys/class/mtd/mtdX/type
  90. Date: April 2009
  91. KernelVersion: 2.6.29
  92. Contact: linux-mtd@lists.infradead.org
  93. Description:
  94. One of the following ASCII strings, representing the device
  95. type:
  96. absent, ram, rom, nor, nand, dataflash, ubi, unknown
  97. What: /sys/class/mtd/mtdX/writesize
  98. Date: April 2009
  99. KernelVersion: 2.6.29
  100. Contact: linux-mtd@lists.infradead.org
  101. Description:
  102. Minimal writable flash unit size. This will always be
  103. a positive integer.
  104. In the case of NOR flash it is 1 (even though individual
  105. bits can be cleared).
  106. In the case of NAND flash it is one NAND page (or a
  107. half page, or a quarter page).
  108. In the case of ECC NOR, it is the ECC block size.
  109. What: /sys/class/mtd/mtdX/ecc_strength
  110. Date: April 2012
  111. KernelVersion: 3.4
  112. Contact: linux-mtd@lists.infradead.org
  113. Description:
  114. Maximum number of bit errors that the device is capable of
  115. correcting within each region covering an ecc step. This will
  116. always be a non-negative integer. Note that some devices will
  117. have multiple ecc steps within each writesize region.
  118. In the case of devices lacking any ECC capability, it is 0.
  119. What: /sys/class/mtd/mtdX/bitflip_threshold
  120. Date: April 2012
  121. KernelVersion: 3.4
  122. Contact: linux-mtd@lists.infradead.org
  123. Description:
  124. This allows the user to examine and adjust the criteria by which
  125. mtd returns -EUCLEAN from mtd_read() and mtd_read_oob(). If the
  126. maximum number of bit errors that were corrected on any single
  127. region comprising an ecc step (as reported by the driver) equals
  128. or exceeds this value, -EUCLEAN is returned. Otherwise, absent
  129. an error, 0 is returned. Higher layers (e.g., UBI) use this
  130. return code as an indication that an erase block may be
  131. degrading and should be scrutinized as a candidate for being
  132. marked as bad.
  133. The initial value may be specified by the flash device driver.
  134. If not, then the default value is ecc_strength.
  135. The introduction of this feature brings a subtle change to the
  136. meaning of the -EUCLEAN return code. Previously, it was
  137. interpreted to mean simply "one or more bit errors were
  138. corrected". Its new interpretation can be phrased as "a
  139. dangerously high number of bit errors were corrected on one or
  140. more regions comprising an ecc step". The precise definition of
  141. "dangerously high" can be adjusted by the user with
  142. bitflip_threshold. Users are discouraged from doing this,
  143. however, unless they know what they are doing and have intimate
  144. knowledge of the properties of their device. Broadly speaking,
  145. bitflip_threshold should be low enough to detect genuine erase
  146. block degradation, but high enough to avoid the consequences of
  147. a persistent return value of -EUCLEAN on devices where sticky
  148. bitflips occur. Note that if bitflip_threshold exceeds
  149. ecc_strength, -EUCLEAN is never returned by the read operations.
  150. Conversely, if bitflip_threshold is zero, -EUCLEAN is always
  151. returned, absent a hard error.
  152. This is generally applicable only to NAND flash devices with ECC
  153. capability. It is ignored on devices lacking ECC capability;
  154. i.e., devices for which ecc_strength is zero.