FlashBurn

As an arch kernel is working like it should, maybe it is a problem of the kernel config?

I just tried the current bootloader for 1200 MHz and 1000 MHz and the current Buster image (5.6.19) and still don´t get the right frequency It now recognizes the maximum frequency right, but if I use 7zip to verify I still don´t have the right frequency with 1200 MHz bootloader -> 750 MHz with 1000 MHz bootloader -> 800 MHz Can someone tell me if it works for them or if it is the same as for me?!

I still don´t get it. I tried archlinux with a kernel 5.8 and it worked like it should. So I tried armbian and build my own kernel 5.7.16 (dev) and still the problem that I don´t get the right frequency. Does anyone has an idea what I can check to find the differences between the archlinux kernel and the armbian kernel?

How? I wanted to change the kernel, but there are only old kernels on armbian-config. So how can I change to a nightly built? Or do you mean from the download site? This hasn´t worked for me yesterday, but I can try tomorrow again. Edit:: Nope, still not working (nightly built download). Goes right to 404

Is there a time frame when espressobin will also have a newer kernel version? I tried arch linux with kernel 5.8 and there the espressobin was working as intended, but on the armbian kernel 4.19.120 (or something like that) it is still not running with the right frequency

I found some time and tried the current version on my board: http://ix.io/26iy Still the same problem that the frequency is the wrong one Am I the only one who is bothered by this? Does it work right for others?

Ok, with the newest kernel 4.19.67 it is still the same with the 1200 MHz firmware: http://ix.io/1T82 So I will wait again half a year till trying it again

Oh man, I once again found some time to do some testing and hoped that the EspressoBin now runs fine, but what have I to find. I updated the bootloader to the current version from 21th May and a current armbian 5.91 (kernel 4.19.59). First I did a test with the 800MHz version: http://ix.io/1T75 I was impressed, because now it seems the kernel can read out the frequency from the firmware (I did not need to change the cpu frequency and it worked out of the box). Then I tried the 1200MHz version and again, the kernel reported the right frequencies without me changing any configuration (besides the firmware update). But then this: http://ix.io/1T7g I thought that the patches for configuring the cpu frequency right where backported? So I will try to build my own kernel and will see how that works.

Maybe you could bring me on line what problems you experience with the newer kernels? I assume it is the problem that with a bootloader for 1000 MHz you have instabilities? If I´m right then a new bootloader will not help with this. What you can test, commenting out the avs in the dts file, compile a dtb and then test if the kernel is working for you.

I haven´t tried an armbian kernel for a while now. I will look into this sometime in the next weeks. But as far as I followed the upstream fix should be in the kernel 4.19.xx. It is just one fix missing regarding a too low voltage, which @sqpr found. I will see if I can point the right people at this patch.

@spqr If you use an unpatched kernel and still got stability problems, yes this then looks like the cpu has also problems at 800 MHz

Here it comes It works like this, you have a base frequency of e.g. 1000MHz and you have 4 load levels. For every load level you can define a divider and a core voltage. Base frequency divider real frequency core voltage 1000 MHz 1 1000 MHz 1.10 V 1000 MHz 2 500 MHz 1.05 V 1000 MHz 4 250 MHz 1.00 V 1000 MHz 5 200 MHz 0.95 V Without the patches for the cpu freq driver the kernel thinks it uses a base frequency of 1000 MHz, but in reality is looks like this: Base frequency divider real frequency core voltage 800 MHz 1 800 MHz 1.10 V 800 MHz 2 400 MHz 1.05 V 800 MHz 4 200 MHz 1.00 V 800 MHz 5 160 MHz 0.95 V As the cpu is running with a lower frequency in reality it also is not a problem that the core voltage is not high enough for the lower load levels. The problem is not the core voltage of the highest load level, but the lower load levels (which one precisely I don´t know). I hope I could explain it to you, if something is still not clear, just ask.

This file does not exist anymore with a current kernel, but the code got merged with the cpufreq driver. But nice finding, because this particular patch is missing or somewhere where I did not find it.

As far as I know, Bootlin is the company which writes the kernel code for Marvell. Interessting that they can reproduce the problem, so maybe this gets more attention.

I just gave a hunch a try and this is the result running sbc-bench stable at 1000 MHz: sbc-bench.sh log output If anyone wants to test this kernel I could upload it to dropbox for everyone to download. As my board was reacting kind of unpredictable, my assumption was that there is a hardware problem with stability, but only at 1000 MHz. So my guess was that the core voltage is to blame, but as the board does run fine at 1000 MHz, it has to be a problem of the core voltage at lower frequencies. So I made a kernel without activating the AVS (automatic voltage scaling). This seems to solve the stability problems on my board. Next step would be to try to let the AVS not use so low voltages, but at the moment I don´t have the time to try this out. I will tell these findings to the linux kernel developer of the cpufreq driver and we will see if he can fix it.

The software (kernel) thinks you are running at 1 GHz, but you are not. To confirm this you could run "7zr b".

@spqr I have to be picky, but your board does not run at 1 GHz, but 800 MHz and that is why it is stable We still don't know if our boards are running stable with 1 GHz without fixing the cpu scaling bug. But as your board boots justs fine at 1 GHz your board is doing better than my V7 board.

The patches which where sent to the kernel mailing list are the same as the one in my pull request. As for me the newer kernels also do not work (kernels without my patch) is this not a problem of the patches, but of something which is wrong in the kernel. Edit:: Some more notes regarding the pull request. Situation now: Firmware running 1000 MHz, real cpu frequency is 800 MHz. Situation with the patch from the pull request: Firmware running 1000 MHz, real cpu frequency is 1000 MHz. So if the board does not run with 1000 MHz, but it did before, just flash the firmware with 800 MHz cpu frequency and it has the same performance like before, but everyone can run the board at the right cpu frequency. Just to be clear, I don´t see the problem why not applying the pull request. The pull request fixes 2 bugs and now things work as expected, but it also maybe does show that some boards are not running up to their specs.

The elegant way is supplying a lib.config in userpatches and insert the line: KERNELBRANCH='tag:v4.19.20'

I just changed my pull request so that my patch is the same code like the 2 patches sent to the mainline kernel mailing list.

@spqr I would need the precise kernel version, especial the number "y" of your kernel (4.19.y), because for me the newer kernels don´t work with 1000 MHz, but older do. Edit:: Just saw that you edited your post and now you gave the precise version. Strange, for me this is a version which does not work. I will have time for this next weekend, maybe I can find a change which broke the kernel for me.

There are 2 patches which were sent to the linux kernel mailinglist. I will change my patches to these 2 patches and adjust my pull request accordingly. With these patches the cpu frequency scaling is working. "Only" problem left is that the current kernel is not working with the 1000 MHz firmware.

I can confirm that the kernel which is in the armbian image 5.69 is running with the 1000 MHz firmware and the kernel 4.19.20 is not. So this is a general kernel problem and not a problem of my patch. We just need to find what the problem is

So, maybe some people can tell which firmware and which kernel version they use running at 1000 MHz that works for them (board revision just for the record). I want to find out if it maybe could be that the newer kernels are not working at 1000 MHz anymore.

@spqr And what firmware did you use? Their ubuntu kernel should be not so different to the mainline regarding the clocks and cpu frequency scaling.