Same question actually, got lost in recent days (nobody answered):
How is CPU governor related to — or different from — manually setting the CPU frequency to a number (e.g. 437MHz or 600Mhz)?
Keep in mind I have not experienced the boot issues; I chose to switch to the performance governor voluntarily, after reading about the boot issues, but now wonder if it's even relatable?
Practically it's the same, just when using a governor it's harder to predict at which speed and voltage you will end up in the exact moment of the reboot -- shutting down services and means increased work-load for the CPU results on the lowest operating points to be unlikely to be chosen at the moment when the SoC is reset -- just not unlikely enough to be reliable.
So using performance tells the SoC to run at maximum all the time, guaranteeing that upon reboot the CPU will already be at maximum? Is that a fair clarification?
If so, using performance would seem to solve the minimum frequency boot/reboot issue we've all been discussing here, wouldn't it?
I really like the power efficiency of the RT3200.
Almost all modern processors support voltage and frequency scaling to save power.
It would be weird if Mediatek did not support this in some way.
But if there is proper evidence this is bricking routers, please change the default.
Both settings configure the CPU clock speed scaling:
https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt
Performance governor statically sets max clock speed all the time while min_freq only defines the minimum allowed scaling clock speed.
They did in their SoCs intended for smartphones, tablets and chromebooks. Some of it made it into MT7622 (probably as a left-over from copy&pasting from another design). More recent SoCs (MT7986, MT7981) completely dropped capabilities for frequency scaling or controlling Vcore by software.
And even more recent SoC (MT7988) again add frequency scaling (but done quite differently) as well as an external PMIC to control Vcore via I2C...
So to me (not knowing the internal reasons for those decisions) this looks very much like there was a need to re-design that part for some reason (we may have found it now).
There is evidence that lowering the core voltage to 0.9V and/or CPU frequency to 437 MHz or below causes bl2 to hang in DRAM calibration on reboot.
There is no conclusive evidence that this is related to the flash corruption issues we have (increasingly) been seeing as well, and while there are (unlikely) chances for this to be linked it's by far not the only possible explanation.
It could be that bl2 is very sensitive to ECC errors and fails even in case of correctable errors.
It could also just be that (as this area of the flash is only written once) bitflips just increase over time and the corrected data is never re-written to the point that too many bits have flipped.
All that should now be resolved by moving FIP into UBI.
echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
Is this the correct way to enable performance governor?
Thank you!
Correct! Do two things:
/etc/rc.localYou can confirm the setting with
$ cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
performance
Devices shouldn’t be running outside of manufacturers spec. It often leads to issues, this is the second time for this device alone… First with the out of spec wifi and now this. The intentions are good but the outcome isn’t 
Thank you!
The spec sheet clearly states a ‘Green’ feature: frequency scaling.
So can you provide the evidence that this is outside the spec?
I find that listed only on wikidevi:
- Green: Intelligent Clock Scaling (exclusive) DDR: ODT off, Self-refresh mode
in MediaTek's product the SoC is presented as running at 1.36 GHz constant speed.
https://www.mediatek.com/products/home-networking/mt7622
And the statement on wikidevi can be read that this feature is subject to compatibility with DRAM chips (which may not be the case for the DDR RAM on that specific board, as we can see; maybe it is only supported when MT7622 is used with DDR2 RAM or specific DDR3 chips?)
Which one? I just see this:
How applicable is that?
I also remember working in an engineering firm and conscious of the discrepancy between what was marketed and reality. I'm inclined to trust the engineers here.
In any case, if the case for positive support of frequency scaling is as tenuous, it shouldn't be the default, right?
I am writing this in haste, but the below seems right in the short time I've been thinking about it.
Namely we don't need to show that the spec explicitly does not support a feature to warrant not using that feature; rather the absence of explicit support of that feature surely is enough to warrant not using that feature? And again this is only regarding what is the default. Override is always possible for the adventurous. Compare with overclocking.
Whelp, that UBI update was relatively painless. Thanks for your work @daniel!
I did do an oopsie and accidentally flashed the recovery on my WAX220 (gotta check the IP addresses better next time!), but luckily that model has A/B partitioning and restored itself after it couldn't boot, so nothing's broken.
Kernel 6.1.79, baby!
@daniel Is it going to be possible to use serial instead of jtag to repair a bricked E8450 with the BL2 serial message?
I'm... not the best at making these connections to the JTAG headers on this board.
To me, it looks like a datasheet stating the feature of frequency scaling on the first page as a 'Green' power saving feature. I have not found any voltage/frequency tables though.
Daniel made a very nice summary of the issue. If setting the default solves the DRAM calibration 'hang' then that alone should be reason enough to change the default (just my opinion). I was just looking for the evidence that is 'outside of spec' and I have not seen hard evidence that this is the case.
Just want to say I am loving the investigatory and courteous spirit in these discussions, and especially want to thank Daniel for his great work honestly transforming a "pretty good" router into a phenomenal one with a bright future.
Yes. Just think how much joy @daniel has brought to so many individuals with his efforts here. In general it has been a fun thread to keep tabs on. What terrific little devices these have been for our amusement, friendly collaboration and experimentation. Three cheers to @daniel and the OpenWrt spirit!
Does everyone on 6.x kernel see these two errs
Wed Feb 28 03:36:00 2024 kern.err kernel: [ 0.603266] OF: Bad cell count for /spi@1100d000/flash@0/partitions
Wed Feb 28 03:36:00 2024 kern.err kernel: [ 0.609539] OF: Bad cell count for /spi@1100d000/flash@0/partitions
Yes, both in the normal boot, and I see it in the logs from the re-installer.
normal boot:
reinstaller:
Writing from /installer/mt7622-snand-ubi-1ddr-bl2.img to /dev/mtd0 ...
ubiformat: mtd1 (nand), size 133693440 bytes (127.5 MiB), 1020 eraseblocks of 131072 bytes (1s
libscan: scanning eraseblock 1019 -- 100 % complete
ubiformat: 999 eraseblocks have valid erase counter, mean value is 0
ubiformat: 11 eraseblocks are supposedly empty
ubiformat: 1 bad eraseblocks found, numbers: 638
ubiformat: warning!: 9 of 1019 eraseblocks contain non-UBI data
u[ 14.137615] platform 1b100000.ethernet: deferred probe pending
ubiformat: formatting eraseblock 1019 -- 100 % complete
[ 15.548260] ubi0: default fastmap pool size: 50
[ 15.552815] ubi0: default fastmap WL pool size: 25
[ 15.557651] ubi0: attaching mtd1
[ 15.871031] ubi0: scanning is finished
[ 15.879484] ubi0: attached mtd1 (name "ibu", size 127 MiB)
[ 15.884985] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[ 15.891887] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[ 15.898680] ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
[ 15.905634] ubi0: good PEBs: 1019, bad PEBs: 1, corrupted PEBs: 0
[ 15.911723] ubi0: user volume: 0, internal volumes: 1, max. volumes count: 128
[ 15.918946] ubi0: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 1
[ 15.928077] ubi0: available PEBs: 994, total reserved PEBs: 25, PEBs reserved for bad PEB 9
[ 15.937392] ubi0: background thread "ubi_bgt0d" started, PID 472
UBI device number 0, total 1019 LEBs (129388544 bytes, 123.3 MiB), available 994 LEBs (126214)
Volume ID 0, size 9 LEBs (1142784 bytes, 1.0 MiB), LEB size 126976 bytes (124.0 KiB), static,1
Volume ID 1, size 5 LEBs (634880 bytes, 620.0 KiB), LEB size 126976 bytes (124.0 KiB), static1
[ 17.541485] OF: Bad cell count for /spi@1100d000/flash@0/partitions
Volume ID 2, size 1 LEBs (126976 bytes, 124.0 KiB), LEB size 126976 bytes (124.0 KiB), dynami1
[ 17.563591] OF: Bad cell count for /spi@1100d000/flash@0/partitions
Volume ID 3, size 1 LEBs (126976 bytes, 124.0 KiB), LEB size 126976 bytes (124.0 KiB), dynami1
write recovery ubi volume
Volume ID 4, size 56 LEBs (7110656 bytes, 6.7 MiB), LEB size 126976 bytes (124.0 KiB), dynami1
[ 19.214627] block ubiblock0_5: created from ubi0:5(fit)
Volume ID 5, size 1 LEBs (126976 bytes, 124.0 KiB), LEB size 126976 bytes (124.0 KiB), dynami1
writing backup files to ubi volume...
Volume ID 6, size 67 LEBs (8507392 bytes, 8.1 MiB), LEB size 126976 bytes (124.0 KiB), dynami1
[ 19.247577] UBIFS (ubi0:6): default file-system created
[ 19.253137] UBIFS (ubi0:6): Mounting in unauthenticated mode
[ 19.258950] UBIFS (ubi0:6): background thread "ubifs_bgt0_6" started, PID 516
[ 19.287944] UBIFS (ubi0:6): UBIFS: mounted UBI device 0, volume 6, name "boot_backup"
[ 19.295787] UBIFS (ubi0:6): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 20s
[ 19.305720] UBIFS (ubi0:6): FS size: 7237632 bytes (6 MiB, 57 LEBs), max 67 LEBs, journal )
[ 19.316947] UBIFS (ubi0:6): reserved for root: 341850 bytes (333 KiB)
[ 19.323402] UBIFS (ubi0:6): media format: w5/r0 (latest is w5/r0), UUID DE3E1E41-6DA7-428El
[ 19.643187] UBIFS (ubi0:6): un-mount UBI device 0
[ 19.647986] UBIFS (ubi0:6): background thread "ubifs_bgt0_6" stops
[ 24.698420] reboot: Restarting system