Would saving/exporting/backup current settings and reloading them in 4.14 work?
Yes. So far there is no change in the actual settings. The change it is only about flash space allocation.
(But it is possible that at some point there will be a change in the hardware switch driver logic, and that would break the switch settings, preventing restoring them.)
ipq806x target (including R7800) in 18.06 was bumped into 4.14 a few minutes ago.
This means that the "sysupgrade break" and TFTP usage will move into between
- (17.01, old 18.06 builds, old master builds)
and - (new master builds, new 18.06 builds).
Thus my next 18.06 build will be with kernel 4.14 and the new kernel partition size.
There will be no new 17.01 builds unless some major fixes/changes happen there. But I expect 17.01 sources to be rather dormant.
EDIT:
owrt1806-r6984-fa0275bd90-20180524-TFTP-flash-kernel-4.14
first 18.06 build with kernel 4.14 (and flow offloading possibility)
1 Like
is reverting to stock still as easy as doing a tftp flash or should we manage the kernel partition separately?
thanks 
Should be.
TFTP flash in handled by u-boot, which is not touched by Openwrt, so the TFTP recovery flash will be able to flash quite normally either a Netgear OEM image or an Openwrt factory image.
Can anyone comment on the state of kernel 4.14 with the R7800 before I upgrade? It's been running well on WRT3200ACM builds, but over at DD-WRT, Kong builds avoid this kernel and have backported FastPath/SFE to 3.x. Has 4.14 made good progress? Looking forward to FastPath/SFE support at the very least, it's a huge performance improvement. Closer to stock firmware (which does hardware NAT).
Devs did not select SFE/fastpath, but chose kernel built-in flow offloading instead, so no point in looking for SFE/fastpath specifically.
But hard to understand why somebody has stayed with ancient 3.x, except for lack for resources to do a bump to 4.x. kernel 4 was released years ago.
For generic R7800 kernel 4.14 discussion, the r7800 exploration thread is a better place than this buildspecific thread.
DD-WRT has a ton of ancient stuff in it. Might be easier to stick to 3.x since they have so many targets running 3.x kernels. DD-WRT needs its own reboot (or at least a stable release!!).
1 Like
DD-WRT supports more targets and more proprietary stuff. They use 3.x kernels for space and compatibility reasons.
Nope! They use 3.X kernel because of broadcom... Only with 2018 april firmware broadcom switched to 4.1 kernel... All proprietary stuff is based on acient kernel and dd-wrt have equal performance to stock firmware because many times uses the same blob of the original firmware... This is the only reason they stay with that kernel.
1 Like
I flashed your build,as well as the build I built.Router booted ,the led is lighting ,but my computer cannot get a right ip ,and cannot ping 192.168.1.1.
Yea true DD-WRT is on an old 3.x kernel and 4.x released 3 years ago, but for what it's worth many Android phones still use 3.x kernel too, maybe because it's been stable for so long. Anyway, excuse the digression.
It's down to size. There's a thread on the kernel mailing list on BrainSlayer crying about I think kernel 3.10 having support cut. 3.16 was causing too much space bloat for DD-WRT.
He can and has ported Broadcom wifi drivers to newer kernels before since he has the source code under NDA.
There's something wrong with the master when doing TFTP flash. 192.168.1.1 is unreachable. The openwrt-18.06 one works though.
Maybe something has broken in master source, if your own build also has problems.
I TFTP flashed my own router earlier with master-r7016-52809db544-20180522-TFTP-flash-kernel-4.14 and that worked ok.
If that is consistent, then maybe something in master sources has changed. Looking at the changes in the last two days, there is one change affecting the initial network setup after flash / reset. That is my guess about a possible culprit. https://github.com/openwrt/openwrt/commit/85048a9c1fa4d37b5896d9237d28bbadbbe09d19 But that is just a hunch after quickly looking the commits between r7016-52809db544 and r7035-4da832e201
I sysupgraded yesterday to from r7016-52809db544-20180522 to r7035-4da832e201-20180524 without problems, so the main firmware itself is ok. But it might well be that the initial network setup is now screwed in master.
yesterday I flash your build which is 20180524,it's broken ether.
Yes that was my point. If TFTP flash with both my master 20180524 build and your own master build fails, but TFTP flash with new 18.06 succeeds and I succeeded two days ago with 20180522 master build, then something has possibly changed in master between 22th and 24th.
I will test TFTP flashing with new builds later tonight.
Looks like my hunch was right:
Likely the fix from jow has fixed master and the next master builds will again be ok for TFTP flashing.
The impact of this breakage is/was quite severe, I'll likely take down all factory and sysupgrade images produced in the last 24 hours as they'll most likely cause soft-bricks. Not sure if failsafe works in the broken state...
It doesn't, I also fell over it when testing ath79/ tl-wr1043nd-v1 and needed tftp recovery.