Am 2021-03-01 18:32, schrieb Michael Walle:
Am 2021-02-28 13:00, schrieb [email protected]:
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
