ezplanet:

There is a patch to increase the ubi partition to 128MB.
The patch was never pushed to mainstream because it overwrites the caldata_backup partition.

At your own risk you can:

1. apply the patch and build your own firmware
2. copy caldata (/dev/mtdblock2) to the new caldata_backup (/dev/mtdblock10) using dd
   or alternatively save /dev/mtdblock10 using dd and restore after having flashed the new firmware with the new flash map.

Please see the patch attached.
cd into trunk and apply using patch -p1 < wndr3700-memory.patch

arjendekorte:

Note that this patch will break the WNDR4300v1 and also will make it much harder to revert back to Netgear stock firmware.

A better way to make use of the 96 MB unused NAND space, would be to mount the unused MTD partition as a separate partition.

ezplanet:

@arjendekorte :

I do not have a 4300, in what way does it break it? I understood 3700v4 and 4300v1 firmware and flash maps were the same.

I assume that to revert back to Netgear firmware you would have to re-flash a firmware with the original memory map and restore caldata_backup using dd first. I have not done it (I would not ever want to revert to Netgear firmware ...), but technically it isn't difficult.

arjendekorte:

The 4300v1 will be soft-bricked after this patch is applied. So although the hardware is similar, there appears to be a difference in the bootcode (in NOR flash) and it will fail to boot if the caldata-backup can't be found in the location it expects it to be in.

Given the fact that the router also has a USB port, I doubt it is really worth the effort to attempt to use the unused 96 MB.

ezplanet:

Would it be possible to create a separate alternative configuration for WNDR3700v4 that changes flash mapping? In the section there can be a warning and instruction to copy caldata_backup the first time the new firmware is flashed.

This would save those like me who already use the new flash map having to apply the patch to every git update.

The USB does not help if we want to build a firmware with lots of native linux tools and packages.

arjendekorte:

I doubt this would be worthwhile. It has been mentioned before (also in earlier incantations of this discussion) that the patch as-is is not the right way to do this. You really shouldn't mess with the existing partitioning of the NAND flash. Either mount the unused 96 MB partition in a separate mountpoint, or use mtd split to concatenate two (or more) partitions.

Although I'm not in the position to veto a separate package (per your request), I think one should always be able to revert to stock firmware with minimal effort (and knowledge). Copying a caldata-backup to a different location is for sure much more than you can expect from a newbie and (see above) not absolutely necessary. Most people won't need the additional storage.

ezplanet:

@arjendekorte

I applied the patch above to every build of openwrt and now LEDE since 2014 and I have not had any problems. However if you believe the patch is not perfect, then please propose an alternative that provides the same result which gives the maximum space to the firmware partition. If using the separate partition as you propose had been acceptable we would not have this long standing request (since the OpenWRT times) and we would not be having this conversation.

I hope that you guys will be open to listen to our requests. OpenWRT and LEDE aren't really for newbies. One can always add a separate configuration with plenty of warnings and instructions to copy the caldata. If the configuration is made available just for custom firmware builds, somebody who can build his own firmware can also repartition and copy the caldata in one direction and he can follow the reverse path too.

Reverting to stock firmware is a VERY, VERY VERY LOW priority. Personally, I never had the need to do it. Even if I resell the router, in general, it fetches more money with OpenWRT or LEDE pre-installed.

To summarize: we would like an alternative WNDR3700v4 configuration that includes the flash remap. This configuration should be made available in the source tree for custom build only and no firmware with this configuration should be built and released as pre-built binary.

This would help with not having to re-apply the patch every time we do a git update. It will also help with not having to chase other changes applied to

target/linux/ar71xx/image/legacy.mk

or any other re-organization of the configuration files.

arjendekorte:

I'm not interested in this at all, for me there is no point in attempting to use the 96 MB partition if I can add any amount of non-volatile memory by just inserting a flash drive.

