Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. As an arch kernel is working like it should, maybe it is a problem of the kernel config?
  2. 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?!
  3. 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?
  4. 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
  5. 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
  6. 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?
  7. 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
  8. 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.
  9. 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.
  10. 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.
  11. @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
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  • Create New...