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
# 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/
