The curious thing is the seemingly wasted (unused) space of MTD9, aside from providing a dual-boot partitioning and another 40 MiB gone with MTD6.
If the layout is flexible through DTB it might be a way to consider, make use of the wasted/unused MTD9 space and/or perhaps transform the device into the a single-boot device (80 MiB).
mtd4 / mtd6 - are basically the two partitions providing the dual boot failsafe mechanism. Preserving the flash layout, as defined in the DTS provided from upstream, allows reverting back to OEM.
Does the OEM code require all of the 40 MiB or can some be contributed to the OpenWrt installation?
What about the unused space of MTD9?
What about increasing the kernel partition from 3 MiB to 5 MiB and decreasing the rootfs partition proportionally?
Sooner than later the size limitation of 3 MiB will just not suffice any-more.
I assume that partition layout modification is a non-starter. dengqf6 bought a lot of kernel space during the 5.4 PR interation cycle by removing some unused FS modules; this was part of the (non)NEON target separation which fell by the wayside.
I'm not sure how anyone can currently build an image though. I have not been able to build since the last procd push due the_jail.c_ error, which neheb has apparently submitted a number of patches which are not being pushed to master.
i agree best to keep the mtd config as close to oem as possible.
the wrt1900v2 has the same mtd allocation, but a 6mB kernel with 3mB smaller (34mB) rootfs in the same 40mB mtd.
it would seem an acceptable tradeoff.
So, used one of neheb patches to allow build to finish and all wrtpac kernels are generated with room still available on the 2 3MB kernel partition devices:
@anomeome -
you have much greater facility than I do. your 3mB solutoin might be great.
i was suggesting that a 6mB kernel scheme had already been accomplished for the wrt1900ac V2, by splitting the 40mB partitions into 6 mB (kernel) = 34mB (rootfs)
see
No firmware of this world will fit into 40 milli Byte.
You should get used to using the correct multiplicators.
It does make a difference if you have 40 milli $ or 40 Mega $ on your bank account.
The problem here non technical here but political, OpenWRT maintainers do not want to split up the builds for mvebu, claiming that extra target will consume extra 10 MB disk space on the build servers, which they do not want mvebu to have, even though other targets do not get such scrutiny. As such until local politics changes nothing really could be done.
Why?
kernel+rootfs split has been modified for many devices e.g. in ipq806x R7800 and related.
Changing wrt32x DTS to have kernel+rootfs as 6+117 instead of 3+120 for both dual-boots should work, I think. The total size would still remain as 123 MB, so reverting back to OEM should be possible quite nicely.
(for wrt1900ac that would be 6+34 vs. 3+37, I think)
With ipq806x devices, the change broke the sysupgrade from older OpenWrt builds, and required using Netgear TFTP recovery flash to install the new version. (but flashing from OEM still works ok)
Looking for that kind of partition size modication solution might be easier than looking for a kernel contents change. But I think that Linksys does not provide quite that easy recovery flash tool, so jumping to modified kernel size might require flashing via OEM firmware, as it flashed in a single sweep, right? (for ipq806x the sysupgrade failed, as our sysupgrade script writes kernel and rotfs in two steps t the locations given in the currently running DTS, not the DTS in the new image. I haven't looked at the mvebu sysupgrade specifics, but I think that follows the same model.)
(Note that strangely the small 3 MB kernel size seems to also concern the new wrt32x, although the slightly older wrt3200acm already had 6 MB kernel space.)
I sincerely hope the next 'step' in mvebu support will move all kernels to a 6 MB size. it seems to me that the 3 MB size for wrt1900/wrt32x is based on history, as is the 6 MB size for wrt1900acs/wrt3200acm.
this is an opportunity to move these platforms closer togetherm not farther apart, as the current 'fix' has done (stop building for certain devices)
beyond the kernel size change to 6MB, why not take this opportunity to make better use of the unused mtd space in some of these devices?
all the u-boot knowledge has been documented previously by so many openwrt/lede router gurus-
esp 'intelliboy' and @lantis1008 https://forum.archive.openwrt.org/viewtopic.php?id=72095
I'm not the right person for the job.
While I was able to add support for the device by following similar devices and looking at the GPL, I don't have the understanding of the implications of expanding the kernel partitions differently to the OEM firmware.
Don't get me wrong, I can add and subtract numbers to figure out how a new DTS should look, but I don't know what it means for factory flashing, sysuograde and returning to stock.
yes - it might be a difficult return to stock if major changes to mtd map occurred. but would changing the kernel size + 3 and rootfs -3 MB make a difference?
as @hnyman suggests, this should not affect reverting?
i openly admit to not enough knowledge. it seems to me that either openwrt is dead to these devices, or the next jump makes some returns more difficult.
maybe the path should be:
from 19.X : revert to stock
from stock: new build which changes kernel size
then revert-to-stock from ech kernel-size branch woudl be required to swithc kernel sizes
the alternative might be to forgo revert-to-stock
im sure there are other paths forward - please?
and thank you
if only the OpenWrt partition layout is changed it should not impact the failsafe mode for the OEM partition.
The developer though does not seem inclined to consider this an opportunity to increase the OpenWrt kernel partition space to a more future proof size as it could inconvenience device users (sysupgrde).