Just posted on github: I use MTD/FTL/BCH FOR NXboot and don't want to
stumble across things being broken and wasting days. If there are
enhancements/improvements I'm all-in but please let us - me - know when
it appears ready to merge and I will test on my custom board: as long as
I see clear information on changes I need to make to prevent breakage!!
On 10/07/2025 21:13, Michal Lenc wrote:
Hi,
I tested the patch few days ago with nxboot and a custom logging
library, used w25q qspi nor flash and internal nor flash in SAMv7 MCU.
Also the simple application presented in my pull request can be used
as a basic test (this was my initial idea to have a separate driver,
but later discarded in favor of changes Xiaomi made to BCH layer).
https://github.com/apache/nuttx/pull/16624
I don't think there are any common MTD/FTL/BCH layer tests available
now. We have MTD benchmark utilities, but these expects write page has
the same size as erase page, so it is unusable for a lot of devices.
I consider the changes presented by Jing Fei important as they remove
huge limitations of BCH/FTL layer described in both pull requests
(basically you either consume a lot of memory for buffering or do
erase for every write, which is slow and wears flash).
Michal
On 7/10/25 20:13, Matteo Golin wrote:
Are there any test cases that could be used to verify the PR? It's a
large
change but I don't see any testing logs in the PR. I think this
should be
tested with a few different devices before getting merged, and the
results
recorded.
Matteo
On Thu, Jul 10, 2025 at 1:25 PM Tomek CEDRO <to...@cedro.info> wrote:
Hello world :-)
There is interesting update PR to bch / mtd / ftl / fs subsystems that
increased granularity of control and improved performance (write).
Please take a look, any hints are welcome especially from people using
them that may be affected or verify the improvement :-)
The solution provides backward compatible behavior but the functions
API will be changed with new flags field added so build errors may pop
up after this change.
https://github.com/apache/nuttx/pull/16642
Summary
**To save more space (equivalent to the size of one erase sector of
MTD device) and to achieve faster read and write speeds, a method for
direct writing was introduced at the FTL layer. This can be
accomplished simply by using the following oflags during
the open operation:
O_DIRECT. when this flag is passed in, ftl internally uses the
direct write strategy and no read cache is used in ftl;
otherwise, each write will be executed with the minimum
granularity of flash erase sector size which means a
"sector read back - erase sector - write sector" operation is
performed by using a read cache buffer in heap.
O_SYNC. When this flag is passed in, we assume that the flash has
been erased in advance and no erase operation
will be performed internally within ftl. O_SYNC will take effect
only when both O_DIRECT and O_SYNC are passed in
simultaneously.
For uniformity, we remapped the mount flag in mount.h and unified
it with the open flag in fcntl.h. The repetitive
parts of their definitions were reused, and the remaining part of
the mount flag redefine to the unused bit of open
flags.**
Impact
When an application wants to bypass the following logic in the FTL
layer during the process of writing to Flash: using the sector size as
the buffer for "read-back - erase - write", the MTD device node can be
opened with the O_DIRECT flag. At this point, the FTL will directly
write to the MTD device. The open method is as follows:
fd = open("/dev/mtd_device", O_RDWR | O_DIRECT);
If the application ensures that the flash has been erased in advance,
then adding the O_SYNC logic can control the FTL not to perform
erasure. The open method is as follows:
fd = open("/dev/mtd_device", O_RDWR | O_DIRECT | O_SYNC);
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
