mtdblock is slow compared to mtd device

[Claus Stovgaard]

Hi

I have an embedded device with two qspi norflash connected to an Xilinx
ZynqMP in parallel. The flash is Micron MT25QU02GCBB8E12

The clock is runnning with 150 MHz, giving a theoretical bandwidth of
150 MB/s.

This also fits what I would expect to measure from mtd0 in bandwith
(Taking the overhead into account).

~ # dd if=/dev/mtd0 of=/dev/null bs=128k count=10
10+0 records in
10+0 records out
1310720 bytes (1.3MB) copied, 0.010963 seconds, 114.0MB/s

Currently part of the norflash is used raw for booting, and some via
UBI / UBIFS. Al this works well with a reasonable bandwidth.

Next I would like to make a section to some readonly production data /
files, so was looking into SquashFS. I noticed it was very slow - so
was looking into the block device used for mounting. Here I noticed
that the speed was much slower than I would expect. Looking further
into the mtdblock device it only gives 3.5 MB/s

~ # dd if=/dev/mtdblock0 of=/dev/null bs=128k count=10
10+0 records in
10+0 records out
1310720 bytes (1.3MB) copied, 0.355392 seconds, 3.5MB/s 

A quick kprobe on mtd_read revealed that mtdblock reads the mtd device
in 512 bytes chunks, destroying the performance.

Looking into mtdblock.c and ftl.c revealed that the flash translation
layer in the kernel in general is hardcoded to 512 bytes sectors, and
also read from the mtd in sector sizes.

The 512 bytes sector size is for me kind of oldschool where all
filesystems where working on this. Has there been any work in making a
translation layer for filesystems block sizes in the 128k or 1024k
range, like I would create the squashfs?

Alternative as I already using UBI for parts of the flash, I am
wondering about using this together with ubiblock. The question is
though if it is faster, and for the second part how it handle locked
flash?

One of the reason I am looking into the squashfs is the readonly
nature, where it fits with the locking capability on the flash chip.
The plan is to write the data as part of production, and afterwards
lock the flash for any other writes. How would UBI handle it, if the
flash is physically locked for writing?

Any comments regarding storing some data (preferable files) in locked
norflash, where the read bandwidth much be close to the bandwidth of
the mtd device is very much welcome.

Thanks ahead.
Claus Stovgaard