Netgear R7800 exploration (IPQ8065, QCA9984)

Just to clarify also for others: TFTP flash is needed only once when you move into kernel 4.14 based firmwares. Sysupgrade works normally after that.

The “sysupgrade break” and forced TFTP flash usage is between these two groups:

  • kernel 4.4 or 4.9: 17.01, old master builds (<r7000), plus the quite earliest 18.06 builds
  • kernel 4.14: new master builds (>r7000), new 18.06 builds

You need TFTP flash once here, if you upgrade/downgrade from one group to the other group. Sysupgrade works normally inside each of those groups.

6 Likes

With build r7046 and "option flow_offloading 1" in /etc/config/firewall I'm seeing WAN speeds above 950Mbps, as with stock firmware. It maxed out at 600Mbps prior to 4.14. Thanks for all the work to get the project to this point!

3 Likes

My friend has a test,linux-4.9 with shortcut-fe,wan speed at 800Mbps,cpu idle is 10% and sirq is 87%.
is there somebody can test 4.14 with folwoffloading and watch cpu usage?

Now that I've used the master build for longer I think there may be a problem with multi-threaded downloads? Single-threaded downloads seem to be more or less consistent in terms of speed, but when there are several downloads happening at once the overall speed fluctuates between 50% and 100% of the maximum.

The most obvious manifestation of this is speedtest.net which performs several concurrent HTTP downloads for its tests. If I run several of these tests in a row (on a gigabit connection) about half of them will give ~500Mbps while about half will give >900Mbps. It's possible (e.g. with Chrome's Network tool) to identify one of the URLs that are downloaded during these tests and then repeatedly fetch it, and the speed remains fairly consistent (~900Mbps) between fetches.

This seems to happen whether flow offloading is enabled or disabled, although when it's disabled the speedtest.net results change between 300/600Mbps rather than 500/900Mbps as above. I'll see if I can work out any more about what's going on but I thought it was worth noting.

I can't seem to upgrade anymore.

I didn't notice the "sysupgrade break" and that's exactly what I did, from a snapshot build in the recent past (1-2 months ago) to the latest as of last week.

My router doesn't go into tftp mode. It seems like the "sysupgrade break" also broke the tftp bootloader.

Any suggestions?

How does one fix a router that has a broken bootloader?

That should not happen, as none of the Openwrt versions writes into the u-boot bootloader's flash area. So that should still be quite intact. You should still be able to trigger the TFTP mode manually.

Rather exact TFTP flash documentation is in the message 5 of this thread:

If you really can't trigger it, you need to attach a serial cable to see the serial console messages and try to figure out, what has happened.

The router doesn't ever go to the blinking white led. Just a solid white.

BTW, this is a more complete set of instructions for accessing the tftp bootloader from the wndr3800 days:
https://www.bufferbloat.net/projects/cerowrt/wiki/Cerowrt_flashing_instructions/

When my test sample unit got stuck upgrading to DD-WRT it showed blinking red for the tftp procedure oddly rather than the white it usually showed, it worked, so check for that.

Okay, I'll try tftping the firmware again. I get the blinking orange led when just turning it on normally.

IF my bootloader is toast because the tftp flash failed, is the only recourse to desolder the eeprom and flash that?

Good news!

For some reason on my router getting it into tftp mode was not straightforward.

I think that what I did was start the router with the reset button depressed and after the orange light started blinking I let go and it then changed into the white blinking led and was successfully put into tftp mode!

uploaded and flashed and good to go!

I don't know why what happened before did, but luckily this time isn't the time I learn how to desolder and flash eeproms :slight_smile:

2 Likes

now thanks to the obligatory tftp update process, it’s the time to make use of 70 MB “Netgear” partition to increase the ca. ~20MB flash currently available.
doing this we had much more flash space on R7800 for software.
r7800%20build

free%20space

1 Like

Disclaimer, I do not own this particular device, so I can't actually provide the answers to the questions raised.

Before removing this partition, you'd really need to find out what it contains and what it is needed for by the OEM firmware. In general LEDE tries really hard to keep the option of reverting to the OEM firmware without jumping through hoops, so this should be a goal for all changes.

Changing the split between kernel- and rootfs/ rootfs_data partition doesn't affect reverting to OEM, because they are right behind each other, their external boundaries don't change and every vendor firmware update replaces both partitions anyways - this means you can revert to the stock OEM firmware without any loss of data or functionality (you just need to flash the OEM firmware via tftp).

If the contents of the netgear partition were part of these OEM firmware upgrades, so tftp-flashing a OEM firmware would restore the contents of the netgear partition to a sufficient degree, the situation would be the same as before (so removing it for LEDE would be fine) - but that's something you'd have to investigate.

Another option would be if it were used as kind of a cache (e.g. for streamboost, dlna support, etc., so only containing volatile data) and which could be re-initialized by the OEM firmware's initscripts or tftp procedure (this would entail reformatting the partition in a compatible format and restoring the necessary directory structure). In this case removing the netgear partition for LEDE could be considered safe as well, as it wouldn't make reverting back to the OEM firmware any harder.

If neither of the options are available, the situation becomes a lot more difficult - yes, you can say that the user should backup the partition beforehand and keep said backup safe, so they can restore it manually (keep in mind, this would entail a two-step process including an intermediate reversal firmware) if they'd desire to revert to a OEM firmware, but… let's be honest, most users won't notice that requirement early enough - and even if they did, chances are that they'd lose their only backup (also think about second hand devices), which would make reverting impossible. Yes, there are devices where such an approach is needed (e.g. some of the ISP locked lantiq devices), but for those there is no other alternative (the OEM bootloader is locked/ signed and needs to be replaced for anything to happen, at the same time the SOC has a very robust recovery method of booting via serial, without any bootloader involvement), this can't really be said for the r7800 (17 MB for rootfs+overlay are less than expected from a 128 MB NAND flash, but it's still comfortable for many uses).

Disclaimer, I'm not a LEDE/ OpenWrt developer, so the opionions raised are my own and not those of the project.

There is no problem to go back to stock OEM.
Even transform R7800 in a Netgear XR500 DumaOS with
modded firmware it's no problem.
Always with tftp,It seemed obvious to me.

1 Like

"netgear" partition contains some saved data from OEM like SSIDs, passwords etc (quick look in hexeditor without mounting UBI long long time ago), moreover, next partition - "reserved" contains downloaded language files (maybe some else) so I think it also could be removed.
Personally run R7800 over 1.5 year without 'netgear' partition and don't need return to OEM, but (just in case) all mtds' binary backups are save :slight_smile:

I had a look inside the partition and found the same. It's mostly configuration files together with streamboost and genie stuff. I haven't yet checked whether removing the partition causes any problems with the OEM firmware.

In case anyone is interested here are the contents:

with tftp flash there's not any problem at all

Have you flashed OpenWrt with the partition removed and then flashed the OEM firmware while confirming that the netgear partition is recreated?

sure
even transform r7000 in Netgear XR500 wiith DumaOS is no problem with tftp flash

how many times I have to rewrite it :sweat:

Ok. I'll try to remove the partition as well when an opportunity to do so presents itself.

I built 18.06 from source and applied the image via tftp. After restoring my previous config, my wifi radios would not come up. 'ifconfig -a' and 'ip link' didn't show any WLAN interfaces. In LUCI, there was no way to set radio frequency, channel width, etc. I compiled the source to use the ath10k-ct driver. Could that be my problem? It worked in the previous 17.01 build.

Thanks.