Re: block devices on MTD and UBI

[Heiko Schocher <hs@denx.de>]

Hello Oskar,

On 25.03.25 09:00, Oskar Nilsson wrote:
>> 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.

Hmm... yep, so the theory ... but let me first look if this is used in mainline:

hs@threadripper:u-boot  [master] $ grep -lr UBI_BLOCK configs/
hs@threadripper:u-boot  [master] $

So no users at all currently? That explains, why it is may buggy.

hs@threadripper:u-boot  [master] $ grep -lr UBI_BLOCK .
./drivers/mtd/nand/spi/core.c
./drivers/mtd/ubi/ubi.h
./drivers/mtd/ubi/Makefile
./drivers/mtd/ubi/Kconfig
./include/ubi_uboot.h

And option is not selected through any Kconfig ... so yes, expect bugs
here... and I have no hardware for that to dig into ... I am sorry.

> 
> 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@1806000
> blk 0 [ ] ubi_blk | | `-- <nand-controller@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@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

Do I see it correct that your patch:

https://patchwork.ozlabs.org/project/uboot/patch/20250325174708.426459-1-onilsson@rums.se/

fixes this problem?

> => 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@1806000
> blk 0 [ ] ubi_blk | | `-- <nand-controller@1806000.blk>
> partition 0 [ ] blk_partition | | |-- <nand-controller@1806000.blk>:1
> partition 1 [ ] blk_partition | | |-- <nand-controller@1806000.blk>:2
> partition 2 [ ] blk_partition | | |-- <nand-controller@1806000.blk>:3
> partition 3 [ ] blk_partition | | |-- <nand-controller@1806000.blk>:4
> partition 4 [ ] blk_partition | | |-- <nand-controller@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.

Please send a formal patch for this, so I can pick it up, thanks!

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs@denx.de