block devices on MTD and UBI

block devices on MTD and UBI

[Mike Looijmans]

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?

I also have UBI_BLOCK enabled, so I would expect UBI volumes to appear 
in the "lsblk" as well.

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@0
   - parent: spi@e000d000
   - driver: jedec_spi_nor
   - path: /axi/spi@e000d000/flash@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"

Zynq> lsblk
Block Driver          Devices
-----------------------------
efi_blk             : <none>
mmc_blk             : mmc 0
mtd_blk             : <none>
ubi_blk             : <none>
usb_storage_blk     : <none>

Zynq> ubi part qspi-rootfs
Zynq> ubi list
0: qspi-rootfs
Zynq> lsblk
Block Driver          Devices
-----------------------------
efi_blk             : <none>
mmc_blk             : mmc 0
mtd_blk             : <none>
ubi_blk             : <none>
usb_storage_blk     : <none>


I would have expected the SPI NOR flash to appear in the "mtd_blk" 
devices, and would expect the UBI volumes to appear in the "ubi_blk" list.
What am I missing?

What I'm aiming for here is to be able to:
- Read from squashfs in (raw) MTD partition (NOR flash is ideal for that)
- Read kernel/devicetree (fit) from UBI volume
- Read from squashfs inside UBI volume


I can read files from UBIFS (and boot into Linux using bootcmd_ubifs) 
just fine, e.g.:
Zynq> ubifsmount ubi0:qspi-rootfs
Zynq> ls ubi 0
<DIR>        5200  Fri Mar 09 12:34:56 2018  bin
<DIR>         160  Fri Mar 09 12:34:56 2018  dev
<DIR>        4984  Fri Mar 09 12:34:56 2018  etc
...


-- 
Mike Looijmans
System Expert

TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl

Re: block devices on MTD and UBI

[Heiko Schocher]

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@0
>    - parent: spi@e000d000
>    - driver: jedec_spi_nor
>    - path: /axi/spi@e000d000/flash@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?

> 
> Zynq> lsblk
> Block Driver          Devices
> -----------------------------
> efi_blk             : <none>
> mmc_blk             : mmc 0
> mtd_blk             : <none>
> ubi_blk             : <none>

Here (and for mtd) seems something missing!

> usb_storage_blk     : <none>
> 
> Zynq> ubi part qspi-rootfs
> Zynq> ubi list
> 0: qspi-rootfs
> Zynq> lsblk
> Block Driver          Devices
> -----------------------------
> efi_blk             : <none>
> mmc_blk             : mmc 0
> mtd_blk             : <none>
> ubi_blk             : <none>
> usb_storage_blk     : <none>
> 
> 
> I would have expected the SPI NOR flash to appear in the "mtd_blk" devices, and would expect the UBI 
> volumes to appear in the "ubi_blk" list.
> What am I missing?

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 }

The only thing I just stumbled over is:

drivers/mtd/ubi/block.c
  35 static struct ubi_device *get_ubi_device(void)
  36 {
  37         return ubi_devices[0];
  38 }

may this is not perfect.

But as said, I cannot try out ...

> What I'm aiming for here is to be able to:
> - Read from squashfs in (raw) MTD partition (NOR flash is ideal for that)
> - Read kernel/devicetree (fit) from UBI volume
> - Read from squashfs inside UBI volume
> 
> 
> I can read files from UBIFS (and boot into Linux using bootcmd_ubifs) just fine, e.g.:
> Zynq> ubifsmount ubi0:qspi-rootfs
> Zynq> ls ubi 0
> <DIR>        5200  Fri Mar 09 12:34:56 2018  bin
> <DIR>         160  Fri Mar 09 12:34:56 2018  dev
> <DIR>        4984  Fri Mar 09 12:34:56 2018  etc
> ...
> 
> 

Good to hear that UBI/UBIFS setup is working!

So I fear there is some "add feature"/debug work ToDo to get this up and
working ...

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

Re: block devices on MTD and UBI

[Mike Looijmans]

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@0
>>    - parent: spi@e000d000
>>    - driver: jedec_spi_nor
>>    - path: /axi/spi@e000d000/flash@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...


>
>>
>> Zynq> lsblk
>> Block Driver          Devices
>> -----------------------------
>> efi_blk             : <none>
>> mmc_blk             : mmc 0
>> mtd_blk             : <none>
>> ubi_blk             : <none>
>
> Here (and for mtd) seems something missing!
>
>> usb_storage_blk     : <none>
>>
>> Zynq> ubi part qspi-rootfs
>> Zynq> ubi list
>> 0: qspi-rootfs
>> Zynq> lsblk
>> Block Driver          Devices
>> -----------------------------
>> efi_blk             : <none>
>> mmc_blk             : mmc 0
>> mtd_blk             : <none>
>> ubi_blk             : <none>
>> usb_storage_blk     : <none>
>>
>>
>> I would have expected the SPI NOR flash to appear in the "mtd_blk" 
>> devices, and would expect the UBI volumes to appear in the "ubi_blk" 
>> list.
>> What am I missing?
>
> 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...


> The only thing I just stumbled over is:
>
> drivers/mtd/ubi/block.c
>  35 static struct ubi_device *get_ubi_device(void)
>  36 {
>  37         return ubi_devices[0];
>  38 }
>
> may this is not perfect.

That might be because there can be only one active UBI device anyway.


