From: Michal Suchanek <hramrach@gmail.com>
To: Marek Vasut <marex@denx.de>
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:39:44 +0200 [thread overview]
Message-ID: <CAOMqctTwrN3onS0EuW1ZB0ZDcw4X+WrKwnFbYizPpwXY8cCLWQ@mail.gmail.com> (raw)
In-Reply-To: <201505041535.29878.marex@denx.de>
On 4 May 2015 at 15:35, Marek Vasut <marex@denx.de> wrote:
> 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:
>> >>
>> >> 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 ?
>
Yes,
makes sense.
Thanks
Michal
next prev parent reply other threads:[~2015-05-04 13:40 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
2015-05-04 13:39 ` Michal Suchanek [this message]
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=CAOMqctTwrN3onS0EuW1ZB0ZDcw4X+WrKwnFbYizPpwXY8cCLWQ@mail.gmail.com \
--to=hramrach@gmail.com \
--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=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marex@denx.de \
--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).