[buildbot - mvebu / cortexa9] snapshots stopped?

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)

For reference R7800:
https://github.com/openwrt/openwrt/commit/dc50694bd1a8f81b40c185bc8cacbdc8e821a3c6

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.)

1 Like

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

been mentioned


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).

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.