Rootfs size on 4/32 device (edimax 3G-6200n), enlarge to fill?

[soulsearchingsun83]

I want to install and use OpenWrt on a 4/32 device (edimax 3G-6200n).
I installed the latest available image (19.07.2). I noticed that the jffs2 partition rootfs_data doesn't get utilized, all settings are just temporary until reboot.
Upon digging further, I noticed that the jffs2 driver complains about having too few erase blocks:

Thu Feb 27 21:06:22 2020 kern.err kernel: [   86.664819] jffs2: Too few erase blocks (2)
Thu Feb 27 21:06:22 2020 daemon.err mount_root: failed - mount -t jffs2 /dev/mtdblock7 /rom/overlay: Not a tty

I was irritated by the error message, but kept investigating.

This is the output of /proc/mtd

root@OpenWrt:~# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00030000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "factory"
mtd3: 00020000 00010000 "cimage"
mtd4: 00390000 00010000 "firmware"
mtd5: 0014864d 00010000 "kernel"
mtd6: 002479b3 00010000 "rootfs"
mtd7: 00020000 00010000 "rootfs_data"

The relevant output of logread

Thu Feb 27 21:05:27 2020 kern.notice kernel: [    0.701953] 5 fixed-partitions partitions found on MTD device 1f000000.cfi
Thu Feb 27 21:05:27 2020 kern.notice kernel: [    0.715977] Creating 5 MTD partitions on "1f000000.cfi":
Thu Feb 27 21:05:27 2020 kern.notice kernel: [    0.726789] 0x000000000000-0x000000030000 : "u-boot"
Thu Feb 27 21:05:27 2020 kern.notice kernel: [    0.739251] 0x000000030000-0x000000040000 : "u-boot-env"
Thu Feb 27 21:05:27 2020 kern.notice kernel: [    0.752310] 0x000000040000-0x000000050000 : "factory"
Thu Feb 27 21:05:27 2020 kern.notice kernel: [    0.764781] 0x0000003e0000-0x000000400000 : "cimage"
Thu Feb 27 21:05:27 2020 kern.notice kernel: [    0.777068] 0x000000050000-0x0000003e0000 : "firmware"
Thu Feb 27 21:05:27 2020 kern.notice kernel: [    0.801261] 2 edimax-fw partitions found on MTD device firmware
Thu Feb 27 21:05:27 2020 kern.notice kernel: [    0.813358] Creating 2 MTD partitions on "firmware":
Thu Feb 27 21:05:27 2020 kern.notice kernel: [    0.823502] 0x000000000000-0x00000014864d : "kernel"
Thu Feb 27 21:05:27 2020 kern.notice kernel: [    0.835926] 0x00000014864d-0x000000390000 : "rootfs"
Thu Feb 27 21:05:27 2020 kern.notice kernel: [    0.848296] mtd: device 6 (rootfs) set to be root filesystem
Thu Feb 27 21:05:27 2020 kern.notice kernel: [    0.859931] 1 squashfs-split partitions found on MTD device rootfs
Thu Feb 27 21:05:27 2020 kern.notice kernel: [    0.872509] 0x000000370000-0x000000390000 : "rootfs_data"

I suppose the flash area spans to 0x3fffff on a 4MiB device, but the rootfs partition only spans to 0x390000, leaving exactly 2 erase blocks for jffs2 (which is not enough as I have learned). What about the range between 0x390000 and 0x3fffff? I'm missing out on 576KiB of jfffs2 storage which would be more than enough for my intended application.

In expectation of a smaller image size I also tested the latest version from the 18 branch (18.06.7). But because the kernel is much bigger there, the rootfs partition even spans to 0x3e0000, with the rootfs_data partition also being only 2 erase blocks in size (0x20000).
I think this kind of supports my assumption that the rootfs_data partition is only two erase blocks in size, regardless of how much flash storage is available.

I tried executing firstboot, but that changes nothing.

The problem may have come from me installing the initramfs image at first, but I have installed several sysupgrade images afterwards.

How can I enlarge the rootfs partition to fill the available space?

[hnyman]

It is defined in the DTS to span only to 390000:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ramips/dts/rt3050_edimax_3g-6200n.dts;h=38598122178f4fbcf6b35e53c4d79af97fd44f65;hb=24ded1810b071ec7e7c8d134e5491d9649c13dac#l19

