block devices on MTD and UBI
Mike Looijmans
mike.looijmans at topic.nl
Mon Mar 24 14:58:01 CET 2025
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...
>
>
>>
>>>
>>> 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 at 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 at tdkz30:~# ubiblock --create /dev/ubi0_0
root at tdkz30:~# mount /dev/ubiblock0_0 /run/s
root at 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 at topic.nl
W: www.topic.nl
More information about the U-Boot
mailing list