I understand that you feel differently about that (and that's OK). But looking at the lack of progress, the active developers don't seem to give this much priority. In the FOSS world, that means that either you or someone else should create a patch that provides the requested function and (in case of LEDE). If the patch looks sane, it might get included.

Reiterating a request usually doesn't really speed things up.

Cutepally:

[[https://wiki.openwrt.org/doc/howto/extroot#chaos_calmer|https://wiki.openwrt.org/doc/howto/extroot#chaos_calmer]] for now, i guess this is the best (and only-without patching) way to get more storage on /overlay because mounting /dev/mtdblock11 will let you use the 96mb but not on overlayfs:/overlay even if you mount it to /overlay (which appears to work but it actually doesnt)

question: is there anyway to get fstab to mount /dev/mtdblock11 (as device) to /overlay (target) like [[https://wiki.openwrt.org/doc/howto/extroot#accessing_original_root|https://wiki.openwrt.org/doc/howto/extroot#accessing_original_root]] shows? i've tried the same method but it's not working. fstype in fstab is set to jffs2 like this:

config mount
	option target	'/overlay'
	option device	'/dev/mtdblock11'
	option fstype	'jffs2'
	option options	'rw,sync'
	option enabled	'1'

but this is not working to mount /dev/mtdblock11 to /overlay (properly)

also please ignore the image below: it was with /dev/mtdblock11 mounted as /overlay (with: umount /overlay ; sleep 5 ; mount -t jffs2 /dev/mtdblock11 /overlay) this does not actually work. it only appears to work but overlayfs:/overlay is not the same as /overlay when its done this way.

Panderine:

I have this issue with my WNDR4300. Indeed AROKH's build of OpenWRT fixed this for me (with no noticeable issues so far). Since I have null experience on building my own image and patching (besides defeating the purpose of running stable releases for me),how can I mount the missing partition in order to be able to install more software on my wnrd4300?

s7lx:

This issue is also on Netgear R6100.
I resolve it by myself with Imagebuilder.

Cutepally:

@matias this is the only way to get more storage on /overlay (without compiling the image yourself to unrevert the reverted patch): add the usb to mount on /overlay with fstab [[https://wiki.openwrt.org/doc/howto/extroot#chaos_calmer|https://wiki.openwrt.org/doc/howto/extroot#chaos_calmer]]

the other way to do it by compiling, would be as normal but with this change: *also note this file path actually changed recently in trunk, i dont recall the original path but this is the newer one
(source/target/linux/ar71xx/image/legacy.mk)
-wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata)ro,512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),23552k(ubi),25600k@0x6c0000(firmware),256k(caldata_backup),-(reserved)
+wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),120832k(ubi),122880k@0x6c0000(firmware),256k(caldata_backup),-(reserved)

i run this on my WNDR3700v4 without problems, this is the original patch [[https://dev.openwrt.org/changeset/48276|https://dev.openwrt.org/changeset/48276]] which was reverted later on in the trunk [[https://dev.openwrt.org/changeset/48456|https://dev.openwrt.org/changeset/48456]] which is the same thing i asked arokh to fix in his builds. well, un-unfix* heh :)

skyblaster:

An earlier reference (https://dev.openwrt.org/ticket/17316) uses the following patch:
-wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),23552k(ubi),25600k@0x6c0000(firmware),256k(caldata_backup),-(reserved)
+wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),121856k(ubi),123904k@0x6c0000(firmware),256k(caldata_backup),-(reserved)

I've been using this patch on my wndr3700v4 for quite some time without issue as well. The ubi size is slightly different than what @Simpy posted above so I'm wondering how these values are calculated and can they be validated?

It would certainly be convenient to have additional menuconfig/imagebuilder profile entries for those who don't ever care to return to stock. In this case it could be WNDR4300_EXPERIMENTAL

arjendekorte:

Better call it WNDR3700_EXPERIMENTAL then, because this patch when applied will softbrick a WNDR4300v1 device if you didn't copy the caldata_backup to the new location before.

Cutepally:

Linking the forum thread for more information for others. LEDE on WNDR3700v4 (available flash size): [[https://forum.lede-project.org/t/lede-on-wndr3700v4-available-flash-size/4130|https://forum.lede-project.org/t/lede-on-wndr3700v4-available-flash-size/4130]]

Kote:

I finally decided to patch and flash the image, but in my case for some reason through mtd it softbricked, but via tftp was fine.