tkaiser
-
Posts
5462 -
Joined
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by tkaiser
-
-
Orange Pi with A31s
What?! Ah, seems Xunlong sent you a preliminary sample with A31s and switched in the meantime to H3 for the 'plus' (not the worst reaction to the news that A31/A31s have been discontinued a while ago ;-)
-
FYI: I donated the M2 I bought a while back in the meantime to the linux-sunxi community. Hans de Goede fortunately had the time to look into it. Regarding quality/state of .dts/defconfig SinoVoip created for the M2 he wrote that they're not really production ready:
Seem to be copy paste from some other boards and then modified until things
work somewhat [...], e.g. the oob interrupt for the wifi is wrong so you get1000-s of interrupts / second (it basically triggers as fast as it can).He started from scratch writing new versions of the two files:
https://github.com/jwrdegoede/u-boot-sunxi/commit/24c82ec836bc34c2086e93f7baa67333a30930ca
https://groups.google.com/forum/#!topic/linux-sunxi/hLOu3iRGfnU
-
Shame on me - using the right working directory results in ...
KB reclen write rewrite read reread 32768 512 160596 297245 480645 482294 32768 1024 161545 298827 494379 492901 ... 2048000 512 39911 40169 138249 140220 2048000 1024 39789 39804 135877 137287That looks much better.
And it shows clearly why testing with files smaller than the system's amount of available RAM is useless: Since then mostly buffers/caches were tested.
I would test with the 3 settings mentioned here http://linux-sunxi.org/USB/UAS#Testing_3_different_external_enclosuresagain and see how the SATA disk behaves.
-
Please see the footnote for the M1+ here: http://linux-sunxi.org/Banana_Pi#Variants
There do differences exist and if you ever realized how bizarre the M1+'s manufacturer creates hardware descriptions (be it fex files or .dts) then you won't expect that anything works. I tried hard to get one M1+ a while ago but SinoVoip's european distributor was not able to help me (they offered me the Banana Pro which they don't distribute or the M2 or the M1 and so I gave up)
Since the schematics of both boards are available (see the link above and http://www.lemaker.org/thread-14686-1-1.html) you might search for different pin mappings and correct them yourself (Igor ships both the needed bin2fex and fex2bin binaries)
-
One thing to mention: iozone does its tests in the current working directory (should be obvious but while troubleshooting sometimes the most basic steps are easy to miss). So ensure you change into a dir that is on your disk before otherwise you might end up testing the SD card.
Then I would always run in another terminal "iostat 5" while testing (since it prints both I/O stuff -- per device so you know you're testing the right one -- as well as CPU utilisation and on Linux also %iowait percentage). And with mainline kernel and the right cpufreq settings (always use performance for tests) the A20 is able to exceed 40/200 MB/s (SATA write/read).
-
The second approach cannot work since the images already contain bootloader, partition table and data, therefore you neither need to partition your card prior to burning nor should you overwrite a specific partition but the whole card instead.
Have you checked the integrity of the SD card? There's an error related to not being able to read the partition table in your screenshot. Never ever use flash based media without a whole integrity check before.
And I would try Armbian/Wheezy for Banana Pi. Can't remember with which version it was but I also had starting issues with jessie some time ago.
BTW: If you're on OS X it should read 'bs=1m' instead of 'bs=1M'
-
I finished the review now and added a few more informations and a summary at the top of the thread.
-
And another important update regarding thermal throttling: It sometimes works and sometimes don't
I made a set of tests with permanent sysbench runs to get an idea how much throttling will affect performance when clocked with 1.3 GHz (performance is worse than with the default 1.1 GHz maximum). Then I adjusted the maximum frequency back to 1.1 GHz and had a look what happens:
echo 1104000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
To my surprise even in this situation the SoC's temperature exceeded 105°C (that's where throttling should jump in). I took the extinguisher in place and at 112°C decided to adjust the clock speed back to 1.3 GHz:
echo 1308000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
Just to realize that throttling doesn't work any longer and 73 seconds later when the SoC's temp reached the default shutdown treshold of 125°C the board rebooted (no idea why, it should've shut down instead): http://pastebin.com/k2qSiNUQ
So my first assumption that it's a kernel config thing whether thermal throttling will jump in or not was wrong. It seems it works most of the time... and sometimes not...
I did another test with LeMaker's default kernel/settings and tried to emulate a crappy enclosure (thermally broken by design). Even with default settings from LeMaker no throttling happens and the SoC's temperature reaches 114°C and the PMU's exceeds 95°C: http://www.lemaker.org/forum.php?mod=redirect&goto=findpost&ptid=22505&pid=89702 (that's a bit scary given I already applied a heatsink to the device)
-
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)
-
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 2648Memory 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...
-
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?!
-
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.
-
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.
-
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 479Sequential 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 1615Again: The eMMC isn't that fast when it's about writing to it (but should be faster than most SD cards)
-
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 testsSkipped 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 2097Integer / 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.
-
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 2344Raspberry 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 2013Banana 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 924ODROID-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 -
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 testsPrimitive 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-benchmarkroot@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=1config.txt readsarm_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 testsPrimitive 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 testsPrimitive 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 testsPrimitive 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
-
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)
-
I use an ipad charger and a good one meter usb cable.
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
-
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 1615It 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.
-
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
-
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 mV2nd 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 mV2nd 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 mVBTW: 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.
-
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
-
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):
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 tocustomize 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°Cthrottling 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 EthernetIt'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_GuitarBoot 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/9bUSA7RrFor 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_BoardsDisclaimer: 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)Complete boot log via debug UART: http://pastebin.com/X2ppDEwSDevice tree used: http://pastebin.com/QNb3i9F6Contents 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
changing motd on banana pro
in Beginners
Posted
https://duckduckgo.com/?q=motd+site%3Aforum.armbian.com