From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mms2.broadcom.com ([216.31.210.18]) by bombadil.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1ORYeX-0005qi-Pp for linux-mtd@lists.infradead.org; Wed, 23 Jun 2010 22:42:46 +0000 From: "Brian Norris" To: linux-mtd@lists.infradead.org Subject: [PATCH] mtd-www doc, FAQ, general: spelling fixes Date: Wed, 23 Jun 2010 15:42:26 -0700 Message-ID: <1277332946-14580-1-git-send-email-norris@broadcom.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Brian Norris List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Several spelling, word choice, etc. edits throughout Signed-off-by: Brian Norris --- doc/general.xml | 2 +- doc/nand.xml | 60 +++++++++++++++++++++++++++--------------------------- doc/onenand.xml | 18 ++++++++-------- doc/ubi.xml | 14 ++++++------ doc/ubifs.xml | 18 ++++++++-------- faq/general.xml | 6 ++-- faq/jffs2.xml | 18 ++++++++-------- faq/nand.xml | 14 ++++++------ faq/ubi.xml | 48 ++++++++++++++++++++++---------------------- faq/ubifs.xml | 48 ++++++++++++++++++++++---------------------- source.xml | 2 +- 11 files changed, 124 insertions(+), 124 deletions(-) diff --git a/doc/general.xml b/doc/general.xml index e170ace..4e1bfdd 100644 --- a/doc/general.xml +++ b/doc/general.xml @@ -122,7 +122,7 @@ git://git.infradead.org/users/ahunter/nand-tests.git and nasty DMA issues on an OMAP2 board with OneNAND flash, just by running this tests for few hours. -
  • mtd_nandecctest: a simple test that checks correctess of the +
  • mtd_nandecctest: a simple test that checks correctness of the built-in software ECC for 256 and 512-byte buffers; this test is not driver-specific but tests general NAND support code.
    • diff --git a/doc/nand.xml b/doc/nand.xml index 549827b..776f891 100644 --- a/doc/nand.xml +++ b/doc/nand.xml @@ -16,8 +16,8 @@ NAND and NOR Flash is the bus interface. NOR Flash is connected to a address / d bus direct like other memory devices as SRAM etc. NAND Flash uses a multiplexed I/O Interface with some additional control pins. NAND flash is a sequential access device appropriate for mass storage applications, while NOR flash is a random access device - appropriate for code storage application.NOR Flash can be used for code storage and - code execution. Code stored on NAND Flash can't be executed frome there. It must be + appropriate for code storage application. NOR Flash can be used for code storage and + code execution. Code stored on NAND Flash can't be executed from there. It must be loaded into RAM memory and executed from there.

    @@ -72,13 +72,13 @@ smart by software.

    The memory is arranged as an array of pages. A page consists of 256 / 512 Byte data and 8 / 16 Byte spare (out of band) area. Newer chips have 2048 Bytes data and and 64 Bytes spare area sizes. The spare area is used to store ECC (error correction code), -bad block information and filesystem dependend data. +bad block information and filesystem-dependent data. n pages build one block. The read / write access to data is on a per page basis. Erase is done on a per block basis. The commands to read / write / erase the chip is given by writing to the chip with the Command Latch Enable pin high. Address is given by writing with the Address Latch Enable pin high.

    -

    There are only a few lines neccecary to access NAND Flashmemory.

    +

    There are only a few lines necessary to access NAND Flashmemory.

    16 bit buswidth chips are supported.

    @@ -92,7 +92,7 @@ given by writing with the Address Latch Enable pin high.

    Pin(s) Function
    /SE Spare area Enable
    R/B Ready / Busy Output
    -

    As it is neccecary to use the spare area, the /SE (Spare area Enable) pin should +

    As it is necessary to use the spare area, the /SE (Spare area Enable) pin should be tied to GND. /CE, CLE and ALE should be GPIO pins or latched signals. It's possible to use address lines for ALE and CLE, but you have to take care about the timing restrictions of the chip !

    @@ -103,8 +103,8 @@ of your NAND chip. Data hold time after rising edge of /WE is different to data time after rising edge of chipselect lines!

    I/O 0-7(15) are connected to the databus D0-D7(D15). The /WP pin can be used for write protection or connected to VCC to enable writes unconditionally. As NAND flash uses -a command driven programming and erasing, an accidential write or erase is not -likely to happen. The Ready / Busy output is not neccecary for operation, +a command driven programming and erasing, an accidental write or erase is not +likely to happen. The Ready / Busy output is not necessary for operation, but it can be tied to a GPIO or an interrupt line.

    @@ -115,7 +115,7 @@ likely to happen. The Ready / Busy output is not neccecary for operation,

    One major problem for using NAND Flash is, that you cannot write as often as you want to a page. The consecutive writes to a page, before erasing it again, are restricted to 1-3 writes, depending on the manufacturers specifications. This applies -similar to the spare area. This makes it neccecary for the filesystem to handle a writebuffer, +similar to the spare area. This makes it necessary for the filesystem to handle a writebuffer, which contains data, that is less than a page

    At the moment there are only a few filesystems, which support NAND

      @@ -133,7 +133,7 @@ NAND code, is planned. There are some other Open Source projects for NAND filesy support, but there's no other working solution than JFFS2 and YAFFS at the moment of this writing. YAFFS is available from YAFFS-Homepage. YAFFS is faster than JFFS2 and consumes less RAM, JFFS2 provides on the fly file compression and -decompression, which is very helpfull for small FLASHs.

      +decompression, which is very helpful for small FLASHs.

      There is currently no support for the wide spread SmartMedia DOS-FAT filesystem, mainly because it's not a reliable filesystem for industrial usage. It's ok for multimedia applications. The hardware support layer is designed to support an @@ -156,11 +156,11 @@ area is the storage of the cleanmarker

      OffsetContentComment
      0x06Clean marker byte 0This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x85. In the remaining pages this byte is reserved
      0x07Clean marker byte 1This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased this +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x19. In the remaining pages this byte is reserved
      @@ -170,35 +170,35 @@ pages this byte is reserved
      OffsetContentComment
      0x08Clean marker byte 0This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x85. In the remaining pages this byte is reserved
      0x09Clean marker byte 1This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x19. In the remaining pages this byte is reserved
      0x0aClean marker byte 2This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x03. In the remaining pages this byte is reserved
      0x0bClean marker byte 3This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x20. In the remaining pages this byte is reserved
      0x0cClean marker byte 4This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x08. In the remaining pages this byte is reserved
      0x0dClean marker byte 5This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x00. In the remaining pages this byte is reserved
      0x0eClean marker byte 6This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x00. In the remaining pages this byte is reserved
      0x0fClean marker byte 7This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x00. In the remaining pages this byte is reserved
      @@ -208,35 +208,35 @@ pages this byte is reserved
      OffsetContentComment
      0x10Clean marker byte 0This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x85. In the remaining pages this byte is reserved
      0x11Clean marker byte 1This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x19. In the remaining pages this byte is reserved
      0x12Clean marker byte 2This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x03. In the remaining pages this byte is reserved
      0x13Clean marker byte 3This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x20. In the remaining pages this byte is reserved
      0x14Clean marker byte 4This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x08. In the remaining pages this byte is reserved
      0x15Clean marker byte 5This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x00. In the remaining pages this byte is reserved
      0x16Clean marker byte 6This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x00. In the remaining pages this byte is reserved
      0x17Clean marker byte 7This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x00. In the remaining pages this byte is reserved
      @@ -260,9 +260,9 @@ kernel code at the moment. The latest code is available from
    • Hardware specific driver

      • the MTD driver just provides a mount point for JFFS2. The generic NAND -driver provides all functions, which are neccecary to identify, read, write -and erase NAND Flash. The hardware dependend functions are provided by -the hardware driver. They provide mainly the hardware access informations and +driver provides all functions, which are necessary to identify, read, write +and erase NAND Flash. The hardware dependent functions are provided by +the hardware driver. They provide mainly the hardware access information and functions for the generic NAND driver. For YAFFS applies the same.

      diff --git a/doc/onenand.xml b/doc/onenand.xml index c8fdd6e..e3bf69b 100644 --- a/doc/onenand.xml +++ b/doc/onenand.xml @@ -50,35 +50,35 @@ Nand chips with 2048 byte pagesize and 64 byte OOB size
      OffsetContentComment
      0x02Clean marker byte 0This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x85. In the remaining pages this byte is reserved
      0x03Clean marker byte 1This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x19. In the remaining pages this byte is reserved
      0x04Clean marker byte 2This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x03. In the remaining pages this byte is reserved
      0x0eClean marker byte 3This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x20. In the remaining pages this byte is reserved
      0x0fClean marker byte 4This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x08. In the remaining pages this byte is reserved
      0x12Clean marker byte 5This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x00. In the remaining pages this byte is reserved
      0x13Clean marker byte 6This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x00. In the remaining pages this byte is reserved
      0x14Clean marker byte 7This byte indicates that a -block was erased under JFFS2 control. If the page was succesfully erased +block was erased under JFFS2 control. If the page was successfully erased this byte in the first page of a block is programmed to 0x00. In the remaining pages this byte is reserved
      @@ -211,7 +211,7 @@ JFFS2 write-buffering enabled buffer (2048) erasesize (126976)

      Yaffs2

      The yaffs2 can run on OneNAND

      -

      If your yaffs2 dosen't work, please check this patch

      +

      If your yaffs2 doesn't work, please check this patch

      diff --git a/doc/ubi.xml b/doc/ubi.xml index 06d8cbd..9290f4a 100644 --- a/doc/ubi.xml +++ b/doc/ubi.xml @@ -46,7 +46,7 @@
    • More documentation
      • -
    • How to send a bugreport?
      • +
    • How do I send a bug report?
      • @@ -117,7 +117,7 @@ Bit-flips are corrected by ECC checksums, but they may accumulate over time and cause data loss. UBI handles this by moving data from physical eraseblocks which have bit-flips to other physical eraseblocks. This process is called scrubbing. Scrubbing is done transparently in background and is -hidden from upper layes.

      +hidden from upper layers.

      Here is a short list of the main UBI features:

        @@ -343,7 +343,7 @@ table records. Each record contains the following information:

      • CRC-32 checksum for this record.
      -

      Each record descripes one UBI volume and record index in the volume table +

      Each record describes one UBI volume and record index in the volume table array corresponds to the volume ID. I.e, UBI volume 0 is described by record 0 in the volume table, and so on. Count of records in the volume table is limited by the LEB size, but cannot be greater than 128. This means that UBI devices @@ -377,7 +377,7 @@ volumes.

    When attaching the MTD device, UBI makes sure that the 2 volume table copies -are equivalent. If they are not equevalent, which may be caused by an unclean +are equivalent. If they are not equivalent, which may be caused by an unclean reboot, UBI picks the one from LEB0 and copies it to LEB1 of the layout volume (because it is newer). If one of the volume table copies is corrupted, UBI restores it from the other volume table copy.

    @@ -817,7 +817,7 @@ order to build in-RAM EC and EBA tables.

    The drawbacks of this design are poor scalability and relatively high overhead on NAND flashes (e.g., the overhead is 1.5%-3% of flash space in case of a NAND flash with 2KiB NAND page and 128KiB eraseblock). The advantages are -simple binary format and robustness, as the result of symplicity.

    +simple binary format and robustness, as the result of simplicity.

    Nonetheless, it is always possible to create UBI2 which would maintain the tables in separate flash areas. UBI2 would not be compatible with UBI because @@ -1182,7 +1182,7 @@ function (just above the body of the function).

    -

    How to send an UBI bugreport?

    +

    How do I send an UBI bug report?

    Before sending a bug report: