1. 05 12月, 2008 2 次提交
  2. 06 11月, 2008 1 次提交
  3. 24 7月, 2008 5 次提交
  4. 03 2月, 2008 1 次提交
  5. 25 1月, 2008 2 次提交
    • A
      UBI: fix warnings · c18a8418
      Artem Bityutskiy 提交于
      Old gcc complains:
      
      CC      drivers/mtd/ubi/wl.o
      drivers/mtd/ubi/wl.c: In function 'wear_leveling_worker':
      drivers/mtd/ubi/wl.c:746: warning: 'pe' may be used uninitialized in this function
      CC      drivers/mtd/ubi/scan.o
      drivers/mtd/ubi/scan.c: In function 'ubi_scan':
      drivers/mtd/ubi/scan.c:772: warning: 'ec' may be used uninitialized in this function
      drivers/mtd/ubi/scan.c:772: note: 'ec' was declared here
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      c18a8418
    • A
      UBI: add auto-resize feature · 4ccf8cff
      Artem Bityutskiy 提交于
      The problem: NAND flashes have different amount of initial bad physical
      eraseblocks (marked as bad by the manufacturer). For example, for 256MiB
      Samsung OneNAND flash there might be from 0 to 40 bad initial eraseblocks,
      which is about 2%. When UBI is used as the base system, one needs to know
      the exact amount of good physical eraseblocks, because this number is
      needed to create the UBI image which is put to the devices during
      production. But this number is not know, which forces us to use the
      minimum number of good physical eraseblocks. And UBI additionally
      reserves some percentage of physical eraseblocks for bad block handling
      (default is 1%), so we have 1-3% of PEBs reserved at the end, depending
      on the amount of initial bad PEBs. But it is desired to always have
      1% (or more, depending on the configuration).
      
      Solution: this patch adds an "auto-resize" flag to the volume table.
      The volume which has the "auto-resize" flag will automatically be re-sized
      (enlarged) on the first UBI initialization. UBI clears the flag when
      the volume is re-sized. Only one volume may have the "auto-resize" flag.
      
      So, the production UBI image may have one volume with "auto-resize"
      flag set, and its size is automatically adjusted on the first boot
      of the device.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      4ccf8cff
  6. 27 12月, 2007 7 次提交
    • A
      UBI: prepare attach and detach functions · cdfa788a
      Artem Bityutskiy 提交于
      Prepare the attach and detach functions to by used outside of
      module initialization:
      
      * detach function checks reference count before detaching
      * it kills the background thread as well
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      cdfa788a
    • A
      UBI: add UBI devices reference counting · e73f4459
      Artem Bityutskiy 提交于
      This is one more step on the way to "removable" UBI devices. It
      adds reference counting for UBI devices. Every time a volume on
      this device is opened - the device's refcount is increased. It
      is also increased if someone is reading any sysfs file of this
      UBI device or of one of its volumes.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      e73f4459
    • A
      UBI: fix comment · 16f557ec
      Artem Bityutskiy 提交于
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      16f557ec
    • A
      UBI: fix ubi_wl_flush · 593dd33c
      Artem Bityutskiy 提交于
      The flush function should finish all the pending jobs. But if
      somebody else is doing a work, this function should wait and let
      it finish.
      
      This patche uses rw semaphore for synchronization purpose - it
      just looks quite convinient.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      593dd33c
    • A
      UBI: bugfix: protect from volume removal · 43f9b25a
      Artem Bityutskiy 提交于
      When the WL worker is moving an LEB, the volume might go away
      occasionally. UBI does not handle these situations correctly.
      
      This patch introduces a new mutex which serializes wear-levelling
      worker and the the 'ubi_wl_put_peb()' function. Now, if one puts
      an LEB, and its PEB is being moved, it will wait on the mutex.
      And because we unmap all LEBs when removing volumes, this will make
      the volume remove function to wait while the LEB movement
      finishes.
      
      Below is an example of an oops which should be fixed by this patch:
      
      Pid: 9167, comm: io_paral Not tainted (2.6.24-rc5-ubi-2.6.git #2)
      EIP: 0060:[<f884a379>] EFLAGS: 00010246 CPU: 0
      EIP is at prot_tree_del+0x2a/0x63 [ubi]
      EAX: f39a90e0 EBX: 00000000 ECX: 00000000 EDX: 00000134
      ESI: f39a90e0 EDI: f39a90e0 EBP: f2d55ddc ESP: f2d55dd4
       DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      Process io_paral (pid: 9167, ti=f2d54000 task=f72a8030 task.ti=f2d54000)
      Stack: f39a95f8 ef6aae50 f2d55e08 f884a511 f88538e1 f884ecea 00000134 00000000
             f39a9604 f39a95f0 efea8280 00000000 f39a90e0 f2d55e40 f8847261 f8850c3c
             f884eaad 00000001 000000b9 00000134 00000172 000000b9 00000134 00000001
      Call Trace:
       [<c0105227>] show_trace_log_lvl+0x1a/0x30
       [<c01052e2>] show_stack_log_lvl+0xa5/0xca
       [<c01053d6>] show_registers+0xcf/0x21b
       [<c0105648>] die+0x126/0x224
       [<c0119a62>] do_page_fault+0x27f/0x60d
       [<c037dd62>] error_code+0x72/0x78
       [<f884a511>] ubi_wl_put_peb+0xf0/0x191 [ubi]
       [<f8847261>] ubi_eba_unmap_leb+0xaf/0xcc [ubi]
       [<f8843c21>] ubi_remove_volume+0x102/0x1e8 [ubi]
       [<f8846077>] ubi_cdev_ioctl+0x22a/0x383 [ubi]
       [<c017d768>] do_ioctl+0x68/0x71
       [<c017d7c6>] vfs_ioctl+0x55/0x271
       [<c017da15>] sys_ioctl+0x33/0x52
       [<c0104152>] sysenter_past_esp+0x5f/0xa5
       =======================
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      43f9b25a
    • A
      UBI: improve comment · d2c46855
      Artem Bityutskiy 提交于
      Explain better the purpose of thie 'move_to_put' stuff.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      d2c46855
    • A
      UBI: create ubi_wl_entry slab on initialization · 06b68ba1
      Artem Bityutskiy 提交于
      Similarly to ltree_entry_slab, it makes more sense to create
      and destroy ubi_wl_entry slab on module initialization/exit.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      06b68ba1
  7. 20 10月, 2007 1 次提交
  8. 14 10月, 2007 4 次提交
  9. 20 7月, 2007 1 次提交
    • P
      mm: Remove slab destructors from kmem_cache_create(). · 20c2df83
      Paul Mundt 提交于
      Slab destructors were no longer supported after Christoph's
      c59def9f change. They've been
      BUGs for both slab and slub, and slob never supported them
      either.
      
      This rips out support for the dtor pointer from kmem_cache_create()
      completely and fixes up every single callsite in the kernel (there were
      about 224, not including the slab allocator definitions themselves,
      or the documentation references).
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      20c2df83
  10. 18 7月, 2007 3 次提交
  11. 27 4月, 2007 1 次提交
    • A
      UBI: Unsorted Block Images · 801c135c
      Artem B. Bityutskiy 提交于
      UBI (Latin: "where?") manages multiple logical volumes on a single
      flash device, specifically supporting NAND flash devices. UBI provides
      a flexible partitioning concept which still allows for wear-levelling
      across the whole flash device.
      
      In a sense, UBI may be compared to the Logical Volume Manager
      (LVM). Whereas LVM maps logical sector numbers to physical HDD sector
      numbers, UBI maps logical eraseblocks to physical eraseblocks.
      
      More information may be found at
      http://www.linux-mtd.infradead.org/doc/ubi.html
      
      Partitioning/Re-partitioning
      
        An UBI volume occupies a certain number of erase blocks. This is
        limited by a configured maximum volume size, which could also be
        viewed as the partition size. Each individual UBI volume's size can
        be changed independently of the other UBI volumes, provided that the
        sum of all volume sizes doesn't exceed a certain limit.
      
        UBI supports dynamic volumes and static volumes. Static volumes are
        read-only and their contents are protected by CRC check sums.
      
      Bad eraseblocks handling
      
        UBI transparently handles bad eraseblocks. When a physical
        eraseblock becomes bad, it is substituted by a good physical
        eraseblock, and the user does not even notice this.
      
      Scrubbing
      
        On a NAND flash bit flips can occur on any write operation,
        sometimes also on read. If bit flips persist on the device, at first
        they can still be corrected by ECC, but once they accumulate,
        correction will become impossible. Thus it is best to actively scrub
        the affected eraseblock, by first copying it to a free eraseblock
        and then erasing the original. The UBI layer performs this type of
        scrubbing under the covers, transparently to the UBI volume users.
      
      Erase Counts
      
        UBI maintains an erase count header per eraseblock. This frees
        higher-level layers (like file systems) from doing this and allows
        for centralized erase count management instead. The erase counts are
        used by the wear-levelling algorithm in the UBI layer. The algorithm
        itself is exchangeable.
      
      Booting from NAND
      
        For booting directly from NAND flash the hardware must at least be
        capable of fetching and executing a small portion of the NAND
        flash. Some NAND flash controllers have this kind of support. They
        usually limit the window to a few kilobytes in erase block 0. This
        "initial program loader" (IPL) must then contain sufficient logic to
        load and execute the next boot phase.
      
        Due to bad eraseblocks, which may be randomly scattered over the
        flash device, it is problematic to store the "secondary program
        loader" (SPL) statically. Also, due to bit-flips it may become
        corrupted over time. UBI allows to solve this problem gracefully by
        storing the SPL in a small static UBI volume.
      
      UBI volumes vs. static partitions
      
        UBI volumes are still very similar to static MTD partitions:
      
          * both consist of eraseblocks (logical eraseblocks in case of UBI
            volumes, and physical eraseblocks in case of static partitions;
          * both support three basic operations - read, write, erase.
      
        But UBI volumes have the following advantages over traditional
        static MTD partitions:
      
          * there are no eraseblock wear-leveling constraints in case of UBI
            volumes, so the user should not care about this;
          * there are no bit-flips and bad eraseblocks in case of UBI volumes.
      
        So, UBI volumes may be considered as flash devices with relaxed
        restrictions.
      
      Where can it be found?
      
        Documentation, kernel code and applications can be found in the MTD
        gits.
      
      What are the applications for?
      
        The applications help to create binary flash images for two purposes: pfi
        files (partial flash images) for in-system update of UBI volumes, and plain
        binary images, with or without OOB data in case of NAND, for a manufacturing
        step. Furthermore some tools are/and will be created that allow flash content
        analysis after a system has crashed..
      
      Who did UBI?
      
        The original ideas, where UBI is based on, were developed by Andreas
        Arnez, Frank Haverkamp and Thomas Gleixner. Josh W. Boyer and some others
        were involved too. The implementation of the kernel layer was done by Artem
        B. Bityutskiy. The user-space applications and tools were written by Oliver
        Lohmann with contributions from Frank Haverkamp, Andreas Arnez, and Artem.
        Joern Engel contributed a patch which modifies JFFS2 so that it can be run on
        a UBI volume. Thomas Gleixner did modifications to the NAND layer. Alexander
        Schmidt made some testing work as well as core functionality improvements.
      Signed-off-by: NArtem B. Bityutskiy <dedekind@linutronix.de>
      Signed-off-by: NFrank Haverkamp <haver@vnet.ibm.com>
      801c135c