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.looijm...@topic.nl
W: www.topic.nl
