1. 30 11月, 2009 1 次提交
    • A
      mtd: OneNAND OTP support rework · 3cf60253
      Amul Kumar Saha 提交于
      What is OTP in OneNAND?
      The device includes,
      1. one block-sized OTP (One Time Programmable) area and
      2. user-controlled 1st block OTP(Block 0)
      that can be used to increase system security or to provide
      identification capabilities.
      
      What is done?
      In OneNAND, one block of the NAND Array is set aside as an OTP
      memory area, and 1st Block (Block 0) can be used as OTP area.
      This area, available to the user, can be configured and locked
      with secured user information. The OTP block can be read,
      programmed and locked using the same operations as any other NAND
      Flash Array memory block. After issuing an OTP-Lock, OTP block
      cannot be erased. OTP block is fully-guaranteed to be a good
      block.
      
      Why it is done?
      Locking the 1st Block OTP has the effect of a 'Write-protect' to
      guard against accidental re-programming of data stored in the 1st
      block and OTP Block.
      
      Which problem it solves?
      OTP support is provided in the existing implementation of
      OneNAND/Flex-OneNAND driver, but it is not working with OneNAND
      devices. Have observed the following in current OTP OneNAND Implmentation,
      1. DataSheet specific sequence to lock the OTP Area is not followed.
      2. Certain functions are quiet generic to cope with OTP specific activity.
      This patch re-implements OTP support for OneNAND device.
      
      How it is done?
      For all blocks, 8th word is available to the user.
      However, in case of OTP Block, 8th word of sector 0, page 0 is reserved as
      OTP Locking Bit area. Therefore, in case of OTP Block, user usage on this
      area is prohibited. Condition specific values are entered in the 8th word,
      sector0, page 0 of the OTP block during the process of issuing an OTP-Lock.
      The possible conditions are:
      1. Only 1st Block Lock
      2. Only OTP Block Lock
      3. Lock both the 1st Block and the OTP Block
      
      What Other feature additions have been done in this patch?
      This patch adds feature for:
      1. Only 1st Block Lock
      2. Lock both the 1st Block and the OTP Blocks
      
      Re-implemented OTP support for OneNAND
      Added following features to OneNAND
      	1. Lock only 1st Block in OneNAND
      	2. Lock BOTH 1st Block and OTP Block in OneNAND
      
      [comments were slightly tweaked by Artem]
      Signed-off-by: NAmul Kumar Saha <amul.saha@samsung.com>
      Reviewed-by: NAdrian Hunter <adrian.hunter@nokia.com>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      3cf60253
  2. 05 10月, 2009 2 次提交
  3. 04 9月, 2009 1 次提交
  4. 16 6月, 2009 1 次提交
  5. 06 6月, 2009 3 次提交
  6. 23 3月, 2009 1 次提交
  7. 10 12月, 2008 1 次提交
    • A
      [MTD] update internal API to support 64-bit device size · 69423d99
      Adrian Hunter 提交于
      MTD internal API presently uses 32-bit values to represent
      device size.  This patch updates them to 64-bits but leaves
      the external API unchanged.  Extending the external API
      is a separate issue for several reasons.  First, no one
      needs it at the moment.  Secondly, whether the implementation
      is done with IOCTLs, sysfs or both is still debated.  Thirdly
      external API changes require the internal API to be accepted
      first.
      
      Note that although the MTD API will be able to support 64-bit
      device sizes, existing drivers do not and are not required
      to do so, although NAND base has been updated.
      
      In general, changing from 32-bit to 64-bit values cause little
      or no changes to the majority of the code with the following
      exceptions:
          	- printk message formats
          	- division and modulus of 64-bit values
          	- NAND base support
      	- 32-bit local variables used by mtdpart and mtdconcat
      	- naughtily assuming one structure maps to another
      	in MEMERASE ioctl
      Signed-off-by: NAdrian Hunter <ext-adrian.hunter@nokia.com>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      69423d99
  8. 12 8月, 2008 1 次提交
  9. 05 6月, 2008 1 次提交
  10. 23 4月, 2008 2 次提交
  11. 16 2月, 2008 1 次提交
  12. 07 2月, 2008 1 次提交
  13. 29 1月, 2008 7 次提交
  14. 26 11月, 2007 1 次提交
  15. 24 10月, 2007 1 次提交
  16. 14 10月, 2007 3 次提交
  17. 13 10月, 2007 1 次提交
  18. 24 9月, 2007 1 次提交
    • A
      [MTD] [OneNAND] fix numerous races · 49dc08ee
      Artem Bityutskiy 提交于
      This patch make the OneNAND driver much less racy. It fixes
      our "onenand_wait: read timeout!" heisenbugs. The reason of
      these bugs was that the driver did not lock the chip when
      accessing OTP, and it screwed up OneNAND state when the OTP
      was read while JFFS2 was doing FS checking.
      
      This patch also fixes other races I spotted:
      1. BBT was not protected
      2. Access to ecc_stats was not protected
      
      Now the chip is locked when BBT is accessed.
      
      To fix all of these I basically split all interface functions
      on 'function()' and 'function_nolock()' parts.
      
      I tested this patch on N800 hardware - it fixes our problems.
      But I tested a little different version because our OneNAND
      codebase is slightly out-of-date. But it should be OK.
      
      This patch also includes the prin fixes I posted before.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      49dc08ee
  19. 06 9月, 2007 1 次提交
  20. 30 8月, 2007 1 次提交
  21. 30 6月, 2007 1 次提交
    • K
      [MTD] [OneNAND] 2X program support · ee9745fc
      Kyungmin Park 提交于
      The 2X Program is an extension of Program Operation.
      
      Since the device is equipped with two DataRAMs, and two-plane NAND Flash 
      memory array, these two component enables simultaneous program of 4KiB.
      Plane1 has only even blocks such as block0, block2, block4 while Plane2 
      has only odd blocks such as block1, block3, block5.
      So MTD regards it as 4KiB page size and 256KiB block size
      
      Now the following chips support it. (KFXXX16Q2M)
      Demux: KFG2G16Q2M, KFH4G16Q2M, KFW8G16Q2M,
      Mux:   KFM2G16Q2M, KFN4G16Q2M,
      
      And more recent chips
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      ee9745fc
  22. 09 5月, 2007 1 次提交
  23. 25 4月, 2007 2 次提交
  24. 09 3月, 2007 4 次提交