I am also experiencing the same issue. I tried mounting the MTD and created a UBI volume. I can successfully access this space, but I don’t know how to use it as extroot. One thing I’ve noticed is that after every reboot, the MTD block needs to be manually mounted.otherwise, I can’t access the UBI partition
Which device are you talking about? which mtd did you format ok (with ubiformat /dev/mtdX, where X is 10 for "data" and 11 for "fota" in case o MF286D)? If you have MF286D do you have a backup of mtd10("data")? I only have backup of mtd11("fota"), I don't seem to need it for anything and I failed to restore it with either mtd write /tmp/fota_backup.bin fota or dd if=/tmp/fota_backup.bin of=/dev/mtd11((
I think the strategy for using extra available space is to identify mtd that can be used (in my case preferable option is mtd11) -> then ubiformat /dev/mtdX and ubiattach -m X (this command will attach ubi1, since you already have ubi0) -> ubimkvol /dev/ubi1 -N extroot -m (creates volume with name extroot and maximum available space) -> format with mkfs.ubifs newly created volume ubi1_0 (I guess, I did not get this far) -> proceed with regular extroot article.
These are just my intuitive thoughts and what I found from AI suggestions, I have not done this before with NAND flash and ubi partition and also need guidence.
I have an AW1000 router, but I'm stuck with the same problem you're experiencing. With the custom firmware and some additional packages, I only have around 4 MB of free space left.
Since this device has a 1 GB NAND, I checked my MTD layout and noticed the following:
cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00040000 "0:sbl1"
mtd1: 00100000 00040000 "0:mibib"
mtd2: 00080000 00040000 "0:bootconfig"
mtd3: 00080000 00040000 "0:bootconfig1"
mtd4: 00300000 00040000 "0:qsee"
mtd5: 00300000 00040000 "0:qsee_1"
mtd6: 00080000 00040000 "0:devcfg"
mtd7: 00080000 00040000 "0:devcfg_1"
mtd8: 00080000 00040000 "0:apdp"
mtd9: 00080000 00040000 "0:apdp_1"
mtd10: 00080000 00040000 "0:rpm"
mtd11: 00080000 00040000 "0:rpm_1"
mtd12: 00080000 00040000 "0:cdt"
mtd13: 00080000 00040000 "0:cdt_1"
mtd14: 00080000 00040000 "0:appsblenv"
mtd15: 00100000 00040000 "0:appsbl"
mtd16: 00100000 00040000 "0:appsbl_1"
mtd17: 00080000 00040000 "0:art"
mtd18: 06400000 00040000 "rootfs"
mtd19: 01880000 00040000 "0:wififw"
mtd20: 06400000 00040000 "rootfs_1"
mtd21: 01880000 00040000 "0:wififw_1"
mtd22: 00240000 00040000 "0:ethphyfw"
mtd23: 00100000 00040000 "0:board_data"
mtd24: 00800000 00040000 "0:arc_datadump"
mtd25: 2cbc0000 00040000 "0:arc_data"
root@Telstra_5G:~#
mtd25: 2cbc0000 00040000 "0:arc_data"
approximately 716 MB appears to be unused.
I can format and mount this partition in OpenWrt without any issues. However, I haven’t been able to find any proper tutorial on how to use this partition as extroot, which seems to be the same issue you're facing.
Correct me if I’m wrong.
As far as I understand, OpenWrt uses the rootfs (SquashFS) as /rom, and the remaining writable space becomes /overlay. So, if we could somehow merge another MTD partition with the rootfs, we might be able to increase the available space for /overlay.
I saw that you previously merged the data and fota partitions, but you didn’t modify the rootfs. That might be why you still have only around 14.52 MiB available on /overlay, right?
It is similar, however in your case if you can format and attach mtd25 without any negative effects you should deffinitelly go with "extroot" approach! In my case, I get all bad blocks when trying of format mtd11, which is only 50MiB, and I would be glad if I could at lease use this 50MiB as extroot.
in my case merging my mtd10 and mtd11 took modifing DTS file and building custom sysupgrade file, as they are close together. However this procedure took me ages, fiddling with VBox Ubuntu and then Debian virtual machines, lots of failed attempts of building images (I guess due to allocating only fixed 40Gb of drive to linux virtual machine). Not to mention that it is rather risky - the reason I did not brick my router is perhaps due to the fact that I only merged mtd10 and mtd11, thinking that installation of openwrd resides in mtd10. However kernel, rootfs and rootfs_data (where, I guess, overlay resides) is actully written to mtd9!
I don't think MTD11 can be used in any way because it's full of bad blocks. I also have a few bad blocks.four, to be exact,but that's not a problem since UBI can handle them. However, in your case, MTD11 is filled with bad blocks. So, using only MTD10 along with MTD9 (rootfs) is your only option i think. You can get an extra 25 MB that way.
Yes, but the problem I’m having is that I tried using the extroot approach, and it didn’t work.
it is not just full of bad blocks it is only bad blocks now!!! AI suggests that it could be due to "bad memory mapping/allocation", but I am back on openwrt official FW, the same FW I previouly used to make a dump of mtd11 via GUI. I looked inside file with Notepad++ and there is sensible content there. I definitelly could not physically damage the chip! @frollic, @Leo-PL, why do you think this might have happened?
@Leo-PL suggests that this way I will surely brick router, so I would like to avoid this approach, although I don't mind disassambly the unit and solder three wires to get serial connection, I definitelly don't want to desolder the NAND chip, besides I don't have the its full dump and don't know where to get it.
I can try to use my mtd10(25MiB) for extroot, it is of little use to me but in case of success I will document it and share it here...
1 Like
ad 1: probably just needs to be erased before formatting as separate UBI partition
ad 2: if we can compile upstream U-boot to replace vendor one, then we can merge both partitions, so U-boot and OpenWrt are on the same page and share the layout.
I hope this clears up the understanding.
Here is what I get, when I try to erase flash by all commands suggested by AI:
root@OpenWrt:~# flash_erase /dev/mtd11 0 0
-ash: flash_erase: not found
root@OpenWrt:~# mtd erase /dev/mtd11
Unlocking /dev/mtd11 ...
Erasing /dev/mtd11 ...
Skipping bad block at 0x0
Skipping bad block at 0x20000
Skipping bad block at 0x40000
...
Skipping bad block at 0x31c0000
Skipping bad block at 0x31e0000 root@OpenWrt:~#
Or should I do the erase procedure under different environment?
I don't even have an idea where to start there, but if anyone more competent can help or guide I will participate to most of my abilities.
no luck so far guys, after formating mtd10, attaching it to ubi and making volume:
ubiformat /dev/mtd10
ubiattach -m 10
ubimkvol /dev/ubi1 -N extroot m
I get this volume:
ubi1
Volumes count: 1
Logical eraseblock size: 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks: 200 (25395200 bytes, 24.2 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes 128
Count of bad physical eraseblocks: 0
Count of reserved physical eraseblocks: 20
Current maximum erase counter value: 11
Minimum input/output unit size: 2048 bytes
Character device major/minor: 244:0
Present volumes: 0
Volume ID: 0 (on ubi1)
Type: dynamic
Alignment: 1
Size: 176 LEBs (22347776 bytes, 21.3 MiB)
State: OK
Name: extroot
Character device major/minor: 244:1
However it disappears upon reboot(((
@frollic, any idea what am I doing wrong?
I took a look at implementation of ZTE MF269 and it gave me an idea… partition@23c0000 {
label = "ubi_kernel";
reg = <0x23c0000 0x3400000>;
};
partition@57c0000 {
label = "0:wififw";
reg = <0x57c0000 0x0800000>;
read-only;
};
/* rootfs partition is the result of squashing
* consecutive stock partitions:
* - openwrt_data (25 MiB)
* - data (30 MiB)
* - fota (99 MiB)
*/
partition@5fc0000 {
label = "rootfs";
reg = <0x5fc0000 0x9a00000>;
Stay tuned.
Now likely you just need to attach it manually during startup using some script calling ubiattach, then mount a volume - OpenWrt relies on special names given to partitions in device tree to attach filesystems, and I know of no definition for overlay here, at least at the time being.
1 Like