michallenc opened a new pull request, #16624:
URL: https://github.com/apache/nuttx/pull/16624
## Summary
This commit introduces the new option `MTD_PARTITION_REGISTER` that allows
to register MTD partition with `mtd_partition_register` call as a standard
device driver with support for `open`/`read`/`write`/`seek` calls. This brings
to the possibility to directly access raw flash without the need for FTL layer
(that causes unnecessary block erases) and BCH layer (usually used with buffers
of erase block size, large memory consumption).
The MTD access avoids any buffering (except for write page allocation if
byte read/write is not available in the flash driver), but keeps the
responsibility of flash erases on the user application. Therefore, write call
only writes the given number of bytes, but doesn't check if erase is needed,
wear leveling, false blocks and so on.
## Impact
None on current implementation. The newly added code is compiled only if
`MTD_PARTITION_REGISTER` is configured.
The goal is to provide the direct access to raw flash. If the application
needs to write directly to flash (usually NOR), it can utilize FTL and BCH
layer. But these two have some disadvantages. FTL layer performs erase before
every write, thus it has to read the entire erase page, erase it and write it
with changes. This means the entire erase page has to be buffered (can be
several kilo bytes of RAM memory) and that flash wear level is much higher than
it has to be. The FTL layer can be used with BCH layer with write buffering
enabled. This limits flash wear as erase/write is performed only when different
erase page is accessed (or during flush), but brings another erase page size
large buffer, thus yet again increases memory consumption. Last but not least,
the write operation performed by FTL takes significant amount of time because
of page erase, meaning the data may be lost during power cut off.
FTL and BCH combination is a good option if you have a lot of RAM and want
simple application that doesn't care about whether it has to erase the page
before writing to it. The newly introduced option brings the possibility of
less memory consumption and potentially faster writes, but imposes further
requirements on the application using it.
The access is similar to the one provided by Linux with MTD layer.
## Testing
Tested with SAMv7 custom board on w25q NOR flash and SAMV71-Xult evaluation
kit on s25fl1 NOR flash. The behavior was tested with a custom logging
application that reads/writes/erases the partitions and the following code. The
board registers the partition to `/dev/mtd` devpath and performs write and seek
operations. The partition was erased prior to writes with `flash_eraseall
/dev/mtd`
```C
#include <nuttx/config.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <errno.h>
int main(int argc, FAR char *argv[])
{
int ret = 0;
int fd = open("/dev/mtd", O_RDWR);
if (fd < 0) {
printf("failed to open %d", errno);
return -1;
}
char buf[4] = {0x33, 0x22, 0x00, 0xab};
ret = write(fd, buf, sizeof buf);
if (ret < 0) {
printf("failed to write: %d\n", errno);
}
lseek(fd, 32, SEEK_SET);
ret = write(fd, buf, sizeof buf);
if (ret < 0) {
printf("failed to write: %d\n", errno);
}
buf[0] = 0xff;
ret = write(fd, buf, sizeof buf);
if (ret < 0) {
printf("failed to write: %d\n", errno);
}
lseek(fd, -4, SEEK_CUR);
buf[0] &= ~(1 << 7);
ret = write(fd, &buf[0], 1);
if (ret < 0) {
printf("failed to write: %d\n", errno);
}
close(fd);
return 0;
}
```
The subsequent hexdump output is as expected:
```console
nsh> hexdump /dev/mtd count=128
/dev/mtd at 00000000:
0000: 33 22 00 ab ff ff ff ff ff ff ff ff ff ff ff ff 3"..............
0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
0020: 33 22 00 ab 7f 22 00 ab ff ff ff ff ff ff ff ff 3"..."..........
0030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
0040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
0050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
0060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
0070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
