Hi Frieder,
On Thu, Feb 29, 2024 at 09:51:04AM +0100, Frieder Schrempf wrote:
Hi Alexey,
On 27.02.24 11:04, Alexey Romanov wrote:
Hello!
This series adds support for the mtdblock device, which allows to read/write data block by block. For example, it can now be used for BCB or Android AB command:
$ bcb load mtd 0 part_name
Tested only on SPI NAND, so bind is made only for SPI NAND drivers.
I don't know much about Android, but as far as I understand you are trying to store dynamic, boot-related information on the MTD device.
This might be acceptable if the underlying device is a NOR flash, but for any type of NAND device it sounds like a rather bad idea.
NAND devices need some kind of FTL (flash translation layer) in order to work reliably. Using a block filesystem directly on the NAND MTD device will cause problems as soon as any bad blocks or bit flips occur.
People are therefore discouraged to use mtdblock on NAND and in the kernel there is even a warning if you try to mount a NAND mtdblock partition.
You are completely right. But, unfortunately, these are legacy ones that need to be supported. On some boards this approach was chosen a long time ago and mistakenly, so I think we need to support this for NAND.
Maybe you should reconsider this and look into how to use UBIFS as a FTL. On the other hand I'm not quite sure if the UBIFS layer in U-Boot is really stable and maintained. So this might not be a good idea either.
Yeah, on our new boards we switched to using UBI, and we already have an implementation UBI block device for U-Boot. Will send this to mailing list in the near future.
Anyway, I'm against implementing mtdblock for SPI NAND (or any other NAND).
Maybe we'll just add warning like it's done in the Linux?
Best regards Frieder