[PATCH v1 0/4] Introduce mtdblock device

[Alexey Romanov]

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