danglin

Members
  • Content Count

    12
  • Joined

  • Last visited

About danglin

  • Rank
    Member

Recent Profile Visitors

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

  1. I should mention that there is a difference between the linux and u-boot device trees for the espressobin. There is a voltage regulator that switches between 1.8V and 3.3V to power SD card. The linux tree has an entry for this regulator that the u-boot tree lacks. Possibly, this affects hot reboots. vcc_sd_reg1: regulator { compatible = "regulator-gpio"; regulator-name = "vcc_sd1"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <3300000>; regulator-boot-on; gpios = <&gpionb 4 GPIO_ACTIVE_HIGH>; gpios-states = <0>; states = <1800000 0x1 3300000 0x0>; enable-active-high; };
  2. I mentioned specifically that this helped with a SanDisk Extreme microSD card. I believe there are multiple problems and some SD cards don't work well. With a Team TUSDH32GUHS03, I consistently get a mmc error on hot reboots (0x208000). According to the Marvell 88F3700 Functional Specs, this is a read data CRC error. I've also seen u-boot fail in memory training but this doesn't happen very often. Strangely, the Team card works fine after the board boots. With the Team card, read errors occur first reading the Armbian boot.scr file, and later reading the Image, uInitrd and dtb files. With the SanDisk card, Linux would start but sometimes the root file system would fail to mount. I don't see CRC errors with it. Since I added rootdelay, the board has booted successfully every time. Three seconds is the minimum for my card. Armbian recommends Samsung and SanDisk brands. If you search Internet, you will find this is a common problem. They weren't designed for random access applications, and I believe they lack TRIMM support. I don't believe the options are conflicting and self excluding. It doesn't say that in the kernel documentation. Nominally, rootwait should cause the kernel to wait until the root file system is mounted. But, it seems trying to mount it before the SD card is ready causes problems. The rootdelay option simply delays mounting the root file system for 3 seconds. You can see delay in mounting root after Linux starts. The delay won't fix the mmc read error problem.
  3. The former works. Add "extraargs=rootdelay=3" to armbianEnv.txt for a delay of 3 seconds
  4. I changed it in the /boot/boot.cmd file: setenv bootargs "$console root=${rootdev} rootfstype=${rootfstype} rootdelay=3 rootwait resume=none loglevel=${verbosity} usb-storage.quirks=${usbstoragequirks} mtdparts=spi0.0:1536k(uboot),64k(uboot-environment),-(reserved) ${extraargs}" echo bootargs=${bootargs} Then you need to run "mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr" to regenerate /boot/boot.scr. You might want to make a backup copy of /boot/boot.scr first so that it's possible to recover easily. Since this is an armbian file, it might get updated by apt. It looks like you could add it to "extraargs" in armbianEnv.txt, or in the u-boot environment.
  5. Adding "rootdelay=3" to bootargs helped reboot with SanDisk Extreme SD card. With just "rootwait", the kernel sometimes tries to mount the root file system before the SD card is ready.
  6. Here are results for 800 and 1000: http://ix.io/1l2a http://ix.io/1l2n The inferred CPU frequencies are now reasonably consistent with configured u-boot values. We also have the old OpenSSL performance back. So, the bug is in the Linux frequency scaling code. Maybe this helps with reboot issue.
  7. The memcpy tests are better at 800. Just built a kernel without frequency scaling (CONFIG_ARM_ARMADA_37XX_CPUFREQ). Testing...
  8. Here are results for 800 MHz: http://ix.io/1l1M 800 MHz seems to be 800 MHz. I have built my own u-boot from the Marvell GitHub: TIM-1.0 WTMI-devel-18.05.0-06b6160 WTMI: system early-init DDR topology parameters: ======================== ddr type DDR3 ddr speedbin 12 bus width 16-bits cs num 2 cs[0] - group num 0 cs[0] - bank num 8 cs[0] - capacity 512MiB cs[1] - group num 0 cs[1] - bank num 8 cs[1] - capacity 512MiB CPU VDD voltage default value: 1.108V DRAM windows: ============= WIN[0] - base addr 0x60000000 WIN[0] - size 0x40000000 WIN[1] - base addr 0xa0000000 WIN[1] - size 0x20000000 memory test region: =================== CS[0] 0x60000000 - 0x7fffffff CS[1] 0x80000000 - 0x9fffffff Fill memory before self refresh...done Fill memory before self refresh...done Now in Self-refresh Mode Restore termination values to original values Exited self-refresh ... Self refresh Pass. DDR self test mode test done!! Self refresh Pass. DDR self test mode test done!! QS GATING ============= Calibration done: cycle = 0x00 tap =0x5F CH0_PHY_RL_Control_CS0_B0[0xC0001180]: 0x0000005F CH0_PHY_RL_Control_CS0_B1[0xC0001184]: 0x0000005F QS GATING ============= Calibration done: cycle = 0x00 tap =0x5E CH0_PHY_RL_Control_CS1_B0[0xC00011A4]: 0x0000005E CH0_PHY_RL_Control_CS1_B1[0xC00011A8]: 0x0000005E DLL TUNING ============== DLL 0xc0001050[21:16]: [0,32,19] DLL 0xc0001050[29:24]: [4,32,1b] DLL 0xc0001054[21:16]: [2,2b,16] DLL 0xc0001054[29:24]: [8,32,1d] DLL 0xc0001074[21:16]: [0,3f,1f] DLL 0xc0001074[29:24]: [0,3f,1f] DLL: pass NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.4(debug):armada-18.05.2:80bbf68 NOTICE: BL1: Built : 15:49:58, Aug 20 2018 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.4(debug):armada-18.05.2:80bbf68 NOTICE: BL2: Built : 15:50:01, Aug 20 2018 NOTICE: BL1: Booting BL31 NOTICE: BL31: v1.4(debug):armada-18.05.2:80bbf68 NOTICE: BL31: Built : 15:50:08 U-Boot 2017.03-armada-18.05.3-gf8e4b96 (Aug 20 2018 - 14:47:00 -0400) Model: Marvell Armada 3720 Community Board ESPRESSOBin CPU 800 [MHz] L2 800 [MHz] NB AXI 200 [MHz] SB AXI 250 [MHz] DDR 800 [MHz] For all the configurations that I have built, u-boot displays the correct CPU and DDR frequencies. Whether it is just showing config values or actual frequencies is an open question. The frquencies appear to be set in the atf code. I don't see any setting for CPU frequency in the u-boot config or device tree. I tend to think the core frequency must be correct as the USB, UART and Ethernet SERDES ports work. However, there is some issue with the sdhci@d0000 interface. The card that I have been testing usually fails to reset on shutdown, and when it does one often gets a SD data CRC error. It rarely fails on a cold start. Possibly, this could be a problem with the Boot ROM code in the 3720 or the Espressobin reset circuit.
  9. Here are the sbc-bench results for 600 and 1000 MHz, respectively: http://ix.io/1kXZ http://ix.io/1kXE There was indeed a problem with the patch for 600 MHz. There were errors in downshifting: Aug 22 13:45:44 localhost kernel: [ 1660.817973] cpu cpu0: _generic_set_opp_clk_only: failed to set clock rate: -22 Aug 22 13:45:44 localhost kernel: [ 1660.817991] cpufreq: __target_index: Failed to change cpu frequency: -22 In the end I set all the 600 MHz values to 1. debian@espressobin:~$ cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 600 MHz - 600 MHz available frequency steps: 600 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 600 MHz and 600 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 600 MHz. cpufreq stats: 600 MHz:100.00% analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 600 MHz - 600 MHz available frequency steps: 600 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 600 MHz and 600 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 600 MHz. cpufreq stats: 600 MHz:100.00% As in tkaiser's sbc-bench run, the actual clock rate at 1000 MHz seems to be 800 MHz. The clock rates match at 600 MHz. It is my understanding that the values in the dvfs table are simple dividers. These get plugged into the A53_CPU_CLK_PRSCL field in the "North Bridge Clock Divider Select 0" register. Acceptable values are 1 to 6. The internal Boot ROM sets up the PLLs and initial clock frequencies. Then, u-boot adjusts the cpu clock and ddr frequencies based on the CLOCKSPRESET value selected in the atf build.
  10. Why? The idle is set to 150MHz for 600MHz max and 200MHz for 800MHz max. The big problem was the code the 600MHz max by two. Running sbc-bench.
  11. Probably, this fixes cpu frequency issue: diff --git a/drivers/cpufreq/armada-37xx-cpufreq.c b/drivers/cpufreq/armada-37xx-cpufreq.c index 739da90ff3f6..29966b407613 100644 --- a/drivers/cpufreq/armada-37xx-cpufreq.c +++ b/drivers/cpufreq/armada-37xx-cpufreq.c @@ -77,7 +77,7 @@ static struct armada_37xx_dvfs armada_37xx_dvfs[] = { {.cpu_freq_max = 1200*1000*1000, .divider = {1, 2, 4, 6} }, {.cpu_freq_max = 1000*1000*1000, .divider = {1, 2, 4, 5} }, {.cpu_freq_max = 800*1000*1000, .divider = {1, 2, 3, 4} }, - {.cpu_freq_max = 600*1000*1000, .divider = {2, 4, 5, 6} }, + {.cpu_freq_max = 600*1000*1000, .divider = {1, 2, 3, 4} }, }; static struct armada_37xx_dvfs *armada_37xx_cpu_freq_info_get(u32 freq) The thermal values are wrong because the Armada 3700 family doesn't have a thermal sensor
  12. I have to wonder if cpu frequency scaling is working correctly. There doesn't seem much difference in temperature with u-boot built with CLOCKSPRESET=CPU_600_DDR_600 and CLOCKSPRESET=CPU_1000_DDR_800. With 600MHz u-boot, cpufreq-info shows: cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 100.0 MHz - 300 MHz available frequency steps: 100.0 MHz, 120 MHz, 150 MHz, 300 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 250 MHz and 300 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 300 MHz. cpufreq stats: 100.0 MHz:0.00%, 120 MHz:0.00%, 150 MHz:0.00%, 300 MHz:100.00% (374) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 100.0 MHz - 300 MHz available frequency steps: 100.0 MHz, 120 MHz, 150 MHz, 300 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 250 MHz and 300 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 300 MHz. cpufreq stats: 100.0 MHz:0.00%, 120 MHz:0.00%, 150 MHz:0.00%, 300 MHz:100.00% (374) The listed frquencies here seem off by a factor of two. With 1GHz u-boot, we have: cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 250 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1000 MHz. cpufreq stats: 200 MHz:0.33%, 250 MHz:80.06%, 500 MHz:1.55%, 1000 MHz:18.06% (194) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 250 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1000 MHz. cpufreq stats: 200 MHz:0.33%, 250 MHz:80.06%, 500 MHz:1.55%, 1000 MHz:18.06% (194) The frequencies here agree with u-boot. It seems the 1GHz u-boot runs at 250MHz at idle while the 600 MHz u-boot runs at 300MHz. If the numbers are correct, this would explain why both feel hot.