tkaiser

  • Posts

    5445
  • Joined

 Content Type 

Forums

Member Map

Store

Crowdfunding

Applications

Everything posted by tkaiser

  1. Another update regarding 1.3 GHz. I tried to simulate an enclosure with broken thermal design (we will see many of them!) that does not ensure enough airflow around SoC and PMU. In such an enclosure it's totally useless to try to clock the S500 with 1.3 GHz unless you allow the device to overheat. Since otherwise the device will permanently throttle down. The cpufreq speed will jump every few seconds between scaling_max_freq (1.3 GHz in my case) and scaling_min_freq (504 MHz in my case): SoC: 96°C, PMU: 84.5°C, clock 1308.0 MHz SoC: 101°C, PMU: 86.5°C, clock 1308.0 MHz SoC: 102°C, PMU: 87.4°C, clock 1308.0 MHz SoC: 104°C, PMU: 88.0°C, clock 1308.0 MHz SoC: 104°C, PMU: 88.2°C, clock 1308.0 MHz SoC: 103°C, PMU: 87.8°C, clock 504.0 MHz SoC: 98°C, PMU: 85.3°C, clock 504.0 MHz SoC: 96°C, PMU: 84.3°C, clock 504.0 MHz SoC: 95°C, PMU: 83.3°C, clock 504.0 MHz SoC: 101°C, PMU: 86.1°C, clock 1308.0 MHz SoC: 102°C, PMU: 87.2°C, clock 1308.0 MHz SoC: 104°C, PMU: 87.8°C, clock 1308.0 MHz SoC: 105°C, PMU: 88.2°C, clock 1308.0 MHz SoC: 104°C, PMU: 88.8°C, clock 1308.0 MHz SoC: 101°C, PMU: 87.0°C, clock 504.0 MHz SoC: 97°C, PMU: 84.9°C, clock 504.0 MHz SoC: 95°C, PMU: 84.3°C, clock 504.0 MHz SoC: 95°C, PMU: 83.5°C, clock 504.0 MHz SoC: 95°C, PMU: 83.3°C, clock 504.0 MHz SoC: 97°C, PMU: 83.9°C, clock 1308.0 MHz SoC: 101°C, PMU: 86.3°C, clock 1308.0 MHz SoC: 103°C, PMU: 87.2°C, clock 1308.0 MHz SoC: 104°C, PMU: 87.6°C, clock 1308.0 MHz SoC: 104°C, PMU: 88.0°C, clock 1308.0 MHz SoC: 104°C, PMU: 88.2°C, clock 504.0 MHz SoC: 98°C, PMU: 85.3°C, clock 504.0 MHz SoC: 96°C, PMU: 84.1°C, clock 504.0 MHz SoC: 96°C, PMU: 83.5°C, clock 504.0 MHz SoC: 101°C, PMU: 86.9°C, clock 1308.0 MHz SoC: 103°C, PMU: 87.8°C, clock 1308.0 MHz SoC: 103°C, PMU: 88.0°C, clock 1308.0 MHz SoC: 104°C, PMU: 88.4°C, clock 1308.0 MHz SoC: 104°C, PMU: 88.8°C, clock 1308.0 MHz SoC: 106°C, PMU: 89.4°C, clock 1308.0 MHz SoC: 101°C, PMU: 87.2°C, clock 504.0 MHz SoC: 97°C, PMU: 85.3°C, clock 504.0 MHz SoC: 97°C, PMU: 84.5°C, clock 504.0 MHz SoC: 96°C, PMU: 84.1°C, clock 504.0 MHz SoC: 95°C, PMU: 83.5°C, clock 504.0 MHz SoC: 97°C, PMU: 84.9°C, clock 1308.0 MHz SoC: 102°C, PMU: 86.9°C, clock 1308.0 MHz SoC: 104°C, PMU: 87.4°C, clock 1308.0 MHz SoC: 104°C, PMU: 87.8°C, clock 1308.0 MHz SoC: 104°C, PMU: 89.0°C, clock 1308.0 MHz SoC: 98°C, PMU: 85.5°C, clock 504.0 MHz SoC: 95°C, PMU: 84.3°C, clock 504.0 MHz SoC: 94°C, PMU: 83.9°C, clock 504.0 MHz SoC: 95°C, PMU: 83.0°C, clock 504.0 MHz SoC: 95°C, PMU: 83.0°C, clock 504.0 MHz SoC: 95°C, PMU: 82.8°C, clock 504.0 MHz SoC: 94°C, PMU: 83.0°C, clock 1308.0 MHz SoC: 101°C, PMU: 85.7°C, clock 1308.0 MHz SoC: 102°C, PMU: 86.7°C, clock 1308.0 MHz SoC: 103°C, PMU: 87.0°C, clock 1308.0 MHz SoC: 104°C, PMU: 87.4°C, clock 1308.0 MHz SoC: 104°C, PMU: 87.8°C, clock 1308.0 MHz SoC: 104°C, PMU: 88.0°C, clock 1308.0 MHz SoC: 104°C, PMU: 88.4°C, clock 504.0 MHz SoC: 97°C, PMU: 85.3°C, clock 504.0 MHz SoC: 97°C, PMU: 84.1°C, clock 504.0 MHz SoC: 95°C, PMU: 83.7°C, clock 504.0 MHz SoC: 95°C, PMU: 83.3°C, clock 504.0 MHz SoC: 94°C, PMU: 82.8°C, clock 504.0 MHz SoC: 94°C, PMU: 83.2°C, clock 504.0 MHz SoC: 95°C, PMU: 83.5°C, clock 1308.0 MHz SoC: 101°C, PMU: 85.9°C, clock 1308.0 MHz SoC: 101°C, PMU: 87.0°C, clock 1308.0 MHz SoC: 103°C, PMU: 87.2°C, clock 1308.0 MHz SoC: 103°C, PMU: 87.8°C, clock 1308.0 MHz SoC: 104°C, PMU: 87.8°C, clock 1308.0 MHz SoC: 96°C, PMU: 84.9°C, clock 504.0 MHz And if you design an enclosure where convection can jump in and apply a heatsink the same happens but less frequently: SoC: 95°C, PMU: 83.0°C, clock 504.0 MHz SoC: 98°C, PMU: 85.5°C, clock 1308.0 MHz SoC: 102°C, PMU: 86.1°C, clock 1308.0 MHz SoC: 102°C, PMU: 86.7°C, clock 1308.0 MHz SoC: 102°C, PMU: 86.7°C, clock 1308.0 MHz SoC: 102°C, PMU: 86.9°C, clock 1308.0 MHz SoC: 103°C, PMU: 87.0°C, clock 1308.0 MHz SoC: 103°C, PMU: 87.4°C, clock 1308.0 MHz SoC: 105°C, PMU: 87.6°C, clock 1308.0 MHz SoC: 104°C, PMU: 87.6°C, clock 1308.0 MHz SoC: 106°C, PMU: 87.4°C, clock 1308.0 MHz SoC: 103°C, PMU: 86.9°C, clock 504.0 MHz SoC: 96°C, PMU: 83.9°C, clock 504.0 MHz SoC: 96°C, PMU: 83.2°C, clock 504.0 MHz SoC: 94°C, PMU: 82.4°C, clock 504.0 MHz SoC: 99°C, PMU: 84.7°C, clock 1308.0 MHz SoC: 100°C, PMU: 85.7°C, clock 1308.0 MHz SoC: 102°C, PMU: 86.1°C, clock 1308.0 MHz SoC: 102°C, PMU: 85.9°C, clock 1308.0 MHz SoC: 103°C, PMU: 86.5°C, clock 1308.0 MHz SoC: 104°C, PMU: 86.7°C, clock 1308.0 MHz SoC: 102°C, PMU: 86.9°C, clock 1308.0 MHz SoC: 103°C, PMU: 86.9°C, clock 1308.0 MHz SoC: 103°C, PMU: 87.2°C, clock 1308.0 MHz SoC: 105°C, PMU: 87.2°C, clock 1308.0 MHz SoC: 103°C, PMU: 87.4°C, clock 1308.0 MHz SoC: 104°C, PMU: 87.6°C, clock 1308.0 MHz SoC: 100°C, PMU: 85.7°C, clock 504.0 MHz SoC: 96°C, PMU: 83.5°C, clock 504.0 MHz SoC: 94°C, PMU: 82.6°C, clock 504.0 MHz SoC: 94°C, PMU: 81.8°C, clock 1308.0 MHz SoC: 99°C, PMU: 85.1°C, clock 1308.0 MHz SoC: 102°C, PMU: 86.3°C, clock 1308.0 MHz SoC: 102°C, PMU: 86.1°C, clock 1308.0 MHz SoC: 103°C, PMU: 86.7°C, clock 1308.0 MHz SoC: 104°C, PMU: 86.7°C, clock 1308.0 MHz SoC: 102°C, PMU: 86.9°C, clock 1308.0 MHz SoC: 102°C, PMU: 86.9°C, clock 1308.0 MHz SoC: 103°C, PMU: 87.0°C, clock 1308.0 MHz SoC: 103°C, PMU: 86.9°C, clock 1308.0 MHz SoC: 103°C, PMU: 87.2°C, clock 1308.0 MHz SoC: 102°C, PMU: 87.2°C, clock 1308.0 MHz SoC: 103°C, PMU: 87.4°C, clock 1308.0 MHz SoC: 104°C, PMU: 87.4°C, clock 1308.0 MHz SoC: 104°C, PMU: 87.8°C, clock 1308.0 MHz SoC: 104°C, PMU: 88.0°C, clock 1308.0 MHz SoC: 104°C, PMU: 88.2°C, clock 1308.0 MHz SoC: 104°C, PMU: 87.8°C, clock 1308.0 MHz SoC: 97°C, PMU: 84.7°C, clock 504.0 MHz SoC: 95°C, PMU: 83.2°C, clock 504.0 MHz SoC: 94°C, PMU: 82.4°C, clock 504.0 MHz SoC: 96°C, PMU: 83.7°C, clock 1308.0 MHz SoC: 101°C, PMU: 85.3°C, clock 1308.0 MHz SoC: 103°C, PMU: 86.1°C, clock 1308.0 MHz SoC: 102°C, PMU: 86.5°C, clock 1308.0 MHz SoC: 103°C, PMU: 86.7°C, clock 1308.0 MHz SoC: 103°C, PMU: 86.7°C, clock 1308.0 MHz SoC: 103°C, PMU: 86.9°C, clock 1308.0 MHz SoC: 102°C, PMU: 86.7°C, clock 1308.0 MHz SoC: 103°C, PMU: 86.7°C, clock 1308.0 MHz SoC: 103°C, PMU: 83.7°C, clock 504.0 MHz SoC: 94°C, PMU: 82.4°C, clock 504.0 MHz SoC: 93°C, PMU: 81.4°C, clock 504.0 MHz SoC: 98°C, PMU: 83.9°C, clock 1308.0 MHz SoC: 101°C, PMU: 85.1°C, clock 1308.0 MHz SoC: 100°C, PMU: 85.1°C, clock 1308.0 MHz SoC: 101°C, PMU: 85.7°C, clock 1308.0 MHz To sum it up: In a 'standard enclosure' trying to clock the S500 with 1.3 GHz and set it under high CPU load over longer periods of time is totally useless since throttling jumps in and the performance is worse than with 1.1 GHz settings (multiple sysbench runs when cpufreq jumps between 504 and 1308 MHz: 188 seconds -- compare with the better 138 seconds when clocked with 1.1 GHz!). You have the following alternatives: Allow the device to overheat by adjusting /sys/devices/virtual/thermal/thermal_zone1/trip_point_0_temp or install an annoying fan. In my setup with an applied heatsink, ambient temperature around 21°C, enough airflow possible and use of convection the SoC's temperature always exceeds the 105°C treshold after a few minutes of high activity. Now imagine the board being used somewhere where ambient temperature is 10°C or even more higher. The problem will occur way earlier. Maybe I adjusted the Vcore voltage too much (I set it to 1325 mV in the kernel sources -- compare with the default 1175 mV for 1.1 GHz) but since there aren't any informations available and LeMaker doesn't confirm that they did a burn-in test lasting at least a few weeks with 1.3 GHz I consider the 'up to 1.3 GHz" phrase as pure marketing at the moment. I list the maximum SoC temperatures I measured (internally through sysfs -- please keep that in mind!) when using the 4 thread sysbench test together with the used clock speeds for all the 5 boards I tested (three times for the Guitar): LeMaker Guitar 1.3 GHz: 107°C (heatsink applied, long run of 'stress -c 4 -m 2 -i 2 -d 2' or multiple times sysbench) LeMaker Guitar 1.3 GHz: 75.5°C (heatsink applied) LeMaker Guitar 1.1 GHz: 79°C (no heatsink back then) Raspberry Pi 2 1.0 GHz: 56°C (no heatsink) Banana Pi 0.96 GHz: 46°C (same heatsink as Guitar applied) ODROID-C1+ 1.7 GHz: 62.5°C (standard heatsink applied) Wandboard Quad 1.0 GHz: 42°C (standard heatsink applied) This is an issue other testers/reviewers should also be aware of: The temperature of the Guitar's SoC increases constantly under load and it takes a few minutes to reach the maximum (after 5 minutes you get near the maximum and after approx. 12-13 min. it's reached). With the marketing settings (1.3 GHz) the problem (thermal throttling therefore worse performance with 1.3 GHz compared to the default 1.1 GHz) won't be noticed when only light workloads are used or the benchmark in question finishes fast enough. A sysbench run with 4 threads finishes within 2 minutes at 1.3 GHz. After a cold boot the Guitar's SoC then shows just 55°C above ambient temperature. If one loops endless through the tests then throttling will occur after the third run. This is important when it's about to decide whether the device is really useable with 1.3 GHz or not (BTW: the same applies to many flash/NAND based media like USB thumb drives or fast SD cards as well -- they all perform well in short benchmarks but when you choose a specific model due to their good benchmark results you'll realize that in reality the performance drops drastically if you use the device more intensive since then thermal throttling occurs)
  2. Guitar running with 1.3 GHz: I followed the advice here http://wiki.linux-xapple.org/w/index.php/Build_Howto to build an own 3.10.37 kernel for the S500 SoC in my usual Armbian build environment. I replaced in drivers/cpufreq/*-cpufreq.c static struct cpu0_opp_table cpu0_table[] = { /*khz uV*/ {1104000, 1175000}, { 900000, 1025000}, { 720000, 975000}, { 504000, 950000}, { 240000, 950000}, }; with static struct cpu0_opp_table cpu0_table[] = { /*khz uV*/ {1308000, 1325000}, {1104000, 1175000}, { 900000, 1025000}, { 720000, 975000}, { 504000, 950000}, }; Build suceeded (I also checked whether in Actions Semi's 3.10 kernel is support for UAS -- nope. If LeMaker or Actions Semi don't manage to get at least to 3.10.78 LTS and backport important stuff then it makes absolutely no sense to play with the device. Too many stuff is missing). Given that the maximum frequencies in the sources were 1.1 GHz and the temperatures when running with 1.3 GHz get really high (I use a heatsink on the SoC now which helps a little bit) and also consumption increases since when running with 1.3 GHz the core voltage must also increased I would not recommend 'overclocking' the S500 at the moment. For the same reason I won't adjust the bar diagrams above. In my eyes the S500 is 1.1 GHz max and the 1.3 GHz LeMaker's talking about are marketing/benchmark stuff. 1) sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=N: 4 Threads: 116 seconds, 90°C SoC, 75.5°C PMU, 8.1W 2 Threads: 230.5 seconds, 80°C SoC, 65.5°C PMU, 5.2W 1 Thread: 461.5 seconds, 70°C SoC, 58.5°C PMU, 4.1W 2) Memory bandwidth tests using mbw: -t0 256: 435.373 MiB/s -t1 256: 488.732 MiB/s -t2 256: 563.031 MiB/s 3) 7-zip: root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# 7za b 7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs) RAM size: 747 MB, # CPU hardware threads: 4 RAM usage: 434 MB, # Benchmark threads: 4 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 1486 330 438 1445 | 42611 393 977 3844 23: 1452 338 437 1480 | 41703 392 972 3816 24: 1395 346 433 1500 | 41023 394 966 3805 ---------------------------------------------------------------- Avr: 338 436 1475 393 972 3822 Tot: 366 704 2648 Memory bandwidth increases a little bit with the SoC being clocked higher (or maybe this has other reasons) and CPU performance scales linearly with clock speed. But since it's not possible to torture the board running with 1.3 GHz (at least for me -- maybe LeMaker or their 'SDK' give better results) I would stay with 1.1 GHz: root@Lemuntu:/home/lemaker# stress -c 4 -m 4 -i 4 -d 4 stress: info: [11317] dispatching hogs: 4 cpu, 4 io, 4 vm, 4 hdd stress: FAIL: [11317] (416) <-- worker 11332 got signal 9 stress: WARN: [11317] (418) now reaping child worker processes stress: FAIL: [11317] (416) <-- worker 11328 got signal 9 stress: WARN: [11317] (418) now reaping child worker processes stress: FAIL: [11317] (452) failed run completed in 2s root@Lemuntu:/home/lemaker# stress -c 4 -m 4 -i 4 stress: info: [11471] dispatching hogs: 4 cpu, 4 io, 4 vm, 0 hdd stress: FAIL: [11471] (416) <-- worker 11480 got signal 9 stress: WARN: [11471] (418) now reaping child worker processes stress: FAIL: [11471] (416) <-- worker 11483 got signal 9 stress: WARN: [11471] (418) now reaping child worker processes stress: FAIL: [11471] (452) failed run completed in 1s UPDATE: I let 'stress -c 4 -m 2 -i 2 -d 2' with 1.3 GHz run for an hour. Finished without a crash but temperatures were rather high. Since when I tested thermal throttling worked as expected (and I got throttling attempts everytime the SoC's temperature exceeded 105°C) I increased the trigger value to 110°C (see above for a brief explanation). Consumption measured between wall and PSU approx. 8.5W and SoC's temperatures above 105°C and the PMU's around 90°C (the board was operated vertically and the SoC has an heatsink applied. If it's lying around horizontally temperatures increase immediately. And I don't want to imagine what happens if the Guitar is under heavy load in an enclosure with broken thermal design and the throttling stuff isn't working): 234 mA 4196 mV 105°C 89.0 1308000 222 mA 4174 mV 106°C 88.8 1308000 196 mA 4050 mV 105°C 89.2 1308000 190 mA 4160 mV 107°C 89.2 1308000 256 mA 4211 mV 107°C 89.2 1308000 268 mA 4211 mV 107°C 89.0 1308000 241 mA 4138 mV 107°C 88.8 1308000 210 mA 4167 mV 106°C 88.8 1308000 222 mA 4182 mV 106°C 89.4 1308000 197 mA 4138 mV 107°C 89.4 1308000 210 mA 4035 mV 105°C 89.2 1308000 273 mA 4160 mV 105°C 89.4 1308000 275 mA 4218 mV 106°C 89.2 1308000 273 mA 4174 mV 107°C 89.2 1308000 303 mA 4160 mV 106°C 89.2 1308000 229 mA 4196 mV 106°C 89.4 1308000 229 mA 4218 mV 107°C 89.2 1308000 229 mA 4138 mV 108°C 89.2 1308000 319 mA 4211 mV 106°C 89.4 1308000 231 mA 4167 mV 108°C 89.2 1308000 228 mA 4189 mV 107°C 89.2 1308000 210 mA 4145 mV 106°C 89.4 1308000 219 mA 4160 mV 107°C 89.8 1308000 310 mA 4138 mV 107°C 90.0 1308000 213 mA 4138 mV 106°C 89.6 1308000 210 mA 4138 mV 105°C 89.6 1308000 273 mA 4145 mV 106°C 89.8 1308000 282 mA 4167 mV 106°C 89.8 1308000 210 mA 4152 mV 106°C 89.8 1308000 190 mA 4145 mV 106°C 89.8 1308000 243 mA 4189 mV 107°C 90.0 1308000 209 mA 4145 mV 106°C 89.6 1308000 235 mA 4204 mV 107°C 90.0 1308000 285 mA 4182 mV 107°C 89.8 1308000 215 mA 4145 mV 106°C 89.6 1308000 222 mA 4160 mV 107°C 90.0 1308000 279 mA 4189 mV 107°C 90.0 1308000 310 mA 4160 mV 107°C 90.0 1308000 295 mA 4145 mV 107°C 90.0 1308000 282 mA 4218 mV 107°C 90.0 1308000 304 mA 4211 mV 107°C 89.8 1308000 240 mA 4130 mV 107°C 89.4 1308000 No idea how sane that is to operate the device in this thermal range...
  3. Last update: After asking regarding USB 3.0 in LeMaker's forum they answered that a special cable is needed and relevant informations/specs will be released next week. How should one review a board marketed as being USB3 capable when such important informations are held back?!
  4. Last update: I tried to test the USB3 storage performance of the Guitar. For whatever reasons the Guitar as a host device features one single USB3 port in Micro-B fashion (instead of the well known Type A female port). I ordered an adapter cable and when I connect this with a JMicron JMS567 equipped drive enclosure behind containing my EVO 840 test SSD... nothing happens (only an error message according to dmesg output... maybe related to USB ). [ 282.104622] temp:52 [ 284.104580] temp:52 [ 285.874259] 1803: RX_ERROR status:0x0046832a root@Lemuntu:/home/lemaker# lsusb unable to initialize libusb: -99 Since LeMaker hides somewhere on their web site a warning regarding USB 3.0 ("This version currently supports not perfect for USB3.0, the next version will fix") I won't waste my time any longer with this device and consider USB 3.0 as being broken. To sum it up: this is a SBC with an interesting concept given the hardware would be Open-source hardware (OSH) (which is not the case) but very limited at the time of this writing (both network and storage being slow as hell and consumption unnecessary high). Given the quality of documentation available and the (non existing) availability of development ressources at the time of this writing it's not worth to spend any more time on this. If LeMaker will sometimes in the future release U-Boot and kernel sources and provides a base board containing an internal USB3 hub and both an ASIX AX88179 and a JMicron JMS567 (to provide GBit Ethernet and an UAS / SAT capable USB3-to-SATA bridge) and if LeMaker or the (yet non existing) community manages to fix the issues with Actions Semi's outdated 3.10.37 kernel, then it might be worth a look again (for me). Since there seems to be no efforts regarding mainline kernel support having to use this outdated 3.10.37 kernel means being cut off from important developments like modern filesystems (btrfs, F2FS and so on), basic features (consider broken UAS support over many years in Linux or the USB/ext4 fixes in 3.10.78 LTS) or even device drivers that require a more recent kernel version. Might apply to a bunch of unfixed kernel security flaws as well.
  5. Another update: This time regarding power supply, consumption and power delivery. LeMaker's specs say that the Guitar has to be fed with 5V-12V @ 2A. 12V@2A sounds strange since this is just an SBC. Is the SoC or board that inefficient? No, that's not the case. The power requirements come from the board's ability to deliver power to connected USB peripherals. According to LeMaker the Guitar's two USB2.0 ports can provide 1.7A current in total, and the USB3.0 port can provide 1.4A current. That's 5V@3.1A in total and that's the reason a 9V - 12V PSU will be necessary if you've to power a lot of external stuff. According to the same source the input voltage will be transformed to 4.28V and fed to the ATC2603C PMU (power management unit) which then creates the different voltages (3.3V, 1.8V and so on) needed by SoC and different board components. Since many PMU's values are accessible through sysfs this parameter can be looked up by querying wall_voltage: root@Lemuntu:~# cat /sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-hwmon.0/wall_voltage 4248 mV If I understood it right, the power requirements of connected USB peripherals aren't managed by the ATC2603C PMU but instead a 'discrete DC-DC component'. I tested connecting USB peripherals with the board being shut down and the power consumption immediately increased (all consumption tests using a cheap "Brennenstuhl PM 231 E" powermeter that should be very precise according to german IT magazine c't) Right now it's unclear to me whether the USB ports act like charging downstream ports (CDP) according to the USB Battery Charging Specification or whether the power delivery is proprietary (unfortunately LeMaker didn't answer that question). Theoretically there are two other ways to power the board: via a connected LiPo battery and via USB (the PMU's APDS -- Adaptive Power Distribute System -- knows BAT, VBUS and WALL as inputs and feeds SYSPWR from there). Since the current base board revisions doesn't contain a JST header any longer to connect a battery (only solder pads available) and since I don't have an USB cable with two type-A-male connectors around I won't test these modes (and what happens with USB power delivery when using battery or an USB port as input). Back to DC-IN. Since the PMU just needs 4.28V I gave the power supply of my beard trimmer a try. It's rated 4.5V/1A and works perfectly unless USB peripherals are connected. Even a sysbench run with 4 threads was no problem (consumption measured between wall and PSU reached 6W in this situation). For a headless server or home automation 5V/1A might be enough. For normal useage with not that much bus-powered USB peripherals 5V/2A should be enough. And in situations where power hungry peripherals are connected then you have to use 9V/2A or even 12V/2A. One downside of the step-down converter needed to transform the incoming voltage for the PMU and the 'discrete DC-DC component' seems to be a higher basic consumption. I used the very same 5V/2A PSU with the Guitar, an Olimex A20 Lime2 (comparable to a Banana Pro) and a Wandboard Quad since they all feature the same 2.1/5.5mm power jack and the latter two show way lower idle consumption (the Lime2 and a Banana Pro take just 1.5W when idle). The Guitar seems to use 2.7W minimum when clocked with ondemand settings (idling at 408MHz) and 3.0W when idling at 1.1GHz (performance governor). This behaviour is interesting since in the x86 world the recommendation nowadays is to better use the performance governor since Intel CPUs go into deep sleep states on their own and the faster they do the less they consume (google for the "race to idle" concept). Maybe this is just a kernel problem and things will improve in the future. With full CPU load consumption increases by more than 3W and this might be even more when LeMaker starts to give us the freedom to use also 1.3GHz (the available frequencies depend on U-Boot settings and at the time of this writing LeMaker as the 'Open Source SBCs community' plays the closed source game and holds back this stuff). Please keep in mind that this extra consumption might only apply to situations where the guitar is being fed from wall. In low-power situations when you want to clock the Guitar at its minimum and feed it from a LiPo battery then both step-down converter and DC-DC components might not be involved at all and idle consumption might be way lower. But this is an area others have to test. My main interest is in a low power server setup. Another area I couldn't test is the GPU's power consumption. If GPU acceleration can be used (according to LeMaker that's true even for Linux with the Guitar's PowerVR GPU) then a VPU/GPU under full load can consume significant amounts of power. But since the LeMedia image LeMaker provides comes with a fixed resolution of just 1024x600 pixels this is not an area where meaningful tests can happen.
  6. Another addendum regarding I/O performance of the Guitar's on-board NAND. I used the dd command from above to measure sequential write/read speeds and also the iozone calls used before to check USB disk access: dd if=/dev/zero of=sd.img bs=1M count=4096 conv=fdatasync && sync; dd bs=1M if=sd.img of=/dev/null 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 235.249 s, 18.3 MB/s 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 81.0141 s, 53.0 MB/s iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K && iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 1024K && iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m Results: random random kB reclen write rewrite read reread read write 4096000 4 18544 14556 52940 52996 4096000 1024 17521 19019 51570 51518 2048000 4 4658 0 13523 0 2506 479 Sequential writes to NAND aren't that fast (compare the results for 4K and 1M -- and think about the amount of data being written when a write attempt to syslog happens), the sequential read speeds are 2.5 times faster compared to the 20 MB/s limitation that applies to inserted SD cards. Since I haven't been able to do storage tests with USB3 due to the Micro-B-port and no adapter cable available (why on earth chose LeMaker this port for a host setup?!) I won't comment on SD card vs. eMMC vs. rootfs on USB now. Way more interesting are the IOPS results. I combine them with the 3 test runs with a Samsung EVO 840 connected over USB2 as a reference. Unfortunately it makes no sense to compare the onboard eMMC NAND with SD cards since in this area (IOPS) results vary heavily and totally depend on the SD card in question. It has also nothing do with SD classes (Class 10 for example) since these specs are all about sequential write speeds in MB/s important for digital cameras. Results: random random kB reclen write rewrite read reread read write Guitar NAND 2048000 4 4658 0 13523 0 2506 479 Guitar SSD 2048000 4 7539 0 7318 0 1940 4172 C1+ SSD 2048000 4 8211 0 8764 0 1588 2276 Wandboard SSD 2048000 4 4728 0 5227 0 4337 1615 Again: The eMMC isn't that fast when it's about writing to it (but should be faster than most SD cards)
  7. Small addendum to the performance tests: A 5th ARM board is lying around therefore also testing a Wandboard Quad Rev. B (the LeMaker Piano when available and ordered also with the quad core i.MX6 will share the same results or even 20%-25% better if it will be clocked with 1.2 GHz and faster DRAM timings are possible). Tests made with Debian jessie 8.1, kernel 4.0.3-armv7-x2, cpufreq settings set to 996000 Hz (1.0 GHz) and performance governor. This device has 2 GB RAM, a SATA port (capable of 90/100 MB/s) and GBit Ethernet (capable of approx. 400 Mbits/sec due to chipset limitations). 1) sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=N: 4 Threads: 156 seconds, 42°C SoC 2 Threads: 303 seconds, 39.5°C SoC 1 Thread: 605 seconds, 36.5°C SoC 2) Memory bandwidth tests using mbw: -t0 256: 242.051 MiB/s -t1 256: 309.936 MiB/s -t2 256: 494.953 MiB/s 3) Rather useless sequential SD card tests Skipped due to no meaningful results and different SD card used. 4) 7-zip results: root@arm:/sys/devices/system/cpu/cpu0/cpufreq# 7za b 7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs) RAM size: 2012 MB, # CPU hardware threads: 4 RAM usage: 850 MB, # Benchmark threads: 4 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 1350 283 464 1313 | 31060 376 744 2802 23: 1341 287 476 1366 | 30704 377 745 2809 24: 1298 285 490 1396 | 30274 378 743 2808 25: 1302 293 507 1486 | 29736 377 741 2796 ---------------------------------------------------------------- Avr: 287 484 1391 377 743 2804 Tot: 332 614 2097 Integer / Memory performance summary of all 5 boards: All boards have been tested with 'performance' governor (except of the RPi 2 -- there force_turbo=1 was NOT set which might slightly/negatively impact performance results). The boards were clocked with sane/safe upper speeds (except of the Guitar that should be able to run with 1.3 GHz but we can't influence that because LeMaker is holding back U-Boot and kernel sources): LeMaker Guitar, Actions Semi S500 quad core SoC, 1.1 GHz, 1 GB RAM, Lemuntu v1509, kernel 3.10.37 Raspberry Pi 2, BroadCom BCM2836 quad core SoC, 1.0 GHz, 1 GB RAM, 2015-09-24-raspbian-jessie, kernel 4.1.10+ Banana Pi, Allwinner A20 dual core SoC, 0.96 GHz, 1 GB RAM, Armbian 4.4 Wheezy, kernel 4.2.2 ODROID-C1+, Amlogic S805 quad core SoC, 1.7 GHz, 1 GB RAM, Ubuntu 14.04, kernel 3.10.80-125 Wandboard Quad Rev. B, Freescale i.MX6 quad core SoC, 1 GHz, 2 GB RAM, Debian jessie 8.1, kernel 4.0.3-armv7-x2 Please keep in mind that when the Guitar is able to be clocked with 1.3 Ghz instead of 1.1 GHz it's the fastest device without any doubt. And also keep in mind that the sysbench results for 2 or 4 threads only apply to situations where many things can happen in parallel. Normal single threaded workloads are far more better represented by the sysbench single thread bar (and also keep in mind that when A20 based devices like the Banana Pi will be overclocked with a heatsink applied then they perform close to the quad core devices listed there... with single threaded workloads): Important: While the bars might indicate that the C1+ or the Guitar or even the RPi 2 outperform the Banana Pi many times it always depends on the workload and use case in question. Whether your device can play h.264 videos in 4K smoothly or not (or at all) isn't related to these performance numbers at all. It's just a driver and OS thing (whether VPU/GPU acceleration can be used or not -- all the boards above are way to slow to handle h.264 content in high resolutions on CPU). Whether you get a faster NAS with one device or the other does only partially depend on CPU horsepower (way more important are I/O and network throughput). And so on... Graphs look nice and 'raw' numbers are easy to compare. But the question is: What's the meaning behind? How does different values affect my specific use case? And CPU integer performance might not play the key role when it's about to choose a specific board. The same applies to things like memory throughput, sequential write speeds of SD cards and all the other easy to compare but mostly insignificant stuff the usual board reviews contain.
  8. And some 7-zip results for the 4 boards (compare with here or here). If you blindly trust in these values you come to different conclusions compared to the sysbench results from above (compare with the graphs below). Here the memory bandwidth plays a more important role (and as usual with benchmarks... the question is: Does this apply to your real-world use case? Most of the times the answer will be: no) LeMaker Guitar (1391/3298 = 2344): root@Lemuntu:/home/lemaker# 7za b 7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs) RAM size: 991 MB, # CPU hardware threads: 4 RAM usage: 850 MB, # Benchmark threads: 4 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 1366 321 414 1329 | 36663 396 834 3307 23: 1332 328 413 1357 | 36131 396 834 3306 24: 1323 340 418 1423 | 35619 398 830 3304 25: 1273 345 421 1454 | 34814 397 824 3273 ---------------------------------------------------------------- Avr: 334 416 1391 397 831 3298 Tot: 365 624 2344 Raspberry Pi 2 (1267/2758 = 2013): root@raspberrypi:/home/pi# 7za b 7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_GB.UTF-8,Utf16=on,HugeFiles=on,4 CPUs) RAM size: 925 MB, # CPU hardware threads: 4 RAM usage: 850 MB, # Benchmark threads: 4 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 1231 286 418 1198 | 30478 397 692 2749 23: 1195 285 426 1218 | 30159 398 693 2759 24: 1203 294 439 1294 | 29783 398 694 2763 25: 1191 299 455 1360 | 29366 398 693 2761 ---------------------------------------------------------------- Avr: 291 435 1267 398 693 2758 Tot: 344 564 2013 Banana Pi (567/1282 = 924): root@bananapi:/sys/devices/system/cpu/cpu0/cpufreq# 7za b 7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,2 CPUs) RAM size: 1003 MB, # CPU hardware threads: 2 RAM usage: 425 MB, # Benchmark threads: 2 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 547 150 355 532 | 14237 200 643 1285 23: 542 153 362 552 | 14023 200 642 1284 24: 536 156 370 577 | 13801 200 641 1280 25: 532 159 382 607 | 13583 200 639 1277 ---------------------------------------------------------------- Avr: 154 367 567 200 641 1282 Tot: 177 504 924 ODROID-C1+ (1544/4024 = 2784): root@odroid:/# 7zr b 7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs) RAM size: 836 MB, # CPU hardware threads: 4 RAM usage: 434 MB, # Benchmark threads: 4 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 1506 274 534 1465 | 44775 386 1047 4039 23: 1545 290 543 1574 | 43912 385 1043 4018 24: 1482 285 559 1593 | 43288 386 1039 4016 ---------------------------------------------------------------- Avr: 283 545 1544 386 1043 4024 Tot: 334 794 2784
  9. Next Update -- some performance measurements. [uPDATE: LeMaker deleted their original forum post with the misleading benchmark results. And I provided a few bar diagrams also containing results from a 5th board a few posts below] Today I did a set of performance tests. There are already tests published (I assume from a LeMaker employee) over there in the LeMaker forums: http://www.lemaker.org/forum.php?mod=viewthread&tid=17277&fromuid=33332 Unfortunately the results published there are questionable/misleading. For the CPU tests they clocked the Guitar with 1.3 GHz while operating the RPi 2 with just 900 MHz and the Banana Pro obviously with 912 MHz (or maybe the performance sucks cause they used ARMv6 based Raspbian). The numbers are also wrong, especially the Guitar's excellent sysbench result with threads=4 (must be clocked with 1.5 GHz at this time otherwise impossible). So I repeated the tests and took care of boundary conditions. I added another board: LeMaker Guitar, Actions Semi S500 quad core SoC, 1.1 GHz, 1 GB RAM, 2 x USB2, 1 x USB3, 1 x Fast Ethernet Raspberry Pi 2, BroadCom BCM2836 quad core SoC, 1.0 GHz, 1 GB RAM, 1 x USB2 LeMaker Banana Pi, Allwinner A20 dual core SoC, 0.96 GHz, 1 GB RAM, 3 x USB2, 1 x SATA, 1 x GBit Ethernet Hardkernel ODROID-C1+, Amlogic S805 quad core SoC, 1.7 GHz, 1 GB RAM, 2 x USB, 1 x GBit Ethernet (you're reading right, the RPi has just 1 x USB2 and the ODROID only 2 USB2 ports, they use both an internal USB hub to provide their 4 external USB ports that have to share bandwidth this way! The RPi's network interface is also connected using the single USB2 connection between SoC and the outside) I let the Guitar run with 1.1 GHz since Lemuntu v1509 doesn't give the opportunity to clock it higher. The RPi 2 is clocked with 1.0 GHz since this is a pretty sane/safe setting. The SoC doesn't get hot at all when running benchmarks even without a heatsink. Same applies to the ODROID, can be clocked safely with 1.7 GHz. The Banana Pi was clocked with the default 960 MHz from mainline kernel (it's confirmed that it works with up to 1.2 GHz but I didn't tested that). Some tests are pretty useless (at least to me: trying to measure/compare GPU performance with gtkperf when the main point is the ability to use hardware acceleration from within Linux for video decoding and encoding... is just a joke) and some doesn't provide valuable results (like trying to measure sequential SD card transfer speed -- to which use case should this apply?) You should also keep in mind that the tester in the aforementioned thread exchanged some labels by accident (eg. read/write speed when testing the SD card wrongly since in his setup his SD card wasn't fast enough and he tested not card but instead partially RAM speed due to wrong invocation of dd) To sum it up: The single thread integer performance of all 4 boards doesn't differ that much especially if they are clocked identical. If the typical workload makes use of many parallel threads then clearly the boards with 4 CPU cores outperform an A20 based device like the Banana Pi that features just 2 CPU cores. GPU performance is about hardware acceleration. As far as I know the best situation is with the RPi's VideoCore GPU (can both encode/decode video stuff on the GPU without the CPU cores being involved) followed by the ODROID-C1+. Since I'm not interested in 'Linux as desktop' I didn't tested this area at all. Memory performance differs a lot but this doesn't influence real-world situations that much. So by looking at numbers or graphs you might not get the real picture. Storage performance can not be measured by looking at sequential read/write speeds of the SD card where the system is installed on. But since every board review contains this useless stuff (most of the times measured wrong) I repeated such tests... and all boards are close together except the ODROID where write performance sucks. To get the real picture random I/O has to be tested (and there large performance differences exist but due to different SD cards and not boards) and disk performance connected via SATA or USB. Comparing network performance is useless since RPi and the Guitar have only Fast Ethernet. The ODROID-C1+ is many times faster and the Banana Pi even more. If it's about network speed then the Guitar should get an USB3-Ethernet adapter to compete with ODROID and Banana. The RPi is a joke since all its peripherals are behind one single USB2 connection between SoC and outside. So parallel storage/network accesses block each other and real-world performance as a NAS is horribly slow. Testing the Guitar v1.3. Tests made with Lemuntu v1509, kernel 3.10.37, cpufreq settings set to 1104000 Hz (1.1 GHz) and performance governor. 1) sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=N: 4 Threads: 138 seconds, 79°C SoC, 67.5°C PMU 2 Threads: 273 seconds, 68°C SoC, 59°C PMU 1 Thread: 546 seconds, 62°C SoC, 54.5°C PMU 2) Memory bandwidth tests using mbw: -t0 256: 425.823 MiB/s -t1 256: 466.103 MiB/s -t2 256: 551.927 MiB/s 3) Rather useless sequential SD card tests Primitive dd 'test': target is a pretty fast SanDisk SD card (8GB Extreme Pro), unlike LeMaker we try to use dd correctly -- https://romanrm.net/dd-benchmark root@Lemuntu:/mnt# dd if=/dev/zero of=sd.img bs=1M count=4096 conv=fdatasync 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 225.577 s, 19.0 MB/s root@Lemuntu:/mnt# sync; dd bs=1M if=sd.img of=/dev/null 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 212.929 s, 20.2 MB/s Testing the Raspberry Pi 2. Tests made with 2015-09-24-raspbian-jessie, kernel 4.1.10+, cpufreq settings set to 1000000 Hz (1.0 GHz), NO use of force_turbo=1 config.txt reads arm_freq=1000 core_freq=450 sdram_freq=450 over_voltage=2 1) sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=N: 4 Threads: 173 seconds, 56°C SoC 2 Threads: 344 seconds, 49.5°C SoC 1 Thread: 692 seconds, 45°C SoC 2) Memory bandwidth tests using mbw: -t0 256: 447.574 MiB/s -t1 256: 980.893 MiB/s -t2 256: 1645.031 MiB/s 3) Rather useless sequential SD card tests Primitive dd 'test': target is a pretty fast SanDisk SD card (8GB Extreme Pro) root@raspberrypi:/home/pi# dd if=/dev/zero of=sd.img bs=1M count=4096 conv=fdatasync && sleep 3 && sync; dd bs=1M if=sd.img of=/dev/null 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 244.799 s, 17.5 MB/s 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 222.493 s, 19.3 MB/s Testing the Banana Pi. Tests made with Armbian_4.4 Wheezy, kernel 4.2.2, cpufreq settings set to 960000 Hz (0.96 GHz) and performance governor. The 960 MHz are the default upper limit with mainline kernel. I resigned to let the Banana Pi run at 1.2 GHz (good heatsinks applied and known to work stable at this clock speed). 1) sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=N: 4 Threads: 371 seconds 2 Threads: 371 seconds 1 Thread: 743 seconds 2) Memory bandwidth tests using mbw: -t0 256: 305.042 MiB/s -t1 256: 590.251 MiB/s -t2 256: 586.218 MiB/s 3) Rather useless sequential SD card tests Primitive dd 'test': target is a pretty fast SanDisk SD card (8GB Extreme Pro) root@bananapi:/# dd if=/dev/zero of=sd.img bs=1M count=4096 conv=fdatasync && sleep 3 && sync; dd bs=1M if=sd.img of=/dev/null 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 198.396 s, 21.6 MB/s 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 187.43 s, 22.9 MB/s Testing the ODROID-C1+. Tests made with Hardkernel's most recent Ubuntu image, kernel 3.10.80-125, cpufreq settings set to 1728000 Hz (1.7 GHz) and performance governor. The default heatsink is in use. 1) sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=N: 4 Threads: 134 seconds, 62.5°C SoC 2 Threads: 265 seconds, 60.5°C SoC 1 Thread: 539 seconds, 56°C SoC 2) Memory bandwidth tests using mbw: -t0 256: 527.641 MiB/s -t1 256: 999.952 MiB/s -t2 256: 1152.731 MiB/s 3) Rather useless sequential SD card tests Primitive dd 'test': target is a pretty fast SanDisk SD card (8GB Extreme Pro). I had to reduce the test size since Hardkernel's OS image wastes space on the 8 GB SD card I used. root@odroid:/# dd if=/dev/zero of=sd.img bs=1M count=2048 conv=fdatasync && sleep 3 && sync; dd bs=1M if=sd.img of=/dev/null 2048+0 records in 2048+0 records out 2147483648 bytes (2.1 GB) copied, 263.918 s, 8.1 MB/s 2048+0 records in 2048+0 records out 2147483648 bytes (2.1 GB) copied, 100.275 s, 21.4 MB/s
  10. Update regarding thermal issues: Through sysfs 3 trigger values are accessible/editable: /sys/devices/virtual/thermal/thermal_zone1/trip_point_0_temp: 105000 /sys/devices/virtual/thermal/thermal_zone1/trip_point_1_temp: 115000 /sys/devices/virtual/thermal/thermal_zone1/trip_point_2_temp: 125000 (translates to 105°C - 125°C). These values should influence thermal throttling (when the SoC's temp exceeds trip_point_0_temp cpufreq should be lowered) but currently only an emergency shutdown using trip_point_2_temp can be triggered. I set this value to 80000 and let some benchmarks run. When the SoC's temperature reached 80°C an automatic shutdown was initiated: root@Lemuntu:/home/lemaker# grep -A10 "critical temperature" /var/log/syslog Oct 8 09:57:57 Lemuntu kernel: [74601.156459] thermal thermal_zone1: critical temperature reached(80 C),shutting down Oct 8 09:57:58 Lemuntu systemd[1]: Started Synchronise Hardware Clock to System Clock. Oct 8 09:57:58 Lemuntu systemd[1]: Stopping Session 26 of user lemaker. Oct 8 09:57:58 Lemuntu systemd[1]: Stopping Session 19 of user lemaker. Oct 8 09:57:58 Lemuntu systemd[1]: Stopping Session 1 of user lemaker. Oct 8 09:57:58 Lemuntu systemd[1]: Stopping Sound Card. Oct 8 09:57:58 Lemuntu systemd[1]: Stopped target Sound Card. Oct 8 09:57:58 Lemuntu systemd[1]: Stopping Disk Manager... Oct 8 09:57:58 Lemuntu systemd[1]: Stopping Authenticate and Authorize Users to Run Privileged Tasks... Oct 8 09:57:58 Lemuntu systemd[1]: Stopping User Manager for UID 1000... Oct 8 09:57:58 Lemuntu systemd[1]: Stopping Graphical Interface. So at least this works. Though the defaults (shutdown when SoC's temperature exceeds 125°C) seem a bit high... UPDATE: When the kernel is built correctly thermal throttling also works correctly. Throttling sometimes works and sometimes not -- see below for more details. I built the kernel on my own and torture the device clocked with 1.3 GHz using "stress -c 4 -m 2 -i 2 -d 2". Everytime the SoC's temperature exceeds trip_point_0_temp immediately the cpufreq settings are adjusted to scaling_min_freq (set to 504 MHz): 285 mA 4167 mV 104°C 87.2 1308000 165 mA 4240 mV 97°C 84.1 504000 149 mA 4240 mV 94°C 82.6 504000 164 mA 4240 mV 94°C 82.0 504000 227 mA 4152 mV 98°C 83.9 1308000 256 mA 4145 mV 101°C 85.3 1308000 278 mA 4152 mV 102°C 85.9 1308000 218 mA 4167 mV 101°C 85.7 1308000 262 mA 4160 mV 103°C 86.3 1308000 222 mA 4152 mV 102°C 86.3 1308000 216 mA 4167 mV 102°C 86.5 1308000 281 mA 4130 mV 103°C 86.7 1308000 As usual when testing a device the relevant parameters are being monitored. In this case: /sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-hwmon.0/wall_current (no idea, seems somehow related to consumption) /sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-hwmon.0/wall_voltage (Voltage supplied to the PMU) /sys/devices/virtual/thermal/thermal_zone1/temp (SoC's temperature) /sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-hwmon.0/ic_temperature (PMU's temperature) /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq (actual CPU clock speed in Hz)
  11. Does this mean you simply trust in charger and cable and believe they're able to deliver enough current/voltage? Or did you check it? On the R1 using an image with kernel 3.4.x it's pretty easy to get a clue if you run in undervoltage/undercurrent issues or not. Simply query the PSU using sysfs (unfortunately this still does not work with mainline kernel due to missing drivers) To get a clue which sysfs entries to query and what the problem is (undervoltage might happen only in situations when the system consumes more power) read this thread here: http://www.lemaker.org/forum.php?mod=viewthread&tid=8312&fromuid=33332
  12. First storage bench: The Guitar's SoC has no SATA therefore USB has to be used to connect disks. The USB 3 port uses the Micro-B connector. So far I haven't been able to find any Micro-B-to-Micro-B cable and just one insanely expensive Micro-B-to-Female-A adapter cable. So I'm currently not able to test USB3 storage performance. Therefore I had to use USB2. I used the very same test method as described here http://linux-sunxi.org/USB/UAS Three differences 1) now I used a pretty fast Samsung EVO 840 SSD in the JMicron JMS567 equipped enclosure instead of a slow notebook disk. This explains the random write IOPS values that are way higher than the ones from the URL above 2) since LeMaker's Lemuntu ships with a kernel without btrfs support (and we currently aren't able to build our own kernel or modules due to the Actions Semi world being 'closed source') I had to rely on ext4 3) since Lemuntu's kernel and/or the S500 SoC has no UAS support the inefficient BOT mode is used. I tested with the three iozone calls from the URL above and the results are really bad (in brackets the results from a Banana Pi with Kernel 4.1.2, the same chipset but UAS used): Seq. Write: 31 MB/s (38.1 MB/s) Seq. Read: 28.5 MB/s (40.5 MB/s) Seq. write IOPS: 7539 (9284) Seq. read IOPS: 7318 (10227) Random write IOPS: 4172 (not comparable since it's now an SSD) Random read IOPS: 1940 (4956) That's the situation with USB 2.0: a Banana Pi or any Allwinner A20 device with mainline kernel utilizing UAS instead of BOT outperforms the Guitar by 10 MB/s and the difference regarding IOPS is in the same range or even worse. As a reference the 3 iozone calls used and the slightly better results from the very same test setup with an ODROID-C1+ (also with kernel 3.10 and lacking both btrfs and UAS capabilities) and also with a Wandboard Quad (kernel 4.0.3, also ext4 and no UAS -- the Wandboard's i.MX6 SoC is known for low USB performance which isn't a problem since it also features a SATA 2.0 port capable of 90/100 MB/s): iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 1024K iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m Results: random random kB reclen write rewrite read reread read write Guitar 4096000 4 31049 31140 28727 28712 4096000 1024 30817 30765 28194 28124 2048000 4 7539 0 7318 0 1940 4172 C1+ 4096000 4 35122 34699 33870 33753 4096000 1024 32499 31542 33773 33757 2048000 4 8211 0 8764 0 1588 2276 Wandboard 4096000 4 19522 19248 20906 20890 4096000 1024 19418 19193 20585 20700 2048000 4 4728 0 5227 0 4337 1615 It was not possible at all to repeat the tests on the RPi 2 because the Raspberry Pi immediately threw kernel Oops when the SSD was connected via USB. No time to investigate further.
  13. Today I tested the mechanical compatibility of 4 GPIO-Add-Ons. They all fit nicely and the distance between Add-On-board and core board is far enough to avoid shortcuts. But due to the different board layout some problems do exist. It would be a good idea if LeMaker exchanges the position of the battery connector and the mounting hole nearby so that 3 mounting holes could be used instead of 2. This would not only help with the first Add-On I tested but with many available Add-Ons and HATs that use the RPi's mounting hole positions. 16x2 LCD + IO Shield: The two top mounting holes match the positions of the wholes on Guitar's baseboard. But the bottom mounting holes are useless as well as the spacer on the bottom PCB side doesn't work so you have to DIY a mounting solution or build an enclosure where everything's securely mounted. 3.2inch TFT+Touchscreen Shield (also available from Waveshare): Same applies to this touchscreen LCD. The spacer is not of any use therefore you can't use this display with the Guitar without an specially designed enclosure I2C to 1-Wire® bridge: Same problem. You cannot use the mounting hole to attach the Add-On-board to the base or core board so you have to either take care of mechanical force or invent a solution to securely fix both base board and Add-On I2C GPIO extend board: Same problem since there is not even a mounting hole. You simply have to take care. But the space between I2C Extender and core board is wide enough
  14. Small update regarding voltage/current values that can be read out using syfs/I2C. I tried three different power sources. A small 5V/2A rated PSU and a dual voltage PSU one time using the 5V connector the other time 12V. The guitar has a step-down converter. And I have no clue how to interpret the values that can be read out: 1st PSU (5V/2A): Powermeter reports 2.7W between PSU and wall: root@Lemuntu:/sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-hwmon.0# ls | while read ; do if [ -f ${REPLY} ]; then echo "${REPLY}: $(cat ${REPLY} 2>/dev/null)"; else for file in ${REPLY}/* ; do echo "${REPLY}/${file}: $(cat ${REPLY}/${file} 2>/dev/null)"; done; fi; done aux0: 262 /1024 aux1: 256 /1024 aux2: 513 mV aux3: <channel not found> backupbat_voltage: 307 /1024 bat_current: 7 mA bat_voltage: 35 mV charge_current: 9 mA current_ref: 1921 mV driver/driver/atc2603c-hwmon.0: driver/driver/bind: driver/driver/uevent: driver/driver/unbind: hwmon/hwmon/hwmon0: icm_current: -4 mA ic_temperature: 47483 mCel modalias: platform:atc2603c-hwmon name: atc260x power/power/autosuspend_delay_ms: power/power/control: power/power/runtime_active_time: power/power/runtime_status: power/power/runtime_suspended_time: remote_control: 126 /1024 subsystem/subsystem/devices: subsystem/subsystem/drivers: subsystem/subsystem/drivers_autoprobe: subsystem/subsystem/drivers_probe: subsystem/subsystem/uevent: svcc_voltage: 3111 mV syspower_voltage: 4226 mV uevent: DEVTYPE=mfd_device DRIVER=atc260x-hwmon OF_NAME=atc260x-hwmon OF_FULLNAME=/i2c@b0170000/atc2603c@65/atc260x-hwmon OF_COMPATIBLE_0=actions,atc2603c-hwmon OF_COMPATIBLE_N=1 MODALIAS=of:Natc260x-hwmonT<NULL>Cactions,atc2603c-hwmon vbus_current: 6 mA vbus_voltage: 21 mV wall_current: 109 mA wall_voltage: 4240 mV 2nd PSU (dual voltage, the 5V outlet is used, 4.97V measured): Powermeter reports 3.8W between PSU and wall (which is ok since this PSU has a higher idle consumption): root@Lemuntu:/sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-hwmon.0# ls | while read ; do if [ -f ${REPLY} ]; then echo "${REPLY}: $(cat ${REPLY} 2>/dev/null)"; else for file in ${REPLY}/* ; do echo "${REPLY}/${file}: $(cat ${REPLY}/${file} 2>/dev/null)"; done; fi; done aux0: 52 /1024 aux1: 255 /1024 aux2: 513 mV aux3: <channel not found> backupbat_voltage: 304 /1024 bat_current: 7 mA bat_voltage: 35 mV charge_current: 9 mA current_ref: 1555 mV driver/driver/atc2603c-hwmon.0: driver/driver/bind: driver/driver/uevent: driver/driver/unbind: hwmon/hwmon/hwmon0: icm_current: 0 mA ic_temperature: 41831 mCel modalias: platform:atc2603c-hwmon name: atc260x power/power/autosuspend_delay_ms: power/power/control: power/power/runtime_active_time: power/power/runtime_status: power/power/runtime_suspended_time: remote_control: 158 /1024 subsystem/subsystem/devices: subsystem/subsystem/drivers: subsystem/subsystem/drivers_autoprobe: subsystem/subsystem/drivers_probe: subsystem/subsystem/uevent: svcc_voltage: 3111 mV syspower_voltage: 4218 mV uevent: DEVTYPE=mfd_device DRIVER=atc260x-hwmon OF_NAME=atc260x-hwmon OF_FULLNAME=/i2c@b0170000/atc2603c@65/atc260x-hwmon OF_COMPATIBLE_0=actions,atc2603c-hwmon OF_COMPATIBLE_N=1 MODALIAS=of:Natc260x-hwmonT<NULL>Cactions,atc2603c-hwmon vbus_current: 9 mA vbus_voltage: 21 mV wall_current: 87 mA wall_voltage: 4255 mV 2nd PSU (dual voltage, the 12V outlet is used, 11.84V measured): Powermeter reports 3.4W between PSU and wall (which is interesting since it's lower than the 5V value above): root@Lemuntu:/sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-hwmon.0# ls | while read ; do if [ -f ${REPLY} ]; then echo "${REPLY}: $(cat ${REPLY} 2>/dev/null)"; else for file in ${REPLY}/* ; do echo "${REPLY}/${file}: $(cat ${REPLY}/${file} 2>/dev/null)"; done; fi; done aux0: 268 /1024 aux1: 256 /1024 aux2: 513 mV aux3: <channel not found> backupbat_voltage: 307 /1024 bat_current: 7 mA bat_voltage: 35 mV charge_current: 7 mA current_ref: 1921 mV driver/driver/atc2603c-hwmon.0: driver/driver/bind: driver/driver/uevent: driver/driver/unbind: hwmon/hwmon/hwmon0: icm_current: 0 mA ic_temperature: 43390 mCel modalias: platform:atc2603c-hwmon name: atc260x power/power/autosuspend_delay_ms: power/power/control: power/power/runtime_active_time: power/power/runtime_status: power/power/runtime_suspended_time: remote_control: 0 /1024 subsystem/subsystem/devices: subsystem/subsystem/drivers: subsystem/subsystem/drivers_autoprobe: subsystem/subsystem/drivers_probe: subsystem/subsystem/uevent: svcc_voltage: 3105 mV syspower_voltage: 4226 mV uevent: DEVTYPE=mfd_device DRIVER=atc260x-hwmon OF_NAME=atc260x-hwmon OF_FULLNAME=/i2c@b0170000/atc2603c@65/atc260x-hwmon OF_COMPATIBLE_0=actions,atc2603c-hwmon OF_COMPATIBLE_N=1 MODALIAS=of:Natc260x-hwmonT<NULL>Cactions,atc2603c-hwmon vbus_current: 6 mA vbus_voltage: 21 mV wall_current: 83 mA wall_voltage: 4240 mV BTW: The PMU's temperature in the first run was higher due to the Guitar being switched on for an hour. The next 2 test runs happened immediately after a cold boot.
  15. Update: The device has 3 LEDs, the red is for power and is not easily accessible via sysfs. The blue and green ones are: root@Lemuntu:/sys/class/leds# ls -al total 0 drwxr-xr-x 2 root root 0 Jan 1 2011 . drwxr-xr-x 50 root root 0 Jan 1 2011 .. lrwxrwxrwx 1 root root 0 Jan 1 2011 blue:GPIOB31 -> ../../devices/leds.6/leds/blue:GPIOB31 lrwxrwxrwx 1 root root 0 Jan 1 2011 green:GPIOB12 -> ../../devices/leds.6/leds/green:GPIOB12 The following triggers are available (defaults in brackets): root@Lemuntu:/sys/class/leds# cat blue\:GPIOB31/trigger [none] timer oneshot heartbeat cpu0 cpu1 cpu2 cpu3 default-on mmc1 mmc2 mmc0 battery-charging-or-full battery-charging battery-full battery-charging-blink-full-solid atc260x-wall-online atc260x-usb-online rfkill0 root@Lemuntu:/sys/class/leds# cat green\:GPIOB12/trigger none timer oneshot [heartbeat] cpu0 cpu1 cpu2 cpu3 default-on mmc1 mmc2 mmc0 battery-charging-or-full battery-charging battery-full battery-charging-blink-full-solid atc260x-wall-online atc260x-usb-online rfkill0 There are also two parameters called brightness and max_brightness but they only partially work: root@Lemuntu:/sys/class/leds# ls -la green\:GPIOB12/ total 0 drwxr-xr-x 3 root root 0 Jan 1 2011 . drwxr-xr-x 4 root root 0 Jan 1 2011 .. -rw-r--r-- 1 root root 4096 Oct 5 15:36 brightness lrwxrwxrwx 1 root root 0 Oct 5 15:36 device -> ../../../leds.6 -r--r--r-- 1 root root 4096 Oct 5 15:36 max_brightness drwxr-xr-x 2 root root 0 Oct 5 14:11 power lrwxrwxrwx 1 root root 0 Oct 5 15:36 subsystem -> ../../../../class/leds -rw-r--r-- 1 root root 4096 Oct 5 15:35 trigger -rw-r--r-- 1 root root 4096 Jan 1 2011 uevent
  16. First steps with LeMaker's guitar: These days a few SBC appear that are based on Actions Semi's S500 SoC (quad core Cortex A9r4 processor with 512KB L2 Cache and a PowerVR SGX544 GPU). Two competitors share the Raspberry's form factor (they both use Actions Semi's reference design): Lemon Pi: Roseapple Pi: The Allo SPARKY is also compatible to RPi HATs LeMaker's Guitar differs in size and shape(s) since the Guitar is the combination of one core board as SO-DIMM containing SoC, DRAM and the power management unit (PMU) and a few base boards featuring different hardware: (yes, currently you won't see a product picture since the LeMaker guys seem to like broken links -- they also start every few weeks to destroy every working link between their support forum and their wiki but since noone cares... I don't care too) All boards share the same common 40 pin GPIO header known from RPi A+/B+/2 and hardware characteristics due to using the same SoC/PMU: 2 USB 2.0 ports, 1 x USB 3.0, 1 or 2 GByte DRAM, up to 64 GByte Micro-SD-card, (optional) eMMC, HDMI output, MIPI DSI/CSI connectors for LCDs and cameras and a 'native' 10/100 MBit/sek Ethernet implementation. And they also share the same software limitations: Actions Semi provides only a weird 'SDK' containing a bunch of scripts and outdated heavily patched 3.10.37 kernel sources and there is zero efforts to get Actions Semi's SoCs supported by mainline kernel (which is really bad -- Amlogic/Hardkernel show with their kernel 3.10.y branch how it should work instead: you clone the official kernel tree, get a huge patchset from the SoC's manufacturer and can then merge all official patches in your customized kernel tree). Actions Semi now seems to be there where Allwinner was back in 2012 regarding 'openness' How differs the Guitar from the other boards: The coreboard/baseboard concept should theoretically help developing baseboards that suit ones needs. But since LeMaker hardware isn't Open-source hardware (OSH) I doubt we will anytime soon see baseboards from other manufacturers than LeMaker They use a different power scheme. The base board can be fed with 5-12V @ 2A which will then be used to power USB peripherals (somehow proprietary and not acting as charging downstream ports (CDP) in conformance with the USB Battery Charging Specification) and also the voltage will be converted down to 4.28V to feed the PMU which then creates the different voltages the board's core components need. According to LeMaker they're able to supply additional 3.1A@5V on the USB ports. For details see below USB 3: According to LeMaker they couldn't use the usual blue Type A port to easily connect peripherals like disks, Ethernet adapters or USB3 hubs but had chose the Micro-B port instead since this port can automagically determine whether to operate in host or device mode (obviously they believe people do flash way more often the onboard eMMC than trying to connect USB peripherals). For reasons yet unknown to me the Micro-B port LeMaker used is incompatible with certain (most?) USB3 cables. To sum it up: USB3 isn't useable unless you're lucky enough to find an adapter cable to interconnect the Guitar with normal USB peripherals. Update: These cables do not exist and you have to customize a cable to get USB3 support with LeMaker's Guitar. Unbelievable! Since I'm neither interested in Android (should work flawlessly since Actions Semi's SoCs originate from this environment) nor in Linux as a desktop nor in GPIO stuff (should just work but unfortunately LeMaker chose wider spaces between the mounting holes which has consequences for HATs -- see below) I focused on the basics (getting any information about S500 and the board's hard- and software) and the area I'm interested in: low-power servers that act partially as a NAS. Therefore you won't find any words on GPU/VPU performance/acceleration or classical SBC/IoT stuff like interacting with sensors and stuff like that. I did some tests regarding integer performance with the default 1.1 GHz and also with 1.3 GHz using an own kernel build (you have to adjust operating points in the kernel's cpufreq sources to define clock speeds and Vcore voltage accordingly). With 1.3 GHz the S500 is the fastest quad core SoC I tested so far. But unless you use a fan I wouldn't recommend running at this speed since both SoC and PMU get freaking hot and when thermal throttling jumps in after a few minutes the performance drops drastically. Without a fan you can operate the device only short periods of time with 1.3 GHz and then it either starts to overheat or to throttle down (for yet unknown reasons throttling sometimes failed in my tests and I managed to trigger emergency shutdowns at 125°C throttling is now fixed). Therefore I used the 1.1 GHz setting for the tests. The other 4 boards I compared with were also clocked at reasonable speeds: Raspberry Pi 2, BroadCom BCM2836 quad core SoC, 1.0 GHz Hardkernel ODROID-C1+, Amlogic S805 quad core SoC, 1.7 GHz Wandboard Quad, Freescale i.MX6 quad core SoC, 1.0 GHz not yet released SBC with Allwinner's A20 quad core successor, 1.1 GHz (tests done with Banana Pi @ 960 MHz and interpolated to 1.1 GHz and 4 CPU cores) The board performs nicely in this area (same applies to sequential transfer speeds to/from SD card or eMMC) but for my use cases I/O and network performance are way more important. Due to LeMaker's choice to introduce mechanical incompabilities that prevent using USB 3.0 for this purpose I will stop at the moment. The USB 2.0 performance is bad (caused by the outdated 3.10.37 kernel we have to use with the S500 that doesn't feature UAS or btrfs support and does not contain USB/ext4 fixes and maybe also caused by Actions Semi's USB implementation) and WiFi or 10/100 Mbits/sec aren't worth to measure since other SoCs feature native GBit Ethernet. Therefore I will stop testing the Guitar unless LeMaker designs a baseboard that makes USB3 useable (featuring the normal Type A port and ideally containing an USB hub and both an UAS capable USB-to-SATA bridge like JMicron's JMS567 and an Ethernet adapter like the ASIX AX88179) and wait for Allwinner's next quad core baby that features both native SATA and GBit Ethernet It's too early to draw conclusions and my use case is obviously too specific for the Guitar. Unfortunately it was rather hard work to get/collect all the informations below and still many questions are open. Time will tell whether they'll be answered by LeMaker and Actions Semi and whether the software side evolves. With the current outdated 3.10.37 kernel the S500 is cut off from important stuff like mature kernel code for modern filesystems and tons of fixes inside the kernel (bug and/or security fixes) Original Thread starting one week ago: Today I received my Guitar (well done since it shipped at the end of last week in Shenzen and has been delivered an hour ago in Munich!). I connected it via HDMI to a display, via Ethernet to a network with DHCP server and via a simple 5V/2A PSU to wall power. The Guitar comes with 1 GByte DDR3 RAM and a quad core SoC. (Partially misleading/wrong) informations here: http://wiki.lemaker.org/LeMaker_Guitar Boot time below 30 seconds. Consumption peak at 3.5W while booting and 2.7W when idling with X server running. Both the SoC (thermal_zone1) as well as the ATC2603 PMU expose internal thermal sensors: /sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-hwmon.0/ic_temperature: 49822 mCel /sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-power.0/power_supply/battery/temp: 0 /sys/devices/virtual/thermal/thermal_zone1/temp: 60000 The PMU can be queried (and maybe its behaviour also modified) using I2C: root@Lemuntu:/sys/devices/b0170000.i2c/i2c-0/0-0065# ls -al total 0 drwxr-xr-x 29 root root 0 Jan 1 2011 . drwxr-xr-x 4 root root 0 Jan 1 2011 .. drwxr-xr-x 3 root root 0 Jan 1 2011 atc2603c-adckeypad.0 drwxr-xr-x 3 root root 0 Jan 1 2011 atc2603c-audio.0 drwxr-xr-x 3 root root 0 Jan 1 2011 atc2603c-cap-gauge.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-dcdc1.1 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-dcdc2.2 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-dcdc3.3 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ext-pwm-dcdc1.1 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ext-pwm-dcdc2.2 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-gpio.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-hwmon.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-irkeypad.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo1.1 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo11.11 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo2.2 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo3.3 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo5.5 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo6.6 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo7.7 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo8.8 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-onoff.0 drwxr-xr-x 3 root root 0 Jan 1 2011 atc2603c-pm.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-power.0 drwxr-xr-x 3 root root 0 Jan 1 2011 atc2603c-pwm.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-rtc.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-sgpio.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-switch1.1 -r--r--r-- 1 root root 4096 Oct 5 14:26 auxadc_dbg lrwxrwxrwx 1 root root 0 Jan 1 2011 driver -> ../../../../bus/i2c/drivers/atc260x_i2c -r--r--r-- 1 root root 4096 Oct 5 14:26 modalias -r--r--r-- 1 root root 4096 Jan 1 2011 name drwxr-xr-x 2 root root 0 Oct 5 14:11 power -r--r--r-- 1 root root 4096 Oct 5 14:26 pstore_dbg -rw-r--r-- 1 root root 4096 Oct 5 14:26 reg_dbg lrwxrwxrwx 1 root root 0 Jan 1 2011 subsystem -> ../../../../bus/i2c -rw-r--r-- 1 root root 4096 Jan 1 2011 uevent root@Lemuntu:/sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-dcdc1.1/regulator/regulator.1# ls -al total 0 drwxr-xr-x 3 root root 0 Jan 1 2011 . drwxr-xr-x 3 root root 0 Jan 1 2011 .. -r--r--r-- 1 root root 4096 Oct 5 14:27 bypass lrwxrwxrwx 1 root root 0 Oct 5 14:27 cpu0-cpuvdd -> ../../../../../../system/cpu/cpu0 lrwxrwxrwx 1 root root 0 Oct 5 14:27 device -> ../../../atc2603c-dcdc1.1 -r--r--r-- 1 root root 4096 Oct 5 14:27 max_microvolts -r--r--r-- 1 root root 4096 Oct 5 14:27 microvolts -r--r--r-- 1 root root 4096 Oct 5 14:27 min_microvolts -r--r--r-- 1 root root 4096 Oct 5 14:27 name -r--r--r-- 1 root root 4096 Oct 5 14:27 num_users drwxr-xr-x 2 root root 0 Oct 5 14:11 power -r--r--r-- 1 root root 4096 Oct 5 14:27 state -r--r--r-- 1 root root 4096 Oct 5 14:27 status lrwxrwxrwx 1 root root 0 Oct 5 14:27 subsystem -> ../../../../../../../class/regulator -r--r--r-- 1 root root 4096 Oct 5 14:27 suspend_disk_state -r--r--r-- 1 root root 4096 Oct 5 14:27 suspend_mem_state -r--r--r-- 1 root root 4096 Oct 5 14:27 suspend_standby_state -r--r--r-- 1 root root 4096 Oct 5 14:27 type -rw-r--r-- 1 root root 4096 Jan 1 2011 uevent Kernel config: http://pastebin.com/9bUSA7Rr For whatever reasons the device is not able to run at 1.3Ghz as advertised (UPDATE: I managed to clock it with 1.3 GHz by modifying kernel sources and building the kernel on my own -- see a few posts below): root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_available_frequencies 408000 720000 900000 1104000 root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_available_governors conservative ondemand userspace powersave interactive performance root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_cur_freq 408000 root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# echo performance >scaling_governor root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# echo 1104000 >scaling_max_freq root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_cur_freq 1104000 Clocked with 1.1Ghz it reaches 2338 7-zip benchmark points -- compare with https://s1.hoffart.de/7zip-bench/ "sysbench --test=cpu --cpu-max-prime=5000 run --num-threads=4" finishes in 19.5 seconds. Regarding integer/memory performance in these two short tests the Guitar is roughly 2.3 times faster at this clock speed compared to an A20 based device with the same clock speed: http://linux-sunxi.org/Category:A20_Boards Disclaimer: It's not clear whether memory performance improves if one disables GPU stuff (like it's the case with slow Allwinner SoCs where high display resolution/colordepth/bandwidth decreases overall memory throughput) so this is just a rough estimate and not a benchmark at all. While running the sysbench test on all CPU cores the consumption increases by 3W and the reported temperature rise up to 76°C SoC and 57°C PMU (when idle in my setup with the Guitar operated vertically with enough airflow around: 60°C SoC and 50°C PMU, when set to ondemand governor and idling at just 408 MHz the temperatures decrease to 56°C SoC and 47°C PMU). Warning: These are just values read out using sysfs and not any real measurements. I collected some other informations at the link below (apply to Guitar Core Board v1.3 and Guitar Base Board Rev. B and "Lemuntu" V1509 (http://www.lemaker.org/article-64-1.html -- obviously LeMaker doesn't care about correct informations, the kernel version there is completely wrong) http://pastebin.com/ZpMNkbU1 Complete boot log via debug UART: http://pastebin.com/X2ppDEwS Device tree used: http://pastebin.com/QNb3i9F6 Contents of /boot/uEnv.txt: uenvcmd=setenv ramdisk_addr_r -; setenv os_type linux; bootargs=earlyprintk clk_ignore_unused selinux=0 scandelay root=/dev/mmcblk0p2 rw console=tty0 rootfstype=ext4 console=ttyS3 loglevel=4 rootwait If sometimes in the future an "SDK" will be released I believe it would be a nice board to add to Armbian? Any comments on that? UPDATE: In the meantime some docs/tools have been released and maybe a community evolves around Actions Semi's SoCs: S500 manual v1.4: http://mirror.lemaker.org/Datasheet_For_S500_V1.4.pdf ATC2603C manual v2.1: http://mirror.lemaker.org/Datasheet_For_ATC2603C_V2.1.pdf image-create-tools (to combine bootloader+kernel with rootfs): https://github.com/LeMaker/image-create-tools-actions bootloader+kernel (both not as source!) LeMaker uses: https://github.com/LeMaker/hwpack-s500 XApp-le community: http://wiki.linux-xapple.org/w/index.php/Main_Page
  17. You should be aware that if you power the 2.5" disk via the board then you might run into power supply troubles. You should first check the power scheme Olimex uses. There are two alternatives: connecting the SATA power header directly to power-in (this is the way Banana Pi/Pro do it for example). If power-in isn't available the SATA disk (with your rootfs on it) will have to spindown. On the other hand if the board's AXP209 PMU decides that there are voltage drops or an undercurrent situation on power-in and it switches to LiPo then the disk won't be affected the SATA power header is driven also by the PMU (that's the way it is implemented on Lamobo R1). Would then be interesting what happens if the PMU switches between power-in (5V) and LiPo (3.7V) or how good the necessary step-up converters on the board work. In other words: You should check schematics of the board, you should get a second SD-card, use Igor's image with Kernel 3.4.x, install RPi-Monitor with sunxi additions and get a clue what's happening regarding power sources. You can search ages for software bugs if it's just an issue with your power supplies (two of them with a PMU in between that implements special logic on its own)
  18. Seems like 'special logic' implemented in the drive's firmware. The drive differentiates between 'sleeping by idle timeout' (using 'hdparm -B') and a state where you sent the drive to sleep manually (no, I don't get the logic behind). It does not work if you add 'hdparm -B255 -S60 /dev/disk/by-id/ata-ST9750420AS_5WS2FWKN' to /etc/rc.local? Currently I can not test the behaviour of RPi-Monitor when reading empty files. IIRC it will be reported as 0 then (0°C as a sign that the disk is sleeping) But you should keep in mind that the temperature of a sleeping disk is below an idle disk. The last disk I tested with had an internal temperature of approx. 4°C above the enclosure's internal temp when sleeping. When it was totally off the temperature reported was the same as the enclosure's internal. But this might differ from disk to disk (in the case of the Samsung I tested with the internal thermal sensor must be nearby electronic circuits otherwise I don't get it why there are 4°C difference between sleeping/standby and totally off. In both cases the disk's surface felt identical.)
  19. What do you mean with 'vanilla'? There's legacy (3.4) or mainline (4.x). With the latter it might be an idea. But a much better idea would be avoiding writes at all (write commits only every x minutes, ramlog). For results have a look at http://forum.armbian.com/index.php/topic/243-debian-jessie-on-bananapi-logging-performance/?p=1455 http://forum.armbian.com/index.php/topic/120-f2fs-for-rootfs/ http://www.lemaker.org/thread-15477-1-1.html
  20. It's a DS18B20 (thermal sensor via 1-Wire). I had to learn it the hard way that in the SBC world all this thermal measurement stuff totally depends on ambient/surrounding temperature. You fire up the standard set of stress tests in the morning without heatsink applied and let RPi-Monitor measure the SoC's temperature. Being back from the office in the evening you mount the newly aquired heatsink and re-run the same set of tests. Big surprise: With applied heatsink the SoC's temperature is 4°C higher than without. In fact, the room's temperature increased by 5°-6°C and so the heatsink led to 1°-2°C less compared to the situation without. If you've not always an eye on surrounding temperature you easily draw wrong conclusions :-)
  21. Just to give an idea how many information sources are available (forget about the cameras since these are Raspberry Pis that record video on the Lamobo): The disk's temp can be read using S.M.A.R.T. (hddtemp package, already included by Igor), PMU using sysfs, SoC using a small binary included with my sunxi fixes, and I also used an internal thermal sensor to get an idea what's going on (since in the enclosure are 2 PSUs and 1 LCD with backlight and signal board) In the statistics view RPi-Monitor provides graphs and there I differentiate between available voltage and used amperage for the power sources "USB OTG" and "power-in" (unfortunately not available for the LiPo connector when used together with a PSU). But this way you get a clue what sort of problem you're running into (most likely undervoltage due to bad USB cables and the most crappy connector in the world: Micro-USB).
  22. The whole idea is crap. The person supplying additional power used the wrong Micro-USB connector (USB OTG and not power-in). You always have to keep in mind that this is not a Raspberry Pi (where you can insert power easily through GPIO pins since its power scheme is totally different) but an A20/AXP209 device. And the PMU (AXP209) decides on its own where to take power from if there is more than one source available. In case you use kernel 3.4 I would suggest installing RPi-Monitor with the sunxi fixes since this immediately shows you thermal values for SoC and PMU and the power used from the three different available sources (power-in, USB-OTG and LiPo -- for the latter not exactly when you connect a PSU to the LiPo connector since the voltage can't be read out and my sunxi fixes then assume 5V). I delivered one R1 recently to a customer. Runs vertical, no heat sinks (one on the SoC but a crappy one that doesn't help at all) but some sort of convection and a small fan that jumps in if the PSU's temperature exceeds 55°C. Uptime while being totally stable for 30+ days. Temperature was a problem a few weeks ago when ambient temperature exceeded 30°C (since inside the enclosure it were 7°-8° above and then the PMU's temperature exceeded 55° -- might be ok if it gets higher but I decided to let then a fan cool down both SoC and PMU since the fan is just a few cm above both)
  23. Unfortunately there are a couple of drives that simply ignore "hdparm -B" settings. Then a daemon approach might help: http://pastebin.com/issrNdcP
  24. As far as I understand it's about the order of started services (ramlog has to be the very first and the last daemon started/stopped so that all other daemon's output will be inside the ramdisk). The parallelisms introduced with systemd make this a bit hard to achieve. Anyway: You can run jessie with SysV init instead of systemd. I tried to summarize the way Bananian does it here: https://olimex.wordpress.com/2015/08/26/devuan-jessie-for-olinuxino-images/#comments
  25. My only remaining idea is to use both .dts/.dtsi from the kernel sources as well as the included dtc command: http://elinux.org/Device_Tree#Tools