[PATCH v3 1/2] mtd: spi-nor: add OTP support
Michael Walle
michael at walle.cc
Mon Mar 1 21:31:22 GMT 2021
Am 2021-03-01 18:32, schrieb Michael Walle:
> Am 2021-02-28 13:00, schrieb Tudor.Ambarus at microchip.com:
>> On 2/16/21 6:28 PM, Michael Walle wrote:
>> Does the otp memory organization matter for the end user?
>> Can't we lock/read/write past region size, for example 2 or 3 regions
>> in a row,
>> depending on length?
>
> Mhh tough one. I guess the question really is: Do we want
> to remap the 0x1000, 0x2000, 0x3000 offsets?
> - 0x1000 -> 0
> - 0x2000 -> 1 * region_size
> - 0x3000 -> 2 * region_size
>
> This is just an example, some devices may us other offsets.
>
> I'd see this as a prerequsite for handling multiple regions
> in one write, because otherwise you'll have to handle the
> holes which makes it impossible I guess. For example what
> would happen with (given an otp size of 0x100):
> (1) lock(0, 0x100)
> (2) lock(0x100, 0xf00)
> (3) lock(0, 0x1000)
>
> (1) will work, (2) should return -EINVAL; but what will (3)
> return. -EINVAL too, I guess. But then, ops spanning multiple
> regions doesn't make sense at all, because they will always
> return -EINVAL.
>
> Unfortunately, I don't know how userspace might access it.
>
> This is how it looks like at the moment:
>
> # flash_otp_info -u /dev/mtd1
> Number of OTP user blocks on /dev/mtd1: 3
> block 0: offset = 0x1000 size = 256 bytes [unlocked]
> block 1: offset = 0x2000 size = 256 bytes [unlocked]
> block 2: offset = 0x3000 size = 256 bytes [unlocked]
Hm, I just found the following in the mtd-utils [1]:
"offset and size must match on OTP region boundaries".
[1]
http://git.infradead.org/mtd-utils.git/blob/HEAD:/misc-utils/flash_otp_lock.c#l25
-michael
More information about the linux-mtd
mailing list