block devices on MTD and UBI

[Oskar Nilsson]

>On 20-03-2025 17:03, Mike Looijmans wrote:
>> On 19-03-2025 15:06, Heiko Schocher wrote:
>>> Hello Mike,
>>>
>>> On 18.03.25 10:04, Mike Looijmans wrote:
>>>> I think I have everything set up to access MTD (and UBI) devices as
>>>> "block", however, lsblk always ignores them, and refuses to list
>>>> anything but the mmc. I can read ubifs and boot from it though, and
>>>> since UBI runs on top of MTD block devices, MTD block device should
>>>> be working, right?
>>>
>>> Yes. I must admit, I have no device on which I have such a setup...
>>>
>>> added Alexey (who introduced ubi block support), may he can give some
>>> hints.
>>>
>>>> I also have UBI_BLOCK enabled, so I would expect UBI volumes to
>>>> appear in the "lsblk" as well.
>>>
>>> good, that would have been my first question, if you have enabled
>>> "UBI_BLOCK"
>>>
>>>> Example U-boot session:
>>>>
>>>> Zynq> mtd list
>>>> SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB,
>>>> total 32 MiB
>>>> List of MTD devices:
>>>> * nor0
>>>> - device: flash at 0
>>>> - parent: spi at e000d000
>>>> - driver: jedec_spi_nor
>>>> - path: /axi/spi at e000d000/flash at 0
>>>> - type: NOR flash
>>>> - block size: 0x10000 bytes
>>>> - min I/O: 0x1 bytes
>>>> - 0x000000000000-0x000002000000 : "nor0"
>>>> - 0x000000000000-0x000000100000 : "qspi-boot-bin"
>>>> - 0x000000100000-0x000002000000 : "qspi-rootfs"
>>>
>>> Aha, SPI NOR. I fear this is not supported yet.
>>>
>>> Do you have somehow called ubi_part() ?
>>>
>>> Can you try "ubi part...." and look if this helps?
>>
>> See below I guess...
>>
>>> It seems to me, that you have to implement this like it is done for
>>> spi nand:
>>>
>>> drivers/mtd/nand/spi/core.c
>>> 1180 static int spinand_bind(struct udevice *dev)
>>> 1181 {
>>> 1182 if (blk_enabled()) {
>>> 1183 struct spinand_plat *plat = dev_get_plat(dev);
>>> 1184 int ret;
>>> 1185
>>> 1186 if (CONFIG_IS_ENABLED(MTD_BLOCK)) {
>>> 1187 ret = mtd_bind(dev, &plat->mtd);
>>> 1188 if (ret)
>>> 1189 return ret;
>>> 1190 }
>>> 1191
>>> 1192 if (CONFIG_IS_ENABLED(UBI_BLOCK))
>>> 1193 return ubi_bind(dev);
>>> 1194 }
>>> 1195
>>> 1196 return 0;
>>> 1197 }
>>>
>> I guess that shouldn't be to hard to implement... I'll send a patch if
>> that fixes the MTD missing...
>
>Not as simple as one would think. The spi flash struct has its own "mtd"
>member which isn't a pointer but was already filled in. So I cannot
>simply call mtd_bind().
>
>I tried calling ubi_bind anyway, which had some effect:
>
>Zynq> lsblk
>Block Driver Devices
>-----------------------------
>efi_blk : <none>
>mmc_blk : mmc 0
>mtd_blk : <none>
>ubi_blk : mtd 0
>usb_storage_blk : <none>
>
>But that didn't get me any further. I'm quite puzzled by UBI block
>support...
>

I have been looking at the same issue, but haven't made much progress either.

>From my understanding, when enabling UBI_BLOCK the .bind function will add a
block device on top of the UBI device. It should then be usable by commands
that expect a blk device like sqfsls.

Note that I'm on u-boot-imx 2024.04 and have back ported the ubi and mtd block
patches, so there may be differences to latest.

Looking at the driver model, a .blk has been added:
=> dm tree
Class Index Probed Driver Name
-----------------------------------------------------------
root 0 [ + ] root_driver root_driver
thermal 0 [ ] imx_thermal |-- imx_thermal
simple_bus 0 [ + ] simple_bus |-- soc
mtd 0 [ + ] mxs-nand-dt | |-- nand-controller at 1806000
blk 0 [ ] ubi_blk | | `-- <nand-controller at 1806000.blk>
...

Calling sqfsls, seems to find the right volume (rootfs0):
=> sqfsls mtd 0 /
FS: Setting up block device: ifname='mtd', dev_part_str='0', fstype=6
Read 512 bytes from volume rootfs0 to 9ef2cb80
Disk <nand-controller at 1806000.blk> not ready
** Bad device specification mtd 0 **
Couldn't find partition mtd 0
FS: Failed to get partition info (err=-19)

Interestingly after each command that uses a blk device, I get 128 blk_partitions
=> dm tree
Class Index Probed Driver Name
-----------------------------------------------------------
root 0 [ + ] root_driver root_driver
thermal 0 [ ] imx_thermal |-- imx_thermal
simple_bus 0 [ + ] simple_bus |-- soc
mtd 0 [ + ] mxs-nand-dt | |-- nand-controller at 1806000
blk 0 [ ] ubi_blk | | `-- <nand-controller at 1806000.blk>
partition 0 [ ] blk_partition | | |-- <nand-controller at 1806000.blk>:1
partition 1 [ ] blk_partition | | |-- <nand-controller at 1806000.blk>:2
partition 2 [ ] blk_partition | | |-- <nand-controller at 1806000.blk>:3
partition 3 [ ] blk_partition | | |-- <nand-controller at 1806000.blk>:4
partition 4 [ ] blk_partition | | |-- <nand-controller at 1806000.blk>:5
...

At first I also got the error "UBIFS not mounted, use ubifsmount to mount volume first!"
To fix that I added this small patch:

diff --git a/disk/part.c b/disk/part.c
index 8982ef3bae..f168311e9a 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -524,7 +524,7 @@ int blk_get_device_part_str(const char *ifname, const char *dev_part_str,
}
#endif

-#if IS_ENABLED(CONFIG_CMD_UBIFS) && !IS_ENABLED(CONFIG_SPL_BUILD)
+#if IS_ENABLED(CONFIG_CMD_UBIFS) && !IS_ENABLED(CONFIG_SPL_BUILD) && !IS_ENABLED(CONFIG_UBI_BLOCK)
/*
* Special-case ubi, ubi goes through a mtd, rather than through
* a regular block device.


Reagrds,
Oskar Nilsson