mtd-utils.git/tests/mtd-tests/flash_speed.c, branch v2.3.1

mtd-tests: flash_speed: fix error message in read_eraseblock()

2025-11-28T19:13:57+00:00

Replace 'write' with 'read' in the error message of the read_eraseblock() function to indicate the correct direction of the operation. Signed-off-by: Gabor Juhos Signed-off-by: David Oberhollenzer

mtd-tests: flash_speed: really skip destructive tests

2025-11-28T19:13:56+00:00

Although both the 'multi-block erase' and the 'read-while-write latency' tests are destructive, but those are executed irregardless of whether destructive mode is enabled or not. Change the code to skip these tests if the DESTRUCTIVE flag is not set to avoid unexpected behaviour. Signed-off-by: Gabor Juhos Signed-off-by: David Oberhollenzer

mtd-tests: flash_speed: Benchmark continuous reads

2024-10-08T06:15:00+00:00

Currently the read throuput test tries: - 1 page - 2 pages - 1 block (64 or more pages, usually) But it might be interesting to see how the speed gradually increases, eg. testing all number of pages from 1 to maybe 16, and then arbitrarilly 32 and 64. Let's add a -C parameter to enable this additional test. The 2-page read/write tests are also moved under this new option. Signed-off-by: Miquel Raynal Signed-off-by: David Oberhollenzer

mtd-tests: flash_speed: Drop read_eraseblock_by_page()

2024-10-08T06:14:57+00:00

The read_eraseblock_by_2pages() has been generalized so it became read_eraseblock_by_npages(), but there is no limitation (besides 0) regarding the number of pages. Hence, drop the _by_page() helper and replace it with the _by_npages(), using 'npages = 1'. Signed-off-by: Miquel Raynal Signed-off-by: David Oberhollenzer

mtd-tests: flash_speed: Generalize read_eraseblock_by_2pages()

2024-10-08T06:14:53+00:00

Right now there are only 2 pages that may be read continuously, but why not trying more? At least when the continuous feature is out, this type of benchmarking will be interesting. In order to facilitate later additions, lets make this helper more generic and accept a global 'npages' variable as parameter (because this function is called in a macro, it is simpler like that). Signed-off-by: Miquel Raynal Signed-off-by: David Oberhollenzer

mtd-tests: flash_speed: Clarify the number of pages in each set while measuring

2024-10-08T06:14:50+00:00

So far speed calculations have only be done 1 page at a time or 2 pages at a time in a block; so basically all the block was always read because all blocks are multiple of 2. But in the future, if we want to extend the number of pages in a single read, the final number of pages actually read might be less than an erase block size, hence failing the throuput calculations. Make the number of pages in a set explicit. Signed-off-by: Miquel Raynal Signed-off-by: David Oberhollenzer

mtd-tests: flash_speed: Drop an apparently useless block

2024-10-08T06:14:46+00:00

I know no device without a multiple of 2 number of pages in each block. Even though it might be the case, it is clearly not a big deal and we don't really care about reading the last page, we are doing a speed benchmark; so as long as the throughput calculation knows how much data has been read it's fine. Eitherway, I don't think we ever have fallen in this block because we would read the content of two pages (so one past the block) and put it in a page-wide buffer, which would probably lead to an out-of-bound abort. Just drop the block. Signed-off-by: Miquel Raynal Signed-off-by: David Oberhollenzer

Remove unused symbols

2023-08-24T07:57:19+00:00

Signed-off-by: David Oberhollenzer

mtd-utils: Add new syntax to get devices by name

2023-05-30T09:12:12+00:00

This introduces a new feature to the MTD command line utilities that allows MTD devices to be referenced by name instead of device node. For example this looks like: > # Display info for the MTD device with name "data" > mtdinfo mtd:data > # Copy file to MTD device with name "data" > flashcp /my/file mtd:data This follows the syntax supported by the kernel which allows MTD device's to be mounted by name[1]. Add the function mtd_find_dev_node() that accepts an MTD "identifier" and returns the MTD's device node. The function accepts a string starting with "mtd:" which it treats as the MTD's name. It then attempts to search for the MTD, and if found maps it back to the /dev/mtdX device node. If the string does not start with "mtd:", then assume it's the old style and refers directly to a MTD device node. The function is then hooked into existing tools like flashcp, mtdinfo, flash_unlock, etc. To load in the new MTD parsing code in a consistent way across programs. [1] http://www.linux-mtd.infradead.org/faq/jffs2.html#L_mtdblock Signed-off-by: Brandon Maier Signed-off-by: David Oberhollenzer

mtd-utils: flash_speed: Measure read while write latency

2022-11-18T19:44:46+00:00

The Read While Write (RWW) feature allows to perform reads from the flash array into cache while a program (from cache) or an erase operation happens, provided that the two areas are located on different banks. The main benefit is the possible reduced latency when requesting to read a page while a much longer operation is ongoing, like a write or an erase. We can try to compare the positive impact of such a feature by enhancing the flash_speed test tool with the following test: - Measure the time taken by an eraseblock write in parallel with an eraseblock read. - Measure when the read operation ends. - Compare the two to get the latency saved with the RWW feature. To be sure the mtd_write actually starts (and acquires the necessary locks) before the mtd_read does, we use SCHED_FIFO at rather high (arbitrary) priorities, respectively 42 and 41. Signed-off-by: Miquel Raynal Signed-off-by: David Oberhollenzer