Am 2020-03-23 22:30, schrieb Tudor.Ambarus@xxxxxxxxxxxxx:
On Monday, March 23, 2020 11:14:05 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 21:26, schrieb Tudor.Ambarus@xxxxxxxxxxxxx:
> 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@xxxxxxxxxxxxx:
>> > 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@xxxxxxxxxxxxx:
>> >> > From: Tudor Ambarus <tudor.ambarus@xxxxxxxxxxxxx>
>> >> >
>> >> > 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
what happens if you request flash_lock -l /dev/mtd1 0 3?
with your 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 3
# cat
/sys/devices/platform/soc/20c0000.spi/spi_master/spi0/spi0.0/status_reg
a4
without it:
# 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 3
# cat
/sys/devices/platform/soc/20c0000.spi/spi_master/spi0/spi0.0/status_reg
a8
# 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)
I'm wondering what was the reason for the -EINVAL.
# 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?
Looks so. You should have obtained, 0xa8, right?
correct, BP should be 010b for the first two sectors.
Will recheck tomorrow
morning.
Thanks for testing this! I don't have a 32Mbit flash ...
You should be able to reproduce it with every flash >=32Mbit which has
3 BP bits.
-michael
Cheers,
ta
> - "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/
