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 -- Thank you, Alexey