public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Amul Kumar Saha <amul.saha@samsung.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
	kyungmin.park@samsung.com, linux-mtd@lists.infradead.org
Subject: Re: [PATCH] [OneNAND] OTP support re-implementation 1/1
Date: Fri, 28 Aug 2009 16:38:56 +0300	[thread overview]
Message-ID: <1251466736.3514.10.camel@localhost> (raw)
In-Reply-To: <6098B9D32DCD48C387EF96034FFFC55D@sisodomain.com>

On Thu, 2009-08-27 at 12:07 +0530, Amul Kumar Saha wrote:
> >> 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
> >
> > -ENOPARSE
> >
> > Large patches like this normally require good explanations of what is
> > done, why it is done, which problem it solves, how it is done, etc.
> >
> 
> 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 valid block.
> 
> Why it is done? (Impact)
> 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 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 Block 

Could you insert the description to the patch and re-send it, please?

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

  reply	other threads:[~2009-08-28 13:38 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-17 10:43 [PATCH] [OneNAND] OTP support re-implementation 1/1 Amul Kumar Saha
2009-08-26  5:41 ` Amul Kumar Saha
2009-08-26  5:58   ` Artem Bityutskiy
2009-08-27  6:37     ` Amul Kumar Saha
2009-08-28 13:38       ` Artem Bityutskiy [this message]
2009-08-31  9:19         ` Amul Kumar Saha
2009-08-31  9:34           ` Kyungmin Park
2009-09-02  5:55             ` Amul Kumar Saha
2009-09-02  5:59             ` Amul Kumar Saha
2009-09-02  6:10               ` Artem Bityutskiy
2009-09-03  5:51                 ` Amul Kumar Saha
2009-09-03  6:10                   ` Artem Bityutskiy
2009-09-03 10:37                     ` Amul Kumar Saha
2009-09-03 11:19                       ` Artem Bityutskiy
2009-09-07  9:45                         ` Amul Kumar Saha
2009-09-07  9:57                           ` Kyungmin Park
2009-09-16  3:33                             ` Amul Kumar Saha
2009-09-16  6:40                               ` Artem Bityutskiy
2009-09-28  9:38                           ` Artem Bityutskiy
2009-10-01  6:48                             ` Amul Kumar Saha
2009-10-12  4:42                             ` Amul Kumar Saha
  -- strict thread matches above, loose matches on Subject: below --
2009-10-12  6:01 Amul Kumar Saha
2009-10-20  8:56 ` Artem Bityutskiy
2009-10-20 14:13   ` Adrian Hunter
2009-10-21 11:20     ` Amul Kumar Saha
2009-10-23  6:11       ` Artem Bityutskiy
2009-10-21 11:30     ` Amul Kumar Saha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1251466736.3514.10.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=amul.saha@samsung.com \
    --cc=dwmw2@infradead.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox