From: Austin Boyle <boyle.austin@gmail.com>
To: unlisted-recipients:; (no To-header on input)
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mtd: m25p80: Flash protection support for STmicro chips
Date: Sun, 9 Mar 2014 02:26:30 +1100 [thread overview]
Message-ID: <20140309022630.690bb2502ba890fdbf6eb6d9@gmail.com> (raw)
In-Reply-To: <20140305083153.GR13420@norris-Latitude-E6410>
Hi all,
I am very sorry I missed this discussion, that was my previous work email address. Thanks for finding me Brian!
> On Thu, Feb 27, 2014 at 03:34:06PM +0100, Gerlando Falauto wrote:
> > >2) While I believe this might work on m25p32, m25p64 and m25p128 (i.e.
> > >flashes with 64 blocks or more), it looks incorrect for smaller chips
> > >(namely our m25p80, with just 16 blocks). There, the 1/64 logic scales
> > >down to 1/16, e.g.
Gerlando, I agree that the logic for calculating the protection bits doesn't work for chips with fewer than 64 sectors. I was only testing the m25p64 at the time.
I don't think there is an issue with some bootloaders not supporting this feature, it is already optional.
It is a good idea to add another flag for flash protection to be explicitly clear which devices support this. (I previously made the assumption that writing to those status bits when unused was harmless, from the datasheets I found they seem to be don't cares.)
The following logic for calculating the block protect bits applies to the majority of the STmicro devices that support protection (m25p10, p20, p40, p80, p16, pe16, p32, p64, p128):
SR_BPs | Protected (upper) | Unprotected (lower)
=====================================================
0 | 0/n | n - 0/n
1 | 1/n | n - 1/n
2 | 2/n | n - 2/n
3 | 3/n | n - 4/n
4 | 4/n | n - 8/n
5 | 5/n | n - 16/n
6 | 6/n | n - 32/n
7 | 7/n | n - 64/n
Where n is number of sectors if less than 64.
Some special cases:
- m25p64 has 128 sectors but only supports protection to 64 sector resolution.
- m25p05 uses SR=1/2 for protect Block Erase, and SR=3 for protect Block Erase, Page Program, Sector Erase.
- m25px32 has an additional bit for locking the lower sections.
A patch with this implementation follows. Let me know what you think. I have a spreadsheet summarising the block protect bits for the STmicro devices I can share if it will help.
Thanks,
Austin.
next prev parent reply other threads:[~2014-03-08 15:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-04 0:02 [PATCH] mtd: m25p80: Flash protection support for STmicro chips Austin Boyle
2013-01-17 10:41 ` Artem Bityutskiy
2013-11-20 20:04 ` Gerlando Falauto
2014-02-27 14:34 ` Gerlando Falauto
2014-03-05 8:10 ` Brian Norris
2014-03-05 8:31 ` Brian Norris
2014-03-08 15:26 ` Austin Boyle [this message]
[not found] ` <CADnxWiqfaaRoaL+B_WQxx38-gpSDmdFQPLN-bs-moGRECXeJxg@mail.gmail.com>
2014-03-10 9:06 ` Gerlando Falauto
2014-03-13 12:57 ` Austin Boyle
2014-03-13 13:46 ` Gerlando Falauto
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=20140309022630.690bb2502ba890fdbf6eb6d9@gmail.com \
--to=boyle.austin@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--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