FlashBurn

Members
  • Content Count

    14
  • Joined

  • Last visited

About FlashBurn

  • Rank
    Member

Recent Profile Visitors

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

  1. FlashBurn

    Espressobin support development efforts

    So the good thing is I found the problem, the bad thing is I don´t know how to fix it The problem is, like I assumed, that the wrong clock source is selected or better to say, no clock source is selected and because of that it is the wrong one. In drivers/cpufreq/armada-37xx-cpufreq.c the dvfs is initialized. The right clock source should be selected with the 2 lines at the end of the function armada37xx_cpufreq_dvfs_setup(). But this does not call the needed function clk_pm_cpu_set_parent() in driver/clk/armada-37xx-periph.c. I fixed it for me with hard coding the right value in the registers. So all that is needed for fixing the problem is that the function clk_pm_cpu_get_parent() needs to be called, to get the right clock source and then clk_pm_cpu_set() needs to be called with that source. I don´t know enough about the clk code to know what needs to be done the right way. The question is now, whom to tell this, so that this could be fixed? This is a sbc-bench.sh run with my hard coded fix and 1200MHz: http://ix.io/1BCD
  2. FlashBurn

    Espressobin support development efforts

    I had a look at marvell's linux kernel source and I'm pretty sure that cpu frequency scaling worked with version 4.4.52 for 600, 800 and 1000MHz, but not with 1200MHz because the wrong clock source was selected for 1200MHz. So I assume if this kernel set the clock source that the current kernel also sets the clock source and that there is something wrong. I just have to find out where and who sets this ;-)
  3. FlashBurn

    Espressobin support development efforts

    I tried to find something which seems off in the bootcode, but everythinh I looked at seems to be correct. I had a look at version 17.06 and 18.12 and the clocks are initialised the same. This is backed up by the fact that the cpu frequency seems right as long as the kernel does not try to change the frequency. If someone could test the old firmware with a current kernel and tell the result it would maybe help. My next guess is that the wrong clock source is selected in the kernel. There is one function which seems to select a clock source for the cpu and there it could happen that the wrong clock got selected. The file is drivers/clk/mvebu/armada-37xx-periph.c and the function clk_pm_cpu_set_parent(). I will try if I can find out who calls this function, but till now I had no luck in finding that out. I come to this conclusion, because it also seems the cpu is running with the selected (from the firmware image one uses) ram frequency. I will try to try this out with running all 4 firmware images (1200, 1000, 800 and 600) and when the performance is saying that the cpu is running with the ram frequency it is one step to solving this problem. As background information, one can select 4 sources for the clock of the peripherals (tbg-a-s, tbg-a-p, tbg-b-s and tbg-b-p) and with a divider of 1 and the wrong tbg the cpu runs with the wrong frequency.
  4. FlashBurn

    Espressobin support development efforts

    I tested a kernel with the applied patch for correctly recognize the XTAL, but this did not help with setting the right cpu frequency I will try to have a look what uboot does and maybe I find something what is different to what the kernel does. Can someone tell an uboot and kernel version which worked?
  5. FlashBurn

    Espressobin support development efforts

    I think I found the problem, but at the moment I can´t get my board to run longer than a minute and so can´t test it. The mainline kernel is missing a patch from marvell´s kernel tree: https://github.com/MarvellEmbeddedProcessors/linux-marvell/commit/80d4cec4cef8282e5ac3aaf98ce3e68fb299a134 The problem seems to be that the code detects a wrong XTAL with 40MHz, but the frequency of the XTAL is just 25MHz. With this wrong assumption the PLL values are calculated wrong. So maybe someone could give this patch a try and tell back if it fixes the problem with the wrong cpu frequency.
  6. FlashBurn

    Espressobin support development efforts

    I just used arch linux as another test to find out where the problem could be and I also was able to reproduce the good benchmark values on armbian too. With the armbian kernel it is the same, as long as the cpu frequency scaling is not used, the performance is as expected. And I assume this is right for all board revisions. I was able to compile my own kernel and uboot and will now check if I can find something out. But this will take some time as there is no documentation for the cpu available.
  7. FlashBurn

    Espressobin support development efforts

    Ok, this is as far as I got today: I can reproduce the expected results in arch linux with 1200MHz. This is a log from sbc-bench.sh: sbc-bench.sh log output The problem seems to be the cpu frequency scaling. If I don´t change the cpu governor in arch, then it seems to performance and this one seems not to change the cpu frequency and it stays as put in by uboot. I modified sbc-bench as to not change the cpu frequency scaling and voila I get the expected results. If the cpu frequency scaling ever worked, something changed somewhere (uboot? kernel?) and this is the problem. I will try to look further if I can find the problem. Edit:: Just finished reading some pages back of this thread and there you already came to the same conclusion that something is wrong with the cpu scaling Has anyone tried to investigate further what the problem is and/or where one has to look?
  8. FlashBurn

    Espressobin support development efforts

    I´m still trying to figure out what is wrong with the performance/cpu frequency. I also did try the current armbian uboot with arch linux and this is my result from 7zip: [alarm@alarm ~]$ uname -a Linux alarm 4.20.7-1-ARCH #1 SMP PREEMPT Wed Feb 6 18:58:45 MST 2019 aarch64 GNU/Linux [alarm@alarm ~]$ 7z b 7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=C,Utf16=off,HugeFiles=on,64 bits,2 CPUs LE) LE CPU Freq: 64000000 - - - - - - - - RAM size: 993 MB, # CPU hardware threads: 2 RAM usage: 441 MB, # Benchmark threads: 2 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 1040 166 610 1012 | 25746 200 1102 2198 23: 1017 172 604 1037 | 25251 200 1095 2186 24: 1002 176 612 1078 | 24677 199 1086 2166 25: 990 183 619 1130 | 24088 200 1074 2144 ---------------------------------- | ------------------------------ Avr: 174 611 1064 | 200 1089 2174 Tot: 187 850 1619 This is a result as one would expect from 7zip running with 1200MHz (according to the results from tkaiser). I got sbc-bench.sh running under arch, but now I´m not able anymore to reproduce this result So if anyone got a tip what I could try. Is it possible that the cpu throttles because of temperature?
  9. FlashBurn

    Espressobin support development efforts

    @ebin-dev No I did not know about this, but this does not explain the results for 1000MHz. I had a quick look at your benchmark result and also there it seems the cpu is just running at 800 MHz. Both the measured frequence and the performance indicate that the cpu is not running with 1000 MHz.
  10. FlashBurn

    Espressobin support development efforts

    If I trust the log file and the measurements behind it, your board is also just running with 800MHz. Now it would be good if someone if a V5 board could run the benchmark and post their result. So we could find out if the problem with the cpu frequency is just a problem with the new revision or if it is a general problem.
  11. FlashBurn

    Espressobin support development efforts

    I just got my EspressoBin V7 and did some tests with it. I flashed the current uboot as told on the download page. Then I measured the performance of the board with sbc-bench (from tkaiser) and found that something is wrong with the cpu frequency. This is the console output from the "flash-image-DDR4-1g-1cs-1200_750.bin": TIM-1.0 WTMI-devel-18.12.0-a0a1cb8 WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.260V NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.5(release):1f8ca7e (Marvell-devel-18.12.2) NOTICE: BL1: Built : 13:50:24, Dec 26 2018 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.5(release):1f8ca7e (Marvell-devel-18.12.2) NOTICE: BL2: Built : 13:50:25, Dec 26 2018 NOTICE: BL1: Booting BL31 NOTICE: BL31: v1.5(release):1f8ca7e (Marvell-devel-18.12.2) NOTICE: BL31: Built : 13 U-Boot 2018.03-devel-18.12.3-gc9aa92c-armbian (Dec 26 2018 - 13:45:06 +0100) Model: Marvell Armada 3720 Community Board ESPRESSOBin CPU 1200 [MHz] L2 800 [MHz] TClock 200 [MHz] DDR 750 [MHz] DRAM: 1 GiB Comphy chip #0: Comphy-0: USB3 5 Gbps Comphy-1: PEX0 2.5 Gbps Comphy-2: SATA0 6 Gbps Target spinup took 0 ms. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIE-0: Link down MMC: sdhci@d0000: 0 Loading Environment from SPI Flash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB OK Model: Marvell Armada 3720 Community Board ESPRESSOBin Net: eth0: neta@30000 [PRIME] Hit any key to stop autoboot: 0 And this is the link to the log output of the sbc-bench.sh run: sbc-bench.sh log output As one can see the cpu frequency is under 800MHz although I used the uboot for 1200MHz. Even the performance suggest that the board is not even running with 800MHz. This is the console output from the "flash-image-DDR4-1g-1cs-1000_800.bin": TIM-1.0 WTMI-devel-18.12.0-a0a1cb8 WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.132V NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.5(release):1f8ca7e (Marvell-devel-18.12.2) NOTICE: BL1: Built : 13:50:08, Dec 26 2018 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.5(release):1f8ca7e (Marvell-devel-18.12.2) NOTICE: BL2: Built : 13:50:09, Dec 26 2018 NOTICE: BL1: Booting BL31 NOTICE: BL31: v1.5(release):1f8ca7e (Marvell-devel-18.12.2) NOTICE: BL31: Built : 13:5 U-Boot 2018.03-devel-18.12.3-gc9aa92c-armbian (Dec 26 2018 - 13:45:06 +0100) Model: Marvell Armada 3720 Community Board ESPRESSOBin CPU 1000 [MHz] L2 800 [MHz] TClock 200 [MHz] DDR 800 [MHz] DRAM: 1 GiB Comphy chip #0: Comphy-0: USB3 5 Gbps Comphy-1: PEX0 2.5 Gbps Comphy-2: SATA0 6 Gbps Target spinup took 0 ms. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIE-0: Link down MMC: sdhci@d0000: 0 Loading Environment from SPI Flash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB OK Model: Marvell Armada 3720 Community Board ESPRESSOBin Net: eth0: neta@30000 [PRIME] Hit any key to stop autoboot: 0 And this is the link to the log output of the sbc-bench.sh run: sbc-bench.sh log output As one can see the cpu frequency is circa 800MHz although I used the uboot for 1000MHz. Even the performance suggest that the board is running with 800MHz. If someone is putting me in the right direction I can try to compile another uboot/kernel and test again.
  12. Would it possible that armbian supplies the needed dtb for the V7 with aonther name and one has just to make sure that the right file is loaded by uboot? Can I assume that if I put my own dtb file at the right position that it will never be overwritten by a kernel update?
  13. Thanks. Does this mean the change will not be in a newer version of armbian or it will take some time till the pull request will be in armbian? I will have a look at the needed changes and try to make them.
  14. I just got my EspressoBin V7 and installed the current armbian for it. I haven't tested much, but Globalscale has changed the numbering of the ethernet ports, as can been seen in the Wiki of the EspressoBin. What do I have to do to rename the ports permanently, so that no update can change it back? Or is this something that needs to be changed in armbian for the V7 boards?