linux-kernel - Re: [PATCH] Add support for flag status register on Micron chips

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 9 Apr 2014 13:14:49 -0500
From:	Graham Moore <ggrahammoore@...il.com>
To:	Gerhard Sittig <gsi@...x.de>
Cc:	Marek Vasut <marex@...x.de>,
	"grmoore@...era.com" <grmoore@...era.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Brian Norris <computersforpeace@...il.com>,
	Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>,
	Sourav Poddar <sourav.poddar@...com>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Geert Uytterhoeven <geert+renesas@...ux-m68k.org>,
	Jingoo Han <jg1.han@...sung.com>,
	Insop Song <insop.song@...nspeed.com>,
	linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Alan Tull <atull@...era.com>,
	Dinh Nguyen <dinguyen@...era.com>,
	Yves Vandervennet <rocket.yvanderv@...il.com>
Subject: Re: [PATCH] Add support for flag status register on Micron chips

On Wed, Apr 9, 2014 at 6:09 AM, Gerhard Sittig <gsi@...x.de> wrote:
> On Wed, 2014-04-09 at 12:03 +0200, Marek Vasut wrote:
>>
>> On Tuesday, April 08, 2014 at 06:12:49 PM, grmoore@...era.com wrote:
>> > From: Graham Moore <grmoore@...era.com>
>> >
>> > This is a slightly different version of the patch that Insop Song
>> > submitted
>> > (http://marc.info/?i=201403012022.10111.marex%20()%20denx%20!%20de).
>> >
>> > I talked to Insop, and he agreed I should submit this patch as a follow-on
>> > to his.
>> >
>> > This patch uses a flag in the m25p_ids[] array to determine which chips
>> > need to use the FSR (Flag Status Register).
>> >
>> > Rationale for using the FSR:
>> >
>> > The Micron data sheets say we have to do this, at least for the multi-die
>> > 512M and 1G parts (n25q512 and n25q00).  In practice, if we don't check
>> > the FSR for program/erase status, and we rely solely on the status
>> > register (SR), then we get corrupted data in the flash.
[...]
>> > Micron told us (Altera) that for multi-die chips based on the 65nm 256MB
>> > die, we need to check the SR first, then check the FSR, which is why the
>> > wait_for_fsr_ready function does that.  Future chips based on 45 nm 512MB
>> > die will use the FSR only.
>
> This sounds to me similar to polling the NAND's R/B pin until the
> operation has completed, to then fetch the STATUS byte to
> determine the execution's result.  Does this sound plausible?
> For NOR, do you poll for the "busy" condition to deassert, and
> check for success then?

Sounds plausible to me.  We poll the SR until not busy, then poll the
FSR until it's not busy.  Success is when FSR busy is deasserted
within the timeout.

Micron said we have to read the FSR "at least once", so we don't
read it once for every die or anything like that.  I ran a quick
test, and for both the 2-die and 4-die parts, the FSR shows not busy
on the first read after SR not busy.

-Graham
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/