No idea why, but possibly there has originally been a reason.
You might try to find it in the history of your device:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=history;f=target/linux/ramips/dts/3G-6200N.dts;hb=6a104ac77206158c593cc7572c46eca6d3f4717f

Possibly there is something OEM stuff or so, in the last few bytes.

In any case, buy a better replacement with 10 EUR or so, as 4/32 is pretty much depreacted. (the 32 MB RAM is the hard limit, not the 4 MB flash)

[soulsearchingsun83]

Thank you for the explanation.
There has been a cimage partition at the end of the flash at 0x3e0000. It has been removed for the v19 branch. I didn't look into the details why.

No idea why the partition firmware ends early at 0x390000.
Also, I'm not sure why the firmware partition spans to 0x3e0000 in my v18.06.7 when it should span to 0x390000 when I look at the dts file for that version.

I acknowledge your recommendation, but I will continue to try for some time to get it to work because I spent too much on IT equipment already and don't think I can find something worth buying for only ten euros. I keep learning on the way, so all is not lost.

[soulsearchingsun83]

This is a follow up, not containing any new questions, but my findings so far.

So it seems I have been confused.

1. There is a "cimage" partition at the end of the flash with a size of 128 kiB, from 0x3e0000 to 0x3fffff:

Thu Feb 27 21:05:27 2020 kern.notice kernel: [    0.764781] 0x0000003e0000-0x000000400000 : "cimage"

I must have missed it because it is mounted rather at the beginning, as mtd3.
To whether is partition is strictly necessary for the soc / wifi or not I'm not sure, as it contains mostly zeros, some repeating patterns and some data that does look to me like it might not be required by the soc, but rather some constants for the manufacurer's firmware, e.g. strings like "admin", "1234", "hsdpa", "dyndns".
Maybe, if I'm feeling adventurous, I will overwrite parts or all of it and see if the device still boots and wifi still works. Not sure yet.

As to why the "rootfs" (and "rootfs_data") partitions only span to 0x390000 instead of 0x3e0000 in 19.07, this has also been an oversight on my end. The output of logread on 18.06 shows absolute addresses for nested partitions, whereas the output on 19.07 shows relative addresses. Because the partition "firmware" starts at 0x50000, this makes the difference between 0x390000 and 0x3e0000.
In absolute adresses, the "rootfs" partitions end at 0x3e0000 in both tested versions.
18.06:

Wed Jan 29 16:06:13 2020 kern.notice kernel: [    0.765852] 0x000000050000-0x0000003e0000 : "firmware"
Wed Jan 29 16:06:13 2020 kern.notice kernel: [    0.789660] 2 edimax-fw partitions found on MTD device firmware
Wed Jan 29 16:06:13 2020 kern.notice kernel: [    0.801790] 0x000000050000-0x0000001a1e20 : "kernel"
Wed Jan 29 16:06:13 2020 kern.notice kernel: [    0.814188] 0x0000001a1e20-0x0000003e0000 : "rootfs"

19.07:

Thu Feb 27 21:05:27 2020 kern.notice kernel: [    0.777068] 0x000000050000-0x0000003e0000 : "firmware"
Thu Feb 27 21:05:27 2020 kern.notice kernel: [    0.801261] 2 edimax-fw partitions found on MTD device firmware
Thu Feb 27 21:05:27 2020 kern.notice kernel: [    0.813358] Creating 2 MTD partitions on "firmware":
Thu Feb 27 21:05:27 2020 kern.notice kernel: [    0.823502] 0x000000000000-0x00000014864d : "kernel"
Thu Feb 27 21:05:27 2020 kern.notice kernel: [    0.835926] 0x00000014864d-0x000000390000 : "rootfs"

Effectively, I solved the problem now by building from source (branch openwrt-19.07), without "luci".
Kernel size went down slightly, from 0x14864d or 1314 kiB to 0x1382f1 or 1249 kiB, this could be because of changes in the sources.
Rootfs size went down to 1824 kiB, leaving 9 blocks or 576 kiB for the jffs2 partition, where currently 320 kiB are available, after doing my configuration, so currently things are looking good for 4/32.