linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: Tudor.Ambarus@microchip.com
Cc: linux-mtd@lists.infradead.org, vigneshr@ti.com, js07.lee@samsung.com
Subject: Re: [PATCH v3 1/5] mtd: spi-nor: Fix gap in SR block protection locking
Date: Mon, 23 Mar 2020 22:14:05 +0100	[thread overview]
Message-ID: <401ca7a54a8d327a0397880db6a9a475@walle.cc> (raw)
In-Reply-To: <4551629.Jkd3TAmcGf@192.168.0.120>

Am 2020-03-23 21:26, schrieb Tudor.Ambarus@microchip.com:
> On Monday, March 23, 2020 9:54:38 PM EET Michael Walle wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know 
>> the
>> content is safe
>> Am 2020-03-23 20:20, schrieb Tudor.Ambarus@microchip.com:
>> > On Monday, March 23, 2020 8:27:13 PM EET Michael Walle wrote:
>> >> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>> >> the
>> >> content is safe
>> >>
>> >> Hi,
>> >>
>> >> Am 2020-03-23 10:24, schrieb Tudor.Ambarus@microchip.com:
>> >> > From: Tudor Ambarus <tudor.ambarus@microchip.com>
>> >> >
>> >> > Fix the gap for the SR block protection, the BP bits were set with
>> >> > a +1 value than actually needed. This patch does not change the
>> >> > behavior of the locking operations, just fixes the protected areas.
>> >>
>> >> So instead of rounding up, it does round down now?
>> >
>> > No. Why do you say that it rounds up? The behavior is not changed, the
>> > patch
>> > merely fix the protected area, which was wrong before. The round down
>> > is
>> > present before this patch.
>> 
>> TBH I don't understand what this patch should do. Could you give an
>> example?
> 
> sure, let me try to be more explicit.
> 
>> 
>> >> > On a 16Mbit flash with 64KByte erase sector, the following changed
>> 
>> >> > for the lock operation:
>> 16MBit is a bad example, because it is broken anyway, isn't it? We use 
>> a
> 
> it's not.

If I'm not mistaken this falls into the same category like the new 4bits 
BP
flashes, because there are more slots free than needed. Ie. the last one
"protect all" is either 110b or 111b and thus don't work with the old
formula. This was actually my reason why there is no new formula for the
4 bits BP flashes; but the current one is not working with flashes 
<32Mbit.
See the old long thread.


> 
>> 32Mbit flash where 2MB are locked and the second 2MB are unlocked. Eg. 
>> a
>> 50/50 split. I haven't seen any issued. Shouldn't it be then 
>> completely
>> locked according this the following example?
> 
> I don't follow.

We've successfully used the "flash_lock 0 0x200" (with 4k sectors) on 
our
boards to lock the first half of our 4MiB flash.

> The table from below was generated for the S25FL116K 16 Mbit flash. 
> BTW, one
> has to disable CONFIG_MTD_SPI_NOR_USE_4K_SECTORS in order to test the 
> locking.
> When you have a 4k sector erase, the locking is simply wrong, but this 
> is
> another topic.

it should work with that too if you convert the number to the smaller 
sectors,
ie multiply by 16; But yeah the cli tool has a broken interface. It 
should
accept both offset and length in bytes; not one one in bytes and one in 
sectors,
where the latter also changes with CONFIG_MTD_SPI_NOR_USE_4K_SECTORS.


>> 
>> >> > Number of blocks | BP2:0 before | BP2:0 now |
>> >> >
>> >> >                1 | 010b         | 001b      |
> 
> - number of blocks is how many blocks you want to lock. One would do 
> for one
> block:
>     flash_lock /dev/mtd 0 1
> i.e. lock a single erase block starting from offset 0.
> 
> - "BP0:2 before" is the result of the operation "flash_lock /dev/mtd 0 
> 1"
> before this patch


Without your patch applied it works like expected:

[    1.914329] spi-nor spi0.0: w25q32dw (4096 Kbytes)
# flash_lock -l /dev/mtd1 0 1
# cat 
/sys/devices/platform/soc/20c0000.spi/spi_master/spi0/spi0.0/status_reg
a4

A4 is 1010_0100, ie BP[2:0] = 001b and TB=1

# flash_lock -u /dev/mtd1 0 64
# flash_lock -l /dev/mtd1 0 32
# cat 
/sys/devices/platform/soc/20c0000.spi/spi_master/spi0/spi0.0/status_reg
b8


With this patch applied:

