[SOLVED] ESPRESSObin "sysupgrade"

See Espressobin / mvebu cpufreq still unstable . Maybe you can change the governor and it still work

1 Like

Thanks! Trying it ... up 2 hours so far, a new record. Will let you know.

Appreciate it!

That is definitely the fix - thanks!! Up 6+ hours now, no issue.

Odd, I tried using this kernel parameter - it's supposed to work as of v5.9, but it doesn't seem to be working. Will dig more though!

cpufreq.default_governor=
2 Likes

That's good, I guess. At least it's working for you!

The linked thread talks about the 1.2GHz variant. From what I can see in /sys, mine has a max frequency of 1GHz. What do you see in /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq ?

It looks to me like the 21.02 kernel for mvebu is only 5.4 though.

Well, the linked patch talks about 1.2GHz but the original post talks about 1.0GHz v5 Espressobin, which is what I have.

I am now runnning 21.02 so we'll see whether or not it's stable. The CPU frequency has shifted to 200MHz while it's idle. If I blast the router with iperf3 it goes up to 1GHz and quickly down again when the test finishes.

1000000

Agreed! But I'm running 22.03.0-rc6, and see

Linux OpenWrt 5.10.134 #0 SMP Sun Jul 31 15:12:47 2022 aarch64 GNU/Linux

So thinking the command line argument should work?

Thanks!

Interesting. Is it an Espressobin v5? Mine seems stable, up nearly 5 hours and I ran some stress tests on it. The github issue about this suggests that the problem is fixed on 1GHz but not on 1.2GHz, which might just be the v7 or the Ultra models.

OK. Just to clarify, you did actually specify which governor in the parameter, right, and not just cpufreq.default_governor=?

Yes, a v5. And it's not stable with ondemand ... LOL. Up now ~ 12 hours, and no issues. Big change, thanks!

Yes, sorry :laughing:. Command line (from kernel log, dmesg),

[    0.000000] Kernel command line: root=PARTUUID=bc50666c-02 rw rootwait console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000

I may see the issue! My command line from U-Boot isn't being taken => I had this issue in the past (ramips), had to change some kernel config parameters. Will check!

Accoring to that other thread, you have to edit boot.scr which is embedded in the boot parameters partition and protected by checksums, which is fairly painful.

I still have an older U-Boot environment config which has the command line in U-Boot environment, because that was the only way I could get the new U-Boot for 21.02 to boot the old OpenWRT 19.07.

Keeping the command line in the environment where it's easy to edit seems preferable, I guess there were reasons to put it in the boot script.

1 Like

That's it! OK, so I went to the source code, made one minor change, to target/linux/mvebu/image/espressobin.bootscript ... it's the source file, no funky checksum. I changed / added (diff),

diff --git a/target/linux/mvebu/image/espressobin.bootscript b/target/linux/mvebu/image/espressobin.bootscript
index 07765df979..e43c64b772 100644
--- a/target/linux/mvebu/image/espressobin.bootscript
+++ b/target/linux/mvebu/image/espressobin.bootscript
@@ -25,7 +25,8 @@ fi
 part uuid ${devtype} ${devnum}:2 uuid

 setenv console "console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000"
-setenv bootargs "root=PARTUUID=${uuid} rw rootwait ${console}"
+setenv cpufreq "cpufreq.default_governor=performance"
+setenv bootargs "root=PARTUUID=${uuid} rw rootwait ${console} ${cpufreq}"

 echo "Booting Linux from ${devtype} ${devnum} with args: ${bootargs}"
 load ${devtype} ${devnum}:1 ${fdt_addr_r} @DTB@.dtb

Rebuilt, flashed, and ...

root@OpenWrt:/# dmesg | grep Kernel
[    0.000000] Kernel command line: root=PARTUUID=bc50666c-02 rw rootwait console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 cpufreq.default_governor=performance

Great, no need to change anything after the flash, the parameter is there. So checked,

root@OpenWrt:/# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
performance
root@OpenWrt:/# cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state
200000 0
250000 0
500000 0
1000000 5824

It works! So never in the wrong state, and no further changes needed. Are you able to try this as well?

Thanks!

For anyone involved, the 1.2 GHz issue is tracked here: https://lore.kernel.org/linux-arm-kernel/20210630135942.29730-1-kabel@kernel.org.

1 Like

Thanks! Very interesting, appreciate the info.

Thinking about a PR for my (small) change above ... thoughts?

You can try it, given that it's not disabling anything. But do argument very well in commit message why You want it.

1 Like

Absolutely agree - needs to be explained (well). Wondering why others aren't having the same issue - or are they?

@tmn505, @hmof - either of you able / want to test this out also?

Thanks!

Well, I'm not experiencing the same issue, so nothing can be reported from my side.

NP, fully understand!

Mine is working (up 23 hours with the 21.02 release), so I'm not going to experiment on it. Maybe it's only a problem on the newer kernel and I'll have to revisit when the next release comes out.

I've been running this board for four years with 19.07 and the release before that, using the ondemand governor, so I wonder why this problem came up at all. Something must have changed between the old 4.14 kernel and 5.4.

1 Like

Agreed! And you are running with the performance governor now (i.e. that's the 23 hour case)?

Thanks!

No, the default ondemand.

Sorry, confused - what did you change then to get it stable?