linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: Michal Suchanek <hramrach@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	"Rafa?? Mi??ecki" <zajec5@gmail.com>,
	Alison Chaiken <alison_chaiken@mentor.com>,
	Ben Hutchings <ben@decadent.org.uk>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	"Bean Huo (beanhuo)" <beanhuo@micron.com>,
	"grmoore@altera.com" <grmoore@altera.com>,
	linux-mtd@lists.infradead.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] MTD: spi-nor: add flag to not use sector erase.
Date: Mon, 4 May 2015 15:35:29 +0200	[thread overview]
Message-ID: <201505041535.29878.marex@denx.de> (raw)
In-Reply-To: <CAOMqctTL3Kg8M-wqb935+awpPCFKHHUuAUr7fe-B52nqcD+-=g@mail.gmail.com>

On Monday, May 04, 2015 at 03:18:56 PM, Michal Suchanek wrote:
> On 4 May 2015 at 14:12, Marek Vasut <marex@denx.de> wrote:
> > On Monday, May 04, 2015 at 01:11:03 PM, Michal Suchanek wrote:
> >> Hello,
> > 
> > Hi!
> > 
> >> On 1 May 2015 at 16:20, Marek Vasut <marex@denx.de> wrote:
> >> > On Friday, May 01, 2015 at 09:05:15 AM, Michal Suchanek wrote:
> >> >> On 1 May 2015 at 01:13, Marek Vasut <marex@denx.de> wrote:
> >> >> I can determine it for this particular chip. However, when the vendor
> >> >> datasheet says the block is 64/32K it might mean that chips with this
> >> >> ID can have either block size.
> >> > 
> >> > http://www.chingistek.com/img/Product_Files/Pm25LD010020datasheet%20v0
> >> > 4.p df page 21:
> >> > 
> >> > SECTOR_ER (20h) erases 4kByte sector.
> >> > BLOCK_ER (d8h) erases 64kByte sector.
> >> > 
> >> > http://www.gigadevice.com/product/download/366.html?locale=en_US
> >> > page 27-28:
> >> > 
> >> > Sector Erase (SE) (20h) erases 4kByte sector
> >> > 64KB Block Erase (BE) (d8h) erases 64kByte sector
> >> 
> >> It's pretty much the same as the datasheet I used
> >> http://www.elm-tech.com/en/products/spi-flash-memory/gd25q41/gd25q41.pdf
> >> 
> >> It mentions both
> >> 32KB Block Erase (BE) (52H)
> >> and
> >> 64KB Block Erase (BE) (D8H)
> > 
> > The SPI NOR framework will use 0xbe opcode, no problem.
> > 
> >> So the chip probably tries its best to be compatible with any command
> >> set and this last patch is not needed. The memory organization table
> >> on page 7 is not all that reassuring, though.
> > 
> > Which exact part do you refer to please ?
> 
> Start of page 7 where it says sector size 32/64K in either datasheet.
> 
> It can refer to both BE opcode variants being supported but it's quite
> unclear.

My guess here would be that the internal organisation of the SPI NOR is
in 4k blocks, which is no surprise really. My understanding is that opcode
0x52 erases 8x4k sector (ie. 32k of data) while 0xd8 erases 16x4k sector
(ie. 64k of data). I don't see any problem here -- there are two different 
opcodes which do two different things and their behavior matches the one on 
various other SPI NORs.

> Write protection seems to be calculated in 4k sectors and not blocks
> so the block size does not seem very relevant.

See above. Does it make sense now please ?

Best regards,
Marek Vasut

  reply	other threads:[~2015-05-04 13:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1430430153.git.hramrach@gmail.com>
     [not found] ` <35add8df33b17e2354d9496eba8597d9d8488f30.1430430153.git.hramrach@gmail.com>
2015-04-30 23:13   ` [PATCH 3/3] MTD: spi-nor: add flag to not use sector erase Marek Vasut
2015-05-01  7:05     ` Michal Suchanek
2015-05-01 10:50       ` Jonas Gorski
2015-05-01 14:20       ` Marek Vasut
2015-05-04 11:11         ` Michal Suchanek
2015-05-04 12:12           ` Marek Vasut
2015-05-04 13:18             ` Michal Suchanek
2015-05-04 13:35               ` Marek Vasut [this message]
2015-05-04 13:39                 ` Michal Suchanek
2015-05-04 14:11                   ` Marek Vasut
2015-05-01 21:56   ` Rafał Miłecki
     [not found] ` <02f7510acb9b6dbb3a5a6cd5bb287762eb4d22c1.1430430153.git.hramrach@gmail.com>
2015-04-30 23:09   ` [PATCH 1/3] MTD: m25p80: fix write return value Marek Vasut
2015-05-20 23:45   ` Brian Norris
2015-05-21  8:33     ` Michal Suchanek

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=201505041535.29878.marex@denx.de \
    --to=marex@denx.de \
    --cc=alison_chaiken@mentor.com \
    --cc=beanhuo@micron.com \
    --cc=ben@decadent.org.uk \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=geert+renesas@glider.be \
    --cc=grmoore@altera.com \
    --cc=hramrach@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=zajec5@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).