Jump to content

tkaiser

Members
  • Posts

    5455
  • Joined

Posts posted by tkaiser

  1. 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 get 
    1000-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

  2. 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   137287
    

    That 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.

  3. 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)

  4. 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).

  5. 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'

  6. 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)

  7. 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)

  8. 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...

  9. 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?!

     

    IMG_5730_small.jpg

  10. 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.

  11. 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.

  12. 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)

  13. 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):

     

    cpu-sysbench.png

     

     

    7-zip.png

     

    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.

  14. 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
    
  15. 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
  16. 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)
  17. 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

  18. 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.

  19. 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

     

    IMG_5710.jpg

     

    IMG_5711.jpg

     

    IMG_5712.jpg

     

    IMG_5713.jpg

     

    IMG_5709.jpg

     

    IMG_5707.jpg

  20. 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. 

  21. 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
    
  22. 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.jpg
     
     
    RoseapplePi.jpg
     
    The Allo SPARKY is also compatible to RPi HATs
     
    allo_sparky.jpg
     
    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:
     
    033934obsbbxeaaeb1yaar.jpg
     
    (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)
    A40-sysbench.png
     
    A40-7-zip.png
     
    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
     
     
    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)
     
     
    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:
  23. 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)

×
×
  • Create New...