I added Qt to Yocto, but when I compile, I have an error:
“ubinize: error!: error in section “sysfs_volume”: size of the image file […] .rootfs.2k.ubifs” is 40886272, which is larger than volume size 39845888"
This volume size 39845888 (38 Mo) is defined in swi-mdm9x28.conf ( UBI_ROOTFS_SIZE ?= “38MiB”). I can increase this value and change the parameter MKUBIFS_ARGS_2k = “-m 2048 -e 126976 -c 1208 -F” as well to make it compile.
But sometimes when I flash a soft (too big ?) , I get this error:
[ 1.568428] ubi0 error: vtbl_check: too large reserved_pebs 123, good PEBs 120
[ 1.574662] ubi0 error: vtbl_check: volume table check failed: record 0, error 9
[ 1.582023] Volume table record 0 dump:
[ 1.585811] reserved_pebs 123
[ 1.589020] alignment 1
[ 1.592087] data_pad 0
[ 1.595096] vol_type 2
[ 1.598131] upd_marker 0
[ 1.601291] name_len 6
[ 1.604295] name rootfs
[ 1.607747] crc 0x62fc0086
[ 1.611837] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd13, error -22
ubiattach: error!: cannot attach mtd13
error 22 (Invalid argument)
Unable to attach mtd13 to UBI logical dev
Could you help me to understand the limitations / misunderstandings ?
Hi @nkau_tha, the rootfs is constrained to a partition of the size described in the .conf file. The limit implemented there is to prevent the developer from attempting to flash the partition with an oversized file. In doing so, the flash write will stop at the partition boundary, and the partition won’t be valid as a UBI device.
We are aware of the boot failure when flashing an oversized image - a similar failure is also observed if writing an oversized Legato Application Framework image. We’d like to make this a more graceful failure, but ultimately it’s still not going to fit :). A potential improvement for the future is to support resizable partitions, but this is not currently available.
Hi @rkirk, I clearly understand that flashing an oversized image causes problems and I understand that there is not yet an easy way to resize partitions, but it should be possible in Yocto to decrease the size of the Legato partition and to increase the rootfs one ?
I don’t know if you could help me to do so but I’d like to know if there are no restrictions.
edit:
I read on another post that the AT command (APPPARTCHG) is not supported on WP7702. When I list mtd partitions, I get:
"
mtd0: 00280000 00040000 “sbl”
mtd1: 00280000 00040000 “mibib”
mtd2: 00680000 00040000 “backup”
mtd3: 00100000 00040000 “security”
mtd4: 00200000 00040000 “persist”
mtd5: 01180000 00040000 “efs2”
mtd6: 04f40000 00040000 “swifota”
mtd7: 00180000 00040000 “tz”
mtd8: 000c0000 00040000 “devcfg”
mtd9: 000c0000 00040000 “rpm”
mtd10: 02000000 00040000 “modem”
mtd11: 00100000 00040000 “aboot”
mtd12: 00f00000 00040000 “boot”
mtd13: 01e00000 00040000 “system”
mtd14: 008c0000 00040000 “lefwkro”
mtd15: 01900000 00040000 “swirw”
mtd16: 08300000 00040000 “userapp”
mtd17: 03680000 00040000 “reserved”
mtd18: 02180000 00040000 “slot_2”
mtd19: 02180000 00040000 “slot_1”
mtd20: 02180000 00040000 “slot_0”
"
I can’t find any references to some of those (swifota for example). So I just want to understand ;), are there any partitions that we can’t access at all by using the software swiflash or fwupdate and the ones that we can reflash can’t be changed because it was a previous operation (made by Sierra Wireless).
Hi @nkau_tha, yes that’s correct. The APPPARTCHG command was supported on the prior generation, and allowed resizing of the Linux partitions (for your modem that would mean aboot->reserved). So, for your modem, the total size of mtd11 to mtd17, inclusive, would remain a constant, but boundaries could be redefined by that command, with logic to ensure they remained on flash block boundaries, etc.
There are some things that might be possible, making changes only in the open source domain. For example, you could remap the partitions in aboot/LK, basically overriding the real partition table . This is dangerous in that FOTA, swiflash, and other tools that depend on SBL for programming, aren’t going to be aware of the updated partition table, making them essentially incompatible. Those tools would still work, respecting the original partition table, and conflicting with your remapped regions. You’d be limited to programming Linux partitions from LK, which means Fastboot mode.
Another possibility is swapping userapp and system partitions, functionally, if you can fit your read/write content into the space currently used by the rootfs. This would make the device incompatible with the Sierra CWE releases, since the Sierra rootfs is still going to be written to the system partition. To do this, you’d need to change the mount scripts and either update the CWE type, or use Fastboot to write the rootfs into the larger partition. I’m not sure if that’s the entire scope of changes, either.
Neither idea would be trivial, and just to emphasize, I haven’t actually tried them myself.
?