Ok, I understand. In this case I would recommend to use the bootloader menu and a TFTP server to update the FIP image. If you want to do it in Linux, be sure to first delete the fip volume and then re-create it with the correct size as static volume, and then write it.
I figured out why I bricked my router. The sysupgrade image generated by attended-sysupgrade does not contain all the files in rootfs-1, it only contains the changed packages.
Notes for those who don't like tearing apart their router for serial recovery:
Do not use attended-sysupgrade, use full images generated by the firmware-selector, they should be 9MB or more.
The recovery image does not have fitblk, preventing a sysupgrade from recovery. This also applies to the one provided by the firmware-selector.
Edit: daniel added it to the image. Thank you! I built and upgraded it in place (see files/installer/install.sh) because I'm lazy, and it works! Hopefully I won't need to use it in the future.
Oh man. Seems like there has been an unfortunate commingling of events at just the wrong time.
The preferred language in the OpenWrt forum is english.
When writing in your native language, please always provide an english translation.
This way other users all around the world can take part in the discussion and possibly benefit from the outcome, without having to use a translator.
Thanks! 
Even worse is I noticed the image size difference and thought the auc-generated one was a delta upgrade to minimize flash wear so I flashed it anyways. At least I know how itb images work now!
Going to try running with the performance governor, since the lower voltages from the cpu/memory might be the cause of initial random flash corruption. MediaTek runs it at max on stock firmware for a reason.
1 Like
Yes I wish there was more conclusive advice on this point.
There are conflicting issues:
-
The default performance governor was changed from 'performance' to 'ondemand'.
-
Reducing power is great, but increasing e-waste is not.
-
There is the theory that capacitor-related aging is temperature dependent, and so running at higher temperature for longer will give rise to faster wear. But in my mind I'm dubious about this. Isn't the aging rate such that we are talking different numbers of decades (e.g. 80 years vs 50 years), at which point our RT3200's will be obsolete anyway? Or doesn't thermal cycling up and down like a YoYo actually worsen things, potentially? Since YoYo'ing temperature means more rapid expansion and contraction of parts?
-
There's also some speculation that the CPU clock variation might hurt SQM especially w.r.t bursty traffic. Logical (and at least one of the original CAKE developers seems to share this concern), but I haven't actually seen any concrete data demonstrating any such hurt. My guess is that this might make a difference in the 0-5ms range, but this is only speculation based on my own testing on my 4G connection.
-
There were some scary reboot problems relating to low CPU rates.
-
There is some concern about possible data corruption issues relating to variable CPU rates. Such corruption issues seem to be potentially bricking devices at the moment.
-
MediaTek apparently stated that they only ever tested running at full rate all the time. Perhaps this is dispositive? Please see this report:
Should we all just run our RT3200's with the 'performance' governor to be on the safe side? I think I'm beginning to lean towards thinking that we should. And perhaps this should be made the default again? I mean do we really know better than those who actually designed this hardware? Isn't that a profound and foolish arrogance?
I wonder what the consensus is in respect of the performance governor:
- I think it is better to use: 'ondemand'
- I think it is better to use: 'performance'
- I do not know.
0
voters
3 Likes
An earlier post comparing ondemand vs performance says there's only a 2-3 C temperature increase from the performance governor, marginal compared to leaving it inside vs outside a cabinet. I think we've had more bricked routers from flash vs capacitors so far. By the time this router completely fails, a comparable used replacement will be available for $20 on eBay.
We know (by consensus) that the RAM does not like low CPU voltage at startup. We really should have listened to the designers and run it using performance like they tested it, trying to save a few watts this way isn't that effective versus other things (HVAC, fridge, computers) in the house.
2 Likes
There will be no final answer even if you ask this every day here from now on. Mediatek - the vendor - would be needed to officially answer this.
From what I read there is no consensus on this question even in Mediatek because another Mediatek developer gave information on power save modes. Itâs already discussed multiple times on this thread.
Even having one opinion majority on the question here from users will not give a safe answer.
1 Like
Please quote the source where the engineers at Mediatek all run the device only at full speed.
I donât think that sharing and discussing opinions here will help solving the issue.
What would help is further analysis of the root cause and trying solution ideas.
If you like to run your device at full speed all the time: do it now. Itâs just one line in the rc.local file. If your device had boot or reboot problems on ondemand scheduler before and you could reproduce a solution by changing to performance governor please report this. For now I only have one report where raising the min_freq clock speed to at least 600 MHz increased reboot stability and 437 MHz or below failed to boot.
I have not read anyone reporting that switching to performance governor has solved the cold boot or reboot problems.
I've been told this by multiple MTK engineers when diving into the problem below. If you are insisting I will dig out the original communication.
An additional datapoint is the code in MediaTek's SDK (publicly available through numerous GPL drops as well as mtk-openwrt-feeds), and in there they do not use frequency scaling on any of their router SoCs (and that's what goes through QA and is then used by basically all commercial board makers to build their firmware)
The "root cause" is that the core voltage does not seem to be reset when we reset the board (eg. due to a reboot). The solution would be to take care of that as the first thing bl2 does before advancing to DRAM initialization.
However, registers used to control core voltage are undocumented (or rather: documented only by the Linux driver)
It does, I've observed this myself and it has been reported by multiple users in this thread.
10 Likes
I'm using 'schedutil' and 437500 as minimum freq with no issues.
1 Like
Thanks for the reply. Why not have performance governor set as new default for all mt7622 targets in the sources for main and 23.05 branch and advice everyone to switch to performance governor via rc.local in the TOH wiki as intermediate workaround?
I would enter this in the wiki by myself but my application to get an account is repeatedly ignored. (solved, thank you @daniel and @slh)
Very helpful. Thank you for posting this.
Shouldnât the default indeed get changed back to âperformanceâ?
I donât understand the question. Itâs a serious issue that can brick devices. From how I understand @daniel the solution is to run the SoC at full clock speed 24/7. Why should we continue to risk bricking MT7622 devices with ondemand governor set as default?
The default is now 'ondemand'. That's why I suggested it get changed back to 'performance'.
Yes, I now suggested this after daniel explained his position, too:
I donât get your question point. The decision can be made by developers with write rights to the OpenWrt sources.
I fully agree and always did so. In fact, it wasn't me merging the change to switch to the ondemand governor instead of performance (or userspace which has the same effect).
The only reason why I haven't reverted the change is my fear of ending up in an edit-war with those users who really wanted it. That's why I think this poll in the forum started by @Lynx is a good approach, because it will give legitimacy to carry out the change and shift the debate to the forum and it won't just be me having to waste time over it. (I do care to some point, but if there is a strong opinion against I will not enforce things even if I know that "it's the right thing to do", simply because I have more important things to do than arguing, reasoning and getting involved in edit-wars -- after all, this is something where I can easily divert for my local systems just by setting my own default in /etc/rc.local).
8 Likes
Given everything that has been discussed so far, there's a very convincing case to use "performance" as the governor.
If Lynx's poll is going to be used as justification for a change, I went up and voted for the "performance" option.
1 Like
Users are still free to deviate from the source code default on their device by setting a different scaling governor. Itâs just one line of code in rc.local.
We would hopefully gain boot and reboot stability for the price of going back to stock power efficiency and thermals. The increased power efficiency of ondemand performance governor is proven get us a brick risk. This is much more expensive, hurts budget and application than stock power efficiency in my opinion.
3 Likes
Just want to report that my router has been running continuously on performance governor since that post, and I have no issues or complaints at all. In fact, as I noted, the Luci web interface even feels quicker.
Updated graphs:
and
1 Like