>
> But as said, I cannot try out ...
>
>> What I'm aiming for here is to be able to:
>> - Read from squashfs in (raw) MTD partition (NOR flash is ideal for 
>> that)
>> - Read kernel/devicetree (fit) from UBI volume
>> - Read from squashfs inside UBI volume
>>
>>
>> I can read files from UBIFS (and boot into Linux using bootcmd_ubifs) 
>> just fine, e.g.:
>> Zynq> ubifsmount ubi0:qspi-rootfs
>> Zynq> ls ubi 0
>> <DIR>        5200  Fri Mar 09 12:34:56 2018  bin
>> <DIR>         160  Fri Mar 09 12:34:56 2018  dev
>> <DIR>        4984  Fri Mar 09 12:34:56 2018  etc
>> ...
>>
>>
>
> Good to hear that UBI/UBIFS setup is working!
>
> So I fear there is some "add feature"/debug work ToDo to get this up and
> working ...
>
Good to know it's just missing and not due to something I broke or missed...

Thanks for your reply.


-- 
Mike Looijmans
System Expert

TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl

Re: block devices on MTD and UBI

[Mike Looijmans]

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@0
>>>    - parent: spi@e000d000
>>>    - driver: jedec_spi_nor
>>>    - path: /axi/spi@e000d000/flash@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...
>
>
>>
>>>
>>> Zynq> lsblk
>>> Block Driver          Devices
>>> -----------------------------
>>> efi_blk             : <none>
>>> mmc_blk             : mmc 0
>>> mtd_blk             : <none>
>>> ubi_blk             : <none>
>>
>> Here (and for mtd) seems something missing!
>>
>>> usb_storage_blk     : <none>
>>>
>>> Zynq> ubi part qspi-rootfs
>>> Zynq> ubi list
>>> 0: qspi-rootfs
>>> Zynq> lsblk
>>> Block Driver          Devices
>>> -----------------------------
>>> efi_blk             : <none>
>>> mmc_blk             : mmc 0
>>> mtd_blk             : <none>
>>> ubi_blk             : <none>
>>> usb_storage_blk     : <none>
>>>
>>>
>>> I would have expected the SPI NOR flash to appear in the "mtd_blk" 
>>> devices, and would expect the UBI volumes to appear in the "ubi_blk" 
>>> list.
>>> What am I missing?
>>
>> 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 a squashfs filesystem put into an ubi block on a static volume. 
In Linux I can do this:

root@tdkz30:~# ubiattach -m 1
UBI device number 0, total 496 LEBs (32442368 bytes, 30.9 MiB), 
available 0 LEBs (0 bytes), LEB size 65408 bytes (63.8 KiB)
root@tdkz30:~# ubiblock --create /dev/ubi0_0
root@tdkz30:~# mount /dev/ubiblock0_0  /run/s
root@tdkz30:~# ls -al /run/s
drwxr-xr-x   16 root     root           236 Mar  9  2018 .
drwxr-xr-x   13 root     root           380 Mar 24 13:21 ..
drwxr-xr-x    2 root     root          1023 Mar  9  2018 bin
drwxr-xr-x    3 root     root           123 Mar  9  2018 boot
drwxr-xr-x    2 root     root             3 Mar  9  2018 dev
drwxr-xr-x   19 root     root           959 Mar  9  2018 etc
...


I have no clue what the equivalent in U-boot would be. I can see that 
the static volume is there:


zynq-uboot> ubi part qspi-rootfs
SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, 
total 32 MiB
ubi0: attaching mtd2
ubi0: scanning is finished
ubi0: attached mtd2 (name "qspi-rootfs", size 31 MiB)
ubi0: PEB size: 65536 bytes (64 KiB), LEB size: 65408 bytes
ubi0: min./max. I/O unit sizes: 1/256, sub-page size 1
ubi0: VID header offset: 64 (aligned 64), data offset: 128
ubi0: good PEBs: 496, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 16/11, WL threshold: 4096, image sequence 
number: 2011979467
ubi0: available PEBs: 0, total reserved PEBs: 496, PEBs reserved for bad 
PEB handling: 0
zynq-uboot> ubi list
0: qspi-rootfs
zynq-uboot> ubi info
UBI: MTD device name:            "qspi-rootfs"
UBI: MTD device size:            31 MiB
UBI: physical eraseblock size:   65536 bytes (64 KiB)
UBI: logical eraseblock size:    65408 bytes
UBI: number of good PEBs:        496
UBI: number of bad PEBs:         0
UBI: smallest flash I/O unit:    1
UBI: VID header offset:          64 (aligned 64)
UBI: data offset:                128
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     1
UBI: available PEBs:             0
UBI: total number of reserved PEBs: 496
UBI: number of PEBs reserved for bad PEB handling: 0
UBI: max/mean erase counter: 16/11


I tried a bunch of variations on "ls qspi-rootfs" and so, I can't seem 
to guess the right invokation there ...


> ...
>

-- 
Mike Looijmans
System Expert

TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl

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@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
=> 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.


Reagrds,
Oskar Nilsson

Re: block devices on MTD and UBI

[Heiko Schocher]

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

Re: block devices on MTD and UBI

[Oskar Nilsson]

Hello Heiko,
On Wednesday, 26 March 2025 at 06:21:35 +01:00, Heiko Schocher <hs@denx.de> wrote:

> Hello Oskar,
> 
> 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.
> 

No problem, I'll continue to try to get it working on my board.
> 
> 
> > 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?
> Yes, that's my patch, I've sent V2. Returning -ENOENT is definitely better.


> > => 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!
> 
OK, I'll test more to see if there is anything that breaks when adding this extra check.

Regards,
Oskar