[R7800] Will no longer save settings after reboot.
- Thread starter Redbot
- Start date
kamoj
Very Senior Member
I don't know.
It's up to Netgear how it is implemented.
It should really never be reset of course!
From a very informative site:
http://www.linux-mtd.infradead.org/doc/ubi.html#L_usptools
"It is important not to lose the erase counters, which means the tools you use to erase the flash and to write the UBI images have to be UBI-aware.
The mtd-utils repository contains the ubiformat utility which does things properly."
What are your counters?
It's up to Netgear how it is implemented.
It should really never be reset of course!
From a very informative site:
http://www.linux-mtd.infradead.org/doc/ubi.html#L_usptools
"It is important not to lose the erase counters, which means the tools you use to erase the flash and to write the UBI images have to be UBI-aware.
The mtd-utils repository contains the ubiformat utility which does things properly."
What are your counters?
HELLO_wORLD
Very Senior Member
Finally received the RMA yesterday, and was able to set ip up today.
NAND of router that started to cause problems: MX30UF1G18AC
NAND of the one I received with RMA procedure: MX30UF1G18AC
(Added `dmesg > /tmp/DMESG_INIT.log` in /etc/init.d/boot).
So it is the same chip... Hope it will be ok overtime... I have a 2 years warranty, so hopefully, if it is the chip, it will happen again before that.
The SSD and USB3 connector cable for it are working great. Entware and swap are on. PS: to install Entware, I had to mkdir /opt first.
I am not installing kamoj addon yet. I will wait for stable release, and see if I can somehow install to USB.
I should receive the fan cooler that goes under the router today.
NAND of router that started to cause problems: MX30UF1G18AC
NAND of the one I received with RMA procedure: MX30UF1G18AC
(Added `dmesg > /tmp/DMESG_INIT.log` in /etc/init.d/boot).
So it is the same chip... Hope it will be ok overtime... I have a 2 years warranty, so hopefully, if it is the chip, it will happen again before that.
The SSD and USB3 connector cable for it are working great. Entware and swap are on. PS: to install Entware, I had to mkdir /opt first.
I am not installing kamoj addon yet. I will wait for stable release, and see if I can somehow install to USB.
I should receive the fan cooler that goes under the router today.
Every additional detail is helpful--one only sees the big picture with a jigsaw puzzle after all the individual pieces are assembled...
What is interesting is that @Redbot, who started this thread, mentioned the potential issue of DST because that is about when his router first displayed this issue starting about 2.5 weeks ago. I remember reading one of your posts where you pointed out that prior to 74.4SF, your R7800 always passed the Shields Up All Service Ports Test, but now it does not if DST and Traffic Meter enabled. So who knows, somehow they may be linked? If so, I speculate that they are not causal, and instead symptomatic of another issue--potentially, a hardware one.
Oh, great, is that the standard length of a warranty in Europe--if so, fantastic! I am in the US, and they did not reset my warranty for the RMA swap replacement they sent, unfortunately.
There is some progress on this front--Voxel has confirmed that yes, persistent settings are stored on the mtd11 partition of the NAND flash chip under official Netgear/Voxel firmware. That partition has a finite, fixed location that does not normally change. The flash layout for OpenWRT is significantly different than that used by official Netgear/Voxel firmware.
So if we suppose one uses a particular firmware first, and "wears out" a certain segment of the flash chip storage*, a different firmware with a different flash layout map may not use that same "worn out" segment of flash chip, and thus, it might function correctly. Of course, this would not be on purpose--it is just a function of using different flash layouts because any/all firmwares suppose the whole NAND chip is functional. And when the different firmware does eventually access the "worn out" location, it would run into the same issues.
* All this said, the folks running R7800s for years without this issue have Micron-brand NAND chips in their routers. And the folks who have experienced this issue, and have been able to identify the manufacturer of the flash chip in their R7800s report it to be Macronix. Note that these are only based on three and two data points, respectively!!! So the more we get, the better!!! But the point is that flash chips should not wear out so quickly--it seems likely that this is a defective batch. And that it was probably not just used in R7800s, but other Netgear routers, too.
HELLO_wORLD
Very Senior Member
Yes, it is the standard warranty in Europe. I bought it on Amazon without any special warranty extension. On the phone for the RMA procedure, the person told me I had a 2 years warranty.
For those who would be willing to help figure out whether this loss of settings issue can be related to one NAND chip manufacturer or another, and who do not have @kamoj's latest beta add-on installed, here is some more finite guidance about how to temporarily alter your /etc/init.d/boot script to get at this information. @HELLO_wORLD had success by adding a dmesg call right at the beginning of the start() function in the /etc/init.d/boot script as per below.
And then after boot, /tmp/DMESG_INIT.log should be waiting for you, and you can grep through it to find the details, i.e. "grep -i nand /tmp/DMESG_INIT.log".
Note that I have seen reference to yet a third type of NAND flash used in the R7800--the AMD/Spansion S34MS01G2 chip--and it would not be surprising if there were even more, too.
-------------------
Just an update, but somebody with an older R7800 that has used it for a couple of years without an issue has reported this S34MS01G2 chip. I called it AMD/Spansion-brand above, but it was pointed out that the brand might instead be called SkyHigh Memory (a joint-venture between Cypress Semiconductor and SK Hynix). But yeah, it is still the third NAND flash chip we know about.
So far with the limited data points we have, the older R7800s with either Micron- or SkyHigh-brand NAND chips are have not experienced this problem. Only the newer R7800s with Macronix-brand chips have experienced the issue. But more data is needed!!!
Code:
...
START=10
STOP=98
start() {
dmesg > /tmp/DMESG_INIT.log
local commit_flag=0
[ -f /proc/mounts ] || /sbin/mount_root
...And then after boot, /tmp/DMESG_INIT.log should be waiting for you, and you can grep through it to find the details, i.e. "grep -i nand /tmp/DMESG_INIT.log".
Note that I have seen reference to yet a third type of NAND flash used in the R7800--the AMD/Spansion S34MS01G2 chip--and it would not be surprising if there were even more, too.
-------------------
Just an update, but somebody with an older R7800 that has used it for a couple of years without an issue has reported this S34MS01G2 chip. I called it AMD/Spansion-brand above, but it was pointed out that the brand might instead be called SkyHigh Memory (a joint-venture between Cypress Semiconductor and SK Hynix). But yeah, it is still the third NAND flash chip we know about.
So far with the limited data points we have, the older R7800s with either Micron- or SkyHigh-brand NAND chips are have not experienced this problem. Only the newer R7800s with Macronix-brand chips have experienced the issue. But more data is needed!!!
Last edited:
microchip
Very Senior Member
According to kamoj addon, Critical Max is 75°C for the router
So I have been able to do the testing I mentioned, and here are the details.
If you want the TL;DR version, know that if your R7800 is experiencing the "loss of settings on power cycle or reboot" issue while running official Netgear or Voxel firmwares, you MAY (not guaranteed) be able to return to a functional device that actually preserves settings on a reboot or power cycle if you flash a different firmware like OpenWRT. This has nothing to do with official Netgear or Voxel firmwares being defective--instead, I speculate that it has everything to do with the fact that the NAND flash chip in some units is not robust, and it is easily "worn out" or damaged. And since OpenWRT uses a very different flash layout map versus the official Netgear and Voxel firmwares, it is able to preserve settings across a reboot or power cycle because it stores its configuration data on a different physical segment of the flash chip that is not yet damaged. In the long run, note that this is all complete speculation on my part--I am definitely not an expert, just an observer. So while the interpretation seem to fit the observations, I am happy for an expert to step up, and set this all straight!!!
If you want more details, keep reading...
-------------------------------------------------------------------------
Briefly to recap, my R7800 is afflicted with the "loss of settings on power cycle or reboot" issue. This appears to be a hardware problem--that the area of the flash chip used to store settings and configuration gets "worn out" prematurely or becomes defective electronically due to something like a power loss or fluctuation. This is NOT normal--there are reports of many r7800s running successfully for years despite hundreds of flashings and real life foibles like power anomalies. These older, more robust R7800s appear to use Micron- and SkyHigh-brand NAND flash chips. But the ones experiencing this loss of settings issue appear to be using Macronix-brand NAND flash chips. At this point, it is not clear if this affects all Macronix-brand flash chips--it may simply be that there was a less robust batch of Macronix NAND that made it into production, and so this only affects a limited number of routers.
With this interpretation of the issue being hardware-related, there was initial speculation that it would affect all R7800s firmwares equally. But after experiencing the issue while running Voxel's latest v1.0.2.75.2SF firmware, I was surprised to see that when I flashed the router with OpenWRT instead, it did not have this problem. It worked normally, and I was able to reboot or cycle the power without losing settings.
This led to the additional speculation that despite the issue likely being hardware-based, it might not actually affect all firmwares as initially expected. This is because the flash layout map between different firmwares can differ significantly. The flash layout maps for official Netgear and Voxel firmwares are identical, which makes sense as Voxel uses the official firmware as a base. But the flash layout map of OpenWRT is significantly different. So the thought is that an OpenWRT installation does not necessarily access the same "worn out" or electronically defective area of the flash chip that official Netgear/Voxel firmware uses.
To provide supporting evidence for this assertion, I flashed three official Netgear firmwares to my R7800 last night to make observations. I tried the latest published one (v1.0.2.68), the version that came installed from factory when I received this R7800 (v1.0.2.62), and the oldest published firmware I could find (v1.0.0.20). The reason for attempting the oldest published firmware that I could find was for more than just kicks and giggles--I explain this below in the discussion of flash layout maps.
For all three official Netgear firmwares, I installed them via the tftp method. After firmware installation, I then did factory resets to give them a fresh start (by holding the reset button for 7+ seconds while the router was on). Under all three firmwares, I experimented by making basic configuration changes, then used the power button to shut the router off, wait two seconds, and then turn it back on again. In all cases, the simple configuration changes that I made were lost, indeed, when I browsed to 192.168.1.1 where one would expect to find the web GUI, instead, I was greeted with the "Netgear Service Terms and Conditions" page to begin the setup process again. The only exception was the earliest router firmware (v1.0.0.20), which does not force this service terms and conditions setup routine, and thus, it let me arrive to the web GUI directly. But the settings were still lost under that firmware as well due to the power cycle.
For good measure, I reflashed OpenWRT, and was once again able to reboot and power cycle without a loss of settings. Indeed, I was able to quickly reload an OpenWRT configuration backup file with all my customizations so I would not have to type them in again by hand, and it worked!
The above provides pretty good evidence of SOMETHING, and one way to interpret this SOMETHING is that the area of the flash chip used by official Netgear firmware to store settings and configuration data is damaged, i.e. either "worn out" or defective electronically. And since OpenWRT has a significantly different flash layout map, it stores its data in a physically different segment/partition of the flash chip that is still functional. Thus, it (OpenWRT) is able to retain its settings for now, but if it were to ever access the same physical portion of the flash chip that is either "worn out" or defective electronically, well, it would have the same issue as well.
There are two potentially interesting implications for this explanation if it indeed is correct, and quite frankly, this is whole reason I have written up this extended discussion. Let me stress that this all conjecture now, but at least it seems to well fit the observations that have been made. In particular, the implications may be helpful for folks whose R7800s are afflicted with the "loss of settings on power cycle or reboot" issue, and that are no longer covered by warranty for an RMA exchange. Here they are:
1.) Flashing an alternative firmware like OpenWRT may allow these folks to return their R7800 to basic functionality as the settings may no longer get vaporized on a reboot or power cycle. Woo-hoo, and great, right??? The detraction is that OpenWRT is, for sure, not quite as simple and easy to use as Voxel's firmware. So there would be a steeper learning curve. The other thing to keep in mind is that if some physical portion of the flash chip is indeed bad, if an R7800 running OpenWRT ever tries to access that portion of the chip, it will have the same problem as any other firmware.
2.) There is still free space on the 128MB NAND flash chip--Voxel's firmware does not fill it up completely. So it might be possible to arrange the flash layout maps to put the configuration partition (mtd11--more about this below) in a different physical location on the flash chip that is not damaged. So one could still run Voxel's firmware, but it would be a special version that uses a custom flash layout.
The only way to figure out if the above implications are valid is to actually try them out. For most people whose routers are suffering from this affliction, it would probably be easy enough to test out implication #1. If OpenWRT allows your router to return to functionality, great! But yeah, you will have a steeper learning curve with OpenWRT. Testing out implication #2 is harder--I suspect it would require a pretty significant effort on Voxel's part to adjust his firmware such that it uses a different flash layout map (maybe not?). But he probably does not have time for this, and he probably has a lot of good reasons for NOT wanting to do it anyways. But who knows...
Final point is about flash layout maps because I have seen something rather puzzling with the official Netgear firmware. But I think it is puzzling only because I have no real experience or expertise on this front--I am just making observations. Anyway, in each of three official Netgear firmware installs, I enabled telnet so I could see the flash layout that was being used ("cat /proc/mtd"). All three returned identical results as per below:
The sizes of the mtdXX partitions are given in hexadecimal values. But if you hex2dec them to turn them into decimal bytes, you come up with a total sum of 231,301,120 bytes (this is exactly 220MB). As a novice with no experience, this seems puzzling to me as the NAND chip in the R7800 is only 128MB in size, i.e. 134,217,728 bytes. So how can official Netgear firmware have a map that spans 220MB in size when the actual capacity of the NAND chip is only 128MB??? Maybe they are using some type of on-the-fly compression/decompression like the old SoftRAM and RAM Doubler products of MS-DOS and Windows 95 days??? This does not make sense to me, but again, I have no expertise in this whatsoever, and I am only making observations.
If you want the TL;DR version, know that if your R7800 is experiencing the "loss of settings on power cycle or reboot" issue while running official Netgear or Voxel firmwares, you MAY (not guaranteed) be able to return to a functional device that actually preserves settings on a reboot or power cycle if you flash a different firmware like OpenWRT. This has nothing to do with official Netgear or Voxel firmwares being defective--instead, I speculate that it has everything to do with the fact that the NAND flash chip in some units is not robust, and it is easily "worn out" or damaged. And since OpenWRT uses a very different flash layout map versus the official Netgear and Voxel firmwares, it is able to preserve settings across a reboot or power cycle because it stores its configuration data on a different physical segment of the flash chip that is not yet damaged. In the long run, note that this is all complete speculation on my part--I am definitely not an expert, just an observer. So while the interpretation seem to fit the observations, I am happy for an expert to step up, and set this all straight!!!
If you want more details, keep reading...
-------------------------------------------------------------------------
Briefly to recap, my R7800 is afflicted with the "loss of settings on power cycle or reboot" issue. This appears to be a hardware problem--that the area of the flash chip used to store settings and configuration gets "worn out" prematurely or becomes defective electronically due to something like a power loss or fluctuation. This is NOT normal--there are reports of many r7800s running successfully for years despite hundreds of flashings and real life foibles like power anomalies. These older, more robust R7800s appear to use Micron- and SkyHigh-brand NAND flash chips. But the ones experiencing this loss of settings issue appear to be using Macronix-brand NAND flash chips. At this point, it is not clear if this affects all Macronix-brand flash chips--it may simply be that there was a less robust batch of Macronix NAND that made it into production, and so this only affects a limited number of routers.
With this interpretation of the issue being hardware-related, there was initial speculation that it would affect all R7800s firmwares equally. But after experiencing the issue while running Voxel's latest v1.0.2.75.2SF firmware, I was surprised to see that when I flashed the router with OpenWRT instead, it did not have this problem. It worked normally, and I was able to reboot or cycle the power without losing settings.
This led to the additional speculation that despite the issue likely being hardware-based, it might not actually affect all firmwares as initially expected. This is because the flash layout map between different firmwares can differ significantly. The flash layout maps for official Netgear and Voxel firmwares are identical, which makes sense as Voxel uses the official firmware as a base. But the flash layout map of OpenWRT is significantly different. So the thought is that an OpenWRT installation does not necessarily access the same "worn out" or electronically defective area of the flash chip that official Netgear/Voxel firmware uses.
To provide supporting evidence for this assertion, I flashed three official Netgear firmwares to my R7800 last night to make observations. I tried the latest published one (v1.0.2.68), the version that came installed from factory when I received this R7800 (v1.0.2.62), and the oldest published firmware I could find (v1.0.0.20). The reason for attempting the oldest published firmware that I could find was for more than just kicks and giggles--I explain this below in the discussion of flash layout maps.
For all three official Netgear firmwares, I installed them via the tftp method. After firmware installation, I then did factory resets to give them a fresh start (by holding the reset button for 7+ seconds while the router was on). Under all three firmwares, I experimented by making basic configuration changes, then used the power button to shut the router off, wait two seconds, and then turn it back on again. In all cases, the simple configuration changes that I made were lost, indeed, when I browsed to 192.168.1.1 where one would expect to find the web GUI, instead, I was greeted with the "Netgear Service Terms and Conditions" page to begin the setup process again. The only exception was the earliest router firmware (v1.0.0.20), which does not force this service terms and conditions setup routine, and thus, it let me arrive to the web GUI directly. But the settings were still lost under that firmware as well due to the power cycle.
For good measure, I reflashed OpenWRT, and was once again able to reboot and power cycle without a loss of settings. Indeed, I was able to quickly reload an OpenWRT configuration backup file with all my customizations so I would not have to type them in again by hand, and it worked!
The above provides pretty good evidence of SOMETHING, and one way to interpret this SOMETHING is that the area of the flash chip used by official Netgear firmware to store settings and configuration data is damaged, i.e. either "worn out" or defective electronically. And since OpenWRT has a significantly different flash layout map, it stores its data in a physically different segment/partition of the flash chip that is still functional. Thus, it (OpenWRT) is able to retain its settings for now, but if it were to ever access the same physical portion of the flash chip that is either "worn out" or defective electronically, well, it would have the same issue as well.
There are two potentially interesting implications for this explanation if it indeed is correct, and quite frankly, this is whole reason I have written up this extended discussion. Let me stress that this all conjecture now, but at least it seems to well fit the observations that have been made. In particular, the implications may be helpful for folks whose R7800s are afflicted with the "loss of settings on power cycle or reboot" issue, and that are no longer covered by warranty for an RMA exchange. Here they are:
1.) Flashing an alternative firmware like OpenWRT may allow these folks to return their R7800 to basic functionality as the settings may no longer get vaporized on a reboot or power cycle. Woo-hoo, and great, right??? The detraction is that OpenWRT is, for sure, not quite as simple and easy to use as Voxel's firmware. So there would be a steeper learning curve. The other thing to keep in mind is that if some physical portion of the flash chip is indeed bad, if an R7800 running OpenWRT ever tries to access that portion of the chip, it will have the same problem as any other firmware.
2.) There is still free space on the 128MB NAND flash chip--Voxel's firmware does not fill it up completely. So it might be possible to arrange the flash layout maps to put the configuration partition (mtd11--more about this below) in a different physical location on the flash chip that is not damaged. So one could still run Voxel's firmware, but it would be a special version that uses a custom flash layout.
The only way to figure out if the above implications are valid is to actually try them out. For most people whose routers are suffering from this affliction, it would probably be easy enough to test out implication #1. If OpenWRT allows your router to return to functionality, great! But yeah, you will have a steeper learning curve with OpenWRT. Testing out implication #2 is harder--I suspect it would require a pretty significant effort on Voxel's part to adjust his firmware such that it uses a different flash layout map (maybe not?). But he probably does not have time for this, and he probably has a lot of good reasons for NOT wanting to do it anyways. But who knows...
Final point is about flash layout maps because I have seen something rather puzzling with the official Netgear firmware. But I think it is puzzling only because I have no real experience or expertise on this front--I am just making observations. Anyway, in each of three official Netgear firmware installs, I enabled telnet so I could see the flash layout that was being used ("cat /proc/mtd"). All three returned identical results as per below:
Code:
dev: size erasesize name
mtd0: 00c80000 00020000 "qcadata"
mtd1: 00500000 00020000 "APPSBL"
mtd2: 00080000 00020000 "APPSBLENV"
mtd3: 00140000 00020000 "ART"
mtd4: 00140000 00020000 "ART.bak"
mtd5: 00220000 00020000 "kernel"
mtd6: 01de0000 00020000 "rootfs"
mtd7: 04480000 00020000 "netgear"
mtd8: 02000000 00020000 "firmware"
mtd9: 00080000 00020000 "crashdump"
mtd10: 00380000 00020000 "language"
mtd11: 00120000 00020000 "config"
mtd12: 00120000 00020000 "pot"
mtd13: 00010000 00001000 "m25p80"
mtd14: 0001f000 0001f000 "cert"
mtd15: 0005d000 0001f000 "pot.bak"
mtd16: 001b2000 0001f000 "traffic_meter"
mtd17: 001b2000 0001f000 "traffic_meter.bak"
mtd18: 001b2000 0001f000 "dongle"
mtd19: 037b4000 0001f000 "overlay_volume"The sizes of the mtdXX partitions are given in hexadecimal values. But if you hex2dec them to turn them into decimal bytes, you come up with a total sum of 231,301,120 bytes (this is exactly 220MB). As a novice with no experience, this seems puzzling to me as the NAND chip in the R7800 is only 128MB in size, i.e. 134,217,728 bytes. So how can official Netgear firmware have a map that spans 220MB in size when the actual capacity of the NAND chip is only 128MB??? Maybe they are using some type of on-the-fly compression/decompression like the old SoftRAM and RAM Doubler products of MS-DOS and Windows 95 days??? This does not make sense to me, but again, I have no expertise in this whatsoever, and I am only making observations.
Sorry, I hit the 10K character limit for postings, ooops, so here is the remainder of the last post...
As a contrast to the above, the flash layout map from OpenWRT returns the following:
If you do the same hex2dec conversion and sum up the sizes, you end up with a grand total of 134,217,728 bytes, which is exactly 128MB, and which makes sense given that the NAND chip is 128MB in size.
In sum, the flash layout map for the official Netgear firmware seemingly specifies a total size of 220MB, whereas the NAND chip is only 128MB in size. For sure, I am not understanding something basic, and I am just adding the observation here because it arose when there was a question about whether router settings and configuration data were stored on the NAND flash chip, or elsewhere. For sure, they are stored on the NAND flash chip in the mtd11 partition.
Sorry for this long blurb, but hopefully, somebody in the know may be able to help out all those folks whose R7800s are no longer covered by their factory warranty!!!
As a contrast to the above, the flash layout map from OpenWRT returns the following:
Code:
dev: size erasesize name
mtd0: 00c80000 00020000 "qcadata"
mtd1: 00500000 00020000 "APPSBL"
mtd2: 00080000 00020000 "APPSBLENV"
mtd3: 00140000 00020000 "art"
mtd4: 00140000 00020000 "artbak"
mtd5: 00400000 00020000 "kernel"
mtd6: 06080000 00020000 "ubi"
mtd7: 00700000 00020000 "reserve"If you do the same hex2dec conversion and sum up the sizes, you end up with a grand total of 134,217,728 bytes, which is exactly 128MB, and which makes sense given that the NAND chip is 128MB in size.
In sum, the flash layout map for the official Netgear firmware seemingly specifies a total size of 220MB, whereas the NAND chip is only 128MB in size. For sure, I am not understanding something basic, and I am just adding the observation here because it arose when there was a question about whether router settings and configuration data were stored on the NAND flash chip, or elsewhere. For sure, they are stored on the NAND flash chip in the mtd11 partition.
Sorry for this long blurb, but hopefully, somebody in the know may be able to help out all those folks whose R7800s are no longer covered by their factory warranty!!!
@verbage
Why are you limiting your analysis to the 128 MB flash memory? The @kamoj addon shows that there is also RAM, Disk and NVRAM. See the image attached to my post: https://www.snbforums.com/threads/r...ettings-after-reboot.62773/page-5#post-566257 I don't know the functions of each (hopefully @kamoj can explain). Are RAM, Disk and NVRAM subsets of flash memory, or are they separate?
@kamoj wrote that he has some code which can be used to save and restore NVRAM early in the boot process. See https://www.snbforums.com/threads/r...ettings-after-reboot.62773/page-3#post-565540 I therefore assumed that settings are saved in NVRAM. My assumption is consistent with the command described in the next paragraph.
Are your cfg settings not being saved, or perhaps there is a glitch in the boot process that is causing them to be erased (or ignored)? Assuming that the cfg settings are stored in NVRAM, you can determine when they were last saved with the command: date -d $(nvram get config_timestamp) -D '%s' "+%F %T" I suggest that you run this command after you have saved (and backed up; I am making the assumption that the backup works correctly and actually correctly saves the settings, and not a virgin settings file) your settings. Get the date and time. Now power cycle the router. I assume that your settings will be lost. Without reconfiguring the router, telnet in and run the command again. Have the date and time changed? Backup the settings again (prior to configuring anything), and compare them with your baseline saved settings. Are the files the same or different? If they are the same, either your settings were never saved in the first place, or your saved settings are still there, but they aren't being recognized upon boot. If they are different, perhaps something in the aftermath of the power cycle caused the original settings to be erased.
In the absence of knowledge of the architecture here, it is impossible for me to suggest solutions. But I am hopeful that @kamoj might be able to help us craft a solution via a light edit of the boot script.
Why are you limiting your analysis to the 128 MB flash memory? The @kamoj addon shows that there is also RAM, Disk and NVRAM. See the image attached to my post: https://www.snbforums.com/threads/r...ettings-after-reboot.62773/page-5#post-566257 I don't know the functions of each (hopefully @kamoj can explain). Are RAM, Disk and NVRAM subsets of flash memory, or are they separate?
@kamoj wrote that he has some code which can be used to save and restore NVRAM early in the boot process. See https://www.snbforums.com/threads/r...ettings-after-reboot.62773/page-3#post-565540 I therefore assumed that settings are saved in NVRAM. My assumption is consistent with the command described in the next paragraph.
Are your cfg settings not being saved, or perhaps there is a glitch in the boot process that is causing them to be erased (or ignored)? Assuming that the cfg settings are stored in NVRAM, you can determine when they were last saved with the command: date -d $(nvram get config_timestamp) -D '%s' "+%F %T" I suggest that you run this command after you have saved (and backed up; I am making the assumption that the backup works correctly and actually correctly saves the settings, and not a virgin settings file) your settings. Get the date and time. Now power cycle the router. I assume that your settings will be lost. Without reconfiguring the router, telnet in and run the command again. Have the date and time changed? Backup the settings again (prior to configuring anything), and compare them with your baseline saved settings. Are the files the same or different? If they are the same, either your settings were never saved in the first place, or your saved settings are still there, but they aren't being recognized upon boot. If they are different, perhaps something in the aftermath of the power cycle caused the original settings to be erased.
In the absence of knowledge of the architecture here, it is impossible for me to suggest solutions. But I am hopeful that @kamoj might be able to help us craft a solution via a light edit of the boot script.
I believe there are only 2 types of physical memory in a typical router:
- RAM (or DRAM): This is the run-time memory used by the CPU, similar to RAM in a PC. This storage is not persistent, contents are lost when power is removed. Read and writes are very fast. RAM memory does not wear out due to use.
- Flash (NAND or NOR, or may have some of each): This is used for persistent storage, i.e. firmware, configuration, etc, similar to the hard disk or SSD in a PC. Reads are relatively fast, writes are slower. Flash memory does wear out due to erase/write cycles, so embedded systems normally limit the number of writes to Flash memory.
Flash memory is organized as a collection of small blocks, where each block can sustain a limited number of writes before wearing out. This number is usually in the thousands or even millions. Flash filesystems usually include "wear leveling" features, which spread the writes evenly across the device to prevent some blocks from wearing out faster than others. They usually also have a small number of spare blocks that can be used to replace bad blocks.
This is a quick and dirty summary, you can google for more (and better) info.
Some info about how OpenWRT uses Flash memory:
https://openwrt.org/docs/techref/flash.layout
Given the wear leveling, I'm a little skeptical about the theory that different memory organization is the reason why OpenWRT might retain settings when Netgear firmware does not. I also have no alternative theory. There are probably differences in kernel, drivers, filesystems, etc. There could even be some kind of bug lurking in the Netgear firmware that only crops up under certain configurations or conditions. It's really difficult to speculate. The best solution for those under warranty is definitely to RMA the router.
- RAM (or DRAM): This is the run-time memory used by the CPU, similar to RAM in a PC. This storage is not persistent, contents are lost when power is removed. Read and writes are very fast. RAM memory does not wear out due to use.
- Flash (NAND or NOR, or may have some of each): This is used for persistent storage, i.e. firmware, configuration, etc, similar to the hard disk or SSD in a PC. Reads are relatively fast, writes are slower. Flash memory does wear out due to erase/write cycles, so embedded systems normally limit the number of writes to Flash memory.
Flash memory is organized as a collection of small blocks, where each block can sustain a limited number of writes before wearing out. This number is usually in the thousands or even millions. Flash filesystems usually include "wear leveling" features, which spread the writes evenly across the device to prevent some blocks from wearing out faster than others. They usually also have a small number of spare blocks that can be used to replace bad blocks.
This is a quick and dirty summary, you can google for more (and better) info.
Some info about how OpenWRT uses Flash memory:
https://openwrt.org/docs/techref/flash.layout
Given the wear leveling, I'm a little skeptical about the theory that different memory organization is the reason why OpenWRT might retain settings when Netgear firmware does not. I also have no alternative theory. There are probably differences in kernel, drivers, filesystems, etc. There could even be some kind of bug lurking in the Netgear firmware that only crops up under certain configurations or conditions. It's really difficult to speculate. The best solution for those under warranty is definitely to RMA the router.
Hi @Droidrat, sorry, I have sometimes been inconsistent earlier on when using NVRAM and NAND flash--partially because the difference was not clear to me either--but I have tried to be more consistent lately by saying NAND flash because that is what I am talking about (i.e. the 128MB Micron, or SkyHigh, or Macronix NAND flash chip in an R7800). Is the NVRAM an actual separate chip on the board (the @kamoj add-on reports it as 393216 bytes in size, i.e. 384 KB)]? I don't know for sure, but I have assumed it was not, and that it was just a special file or segment somewhere on the NAND flash. And that because of historical usage with the "nvram" command, it was still referred to as "NVRAM". I could be wrong, and I am happy to find out either way. But in the long run, I'm not sure this quite matters for this case because what is disappearing during a reboot or power cycle is the higher level network data that you set via the web GUI (like initial setup info, SSIDs, DHCP reservations and names, etc.). My understanding is that this higher level data is stored in the mtd11 "config" partition on the NAND flash under official Netgear and Voxel firmwares. BTW, maybe the "NVRAM" file/database is stored under this partition, too??? Whatever the case, because the flash layout map for the NAND flash chip under OpenWRT is so different, it does not end up storing its configuration data in the same physical location on the chip as it would if running official Netgear or Voxel firmwares (i.e. the mtd11 partition). Again, if somebody in the know can clue us in, great, I am happy to hear from them even if I am completely wrong!!!
Last edited:
This is a good point, but I have only tried to build an interpretation that matches with the observations. My R7800 worked fine initially using Voxel's firmware before it fell victim to the "loss of settings on power cycle or reboot" issue. But the issue is also present under official Netgear firmware since the two are so close. My understanding from Voxel is that router configuration and settings data is stored at mtd11, which has been consistent since the earliest firmwares for the R7800--recall my comments above about the flash layout map from the earliest available v1.0.0.28 firmware--that is from Oct 2015!!! BTW, I wrote "v1.0.0.20" in my big long posting above, but I did not proofread, and it should have been "v1.0.0.28" as stated here. Since there are plenty of R7800s that are NOT experiencing this problem, it is probably not an issue with the firmware--it is likely a hardware issue. Different flash layout maps are one seemingly logical way to explain why some firmwares exhibit this issue while others don't. Again, if an expert can step in to help set the record straight, I have no problem hearing that all my guessing has been incorrect!!!
Hey, I have looked into this some more, and just came across a thread by @RMerlin that may be helpful. Yes, his work is focused on Asus routers, but I suspect it might be similar for Netgear ones, too. He writes that "NVRAM stands for Non-Volatile Random Access Memory. It's a small portion of the router's flash memory that's usually between 32 KB and 128 KB in size (depending on the router model), and which contains all the router settings. This includes both some low-level settings that are automatically managed by the router (such as power gain per antenna, GPIO addresses of hardware features, etc...), temporary storage, and user-configured settings." So this would seem to indicate that "NVRAM" is NOT a separate chip, but just a small, reserved location or file on the main 128MB NAND flash chip. Again, his posting is for Asus routers, and it might not be applicable here. The thread in question is:
https://www.snbforums.com/threads/faq-nvram-and-factory-default-reset.22822/
kamoj
Very Senior Member
A very short note on these discussions:
There is only 2 memory chips in the router. A "RAM" and an "MTD FLASH".
The MTD FLASH in the router is partitioned in a number of MTD Blocks.
The MTD is a block device, i.e. similar to an SSD disk in that sense.
Different blocks can have different type of formatting/file system.
(The "System Disk" e.g. uses squashfs that is able to compress data.
If you look in Kamoj Router Information you will see 2 different size figures,
1: one bigger value that is an estimate of how much can be stored, and 2: the physical size)
To write even a single byte you need to write a large chunk of e.g. 2048 bytes.
Then there are different techniques to hide this from the programmers.
One is to copy the MTD block to RAM and use that until it is decided to be stored persistently.
E.g. to update Netgear nvram you issue command "nvram set x=x", and to save it "nvram commit"
If you don't issue "nvram commit" you will lose the written data in case of power off or reboot.
The nvram usable for the programs is 393216 bytes but its' MTD size is 3 times bigger: 1179648 bytes.
I don't know why this is, and how it is used, maybe some redundancy? Anyone know?
And note that the nvram is not handled through UBI, so the "UBI max/mean erase counters" is as I understand not applicable here.
The nvram MTD block can easily be backup to an USB device:
I updated the Kamoj add-on Router Information to be more clear.
Here an attached picture of current look:
There is only 2 memory chips in the router. A "RAM" and an "MTD FLASH".
The MTD FLASH in the router is partitioned in a number of MTD Blocks.
The MTD is a block device, i.e. similar to an SSD disk in that sense.
Different blocks can have different type of formatting/file system.
(The "System Disk" e.g. uses squashfs that is able to compress data.
If you look in Kamoj Router Information you will see 2 different size figures,
1: one bigger value that is an estimate of how much can be stored, and 2: the physical size)
To write even a single byte you need to write a large chunk of e.g. 2048 bytes.
Then there are different techniques to hide this from the programmers.
One is to copy the MTD block to RAM and use that until it is decided to be stored persistently.
E.g. to update Netgear nvram you issue command "nvram set x=x", and to save it "nvram commit"
If you don't issue "nvram commit" you will lose the written data in case of power off or reboot.
The nvram usable for the programs is 393216 bytes but its' MTD size is 3 times bigger: 1179648 bytes.
I don't know why this is, and how it is used, maybe some redundancy? Anyone know?
And note that the nvram is not handled through UBI, so the "UBI max/mean erase counters" is as I understand not applicable here.
The nvram MTD block can easily be backup to an USB device:
Code:
root@R7800:/$ dd if=/dev/mtd11 of=/mnt/sda1/mtd11.backup
2304+0 records in
2304+0 records out
root@R7800:/$
root@R7800:/$ \ls -al /mnt/sda1/mtd11.backup
-rwxrwxrwx 1 root root 1179648 Apr 12 07:57 /mnt/sda1/mtd11.backupI updated the Kamoj add-on Router Information to be more clear.
Here an attached picture of current look:
Last edited:
Fantastic, thanks so much @kamoj for confirming that what is called "NVRAM" is not actually a different chip on the router circuit board, but it is just stored in the mtd11 partition of the main 128MB NAND flash chip.
Wear-leveling is happening as @spocko points out, but whatever the case, let's go back to the fact that this issue is NOT normal. There are many people who have been running their R7800s for several years using the same MTD flash layout/partitioning scheme, and even after hundreds of flashes and constant daily use, they have not experienced this issue. For the few data points that have been gathered, these older, more robust R7800 systems appear to be using either Micron- or SkyHigh-brand NAND flash chips. For the R7800s that do show this issue, most seem to be relatively recent (like from 2019 or later), and the issue appears relatively rapidly--not years later. At this time, we have only two NAND chip manufacturer IDs for R7800s experiencing the issue, and both are newer units, and both have Macronix-brand NAND flash chips.
As I said in my long post from yesterday afternoon, it is not clear if this affects all Macronix-brand flash chips--I suspect not!!! Instead, I suspect that it may simply be related to a limited batch of less robust chips that made it into production, so this probably only affects a limited number of routers.
Note that yes, there have been reports of lost settings due to power outages and such going back at least a couple of years on the Netgear forums, but there seem to be a lot more cases from 2019 onwards. And note that this does not affect just the R7800, but other models too. For the moment, I have a list of about ~30+ threads on the Netgear forums where people mention this issue, but I have not analyzed them systematically, for example, to get statistics on which models are affected, the potential time ranges for those models, etc. This would require a detailed analysis, and to put it in COVID-19 terms since that is on everybody's radar, it would be like a meticulous, contact tracing operation, which takes lots of time. I suspect that Netgear has already done this type of analysis and knows exactly what the problem is because the quantity of threads about this seems to suggest these are not just normal, random failures.
[COMPLETE AND UTTER SPECULATION MODE ON]
Here's another thought--this might not have anything to do with the Macronix chips themselves. Instead, it might have to do with a slight design revision to the R7800 circuit board. For example, it often happens that when a product is released, it goes through multiple revisions as issues are worked out. Some times revisions are made as it slightly cuts production costs of an item. So imagine a situation where it is concluded that if they slightly alter the router circuitry, and remove a series of $0.10 capacitors, they can simplify the product, and save an overall $2 on production costs. This directly translates into $2 extra profit per unit sold. But the net effect of such a change is that the power smoothing circuit is weakened, and thus, the NAND flash becomes super susceptible to power variations. I repeat that this is COMPLETE AND UTTER SPECULATION, but I just throw it out there as another interpretation that might fit the observations.
[COMPLETE AND UTTER SPECULATION MODE OFF]
As I mentioned, I am sure Netgear already knows exactly what the problem is. The the only way to figure it out at this level is to collect data. For the complete and utter speculation point above, resolving this may never be possible because it would require an invasive operation to actually open up the router, and look at the circuitry. I find it unlikely that folks will be willing to disassemble their R7800s while still under warranty, and once the warranty expires, well, there is little one can do after the fact except to move on. And probably most folks are not willing to buy up a batch of R7800s of different age ranges to disassemble them to see if the circuitry has changed. And furthermore, if I were one of those folks with an older, robust and stable R7800, neither would I want to jeopardize it by taking it apart to make observations. In sum, there are lots of reasons an "invasive" approach will not work--so resolving something like the complete and utter speculation point above may be impossible. That said, there may be non-invasive solutions to collect this data... For example, beyond the NAND manufacturer ID data point that we already know how to collect from the dmesg logs, it is possible that other certain data points--like Board Rev. A1, Board Rev. B2, etc.--are stored somewhere in the immutable MTD partitions, and can be read back electronically.
Last edited:
microchip
Very Senior Member
@verbage
Well, I may be wrong, but there's no v2 or v3 revision of the R7800 like there is for some models. I know this because if you go to the support site of NETGEAR, usually if there are revisions, the site asks you to select it (v1, v2, v3, etc). There is no such thing for the R7800 and a few other models. Why they didn't stuck with only one brand of NAND chips is still a mystery for me
Well, I may be wrong, but there's no v2 or v3 revision of the R7800 like there is for some models. I know this because if you go to the support site of NETGEAR, usually if there are revisions, the site asks you to select it (v1, v2, v3, etc). There is no such thing for the R7800 and a few other models. Why they didn't stuck with only one brand of NAND chips is still a mystery for me
Similar threads
Similar threads
Similar threads
-
Voxel Custom firmware build for R7800 v. 1.0.2.107SF- Started by Voxel
- Replies: 12
-
Voxel Custom firmware build for R7800 v. 1.0.2.106SF
- Started by Voxel
- Replies: 26
-
Netgear x6 r7800 power light white brightness
- Started by shs9
- Replies: 3
-
-
Voxel Custom firmware build for R7800 v. 1.0.2.105SF
- Started by Voxel
- Replies: 15
-
Voxel Custom firmware build for R7800 v. 1.0.2.104SF
- Started by Voxel
- Replies: 25
-
-
Voxel [R7800] Way to route traffic using the subdomain used?
- Started by QuinTeknoLife
- Replies: 1
-
Voxel Custom firmware build for R7800 v. 1.0.2.103SF
- Started by Voxel
- Replies: 10
Latest threads
-
-
-
LAN > DHCP List - Manually Assigned Name + Icon DONT SAVE
- Started by copperhead
- Replies: 2
-
-
Sign Up For SNBForums Daily Digest
Get an update of what's new every day delivered to your mailbox. Sign up here!