Re: [PATCH v1 0/4] Introduce mtdblock device
Hi Alexey, On 01.03.24 14:42, Alexey Romanov wrote: > 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? If we really need this, then yes, please add a warning that is printed to the console. Thanks Frieder
Re: [PATCH v1 0/4] Introduce mtdblock device
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
Re: [PATCH v1 0/4] Introduce mtdblock device
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. 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. Anyway, I'm against implementing mtdblock for SPI NAND (or any other NAND). Best regards Frieder
[PATCH v1 0/4] Introduce mtdblock device
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. Alexey Romanov (4): drivers: introduce mtdblock abstraction disk: support MTD partitions spinand: bind mtdblock efi: block: compile only if CONFIG_EFI_PARTITION enabled disk/part.c | 5 +- drivers/block/blk-uclass.c | 1 + drivers/mtd/Kconfig | 1 + drivers/mtd/Makefile| 1 + drivers/mtd/mtdblock.c | 170 drivers/mtd/mtdpart.c | 69 +++ drivers/mtd/nand/spi/core.c | 20 + include/linux/mtd/mtd.h | 12 +++ include/part.h | 2 + lib/efi_driver/Makefile | 2 +- 10 files changed, 281 insertions(+), 2 deletions(-) create mode 100644 drivers/mtd/mtdblock.c -- 2.34.1