# flash_lock -u /dev/mtd1 0 64
# cat 
/sys/devices/platform/soc/20c0000.spi/spi_master/spi0/spi0.0/status_reg
00
# flash_lock -l /dev/mtd1 0 1
flash_lock: error!: could not lock device: /dev/mtd1

             error 22 (Invalid argument)
# flash_lock -l /dev/mtd1 0 2
# cat 
/sys/devices/platform/soc/20c0000.spi/spi_master/spi0/spi0.0/status_reg
a4

which is wrong, isn't it?

-michael

> 
> - "BP0:2 now" is the result of the operation "flash_lock /dev/mtd 0 1" 
> using
> this patch
> 
> So before this patch, the lock operation was bad, because it locked 2 
> blocks
> instead of one.
> 
>> >> >                2 | 110b         | 010b      |
> 
> - lock 2 erase blocks starting from offset 0. Results before this 
> patch, and
> after this patch. Continue the logic on the following lines.
> 
> oops there's a typo in column 2, sorry. The value in column 2 should 
> have been
> 011b.
> 
> So before this patch, when one requested to lock 2 block starting from 
> offset
> 0, we would obtain 4 blocks locked, and he should have obtained just 2.
> 
> The scope of this patch is to first fix the locking ops, so that we can
> introduce a more generic formula that gives the same results as before
> introducing it. Without this patch, the new formula will silently fix 
> the bug
> that is described here.
> 
>> >> >                3 | 110b         | 010b      |
> 		^ typo s/110b/011b
> 
> rest of the examples are good.
> 
> Cheers,
> ta
> 
>> >> >                4 | 100b         | 011b      |
>> >> >                5 | 100b         | 011b      |
>> >> >                6 | 100b         | 011b      |
>> >> >                7 | 100b         | 011b      |
>> >> >                8 | 101b         | 100b      |
>> >> >                9 | 101b         | 100b      |
>> >> >
>> >> >              ... | ...          | ...       |
>> >> >
>> >> > For the lock operation, if one requests to lock an area that is not
>> >> > matching the upper boundary of a BP protected area, we round down
>> >> > the total length and lock less than the user requested, in order to
>> >> > not lock more than the user actually requested.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2020-03-23 21:14 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-23  9:24 [PATCH v3 0/5] mtd: spi-nor: Add SR 4bit block protection support Tudor.Ambarus
2020-03-23  9:24 ` [PATCH v3 1/5] mtd: spi-nor: Fix gap in SR block protection locking Tudor.Ambarus
2020-03-23 18:27   ` Michael Walle
2020-03-23 19:20     ` Tudor.Ambarus
2020-03-23 19:54       ` Michael Walle
2020-03-23 20:26         ` Tudor.Ambarus
2020-03-23 21:14           ` Michael Walle [this message]
2020-03-23 21:30             ` Tudor.Ambarus
2020-03-23 21:33               ` Tudor.Ambarus
2020-03-23 22:35               ` Michael Walle
2020-03-24  5:37                 ` Tudor.Ambarus
2020-03-24  3:52   ` Jungseung Lee
2020-03-25  9:44   ` Tudor.Ambarus
2020-03-23  9:24 ` [PATCH v3 2/5] mtd: spi-nor: Set all BP bits to one when lock_len == mtd->size Tudor.Ambarus
2020-03-23 14:08   ` Jungseung Lee
2020-03-23 18:28   ` Michael Walle
2020-03-23  9:24 ` [PATCH v3 3/5] mtd: spi-nor: Add new formula for SR block protection handling Tudor.Ambarus
     [not found]   ` <000001d600ff$063a8fd0$12afaf70$@samsung.com>
2020-03-23 13:32     ` Jungseung Lee
2020-03-23  9:24 ` [PATCH v3 4/5] mtd: spi-nor: Add SR 4bit block protection support Tudor.Ambarus
2020-03-23 12:43   ` Jungseung Lee
2020-03-23 12:55     ` Tudor.Ambarus
2020-03-23 13:16       ` Jungseung Lee
2020-03-23 18:33   ` Michael Walle
2020-03-23 18:51     ` Tudor.Ambarus
2020-03-23  9:24 ` [PATCH v3 4/5] mtd: spi-nor: Add 4bit SR " Tudor.Ambarus
2020-03-23  9:46   ` Tudor.Ambarus
2020-03-23  9:24 ` [PATCH v3 5/5] mtd: spi-nor: Enable locking for n25q512ax3/n25q512a Tudor.Ambarus

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=401ca7a54a8d327a0397880db6a9a475@walle.cc \
    --to=michael@walle.cc \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=js07.lee@samsung.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=vigneshr@ti.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).