FlashBurn

Members
  • Content Count

    42
  • Joined

  • Last visited

About FlashBurn

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. 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
  2. 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.
  3. 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.
  4. 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.
  5. @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
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. The software (kernel) thinks you are running at 1 GHz, but you are not. To confirm this you could run "7zr b".
  11. @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.
  12. 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.
  13. The elegant way is supplying a lib.config in userpatches and insert the line: KERNELBRANCH='tag:v4.19.20'
  14. 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.
  15. @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.