The problem seems to be that default installation uses only 20mb for ubifs, which is also crazy from the uniform wearing of the nand available to prolong its lifespan.
# ubinfo -a
UBI version: 1
Count of UBI devices: 1
UBI control device major/minor: 10:59
Present UBI devices: ubi0
ubi0
Volumes count: 2
Logical eraseblock size: 129024 bytes, 126.0 KiB
Total amount of logical eraseblocks: 167 (21547008 bytes, 20.5 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: 13
Minimum input/output unit size: 2048 bytes
Character device major/minor: 251:0
Present volumes: 0, 1
Volume ID: 0 (on ubi0)
Type: dynamic
Alignment: 1
Size: 28 LEBs (3612672 bytes, 3.4 MiB)
State: OK
Name: rootfs
Character device major/minor: 251:1
-----------------------------------
Volume ID: 1 (on ubi0)
Type: dynamic
Alignment: 1
Size: 115 LEBs (14837760 bytes, 14.1 MiB)
State: OK
Name: rootfs_data
Character device major/minor: 251:2
What should I do to take advantage of all, or at least a couple of MB more of the nand flash?
I'm not really sure if the mtd layout is defined by the hardware or whether this is part of the device tree specification.
Linux version 4.14.171 (builder@buildhost) (gcc version 7.5.0 (OpenWrt GCC 7.5.0 r10947-65030d81f3)) #0 Thu Feb 27 21:05:12 2020
Just for the record, I've went ahead and flashed factory image openwrt-19.07.3-apm821xx-nand-netgear_wndr4700-squashfs-factory.img to validate it could re-build mtd or something from scratch, no luck
It seems current snapshot is broken for this HW, since once flashed it keeps boot looping. No broadcast message, no safe booting message, nothing, just plain dead.
Usually the person porting OpenWrt takes care not to wipe partitions that might break reverting back to stock firmware. To the untrained eye, that looks like a lot of 'wasted' space. Not all of that space can simply be freed up to install OpenWrt. On top of that, NAND space is usually more generous to compensate for the fact they wear out quicker than NOR.
It looks like you got 20 MiB, I'd say that's plenty for even a loaded OpenWrt image. No idea what you're trying to do. Maybe look into extroot (or, if you want to do non-router stuff, to an ARM SBC that allows you more, replaceable, internal storage).
Gotcha!
Particularly on my case, I don't plan to go back to the original firmware so makes no sense for me to leave that much juice storage laying around.
Particularly on my case, I just need a couple of megabytes more to accomplish fully the routers functionality.
Using extroot and adding an extra dependency on another device that could fail, while being able to use existing one, is a last option.
I've checked out master git repo and seems to be broken for my device, it just keeps bootlooping, so I'm now trying to switch the mtd device to a larger one, but looks too nasty.
I'm trying to switch the dtb for this device, in order to use instead another partition that has a large 96MB config, supposedly for the original factory firmware.
I'm not sure what "pot" does but it probably is only relevant to stock firmware. Before re-partitioning of course have backups of all the stock partitions.
So you could expand "ubi" up to the end of the present "ecos" which would also swallow up all the little partitions in between. There would be one big ubi and no config, pot, ecos, etc.
On first boot the rootfs_data fs will be formatted to use all the space.
Ok, so just for any casual internet sailer, I rebuilt 19.07.3 release, since snapshot seems to be currently broken and produces the device to bootloop.
Having performed a dump from factory NAND data, which mostly was padded btw, this is the working champion config that allowed me to re-gain 120MB instead of 20MB from current Linux kernel device tree config.