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-control...@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-control...@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-onils...@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-control...@1806000.blk>
partition 0 [ ] blk_partition | | |-- <nand-control...@1806000.blk>:1
partition 1 [ ] blk_partition | | |-- <nand-control...@1806000.blk>:2
partition 2 [ ] blk_partition | | |-- <nand-control...@1806000.blk>:3
partition 3 [ ] blk_partition | | |-- <nand-control...@1806000.blk>:4
partition 4 [ ] blk_partition | | |-- <nand-control...@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: h...@denx.de
